Hi, Francesca:
As requested by our AD, we did request media type review from you in earlier email (Wed, Aug 25, 2021 at 6:26 AM). I thought the media type review job has already been assigned to
someone you appointed. Kevin Ma who is also one of coauthor of draft-ietf-cdni-request-routing-alto-16 did contact you for media type review (See separate email I forward to you offline), let us know if we should follow up by ourselves and send the media type
registration to the media type mailing list? What is the procedure for the media type review?
-Qin (on behalf of chairs)
发件人: Francesca Palombini [mailto:francesca.palombini@xxxxxxxxxxxx]
发送时间: 2021年12月2日
6:46
收件人: Thomas Fossati <Thomas.Fossati@xxxxxxx>
抄送: art@xxxxxxxx; draft-ietf-alto-cdni-request-routing-alto.all@xxxxxxxx; IETF ALTO <alto@xxxxxxxx>; Thomas Fossati <Thomas.Fossati@xxxxxxx>; last-call@xxxxxxxx
主题: Re: [alto] Artart last call review of draft-ietf-alto-cdni-request-routing-alto-16
Thomas: thank you very much for this review! And thanks to the authors for addressing it. I balloted DISCUSS to get the JSON in
one of the examples fixed, and to encourage the authors to send the media type registrations to the media-type mailing list for review before the document moves forward.
Thanks,
Francesca
Hi Jensen,
Thanks very much for addressing my review. Your proposed changes
generally look very good to me.
Some more (very minor) comments in-lined below.
cheers!
On 07/09/2021, 12:04, "Jensen Zhang" <jingxuan.n.zhang@xxxxxxxxx> wrote:
> > On Sat, Aug 28, 2021 at 8:28 AM Thomas Fossati via Datatracker <noreply@xxxxxxxx> wrote:
> > It is not clear to a newcomer why a RESTful design is listed as one
> > of the criteria for choosing ALTO. Please be more specific about
> > the advantages. E.g., it's a good fit with the rest of the CDNI
> > suite and therefore reduces the cognitive dissonance for users and
> > developers alike? It allows at least some level of code reuse?
>
> Thanks for the suggestion. We will add the following sentence into
> this bullet to make the benefit clear:
>
> [...] It can provide the consistent
> client-server interaction model for other existing CDNI interfaces
> or potential future extensions and therefore reduce the learning
> cost for both users and developers, although they are not in the
> scope of this document. A CDNI FCI interface ...
That's great. Although, I'd argue that developers are certainly in
scope :-) and -- to a smaller extent -- users too.
> We will add the following note before Sec 3.1:
>
> Note that the encoding of BaseAdvertisementObject exactly reuses
> the one defined in [RFC8008] and therefore also follows the
> recommendations of I-JSON (Internet JSON) [RFC7493], which is
> required by [RFC8008].
Great. (Maybe you could drop "exactly".)
> > # Section 3.2
> >
> > Is there any specific recommendation regarding caching of these
> > resources?
>
> Can you explain more? ALTO is based on HTTP and therefore can reuse
> HTTP cache control. Is it what you are looking for?
Yes, I was wondering whether you have any specific recommendation for
the cache control settings associated with the resources you define.
> > I am having a hard time parsing this text:
> >
> > Note: Further optimization of BaseAdvertisement objects to
> > effectively provide the advertisement of capabilities with
> > footprint restrictions is certainly possible.
> >
> > what optimisation are hinted here? And what is their relation with
> > the examples? Are those associated with the use of altopid? If so,
> > you should consider adding a forward reference to section 4.1 here.
>
> Example 1 contains two BaseAdvertisementObject objects for delivery
> protocol http/1.1 and https/1.1 respectively.
> But they have the same footprint constraints.
> Example 2 merges them to a single BaseAdvertisementObject.
> It has not been associated with altopid yet.
> Do you think we need to illustrate the examples more?
The examples are pretty clear to me. The thing that I couldn't
understand was what "further optimization [...] is certainly possible".
Is this referring to the merged example?
> > [...] a filtered CDNI Advertisement request is invalid if:
> >
> > o the value of "capability-type" is null;
> >
> > o the value of "capability-value" is null;
> >
> > What if one of capability-type or capability-value is missing? What
> > if one of them is the empty value for the type or if any mandatory
> > fields are missing? What if the value in "capability-type" is not
> > known? It'd seem to me that the conditions that can make a request
> > invalid can be many more than those currently listed. And in
> > general I'd leave the decision to the server.
>
> Here we just discuss the E_INVALID_FIELD_VALUE error because this is
> the only case that [RFC7285] does not define how to commonly handle.
>
> For missing field cases, the ALTO server returns E_MISSING_FIELD. For
> other cases, the ALTO server returns E_INVALID_FIELD_TYPE.
WFM, and thanks for the explanation! My comment was obviously missing
the wider ALTO context.
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose,
or store or copy the information in any medium. Thank you.
--
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call
