Re: [alto] Paul Wouters' Discuss on draft-ietf-alto-cost-mode-03: (with DISCUSS and COMMENT)

[Martin Duke <[e-mail]>]

I discussed this with Paul. Can we add a sentence about what to do if the
received string is more than 32 characters?

On Wed, Jun 1, 2022 at 9:24 PM <[e-mail]> wrote:

> Hi Paul,
>
> Thank you for the review.
>
> Please see inline.
>
> Cheers,
> Med
>
> > -----Message d'origine-----
> > De : Paul Wouters via Datatracker <[e-mail]>
> > Envoyé : jeudi 2 juin 2022 05:12
> > À : The IESG <[e-mail]>
> > Cc : [e-mail]; [e-mail];
> > [e-mail]; [e-mail]; [e-mail]
> > Objet : Paul Wouters' Discuss on draft-ietf-alto-cost-mode-03:
> > (with DISCUSS and COMMENT)
> >
> > Paul Wouters has entered the following ballot position for
> > draft-ietf-alto-cost-mode-03: Discuss
> >
> > When responding, please keep the subject line intact and reply to
> > all email addresses included in the To and CC lines. (Feel free to
> > cut this introductory paragraph, however.)
> >
> >
> > Please refer to
> > https://www.ietf.org/about/groups/iesg/statements/handling-ballot-
> > positions/
> > for more information about how to handle DISCUSS and COMMENT
> > positions.
> >
> >
> > The document, along with other ballot positions, can be found
> > here:
> > https://datatracker.ietf.org/doc/draft-ietf-alto-cost-mode/
> >
> >
> >
> > ------------------------------------------------------------------
> > ----
> > DISCUSS:
> > ------------------------------------------------------------------
> > ----
> >
> > Probably an easily answered issue, but I am not too familiar with
> > ALTO.
> >
> >      The string MUST be no more than 32 characters, and it MUST
> > NOT contain
> >      characters other than [...]
> >
> > Are there implementations that already deployed a cost string with
> > more than 32
> > characters or characters not in this newly imposed set of
> > characters?
>
> [Med] No.
>
>  What
> > should happen if that is in use? That is, is this protocol
> > modification
> > potentially breaking interoperability with older implementations?
> >
> >
> > ------------------------------------------------------------------
> > ----
> > COMMENT:
> > ------------------------------------------------------------------
> > ----
> >
> > While no fan of "patch RFCs", thank you for at least putting the
> > OLD and NEW
> > text in one document, so an implementer and reviewer doesn't have
> > to switch
> > between documents and get confused about what was read was the old
> > doc or new
> > doc.
> >
> > That said, patching in the text "This document" feels a little
> > weird. What RFC
> > does "This document" then refer to? Perhaps change "This document
> > defines two
> > cost modes" to "Two cost modes are defined".
>
> [Med] OK.
>
> >
> >      Future documents that define a new cost mode SHOULD indicate
> >
> > I think that SHOULD can be a MUST.
>
> [Med] We don't use MUST here because we do have a default behavior
> specified in the sentence right after: "If not explicitly indicated, the
> new cost mode applies to all cost metrics."
>
>
> _________________________________________________________________________________________________________________________
>
> 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.
>
>