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

[[e-mail]]

Hi Kai, 

I know that 7285 includes something similar, but the proposed text is redundant with the structure of the table in that section. I prefer to not include this text.

Thank you.

Cheers,
Med 

> -----Message d'origine-----
> De : [e-mail] <[e-mail]>
> Envoyé : dimanche 17 avril 2022 16:08
> À : BOUCADAIR Mohamed INNOV/NET <[e-mail]>
> Cc : [e-mail]; Qin Wu <[e-mail]>
> Objet : Re: Re: [alto] Shepherd review for draft-ietf-alto-cost-
> mode-01
> 
> Hi Med,
> 
> Thanks for the quick update but I have one additional comment on
> the registry specification:
> I suggest adding the following paragraphs after the registry
> table:
> 
> NEW:
>    Requests to add a new value to the registry MUST include the
>    following information:
> 
>    o  Identifier: The name of the ALTO cost mode.
> 
>    o  Intended Semantics: A document defining a new cost mode must
>       indicate how costs should be interpreted (Section 6.1.2 of
> [RFC7285]).
>       For example, the "numerical" cost mode indicates the costs
> are
>       interpreted as values on which numerical operations can be
> applied.
> 
> Best,
> Kai
> 
> &gt; -----Original Messages-----
> &gt; From: [e-mail]
> &gt; Sent Time: 2022-04-16 17:00:05 (Saturday) &gt; To:
> "[e-mail]" <[e-mail]>, "[e-mail]"
> <[e-mail]> &gt; Cc: "Qin Wu" <[e-mail]> &gt;
> Subject: Re: [alto] Shepherd review for draft-ietf-alto-cost-mode-
> 01 &gt; &gt; Hi Kai, &gt; &gt; The changes are raisonnable.
> &gt;
> &gt; A new version that implements the changes edits is now
> online.
> &gt;
> &gt; Thanks.
> &gt;
> &gt; Cheers,
> &gt; Med
> &gt;
> &gt; &gt; -----Message d'origine-----
> &gt; &gt; De&nbsp;: [e-mail] <[e-mail]> &gt;
> &gt; Envoyé&nbsp;: samedi 16 avril 2022 03:49 &gt; &gt; À&nbsp;:
> [e-mail] &gt; &gt; Cc&nbsp;: BOUCADAIR Mohamed INNOV/NET
> <[e-mail]>; &gt; &gt; Qin Wu
> <[e-mail]> &gt; &gt; Objet&nbsp;: Shepherd review for
> draft-ietf-alto-cost-mode-01 &gt; &gt; &gt; &gt; Dear WG and
> authors of draft-ietf-alto-cost-mode, &gt; &gt; &gt; &gt; I am
> posting this review of draft-ietf-alto-cost-mode-01 to the &gt;
> &gt; mailing list, as part of my shepherd write-up. Any comments
> and &gt; &gt; feedback are more than welcome!
> &gt; &gt;
> &gt; &gt; Best,
> &gt; &gt; Kai
> &gt; &gt;
> &gt; &gt; ===================
> &gt; &gt;
> &gt; &gt; This draft extends the base ALTO protocol (RFC 7285) by
> relaxing &gt; &gt; the constraint on valid cost mode values and
> introducing a new &gt; &gt; IANA (sub-)registry to document new
> cost mode values. The &gt; &gt; motivation is clear and the
> proposed mechanism is clean. Most &gt; &gt; comments raised in
> Call for Adoption and WGLC are addressed in the &gt; &gt; latest
> revision except Dhruv's comment [1] on giving more detailed &gt;
> &gt; specifications of the contents in IANA registry. There are
> two &gt; &gt; remaining comments and I think the draft is ready
> for publication &gt; &gt; once they are addressed.
> &gt; &gt;
> &gt; &gt; Comments:
> &gt; &gt;
> &gt; &gt; Section 3.1, last paragraph: The paragraph says &gt;
> &gt;
> &gt; &gt;    Future documents that define a new cost mode SHOULD
> indicate
> &gt; &gt; whether
> &gt; &gt;    that new cost mode applies to all or a subset of cost
> metrics.
> &gt; &gt;
> &gt; &gt; In that case, it seems to me that the default behavior
> should be &gt; &gt; specified in case the applicability of the new
> cost mode is not &gt; &gt; indicated. Either the "SHOULD" keyword
> is replaced by "MUST" or an &gt; &gt; additional sentence is
> required, e.g., &gt; &gt; &gt; &gt; NEW:
> &gt; &gt;     If not explicitly specified, the new cost mode
> applies to all
> &gt; &gt; cost metrics.
> &gt; &gt;
> &gt; &gt; Section 4:
> &gt; &gt;
> &gt; &gt; I also agree with Dhruv's comment that the contents of
> the "ALTO &gt; &gt; Cost Modes"
> &gt; &gt; registry should be better specified. While the initial
> entries set &gt; &gt; good examples of how to register a new cost
> mode, it can still be &gt; &gt; helpful if the format and content
> of each field are specified in &gt; &gt; more details, e.g., using
> similar specifications in Sections 14.2 &gt; &gt; and 14.3 of RFC
> 7285 (as suggested by Dhruv).
> &gt; &gt;
> &gt; &gt; I also suggest renaming the "Specification" field to
> "Intended &gt; &gt; Semantics", to be consistent with other ALTO
> registries (in RFC &gt; &gt; 7285 and in the unified property
> draft).
> &gt; &gt;
> &gt; &gt; [1]
> https://mailarchive.ietf.org/arch/msg/alto/B1agkfVtdu7tsad2-
> &gt; &gt; MzErQXMk44/
> &gt;

_________________________________________________________________________________________________________________________

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.