Found 1 record.
Status: Rejected (1)
RFC 4553, "Structure-Agnostic Time Division Multiplexing (TDM) over Packet (SAToP)", June 2006Source of RFC: pwe3 (int)
Errata ID: 1048
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2007-03-07
Rejected by: Stewart Bryant
Date Rejected: 2011-08-04
There are two distinct "PWE3 Pseudowire Type" namespaces maintained by IANA: - the 'L2TPv3 Pseudowire Types' subregistry of the "l2tp-parameters" registry, rooted in RFC 3831, and - the 'MPLS Pseudowire Type' subregistry of the "pwe3-parameters" registry, rooted in RFC 4446. From the text of RFC 4553, it might be concluded that it was intended to make identical PW type allocations in both subregistries for SAToP, as has been done before in a similar manner in PWE3 RFCs dealing with "<any> over MPLS PWs" and "<any> over L2TPv3 PWs". But the IANA Considerations (Section 11) of RFC 4553 simply state, Allocation of PW types for the corresponding SAToP PWs is defined in [RFC4446]. ... and RFC 4446 has only registered the following assignments for SAToP over MPLS: 0x0011 Structure-agnostic E1 over Packet [SAToP] 0x0012 Structure-agnostic T1 (DS1) over Packet [SAToP] 0x0013 Structure-agnostic E3 over Packet [SAToP] 0x0014 Structure-agnostic T3 (DS3) over Packet [SAToP] Looking into the two IANA registries quoted above, it can be seen that indeed only "pwe3-parameters" contains these assignments, whereas they are not listed in "l2tp-parameters". Apparently, this has been overseen by all parties involved! If this conclusion applies, you should urgently: (1) submit an Author's RFC Errata Note for RFC 4553 to the RFC-Ed with an amendment to Section 11, e.g.: IANA should perform the same assignemnts in the L2TPv3 Pseudowire Type subregistry. (2) Request this action from IANA.
The IANA registry has been updated to correctly reflect the assignment of PW types 0x0011 to 0x0014 to RFC4553. Signalling of TDM PWS over L2TPv3 was not specified until RFC5611, thus L2TPv3 PW type assignments were out of scope of RFC4553.
These IANA assignments would not be re-requested in a future version of this document and an implementer would not be misled by the existing IANA text, thus
reject seems to be the most appropriate state for this erratum.