Re-, Please see inline.
Cheers, Med > -----Message d'origine----- > De : Sebastian Kiesel <ietf-a...@skiesel.de> > Envoyé : mercredi 9 mars 2022 10:47 > À : BOUCADAIR Mohamed INNOV/NET <mohamed.boucad...@orange.com> > Cc : Chris Smiley <csmi...@amsl.com>; martin.h.d...@gmail.com; > Zaheduzzaman Sarker <zaheduzzaman.sar...@ericsson.com>; > ral...@google.com; repe...@cisco.com; y...@cs.yale.edu; > sprev...@cisco.com; w.ro...@alcatel-lucent.com; shalu...@shlang.com; > richard_wou...@cable.comcast.com; alto@ietf.org; RFC Errata System <rfc- > edi...@rfc-editor.org> > Objet : Re: [Editorial Errata Reported] RFC7285 (6874) > > Hi Med, > > On Wed, Mar 09, 2022 at 06:39:41AM +0000, mohamed.boucad...@orange.com > wrote: > > Hi Sebastien, > > > > "priv:" is not an identifier per se and as such it should not be > > listed in that table. There is no change of the assignment policy in > > the errata. > > ok .. so no policy change intended. That's great, otherwise we would > have to revise much more text. > > > While it was maybe somewhat unfortunate to include the line in the table > in the first place, I am worrying that removing it at this point in time > could be interpreted as a policy change. > > Maybe we should clarify that by adding a line right below the table: > > OLD: > > > Original Text > > ------------- > > > > +-------------+---------------------+ > > | Identifier | Intended Semantics | > > +-------------+---------------------+ > > | routingcost | See Section 6.1.1.1 | > > | priv: | Private use | > > +-------------+---------------------+ > > > > Table 3: ALTO Cost Metrics > > > > Corrected Text > > -------------- > > > > +-------------+---------------------+ > > | Identifier | Intended Semantics | > > +-------------+---------------------+ > > | routingcost | See Section 6.1.1.1 | > > +-------------+---------------------+ > > > > Note: Identifiers prefixed with "priv:" > > are reserved for Private Use [RFC5226] > > without a need to register with IANA. > > > > > > Table 3: ALTO Cost Metrics > [Med] Looks good to me but with s/5226/8126 and removing "without a need to register with IANA" as that is implied by "private use". RFC8126 says the following: IANA does not record assignments from registries or ranges with this policy (and therefore there is no need for IANA to review them) and assignments are not generally useful for broad interoperability. It is the responsibility of the sites making use of the Private Use range to ensure that no conflicts occur (within the intended scope of use). > > > If we are worried about consistency, wouldn't we have to update Table 4 > as well? [Med] Indeed. This was reported in a separate erratum :-) Keeping RFC 7285 consistent within the document is probably > more important than compatibility with extensions that are specified > some 8 years later. > > Thanks, > Sebastian > > > > > > > FWIW, the proposed changed was triggered by a comment "about > consistency" we received for draft-bw-alto-cost-mode. > > > > As a Chair, I prefer that to be fixed in the original RFC rather than > blinding echoing that same structure for every (new) ALTO registry. > > > > Cheers, > > Med > > > > > -----Message d'origine----- > > > De : Sebastian Kiesel <ietf-a...@skiesel.de> Envoyé : mercredi 9 > > > mars 2022 00:07 À : Chris Smiley <csmi...@amsl.com> Cc : > > > martin.h.d...@gmail.com; Zaheduzzaman Sarker > > > <zaheduzzaman.sar...@ericsson.com>; BOUCADAIR Mohamed INNOV/NET > > > <mohamed.boucad...@orange.com>; ral...@google.com; > > > repe...@cisco.com; y...@cs.yale.edu; sprev...@cisco.com; > > > w.ro...@alcatel-lucent.com; shalu...@shlang.com; > > > richard_wou...@cable.comcast.com; alto@ietf.org; RFC Errata System > > > <rfc-edi...@rfc-editor.org> Objet : Re: [Editorial Errata Reported] > > > RFC7285 (6874) > > > > > > Hi, > > > > > > I am not sure whether this is an editorial erratum. Not even sure > > > whether this issue is an erratum at all - or maybe a > > > specification/policy change that, if desired, should be made through > > > some consensus process that leads to an RFC updating RFC 7285. > > > > > > The original idea was to establish an IANA registry "ALTO Cost > > > Metric Registry", which is initially populated with only one entry > > > "routingcost". > > > Furthermore, section 10.6. specifies that identifiers prefixed with > > > "priv:" are reserved for Private Use without a need to register with > > > IANA. > > > So technically, the report is correct, "priv:" as such is not a cost > > > metric. I think it is still valuable to have it in the table, as a > > > reminder to IANA, not to register names starting with "priv:". > > > Maybe we should have written "priv:*" along with a further > > > explanation that the star means further characters, but I doubt that > > > this would have added clarity. > > > > > > If the erratum report is just for cosmetic reasons, removing a > > > prefix from a table that should hold only complete names ... well > > > ... I'd say this is not worth the effort, maybe even harmful. If, on > > > the other hand, the intention is to deprecate the whole idea of > > > having a part of the namespace for private use without IANA > > > registration, this should IMO go through a broader consensuns > process and not through an erratum. > > > > > > Just my two cents, being one of the original authors. > > > WG Chairs / AD, please advise. > > > > > > thanks, > > > Sebastian > > > > > > > > > > > > > > > On Tue, Mar 08, 2022 at 01:39:12PM -0800, Chris Smiley wrote: > > > > > > > > Greetings, > > > > > > > > We are unable to verify this erratum that the submitter marked as > > > editorial. > > > > Please note that we have changed the “Type” of the following > > > > errata report to “Technical”. As Stream Approver, please review > > > > and set the Status and Type accordingly (see the definitions at > > > > https://www.rfc-editor.org/errata-definitions/). > > > > > > > > You may review the report at: > > > > https://www.rfc-editor.org/errata/eid6874 > > > > > > > > Please see https://www.rfc-editor.org/how-to-verify/ for further > > > > information on how to verify errata reports. > > > > > > > > Further information on errata can be found at: > > > > https://www.rfc-editor.org/errata.php. > > > > > > > > Thank you. > > > > > > > > RFC Editor/cs > > > > > > > > > > > > > On Mar 8, 2022, at 12:50 AM, RFC Errata System <rfc-editor@rfc- > > > editor.org> wrote: > > > > > > > > > > The following errata report has been submitted for RFC7285, > > > > > "Application-Layer Traffic Optimization (ALTO) Protocol". > > > > > > > > > > -------------------------------------- > > > > > You may review the report below and at: > > > > > https://www.rfc-editor.org/errata/eid6874 > > > > > > > > > > -------------------------------------- > > > > > Type: Editorial > > > > > Reported by: Mohamed BOUCADAIR <mohamed.boucad...@orange.com> > > > > > > > > > > Section: 14.2 > > > > > > > > > > Original Text > > > > > ------------- > > > > > > > > > > +-------------+---------------------+ > > > > > | Identifier | Intended Semantics | > > > > > +-------------+---------------------+ > > > > > | routingcost | See Section 6.1.1.1 | > > > > > | priv: | Private use | > > > > > +-------------+---------------------+ > > > > > > > > > > Table 3: ALTO Cost Metrics > > > > > > > > > > Corrected Text > > > > > -------------- > > > > > > > > > > +-------------+---------------------+ > > > > > | Identifier | Intended Semantics | > > > > > +-------------+---------------------+ > > > > > | routingcost | See Section 6.1.1.1 | > > > > > +-------------+---------------------+ > > > > > > > > > > Table 3: ALTO Cost Metrics > > > > > > > > > > Notes > > > > > ----- > > > > > priv: is not a cost metric but a prefix > > > > > > > > > > Instructions: > > > > > ------------- > > > > > This erratum is currently posted as "Reported". If necessary, > > > > > please use "Reply All" to discuss whether it should be verified > > > > > or rejected. When a decision is reached, the verifying party can > > > > > log in to change the status and edit the report, if necessary. > > > > > > > > > > -------------------------------------- > > > > > RFC7285 (draft-ietf-alto-protocol-27) > > > > > -------------------------------------- > > > > > Title : Application-Layer Traffic Optimization > (ALTO) > > > Protocol > > > > > Publication Date : September 2014 > > > > > Author(s) : R. Alimi, Ed., R. Penno, Ed., Y. Yang, > Ed., S. > > > Kiesel, S. Previdi, W. Roome, S. Shalunov, R. Woundy > > > > > Category : PROPOSED STANDARD > > > > > Source : Application-Layer Traffic Optimization > > > > > Area : Transport > > > > > Stream : IETF > > > > > Verifying Party : IESG > > > > > > > > > > > > > ______________________________________________________________________ > > ___________________________________________________ > > > > 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. > > _________________________________________________________________________________________________________________________ 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
