Subject: [Pce] [Editorial Errata Reported] RFC5520 (3582)

From: RFC Errata System <[email-masked]>
Date: Fri, 5 Apr 2013 01:45:26 -0700 (PDT)

The following errata report has been submitted for RFC5520,
"Preserving Topology Confidentiality in Inter-Domain Path Computation Using a Path-Key-Based Mechanism".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=5520&eid=3582

--------------------------------------
Type: Editorial
Reported by: Dhruv Dhody <[email-masked]>

Section: 3.2.3

Original Text
-------------
<request>::= <RP>
                    <segment-computation> | <path-key-expansion>

       where:
          <segment-computation> ::= <END-POINTS>
                                    [<LSPA>]
                                    [<BANDWIDTH>]
                                    [<BANDWIDTH>]
                                    [<metric-list>]
                                    [<RRO>]
                                    [<IRO>]
                                    [<LOAD-BALANCING>]
          <path-key-expansion> ::= <PATH-KEY>

Corrected Text
--------------
<request>::= <RP>
                    <segment-computation> | <path-key-expansion>

       where:
          <segment-computation> ::= <END-POINTS>
                                    [<LSPA>]
                                    [<BANDWIDTH>]
                                    [<metric-list>]
                                    [<RRO>[<BANDWIDTH>]]
                                    [<IRO>]
                                    [<LOAD-BALANCING>]
          <path-key-expansion> ::= <PATH-KEY>

Notes
-----
This document defines <path-key-expansion> to allow path request message to be used for getting the confidential path segment. The <segment-computation> should be as per RFC5440 itself. 
There is a mistake in the second BANDWIDTH object which should be placed with RRO as per RFC5440.

Instructions:
-------------
This errata 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 (IESG)
can log in to change the status and edit the report, if necessary. 

--------------------------------------
RFC5520 (draft-ietf-pce-path-key-05)
--------------------------------------
Title               : Preserving Topology Confidentiality in Inter-Domain Path Computation Using a Path-Key-Based Mechanism
Publication Date    : April 2009
Author(s)           : R. Bradford, Ed., JP. Vasseur, A. Farrel
Category            : PROPOSED STANDARD
Source              : Path Computation Element
Area                : Routing
Stream              : IETF
Verifying Party     : IESG

---

From: "Adrian Farrel" <[email-masked]>
Date: Sun, 7 Apr 2013 14:02:23 +0100

Hi PCE,

Dhurv's Errata Report at
http://www.rfc-editor.org/errata_search.php?rfc=5520&eid=3582 seems to make a
good point. The RBNF in RFC 5520 appears to offer the presence of two copies of
<BANDWIDTH> without any explanation, but also to not allow <BANDWIDTH> to be
present alongside the <RRO>.

I can see how this happened...
Revision -08 of draft-ietf-pce-pcep used exactly the formulation that found its
way into RFC5520, but by the time PCEP became RFC 5440, this issue had been
resolved in the PCEP spec. Obviously the fix did not get applied across to the
Path Key document.

I propose to accept this Errata Report, but since I am a co-author, I just want
to poll the WG to make sure no=one objects.

Thanks,
Adrian

> -----Original Message-----
> From: RFC Errata System [mailto:[email-masked]]
> Sent: 05 April 2013 09:45
> To: [email-masked]; [email-masked]; [email-masked];
> [email-masked]; [email-masked]; [email-masked];
> [email-masked]
> Cc: [email-masked]; [email-masked]; [email-masked]
> Subject: [Editorial Errata Reported] RFC5520 (3582)
> 
> This document defines <path-key-expansion> to allow path request message to
> be used for getting the confidential path segment. The <segment-computation>
> should be as per RFC5440 itself.
> Title               : Preserving Topology Confidentiality in Inter-Domain Path
> Computation Using a Path-Key-Based Mechanism

---

From: Abdussalam Baryun <[email-masked]>
Date: Sun, 7 Apr 2013 17:20:25 +0200

