[Technical Errata Reported] RFC6016 (2561)

RFC Errata System <rfc-editor@rfc-editor.org> Tue, 12 October 2010 18:41 UTC

To: bsd@cisco.com, flefauch@cisco.com, ashokn@cisco.com, ietfdbh@comcast.net, lars.eggert@nokia.com, jmpolk@cisco.com, gorry@erg.abdn.ac.uk
Subject: [Technical Errata Reported] RFC6016 (2561)
From: RFC Errata System <rfc-editor@rfc-editor.org>
Message-Id: <20101012184303.EAE3CE06EE@rfc-editor.org>
Date: Tue, 12 Oct 2010 11:43:03 -0700
Cc: ah@TR-Sys.de, tsvwg@ietf.org, rfc-editor@rfc-editor.org
Precedence: list

The following errata report has been submitted for RFC6016,
"Support for the Resource Reservation Protocol (RSVP) in Layer 3 VPNs".

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

--------------------------------------
Type: Technical
Reported by: Alfred Hoenes <ah@TR-Sys.de>

Section: 8.7,pg.27/28

Original Text
-------------
|  The usage of Aggregated VPN-IPv4 FILTER_SPEC object is described in
|  Section 7.3.  The AGGREGATE-VPN-IPv4 FILTER_SPEC object appears in
|  RSVP messages that ordinarily contain a AGGREGATE-IPv4 FILTER_SPEC
   object as defined in [RFC3175] and [RFC4860], and are sent between
   ingress PE and egress PE in either direction.  These objects MUST NOT
   be included in any RSVP messages that are sent outside of the
   provider's backbone (except in the inter-AS Option-B and Option-C
|  cases, as described above, when it may appear on inter-AS links).

   The processing rules for these objects are otherwise identical to
|  those of the VPN-IPv4 FILTER_SPEC object defined in Section 8.3.  The
   format of the object is as follows:


Corrected Text
--------------
|  The usage of the Aggregated VPN-IPv4 FILTER_SPEC object is described
|  in Section 7.3.  The AGGREGATE-VPN-IPv4 (or AGGREGATE-VPN-IPv6)
   FILTER_SPEC object appears in RSVP messages that ordinarily contain
|  an AGGREGATE-IPv4 (respectively, AGGREGATE-IPv6) FILTER_SPEC object
   as defined in [RFC3175] and [RFC4860], and are sent between ingress
   PE and egress PE in either direction.  These objects MUST NOT be
   included in any RSVP messages that are sent outside of the provider's
   backbone (except in the inter-AS Option-B and Option-C cases, as
|  described above, when they may appear on inter-AS links).

   The processing rules for these objects are otherwise identical to
|  those of the VPN-IPv4 and VPN-IPv6 FILTER_SPEC objects defined in
   Section 8.3.  The format of the object is as follows:



Notes
-----
Rationale:
  a) missing article
  b) incomplete specification; the use of "These objects" as well as the
     references to two different RFCs (one for the IPv4 case, one for the
     IPv6 case) are strong indications that this text should be phrased
     in a similar manner as in preceding subsections of Section 8, i.e.
     it should include mention of the equivalent object for the IPv6 case
     as well (this qualifies the Errata Note as Technical);
  c) s/a AGGREGATE/an AGGREGATE/
  d) singular/plural mismatch:  s/it/they/ .

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. 

--------------------------------------
RFC6016 (draft-ietf-tsvwg-rsvp-l3vpn-07)
--------------------------------------
Title               : Support for the Resource Reservation Protocol (RSVP) in Layer 3 VPNs
Publication Date    : October 2010
Author(s)           : B. Davie, F. Le Faucheur, A. Narayanan
Category            : PROPOSED STANDARD
Source              : Transport Area Working Group
Area                : Transport
Stream              : IETF
Verifying Party     : IESG

[Technical Errata Reported] RFC6016 (2561) RFC Errata System