From nobody Fri Mar 5 22:48:23 2021 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D221A3A141E for ; Fri, 5 Mar 2021 22:48:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U-DndNsIKN-u for ; Fri, 5 Mar 2021 22:48:19 -0800 (PST) Received: from mail-pf1-x434.google.com (mail-pf1-x434.google.com [IPv6:2607:f8b0:4864:20::434]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2B4693A141D for ; Fri, 5 Mar 2021 22:48:19 -0800 (PST) Received: by mail-pf1-x434.google.com with SMTP id x7so268558pfi.7 for ; Fri, 05 Mar 2021 22:48:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=content-transfer-encoding:from:mime-version:subject:date:message-id :references:cc:in-reply-to:to; bh=Y38E3GH9oP2NeN7zf9nUb1cYot62m849CD8s3QJam/Q=; b=fzj66OTJMtWxyinJB6eo7BHtnG9HqPYKD9z9C5ZY5RDsWpKeISNaSOiCRW5bXYjCok rYfExBsSGTr/Zf4WfKwTgOymNZB93GkoPR6Q+rXMYhh4pi1CDpS38EyBbUY7NQ8HEXzC O4NpASmql5DTj09S9KylADRUnxkom+5FKWA4/QF0t6pxvtEPnAjYDDnprqGJy/XVX7VF Xpyj0YJ2AECviZ0hlqQ7Nb9LSmwq6WJ246JZ3ykIgbGsKTaluAzTIUtlvS38AmPU4vHm PE3YXjZy5j2dMTNEvpzI+ELegnfnrSkpykDs14i/kzU89A+yiChkJ3HKAP6W0cQTGLs7 TSbQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:content-transfer-encoding:from:mime-version :subject:date:message-id:references:cc:in-reply-to:to; bh=Y38E3GH9oP2NeN7zf9nUb1cYot62m849CD8s3QJam/Q=; b=U5Z75P8pm5CWC9Vcpn5rLe9ReIZDjXa3nyPE0cFFbtITt70Crrl+pKJfJGevt1ZMZR FHTBjAFnFUxD63UZjj4Bi7xAKl7qGJw1N0cwj/Fs9pacsTbhV7wsN66MeKL2ej8E/g++ f6i6VlZ/EhFDOt/3F0pwMhsVeCJS4e0KckxBgeGFlRVnBi/Sf2DIVA14prVmKobkMWwo XSYlRZYiLl5AlyNxGW8hMyUn1TwVUqPx15djPCAK8/3sa1FYbj2obGPdS3UCYjp70PB4 EtG03lfV/7DCnZmb5I9FFEvCYLxU5mgByCWPzd3OQAT9gysAvq0402jPW1nNyoajzGQ4 d0oA== X-Gm-Message-State: AOAM533i01uPivWz0927kRCjeJO01LTwW2DqZPImkxt386O3Y9qM75BO qNE+moTbf/fliVCOCo+LjWM= X-Google-Smtp-Source: ABdhPJztvulI+emuwky5fUayvSqS6hX4al6ojai3ZrbaxTJH6eFeXVyfNusbnhthAfCjzcodseSBug== X-Received: by 2002:a63:4513:: with SMTP id s19mr11536372pga.229.1615013297988; Fri, 05 Mar 2021 22:48:17 -0800 (PST) Received: from [192.168.1.42] ([124.104.184.212]) by smtp.gmail.com with ESMTPSA id e10sm4348682pgd.63.2021.03.05.22.48.16 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 05 Mar 2021 22:48:17 -0800 (PST) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable From: Loa Andersson Mime-Version: 1.0 (1.0) Date: Sat, 6 Mar 2021 14:48:12 +0800 Message-Id: References: Cc: adrian@olddog.co.uk, mpls@ietf.org, Duane.Anderson@edgewater.ca In-Reply-To: To: "BRUNGARD, DEBORAH A" X-Mailer: iPad Mail (18C66) Archived-At: Subject: Re: [mpls] [Technical Errata Reported] RFC3031 (6450) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Mar 2021 06:48:22 -0000 Deborah, ail, In-line please.=20 Sent from my iPad > On 5 Mar 2021, at 05:47, BRUNGARD, DEBORAH A wrote: >=20 > =EF=BB=BFHi, >=20 > Thanks Duane for user feedback - much appreciated! As you know, those most= familiar with a technology, often do not see the same as someone first-time= reading. Usually we rely on our friendly ADs from other IETF Areas or exper= t RFC editors to do a final scrub during publication - and some are quite sc= rutinizing! I don't think this would have passed today's IESG=F0=9F=98=8A >=20 > But as Stewart notes, given one does have the context of the sentences for= the meaning, this is more editorial than technical. >=20 > The RFC viewing has much improved and we now can view with verified errata= : > https://www.rfc-editor.org/rfc/inline-errata/rfc3031.html >=20 > I'd suggest, doing an editorial errata as Adrian suggests. If you are happ= y with his proposal - and the MPLS chairs agree - I can swap this over to an= editorial and verify. As I'll be stepping down as AD next week, if can let m= e know in the next few days, I'll do immediately. If more time is needed, it= will be for Martin to approve. Note - we have Adrian's list (thanks Adrian!= ) - if more are identified later - can always do another errata. >=20 > Duane - Ok? MPLS Chairs - Ok? I seriously doubt that this necessary. After all this is a question that we n= ever once have had to answer, it seems that the context in every case is cle= ar. However, as an editorial errata to to be hold for a 3031bis, I guess it is h= armless.=20 /Loa >=20 > Deborah >=20 >=20 > -----Original Message----- > From: Adrian Farrel =20 > Sent: Thursday, March 4, 2021 12:46 PM > To: mpls@ietf.org > Cc: Duane.Anderson@Edgewater.CA; BRUNGARD, DEBORAH A ; are= tana.ietf@gmail.com; martin.vigoureux@nokia.com; loa@pi.nu; n.leymann@teleko= m.de; tsaad.net@gmail.com; jgs@juniper.net > Subject: RE: [mpls] [Technical Errata Reported] RFC3031 (6450) >=20 > Hi, >=20 > I looked through this and reread 3031 (if may have been a few years). >=20 > While I can agree that there is "potential for confusion" in the use of "L= 2" > and "L3", I agree with Stewart that not many people have reported being > confused in the last 20 years (happy birthday, RFC 3031!). >=20 > Perhaps an easier fix (if a fix is needed at all - I don't believe it is) i= s > to remove the abbreviations "L2" and "L3".=20 >=20 > For "L2" > 2.3 Remove L2 > 3.23 s/L2/layer 2/ twice >=20 > For "L3" > 2.2 s/L3/layer 3/ three times > 2.3 Remove L3 > 3.17 s/L3/layer 3/=20 > 4.15 s/L3/layer 3/ > 5.1.1.2 s/L3/layer 3/ twice > 5.1.2.2 s/L3/layer 3/ > 5.1.3 s/L3/layer 3/ > 5.1.4 s/L3/layer 3/ > 5.1.4.2 s/L3/layer 3/ > 5.1.5 s/L3/layer 3/ four times > 5.1.5.1 s/L3/layer 3/ > 5.2.2 s/L3/layer 3/ >=20 > Maybe pop that list of changes in the report, mark it as Editorial, and mo= ve > on? >=20 > Cheers, > Adrian >=20 > -----Original Message----- > From: mpls On Behalf Of RFC Errata System > Sent: 04 March 2021 03:43 > To: erosen@cisco.com; arun@force10networks.com; rcallon@juniper.net; > db3546@att.com; aretana.ietf@gmail.com; martin.vigoureux@nokia.com; > loa@pi.nu; n.leymann@telekom.de; tsaad.net@gmail.com > Cc: Duane.Anderson@Edgewater.CA; mpls@ietf.org; rfc-editor@rfc-editor.org > Subject: [mpls] [Technical Errata Reported] RFC3031 (6450) >=20 > The following errata report has been submitted for RFC3031, > "Multiprotocol Label Switching Architecture". >=20 > -------------------------------------- > You may review the report below and at: > https://urldefense.com/v3/__https://www.rfc-editor.org/errata/eid6450__;!!= BhdT!2-7fS0CMjWs9n-bXsviC8j9-l7nAesqsNNgwryAxWA5laUCob4MKYTYMnuK6s74$=20 >=20 > -------------------------------------- > Type: Technical > Reported by: Duane L. Anderson >=20 > Section: GLOBAL >=20 > Original Text > ------------- > 2.2. Terminology defines the terms >=20 > Layer 2 layer 2 the protocol layer under layer 3=20 > (which therefore offers the services used by layer > 3) > Layer 3 the protocol layer at which IP and its associated=20= > routing protocols operate >=20 > 2.3. Acronyms and Abbreviations defines=20 >=20 > L2 Layer 2 > L3 Layer 3 >=20 > 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.=20 >=20 > Of course, in 3.23. Time-to-Live (TTL), L2 is used to refer to layer 2 fra= me > header and to a layer 2 switch, which is correct.=20 >=20 > However, in 4.3. Label Stacks and Implicit Peering, the term level 1 is us= ed > 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 nam= ed > 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).=20= >=20 > 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, refe= r > to L3 meaning level 3, which is correct.=20 >=20 > 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. Sco= pe > and Uniqueness of Labels, 4.1.2.2. Distributing Labels, 5.1.5. Upstream LS= R: > labelUse Procedure, 5.1.5.2. UseIfLoopNotDetected, 5.1.6. Downstream LSR: > Withdraw Procedure >=20 > * L is used as a name for a certain label attached to packet, and=20 >=20 > * L is used as a arbitrary value assigned to a label attached to a packet >=20 >=20 > 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.=20 >=20 > 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.=20 >=20 > 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 name= s > L1, L2, L3 and L for labels, plus the use of L1 and L2 as indexed names fo= r > the ordinal position of a label prefixed to a payload, then to use L2 and L= 3 > as to actually mean layer 2 and layer is uh ... sloppy.=20 >=20 > 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.= =20 >=20 > 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.=20 >=20 > 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 o= f > it before I realized that the fault is not mine but it is of the document.= >=20 > Instructions: > ------------- > This erratum 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 =20 > can log in to change the status and edit the report, if necessary.=20 >=20 > -------------------------------------- > 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 >=20 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/mpls__;!= !BhdT!2-7fS0CMjWs9n-bXsviC8j9-l7nAesqsNNgwryAxWA5laUCob4MKYTYMmj5Y50k$=20 >=20 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls