Re: [mpls] [EXTERNAL] Re: [Errata Held for Document Update] RFC3031 (6450)

[Tony Li <[e-mail]>]

Dear Mr. Anderson,

If you visit the errata database entry for your submission (https://www.rfc-editor.org/errata/eid6450) you will see that the errata is being held for the next update of the document.  We will happily address it at that time.

Sincerely,
Anthony Li, VP Juniper Fellow
Juniper Networks
1133 Innovation Way
Sunnyvale, California, 94089 USA


> On Aug 12, 2022, at 7:51 AM, Duane Anderson <[e-mail]> wrote:
> 
> Ladies and Gentlemen,
>  
> I first reported the issue re RFC-3031 because IETF RFC-3031 MPLS (a.k.a. Layer 2.5) is has been specified as a part of a NATO standard real-time computer LAN system, where LANs can be internetworked and connected to a WAN. The LAN/WAN will follow IEEE 802, 802.1, and 802.2 (ISO/IEC 8802-2). For hard-real-time and safety-critical reasons, these the LANs and WAN will have static virtual circuits, using private MAC addressing to identify data terminal equipment (DTE) and data communication equipment (DCE). 
>  
> The issue re RFC-3031 is its ambiguities. In the conversations Re: [mpls] [Errata Held for Document Update] RFC3031 (6450), some express the opinion that because those participating in the conversation have become accustomed to the ambiguities and because “It is also not local to RFC 3031, the MPLS working group or the IETF”, that there is no need nor responsibility for RFC-3031 be held for document update.
>  
> The IETF cannot control who will use its standard for purposes other than the Internet. Safety-critical and mission-critical systems use IEEE, ISO, MIL, ANSI, SAE, etc., standards for systems that must be certified to be complain with the standards, which is possible because these standards are necessarily well written. The ambiguity of RFC-3031 will make it difficult for any developer of a product compliant to the NATO standard, which is derived from many industry standards. 
>  
> An implementation of a product based upon an ambiguous specification is not erroneous. The specification is erroneous and a failure of the product to perform as required during operation due to a latent defect in the design due to an ambiguity in the specification will be the the fault of the IETF, even though it or any member cannot be held responsible.  
>  
> Sincerely,
>  
> Duane L. Anderson, President 
> Edgewater Computer Systems, Inc.
> 50 Hines Road, Suite 200
> Ottawa, ON K2K 2M5 Canada 
> Telephone: [phone]
> Facsimile: [phone] 
> ________________________________________________________________________
>   
> This e-mail may be privileged and/or confidential, and the sender does not waive any related rights and obligations. Any distribution, use or copying of this e-mail or the information it contains by other than an intended recipient is unauthorized. If you are not the intended recipient, please notify me at the telephone number shown above or by return e-mail and immediately delete this communication and any copy. Thank you.
>   
> Ce courrier électronique est confidentiel et protégé. L'expéditeur ne renonce pas aux droits et obligations qui s'y rapportent. Toute diffusion, utilisation ou copie de ce message ou des renseignements qu'il contient par une personne autre que le (les) destinataire(s) désigné(s) est interdite. Si ce message vous est parvenu par erreur, vous êtes en conséquence prié de nous aviser immédiatement par téléphone ou par courriel. De plus veuillez détruire ce message immédiatement. Merci.
>  
> From: Greg Mirsky <[e-mail]> 
> Sent: August 4, 2022 5:38 PM
> To: Alexander Vainshtein <[e-mail]>
> Cc: Andrew G. Malis <[e-mail]>; Acee Lindem (acee) <acee=[e-mail]>; mpls <[e-mail]>; Chris Smiley <[e-mail]>; Andrew Alston <Andrew.Alston=[e-mail]>; Duane Anderson <[e-mail]>; Andrew Alston - IETF <[e-mail]>; [e-mail]; Ross Callon <[e-mail]>; [e-mail]; RFC Errata System <[e-mail]>; The IESG <[e-mail]>
> Subject: Re: [mpls] [EXTERNAL] Re: [Errata Held for Document Update] RFC3031 (6450)
>  
> I concur with the previously stated opinion that the errata has not affect the correctness of the interpretation and we have no evidence that it lead to a erroneous implementation. 
>  
> Regards,
> Greg
>  
> On Thu, Aug 4, 2022, 03:11 Alexander Vainshtein <[e-mail]> wrote:
> Andy, Acee, and all,
> +1.
>  
>  
>  
> Regards,
> Sasha
>  
> Office: [phone]
> Cell:      [phone]
> Email:   [e-mail]
>  
> From: mpls <[e-mail]> On Behalf Of Andrew G. Malis
> Sent: Thursday, August 4, 2022 1:53 PM
> To: Acee Lindem (acee) <acee=[e-mail]>
> Cc: [e-mail]; Chris Smiley <[e-mail]>; Andrew Alston <Andrew.Alston=[e-mail]>; [e-mail]; Andrew Alston - IETF <[e-mail]>; [e-mail]; [e-mail]; [e-mail]; RFC Errata System <[e-mail]>; The IESG <[e-mail]>
> Subject: [EXTERNAL] Re: [mpls] [Errata Held for Document Update] RFC3031 (6450)
>  
> I also agree.
>  
> Cheers,
> Andy
>  
>  
> On Wed, Aug 3, 2022 at 7:13 AM Acee Lindem (acee) <acee=[e-mail]> wrote:
> Agree with Stewart. I’ve never had problems with the ambiguity of the acronyms when they are consumed in context. 
> Acee
>  
> From: mpls <[e-mail]> on behalf of Stewart Bryant <[e-mail]>
> Date: Wednesday, August 3, 2022 at 2:46 AM
> To: Andrew Alston <Andrew.Alston=[e-mail]>
> Cc: Chris Smiley <[e-mail]>, Andrew Alston - IETF <[e-mail]>, "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>, The IESG <[e-mail]>, "[e-mail]" <[e-mail]>, Ross Callon <[e-mail]>, "[e-mail]" <[e-mail]>, RFC Errata System <[e-mail]>
> Subject: Re: [mpls] [Errata Held for Document Update] RFC3031 (6450)
>  
> Hi Andrew,
>  
> I agree with what you say, and that it should be held for update.
>  
> However I think that this is an editorial rather than a technical change.
>  
> Stewart
>  
> Sent from my iPad
>  
> 
> On 2 Aug 2022, at 22:37, Andrew Alston <Andrew.Alston=[e-mail]> wrote:
> 
> As I said in my notes, while I do believe that this errata contains things that probably should be rectified, considering the wide number of changes this would entail within the document, I do not consider this a simple errata, and hence believe that if these changes are to be made, they need to be done when and if there is a BIS document published to update this and not a simple errata.
>  
> Hence, I believe that holding this for an update and if at some point someone chooses to push through a BIS to update this – along with any other potential changes – these fixes can be incorporated at that point, until then – I’m going to stand by my hold for update status on this one.
>  
> Thanks
>  
> Andrew
>  
>  
> From: mpls <[e-mail]> On Behalf Of Chris Smiley
> Sent: Wednesday, August 3, 2022 12:29 AM
> To: Andrew Alston - IETF <[e-mail]>
> Cc: [e-mail]; [e-mail]; The IESG <[e-mail]>; [e-mail]; [e-mail]; [e-mail]; RFC Errata System <[e-mail]>
> Subject: Re: [mpls] [Errata Held for Document Update] RFC3031 (6450)
>  
> 
> Hi Andrew,
> 
> We note that this erratum has already been marked as "Held for Document Update”. Please let us know if you would like us to set it back to “Reported” so you can make further updates. 
> 
> Thank you.
> 
> RFC Editor/cs
> 
> 
> > On Jul 28, 2022, at 4:45 AM, Loa Andersson <[e-mail]> wrote:
> > 
> > Andrew,
> > 
> > I think we should reject this errata, it has been running code for 25 years or more, no problems reported. It is also not local to RFC 3031, the MPLS working group or the IETF.
> > 
> > RFC Editor (Errata System),
> > 
> > I think Andrew need to OK this, but if not necessary just go and reject.
> > 
> > /Loa
> > 
> > PS
> > 
> > THe addresses to Eric, Ross and Arun are likely not current, but I don't think we need to consult them.
> > 
> > On 2022-05-26 15:56, RFC Errata System wrote:
> >> The following errata report has been held for document update
> >> for RFC3031, "Multiprotocol Label Switching Architecture".
> >> --------------------------------------
> >> You may review the report below and at:
> >> https://www.rfc-editor.org/errata/eid6450
> >> --------------------------------------
> >> Status: Held for Document Update
> >> Type: Technical
> >> Reported by: Duane L. Anderson <[e-mail]>
> >> Date Reported: 2021-03-0
> >> Held by: Andrew Alston (IESG)
> >> Section: GLOBAL
> >> Original Text
> >> -------------
> >> 2.2. Terminology defines the terms
> >> Layer 2 layer 2 the protocol layer under layer 3
> >> (which therefore offers the services used by layer 3)
> >> Layer 3 the protocol layer at which IP and its associated
> >> routing protocols operate
> >> 2.3. Acronyms and Abbreviations defines
> >> L2 Layer 2
> >> L3 Layer 3
> >> However, in 3.14. Scope and Uniqueness of Labels, 4.3. Label Stacks and Implicit Peering, 4.5. LSP Trees as Multipoint-to-Point Entities, and 4.6. LSP Tunneling between BGP Border Routers, L1, L2 and L3 are used as differentiating names for certain labels attached to packets.
> >> Of course, in 3.23. Time-to-Live (TTL), L2 is used to refer to layer 2 frame header and to a layer 2 switch, which is correct.
> >> However, in 4.3. Label Stacks and Implicit Peering, the term level 1 is used to refer to the LIFO (stack) ordinal number of a label then named L1 and given a protocol layer 2 protocol of layer 2 (L2). Furthermore, labels named L2 and then L1 are pushed onto the stack of labels prefixed to the packet. To top it all off the packet's stack attribute as protocol level 2 (L2).
> >> Of course, in 3.17. LSP Next Hop, 4.1.5. The Implicit NULL Label, 5.1.1.2. PushConditional, 5.1.1.4. PulledConditional, 5.1.2.2. RequestWhenNeeded, 5.1.3. Upstream LSR: NotAvailable Procedure, 5.1.4. Upstream LSR: Release Procedure, 5.1.4.2. NoReleaseOnChange, 5.1.5. Upstream LSR: labelUse Procedure, 5.2.2. Schemes for LSRs that do not Support Label Merging, refer to L3 meaning level 3, which is correct.
> >> Furthermore, in 3.1. Labels, 3.2. Upstream and Downstream LSRs, 3.4. Label Assignment and Distribution, 3.5. Attributes of a Label Binding, 3.14. Scope and Uniqueness of Labels, 4.1.2.2. Distributing Labels, 5.1.5. Upstream LSR: labelUse Procedure, 5.1.5.2. UseIfLoopNotDetected, 5.1.6. Downstream LSR: Withdraw Procedure
> >> * L is used as a name for a certain label attached to packet, and
> >> * L is used as a arbitrary value assigned to a label attached to a packet
> >> Corrected Text
> >> --------------
> >> I have not provided any corrected text as I've literally "highlighted" 44 places in a pdf format file of RFC 3031 that are ambiguous.
> >> As there is no facility to attach a file to this Report Errata for RFC3031 form, i will send the file commented pdf file upon request.
> >> Notes
> >> -----
> >> My rational for highlighting (no pun intended) these problems is that the overloading of the L2, L3 abbreviations layer 2 and layer 3, with the names L1, L2, L3 and L for labels, plus the use of L1 and L2 as indexed names for the ordinal position of a label prefixed to a payload, then to use L2 and L3 as to actually mean layer 2 and layer is uh ... sloppy.
> >> Honestly, I can't understand how RFC 3031 has been posted for twenty years and that it is on the Standards Track and no one has found these problems.
> >> Its similar to when someone publishes a mathematical treatise and use the same set of variable names {x, y, z, t} over and over again in different contexts spread throughout the paper. Its intractable and practically gibberish.
> >> I apologize if my criticism is harsh regarding this problem but I spent a considerable amount of my time reading this document trying to make sense of it before I realized that the fault is not mine but it is of the document.
> >> [Andrew] This seems to wide and generalized to be a simple errata, as such I am marking this as held for document update.
> >> --------------------------------------
> >> RFC3031 (draft-ietf-mpls-arch-06)
> >> --------------------------------------
> >> Title : Multiprotocol Label Switching Architecture
> >> Publication Date : January 2001
> >> Author(s) : E. Rosen, A. Viswanathan, R. Callon
> >> Category : PROPOSED STANDARD
> >> Source : Multiprotocol Label Switching
> >> Area : Routing
> >> Stream : IETF
> >> Verifying Party : IESG
> >> _______________________________________________
> >> mpls mailing list
> >> [e-mail]
> >> https://www.ietf.org/mailman/listinfo/mpls
> > 
> > -- 
> > Loa Andersson email: [e-mail]
> > Senior MPLS Expert [e-mail]
> > Bronze Dragon Consulting phone: [phone]
> > 
> 
> _______________________________________________
> mpls mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mpls
>  
> Internal All Employees
> _______________________________________________
> mpls mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mpls
> _______________________________________________
> mpls mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mpls
> 
> Notice: This e-mail together with any attachments may contain information of Ribbon Communications Inc. and its Affiliates that is confidential and/or proprietary for the sole use of the intended recipient. Any review, disclosure, reliance or distribution by others or forwarding without express permission is strictly prohibited. If you are not the intended recipient, please notify the sender immediately and then delete all copies, including any attachments.
> 
> Notice: This e-mail together with any attachments may contain information of Ribbon Communications Inc. and its Affiliates that is confidential and/or proprietary for the sole use of the intended recipient. Any review, disclosure, reliance or distribution by others or forwarding without express permission is strictly prohibited. If you are not the intended recipient, please notify the sender immediately and then delete all copies, including any attachments.
> _______________________________________________
> mpls mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mpls
> _______________________________________________
> mpls mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mpls