Re: [alto] Paul Wouters' Discuss on draft-ietf-alto-cost-mode-03: (with DISCUSS and COMMENT)
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 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 wrote: > >> Hi Paul, >> >> Thank you for the review. >> >> Please see inline. >> >> Cheers, >> Med >> >> > -Message d'origine- >> > De : Paul Wouters via Datatracker >> > Envoyé : jeudi 2 juin 2022 05:12 >> > À : The IESG >> > Cc : draft-ietf-alto-cost-m...@ietf.org; alto-cha...@ietf.org; >> > alto@ietf.org; kai...@scu.edu.cn; kai...@scu.edu.cn >> > 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 alto@ietf.org https://www.ietf.org/mailman/listinfo/alto
[alto] Murray Kucherawy's No Objection on draft-ietf-alto-cost-mode-05: (with COMMENT)
Murray Kucherawy has entered the following ballot position for draft-ietf-alto-cost-mode-05: No Objection 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/ -- COMMENT: -- Thanks for addressing my DISCUSS position. A minor suggestion: In Section 5, include the table of initial values after you've defined the required fields. ___ alto mailing list alto@ietf.org https://www.ietf.org/mailman/listinfo/alto
Re: [alto] Murray Kucherawy's Discuss on draft-ietf-alto-cost-mode-04: (with DISCUSS and COMMENT)
On Thu, Jun 2, 2022 at 12:16 AM wrote: > Deal! > > > > As you can see at > https://www.ietf.org/rfcdiff?url2=draft-ietf-alto-cost-mode-05, went with > a more verbose text to insist on this + add a MUST for implementations. > Ship it! -MSK ___ alto mailing list alto@ietf.org https://www.ietf.org/mailman/listinfo/alto
Re: [alto] Murray Kucherawy's Discuss on draft-ietf-alto-cost-mode-04: (with DISCUSS and COMMENT)
Re-, Deal! As you can see at https://www.ietf.org/rfcdiff?url2=draft-ietf-alto-cost-mode-05, went with a more verbose text to insist on this + add a MUST for implementations. Thanks. Cheers, Med De : Murray S. Kucherawy Envoyé : jeudi 2 juin 2022 08:58 À : BOUCADAIR Mohamed INNOV/NET Cc : The IESG ; draft-ietf-alto-cost-m...@ietf.org; alto-cha...@ietf.org; alto@ietf.org; kai...@scu.edu.cn Objet : Re: Murray Kucherawy's Discuss on draft-ietf-alto-cost-mode-04: (with DISCUSS and COMMENT) On Wed, Jun 1, 2022 at 11:54 PM mailto:mohamed.boucad...@orange.com>> wrote: [Med] That wording was on purpose. We could easily turn that text into the following: NEW: If the definition of a cost mode does not indicate whether it applies to a subset of cost metrics, ALTO implementations MUST be prepared to accept that cost mode for any cost metric. ... but there is a high risk that this behavior will overlooked and thus the default mode will be the rule. This would have interoperability implications as it is likely that some modes can't be associated with all cost metrics. The SHOULD is some sort of authors guideline to assess the applicability and record it. Hi Mohamed, Understood. I suggest using "should" rather than "SHOULD", and then saying something like what you just said here to underscore why it's important for future documents to go into this. -MSK _ 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 alto@ietf.org https://www.ietf.org/mailman/listinfo/alto
[alto] I-D Action: draft-ietf-alto-cost-mode-05.txt
A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Application-Layer Traffic Optimization WG of the IETF. Title : A Cost Mode Registry for the Application-Layer Traffic Optimization (ALTO) Protocol Authors : Mohamed Boucadair Qin Wu Filename: draft-ietf-alto-cost-mode-05.txt Pages : 8 Date: 2022-06-02 Abstract: This document creates a new IANA registry for tracking cost modes supported by the Application-Layer Traffic Optimization (ALTO) Protocol. Also, this document relaxes a constraint that was imposed by the ALTO specification on allowed cost mode values. This document updates RFC 7285. Editorial Note (To be removed by RFC Editor) Please update RFC statements within the document with the RFC number to be assigned to this document. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-alto-cost-mode/ There is also an htmlized version available at: https://datatracker.ietf.org/doc/html/draft-ietf-alto-cost-mode-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-alto-cost-mode-05 Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts ___ alto mailing list alto@ietf.org https://www.ietf.org/mailman/listinfo/alto
Re: [alto] Murray Kucherawy's Discuss on draft-ietf-alto-cost-mode-04: (with DISCUSS and COMMENT)
On Wed, Jun 1, 2022 at 11:54 PM wrote: > [Med] That wording was on purpose. We could easily turn that text into the > following: > > NEW: > If the definition of a cost mode does not indicate whether it > applies to a subset of cost metrics, ALTO implementations > MUST be prepared to accept that cost mode for any cost metric. > > ... but there is a high risk that this behavior will overlooked and thus > the default mode will be the rule. This would have interoperability > implications as it is likely that some modes can't be associated with all > cost metrics. > > The SHOULD is some sort of authors guideline to assess the applicability > and record it. > Hi Mohamed, Understood. I suggest using "should" rather than "SHOULD", and then saying something like what you just said here to underscore why it's important for future documents to go into this. -MSK ___ alto mailing list alto@ietf.org https://www.ietf.org/mailman/listinfo/alto
Re: [alto] Murray Kucherawy's Discuss on draft-ietf-alto-cost-mode-04: (with DISCUSS and COMMENT)
Hi Murray, Thanks for the review. Please see inline. Cheers, Med > -Message d'origine- > De : Murray Kucherawy via Datatracker > Envoyé : jeudi 2 juin 2022 08:16 > À : The IESG > Cc : draft-ietf-alto-cost-m...@ietf.org; alto-cha...@ietf.org; > alto@ietf.org; kai...@scu.edu.cn > Objet : Murray Kucherawy's Discuss on draft-ietf-alto-cost-mode- > 04: (with DISCUSS and COMMENT) > > Murray Kucherawy has entered the following ballot position for > draft-ietf-alto-cost-mode-04: 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: > -- > > > Paul said: > > > I think that SHOULD can be a MUST. Although one could question > the 2119 usage > as it seems to be a directive to a document author and not a > protocol action. > So I would also be okay with lowercasing this. > > I'm ambivalent about the first sentence, but I concur strongly > with the second; > use of BCP 14 language to establish a requirement against some > future document > seems quite unconventional to me. Can we talk about why this is > necessary > and/or appropriate? [Med] That wording was on purpose. We could easily turn that text into the following: NEW: If the definition of a cost mode does not indicate whether it applies to a subset of cost metrics, ALTO implementations MUST be prepared to accept that cost mode for any cost metric. ... but there is a high risk that this behavior will overlooked and thus the default mode will be the rule. This would have interoperability implications as it is likely that some modes can't be associated with all cost metrics. The SHOULD is some sort of authors guideline to assess the applicability and record it. _ 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 alto@ietf.org https://www.ietf.org/mailman/listinfo/alto
[alto] Murray Kucherawy's Discuss on draft-ietf-alto-cost-mode-04: (with DISCUSS and COMMENT)
Murray Kucherawy has entered the following ballot position for draft-ietf-alto-cost-mode-04: 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: -- Paul said: > I think that SHOULD can be a MUST. Although one could question the 2119 usage as it seems to be a directive to a document author and not a protocol action. So I would also be okay with lowercasing this. I'm ambivalent about the first sentence, but I concur strongly with the second; use of BCP 14 language to establish a requirement against some future document seems quite unconventional to me. Can we talk about why this is necessary and/or appropriate? -- COMMENT: -- A minor suggestion: In Section 5, include the table of initial values after you've defined the required fields. ___ alto mailing list alto@ietf.org https://www.ietf.org/mailman/listinfo/alto
Re: [alto] I-D Action: draft-ietf-alto-cost-mode-04.txt
Hi Martin, all, This version addresses the various IESG reviews. Cheers, Med > -Message d'origine- > De : alto De la part de internet- > dra...@ietf.org > Envoyé : jeudi 2 juin 2022 07:30 > À : i-d-annou...@ietf.org > Cc : alto@ietf.org > Objet : [alto] I-D Action: draft-ietf-alto-cost-mode-04.txt > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Application-Layer Traffic > Optimization WG of the IETF. > > Title : A Cost Mode Registry for the > Application-Layer Traffic Optimization (ALTO) Protocol > Authors : Mohamed Boucadair > Qin Wu > Filename: draft-ietf-alto-cost-mode-04.txt > Pages : 7 > Date: 2022-06-01 > > Abstract: >This document creates a new IANA registry for tracking cost > modes >supported by the Application-Layer Traffic Optimization (ALTO) >Protocol. Also, this document relaxes a constraint that was > imposed >by the ALTO specification on allowed cost mode values. > >This document updates RFC 7285. > > Editorial Note (To be removed by RFC Editor) > >Please update RFC statements within the document with the > RFC >number to be assigned to this document. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-alto-cost-mode/ > > There is also an htmlized version available at: > https://datatracker.ietf.org/doc/html/draft-ietf-alto-cost-mode-04 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-alto-cost-mode-04 > > > Internet-Drafts are also available by rsync at > rsync.ietf.org::internet-drafts > > > ___ > alto mailing list > alto@ietf.org > https://www.ietf.org/mailman/listinfo/alto _ 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 alto@ietf.org https://www.ietf.org/mailman/listinfo/alto
