Subject: Re: [alto] [Editorial Errata Reported] RFC7285 (6874)

From: Chris Smiley <[email-masked]>
Date: Tue, 8 Mar 2022 13:39:12 -0800

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 <[email-masked]> 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-masked]>
> 
> 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
>

---

From: RFC Errata System <[email-masked]>
Date: Tue, 8 Mar 2022 00:50:29 -0800 (PST)

Section: 14.2

Original Text
-------------

Corrected Text
--------------

Notes
-----

Instructions:
-------------

---

From: Sebastian Kiesel <[email-masked]>
Date: Wed, 9 Mar 2022 00:07:23 +0100

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

---

From: <[email-masked]>
Date: Wed, 9 Mar 2022 06:39:41 +0000

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. 

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-masked]>
> Envoyé : mercredi 9 mars 2022 00:07
> À : Chris Smiley <[email-masked]>
> Cc : [email-masked]; Zaheduzzaman Sarker
> <[email-masked]>; BOUCADAIR Mohamed INNOV/NET
> <[email-masked]>; [email-masked]; [email-masked];
> [email-masked]; [email-masked]; [email-masked];
> [email-masked]; [email-masked]; [email-masked];
> RFC Errata System <[email-masked]>
> 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.
> 
> that the star means further characters, but I doubt that this would have
> added clarity.
> 
> > > rejected. When a decision is reached, the verifying party can log in
> > > to change the status and edit the report, if necessary.
> > >
> > > Author(s)           : R. Alimi, Ed., R. Penno, Ed., Y. Yang, Ed., S.
> Kiesel, S. Previdi, W. Roome, S. Shalunov, R. Woundy

_________________________________________________________________________________________________________________________

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.

---

From: Sebastian Kiesel <[email-masked]>
Date: Wed, 9 Mar 2022 10:47:14 +0100

Hi Med,

On Wed, Mar 09, 2022 at 06:39:41AM +0000, [email-masked] 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:

>                   Note: Identifiers prefixed with "priv:" 
>                   are reserved for Private Use [RFC5226]
>                   without a need to register with IANA.
>
>

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

---

From: <[email-masked]>
Date: Wed, 9 Mar 2022 10:02:10 +0000

Re-,

Please see inline. 

Cheers,
Med

> Envoyé : mercredi 9 mars 2022 10:47
> À : BOUCADAIR Mohamed INNOV/NET <[email-masked]>
> Cc : Chris Smiley <[email-masked]>; [email-masked];
> Zaheduzzaman Sarker <[email-masked]>;
> [email-masked]; [email-masked]; [email-masked];
> [email-masked]; [email-masked]; [email-masked];
> [email-masked]; [email-masked]; RFC Errata System <rfc-
> [email-masked]>

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

> as well?

[Med] Indeed. This was reported in a separate erratum :-) 

  Keeping RFC 7285 consistent within the document is probably
> > 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
> >
> > > De : Sebastian Kiesel <[email-masked]> Envoyé : mercredi 9
> > > mars 2022 00:07 À : Chris Smiley <[email-masked]> Cc :
> > > [email-masked]; Zaheduzzaman Sarker
> > > <[email-masked]>; [email-masked];
> > > [email-masked]; [email-masked]; [email-masked];
> > > [email-masked]; [email-masked];
> > > [email-masked]; [email-masked]; RFC Errata System
> > > <[email-masked]> Objet : Re: [Editorial Errata Reported]
> > > RFC7285 (6874)
> > >
> > > Hi,
> > >
> > > The original idea was to establish an IANA registry "ALTO Cost
> > > Metric Registry", which is initially populated with only one entry
> > > "routingcost".
> > > 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.
> > >
> > > > 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
> > > > > 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.
> > > > >
> > > > > Title               : Application-Layer Traffic Optimization
> (ALTO)
> > > Protocol
> > ______________________________________________________________________
> > ___________________________________________________
> >
> > 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.

---

From: Sebastian Kiesel <[email-masked]>
Date: Wed, 9 Mar 2022 11:28:25 +0100

Hi Med,

On Wed, Mar 09, 2022 at 10:02:10AM +0000, [email-masked] wrote:
> [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". 
> 

what about:

>                   Note: Identifiers prefixed with "priv:" are
>                   reserved for Private Use (see Section 10.6)
>
>

This would avoid consistency issues wrt. citing 5226 vs. 8126.

Thanks
Sebastian

---

From: <[email-masked]>
Date: Wed, 9 Mar 2022 11:50:42 +0000

Re-,

Works for me, thanks. 

Cheers,
Med

PS: The note is redundant with this text in 14.2, but that's OK as the note is intended to be echoed in the IANA registry:

   As specified in Section 10.6, identifiers prefixed with "priv:" are
   reserved for Private Use.

> Envoyé : mercredi 9 mars 2022 11:28