RFC Errata


Errata Search

 
Source of RFC  
Summary Table Full Records

Found 15 records.

Status: Verified (2)

RFC 4875, "Extensions to Resource Reservation Protocol - Traffic Engineering (RSVP-TE) for Point-to-Multipoint TE Label Switched Paths (LSPs)", May 2007

Note: This RFC has been updated by RFC 6510

Source of RFC: mpls (rtg)

Errata ID: 2483
Status: Verified
Type: Editorial
Publication Format(s) : TEXT

Reported By: Alfred Hoenes
Date Reported: 2007-05-15
Verifier Name: Adrian Farrel
Date Verified: 2010-08-21

Section 6.1 says:

Erratum created by duplication from multipart Erratum 961 raised by Alfred Hoenes.

(3)  Section 6.1 -- bad internal reference, and missing article

Within Section 6.1, the first text lines on page 17 say:

|  The S2L sub-LSP flow descriptor has the same format as S2L sub-LSP
|  descriptor in section 4.1 with the difference that a
   P2MP_SECONDARY_RECORD_ROUTE object is used in place of a P2MP
   SECONDARY_EXPLICIT_ROUTE object.  [...]

The text should insert the missing article and correct the reference to point to Section 5.1

It should say:


|  The S2L sub-LSP flow descriptor has the same format as the S2L
|  sub-LSP descriptor in section 5.1 with the difference that a
   P2MP_SECONDARY_RECORD_ROUTE object is used in place of a P2MP
   SECONDARY_EXPLICIT_ROUTE object.  [...]

Errata ID: 2490
Status: Verified
Type: Editorial
Publication Format(s) : TEXT

Reported By: Alfred Hoenes
Date Reported: 2007-05-15
Verifier Name: Adrian Farrel
Date Verified: 2010-08-21

Section 17 says:

Erratum created by duplication from multipart Erratum 961 raised by Alfred Hoenes.

(10)  Section 17 -- bad internal reference

Within Section 17, in the second paragraph on page 35, the reader
is referred to:
                 "Figure 2 in section 24"
which should be:
                 "Figure 2 in Appendix A"


Status: Held for Document Update (10)

RFC 4875, "Extensions to Resource Reservation Protocol - Traffic Engineering (RSVP-TE) for Point-to-Multipoint TE Label Switched Paths (LSPs)", May 2007

Note: This RFC has been updated by RFC 6510

Source of RFC: mpls (rtg)

Errata ID: 2481
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT

Reported By: Alfred Hoenes
Date Reported: 2007-05-15
Held for Document Update by: Adrian Farrel
Date Held: 2010-08-21

 

Erratum created by duplication from multipart Erratum 961 raised by Alfred Hoenes.

(1)  Section 4.5 -- syntax / punctuation issue

In the first paragraph of Section 4.5, on page 7, RFC 4875 says:
                                           vv
|           [...].  The < [<EXPLICIT_ROUTE>], <S2L_SUB_LSP> > tuple
   represents the S2L sub-LSP and is referred to as the sub-LSP
   descriptor.  [...]

Obviously, the tagged comma should be *inside* the square brackets:
                                           vv
|           [...].  The < [<EXPLICIT_ROUTE>,] <S2L_SUB_LSP> > tuple
   represents the S2L sub-LSP and is referred to as the sub-LSP
   descriptor.  [...]

The same issue recurs in the third paragraph of Section 4.5, on the
same page.

At similar places in the RFC, e.g. in the first paragraph of
Section 5.2.1, the comma is omitted entirely in the tuple notation.
That is very unusual.


It should say:

[see above]

Errata ID: 2482
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT

Reported By: Alfred Hoenes
Date Reported: 2007-05-15
Held for Document Update by: Adrian Farrel
Date Held: 2010-08-21

Section 5.2.1 says:

Erratum created by duplication from multipart Erratum 961 raised by Alfred Hoenes.

(2)  Section 5.2.1 -- typo (text reformatting problem ?)

In the 5th line of the last-paragraph of Section 5.2.1,
    "Sub- Group"   should be spelled   "Sub-Group" .

Errata ID: 2484
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT

Reported By: Alfred Hoenes
Date Reported: 2007-05-15
Held for Document Update by: Adrian Farrel
Date Held: 2010-08-21

Section 6.2 says:

Erratum created by duplication from multipart Erratum 961 raised by Alfred Hoenes.

