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 <[email protected]> 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 <[email protected]> wrote: > >> Hi Paul, >> >> Thank you for the review. >> >> Please see inline. >> >> Cheers, >> Med >> >> > -----Message d'origine----- >> > De : Paul Wouters via Datatracker <[email protected]> >> > Envoyé : jeudi 2 juin 2022 05:12 >> > À : The IESG <[email protected]> >> > Cc : [email protected]; [email protected]; >> > [email protected]; [email protected]; [email protected] >> > 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. >> >>
_______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
