Re: [alto] Shepherd review for draft-ietf-alto-cost-mode-01

[[e-mail]]

Hi Kai, 

The changes are raisonnable. 

A new version that implements the changes edits is now online. 

Thanks. 

Cheers,
Med

> -----Message d'origine-----
> De : [e-mail] <[e-mail]>
> Envoyé : samedi 16 avril 2022 03:49
> À : [e-mail]
> Cc : BOUCADAIR Mohamed INNOV/NET <[e-mail]>;
> Qin Wu <[e-mail]>
> Objet : Shepherd review for draft-ietf-alto-cost-mode-01
> 
> Dear WG and authors of draft-ietf-alto-cost-mode,
> 
> I am posting this review of draft-ietf-alto-cost-mode-01 to the
> mailing list, as part of my shepherd write-up. Any comments and
> feedback are more than welcome!
> 
> Best,
> Kai
> 
> ===================
> 
> This draft extends the base ALTO protocol (RFC 7285) by relaxing
> the constraint on valid cost mode values and introducing a new
> IANA (sub-)registry to document new cost mode values. The
> motivation is clear and the proposed mechanism is clean. Most
> comments raised in Call for Adoption and WGLC are addressed in the
> latest revision except Dhruv's comment [1] on giving more detailed
> specifications of the contents in IANA registry. There are two
> remaining comments and I think the draft is ready for publication
> once they are addressed.
> 
> Comments:
> 
> Section 3.1, last paragraph: The paragraph says
> 
>    Future documents that define a new cost mode SHOULD indicate
> whether
>    that new cost mode applies to all or a subset of cost metrics.
> 
> In that case, it seems to me that the default behavior should be
> specified in case the applicability of the new cost mode is not
> indicated. Either the "SHOULD" keyword is replaced by "MUST" or an
> additional sentence is required, e.g.,
> 
> NEW:
>     If not explicitly specified, the new cost mode applies to all
> cost metrics.
> 
> Section 4:
> 
> I also agree with Dhruv's comment that the contents of the "ALTO
> Cost Modes"
> registry should be better specified. While the initial entries set
> good examples of how to register a new cost mode, it can still be
> helpful if the format and content of each field are specified in
> more details, e.g., using similar specifications in Sections 14.2
> and 14.3 of RFC 7285 (as suggested by Dhruv).
> 
> I also suggest renaming the "Specification" field to "Intended
> Semantics", to be consistent with other ALTO registries (in RFC
> 7285 and in the unified property draft).
> 
> [1] https://mailarchive.ietf.org/arch/msg/alto/B1agkfVtdu7tsad2-
> MzErQXMk44/

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.