(4)  Section 6.2 -- missing article

The second paragraph of Section 6.2, on mid-page 17, says:

                                 [...].  When the integrity bit is set
|  in the LSP_REQUIRED_ATTRIBUTE object, Resv message MUST NOT be sent
   upstream until all Resv messages have been received from the
   downstream neighbors.

Missing indefinite article.

It should say:

                                 [...].  When the integrity bit is set
|  in the LSP_REQUIRED_ATTRIBUTE object, a Resv message MUST NOT be sent
   upstream until all Resv messages have been received from the
   downstream neighbors.

Errata ID: 2485
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT

Reported By: Alfred Hoenes
Date Reported: 2007-05-15
Held for Document Update by: Adrian Farrel
Date Held: 2010-08-21

Section 8.2 says:

Erratum created by duplication from multipart Erratum 961 raised by Alfred Hoenes.

(5)  Section 8.2 -- text duplication and inconsistency

The second paragraph of Section 8.2 (on page 23),

   A transit LSR sets the Sub-Group Originator ID in the FILTER_SPEC
   object(s) of a Resv message to the value that was received in the
   corresponding Path message.  If any of the incoming Resv messages
   corresponding to a single Path message carry a RESV_CONFIRM object,
   then the LSR MUST include a RESV_CONFIRM object in the corresponding
   Resv message that it sends upstream.  If the Sub-Group Originator ID
   is its own address, then it MUST set the receiver address in the
   RESV_CONFIRM object to this address, else it MUST propagate the
   object unchanged.

should be deleted entirely !

Rationale:
  The first two sentences in this paragraph are repeated almost
  literally in the subsequent (third) paragraph of the section.
  The third (last) sentence above essentially is superseeded, in
  a more precise manner, by the second and the third bullet at the
  bottom of page 23.
  But, perhaps most importantly, the first bullet there handles a
  subcase not covered by, and hence mis-specified, by that sentence!

  Apparently, the lower half of page 23 is a revised revision of
  the quoted second paragraph, which should have been deleted.

Errata ID: 2486
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT

Reported By: Alfred Hoenes
Date Reported: 2007-05-15
Held for Document Update by: Adrian Farrel
Date Held: 2010-08-21

Section 10.2 says:

Erratum created by duplication from multipart Erratum 961 raised by Alfred Hoenes.

(6)  Section 10.2 -- clarification including mismatched angle
                     brackets, word omissions, and punctuation

Within Section 10.2, the third paragraph on page 26 says:

   [...]
|  A newly received Path message that matches SESSION object and Sender
   Tunnel Address, LSP ID, Sub-Group Originator ID> with existing Path
|  state carrying the same or different Sub-Group_ID, referred to Sub-
|  Group_ID(n) is processed as follows:

It should say:

|  A newly received Path message with SESSION object and <Sender Tunnel
|  Address, LSP ID, Sub-Group Originator ID> tuple matching existing
|  Path state carrying the same or a different Sub-Group_ID, referred to
|  as Sub-Group_ID(n), is processed as follows:

Errata ID: 2487
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT

Reported By: Alfred Hoenes
Date Reported: 2007-05-15
Held for Document Update by: Adrian Farrel
Date Held: 2010-08-21

Section 11.3 says:

Erratum created by duplication from multipart Erratum 961 raised by Alfred Hoenes.

(7)  Section 11.3

Established language in IETF (and other) publications is "tear down",
not simply "tear", when it comes to the deletion of connections etc.

Therefore, while not really wrong, I would have appreciated the
following changes:

- in the 5th line of the 3rd paragraph of Section 11.3 (on page 28):
       "It does not tear any other branches ..."
  -->  "It does not tear down any other branches ..."

- in the 5th paragraph of Section 11.3, in the last text line on p.28:
       "... that are explicitely torn ..."
  -->  "... that are explicitely torn down ..."

[ I note this minor issue just for consideration in the preparation
  of future / derived work. ]

Errata ID: 2488
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT

Reported By: Alfred Hoenes
Date Reported: 2007-05-15
Held for Document Update by: Adrian Farrel
Date Held: 2010-08-21

Section 15.1.2 says:

Erratum created by duplication from multipart Erratum 961 raised by Alfred Hoenes.

(8)  Section 15.1.2 -- another typo

On page 31, in the 6th line of the first paragraph of Section 15.1.2,

  "being backed- up"  should be  "being backed up"

