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

[Martin Duke <[e-mail]>]

I see now that 8.5 of RFC 7285 covers this, so please disregard

On Thu, Jun 2, 2022 at 12:07 PM Martin Duke <[e-mail]> wrote:

> 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.
>>
>>