My small objection is just that the errata did not add the full PCReq
message paragraph in the errata (it contains another editorial issue),
as the missing part can add to read the below (similar to RFC5440);
++++++++++++++
The format of a PCReq message is as follows:

   <PCReq Message>::= <Common Header>
                      [<svec-list>]
                      <request-list>

   where:

      <svec-list>::=<SVEC>[<svec-list>]
      <request-list>::=<request>[<request-list>]
++++++++++++++

The RFC5520 had mentioned the above as differently from RFC5440 as;
+++++++++++++++++
The format of a PCReq message is as follows:

   <PCReq Message>::= <Common Header>
                      [<SVEC-list>]
                      <request-list>

   where:

      <svec-list>::=<SVEC>[<svec-list>]
      <request-list>::=<request>[<request-list>]
++++++++++++++++++
I think there may be difference between <SVEC-list> and <svec-list>
However, I don't object if the authors ignored that,

Regards
AB

*This message was a reply to the below request*
++++++++++++++++++++++++++++++++++++
On 4/7/13, Adrian Farrel <[email-masked]> wrote:
>> "Preserving Topology Confidentiality in Inter-Domain Path Computation
>> Using a
>> Path-Key-Based Mechanism".
>>
>> There is a mistake in the second BANDWIDTH object which should be placed
>> with
>> RRO as per RFC5440.
>>
>> Instructions:
>> -------------
> _______________________________________________
> Pce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pce
>

---

From: "Adrian Farrel" <[email-masked]>
Date: Sun, 7 Apr 2013 17:06:09 +0100

Hi AB,

You're right that this is another typo in the same section.

It is generally best to raise individual issues in separate reports because that
way it is easier to process them.

Would you like to raise the Errata Report for this, or shall I handle it?

Adrian

> From: Abdussalam Baryun [mailto:[email-masked]]
> Sent: 07 April 2013 16:20
> To: [email-masked]
> Cc: [email-masked]; [email-masked]
> Subject: Re: [Pce] [Editorial Errata Reported] RFC5520 (3582)
> 
> > http://www.rfc-editor.org/errata_search.php?rfc=5520&eid=3582 seems to
> make
> > a
> > <BANDWIDTH> without any explanation, but also to not allow <BANDWIDTH>
> to
> > be

---

From: "Rich Bradford (rbradfor)" <[email-masked]>
Date: Sun, 7 Apr 2013 17:19:35 +0000

I agree with the changes. 
--rich

-----Original Message-----
From: Adrian Farrel [mailto:[email-masked]] 
Sent: Sunday, April 07, 2013 9:02 AM
To: [email-masked]
Cc: [email-masked]; Rich Bradford (rbradfor); [email-masked]; Stewart Bryant (stbryant); [email-masked]; [email-masked]
Subject: RE: [Editorial Errata Reported] RFC5520 (3582)
Importance: High

Hi PCE,

Dhurv's Errata Report at
http://www.rfc-editor.org/errata_search.php?rfc=5520&eid=3582 seems to make a good point. The RBNF in RFC 5520 appears to offer the presence of two copies of <BANDWIDTH> without any explanation, but also to not allow <BANDWIDTH> to be present alongside the <RRO>.

I can see how this happened...
Revision -08 of draft-ietf-pce-pcep used exactly the formulation that found its way into RFC5520, but by the time PCEP became RFC 5440, this issue had been resolved in the PCEP spec. Obviously the fix did not get applied across to the Path Key document.

I propose to accept this Errata Report, but since I am a co-author, I just want to poll the WG to make sure no=one objects.

Thanks,
Adrian

> Using a Path-Key-Based Mechanism".
> 
> This document defines <path-key-expansion> to allow path request 
> message to be used for getting the confidential path segment. The 
> <segment-computation> should be as per RFC5440 itself.
> use "Reply All" to discuss whether it should be verified or rejected. 
> When a decision is reached, the verifying party (IESG) can log in to 
> change the status and edit the report, if necessary.
>