Re: [Teas] RTGDIR Early Review of draft-ietf-opsawg-teas-attachment-circuit
Donald Eastlake <d3e3e3@gmail.com> Mon, 11 March 2024 17:04 UTC
Return-Path: <d3e3e3@gmail.com>
X-Original-To: teas@ietfa.amsl.com
Delivered-To: teas@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FD79C14F5F8; Mon, 11 Mar 2024 10:04:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.855
X-Spam-Level:
X-Spam-Status: No, score=-1.855 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_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=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 ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fzlzjVk4K-N7; Mon, 11 Mar 2024 10:04:45 -0700 (PDT)
Received: from mail-ed1-x52a.google.com (mail-ed1-x52a.google.com [IPv6:2a00:1450:4864:20::52a]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 61F3FC14F6FA; Mon, 11 Mar 2024 10:04:45 -0700 (PDT)
Received: by mail-ed1-x52a.google.com with SMTP id 4fb4d7f45d1cf-5685d46b199so1757409a12.3; Mon, 11 Mar 2024 10:04:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1710176683; x=1710781483; darn=ietf.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=7vsoYyCSCEjm/Ldlci1ERo7fp6lqRQyZcjMMoTKz2/E=; b=iuyg/LQEoGx2J9UxKt56z9v4CLPlISDoLHnkjGjh4+cjph0kQSLPab6fangRln2+ot XUoLnZZAjdnTFZA+9iruhPAL9wEWGHONfOgsnU5MoAeG4GzQV+Y9Xq1GUcDRc4XLsp2u 3aogMA3yQhy/LvSS5F9wlEgg8q2Z17QCsdrLKIcWmEYqBtPs/mAP5FR3OQOT3LvMgqpn nb8x/H/0aiwUQTD0V6WfH9TDLHXnYr0W+CpLfs0csFtFX++rao9XTIuMnSUKC9bmTjRt PQu+n9BPSI0Y4s9Ck3tWXdoJkdGCRlKOH6usbH3GC8euJ0GOaIJd0O9ufrHyjxGewvuE OVrw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1710176683; x=1710781483; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=7vsoYyCSCEjm/Ldlci1ERo7fp6lqRQyZcjMMoTKz2/E=; b=TLujy3kl0tvkkHhXP1qYrSouYkaWuD37nrjl5tpMpmL6AF4sTXLC3nNExLF8Oy1VMI MQTcj0xUCfDvJTpWlqNgGXJ3vBrrNlMBorIDM6LGm/3e50lvYxtk8VuCmv2oLjsLvH/n ttBBUVOCcM1pUWpi3H46diLYzMaUkuUEqJrEa+HsSQZOANEZI41/WL0jvp+depveht1q Ji1J6Ut8CttBl8qlng6SKE4/8yxi47JUNOv4bhYDwqtD34wu0jK7RSKkYHIaG8cXdvXc 1NNcAXN4OO22h7AFYpR2bekTs9HRepm0MiLgTJdhH4qZkPi/dWeugnryi1WqGJM+stAb aDRQ==
X-Forwarded-Encrypted: i=1; AJvYcCXyA6T58hmfBEU/kU0vHs2LhJwVoZLo32kRfg94bho1ZqbdYDho4CTQ+wIp/PyIMFmAIsyur1RhK5wHBC08pjeygGrZ8QG616dY7ENYVBszVPc4aJ3XBWEgqNdK43KwDLFE27MsB79HJVkz6CvxkcYJ12x9HZSS+FlMufPPE2uKX54SMbIZmLQ=
X-Gm-Message-State: AOJu0Yxzy3EkU0yPMmAN30jhlnn+Gxbi6pVl/DIqMkKgN6M2rc1Vm0E/ I8P7Yy/W5ZjZtWJNvyvfqU8kyhkbMgdVMdHZvJT7jlCOJDn5fyccYyh/VnPMdwz7UsV7CAx2Lns oNpSfz3bWAtvT1hVz0qJOQQlLrslG1G1Z
X-Google-Smtp-Source: AGHT+IG8IYjJXG/6pWoplnMLRi8ILTKOIScn0Zy4ExvfRVjGcycxSD4fqa6J/hydVkQpSCTQXestZBY12Jog9qI5OnM=
X-Received: by 2002:a50:cd95:0:b0:567:45e2:c4db with SMTP id p21-20020a50cd95000000b0056745e2c4dbmr732966edi.39.1710176683110; Mon, 11 Mar 2024 10:04:43 -0700 (PDT)
MIME-Version: 1.0
References: <CAF4+nEGwv8FbtszhgACKX2cqt7cH-2KTmLuG64gYHosLsdajQw@mail.gmail.com> <DU2PR02MB101602856D869C0C4DABCF42088242@DU2PR02MB10160.eurprd02.prod.outlook.com>
In-Reply-To: <DU2PR02MB101602856D869C0C4DABCF42088242@DU2PR02MB10160.eurprd02.prod.outlook.com>
From: Donald Eastlake <d3e3e3@gmail.com>
Date: Mon, 11 Mar 2024 13:04:31 -0400
Message-ID: <CAF4+nEH94mW5Zdk8i=M-P+rSx6SvZSypWFp-BFvf=joWKG7GSw@mail.gmail.com>
To: mohamed.boucadair@orange.com
Cc: "opsawg@ietf.org" <opsawg@ietf.org>, "draft-ietf-opsawg-teas-attachment-circuit.all@ietf.org" <draft-ietf-opsawg-teas-attachment-circuit.all@ietf.org>, Routing Directorate <rtg-dir@ietf.org>, "teas@ietf.org" <teas@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000b33a680613658987"
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/TGyO4QzVKB3EM_xviIgrjvoN-7w>
Subject: Re: [Teas] RTGDIR Early Review of draft-ietf-opsawg-teas-attachment-circuit
X-BeenThere: teas@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Traffic Engineering Architecture and Signaling working group discussion list <teas.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/teas>, <mailto:teas-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/teas/>
List-Post: <mailto:teas@ietf.org>
List-Help: <mailto:teas-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/teas>, <mailto:teas-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 11 Mar 2024 17:04:49 -0000
Hi Med, I have reviewed the changes you made and am happy with them. I consider all my comments to have been resolved. Thanks, Donald =============================== Donald E. Eastlake 3rd +1-508-333-2270 (cell) 2386 Panoramic Circle, Apopka, FL 32703 USA d3e3e3@gmail.com On Mon, Mar 11, 2024 at 2:31 AM <mohamed.boucadair@orange.com> wrote: > Hi Donald, > > > > (adding OPSAWG as it seems the review was not shared on that list) > > > > Thanks for the careful review. > > > > A diff to track the changes to address your comments can be seen at: > > > > > https://author-tools.ietf.org/api/iddiff?doc_1=draft-ietf-opsawg-teas-attachment-circuit&url_2=https://boucadair.github.io/attachment-circuit-model/draft-ietf-opsawg-teas-attachment-circuit.txt > > > > See more context inline, fwiw. > > > > Cheers, > > Med > > > > *De :* Donald Eastlake <d3e3e3@gmail.com> > *Envoyé :* samedi 9 mars 2024 04:16 > *À :* teas-chairs@ietf.org; > draft-ietf-opsawg-teas-attachment-circuit.all@ietf.org > *Cc :* Routing Directorate <rtg-dir@ietf.org>; teas@ietf.org > *Objet :* RTGDIR Early Review of draft-ietf-opsawg-teas-attachment-circuit > > > > Hello, > > I have been selected to do a routing directorate “early” review of this > draft. > https://datatracker.ietf.org/doc/draft-ietf-opsawg-teas-attachment-circuit/ > > The routing directorate will, on request from the working group chair, > perform an “early” review of a draft before it is submitted for publication > to the IESG. The early review can be performed at any time during the > draft’s lifetime as a working group document. The purpose of the early > review depends on the stage that the document has reached. > > As this document has recently been adopted by the working group fairly > recently (November 2023), my focus for the review is on catching any issues > early on in the document's life cycle. > > For more information about the Routing Directorate, please see > https://wiki.ietf.org/en/group/rtg/RtgDir > > Document: draft-ietf-opsawg-teas-attachment-circuit-07.txt > Reviewer: Donald Eastlake > Review Date: 8 March 2024 > Intended Status: Standards Track > > > Summary: > -------- > > I have some minor concerns about this document that I think should be > resolved before it is submitted to the IESG. > > This document specifies a YANG service data model for Attachment Circuits > and a set of reusable groupings. I am not that deep a YANG expert but > it seems to be headed in the right direction. > > > Comments: > --------- > > I found the writing in this draft to be reasonably good in quality and > readability. > > It seems curious that the first sentence of Section 1.1 does not mention > PEs. > > *[Med] That list focuses on the customer terminating points, not the > network-facing ones. Added a PE mention in the para when provider network > is mentioned.* > > > > Also, Service Functions (and Service Function Forwarders?) seem to usually > be listed first in such lists giving them great importance. > > *[Med] SF is mentioned (and changed all occurrences of network function to > SF for consistency). No need to call out SFF.* > > In Section 3.2, I don't think "advanced network services", which sounds > like a marketing term, is well defined. If you mean network slicing, just > say that. > > *[Med] Reworded. * > > > The list of references to section 4.2.5.3.x at the start of the 2nd > paragraph of Section 4.2.5.3 is missing VRRP (Section 4.2.5.6). > > *[Med] Added a new sentence to mention VRRP. * > > > > Except that actually a number of the sections seem like they should be one > level deeper: 4.2.5.4 -> 4.2.5.3.4, 4.2.5.5 -> 4.2.3.5, and 4.2.5.6 -> > 4.2.5.3.6. This would change the numbering of a few following sections > such as 4.2.5.7 -> 4.2.5.4. > > *[Med] Good catch. Fixed.* > > > Figure 11 seems to be missing ospf. > > *[Med] You are right. Fixed. * > > > In Section 6 there are two sentences that begin "These data nodes are > defined with ". It is not clear to me if "These" refers to the nodes > listed before or those listed after the sentence. > > *[Med] Reworded to clarify the intent.* > > > > Nits: > > *[Med] Went with almost all your suggestions. Please note that I didn’t > add a ref to RFC20 given that we provide the authoritative reference > RFC8177 for key strings. I also didn’t change to vrrp-bis for now. Will > take care of that when the RFC is published.* > > > ----- > > "merit to decorrelate the" -> "merit of decorrelating the" > > "An example to retrieve a" -> "An example of retrieving a" > > "SAPs" is not spelled out where first used but rather in the following > paragraph. > > "the ACs that the ordered" -> "the ACs that they ordered" > > "If these provisioning of these services require specific" -> "If the > provisioning of these services requires" > > Section 1.2 heading: "Position" -> "Positioning" > > Section 1.2.1 and 1.2.2 headings: "Using" -> "Use" > > "L2SM" and "L3SM" are not expanded. > > Section 3.1, Since "VRRP" is used and expanded, a reference to > draft-ietf-rtgwg-vrrp-rfc5798bis-18 would be appropriate. (That draft is in > the RFC Editor queue in the final stage of editing so should not become a > blocking reference.) > > In Figures 1, 35, 36, and 40, vertical lines are usually represented by > the ASCII VERTICAL LINE character, 0x7C, which is what is normally used in > ASCII art, but in some cases the Unicode character BOX DRAWINGS LIGHT > VERTICAL, 0x2502, is used. This causes garbles in the htmlized version of > the draft. I recommend a global replacement of character 0x2502 with > character 0x7C and, in any case, they should be consistent. > > In the first line after the Figure 3 caption, there is an "NF", which I > would guess stands for Network Function, that is not expanded or explained > anywhere. > > Since LLDP is used and expanded, there should probably be a reference to > IEEE Std 802.1AB. > > In Section 4.1, there are several references to "PE" and "PoP" but I don't > think these are expanded anywhere. > > "If these status values differ, a trigger to detect an anomaly." -> "These > status values differing should trigger the detection of an anomaly > condition." > > "The profiles definition are" -> "The profile definitions are" > > "abovementioned" -> "above mentioned" > > "request avoiding to connnecting" -> "request avoidance of connecting" > > Section 4.2.5.1 "encapsulation type defined" -> "encapsulation types > defined" > > > Suggest changing the heading of 4.2.5.7 (which should probably be 4.2.5.4 > as mentioned above) from "OAM" to "Operations, Administration, and > Maintenance (OAM [RFC6291]" > > There are about three uses of "ACes" in the draft but many uses of "ACs". > Suggest changing all "ACes" to "ACs". > > Globally replace "commited" with "committed". > > Section 6: "this lead to" -> "this leads to", "leading to malfunctioning" > -> "which can lead to malfunctioning" > > Suggest "ASCII" -> "ASCII [RFC0020]" > > Sometimes it is "c-vlan" and sometimes it is "cvlan". Probably best to > standardize. > > The first word of Section A.4, instead of the character 0x27 apostrophe, > has unicode character 0x2019 RIGHT SINGLE QUOTE. This causes a grable in > the htmlized version. Suggest using the usual ASCII apostrophe. > > In the caption of Figures 27, 28 and 29: non-initial "The" -> "the". But > some more words in the caption of Figure 30 should be capitalized. > > "reponse" -> "response" > > "latencey" -> "latency" > > First word of Acknowledgements section: "The" -> "This" > > There are a number of idnits complaints about lines too long but I think > these are due to non-ASCII characters and are not actual problems. > > > > Thanks, > Donald > =============================== > Donald E. Eastlake 3rd +1-508-333-2270 (cell) > 2386 Panoramic Circle, Apopka, FL 32703 USA > d3e3e3@gmail.com > > ____________________________________________________________________________________________________________ > Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. > > This message and its attachments may contain confidential or privileged information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and delete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. > Thank you. > >
- [Teas] RTGDIR Early Review of draft-ietf-opsawg-t… Donald Eastlake
- Re: [Teas] RTGDIR Early Review of draft-ietf-opsa… mohamed.boucadair
- Re: [Teas] RTGDIR Early Review of draft-ietf-opsa… Donald Eastlake
- Re: [Teas] RTGDIR Early Review of draft-ietf-opsa… mohamed.boucadair