[ The hyphenated form, "backed-up" is only appropriate in adverbial
  context, e.g., "a backed-up LSP". ]


Errata ID: 2489
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT

Reported By: Alfred Hoenes
Date Reported: 2007-05-15
Held for Document Update by: Adrian Farrel
Date Held: 2010-08-21

Section 16 says:

Erratum created by duplication from multipart Erratum 961 raised by Alfred Hoenes.

(9)  Section 16 -- typo/grammar

Within Section 16, the third paragraph on page 34 says:

   There maybe overhead for an operator to configure ...

It should say:

   There may be overhead for an operator to configure ...
            ^

Rationale: Otherwise, the sentence lacks of a verb.

Errata ID: 2491
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT

Reported By: Alfred Hoenes
Date Reported: 2007-05-15
Held for Document Update by: Adrian Farrel
Date Held: 2010-08-21

Section 18 says:

Erratum created by duplication from multipart Erratum 961 raised by Alfred Hoenes.

(11)  Section 18 -- typo (text reformatting problem ?)

Within Section 18, at the bottom of page 35,
    "re- merge"  should be  "re-merge"


Errata ID: 2493
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT

Reported By: Alfred Hoenes
Date Reported: 2007-05-15
Held for Document Update by: Adrian Farrel
Date Held: 2010-08-21

Section 19 says:

Erratum created by duplication from multipart Erratum 961 raised by Alfred Hoenes.

(12)  Section 19

(12b) -- unusual presentation

It is unusual to present the explanations of fields in a diagram
in a sequence that does not correspond to the sequence of the
fields therein.

Therefore, I would have appreciated it to find ...

o  in Section 19.2.1 (on page 41) the explanation for "LSP ID"
   not at the bottom of the list, but at the second position,
   below the explanation for "IPv4 tunnel sender address";

and

o  in Section 19.2.2 (on page 42) the explanation for "LSP ID"
   not at the bottom of the list, but at the second position,
   below the explanation for "IPv6 tunnel sender address";

Status: Rejected (3)

RFC 4875, "Extensions to Resource Reservation Protocol - Traffic Engineering (RSVP-TE) for Point-to-Multipoint TE Label Switched Paths (LSPs)", May 2007

Note: This RFC has been updated by RFC 6510

Source of RFC: mpls (rtg)

Errata ID: 961
Status: Rejected
Type: Technical
Publication Format(s) : TEXT

Reported By: Alfred Hoenes
Date Reported: 2007-05-15
Rejected by: Adrian Farrel
Date Rejected: 2010-08-21

 

(1)  Section 4.5 -- syntax / punctuation issue

In the first paragraph of Section 4.5, on page 7, RFC 4875 says:
                                           vv
|           [...].  The < [<EXPLICIT_ROUTE>], <S2L_SUB_LSP> > tuple
   represents the S2L sub-LSP and is referred to as the sub-LSP
   descriptor.  [...]

Obviously, the tagged comma should be *inside* the square brackets:
                                           vv
|           [...].  The < [<EXPLICIT_ROUTE>,] <S2L_SUB_LSP> > tuple
   represents the S2L sub-LSP and is referred to as the sub-LSP
   descriptor.  [...]

The same issue recurs in the third paragraph of Section 4.5, on the
same page.

At similar places in the RFC, e.g. in the first paragraph of
Section 5.2.1, the comma is omitted entirely in the tuple notation.
That is very unusual.


(2)  Section 5.2.1 -- typo (text reformatting problem ?)

In the 5th line of the last-paragraph of Section 5.2.1,
    "Sub- Group"   should be spelled   "Sub-Group" .


(3)  Section 6.1 -- bad internal reference, and missing article

Within Section 6.1, the first text lines on page 17 say:

|  The S2L sub-LSP flow descriptor has the same format as S2L sub-LSP
|  descriptor in section 4.1 with the difference that a
   P2MP_SECONDARY_RECORD_ROUTE object is used in place of a P2MP
   SECONDARY_EXPLICIT_ROUTE object.  [...]

The RFC should say, inserting the missing article and correcting
the reference to point to Section 5.1 :

|  The S2L sub-LSP flow descriptor has the same format as the S2L
|  sub-LSP descriptor in section 5.1 with the difference that a
   P2MP_SECONDARY_RECORD_ROUTE object is used in place of a P2MP
   SECONDARY_EXPLICIT_ROUTE object.  [...]


