--- 1/draft-ietf-pce-path-key-04.txt	2008-11-17 18:12:03.000000000 +0100
+++ 2/draft-ietf-pce-path-key-05.txt	2008-11-17 18:12:03.000000000 +0100
@@ -1,20 +1,20 @@
 Networking Working Group                              Rich Bradford (Ed)
 Internet-Draft                                                JP Vasseur
 Intended Status: Standards Track                     Cisco Systems, Inc.
 Created: November 17, 2008                                 Adrian Farrel
 Expires: May 17, 2009                                 Old Dog Consulting
 
         Preserving Topology Confidentiality in Inter-Domain Path
                 Computation Using a Key-Based Mechanism
 
-                   draft-ietf-pce-path-key-04.txt
+                   draft-ietf-pce-path-key-05.txt
 
 Status of this Memo
 
    This Internet-Draft is submitted to IETF in full conformance with
    the provisions of BCP 78 and BCP 79.
 
    Internet-Drafts are working documents of the Internet Engineering
    Task Force (IETF), its areas, and its working groups.  Note that
    other groups may also distribute working documents as Internet-
    Drafts.
@@ -161,20 +161,22 @@
    extensions, path segment confidentiality and path diversity are
    mutually incompatible requirements.
 
    This document defines the notion of a Path Key that is a token
    that replaces a path segment in an explicit route. The Path Key is
    encoded as a Path Key Subobject (PKS) returned in the PCEP Path
    Computation Reply message (PCRep) ([PCEP]). Upon receiving the
    computed path, the PKS will be carried in an RSVP-TE Path message
    (RSVP-TE [RFC3209] and [RSVP-PKS]) during signaling.
 
+   The BNF in this document follows the format described in [RBNF].
+
 1.1.   Terminology
 
    This document makes use of the following terminology and acronyms.
 
    AS: Autonomous System.
 
    ASBR: Autonomous System Border Routers used to connect to another
    AS of a different or the same Service Provider via one or more
    links inter-connecting between ASes.
 
@@ -335,21 +337,21 @@
    an identifier that is unique within the domain that the PCE
    serves. The PCE-ID has to be mapped to a reachable IPv4 or IPv6
    address of the PCE by the first node of the CPS (usually a domain
    border router) and a PCE MAY use one of its reachable IP addresses
    as its PCE-ID. Alternatively and to provide greater security (see
    Section 5) or increased confidentiality, according to domain-local
    policy, the PCE MAY use some other identifier that is scoped only
    within the domain.
 
    To allow IPv4 and IPv6 addresses to be carried, two subobjects are
-   defined as follows.
+   defined in the following subsections.
 
    The Path Key Subobject may be present in the PCEP ERO or the PCEP
    PATH-KEY object (see Section 3.2).
 
 3.1.1. PKS with 32-bit PCE ID
 
    The Subobject Type for the PKS with 32-bit PCE ID is to be
    assigned by IANA (recommended value 64). The format of this
    subobject is as follows:
 
@@ -436,21 +438,22 @@
 
 3.2. Unlocking Path Keys
 
    When a network node needs to decode a Path Key so that it can
    continue signaling for an LSP, it must send a PCReq to the
    designated PCE. The PCReq defined in [PCEP] needs to be modified
    to support this usage which differs from the normal path
    computation request. To that end, a new flag is defined to show
    that the PCReq relates to the expansion of a PKS, and a new object
    is defined to carry the PKS in the PCReq. These result in an
-   update to the BNF for the message.
+   update to the BNF for the message. The BNF used in this document is
+   as described in [RBNF].
 
 3.2.1. Path Key Bit
 
    [PCEP] defines the Request Parameters (RP) object that is used to
    specify various characteristics of the path computation request
    (PCReq).
 
    In this document we define a new bit named the Path Key bit as
    follows. See Section 7.3 for the IANA assignment of the
    appropriate bit number.
@@ -816,24 +819,28 @@
    [RFC4216] Zhang, R., Vasseur, JP., et. al., "MPLS Inter-AS Traffic
              Engineering requirements", RFC 4216, November 2005.
 
    [RFC5298] Takeda, T., et al, "Analysis of Inter-domain Label
              Switched Path (LSP) Recovery", RFC 5298, August 2008.
 
    [PCEP-MIB] Kiran Koushik, A., and Stephan, E., "PCE communication
              protocol (PCEP) Management Information Base", draft-
              kkoushik-pce-pcep-mib, work in progress.
 
+   [RBNF]    Farrel, A., "Reduced Backus-Naur Form (RBNF) A Syntax Used
+             in Various Protocol Specifications", draft-farrel-rtg-
+             common-bnf, work in progress.
+
 10. Acknowledgements
 
-   The authors would like to thank Eiji Oki for his comments on this
-   document.
+   The authors would like to thank Eiji Oki, Ben Campbell, and Ross
+   Callon for their comments on this document.
 
 11. Authors' Addresses
 
    Rich Bradford (Editor)
    Cisco Systems, Inc.
    1414 Massachusetts Avenue
    Boxborough, MA - 01719
    USA
    EMail: rbradfor@cisco.com