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

"Adrian Farrel" <adrian@olddog.co.uk> Sun, 07 April 2013 13:02 UTC

Return-Path: <adrian@olddog.co.uk>
X-Original-To: pce@ietfa.amsl.com
Delivered-To: pce@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6507E21F8CDD for <pce@ietfa.amsl.com>; Sun, 7 Apr 2013 06:02:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.272
X-Spam-Level:
X-Spam-Status: No, score=-2.272 tagged_above=-999 required=5 tests=[AWL=-0.273, BAYES_00=-2.599, J_CHICKENPOX_23=0.6]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oB1dziqcPFFT for <pce@ietfa.amsl.com>; Sun, 7 Apr 2013 06:02:31 -0700 (PDT)
Received: from asmtp2.iomartmail.com (asmtp2.iomartmail.com [62.128.201.249]) by ietfa.amsl.com (Postfix) with ESMTP id 75B0921F8CD8 for <pce@ietf.org>; Sun, 7 Apr 2013 06:02:31 -0700 (PDT)
Received: from asmtp2.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id r37D2PP4020454; Sun, 7 Apr 2013 14:02:25 +0100
Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id r37D2OlD020444 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 7 Apr 2013 14:02:24 +0100
From: Adrian Farrel <adrian@olddog.co.uk>
To: pce@ietf.org
References: <20130405084526.2C9EAB1E002@rfc-editor.org>
In-Reply-To: <20130405084526.2C9EAB1E002@rfc-editor.org>
Date: Sun, 07 Apr 2013 14:02:23 +0100
Message-ID: <04ca01ce3390$262577e0$727067a0$@olddog.co.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQLM8DE2/vPmu6kqzyDU2wR6fcXWhJbNPeQQ
Content-Language: en-gb
Cc: jpv@cisco.com
Subject: Re: [Pce] [Editorial Errata Reported] RFC5520 (3582)
X-BeenThere: pce@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: adrian@olddog.co.uk
List-Id: Path Computation Element <pce.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pce>, <mailto:pce-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/pce>
List-Post: <mailto:pce@ietf.org>
List-Help: <mailto:pce-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pce>, <mailto:pce-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 07 Apr 2013 13:02:32 -0000

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:rfc-editor@rfc-editor.org]
> Sent: 05 April 2013 09:45
> To: rbradfor@cisco.com; jpv@cisco.com; adrian@olddog.co.uk;
> stbryant@cisco.com; adrian@olddog.co.uk; jpv@cisco.com;
> julien.meuric@orange.com
> Cc: dhruv.ietf@gmail.com; pce@ietf.org; rfc-editor@rfc-editor.org
> Subject: [Editorial Errata Reported] RFC5520 (3582)
> 
> 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 <dhruv.ietf@gmail.com>
> 
> 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