(4)  Section 6.2 -- missing article

The second paragraph of Section 6.2, on mid-page 17, says:

                                 [...].  When the integrity bit is set
|  in the LSP_REQUIRED_ATTRIBUTE object, Resv message MUST NOT be sent
   upstream until all Resv messages have been received from the
   downstream neighbors.

It should say:

                                 [...].  When the integrity bit is set
|  in the LSP_REQUIRED_ATTRIBUTE object, a Resv message MUST NOT be sent
   upstream until all Resv messages have been received from the
   downstream neighbors.


(5)  Section 8.2 -- text duplication and inconsistency

The second paragraph of Section 8.2 (on page 23),

   A transit LSR sets the Sub-Group Originator ID in the FILTER_SPEC
   object(s) of a Resv message to the value that was received in the
   corresponding Path message.  If any of the incoming Resv messages
   corresponding to a single Path message carry a RESV_CONFIRM object,
   then the LSR MUST include a RESV_CONFIRM object in the corresponding
   Resv message that it sends upstream.  If the Sub-Group Originator ID
   is its own address, then it MUST set the receiver address in the
   RESV_CONFIRM object to this address, else it MUST propagate the
   object unchanged.

should be deleted entirely !

Rationale:
  The first two sentences in this paragraph are repeated almost
  literally in the subsequent (third) paragraph of the section.
  The third (last) sentence above essentially is superseeded, in
  a more precise manner, by the second and the third bullet at the
  bottom of page 23.
  But, perhaps most importantly, the first bullet there handles a
  subcase not covered by, and hence mis-specified, by that sentence!

  Apparently, the lower half of page 23 is a revised revision of
  the quoted second paragraph, which should have been deleted.


(6)  Section 10.2 -- clarification including mismatched angle
                     brackets, word omissions, and punctuation

Within Section 10.2, the third paragraph on page 26 says:

   [...]
|  A newly received Path message that matches SESSION object and Sender
   Tunnel Address, LSP ID, Sub-Group Originator ID> with existing Path
|  state carrying the same or different Sub-Group_ID, referred to Sub-
|  Group_ID(n) is processed as follows:

It should say:

   [...]
|  A newly received Path message that matches in SESSION object and
|  <Sender Tunnel Address, LSP ID, Sub-Group Originator ID> with
|  existing Path state carrying the same or a different Sub-Group_ID,
|  referred to as Sub-Group_ID(n), is processed as follows:

Or even better, a bit reworded for enhanced readability:

   [...]
|  A newly received Path message with SESSION object and <Sender Tunnel
|  Address, LSP ID, Sub-Group Originator ID> tuple matching existing
|  Path state carrying the same or a different Sub-Group_ID, referred to
|  as Sub-Group_ID(n), is processed as follows:


(7)  Section 11.3

Established language in IETF (and other) publications is "tear down",
not simply "tear", when it comes to the deletion of connections etc.

Therefore, while not really wrong, I would have appreciated the
following changes:

- in the 5th line of the 3rd paragraph of Section 11.3 (on page 28):
       "It does not tear any other branches ..."
  -->  "It does not tear down any other branches ..."

- in the 5th paragraph of Section 11.3, in the last text line on p.28:
       "... that are explicitely torn ..."
  -->  "... that are explicitely torn down ..."

[ I note this minor issue just for consideration in the preparation
  of future / derived work. ]


(8)  Section 15.1.2 -- another typo

On page 31, in the 6th line of the first paragraph of Section 15.1.2,

  "being backed- up"  should be  "being backed up"

[ The hyphenated form, "backed-up" is only appropriate in adverbial
  context, e.g., "a backed-up LSP". ]


(9)  Section 16 -- typo/grammar

Within Section 16, the third paragraph on page 34 says:

   There maybe overhead for an operator to configure ...

It should say:

   There may be overhead for an operator to configure ...
            ^

Rationale: Otherwise, the sentence lacks of a verb.


(10)  Section 17 -- bad internal reference

Within Section 17, in the second paragraph on page 35, the reader
is referred to:
                 "Figure 2 in section 24"
which should be:
                 "Figure 2 in Appendix A"


(11)  Section 18 -- typo (text reformatting problem ?)

Within Section 18, at the bottom of page 35,
    "re- merge"  should be  "re-merge"


(12)  Section 19

