Hi Med, On Wed, Mar 09, 2022 at 06:39:41AM +0000, [email protected] 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 If we are worried about consistency, wouldn't we have to update Table 4 as well? 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 <[email protected]> > > Envoyé : mercredi 9 mars 2022 00:07 > > À : Chris Smiley <[email protected]> > > Cc : [email protected]; Zaheduzzaman Sarker > > <[email protected]>; BOUCADAIR Mohamed INNOV/NET > > <[email protected]>; [email protected]; [email protected]; > > [email protected]; [email protected]; [email protected]; > > [email protected]; [email protected]; [email protected]; > > RFC Errata System <[email protected]> > > 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 <[email protected]> > > > > > > > > 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. > _______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