(12a) -- lack of precision / completeness

The sub-sections of Section 19 mostly remain a bit unspecific with
respect to Class *numbers* (only Section 19.3 does supply these),
whereas C-Type values always are specified fully.

For uniformity and completeness, and for the ease of the reader,
the following changes/amendments (determined after IANA lookup)
should be applied -- adopting the style of the RFC text from
Section 19.3 --, to the lines immediately above the class data
structure diagrams (I use abbreviated, diff-like notation):

o  in Section 19.1.1 (on mid-page 39):

   Class = SESSION, P2MP_LSP_TUNNEL_IPv4 C-Type = 13
--
   SESSION Class = 1, P2MP_LSP_TUNNEL_IPv4 C-Type = 13

o  in Section 19.1.2 (on page 40):

   Class = SESSION, P2MP_LSP_TUNNEL_IPv6 C-Type = 14
--
   SESSION Class = 1, P2MP_LSP_TUNNEL_IPv6 C-Type = 14

o  in Section 19.2.1 (on top of page 41):

   Class = SENDER_TEMPLATE, P2MP_LSP_TUNNEL_IPv4 C-Type = 12
--
   SENDER_TEMPLATE Class = 11, P2MP_LSP_TUNNEL_IPv4 C-Type = 12

o  in Section 19.2.2 (on top of page 42):

   Class = SENDER_TEMPLATE, P2MP_LSP_TUNNEL_IPv6 C-Type = 13
--
   SENDER_TEMPLATE Class = 11, P2MP_LSP_TUNNEL_IPv6 C-Type = 13

o  in Section 19.4.1 (at the bottom of page 43):

   Class = FILTER_SPEC, P2MP LSP_IPv4 C-Type = 12
--
   FILTER_SPEC Class = 10, P2MP LSP_IPv4 C-Type = 12

o  in Section 19.4.2 (at the top of page 44):

   Class = FILTER_SPEC, P2MP LSP_IPv6 C-Type = 13
--
   FILTER_SPEC Class = 10, P2MP LSP_IPv6 C-Type = 13

o  in Section 19.5 (on page 44):

                       The class of the P2MP SERO is the same as the
   SERO defined in [RFC4873].
--
                       The class of the P2MP SERO is 200, as assigned
   for the SERO in [RFC4873].

o  in Section 19.6 (on page 44):

                The class of the P2MP SRRO is the same as the SRRO
   defined in [RFC4873].
--
                The class of the P2MP SRRO is 201, as assigned for
   the SRRO in [RFC4873].


(12b) -- unusual presentation

It is unusual to present the explanations of fields in a diagram
in a sequence that does not correspond to the sequence of the
fields therein.

Therefore, I would have appreciated it to find ...

o  in Section 19.2.1 (on page 41) the explanation for "LSP ID"
   not at the bottom of the list, but at the second position,
   below the explanation for "IPv4 tunnel sender address";

and

o  in Section 19.2.2 (on page 42) the explanation for "LSP ID"
   not at the bottom of the list, but at the second position,
   below the explanation for "IPv6 tunnel sender address";


(13)  Section 20.2 -- similar to (12a)

Contrary to Section 20.1, Section 20.2 is silent about the class
numbers.  As in item (12a) above, for consistency and completeness,
the following changes should be applied, in accordance with the
style of the IANA registry file and Section 20.1 :

   Class Name = SESSION
--
     1  Class Name = SESSION


   Class Name = SENDER_TEMPLATE
--
    11  Class Name = SENDER_TEMPLATE


   Class Name = FILTER_SPEC
--
    10  Class Name = FILTER_SPEC


   Class Name = SECONDARY_EXPLICIT_ROUTE (Defined in [RFC4873])
--
   200  Class Name = SECONDARY_EXPLICIT_ROUTE


   Class Name = SECONDARY_RECORD_ROUTE (Defined in [RFC4873])
--
   201  Class Name = SECONDARY_RECORD_ROUTE


[ Note:
  I have deleted the repeated refs to RFC 4873 for uniformity;
  this information is already present in Section 19, it might
  only have been interesting here for the IANA in the I-D phase. ]

It should say:

[see above]

Notes:

I strongly recommend to at least address items (3), (5), (6),
and (10) by an RFC Errata Note; I leave it to your decision which
other items to include additionally; IMHO, items (1), (12a), and
(13) should get high priority among these.

from pending
--VERIFIER NOTES--
Multipart Erratum split into Errata 2481-2494

Errata ID: 2492
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT

Reported By: Alfred Hoenes
Date Reported: 2007-05-15
Rejected by: Adrian Farrel
Date Rejected: 2010-08-21

Section 19 says:

Erratum created by duplication from multipart Erratum 961 raised by Alfred Hoenes.

(12)  Section 19

(12a) -- lack of precision / completeness

The sub-sections of Section 19 mostly remain a bit unspecific with
respect to Class *numbers* (only Section 19.3 does supply these),
whereas C-Type values always are specified fully.

For uniformity and completeness, and for the ease of the reader,
the following changes/amendments (determined after IANA lookup)
should be applied -- adopting the style of the RFC text from
Section 19.3 --, to the lines immediately above the class data
structure diagrams (I use abbreviated, diff-like notation):

o  in Section 19.1.1 (on mid-page 39):

   Class = SESSION, P2MP_LSP_TUNNEL_IPv4 C-Type = 13
--
   SESSION Class = 1, P2MP_LSP_TUNNEL_IPv4 C-Type = 13

o  in Section 19.1.2 (on page 40):

   Class = SESSION, P2MP_LSP_TUNNEL_IPv6 C-Type = 14
--
   SESSION Class = 1, P2MP_LSP_TUNNEL_IPv6 C-Type = 14

o  in Section 19.2.1 (on top of page 41):

   Class = SENDER_TEMPLATE, P2MP_LSP_TUNNEL_IPv4 C-Type = 12
--
   SENDER_TEMPLATE Class = 11, P2MP_LSP_TUNNEL_IPv4 C-Type = 12

o  in Section 19.2.2 (on top of page 42):

   Class = SENDER_TEMPLATE, P2MP_LSP_TUNNEL_IPv6 C-Type = 13
--
   SENDER_TEMPLATE Class = 11, P2MP_LSP_TUNNEL_IPv6 C-Type = 13

o  in Section 19.4.1 (at the bottom of page 43):

   Class = FILTER_SPEC, P2MP LSP_IPv4 C-Type = 12
--
   FILTER_SPEC Class = 10, P2MP LSP_IPv4 C-Type = 12

o  in Section 19.4.2 (at the top of page 44):

   Class = FILTER_SPEC, P2MP LSP_IPv6 C-Type = 13
--
   FILTER_SPEC Class = 10, P2MP LSP_IPv6 C-Type = 13

o  in Section 19.5 (on page 44):

                       The class of the P2MP SERO is the same as the
   SERO defined in [RFC4873].
--
                       The class of the P2MP SERO is 200, as assigned
   for the SERO in [RFC4873].

o  in Section 19.6 (on page 44):

                The class of the P2MP SRRO is the same as the SRRO
   defined in [RFC4873].
--
                The class of the P2MP SRRO is 201, as assigned for
   the SRRO in [RFC4873].



Notes:


--VERIFIER NOTES--
The risk of errors is reduced by only defining numbers once in a document. In any case, sufficient information exists in the document to make implementation simple.

Errata ID: 2494
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT

Reported By: Alfred Hoenes
Date Reported: 2007-05-15
Rejected by: Adrian Farrel
Date Rejected: 2010-08-21

Section 20.2 says:

Erratum created by duplication from multipart Erratum 961 raised by Alfred Hoenes.

(13)  Section 20.2 -- similar to (12a)

Contrary to Section 20.1, Section 20.2 is silent about the class
numbers.  As in item (12a) above, for consistency and completeness,
the following changes should be applied, in accordance with the
style of the IANA registry file and Section 20.1 :

   Class Name = SESSION
--
     1  Class Name = SESSION


   Class Name = SENDER_TEMPLATE
--
    11  Class Name = SENDER_TEMPLATE


   Class Name = FILTER_SPEC
--
    10  Class Name = FILTER_SPEC


   Class Name = SECONDARY_EXPLICIT_ROUTE (Defined in [RFC4873])
--
   200  Class Name = SECONDARY_EXPLICIT_ROUTE


   Class Name = SECONDARY_RECORD_ROUTE (Defined in [RFC4873])
--
   201  Class Name = SECONDARY_RECORD_ROUTE


Notes:


--VERIFIER NOTES--
No need to make this change as all the important information is already present in the document in the IANA section.

Report New Errata



Advanced Search