From nobody Sat May 1 01:01:10 2021 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF9663A0835; Sat, 1 May 2021 01:01:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.785 X-Spam-Level: X-Spam-Status: No, score=0.785 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MAY_BE_FORGED=2.7, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no 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 hhJ678BAS4ZU; Sat, 1 May 2021 01:01:03 -0700 (PDT) Received: from mta5.iomartmail.com (mta5.iomartmail.com [62.128.193.155]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D597A3A0827; Sat, 1 May 2021 01:01:02 -0700 (PDT) Received: from vs1.iomartmail.com (vs1.iomartmail.com [10.12.10.121]) by mta5.iomartmail.com (8.14.4/8.14.4) with ESMTP id 14180wmv027343; Sat, 1 May 2021 09:00:58 +0100 Received: from vs1.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 9649C22052; Sat, 1 May 2021 09:00:58 +0100 (BST) Received: from asmtp2.iomartmail.com (unknown [10.12.10.249]) by vs1.iomartmail.com (Postfix) with ESMTPS id 885422204E; Sat, 1 May 2021 09:00:58 +0100 (BST) Received: from LAPTOPK7AS653V (74.197.bbplus.pte-ag1.dyn.plus.net [81.174.197.74] (may be forged)) (authenticated bits=0) by asmtp2.iomartmail.com (8.14.4/8.14.4) with ESMTP id 14180vQK020190 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sat, 1 May 2021 09:00:58 +0100 Reply-To: From: "Adrian Farrel" To: "'Ravi Singh'" , , Cc: , References: In-Reply-To: Date: Sat, 1 May 2021 09:00:58 +0100 Organization: Old Dog Consulting Message-ID: <01db01d73e60$1f1aedc0$5d50c940$@olddog.co.uk> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_01DC_01D73E68.80DF55C0" X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQE7mBtQB3nYp/Vokiljzq0s3n5GdawFj9Qg Content-Language: en-gb X-Originating-IP: 81.174.197.74 X-Thinkmail-Auth: adrian@olddog.co.uk X-TM-AS-GCONF: 00 X-TM-AS-Product-Ver: IMSVA-9.0.0.1623-8.2.0.1013-26124.006 X-TM-AS-Result: No--16.781-10.0-31-10 X-imss-scan-details: No--16.781-10.0-31-10 X-TMASE-Version: IMSVA-9.0.0.1623-8.2.1013-26124.006 X-TMASE-Result: 10--16.781000-10.000000 X-TMASE-MatchedRID: 9vvqFUF7IWmWfDtBOz4q22mpWpGzPzJdaMmm586o4gDPlmI4N1s8ilVx c/d4wt8XQ+qFfSnBhruH7/YaXrc5rF6roberhuTglVHM/F6YkvSpvf+jmz45w56+KClOpyujdAl mC9v1KauKLpFrWkyjfvNrZv9cFWGfQpm8rLhVqkN7396uJNSvqinsJ9MqQSOlWGzy6KaAc0KB+d uJcV6+5X4fsU2Mo5fdAJ42yu0exwIoEmCdDOvToeUKNN5hHcABrFP4l9ANsI+O9vLIatD3yMkZb L61I/L0CuMeNI8ov5dJpV9rHFX3j7MwnTKgkbsOwbRQ2BpmliraCn4DqCiXNrYzXCxJu2uR90ib xL4bz6BrlDI4zvG/OgCHPJ7UNtV51LFdtmiebE6A3KVVsj8QDKgJ/sh288AnGHWakJc1ULz6p1j lhLAJAlWeA27U+g5dIw6Kr6crgUxhTSvDZHacphz2MDiYujy5EsGpOXjV8vtMvtSjCgVE+gSTtQ 0wIxotdH2PU6szI3OJ6uGtPJgUD0UuXkWTSi/RT7O/YHJhINAFeeAjqMW+lxXVi8DrxXDvbVsEF Jqff8nvp8GuZhjBuTsOdvA5nu/wA7dimDbca7izRPQ8T4oe5bPksiHb4g58AUYifayLzo/hry2N wTSXHIFeREEb0o7aFABeLgZr0ZEfE8yM4pjsD4MbH85DUZXyAzmRhRrMoRWw7M6dyuYKgyWCaJn oH28H1WAjPpJPzwS4pUlnzj5z4aioecx+vLoa1XHj0GPcmF0= X-TMASE-SNAP-Result: 1.821001.0001-0-1-12:0,22:0,33:0,34:0-0 Archived-At: Subject: Re: [RTG-DIR] RtgDir Early review: draft-ietf-bess-datacenter-gateway-10.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 May 2021 08:01:08 -0000 This is a multipart message in MIME format. ------=_NextPart_000_01DC_01D73E68.80DF55C0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi Ravi, =20 Thanks for taking the time and providing your review. =20 Best, Adrian =20 From: Ravi Singh =20 Sent: 01 May 2021 07:42 To: bess-chairs@ietf.org; draft-ietf-bess-datacenter-gateway@ietf.org Cc: bess@ietf.org; rtg-dir@ietf.org Subject: RtgDir Early review: draft-ietf-bess-datacenter-gateway-10.txt =20 Hello I have been selected to do a routing directorate =E2=80=9Cearly=E2=80=9D = review of this draft. draft-ietf-bess-datacenter-gateway The routing directorate will, on request from the working group chair, = perform an =E2=80=9Cearly=E2=80=9D 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=E2=80=99s lifetime as a working group = document. The purpose of the early review depends on the stage that the = document has reached. =20 Document: draft-ietf-bess-datacenter-gateway-10.txt Reviewer: Ravi Singh Review Date: 04/30/2021 Intended Status: Standards Track Summary: * No issues found. This documents is ready to proceed to the IESG. =20 Regards Ravi =20 ------=_NextPart_000_01DC_01D73E68.80DF55C0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Hi = Ravi,

 

Thanks for = taking the time and providing your review.

 

Best,

Adrian

 

From: Ravi Singh = <ravi.singh.ietf@gmail.com>
Sent: 01 May 2021 = 07:42
To: bess-chairs@ietf.org; = draft-ietf-bess-datacenter-gateway@ietf.org
Cc: bess@ietf.org; = rtg-dir@ietf.org
Subject: RtgDir Early review: = draft-ietf-bess-datacenter-gateway-10.txt

 

H= ello

I= have been selected to do a routing directorate =E2=80=9Cearly=E2=80=9D = review of this draft.

draft-ietf-bess-datacenter-gateway

T= he routing directorate will, on request from the working group chair, = perform an =E2=80=9Cearly=E2=80=9D 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=E2=80=99s lifetime as a working group = document. The purpose of the early review depends on the stage that the = document has reached.

 

Document: draft-ietf-bess-datacenter-gateway-10.txt
Reviewer: Ravi = Singh
Review = Date: 04/30/2021
Intended Status: Standards = Track



Summary:

  • No issues found. This documents is ready to proceed to = the IESG.

 

Regards

Ravi

 

------=_NextPart_000_01DC_01D73E68.80DF55C0-- From nobody Tue May 4 09:05:42 2021 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF8383A0FD2; Tue, 4 May 2021 09:05:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 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, HTML_MESSAGE=0.001, 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 7cFs5zRs_jgY; Tue, 4 May 2021 09:05:32 -0700 (PDT) Received: from mail-lj1-x22b.google.com (mail-lj1-x22b.google.com [IPv6:2a00:1450:4864:20::22b]) (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 B4ABF3A0FDA; Tue, 4 May 2021 09:05:31 -0700 (PDT) Received: by mail-lj1-x22b.google.com with SMTP id o16so11849155ljp.3; Tue, 04 May 2021 09:05:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=xB0HhhWnlPx6YWrAH7A/ZlkyWf/sMgssI4UlJY1DpH4=; b=A7rj2KPxEJqMJJr+8fgzAarp5CGwHkbWeqp1070ZGIeQWZEKqLbLmbwRhkXoQMaiWn ZcUEEhbGRxwjsWq9imRQCmPJ6vCQpvw3ISl5ba+ujuLnDLVvEzbc4ZnnFVmMxRF2pJ6h 7R6bKMTPJl5fiX5yLSMy0cHmqhW1GZQ1CzbA7I3YFTwSDSMiSXZ/BfBwbUVorhTU2gqB 7zJjTDcNjyMDmwzye+Gz3fTVOjpyN1xiV+xlbe+eRyKDSxJXj4koXhByaACIWxDyXBYU ewhppa79NvxFE9eSAZXHWBC/meTrzYFnnUK/uNNB7KmcnoMarOynBLLehnYShuWKKoUR uWvg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=xB0HhhWnlPx6YWrAH7A/ZlkyWf/sMgssI4UlJY1DpH4=; b=q5FUtP3m7JSco+Y+Dl+TLGPGWfDQ7PykcbnP9beqdfKde15QJCUYhXJkH4wwiTl5M9 70KRvXz/Vh1U/5jeljNwNhh1TOJacCnnhCtaSjWnmbI5hTF6kf1MduQzRtxOF1Ak2uGV ru2qmU6GspsPhISxebowz76RxLO/ANOx68uLzqetJhpkz8p+uFk+5loMjohn94fCjT+9 I99c75pCO5Yy36AGS+Yn00gIvqYg59bDqhf+5/btBQBBR5uhWD6TfWnnX5KbM4mfdz0I zod+3qSsFMDXW/uvyetTeGTXIhU+MqtNe0TKigNigRYuObFyONXyVde8BRO82v7DECtt nliQ== X-Gm-Message-State: AOAM533ddZFyBMcGovSSDy7qSJfb0FcNYT8dL4RrefzhvqC/6tyhr9qT B3uxKD/81iiv0FaIg0YcxlDqJWUg1I9eOwzsuwI= X-Google-Smtp-Source: ABdhPJzodNYndNCz7xDBxWn0k+uNuYrtigosX9uF0vulneSmVC1Muwsa277LyuK0K7acExK33h07XeiPFOindVFxoKo= X-Received: by 2002:a2e:b531:: with SMTP id z17mr12513758ljm.126.1620144329219; Tue, 04 May 2021 09:05:29 -0700 (PDT) MIME-Version: 1.0 References: <149978159930.12344.18347332855391607627@ietfa.amsl.com> <20170717090400.GC24942@pfrc.org> <20170717092332.GD24942@pfrc.org> In-Reply-To: <20170717092332.GD24942@pfrc.org> From: Greg Mirsky Date: Tue, 4 May 2021 09:05:17 -0700 Message-ID: To: Jeffrey Haas Cc: Carlos Pignataro , Routing Directorate , "mpls@ietf.org" , draft-ietf-mpls-bfd-directed.all@ietf.org, bfd-chairs@ietf.org Content-Type: multipart/alternative; boundary="0000000000003a62fe05c1833fb8" Archived-At: Subject: Re: [RTG-DIR] Rtgdir early review of draft-ietf-mpls-bfd-directed-07 X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 May 2021 16:05:37 -0000 --0000000000003a62fe05c1833fb8 Content-Type: text/plain; charset="UTF-8" Hi Jeff, I've checked this discussion thread and realized that I've missed highlighting updates that I've made following our discussion on the use of the LSP Ping with BFD Discriminator TLV. Below, please find the text added to Section 3.1: NEW TEXT: The BFD Reverse Path TLV MAY be used in the bootstrapping of a BFD session process described in Section 6 [RFC5884]. A system that supports this specification MUST support using the BFD Reverse Path TLV after the BFD session has been established. If a system that supports this specification receives an LSP Ping with the BFD Discriminator TLV and no BFD Reverse Path TLV even though the reverse path for the specified BFD session has been established according to the previously received BFD Reverse Path TLV, the egress LSR MUST transition to transmitting periodic BFD Control messages as defined in Section 7 [RFC5884]. Please let me know if this text addresses your concerns. Best regards, Greg On Mon, Jul 17, 2017 at 2:13 AM Jeffrey Haas wrote: > On Mon, Jul 17, 2017 at 02:06:01AM -0700, Greg Mirsky wrote: > > true, the RFC 5884 does not discuss handling of subsequent LSP Ping with > > the same BFD Discriminator value in BFD Discriminator TLV. My reference > to > > RFC 5884 is to point that the default, implied path for the reverse > > direction of the BFD session is over IP network and that how this draft > > interprets BFD Reverse Path TLV with none- sub-TLVs included. And yes, > > nodes that would support this draft MUST handle subsequent LSP Ping Echo > > Request with BFD Discriminator and BFD Reverse TLVs. > > > > I don't believe the procedure updating 5884 to change existing session > properties is called out in the -directed document. I don't have a strong > opinion about the use case of whether such updates are desired or not. > That's a decision for the MPLS WG. However, I do think such procedure > needs > to be clear if it's desired. This is part of Carlos' point. > > -- Jeff > --0000000000003a62fe05c1833fb8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Jeff,
I've checked this discussion thread and r= ealized that I've missed highlighting updates that I've made follow= ing our discussion on the use of the LSP Ping with BFD Discriminator TLV. B= elow, please find the text added to Section 3.1:
NEW TEXT:

=C2=A0 =C2=A0The BFD Reverse Path TLV MAY be used in the bootst= rapping of a BFD
=C2=A0 =C2=A0session process described in Section 6 [RF= C5884].=C2=A0 A system that
=C2=A0 =C2=A0supports this specification MUS= T support using the BFD Reverse Path
=C2=A0 =C2=A0TLV after the BFD sess= ion has been established.=C2=A0 If a system that
=C2=A0 =C2=A0supports t= his specification receives an LSP Ping with the BFD
=C2=A0 =C2=A0Discrim= inator TLV and no BFD Reverse Path TLV even though the reverse
=C2=A0 = =C2=A0path for the specified BFD session has been established according to<= br>=C2=A0 =C2=A0the previously received BFD Reverse Path TLV, the egress LS= R MUST
=C2=A0 =C2=A0transition to transmitting periodic BFD Control mess= ages as defined
=C2=A0 =C2=A0in Section 7 [RFC5884].

<= /div>
Please let me know if this text addresses your concerns.

Best regards,
Greg

On Mon, J= ul 17, 2017 at 2:13 AM Jeffrey Haas <j= haas@pfrc.org> wrote:
On Mon, Jul 17, 2017 at 02:06:01AM -0700, Greg Mirsky wrote: > true, the RFC 5884 does not discuss handling of subsequent LSP Ping wi= th
> the same BFD Discriminator value in BFD Discriminator TLV. My referenc= e to
> RFC 5884 is to point that the default, implied path for the reverse > direction of the BFD session is over IP network and that how this draf= t
> interprets BFD Reverse Path TLV with none- sub-TLVs included. And yes,=
> nodes that would support this draft MUST handle subsequent LSP Ping Ec= ho
> Request with BFD Discriminator and BFD Reverse TLVs.
>

I don't believe the procedure updating 5884 to change existing session<= br> properties is called out in the -directed document.=C2=A0 I don't have = a strong
opinion about the use case of whether such updates are desired or not.
That's a decision for the MPLS WG.=C2=A0 However, I do think such proce= dure needs
to be clear if it's desired.=C2=A0 This is part of Carlos' point.
-- Jeff
--0000000000003a62fe05c1833fb8-- From nobody Wed May 5 07:25:36 2021 Return-Path: X-Original-To: rtg-dir@ietf.org Delivered-To: rtg-dir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CED3C3A0E60; Wed, 5 May 2021 07:25:26 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Ron Bonica via Datatracker To: Cc: draft-ietf-idr-bgp-flowspec-oid.all@ietf.org, idr@ietf.org, last-call@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.28.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <162022472678.17502.923532743446987101@ietfa.amsl.com> Reply-To: Ron Bonica Date: Wed, 05 May 2021 07:25:26 -0700 Archived-At: Subject: [RTG-DIR] Rtgdir last call review of draft-ietf-idr-bgp-flowspec-oid-13 X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 May 2021 14:25:27 -0000 Reviewer: Ron Bonica Review result: Ready Solid spec supported by implementations. From nobody Tue May 11 04:31:20 2021 Return-Path: X-Original-To: rtg-dir@ietf.org Delivered-To: rtg-dir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F5E43A11A9; Tue, 11 May 2021 04:31:18 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Dhruv Dhody via Datatracker To: Cc: ccamp@ietf.org, draft-ietf-ccamp-transport-nbi-app-statement.all@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.28.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <162073267819.27623.14933803198192582361@ietfa.amsl.com> Reply-To: Dhruv Dhody Date: Tue, 11 May 2021 04:31:18 -0700 Archived-At: Subject: [RTG-DIR] Rtgdir early review of draft-ietf-ccamp-transport-nbi-app-statement-12 X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 May 2021 11:31:18 -0000 Reviewer: Dhruv Dhody Review result: Has Issues Subject:RtgDir Early review: draft-ietf-ccamp-transport-nbi-app-statement Hello I have been selected to do a routing directorate “early” review of this draft. https://datatracker.ietf.org/doc/draft-ietf-ccamp-transport-nbi-app-statement/ 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. This review request might have been marked as an Early review by mistake. The review stands nevertheless. For more information about the Routing Directorate, please see http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir Document: draft-ietf-ccamp-transport-nbi-app-statement Reviewer: Dhruv Dhody Review Date: 2021-05-10 Intended Status: Informational Summary: I have some minor concerns about this document that I think should be resolved before it is submitted to the IESG. Overview: I have done a review of this I-D based on my understanding of ACTN and the related YANG models. Overall, I found the document difficult to review. I was scrolling up and down the document and finally had to keep the document open on multiple screens to cross-reference various figures to understand the text. I wonder if there is a way to improve readability; can't think of anything obvious... Given the complexity of the subject matter, I do believe that the authors have done a good job. I hope the document would be useful for the implementors. I have some concerns about the JSON Code which I have listed first, followed by other minor comments and nits! JSON Code Issues: - This document provides a 'non-standard' JSON Code in the appendix and provides personal GitHub links on how to validate that JSON code. While the JSON code is common in the YANG documents, this document introduces what looks like a new way to add comments. Question to John (as responsible AD): Does this approach has any IETF process issue? The authors have done a decent job in explaining the need for it and how to handle it. - I tried to set up the docker validate tool as per https://github.com/GianmarcoBruno/json-yang ; I was not able to make it run and gave up after a while. :( The instruction on GitHub README.md does not match with what's in the docker image include the options. - JSON code is based on an older version of YANG models. It would be a good idea to update it to the latest. Related question: YANG models are normative references (which seems the right thing to do), so this document should be published together or after those YANG models are ready and thus some coordination across WG is required. Again something for John to consider. - JSON code should start with . Example - file "mpi1-otn-topology.json", so that the json code can be stripped from the document. - Should the GitHub repo mentioned in the appendix moved under CCAMP WG's GitHub? That would be giving some control over the longtime validity of these URLs. Should they be added as references in the document as well. - Update this -   ========== NOTE: '\\' line wrapping per BCP XXX (RFC XXXX) ==========   It was published as an informational RFC 8792, so remove the BCP and update the RFC number! - On first reading I did not understand the TTP ID naming convention used as per   "// __COMMENT__ tunnel-tp-id": "AN1-1 TTP-ID (1 ->\    \ 0x01 -> 'AQ==')"   Perhaps it could be mentioned somewhere that AQ== is the base64 representation of 0x01. - Appendix B.1.1, Figure 3 - "OTN Abstract Topology exposed at MPI1 (MPI1 OTN Topology)" does not have AN1-8 but the JSON does. I think that might be a mistake? Others: - Title, "Transport Northbound Interface Applicability Statement" - not sure about the title, it does not match with the content of the I-D. - Section 2, the definition of connection is not clear. The use of connection/LSP multiple times is also distracting. Similarly "Link: A link, or a physical link, ..." reads weird.  The note in section 2 needs to be handled at this stage. Note that [TE-TUTORIAL] is already marked informative in the -12 version! - Section 3.1, the notations need to explain what {} means. - Section 3.2 is better suited for the appendix as the JSON code exists only in the appendix. - Section 4.6 is not clear to me. Should one refer to RFC 8640, 8641, and 8650 as far as the datastore update is concerned? Clarify the term 'alarm', do you mean YANG notification or RFC 8623? This section needs some work. - Section 5.1.1, the text at the very end of this section about JSON code is much useful closer to the code in the appendix. - Section 5.1.4, we need to all add some text to describe for merging of multiple instances of TE topology from the same PNC. For example, the merging of OTN (Figure 3) and ETH (Figure 4) should lead to Network domain 1 topology in Figure 6. - Section 5.2.1, is there any reference that can be provided about the handling of TTP and route-object-include-exclude? Or is this document specifying how they should be handled? This is applicable in other instances as well. - Section 5.2.2, "...abstracting S3-1 and S18-3 TTPs", please show S18-3 in the figure, otherwise, it is not clear which TTP it is! Nits: - Authors address at the end of the document do not match the front - Please make abstract as the first section as per the style guide https://www.rfc-editor.org/rfc/rfc7322.html#section-4 - It is expected to use https in the status of the memo - Expand on first use: ODU, EPL, EVPL, OTN, LSP, FC, STM-n, L1CSM, L2SM, VN, - Section 2, s/swith/switch/ ; s/failurs/failures/ - Section 2, adding a reference to documents where these terms come from would help. It's already done for some terms! - Section 4.2, s/[RFC8453] Provides/[RFC8453] provides/ ; s/PNcs/PNCs/ - Section 4.3, Ri (PKT -> foo) and Rj (foo -> PKT) does not align to the format in Section 3.1. Should this be Ri [(PKT) -> foo] and Rj [foo -> (PKT)] instead? - Section 4.7, order of closing brackets is incorrect OLD       R1 [(PKT) -> ODU2], S3[(ODU2]), S1 [(ODU2]), S2[(ODU2]),       S8 [(ODU2]), S12[(ODU2]), S15 [(ODU2]), S18[(ODU2]), R8 [ODU2 ->       (PKT)] NEW       R1 [(PKT) -> ODU2], S3[(ODU2)], S1 [(ODU2)], S2 [(ODU2)],       S8 [(ODU2)], S12[(ODU2)], S15 [(ODU2)], S18[(ODU2)], R8 [ODU2 ->       (PKT)] - Section 5.2, s/models is (e.g., L1CSM, L2SM, VN) is outside/models (e.g., L1CSM, L2SM, VN) is outside/ - Section 5.2, The text says ".. (steps 2.1, 2.2 and 2.3 in Figure 7)". There are no steps 2.1, 2.2, and 2.3 in the figure. - Section 5.2.1, s/OUD2/ODU2/ - Section 5.2.1.1, s/terminating on AN-1 and AN1-2 LTPs/terminating on AN1-1 and AN1-2 LTPs/ - Section 5.2.2, s/Appendix Error! Reference source not found./Appendix B.2.3/; s/OUD2/ODU2/; s/[ETH -> (ODU)]/[ETH -> (ODU2)]/g; - Section 5.2.2.1, s/Tunnel between the AN1-1 and AN1-2/Tunnel between the AN1-1 and AN1-8/ - Section 5.2.3, s/[STM-64 -> (ODU)]/[STM-64 -> (ODU2)]/ - Section 5.2.4, "..physical nodes S3, S1, S2, S31, S33, S15 and S18.." -> S34 is missing!!! - Section 5.3.2, s/S31 and D34/S31 and S34/ ; s/lin/link/ ; - Appendix A, s/an Internet-Draft/this document/ Thanks! Dhruv From nobody Tue May 11 04:39:00 2021 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 809A53A11F7; Tue, 11 May 2021 04:38:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 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, HTML_MESSAGE=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 lKFnmxK65DTk; Tue, 11 May 2021 04:38:49 -0700 (PDT) Received: from mail-io1-xd36.google.com (mail-io1-xd36.google.com [IPv6:2607:f8b0:4864:20::d36]) (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 2DA0C3A11FC; Tue, 11 May 2021 04:38:45 -0700 (PDT) Received: by mail-io1-xd36.google.com with SMTP id k25so17819429iob.6; Tue, 11 May 2021 04:38:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=fKQSwlpxsZzynC5PXZudRl4bzfoKPmc3JhcGbJgJ+28=; b=GU6Z7yEkEzU1RG521xbTEyJ31ngtfM5mOJdCT8Fn6imuJLylBCEyW7lpNLVAkJsEV4 rL5jJcR25wsx6LJHBH4FyeuEEUXNtWnauRJeKR6zF9iEpdcFkUWMEXAUgl3brPwWK1xq 2fHDF21H0bqGHx4Yo4x77SZUFko9dfJHSgzTnHWn9+mW5hszxKsJsVtqq790ff6o1JA+ qsJi3KvQVVonuMwtk9hKxPt/BZxDxkGmGtgjeNVNXLXjxXgB1oW/95yHv/SXGWUi1K0Y ia+/2mFa+DTfNsH6U8sRB5yFz52YXUQqDt9EZ6IP0EDc1NiLUM587o8ghiN56hOIGCO0 bjJQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=fKQSwlpxsZzynC5PXZudRl4bzfoKPmc3JhcGbJgJ+28=; b=lpjI3REhpOKEJre7Czjr8n0agv7zJICsYlQ1Ha1CREOIxEUyiUrnaCnScq1ZGMZZGE E6WfMX/2DqoRRXILY0T5yRgJ0ah6qjOyrnVFnesUKPhFeJ6c3ajNtOOu9dlg30G77rZ1 RsL1GOaQVftENREcb7D8iwX36iGsZhaFjQmNl5BotiA4N7+dN6sv6gJzoqTS3c8cWvcn ocJO6Naq4c0W5z/SaAXBj4Y4bqkatw7OdY+bQcmMiYyJlMsBTsyRjYn23M5mq50KiFvI cDAfvGXDRHDhEry/n34roJy+sYr6CvQaDuJoAxJ2CIwEmgPjGCiZnwg1JREWp4KREdmR NWhA== X-Gm-Message-State: AOAM530G8ifQZR9Tr733k8L7zEQPzkSaF9QGrnrn4bES3JiSsUQhUXwi aWu2FGqnkmjTE4kCM66ohZ1nMM7NP9pBz8BzmKQ= X-Google-Smtp-Source: ABdhPJyttTeNJkfWsgF00Oi8NJI00EHiLC1uNATz3FMBPqPxZsF8xFHU1BDUZoy1X2mHjx+pmjGTwq3W+33wY50QKuM= X-Received: by 2002:a5e:a604:: with SMTP id q4mr22693759ioi.178.1620733123045; Tue, 11 May 2021 04:38:43 -0700 (PDT) MIME-Version: 1.0 References: <162073267819.27623.14933803198192582361@ietfa.amsl.com> In-Reply-To: <162073267819.27623.14933803198192582361@ietfa.amsl.com> From: Dhruv Dhody Date: Tue, 11 May 2021 17:08:06 +0530 Message-ID: To: Dhruv Dhody Cc: rtg-dir@ietf.org, "CCAMP (ccamp@ietf.org)" , draft-ietf-ccamp-transport-nbi-app-statement.all@ietf.org Content-Type: multipart/alternative; boundary="000000000000132f3a05c20c5679" Archived-At: Subject: Re: [RTG-DIR] Rtgdir early review of draft-ietf-ccamp-transport-nbi-app-statement-12 X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 May 2021 11:38:55 -0000 --000000000000132f3a05c20c5679 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi, The formatting seems to be off when I uploaded the text file in the review tool. It looks okay in the datatracker : https://datatracker.ietf.org/doc/review-ietf-ccamp-transport-nbi-app-statem= ent-12-rtgdir-early-dhody-2021-05-11/ ; seems to be an issue with the email then! I am pasting the review again, hoping this works! =3D=3D=3D=3D=3D Subject:RtgDir Early review: draft-ietf-ccamp-transport-nbi-app-statement Hello I have been selected to do a routing directorate =E2=80=9Cearly=E2=80=9D re= view of this draft. https://datatracker.ietf.org/doc/draft-ietf-ccamp-transport-nbi-app-stateme= nt/ The routing directorate will, on request from the working group chair, perform an =E2=80=9Cearly=E2=80=9D 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=E2=80=99s lifetime as a working group document. The purpose of the ea= rly review depends on the stage that the document has reached. This review request might have been marked as an Early review by mistake. The review stands nevertheless. For more information about the Routing Directorate, please see http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir Document: draft-ietf-ccamp-transport-nbi-app-statement Reviewer: Dhruv Dhody Review Date: 2021-05-10 Intended Status: Informational Summary: I have some minor concerns about this document that I think should be resolved before it is submitted to the IESG. Overview: I have done a review of this I-D based on my understanding of ACTN and the related YANG models. Overall, I found the document difficult to review. I was scrolling up and down the document and finally had to keep the document open on multiple screens to cross-reference various figures to understand the text. I wonder if there is a way to improve readability; can't think of anything obvious... Given the complexity of the subject matter, I do believe that the authors have done a good job. I hope the document would be useful for the implementors. I have some concerns about the JSON Code which I have listed first, followed by other minor comments and nits! JSON Code Issues: - This document provides a 'non-standard' JSON Code in the appendix and provides personal GitHub links on how to validate that JSON code. While the JSON code is common in the YANG documents, this document introduces what looks like a new way to add comments. Question to John (as responsible AD): Does this approach has any IETF process issue? The authors have done a decent job in explaining the need for it and how to handle it. - I tried to set up the docker validate tool as per https://github.com/GianmarcoBruno/json-yang ; I was not able to make it run and gave up after a while. :( The instruction on GitHub README.md does not match with what's in the docker image include the options. - JSON code is based on an older version of YANG models. It would be a good idea to update it to the latest. Related question: YANG models are normative references (which seems the right thing to do), so this document should be published together or after those YANG models are ready and thus some coordination across WG is required. Again something for John to consider. - JSON code should start with . Example - file "mpi1-otn-topology.json", so that the json code can be stripped from the document. - Should the GitHub repo mentioned in the appendix moved under CCAMP WG's GitHub? That would be giving some control over the longtime validity of these URLs. Should they be added as references in the document as well. - Update this - =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D NOTE: '\\' line wrapping per BCP XXX (RFC = XXXX) =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D It was published as an informational RFC 8792, so remove the BCP and update the RFC number! - On first reading I did not understand the TTP ID naming convention used as per "// __COMMENT__ tunnel-tp-id": "AN1-1 TTP-ID (1 ->\ \ 0x01 -> 'AQ=3D=3D')" Perhaps it could be mentioned somewhere that AQ=3D=3D is the base64 representation of 0x01. - Appendix B.1.1, Figure 3 - "OTN Abstract Topology exposed at MPI1 (MPI1 OTN Topology)" does not have AN1-8 but the JSON does. I think that might be a mistake? Others: - Title, "Transport Northbound Interface Applicability Statement" - not sure about the title, it does not match with the content of the I-D. - Section 2, the definition of connection is not clear. The use of connection/LSP multiple times is also distracting. Similarly "Link: A link, or a physical link, ..." reads weird. The note in section 2 needs to be handled at this stage. Note that [TE-TUTORIAL] is already marked informative in the -12 version! - Section 3.1, the notations need to explain what {} means. - Section 3.2 is better suited for the appendix as the JSON code exists only in the appendix. - Section 4.6 is not clear to me. Should one refer to RFC 8640, 8641, and 8650 as far as the datastore update is concerned? Clarify the term 'alarm', do you mean YANG notification or RFC 8623? This section needs some work. - Section 5.1.1, the text at the very end of this section about JSON code is much useful closer to the code in the appendix. - Section 5.1.4, we need to all add some text to describe for merging of multiple instances of TE topology from the same PNC. For example, the merging of OTN (Figure 3) and ETH (Figure 4) should lead to Network domain 1 topology in Figure 6. - Section 5.2.1, is there any reference that can be provided about the handling of TTP and route-object-include-exclude? Or is this document specifying how they should be handled? This is applicable in other instances as well. - Section 5.2.2, "...abstracting S3-1 and S18-3 TTPs", please show S18-3 in the figure, otherwise, it is not clear which TTP it is! Nits: - Authors address at the end of the document do not match the front - Please make abstract as the first section as per the style guide https://www.rfc-editor.org/rfc/rfc7322.html#section-4 - It is expected to use https in the status of the memo - Expand on first use: ODU, EPL, EVPL, OTN, LSP, FC, STM-n, L1CSM, L2SM, VN= , - Section 2, s/swith/switch/ ; s/failurs/failures/ - Section 2, adding a reference to documents where these terms come from would help. It's already done for some terms! - Section 4.2, s/[RFC8453] Provides/[RFC8453] provides/ ; s/PNcs/PNCs/ - Section 4.3, Ri (PKT -> foo) and Rj (foo -> PKT) does not align to the format in Section 3.1. Should this be Ri [(PKT) -> foo] and Rj [foo -> (PKT)] instead? - Section 4.7, order of closing brackets is incorrect OLD R1 [(PKT) -> ODU2], S3[(ODU2]), S1 [(ODU2]), S2[(ODU2]), S8 [(ODU2]), S12[(ODU2]), S15 [(ODU2]), S18[(ODU2]), R8 [ODU2 -> (PKT)] NEW R1 [(PKT) -> ODU2], S3[(ODU2)], S1 [(ODU2)], S2 [(ODU2)], S8 [(ODU2)], S12[(ODU2)], S15 [(ODU2)], S18[(ODU2)], R8 [ODU2 -> (PKT)] - Section 5.2, s/models is (e.g., L1CSM, L2SM, VN) is outside/models (e.g., L1CSM, L2SM, VN) is outside/ - Section 5.2, The text says ".. (steps 2.1, 2.2 and 2.3 in Figure 7)". There are no steps 2.1, 2.2, and 2.3 in the figure. - Section 5.2.1, s/OUD2/ODU2/ - Section 5.2.1.1, s/terminating on AN-1 and AN1-2 LTPs/terminating on AN1-1 and AN1-2 LTPs/ - Section 5.2.2, s/Appendix Error! Reference source not found./Appendix B.2.3/; s/OUD2/ODU2/; s/[ETH -> (ODU)]/[ETH -> (ODU2)]/g; - Section 5.2.2.1, s/Tunnel between the AN1-1 and AN1-2/Tunnel between the AN1-1 and AN1-8/ - Section 5.2.3, s/[STM-64 -> (ODU)]/[STM-64 -> (ODU2)]/ - Section 5.2.4, "..physical nodes S3, S1, S2, S31, S33, S15 and S18.." -> S34 is missing!!! - Section 5.3.2, s/S31 and D34/S31 and S34/ ; s/lin/link/ ; - Appendix A, s/an Internet-Draft/this document/ Thanks! Dhruv --000000000000132f3a05c20c5679 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

The formatting seems to be off when I uploaded= the text file in the revie= w tool. It looks okay in the datatracker : https://datatracker.ietf.org/doc/review-ietf-ccamp= -transport-nbi-app-statement-12-rtgdir-early-dhody-2021-05-11/ ; seems = to be an issue with the email then!=C2=A0

I am pasting the review again, hoping this works!

=3D=3D=3D=3D=3D=C2=A0

Subje= ct:RtgDir Early review: draft-ietf-ccamp-transport-nbi-app-statement
Hello

I have been selected to do a routing directorate =E2=80=9Cear= ly=E2=80=9D review of this draft.
https://datatracker.ie= tf.org/doc/draft-ietf-ccamp-transport-nbi-app-statement/

The rou= ting directorate will, on request from the working group chair, perform an = =E2=80=9Cearly=E2=80=9D review of a draft before it is submitted for public= ation to the IESG. The early review can be performed at any time during the= draft=E2=80=99s lifetime as a working group document. The purpose of the e= arly review depends on the stage that the document has reached.

This= review request might have been marked as an Early review by mistake. The r= eview stands nevertheless.

For more information about the Routing Di= rectorate, please see http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir
Document: draft-ietf-ccamp-transport-nbi-app-statement
Reviewer: Dhruv = Dhody
Review Date: 2021-05-10
Intended Status: Informational

S= ummary:
I have some minor concerns about this document that I think shou= ld be resolved before it is submitted to the IESG.

Overview:
I ha= ve done a review of this I-D based on my understanding of ACTN and the rela= ted YANG models. Overall, I found the document difficult to review. I was s= crolling up and down the document and finally had to keep the document open= on multiple screens to cross-reference various figures to understand the t= ext. I wonder if there is a way to improve readability; can't think of = anything obvious... =C2=A0

Given the complexity of the subject matte= r, I do believe that the authors have done a good job. I hope the document = would be useful for the implementors.

I have some concerns about the= JSON Code which I have listed first, followed by other minor comments and = nits! =C2=A0

JSON Code Issues:
- This document provides a 'no= n-standard' JSON Code in the appendix and provides personal GitHub link= s on how to validate that JSON code. While the JSON code is common in the Y= ANG documents, this document introduces what looks like a new way to add co= mments. Question to John (as responsible AD): Does this approach has any IE= TF process issue? The authors have done a decent job in explaining the need= for it and how to handle it. =C2=A0
- I tried to set up the docker val= idate tool as per h= ttps://github.com/GianmarcoBruno/json-yang ; I was not able to make it = run and gave up after a while. :( The instruction on GitHub README.md does = not match with what's in the docker image include the options.
- JS= ON code is based on an older version of YANG models. It would be a good ide= a to update it to the latest. Related question: YANG models are normative r= eferences (which seems the right thing to do), so this document should be p= ublished together or after those YANG models are ready and thus some coordi= nation across WG is required. Again something for John to consider.
- JS= ON code should start with <CODE BEGINS>. Example - <CODE BEGINS>= ; file "mpi1-otn-topology.json", so that the json code can be str= ipped from the document. =C2=A0
- Should the GitHub repo mentioned in th= e appendix moved under CCAMP WG's GitHub? That would be giving some con= trol over the longtime validity of these URLs. Should they be added as refe= rences in the document as well. =C2=A0
- Update this -
=C2=A0 =3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D NOTE: '\\' line wrapping per BCP XXX (RFC = XXXX) =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
=C2=A0 It was published as an infor= mational RFC 8792, so remove the BCP and update the RFC number!
- On fir= st reading I did not understand the TTP ID naming convention used as per=C2=A0 "// __COMMENT__ tunnel-tp-id": "AN1-1 TTP-ID (1 ->= ;\
=C2=A0 =C2=A0\ 0x01 -> 'AQ=3D=3D')"
=C2=A0 Perhaps= it could be mentioned somewhere that AQ=3D=3D is the base64 representation= of 0x01. =C2=A0
- Appendix B.1.1, Figure 3 - "OTN Abstract Topolog= y exposed at MPI1 (MPI1 OTN Topology)" does not have AN1-8 but the JSO= N does. I think that might be a mistake?


Others:
- Title, &qu= ot;Transport Northbound Interface Applicability Statement" - not sure = about the title, it does not match with the content of the I-D. =C2=A0
-= Section 2, the definition of connection is not clear. The use of connectio= n/LSP multiple times is also distracting. Similarly "Link: A link, or = a physical link, ..." reads weird.=C2=A0 The note in section 2 needs t= o be handled at this stage. Note that [TE-TUTORIAL] is already marked infor= mative in the -12 version! =C2=A0
- Section 3.1, the notations need to e= xplain what {} means.
- Section 3.2 is better suited for the appendix as= the JSON code exists only in the appendix.
- Section 4.6 is not clear t= o me. Should one refer to RFC 8640, 8641, and 8650 as far as the datastore = update is concerned? Clarify the term 'alarm', do you mean YANG not= ification or RFC 8623? This section needs some work.
- Section 5.1.1, th= e text at the very end of this section about JSON code is much useful close= r to the code in the appendix.
- Section 5.1.4, we need to all add some = text to describe for merging of multiple instances of TE topology from the = same PNC. For example, the merging of OTN (Figure 3) and ETH (Figure 4) sho= uld lead to Network domain 1 topology in Figure 6.
- Section 5.2.1, is t= here any reference that can be provided about the handling of TTP and route= -object-include-exclude? Or is this document specifying how they should be = handled? This is applicable in other instances as well.
- Section 5.2.2,= "...abstracting S3-1 and S18-3 TTPs", please show S18-3 in the f= igure, otherwise, it is not clear which TTP it is!

Nits:
- Author= s address at the end of the document do not match the front
- Please mak= e abstract as the first section as per the style guide https://www.rfc-editor.org/rf= c/rfc7322.html#section-4
- It is expected to use https in the status= of the memo
- Expand on first use: ODU, EPL, EVPL, OTN, LSP, FC, STM-n,= L1CSM, L2SM, VN,
- Section 2, s/swith/switch/ ; s/failurs/failures/
= - Section 2, adding a reference to documents where these terms come from wo= uld help. It's already done for some terms!
- Section 4.2, s/[RFC845= 3] Provides/[RFC8453] provides/ ; s/PNcs/PNCs/
- Section 4.3, Ri (PKT -&= gt; foo) and Rj (foo -> PKT) does not align to the format in Section 3.1= . Should this be Ri [(PKT) -> foo] and Rj [foo -> (PKT)] instead?
= - Section 4.7, order of closing brackets is incorrect
OLD
=C2=A0 =C2= =A0 =C2=A0 R1 [(PKT) -> ODU2], S3[(ODU2]), S1 [(ODU2]), S2[(ODU2]),
= =C2=A0 =C2=A0 =C2=A0 S8 [(ODU2]), S12[(ODU2]), S15 [(ODU2]), S18[(ODU2]), R= 8 [ODU2 ->
=C2=A0 =C2=A0 =C2=A0 (PKT)]
NEW
=C2=A0 =C2=A0 =C2=A0= R1 [(PKT) -> ODU2], S3[(ODU2)], S1 [(ODU2)], S2 [(ODU2)],
=C2=A0 =C2= =A0 =C2=A0 S8 [(ODU2)], S12[(ODU2)], S15 [(ODU2)], S18[(ODU2)], R8 [ODU2 -&= gt;
=C2=A0 =C2=A0 =C2=A0 (PKT)]
- Section 5.2, s/models is (e.g., L1C= SM, L2SM, VN) is outside/models (e.g., L1CSM, L2SM, VN) is outside/
- Se= ction 5.2, The text says ".. (steps 2.1, 2.2 and 2.3 in Figure 7)"= ;. There are no steps 2.1, 2.2, and 2.3 in the figure.
- Section 5.2.1, = s/OUD2/ODU2/
- Section 5.2.1.1, s/terminating on AN-1 and AN1-2 LTPs/ter= minating on AN1-1 and AN1-2 LTPs/ =C2=A0
- Section 5.2.2, s/Appendix Err= or! Reference source not found./Appendix B.2.3/; s/OUD2/ODU2/; s/[ETH ->= (ODU)]/[ETH -> (ODU2)]/g;
- Section 5.2.2.1, s/Tunnel between the AN= 1-1 and AN1-2/Tunnel between the AN1-1 and AN1-8/
- Section 5.2.3, s/[ST= M-64 -> (ODU)]/[STM-64 -> (ODU2)]/
- Section 5.2.4, "..physic= al nodes S3, S1, S2, S31, S33, S15 and S18.." -> S34 is missing!!!<= br>- Section 5.3.2, s/S31 and D34/S31 and S34/ ; s/lin/link/ ;
- Appendi= x A, s/an Internet-Draft/this document/


Thanks!
Dhruv
--000000000000132f3a05c20c5679-- From nobody Wed May 12 23:50:09 2021 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FE6C3A2A52; Wed, 12 May 2021 23:50:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 9Ytk8wh-wqPr; Wed, 12 May 2021 23:49:59 -0700 (PDT) Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9B5CC3A2A51; Wed, 12 May 2021 23:49:59 -0700 (PDT) Received: from fraeml710-chm.china.huawei.com (unknown [172.18.147.201]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4Fghry0TL0z6rm0h; Thu, 13 May 2021 14:41:38 +0800 (CST) Received: from dggpemm100002.china.huawei.com (7.185.36.179) by fraeml710-chm.china.huawei.com (10.206.15.59) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2176.2; Thu, 13 May 2021 08:49:57 +0200 Received: from dggpemm500002.china.huawei.com (7.185.36.229) by dggpemm100002.china.huawei.com (7.185.36.179) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2176.2; Thu, 13 May 2021 14:49:55 +0800 Received: from dggpemm500002.china.huawei.com ([7.185.36.229]) by dggpemm500002.china.huawei.com ([7.185.36.229]) with mapi id 15.01.2176.012; Thu, 13 May 2021 14:49:55 +0800 From: Mach Chen To: "idr-chairs@ietf.org" , "draft-ietf-idr-bgp-open-policy.all@ietf.org" CC: "rtg-dir@ietf.org" , "idr@ietf.org" Thread-Topic: RtgDir Early review: draft-ietf-idr-bgp-open-policy-15.txt Thread-Index: AddHqF05jAuFF5QzTsaQPC2aQyKdxQ== Date: Thu, 13 May 2021 06:49:55 +0000 Message-ID: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.108.243.140] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: [RTG-DIR] RtgDir Early review: draft-ietf-idr-bgp-open-policy-15.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 May 2021 06:50:04 -0000 SGVsbG8NCg0KSSBoYXZlIGJlZW4gc2VsZWN0ZWQgdG8gZG8gYSByb3V0aW5nIGRpcmVjdG9yYXRl IOKAnGVhcmx54oCdIHJldmlldyBvZiB0aGlzIGRyYWZ0Lg0K4oCLaHR0cHM6Ly9kYXRhdHJhY2tl ci5pZXRmLm9yZy9kb2MvIGRyYWZ0LWlldGYtaWRyLWJncC1vcGVuLXBvbGljeSAvDQoNClRoZSBy b3V0aW5nIGRpcmVjdG9yYXRlIHdpbGwsIG9uIHJlcXVlc3QgZnJvbSB0aGUgd29ya2luZyBncm91 cCBjaGFpciwgcGVyZm9ybSBhbiDigJxlYXJseeKAnSByZXZpZXcgb2YgYSBkcmFmdCBiZWZvcmUg aXQgaXMgc3VibWl0dGVkIGZvciBwdWJsaWNhdGlvbiB0byB0aGUgSUVTRy4gVGhlIGVhcmx5IHJl dmlldyBjYW4gYmUgcGVyZm9ybWVkIGF0IGFueSB0aW1lIGR1cmluZyB0aGUgZHJhZnTigJlzIGxp ZmV0aW1lIGFzIGEgd29ya2luZyBncm91cCBkb2N1bWVudC4gVGhlIHB1cnBvc2Ugb2YgdGhlIGVh cmx5IHJldmlldyBkZXBlbmRzIG9uIHRoZSBzdGFnZSB0aGF0IHRoZSBkb2N1bWVudCBoYXMgcmVh Y2hlZC4NCg0KQXMgdGhpcyBkb2N1bWVudCBoYXMgYmVlbiBzZW50IHRvIElFU0cgZm9yIHB1Ymxp Y2F0aW9uLCBteSBmb2N1cyBmb3IgdGhlIHJldmlldyB3YXMgdG8gZGV0ZXJtaW5lIHdoZXRoZXIg dGhlIGRvY3VtZW50IGlzIHJlYWR5IHRvIGJlIHB1Ymxpc2hlZC4gUGxlYXNlIGNvbnNpZGVyIG15 IGNvbW1lbnRzIGFsb25nIHdpdGggdGhlIG90aGVyIGxhc3QgY2FsbCBjb21tZW50cy4NCg0KRG9j dW1lbnQ6IGRyYWZ0LWlldGYtaWRyLWJncC1vcGVuLXBvbGljeS0xNS50eHQNClJldmlld2VyOiBN YWNoIENoZW4NClJldmlldyBEYXRlOiAyMDIxLzA1LzEzDQpJbnRlbmRlZCBTdGF0dXM6IFN0YW5k YXJkcyBUcmFjaw0KDQpTdW1tYXJ5Og0KDQpUaGlzIGRvY3VtZW50IGlzIGJhc2ljYWxseSByZWFk eSBmb3IgcHVibGljYXRpb24sIGJ1dCBoYXMgbml0cyBhbmQgbWlub3IgY29uY2VybnMgdGhhdCBz aG91bGQgYmUgY29uc2lkZXJlZCBwcmlvciB0byBiZWluZyBzdWJtaXR0ZWQgdG8gdGhlIElFU0cu DQoNCkNvbW1lbnRzOg0KDQpTZWN0aW9uIDYuIA0KSXQgZG9lcyBub3Qgc3BlY2lmeSBob3cgYSBz cGVha2VyIGhhbmRsZSBhIHJvdXRlIHdpdGggT1RDIGF0dHJpYnV0ZSBidXQgdGhlIHNlbmRlcidz IHJvbGUgaXMgdW5rbm93bi4NCg0KDQpOaXRzOg0KDQpTZWN0aW9uIDIuIA0Kcy8gdGhlaXIgY3Vz dG9tZXJzL2l0cyBjdXN0b21lcnMNCg0KU2VjdGlvbiAzLg0Kcy9BbGxvd2VkIFJvbGUgdmFsdWVz L0FsbG93ZWQgUm9sZXMNCg0KU2VjdGlvbiA0Lg0KSXQncyBiZXR0ZXIgdG8gdXBkYXRlIHRoZSB0 YWJsZSBhcyBmb2xsb3dzOg0KDQogICAgICAgICAgICAgICAgICAgICAgKy0tLS0tLS0rLS0tLS0t LS0tLS0tLS0tLS0tLS0tKw0KICAgICAgICAgICAgICAgICAgICAgIHwgVmFsdWUgfCBSb2xlIG5h bWUgICAgICAgICAgIHwNCiAgICAgICAgICAgICAgICAgICAgICArLS0tLS0tLSstLS0tLS0tLS0t LS0tLS0tLS0tLS0rDQogICAgICAgICAgICAgICAgICAgICAgfCAgIDAgICB8IFNlbmRlciBpcyBQ cm92aWRlciAgfA0KICAgICAgICAgICAgICAgICAgICAgIHwgICAxICAgfCBTZW5kZXIgaXMgUlMg ICAgICAgIHwNCiAgICAgICAgICAgICAgICAgICAgICB8ICAgMiAgIHwgU2VuZGVyIGlzIFJTLWNs aWVudCB8DQogICAgICAgICAgICAgICAgICAgICAgfCAgIDMgICB8IFNlbmRlciBpcyBDdXN0b21l ciAgfA0KICAgICAgICAgICAgICAgICAgICAgIHwgICA0ICAgfCBTZW5kZXIgaXMgUGVlciAgICAg IHwNCiAgICAgICAgICAgICAgICAgICAgICB8IDUtMjU1ICB8IFJlc2VydmVkICAgICAgfCAgICAg ICAgICAgICAgICAgICAgICAgICANCiAgICAgICAgICAgICAgICAgICAgICArLS0tLS0tLSstLS0t LS0tLS0tLS0tLS0tLS0tLS0rDQoNClNlY3Rpb24gNS4NCk9MRDoNCiJJZiB0aGUgcm9sZSBvZiB0 aGUgcmVjZWl2aW5nIHNwZWFrZXIgZm9yIHRoZSBlQkdQIHNlc3Npb24gaW4NCiAgIGNvbnNpZGVy YXRpb24gaXMgaW5jbHVkZWQgaW4gVGFibGUgMSBhbmQgdGhlIG9ic2VydmVkIFJvbGUgcGFpciBp cw0KICAgbm90IGluIHRoZSBhYm92ZSB0YWJsZSwiDQpORVc6DQoNCiJJZiB0aGUgb2JzZXJ2ZWQg Um9sZSBwYWlyIGlzIG5vdCBpbiB0aGUgYWJvdmUgdGFibGUsIg0KDQpJTUhPLCBpdCdzIHJlZHVu ZGFudCB0byBpbmNsdWRlICJJZiB0aGUgcm9sZSBvZiB0aGUgcmVjZWl2aW5nIHNwZWFrZXIgZm9y IHRoZSBlQkdQIHNlc3Npb24gaW4gY29uc2lkZXJhdGlvbiBpcyBpbmNsdWRlZCBpbiBUYWJsZSAx IiwganVzdCBrZWVwIHRoZSBzZWNvbmQgaGFsZiBvZiB0aGUgc2VudGVuY2UgaXMgZW5vdWdoLg0K DQpTZWN0aW9uIDUuMQ0KDQpzL3NlbmQgYSBzZW5kIGEvc2VuZCBhLCB0aGVyZSBpcyBhIHJlZHVu ZGFudCAic2VuZCBhIi4NCg0KQmVzdCByZWdhcmRzLA0KTWFjaA0K From nobody Thu May 13 05:16:02 2021 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81AEA3A0E32 for ; Thu, 13 May 2021 05:16:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.647 X-Spam-Level: X-Spam-Status: No, score=-1.647 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=danielking-net.20150623.gappssmtp.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 CWRXZKwXE_dd for ; Thu, 13 May 2021 05:15:55 -0700 (PDT) Received: from mail-wr1-x432.google.com (mail-wr1-x432.google.com [IPv6:2a00:1450:4864:20::432]) (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 586E43A0E2E for ; Thu, 13 May 2021 05:15:54 -0700 (PDT) Received: by mail-wr1-x432.google.com with SMTP id v12so26670413wrq.6 for ; Thu, 13 May 2021 05:15:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=danielking-net.20150623.gappssmtp.com; s=20150623; h=sender:from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-language:thread-index; bh=7j9vWGrqGKgiFL9JkivoDfYePtl2TnOAcixvfe+IVBg=; b=lDZieQ9bNyuYvmu0MYCK3g5xoLoFcq29OeaMzzzOb/XC+xEhX/tshRDsbzfXoZVBeF jrDyk9HGptxkHiMXm32MksQW0Wy+taLjSTCSRtghBMJApg+qdQ14tl5ArN3uk2vJ6G02 MQVLEuHTL/I3afaihT4xp/55u/Dd4FUhMsO9dlYab2GKj4mub/pWCDfHrBsyGjxU4ptD vQaWBvcIpPeq/iO6wbakGkPOMQ57SbWOaqG3jTChxmtjQnwIEkFCVLHqPl+9IwSgp54a 2lwTaXDOUmuyGFnP3liEJtMFpibkXZtJaCNjvqzqsvErsBByL7nn4Se4DdqVo08TLh7b eNgg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:from:to:cc:references:in-reply-to:subject :date:message-id:mime-version:content-language:thread-index; bh=7j9vWGrqGKgiFL9JkivoDfYePtl2TnOAcixvfe+IVBg=; b=ClRioqePtyecd1iyYk+JTtpk13IXUii6ouFgt/JVz2xhWiVOeWH1gow4UjWzxDnxo0 qTqTyWADoBt9OYTVMJjtcr4pIoRuynVWzJ9zIBrKV3bRPJj+5uUJiCBaUJtHXPqc7++5 YNhp5mAjRH+HDeukA6hDCM3ZrbNuypQGWfULxC9DgNQotBSuvQFQ3zKqqTkk+KTIefIx HT6jkUVCONd3AJjo2PHlmn/otqYs7Bs1tFUV3weLgmh04zI/IcW7e9sMsranIwMw6rnD ICHXuHkMi3xCxtbjQLT8XHSaMY7c/NH433bkmA3+NXh9TuoWwxwuiODS60trE9UIcCMV HN/A== X-Gm-Message-State: AOAM5339rXCHMV5LIq8brWCx73AerBkG/L1vywNbh3wHf/sEBr5R6CvI dG3QVCmscueiyylowsZZ8ukrhg== X-Google-Smtp-Source: ABdhPJwjeNwO/lyUDmFZq2edIX7YoGS38IzyYqhDdZj/PMZb7u4tVOTDNqdeXbITu9dDkBL+EPYoIQ== X-Received: by 2002:adf:e44e:: with SMTP id t14mr52340077wrm.310.1620908151850; Thu, 13 May 2021 05:15:51 -0700 (PDT) Received: from CIPHER ([2a00:23c7:108:9201:89ea:c7e3:288e:cdac]) by smtp.gmail.com with ESMTPSA id s7sm8311655wmh.35.2021.05.13.05.15.50 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 13 May 2021 05:15:51 -0700 (PDT) Sender: Daniel King X-Google-Original-Sender: From: To: "'Dhruv Dhody'" , "'Dhruv Dhody'" Cc: , "'CCAMP'" , References: <162073267819.27623.14933803198192582361@ietfa.amsl.com> In-Reply-To: Date: Thu, 13 May 2021 13:15:49 +0100 Message-ID: <00c401d747f1$b66f8010$234e8030$@olddog.co.uk> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00C5_01D747FA.1834AB60" X-Mailer: Microsoft Outlook 16.0 Content-Language: en-gb Thread-Index: AQGpr3r/G12dcCxzp2aYkMlIhCAingF1Gb9YqzDbQzA= Archived-At: Subject: Re: [RTG-DIR] Rtgdir early review of draft-ietf-ccamp-transport-nbi-app-statement-12 X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 May 2021 12:16:01 -0000 This is a multipart message in MIME format. ------=_NextPart_000_00C5_01D747FA.1834AB60 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Dhruv,=20 =20 Thanks very much for the detailed review! The comments and suggestions = are most welcome.=20 =20 Re: Draft Naming=20 =20 Let me chat with the co-authors and get back to you and the WG with a = response.=20 =20 For the other items, we will address in the next version.=20 =20 BR, Dan.=20 =20 From: Dhruv Dhody =20 Sent: 11 May 2021 12:38 To: Dhruv Dhody Cc: rtg-dir@ietf.org; CCAMP (ccamp@ietf.org) ; = draft-ietf-ccamp-transport-nbi-app-statement.all@ietf.org Subject: Re: [RTG-DIR] Rtgdir early review of = draft-ietf-ccamp-transport-nbi-app-statement-12 =20 Hi,=20 The formatting seems to be off when I uploaded the text file in the = review tool. It looks okay in the datatracker : = https://datatracker.ietf.org/doc/review-ietf-ccamp-transport-nbi-app-stat= ement-12-rtgdir-early-dhody-2021-05-11/ ; seems to be an issue with the = email then!=20 =20 I am pasting the review again, hoping this works! =20 =3D=3D=3D=3D=3D=20 =20 Subject:RtgDir Early review: = draft-ietf-ccamp-transport-nbi-app-statement Hello I have been selected to do a routing directorate =E2=80=9Cearly=E2=80=9D = review of this draft. https://datatracker.ietf.org/doc/draft-ietf-ccamp-transport-nbi-app-state= ment/ The routing directorate will, on request from the working group chair, = perform an =E2=80=9Cearly=E2=80=9D 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=E2=80=99s lifetime as a working group = document. The purpose of the early review depends on the stage that the = document has reached. This review request might have been marked as an Early review by = mistake. The review stands nevertheless. For more information about the Routing Directorate, please see = http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir Document: draft-ietf-ccamp-transport-nbi-app-statement Reviewer: Dhruv Dhody Review Date: 2021-05-10 Intended Status: Informational Summary: I have some minor concerns about this document that I think should be = resolved before it is submitted to the IESG. Overview: I have done a review of this I-D based on my understanding of ACTN and = the related YANG models. Overall, I found the document difficult to = review. I was scrolling up and down the document and finally had to keep = the document open on multiple screens to cross-reference various figures = to understand the text. I wonder if there is a way to improve = readability; can't think of anything obvious... =20 Given the complexity of the subject matter, I do believe that the = authors have done a good job. I hope the document would be useful for = the implementors. I have some concerns about the JSON Code which I have listed first, = followed by other minor comments and nits! =20 JSON Code Issues: - This document provides a 'non-standard' JSON Code in the appendix and = provides personal GitHub links on how to validate that JSON code. While = the JSON code is common in the YANG documents, this document introduces = what looks like a new way to add comments. Question to John (as = responsible AD): Does this approach has any IETF process issue? The = authors have done a decent job in explaining the need for it and how to = handle it. =20 - I tried to set up the docker validate tool as per = https://github.com/GianmarcoBruno/json-yang ; I was not able to make it = run and gave up after a while. :( The instruction on GitHub README.md = does not match with what's in the docker image include the options.=20 - JSON code is based on an older version of YANG models. It would be a = good idea to update it to the latest. Related question: YANG models are = normative references (which seems the right thing to do), so this = document should be published together or after those YANG models are = ready and thus some coordination across WG is required. Again something = for John to consider. - JSON code should start with . Example - = file "mpi1-otn-topology.json", so that the json code can be stripped = from the document. =20 - Should the GitHub repo mentioned in the appendix moved under CCAMP = WG's GitHub? That would be giving some control over the longtime = validity of these URLs. Should they be added as references in the = document as well. =20 - Update this - =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D NOTE: '\\' line wrapping per BCP XXX = (RFC XXXX) =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D It was published as an informational RFC 8792, so remove the BCP and = update the RFC number! - On first reading I did not understand the TTP ID naming convention = used as per "// __COMMENT__ tunnel-tp-id": "AN1-1 TTP-ID (1 ->\ \ 0x01 -> 'AQ=3D=3D')" Perhaps it could be mentioned somewhere that AQ=3D=3D is the base64 = representation of 0x01. =20 - Appendix B.1.1, Figure 3 - "OTN Abstract Topology exposed at MPI1 = (MPI1 OTN Topology)" does not have AN1-8 but the JSON does. I think that = might be a mistake? Others: - Title, "Transport Northbound Interface Applicability Statement" - not = sure about the title, it does not match with the content of the I-D. =20 - Section 2, the definition of connection is not clear. The use of = connection/LSP multiple times is also distracting. Similarly "Link: A = link, or a physical link, ..." reads weird. The note in section 2 needs = to be handled at this stage. Note that [TE-TUTORIAL] is already marked = informative in the -12 version! =20 - Section 3.1, the notations need to explain what {} means. - Section 3.2 is better suited for the appendix as the JSON code exists = only in the appendix. - Section 4.6 is not clear to me. Should one refer to RFC 8640, 8641, = and 8650 as far as the datastore update is concerned? Clarify the term = 'alarm', do you mean YANG notification or RFC 8623? This section needs = some work. - Section 5.1.1, the text at the very end of this section about JSON = code is much useful closer to the code in the appendix. - Section 5.1.4, we need to all add some text to describe for merging of = multiple instances of TE topology from the same PNC. For example, the = merging of OTN (Figure 3) and ETH (Figure 4) should lead to Network = domain 1 topology in Figure 6. - Section 5.2.1, is there any reference that can be provided about the = handling of TTP and route-object-include-exclude? Or is this document = specifying how they should be handled? This is applicable in other = instances as well. - Section 5.2.2, "...abstracting S3-1 and S18-3 TTPs", please show S18-3 = in the figure, otherwise, it is not clear which TTP it is! Nits: - Authors address at the end of the document do not match the front - Please make abstract as the first section as per the style guide = https://www.rfc-editor.org/rfc/rfc7322.html#section-4 - It is expected to use https in the status of the memo - Expand on first use: ODU, EPL, EVPL, OTN, LSP, FC, STM-n, L1CSM, L2SM, = VN, - Section 2, s/swith/switch/ ; s/failurs/failures/ - Section 2, adding a reference to documents where these terms come from = would help. It's already done for some terms! - Section 4.2, s/[RFC8453] Provides/[RFC8453] provides/ ; s/PNcs/PNCs/ - Section 4.3, Ri (PKT -> foo) and Rj (foo -> PKT) does not align to the = format in Section 3.1. Should this be Ri [(PKT) -> foo] and Rj [foo -> = (PKT)] instead? - Section 4.7, order of closing brackets is incorrect OLD R1 [(PKT) -> ODU2], S3[(ODU2]), S1 [(ODU2]), S2[(ODU2]), S8 [(ODU2]), S12[(ODU2]), S15 [(ODU2]), S18[(ODU2]), R8 [ODU2 -> (PKT)] NEW R1 [(PKT) -> ODU2], S3[(ODU2)], S1 [(ODU2)], S2 [(ODU2)], S8 [(ODU2)], S12[(ODU2)], S15 [(ODU2)], S18[(ODU2)], R8 [ODU2 -> (PKT)] - Section 5.2, s/models is (e.g., L1CSM, L2SM, VN) is outside/models = (e.g., L1CSM, L2SM, VN) is outside/ - Section 5.2, The text says ".. (steps 2.1, 2.2 and 2.3 in Figure 7)". = There are no steps 2.1, 2.2, and 2.3 in the figure. - Section 5.2.1, s/OUD2/ODU2/ - Section 5.2.1.1, s/terminating on AN-1 and AN1-2 LTPs/terminating on = AN1-1 and AN1-2 LTPs/ =20 - Section 5.2.2, s/Appendix Error! Reference source not found./Appendix = B.2.3/; s/OUD2/ODU2/; s/[ETH -> (ODU)]/[ETH -> (ODU2)]/g; - Section 5.2.2.1, s/Tunnel between the AN1-1 and AN1-2/Tunnel between = the AN1-1 and AN1-8/ - Section 5.2.3, s/[STM-64 -> (ODU)]/[STM-64 -> (ODU2)]/ - Section 5.2.4, "..physical nodes S3, S1, S2, S31, S33, S15 and S18.." = -> S34 is missing!!! - Section 5.3.2, s/S31 and D34/S31 and S34/ ; s/lin/link/ ; - Appendix A, s/an Internet-Draft/this document/ Thanks!=20 Dhruv ------=_NextPart_000_00C5_01D747FA.1834AB60 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Hi Dhruv,

 

Thanks very = much for the detailed review! The comments and suggestions are most = welcome.

 

Re: Draft = Naming

 

Let me chat = with the co-authors and get back to you and the WG with a response. =

 

For the = other items, we will address in the next version. =

 

BR, Dan. =

 

From: Dhruv Dhody = <dhruv.ietf@gmail.com>
Sent: 11 May 2021 = 12:38
To: Dhruv Dhody <dd@dhruvdhody.com>
Cc: = rtg-dir@ietf.org; CCAMP (ccamp@ietf.org) <ccamp@ietf.org>; = draft-ietf-ccamp-transport-nbi-app-statement.all@ietf.org
Subject:<= /b> Re: [RTG-DIR] Rtgdir early review of = draft-ietf-ccamp-transport-nbi-app-statement-12

 

Hi,

The formatting seems to be off = when I uploaded the text file in the review tool. It = looks okay in the datatracker : https://datatracker.ietf= .org/doc/review-ietf-ccamp-transport-nbi-app-statement-12-rtgdir-early-dh= ody-2021-05-11/ ; seems to be an issue with the email = then! 

 

I am pasting the review again, hoping this = works!

 

=3D=3D=3D=3D=3D 

=

 

Subject:RtgDir Early = review: = draft-ietf-ccamp-transport-nbi-app-statement

Hello

I have = been selected to do a routing directorate =E2=80=9Cearly=E2=80=9D review = of this draft.
https://datatracker.ietf.org/doc/draft-ietf-ccamp-transpor= t-nbi-app-statement/

The routing directorate will, on request = from the working group chair, perform an =E2=80=9Cearly=E2=80=9D 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=E2=80=99s lifetime = as a working group document. The purpose of the early review depends on = the stage that the document has reached.

This review request = might have been marked as an Early review by mistake. The review stands = nevertheless.

For more information about the Routing Directorate, = please see http://trac= .tools.ietf.org/area/rtg/trac/wiki/RtgDir

Document: = draft-ietf-ccamp-transport-nbi-app-statement
Reviewer: Dhruv = Dhody
Review Date: 2021-05-10
Intended Status: = Informational

Summary:
I have some minor concerns about this = document that I think should be resolved before it is submitted to the = IESG.

Overview:
I have done a review of this I-D based on my = understanding of ACTN and the related YANG models. Overall, I found the = document difficult to review. I was scrolling up and down the document = and finally had to keep the document open on multiple screens to = cross-reference various figures to understand the text. I wonder if = there is a way to improve readability; can't think of anything = obvious...  

Given the complexity of the subject matter, I = do believe that the authors have done a good job. I hope the document = would be useful for the implementors.

I have some concerns about = the JSON Code which I have listed first, followed by other minor = comments and nits!  

JSON Code Issues:
- This document = provides a 'non-standard' JSON Code in the appendix and provides = personal GitHub links on how to validate that JSON code. While the JSON = code is common in the YANG documents, this document introduces what = looks like a new way to add comments. Question to John (as responsible = AD): Does this approach has any IETF process issue? The authors have = done a decent job in explaining the need for it and how to handle it. =  
- I tried to set up the docker validate tool as per https://github.com/G= ianmarcoBruno/json-yang ; I was not able to make it run and gave up = after a while. :( The instruction on GitHub README.md does not match = with what's in the docker image include the options.
- JSON code is = based on an older version of YANG models. It would be a good idea to = update it to the latest. Related question: YANG models are normative = references (which seems the right thing to do), so this document should = be published together or after those YANG models are ready and thus some = coordination across WG is required. Again something for John to = consider.
- JSON code should start with <CODE BEGINS>. Example = - <CODE BEGINS> file "mpi1-otn-topology.json", so that = the json code can be stripped from the document.  
- Should the = GitHub repo mentioned in the appendix moved under CCAMP WG's GitHub? = That would be giving some control over the longtime validity of these = URLs. Should they be added as references in the document as well. =  
- Update this -
  =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D NOTE: = '\\' line wrapping per BCP XXX (RFC XXXX) = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
  It was published as an = informational RFC 8792, so remove the BCP and update the RFC = number!
- On first reading I did not understand the TTP ID naming = convention used as per
  "// __COMMENT__ = tunnel-tp-id": "AN1-1 TTP-ID (1 ->\
   \ 0x01 = -> 'AQ=3D=3D')"
  Perhaps it could be mentioned = somewhere that AQ=3D=3D is the base64 representation of 0x01. =  
- Appendix B.1.1, Figure 3 - "OTN Abstract Topology = exposed at MPI1 (MPI1 OTN Topology)" does not have AN1-8 but the = JSON does. I think that might be a mistake?


Others:
- = Title, "Transport Northbound Interface Applicability = Statement" - not sure about the title, it does not match with the = content of the I-D.  
- Section 2, the definition of connection = is not clear. The use of connection/LSP multiple times is also = distracting. Similarly "Link: A link, or a physical link, ..." = reads weird.  The note in section 2 needs to be handled at this = stage. Note that [TE-TUTORIAL] is already marked informative in the -12 = version!  
- Section 3.1, the notations need to explain what {} = means.
- Section 3.2 is better suited for the appendix as the JSON = code exists only in the appendix.
- Section 4.6 is not clear to me. = Should one refer to RFC 8640, 8641, and 8650 as far as the datastore = update is concerned? Clarify the term 'alarm', do you mean YANG = notification or RFC 8623? This section needs some work.
- Section = 5.1.1, the text at the very end of this section about JSON code is much = useful closer to the code in the appendix.
- Section 5.1.4, we need = to all add some text to describe for merging of multiple instances of TE = topology from the same PNC. For example, the merging of OTN (Figure 3) = and ETH (Figure 4) should lead to Network domain 1 topology in Figure = 6.
- Section 5.2.1, is there any reference that can be provided about = the handling of TTP and route-object-include-exclude? Or is this = document specifying how they should be handled? This is applicable in = other instances as well.
- Section 5.2.2, "...abstracting S3-1 = and S18-3 TTPs", please show S18-3 in the figure, otherwise, it is = not clear which TTP it is!

Nits:
- Authors address at the end = of the document do not match the front
- Please make abstract as the = first section as per the style guide https://ww= w.rfc-editor.org/rfc/rfc7322.html#section-4
- It is expected to = use https in the status of the memo
- Expand on first use: ODU, EPL, = EVPL, OTN, LSP, FC, STM-n, L1CSM, L2SM, VN,
- Section 2, = s/swith/switch/ ; s/failurs/failures/
- Section 2, adding a reference = to documents where these terms come from would help. It's already done = for some terms!
- Section 4.2, s/[RFC8453] Provides/[RFC8453] = provides/ ; s/PNcs/PNCs/
- Section 4.3, Ri (PKT -> foo) and Rj = (foo -> PKT) does not align to the format in Section 3.1. Should this = be Ri [(PKT) -> foo] and Rj [foo -> (PKT)] instead?
- Section = 4.7, order of closing brackets is incorrect
OLD
    =   R1 [(PKT) -> ODU2], S3[(ODU2]), S1 [(ODU2]), = S2[(ODU2]),
      S8 [(ODU2]), S12[(ODU2]), S15 = [(ODU2]), S18[(ODU2]), R8 [ODU2 ->
      = (PKT)]
NEW
      R1 [(PKT) -> ODU2], S3[(ODU2)], = S1 [(ODU2)], S2 [(ODU2)],
      S8 [(ODU2)], = S12[(ODU2)], S15 [(ODU2)], S18[(ODU2)], R8 [ODU2 ->
    =   (PKT)]
- Section 5.2, s/models is (e.g., L1CSM, L2SM, VN) is = outside/models (e.g., L1CSM, L2SM, VN) is outside/
- Section 5.2, The = text says ".. (steps 2.1, 2.2 and 2.3 in Figure 7)". There are = no steps 2.1, 2.2, and 2.3 in the figure.
- Section 5.2.1, = s/OUD2/ODU2/
- Section 5.2.1.1, s/terminating on AN-1 and AN1-2 = LTPs/terminating on AN1-1 and AN1-2 LTPs/  
- Section 5.2.2, = s/Appendix Error! Reference source not found./Appendix B.2.3/; = s/OUD2/ODU2/; s/[ETH -> (ODU)]/[ETH -> (ODU2)]/g;
- Section = 5.2.2.1, s/Tunnel between the AN1-1 and AN1-2/Tunnel between the AN1-1 = and AN1-8/
- Section 5.2.3, s/[STM-64 -> (ODU)]/[STM-64 -> = (ODU2)]/
- Section 5.2.4, "..physical nodes S3, S1, S2, S31, = S33, S15 and S18.." -> S34 is missing!!!
- Section 5.3.2, = s/S31 and D34/S31 and S34/ ; s/lin/link/ ;
- Appendix A, s/an = Internet-Draft/this document/


Thanks! =
Dhruv

------=_NextPart_000_00C5_01D747FA.1834AB60-- From nobody Wed May 26 07:50:16 2021 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 741D63A30E6; Wed, 26 May 2021 07:50:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.797 X-Spam-Level: X-Spam-Status: No, score=-2.797 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.698, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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=juniper.net header.b=PKIT7XWJ; dkim=pass (1024-bit key) header.d=juniper.net header.b=MlPrwlwY 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 r2njUaOYuXmK; Wed, 26 May 2021 07:50:08 -0700 (PDT) Received: from mx0a-00273201.pphosted.com (mx0a-00273201.pphosted.com [208.84.65.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 519B13A30E3; Wed, 26 May 2021 07:50:04 -0700 (PDT) Received: from pps.filterd (m0108159.ppops.net [127.0.0.1]) by mx0a-00273201.pphosted.com (8.16.0.43/8.16.0.43) with SMTP id 14QEnB49021684; Wed, 26 May 2021 07:50:03 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : to : cc : subject : date : message-id : content-type : content-transfer-encoding : mime-version; s=PPS1017; bh=vcZ/rEdCwHIDbcCkILvLT7y/cblm8Gt/7JA7V+5eJ0Y=; b=PKIT7XWJaEslFubs76Wxhlia13K/19OI97dq2gXy57qlLoYqtM1G8EozQMQlt86YfkP5 NSBem/9o7dSuX+QzWbHR1AVuPsrDDO8piRZ/2y1JBEmJgJs0HGB5KTmzG9Bv8fL3KxkF u9kgFG0OicBpIASOd0AkUQ+nTkWax6V8lyX3f9AlCl91p/T2vVbRSpUdZ9DMpwVflz/n VYdp5keByol8L+fTiN+Z3boF4APpwaEIktcO80k75m6DoMnWBkcWSWAKbEhew1WVKcB8 76laxhyO+Wsv8+xi9Vo+iAQjJ9wQZCNSHs0R+hb0EvbIjzuxP49+E7ELew/QAmar8sm0 sA== Received: from nam12-mw2-obe.outbound.protection.outlook.com (mail-mw2nam12lp2040.outbound.protection.outlook.com [104.47.66.40]) by mx0a-00273201.pphosted.com with ESMTP id 38sken8m70-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 26 May 2021 07:50:03 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=GL/PC0hlQajCu41sEemboCfQAjQOBhV/oHmkpyAGlgDXvGYD4AKc9YCoZLSxZiStsNAA0K1lVzhMfrQX1tea5JJ2Rq9RucnbFrmUzIVPClEdkw5qQmQssbnjEaT825HZCf9FA4FUVnpxLqppOhWPEUe1Ki2IwqWSx5J8qGtTGkienFXiXUEAv2QUBd+8baXzNqWagRsCl7Xi8xb0Az+KCWGDk9Itm9d7c/f5d9yyeo/TGOULLMjGpudX2c1cGnS9F5R3A0O9MWwYatMlJpkURpLMwY6UMFg/7gjMzCNkw9zbjO1REgKOvXDNjSv103KS69V+zupdZ2/hS6/gqe/bqg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=vcZ/rEdCwHIDbcCkILvLT7y/cblm8Gt/7JA7V+5eJ0Y=; b=ecN6r9NkGc1PH/zcwShI75Gfhce97bq9Oz4wSgL++7uYhdY8LdabQZGT/IfjUFOajynQ07kadu96+zYSif8YuJIWCEQrmKH0UjXI/9wNl+LEMkX7fSqTCqC3DLbACVxKJWJrC1x8+WSOfMw1wnFb/v91qLtRWuJHzxE5JWM7ziMzwcji8bdHgnM8tBD5CR/8jNQJtQoZZsOeVGdsXgXi0Zo8RRgrTz7pSTmzgMt/cER+AzzF+YWi2Mips5D6EM8OZ9CbIk+KSek73MozHYBXgQ+S6uL3jryUCi3NWNhCLF2JlVE0/KRVc6Vt99UtDcr+wxVOeV9wHO7v1w7Sp68IFw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=juniper.net; dmarc=pass action=none header.from=juniper.net; dkim=pass header.d=juniper.net; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=vcZ/rEdCwHIDbcCkILvLT7y/cblm8Gt/7JA7V+5eJ0Y=; b=MlPrwlwYyWA+PrbuU20eIgwapMZZxiwnI97/X1t2rqAuoYNUk7eH0QrCla0Iv/OOoGx1q3/J1y17Zt9uEDq4f8KnJS4Lv2joMZ5g2VWCeOmzj5eNUXZ7oRVvOcpqmjkISUDvGe6ZDbBdWbAtW8eO5jpKckRM2n5ys9CG44Fb0EQ= Received: from BY3PR05MB8081.namprd05.prod.outlook.com (2603:10b6:a03:366::15) by BYAPR05MB5224.namprd05.prod.outlook.com (2603:10b6:a03:9b::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4173.16; Wed, 26 May 2021 14:50:02 +0000 Received: from BY3PR05MB8081.namprd05.prod.outlook.com ([fe80::9195:d339:76df:f757]) by BY3PR05MB8081.namprd05.prod.outlook.com ([fe80::9195:d339:76df:f757%3]) with mapi id 15.20.4195.009; Wed, 26 May 2021 14:50:01 +0000 From: John E Drake To: "masque-wg-chairs@ietf.org" , "draft-ietf-masque-ip-proxy-reqs@ietf.org" CC: "rtg-dir@ietf.org" , "masque-wg-mailing-list@ietf.org" Thread-Topic: RtgDir Early review: draft-ietf-masque-ip-proxy-reqs-02.txt Thread-Index: AddSPQkdLoWbe410Tj+ZDBK8L667ow== Date: Wed, 26 May 2021 14:50:01 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 11.6.100.41 dlp-reaction: no-action msip_labels: MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Enabled=true; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_SetDate=2021-05-26T14:50:00Z; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Method=Standard; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Name=0633b888-ae0d-4341-a75f-06e04137d755; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_SiteId=bea78b3c-4cdb-4130-854a-1d193232e5f4; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_ActionId=73dd636a-c239-447a-8c8d-d6c6c14108f7; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_ContentBits=2 authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=juniper.net; x-originating-ip: [96.235.63.100] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: e41bf993-9977-41f6-f259-08d920558aa0 x-ms-traffictypediagnostic: BYAPR05MB5224: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: gInPe+RgPUFpudrXftX+WXmsw/eLrTyyYT3HFDIhZOpJ8sYQCypcOkbV1qijAzCGGVjZT+ONcoyyNaBkbW8WqYM1WksP+XEiLmq3IC+QBoXV13Rr71GC4a9W3JvJj8gNUlxkwJp0ef+6SPqG+4oKSVMuNwfpbR+SJyerK4VIzfW6NgyahpNCzWu1lymgrkUE1aDmcG3oLkoR5Yd3SWjvLfMmDe9vKNmDt07jkwAgEQd8dvT5bVwZIxhJT0fSZ5ssO7Dwm32vRQWIWUCtvptjdbBX+TaoYQrN17qk2fVB6+ceHuW0jqF9CeC6DrR05zeas2xz0vczn6MKqlBs85QTgCya6FQy93BYPBVva0WAbO8XS6sTEtkXljGDyEuy2vzifx9mUkjNzv4jZ71gDw+YRzvJoHDt+TkEIhx0cGLVPNY8Ty48W/kPM2KTgqQeoWqVjk6rkdXpFV9C7ssHNaykGef6hC3Z7AfAWMu+6QhN6X9V1S8oPzWwS6awkFluDntQBv9Eyq4s+fwe9hxjNTaLYX5axgEz2bbhY1xbIhx5QL/7CE+muFokFuM4S8EujFGpeMqtuLM4bIg9+bFg3neAZVg22DQsb3fSg6t3EuCvS2oKr3UdJ4aVcOBeQ+8aebhKeIB2db9zyFGIGfQaWtvkl84gHoFYYf1sqRQXJav3jk4z/Ha5faNwGyHbAGmWpdyD8RKFlt7gqt1VE0nvUIny9g== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BY3PR05MB8081.namprd05.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(396003)(376002)(346002)(39860400002)(136003)(54906003)(8936002)(4743002)(478600001)(66556008)(33656002)(4744005)(7696005)(6506007)(316002)(26005)(5660300002)(110136005)(2906002)(76116006)(9686003)(122000001)(186003)(71200400001)(38100700002)(66446008)(55016002)(4326008)(450100002)(86362001)(52536014)(83380400001)(66946007)(64756008)(66476007)(8676002); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: =?utf-8?B?UGtscUZRcXdkZWpOWGFXWnhEajdoSncydURCS3E0U0VOdm5rU25QNjRiMlR6?= =?utf-8?B?UWpMc1hMY2JURFZ6bjF1RGE2ZjRETURFKzZVMlFZRnBaSHZIM296YkFXWGt6?= =?utf-8?B?amdjazJqQXlLa3hKK3lvZW5pZjFXQnRxdVVHcGd0YTlVZVAxVmRxNnpabEdS?= =?utf-8?B?N1VER3FlRnRJM2dVVi9XMG4wQnFQVjlrVHZQbXZ1cjd1TFhDOTNUZ01lRkds?= =?utf-8?B?YWx0WWN3Um5ZS3ZZRnhvSS8zYU4zeDJBa0svcUFYcEhuK1lBNndqMWFJd1py?= =?utf-8?B?MnR6WjRmZWhuZzE2WDJSSm1pUDBJUFRMcGhVZnloSzc5SmEvUUlCK05GSVBM?= =?utf-8?B?L1JBZ3dqVERyNmtQRWdXMmFITGNQeTNudDJHR2JjSTNHd1NRQm5ORjM2QS9n?= =?utf-8?B?S0VFdzNxTDhDeFBPc08wQ1pFVUVJcmRPRUFYMnpnUStVamFkUzhubGtvb0Z6?= =?utf-8?B?emdYUjhKUVJiVlpWa3MxTm1JTHRNemFLcU1sR3J4MVZoWFlDVDhuQmxJQ1h5?= =?utf-8?B?M0ZCVnpHY05nSlFCVzRkWjgzQzJRNGdKNzY4U1RSaVBidUFBdStYUDh0VFp1?= =?utf-8?B?ajJDNTMzaE5pL1hTc09BcXpwck9BYlBoZVpOOFhNMnhHL2ROdkZwZ1U0MWFr?= =?utf-8?B?a2pNOE1tQzFTTEtJZU4rRVcrZk16QUlMbkNsVzRFK0g2ODArMCtrdk40TlJK?= =?utf-8?B?NlcrMDMyVGoyTGw1cWFBaFpaTXZ2akpuNDJnbTVJVStlY2ZDTVpHRThyeFlZ?= =?utf-8?B?YWYzVUQvZkZNTDB2azhRWkNKM0lzR2t4Q2NrczdGVzd2cVlScEJMclBwU21Q?= =?utf-8?B?cW1iVDlLSHgrOE1TOExxMUlxdDhEWW9ZNFExd0RuM0dIaTNHTWJ5aVBoclpl?= =?utf-8?B?ZWRLUmV3RWxlcG44QUdyL0YzeEZ1RUx2bk5KWnFIYjRTUTlOZmdaQVA5YVpR?= =?utf-8?B?UHkzLzVTRWdNcXEvZVB4elMrSVJpd1pCaG5MYVFMejNoaW9rVHhkK1hkN09U?= =?utf-8?B?RHlBb1YwelhRSkNoRkNJd0MzcnYyanVjTVhrSXByZGZmZCtiODhWSzZ0Qnc1?= =?utf-8?B?OG5TSnpDS0pRSHVmV2NoTnd5NExZZ2xqVFVHUTZMVnVzV1Z2eUhmdm5jTWU0?= =?utf-8?B?QzVsNll5clc3MTNxR2F1OFpWMUxGUVhWOXlDOWdFRjF4L1daaU9YUDdOM3lk?= =?utf-8?B?a3F2ZUhKc05ZcExPaWVja1JRNnJ5T1ZyWUFlTFBvS0llVGZjWERaRmJPYml0?= =?utf-8?B?dVJKdllzMFdwNWxIVy9qSUJZaHJXa3lrRTlGS1NnTjVPbmtWR3N1SzBTUXZK?= =?utf-8?B?WkpYeVE1VWFKOGY5VEF0MWxrL2hkTmFkWktOQ25KamprNXhrOW9wd2xjN0dy?= =?utf-8?B?ZWIzTmtQMW9KcTFwMU1WT2V4czBVY282Vnkvb1dNZUFCS2FOWXB1SUQ2aEdr?= =?utf-8?B?TUZ4QkRtK1J0d2FRbnpncHhIWlczVHc0T3hua3k2RWNqSkZvRjNDajE4cU85?= =?utf-8?B?ajdXZ0tWci9VRHBTU2lNMFZkWmtaWm5HU3A2REZITEIwWllPVmZOMFBSVjlx?= =?utf-8?B?enpSSHhCRlY3SUh3K1BsVkg3S0dZY0NVcnlmTHVhR2loNk8rRmVaY2VXS0hl?= =?utf-8?B?ZVY0cDJ3b1F0UTNtMEIwTEF5dm5DQ3hRTFVNQUtkSXZXRDZsRnFUQUhWNU84?= =?utf-8?B?U2RlSG0yU0piVXZCSGVubUFRVTZHd0RwZERRMkMzb2ZrSGcxT0NDQ3VWRW9X?= =?utf-8?Q?w/to5B9g+IaSKV6BMbg5ur4akwIxE+CXh8mYlEH?= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BY3PR05MB8081.namprd05.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: e41bf993-9977-41f6-f259-08d920558aa0 X-MS-Exchange-CrossTenant-originalarrivaltime: 26 May 2021 14:50:01.8075 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: PwvYNSyHbDvziN8whESHG90mqKOk4i2kzCHIfX4n688nFvMNY24dWvbCMirTjHsayizLFeK+9d897JYu0f4LHw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR05MB5224 X-Proofpoint-ORIG-GUID: 3gQYVx8ncE1Qnr0li3yOAlEJDkBg57jM X-Proofpoint-GUID: 3gQYVx8ncE1Qnr0li3yOAlEJDkBg57jM X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.391, 18.0.761 definitions=2021-05-26_09:2021-05-26, 2021-05-26 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 clxscore=1011 adultscore=0 malwarescore=0 impostorscore=0 mlxscore=0 bulkscore=0 priorityscore=1501 phishscore=0 spamscore=0 lowpriorityscore=0 suspectscore=0 mlxlogscore=999 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2104190000 definitions=main-2105260100 Archived-At: Subject: [RTG-DIR] RtgDir Early review: draft-ietf-masque-ip-proxy-reqs-02.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 May 2021 14:50:15 -0000 SGVsbG8NCg0KSSBoYXZlIGJlZW4gc2VsZWN0ZWQgdG8gZG8gYSByb3V0aW5nIGRpcmVjdG9yYXRl IOKAnGVhcmx54oCdIHJldmlldyBvZiB0aGlzIGRyYWZ0Lg0K4oCLaHR0cHM6Ly9kYXRhdHJhY2tl ci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1tYXNxdWUtaXAtcHJveHktcmVxcy8NCg0KVGhlIHJv dXRpbmcgZGlyZWN0b3JhdGUgd2lsbCwgb24gcmVxdWVzdCBmcm9tIHRoZSB3b3JraW5nIGdyb3Vw IGNoYWlyLCBwZXJmb3JtIGFuIOKAnGVhcmx54oCdIHJldmlldyBvZiBhIGRyYWZ0IGJlZm9yZSBp dCBpcyBzdWJtaXR0ZWQgZm9yIHB1YmxpY2F0aW9uIHRvIHRoZSBJRVNHLiBUaGUgZWFybHkgcmV2 aWV3IGNhbiBiZSBwZXJmb3JtZWQgYXQgYW55IHRpbWUgZHVyaW5nIHRoZSBkcmFmdOKAmXMgbGlm ZXRpbWUgYXMgYSB3b3JraW5nIGdyb3VwIGRvY3VtZW50LiBUaGUgcHVycG9zZSBvZiB0aGlzIGVh cmx5IHJldmlldyBpcyB0byBlbnN1cmUgYXMgd2lkZSBvZiBhIHJldmlldyBhcyBwb3NzaWJsZQ0K DQpGb3IgbW9yZSBpbmZvcm1hdGlvbiBhYm91dCB0aGUgUm91dGluZyBEaXJlY3RvcmF0ZSwgcGxl YXNlIHNlZSDigItodHRwOi8vdHJhYy50b29scy5pZXRmLm9yZy9hcmVhL3J0Zy90cmFjL3dpa2kv UnRnRGlyDQoNCkRvY3VtZW50OiBkcmFmdC1pZXRmLW1hc3F1ZS1pcC1wcm94eS1yZXFzLTAyLnR4 dA0KUmV2aWV3ZXI6IEpvaG4gRHJha2UNClJldmlldyBEYXRlOiAyNi1NYXktMjAyMQ0KSW50ZW5k ZWQgU3RhdHVzOiBOb25lDQoNClN1bW1hcnk6IA0KDQpObyBpc3N1ZXMgZm91bmQuDQoNCkNvbW1l bnRzOg0KDQpUaGUgZHJhZnQgaXMgY29uY2lzZSwgY29tcGxldGUsIGFuZCB3ZWxsIHdyaXR0ZW4u DQoNCllvdXJzIElycmVzcGVjdGl2ZWx5LA0KDQpKb2huDQoNCg0KSnVuaXBlciBCdXNpbmVzcyBV c2UgT25seQ0K From nobody Wed May 26 09:18:04 2021 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26BB03A0884; Wed, 26 May 2021 09:18:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.797 X-Spam-Level: X-Spam-Status: No, score=-2.797 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.698, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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=juniper.net header.b=Mp9sAomg; dkim=pass (1024-bit key) header.d=juniper.net header.b=ZQn0sDjf 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 e14cTD2QZxxP; Wed, 26 May 2021 09:17:57 -0700 (PDT) Received: from mx0b-00273201.pphosted.com (mx0b-00273201.pphosted.com [67.231.152.164]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8FA563A0874; Wed, 26 May 2021 09:17:57 -0700 (PDT) Received: from pps.filterd (m0108160.ppops.net [127.0.0.1]) by mx0b-00273201.pphosted.com (8.16.0.43/8.16.0.43) with SMTP id 14QGFq4J007925; Wed, 26 May 2021 09:17:56 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : to : cc : subject : date : message-id : content-type : content-transfer-encoding : mime-version; s=PPS1017; bh=WwcMtaH2MJsTImO56pgv2rtNV85gtKYg5cVT8FOIkIw=; b=Mp9sAomgobk6KW3AXnnNfh1djqCBMSo1iXxuIy6bo98qaVLEZ9pKEgWL+98sl5gtPEfi AX3mbYw3HnPYY5DA9nVjfehKqJPKUZmJS47iqyf2RR52Cqe35Y4qVrJyXYidMiQ6BDqS MTxlCD5GJP32/QLwzt04fBJRs5dTvFbEB3/DWckGw9MQFWHPcavLoEM0MP8cibkfWnkR ltyVFinWaxMJbnpigKBvVgFp27A3ENBYHV8MmE/daC5vjCDqsHLGjpzI8kPxfUPwE7wC 5OO3D/xlGVzVgUvj815eTrsg3MW1m0ivdiAD/OKSbvuaIjuNPvW/x00mBNrKrbh8s5Ap rg== Received: from nam04-bn8-obe.outbound.protection.outlook.com (mail-bn8nam08lp2041.outbound.protection.outlook.com [104.47.74.41]) by mx0b-00273201.pphosted.com with ESMTP id 38shnc96vp-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 26 May 2021 09:17:56 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=TGqk8ZQMmEROZdaa0TLmNNcfIjAonVUajtTBceekQ0dQe22JftgHiWZHzqXDKvLD1VQD58IykT6UDmrlL16uelM/I/dYVGs/Vjql6Y0zV1nDVJ1d5vAjYdsdn+gq8VxBEIgUIdMXxnDCFNEZuepRJSAbBgKFcKUxnmr/3T7wBI8sOGj0yEPZVoFhNxFiv0TiOV3fV6jCvfhoqVwvwGsc7ZjGxtbzv3UxozO2NzNiuhlSbBoFZ3M7eGy2oAWANn76Edq6vt1bExI3D5u0+WMmxqx0YOfb23QEyc+hBnIJKtQ7u6MEgrWZM1bkUQQcfVW0onD2KVFONt1DA6yw4o0OPg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=WwcMtaH2MJsTImO56pgv2rtNV85gtKYg5cVT8FOIkIw=; b=e+gqDgakGRLo0yM17Fu1iH6pTLLPD28uxMjyO97TilF1Bu7hRAnrhG4ujgERxTTwrcl7COMwNMjXu6OrTCB+93RPcEi32SyI8hbTwBFCQycNllUmZbFOxAP1Y7eumZn8uvGkNXYj8gQRl1zZj65ZlhDderudzFTsaQsGag8YPlTirE8xS0Ab47PDSU5Vv/AUnm/JpijPya3/LMW0Z8spNPmsxBGSJHVY4iGIh42KzLRCmW4e2+ETp5Pt/hEcjW6U0Q8G9mIlcB8Ii3YaNcruATu/5eWXs3/V+6LddBo2fA/hhwi5aQSjR4HO36FsAuQRQU97aT8WWuJdgOb4zZNbiQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=juniper.net; dmarc=pass action=none header.from=juniper.net; dkim=pass header.d=juniper.net; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=WwcMtaH2MJsTImO56pgv2rtNV85gtKYg5cVT8FOIkIw=; b=ZQn0sDjf3DhX4MBn1b/Jpzn/BXpZC/6JiHXZsLyU9eoOfkRPSE+Mc7gaiZi4V/IiKuD7BSSAxSKCaGsCaozaHZ7WayNt80LRmy7IVRZ3C4PZ9QY+BpDoT5UEybHyHo5PLEvC1HVzT+7D6sjWV/uz/oAnzkS1oNPVn+LUX/e+XqU= Received: from BY3PR05MB8081.namprd05.prod.outlook.com (2603:10b6:a03:366::15) by BYAPR05MB4150.namprd05.prod.outlook.com (2603:10b6:a02:8f::31) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4173.11; Wed, 26 May 2021 16:17:53 +0000 Received: from BY3PR05MB8081.namprd05.prod.outlook.com ([fe80::9195:d339:76df:f757]) by BY3PR05MB8081.namprd05.prod.outlook.com ([fe80::9195:d339:76df:f757%3]) with mapi id 15.20.4195.009; Wed, 26 May 2021 16:17:52 +0000 From: John E Drake To: "masque-chairs@ietf.or" , "draft-ietf-masque-ip-proxy-reqs@ietf.org" CC: "rtg-dir@ietf.org" , "masque@ietf.org" Thread-Topic: RtgDir Early review: draft-ietf-masque-ip-proxy-reqs-02.txt Thread-Index: AddSSie6woQR9e44TvWX2lqChubJEQ== Date: Wed, 26 May 2021 16:17:52 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 11.6.100.41 dlp-reaction: no-action msip_labels: MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Enabled=true; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_SetDate=2021-05-26T16:17:51Z; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Method=Standard; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Name=0633b888-ae0d-4341-a75f-06e04137d755; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_SiteId=bea78b3c-4cdb-4130-854a-1d193232e5f4; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_ActionId=e652bc17-9dd2-4dd3-b4a4-812ead3b4189; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_ContentBits=2 authentication-results: ietf.or; dkim=none (message not signed) header.d=none;ietf.or; dmarc=none action=none header.from=juniper.net; x-originating-ip: [96.235.63.100] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 0adcaeaf-b1ff-4bad-4fcb-08d92061d060 x-ms-traffictypediagnostic: BYAPR05MB4150: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 81dWfCD38UugiTQ4LVZBqvGtwLrgIu+ALdPcQrPAYaKwMAB7Kti7NF1dkeqEWW9Gq6AOTgT0pXz4c7ajXAXM2k6U5nEzuhkMVnrMMjuAN76myq7IXji8aNRIIilif/zVo6U9gmN5WitI4PeNtNUInhKSNCxYrCRUZesisbh4e0K64qTdjNURmBog8ZKzqtCSfMZ8mFeiCwIbROFAoLsBf0Gil5t34C89GNGzlNnHZx27Psoisyvj9SRa2xQrK4obOtCsfRTDWPrrQcdV7mBiw7h/o52nT7Z8svzVAXw3U2LGPLgaIsF6x0rpAZ7aMKsQhv/VodjRhmZdqC2T3H7Jo4l3M13xXfDCp8Tx/SxX7poTfnyJgBDuw5glyv04y1Ni2zweWNv3WS9BHaPJR3btNih2YgKuhRjRmDl1tVgOC7eJ6GsOuC1/dbMorcowTnSuqLwcSRAs6/c2GbBfg9PXDQ5iREYHZnbPjxng2dH6aNj0UkImqzjsKBCfDZVPh2KsjTbXElRPH2XmizpaUKFWwyLTCiNhgjkxQPUrw4qOkwEECTImtn+T3HiU7m8GJRLzC7Yl5M4/r2nXfoi0HqXLdMelXm8wLlC+eph/FqFQenMVYip4h4R/I/nG1zTRip5bTIk7omKqFIq7XMouU+z93xPy2kV0mtshyL5hG9J9NphLZeN1rq7/kCZDO2P3iGs9mA4bgswHTTvBWsPQNYB54w== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BY3PR05MB8081.namprd05.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(136003)(396003)(39860400002)(376002)(346002)(7696005)(4744005)(186003)(55016002)(110136005)(4326008)(966005)(2906002)(76116006)(8676002)(66446008)(64756008)(83380400001)(26005)(66556008)(66946007)(66476007)(316002)(8936002)(9686003)(38100700002)(478600001)(33656002)(71200400001)(86362001)(4743002)(54906003)(52536014)(6506007)(5660300002)(122000001); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: =?us-ascii?Q?ajh4ImWkb749dxMk1JnPl7znB2re8o3ebDZwL8337X5kMDECrVGiatig1AjJ?= =?us-ascii?Q?0+VGJL+Z24ZaifDoJPp8GHlY+mDB1L5JkML3KQG+MyuMpdKCDGQTRH/BNw/u?= =?us-ascii?Q?t6YWyec6hFuAY7ztPbai2BI2aUx3G+EtIEoOBjE2QE1YeINhy2+MEYRGZCGT?= =?us-ascii?Q?Kx3ixxCj8D2Gw9u/jp5xzdQZ5Qqk0hpp+Fg0dY/lHHUgymAORV6TeDc4K4DC?= =?us-ascii?Q?PSqz94byfv9omoEOql8SoDO1Czi5oCJQZr+a5xaif1kt0t/JdVa08gjhrrPR?= =?us-ascii?Q?xd6NK0+A5bwZR+FquGq5x8If52FdhkJ29dT9Tkw2c1QX5YCyS7gbLU4JOiyZ?= =?us-ascii?Q?qGBg8wJME26dsGc3cS9g4OFOGDJ4X5pnkhIYgmRbOVHctdyDtZp1wPA9dJ2o?= =?us-ascii?Q?qED39ZGR43Q13MJ1e3ocYrjEadkhOYwO9y4ofyRYYE+vJY5pf8QPC/e7UBan?= =?us-ascii?Q?S14mojIs5MANFmOEAvE4LmpJK7wLGcAd5yCCqKpz9e8pLWz6RKeHjyaPQZk3?= =?us-ascii?Q?LP9CBwnQeXwh1OKijTZjegJOEudKGWXKNNV+5kpCTnsJGxTg7LSTHdilX71x?= =?us-ascii?Q?HAdJGOeNKQ4CMx+ZjUJXw8jC8QYyFdI+WJ99VMCGPXm05DEiNrw7SrXsb/NE?= =?us-ascii?Q?YV+oSEL8KJj0uFjq3XlOFWtEVH2M+jTx5ZPR4BzDIYwFiqH0nAh6TFnSTG9i?= =?us-ascii?Q?o84weDXhuYzYgKR3sqvIfJSRFrk+ybmqj7k0pVRj6JzWVV0MaPg2qul+tSKL?= =?us-ascii?Q?dfFcnjmpxjdvdifSe0HuEnKiRiqPXq+RPdkUZC13elGEYUId/tC5Zh5lENYe?= =?us-ascii?Q?hq0l8ZAv4+Bf0vviwnbVaWRuxwt56bLUbpGk5gzQ2q3ol6xGtpYj4YTe1Y9l?= =?us-ascii?Q?FQMmu85pHFwnVgabvC19xNBEHmLT16jXRT15i81ju2WbnIJhyN+GwFGKD5NM?= =?us-ascii?Q?FovaBiu9H6myqNTJokq0M6oDXrxbTArkN1GOyRSktAXOoOidC+Vda2ZCLf8Q?= =?us-ascii?Q?Du51trCrfYN0cZoZVmxcnJPlQPXMYmNElLe//NlOqPqPXptbNzLWZYJ2F2ib?= =?us-ascii?Q?h+xazsFqtAWtUsUFn5HPKgLydSq7l5rezE7KIGtWt1ty5RFbq7MCoFziqBzx?= =?us-ascii?Q?A45tpoT5ZIFXeqXBOCn4nuHAqmC72CWc2gPS71iiqlArgWxfzY7Q2zctbEcz?= =?us-ascii?Q?Ilsym8IzZw+LlYRKARb48NFvhz965rRHvthOARMP4RQ1y/EtonBrprZc9KED?= =?us-ascii?Q?VTlH4SIybdkrUAYMrwwnNLlubaa3cP9ZNZ85+X1PrAlz0Hvow2lv2A3jtAFT?= =?us-ascii?Q?miTRfMVSQxzkXxB9o77mHqQi?= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BY3PR05MB8081.namprd05.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 0adcaeaf-b1ff-4bad-4fcb-08d92061d060 X-MS-Exchange-CrossTenant-originalarrivaltime: 26 May 2021 16:17:52.8449 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: SuI01Kq9kWxh8XSQWSSqBp2cvP0OQr33fyUgG9Pn9INt5307M8S/ITIGOqSQWpfxT1dnLF3HJisQJ0aBkWnDyQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR05MB4150 X-Proofpoint-GUID: tx87YX9TeQTilcUC_aRwR3wXeGh0zuld X-Proofpoint-ORIG-GUID: tx87YX9TeQTilcUC_aRwR3wXeGh0zuld X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.391, 18.0.761 definitions=2021-05-26_10:2021-05-26, 2021-05-26 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 mlxscore=0 adultscore=0 lowpriorityscore=0 bulkscore=0 malwarescore=0 impostorscore=0 phishscore=0 mlxlogscore=920 priorityscore=1501 clxscore=1011 spamscore=0 suspectscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2104190000 definitions=main-2105260110 Archived-At: Subject: [RTG-DIR] RtgDir Early review: draft-ietf-masque-ip-proxy-reqs-02.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 May 2021 16:18:02 -0000 Hello I have been selected to do a routing directorate "early" review of this dra= ft. https://datatracker.ietf.org/doc/draft-ietf-masque-ip-proxy-reqs/ The routing directorate will, on request from the working group chair, perf= orm 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 this early review is t= o ensure as wide of a review as possible For more information about the Routing Directorate, please see http://trac.= tools.ietf.org/area/rtg/trac/wiki/RtgDir Document: draft-ietf-masque-ip-proxy-reqs-02.txt Reviewer: John Drake Review Date: 26-May-2021 Intended Status: None Summary:=20 No issues found. Comments: The draft is concise, complete, and well written. Yours Irrespectively, John Juniper Business Use Only From nobody Fri May 28 13:05:06 2021 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 909F93A3406; Fri, 28 May 2021 13:05:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 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, HTML_MESSAGE=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 Eu7BXRGgzW0w; Fri, 28 May 2021 13:04:56 -0700 (PDT) Received: from mail-pf1-x433.google.com (mail-pf1-x433.google.com [IPv6:2607:f8b0:4864:20::433]) (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 1F4673A3402; Fri, 28 May 2021 13:04:52 -0700 (PDT) Received: by mail-pf1-x433.google.com with SMTP id y15so99694pfl.4; Fri, 28 May 2021 13:04:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ijgyewwuaFTZOCEdwpTSv6RjYQi83tRNg9GWI58vi8w=; b=H+clWeidzno8dNrhB0EuIbbi0sCEyhrR7NHkuJCsw2FSmBCqogxeg/7NqyYI4LM7zN koZvNP2NVETU8KFaQj0Pp/oQ5ZLtIMwNJliqruUIe/Zjr6h4icbC89BJJb35BMnNvXtw /UB9ITqAgQAQjwaI5x8JQdK++Xc3rDEWBGHDiB9xMs9RCW6a6m8jRpVJnUPwKH4lKRKr 7rGxw8o4PtMUSEbrSXWWcNcnrR330eb1qTJC1DxyKpTHicB1q+GFunxmGi7x5UYEKAa+ Vjv/Aez+5/msp38w/9u7YQFwc21VWumQdCv8HcBGIcbQv0HkIJAqTA/A8QbTpQzIGS/H IpEw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=ijgyewwuaFTZOCEdwpTSv6RjYQi83tRNg9GWI58vi8w=; b=cMKTIhoF5znufuLGuYTClU2U+gSVh3gy0URJLUyZhSCibNRZ2pOz1TiYWnpipoqZ0C 5Y9BtbKGs2+ips503QvhwF2rxI9kK/gYfZlJyhdc++aztdjtELjIZzEVleMGfdZ07G32 IYTVju+gex7KEsS3LYBLoJTZw3jbytd9Xyqs2pTv2Zx0o7Bkk+nxvNSk1LNpqeOB/WtO DaBzNwOmxNWhdY+SPGhpKT3+a+F6SreDgNJEonoXac9ztlnsSWDqVkQwzEiC8CLn2Uk8 1icalV6F5zG2VNkYpZDeQ6255Jzlhkt5qQPSwRsW5g/onZXkh1uA2kFmzMaOzRe/PPvw Bf6Q== X-Gm-Message-State: AOAM5325JShUNKtbVi35D6laAc/tHzBY1Q5zcb4cRJy70w3xMbeHK1Ov qPIWHLR5tLdyjuxd/fnbnbjBO8uEMB1tHWYiQVs= X-Google-Smtp-Source: ABdhPJxS4C1WmHswdwtYov1Yq00ZYxQytGLmScsOLoBATpIRkzJglKmdf26jZQ/Maxi9BBQd75Cf40mqRKMrme9wAto= X-Received: by 2002:a63:b907:: with SMTP id z7mr10305520pge.112.1622232290984; Fri, 28 May 2021 13:04:50 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Alexander Azimov Date: Fri, 28 May 2021 23:04:40 +0300 Message-ID: To: Mach Chen Cc: "idr-chairs@ietf.org" , "draft-ietf-idr-bgp-open-policy.all@ietf.org" , "rtg-dir@ietf.org" , "idr@ietf.org" Content-Type: multipart/alternative; boundary="0000000000007285e405c3696308" Archived-At: Subject: Re: [RTG-DIR] RtgDir Early review: draft-ietf-idr-bgp-open-policy-15.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 May 2021 20:05:01 -0000 --0000000000007285e405c3696308 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Dear Mach, Thank you for your comments, all nits are already applied. But it proved that different authors have a different reading of your comment related to section 6: > Section 6. > It does not specify how a speaker handle a route with OTC attribute but > the sender's role is unknown. Are you speaking about the OTC processing in case of the absence of a locally configured role? Or does it about receiving OTC attribute from a neighbor that doesn't participate in the role negotiation? =D1=87=D1=82, 13 =D0=BC=D0=B0=D1=8F 2021 =D0=B3. =D0=B2 09:50, Mach Chen : > Hello > > I have been selected to do a routing directorate =E2=80=9Cearly=E2=80=9D = review of this > draft. > =E2=80=8Bhttps://datatracker.ietf.org/doc/ draft-ietf-idr-bgp-open-policy= / > > The routing directorate will, on request from the working group chair, > perform an =E2=80=9Cearly=E2=80=9D review of a draft before it is submitt= ed for publication > to the IESG. The early review can be performed at any time during the > draft=E2=80=99s 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 been sent to IESG for publication, my focus for the > review was to determine whether the document is ready to be published. > Please consider my comments along with the other last call comments. > > Document: draft-ietf-idr-bgp-open-policy-15.txt > Reviewer: Mach Chen > Review Date: 2021/05/13 > Intended Status: Standards Track > > Summary: > > This document is basically ready for publication, but has nits and minor > concerns that should be considered prior to being submitted to the IESG. > > Comments: > > Section 6. > It does not specify how a speaker handle a route with OTC attribute but > the sender's role is unknown. > > > Nits: > > Section 2. > s/ their customers/its customers > > Section 3. > s/Allowed Role values/Allowed Roles > > Section 4. > It's better to update the table as follows: > > +-------+---------------------+ > | Value | Role name | > +-------+---------------------+ > | 0 | Sender is Provider | > | 1 | Sender is RS | > | 2 | Sender is RS-client | > | 3 | Sender is Customer | > | 4 | Sender is Peer | > | 5-255 | Reserved | > +-------+---------------------+ > > Section 5. > OLD: > "If the role of the receiving speaker for the eBGP session in > consideration is included in Table 1 and the observed Role pair is > not in the above table," > NEW: > > "If the observed Role pair is not in the above table," > > IMHO, it's redundant to include "If the role of the receiving speaker for > the eBGP session in consideration is included in Table 1", just keep the > second half of the sentence is enough. > > Section 5.1 > > s/send a send a/send a, there is a redundant "send a". > > Best regards, > Mach > --=20 Best regards, Alexander Azimov --0000000000007285e405c3696308 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear=C2=A0Mach,

Thank you for your comm= ents, all nits are already applied.

But it proved = that different authors have a different reading of your comment related to = section 6:
Section 6= .
It does not specify how a speaker handle a route with OTC attribute bu= t the sender's role is unknown.
Are you speaking=C2=A0= about the OTC processing in case of the absence of a locally configured rol= e?
Or does it about receiving OTC attribute from a neighbor= =C2=A0that doesn't participate in the role negotiation?

=
=D1=87=D1= =82, 13 =D0=BC=D0=B0=D1=8F 2021 =D0=B3. =D0=B2 09:50, Mach Chen <mach.chen@huawei.com>:
Hello

I have been selected to do a routing directorate =E2=80=9Cearly=E2=80=9D re= view of this draft.
=E2=80=8Bhttps://datatracker.ietf.org/doc/ draft-ietf-idr-bgp-o= pen-policy /

The routing directorate will, on request from the working group chair, perf= orm an =E2=80=9Cearly=E2=80=9D review of a draft before it is submitted for= publication to the IESG. The early review can be performed at any time dur= ing the draft=E2=80=99s lifetime as a working group document. The purpose o= f the early review depends on the stage that the document has reached.

As this document has been sent to IESG for publication, my focus for the re= view was to determine whether the document is ready to be published. Please= consider my comments along with the other last call comments.

Document: draft-ietf-idr-bgp-open-policy-15.txt
Reviewer: Mach Chen
Review Date: 2021/05/13
Intended Status: Standards Track

Summary:

This document is basically ready for publication, but has nits and minor co= ncerns that should be considered prior to being submitted to the IESG.

Comments:

Section 6.
It does not specify how a speaker handle a route with OTC attribute but the= sender's role is unknown.


Nits:

Section 2.
s/ their customers/its customers

Section 3.
s/Allowed Role values/Allowed Roles

Section 4.
It's better to update the table as follows:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 +-------+---------------------+
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 | Value | Role name=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 +-------+---------------------+
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 |=C2=A0 =C2=A00=C2=A0 =C2=A0| Sender is Provider=C2=A0 |
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 |=C2=A0 =C2=A01=C2=A0 =C2=A0| Sender is RS=C2=A0 =C2=A0 =C2=A0 =C2=A0 |=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 |=C2=A0 =C2=A02=C2=A0 =C2=A0| Sender is RS-client |
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 |=C2=A0 =C2=A03=C2=A0 =C2=A0| Sender is Customer=C2=A0 |
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 |=C2=A0 =C2=A04=C2=A0 =C2=A0| Sender is Peer=C2=A0 =C2=A0 =C2=A0 |
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 | 5-255=C2=A0 | Reserved=C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 +-------+---------------------+

Section 5.
OLD:
"If the role of the receiving speaker for the eBGP session in
=C2=A0 =C2=A0consideration is included in Table 1 and the observed Role pai= r is
=C2=A0 =C2=A0not in the above table,"
NEW:

"If the observed Role pair is not in the above table,"

IMHO, it's redundant to include "If the role of the receiving spea= ker for the eBGP session in consideration is included in Table 1", jus= t keep the second half of the sentence is enough.

Section 5.1

s/send a send a/send a, there is a redundant "send a".

Best regards,
Mach


--
Best regards,
Alexander Azi= mov
--0000000000007285e405c3696308-- From nobody Sat May 29 01:03:38 2021 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D79E3A0D38; Sat, 29 May 2021 01:03:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.895 X-Spam-Level: X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 aE__gR_yAmMQ; Sat, 29 May 2021 01:03:32 -0700 (PDT) Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A480C3A0D31; Sat, 29 May 2021 01:03:32 -0700 (PDT) Received: from fraeml738-chm.china.huawei.com (unknown [172.18.147.200]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4FsYjj6Rg4z6S1fN; Sat, 29 May 2021 15:54:33 +0800 (CST) Received: from dggpemm500001.china.huawei.com (7.185.36.107) by fraeml738-chm.china.huawei.com (10.206.15.219) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2176.2; Sat, 29 May 2021 10:03:28 +0200 Received: from dggpemm500002.china.huawei.com (7.185.36.229) by dggpemm500001.china.huawei.com (7.185.36.107) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2176.2; Sat, 29 May 2021 16:03:26 +0800 Received: from dggpemm500002.china.huawei.com ([7.185.36.229]) by dggpemm500002.china.huawei.com ([7.185.36.229]) with mapi id 15.01.2176.012; Sat, 29 May 2021 16:03:26 +0800 From: Mach Chen To: Alexander Azimov CC: "draft-ietf-idr-bgp-open-policy.all@ietf.org" , "idr-chairs@ietf.org" , "idr@ietf.org" , "rtg-dir@ietf.org" Thread-Topic: [RTG-DIR] RtgDir Early review: draft-ietf-idr-bgp-open-policy-15.txt Thread-Index: AddHqF05jAuFF5QzTsaQPC2aQyKdxQMEUXMAAClIxOA= Date: Sat, 29 May 2021 08:03:26 +0000 Message-ID: <5b1c53aa2e9c4a18b03b95fb7b00abf2@huawei.com> References: In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.108.243.140] Content-Type: multipart/alternative; boundary="_000_5b1c53aa2e9c4a18b03b95fb7b00abf2huaweicom_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [RTG-DIR] RtgDir Early review: draft-ietf-idr-bgp-open-policy-15.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 May 2021 08:03:38 -0000 --_000_5b1c53aa2e9c4a18b03b95fb7b00abf2huaweicom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgQWxleGFuZGVyLA0KDQpQbGVhc2Ugc2VlIG1lIHJlc3BvbnNlIGlubGluZSB3aXRoIFtNYWNo XQ0KDQpGcm9tOiBydGctZGlyIFttYWlsdG86cnRnLWRpci1ib3VuY2VzQGlldGYub3JnXSBPbiBC ZWhhbGYgT2YgQWxleGFuZGVyIEF6aW1vdg0KU2VudDogU2F0dXJkYXksIE1heSAyOSwgMjAyMSA0 OjA1IEFNDQpUbzogTWFjaCBDaGVuIDxtYWNoLmNoZW5AaHVhd2VpLmNvbT4NCkNjOiBkcmFmdC1p ZXRmLWlkci1iZ3Atb3Blbi1wb2xpY3kuYWxsQGlldGYub3JnOyBpZHItY2hhaXJzQGlldGYub3Jn OyBpZHJAaWV0Zi5vcmc7IHJ0Zy1kaXJAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbUlRHLURJUl0g UnRnRGlyIEVhcmx5IHJldmlldzogZHJhZnQtaWV0Zi1pZHItYmdwLW9wZW4tcG9saWN5LTE1LnR4 dA0KDQpEZWFyIE1hY2gsDQoNClRoYW5rIHlvdSBmb3IgeW91ciBjb21tZW50cywgYWxsIG5pdHMg YXJlIGFscmVhZHkgYXBwbGllZC4NCg0KW01hY2hdIE9LLg0KDQpCdXQgaXQgcHJvdmVkIHRoYXQg ZGlmZmVyZW50IGF1dGhvcnMgaGF2ZSBhIGRpZmZlcmVudCByZWFkaW5nIG9mIHlvdXIgY29tbWVu dCByZWxhdGVkIHRvIHNlY3Rpb24gNjoNClNlY3Rpb24gNi4NCkl0IGRvZXMgbm90IHNwZWNpZnkg aG93IGEgc3BlYWtlciBoYW5kbGUgYSByb3V0ZSB3aXRoIE9UQyBhdHRyaWJ1dGUgYnV0IHRoZSBz ZW5kZXIncyByb2xlIGlzIHVua25vd24uDQpBcmUgeW91IHNwZWFraW5nIGFib3V0IHRoZSBPVEMg cHJvY2Vzc2luZyBpbiBjYXNlIG9mIHRoZSBhYnNlbmNlIG9mIGEgbG9jYWxseSBjb25maWd1cmVk IHJvbGU/DQpPciBkb2VzIGl0IGFib3V0IHJlY2VpdmluZyBPVEMgYXR0cmlidXRlIGZyb20gYSBu ZWlnaGJvciB0aGF0IGRvZXNuJ3QgcGFydGljaXBhdGUgaW4gdGhlIHJvbGUgbmVnb3RpYXRpb24/ DQoNCltNYWNoXSBBY3R1YWxseSwgaW4gYm90aCBjYXNlcywgdGhlIHJvbGUgb2YgdGhlIHBlZXIg aXMgdW5jZXJ0YWluLCBpZiBzbyB3aGF0IHdpbGwgdGhlIGluZ3Jlc3MgcG9saWN5IGFuZCBlZ3Jl c3MgcG9saWN5IGJlPyBGb3IgZXhhbXBsZSwgcmVnYXJkaW5nIGluZ3Jlc3MgcG9saWN5LCBob3cg dG8gaGFuZGxlIGEgcm91dGUgd2l0aCBPVEMgYXR0cmlidXRlIGJ1dCBub3Qgc3VyZSB0aGUgc2Vu ZGVy4oCZcyByb2xlLiBBbmQgcmVnYXJkaW5nIHRoZSBlZ3Jlc3MgcG9saWN5LCBpZiB0aGUgcGVl cuKAmXMgcm9sZSBjYW5ub3QgYmUgZGV0ZXJtaW5lZCwgV2hldGhlciB0aGUgcm91dGUgc2hvdWxk IGJlIHNlbnQgdG8gdGhlIHBlZXI/IFNob3VsZCB0aGUgT1RDIGJlIGtlcHQ/DQoNCkJlc3QgcmVn YXJkcywNCk1hY2gNCg0K0YfRgiwgMTMg0LzQsNGPIDIwMjEg0LMuINCyIDA5OjUwLCBNYWNoIENo ZW4gPG1hY2guY2hlbkBodWF3ZWkuY29tPG1haWx0bzptYWNoLmNoZW5AaHVhd2VpLmNvbT4+Og0K SGVsbG8NCg0KSSBoYXZlIGJlZW4gc2VsZWN0ZWQgdG8gZG8gYSByb3V0aW5nIGRpcmVjdG9yYXRl IOKAnGVhcmx54oCdIHJldmlldyBvZiB0aGlzIGRyYWZ0Lg0K4oCLaHR0cHM6Ly9kYXRhdHJhY2tl ci5pZXRmLm9yZy9kb2MvIGRyYWZ0LWlldGYtaWRyLWJncC1vcGVuLXBvbGljeSAvDQoNClRoZSBy b3V0aW5nIGRpcmVjdG9yYXRlIHdpbGwsIG9uIHJlcXVlc3QgZnJvbSB0aGUgd29ya2luZyBncm91 cCBjaGFpciwgcGVyZm9ybSBhbiDigJxlYXJseeKAnSByZXZpZXcgb2YgYSBkcmFmdCBiZWZvcmUg aXQgaXMgc3VibWl0dGVkIGZvciBwdWJsaWNhdGlvbiB0byB0aGUgSUVTRy4gVGhlIGVhcmx5IHJl dmlldyBjYW4gYmUgcGVyZm9ybWVkIGF0IGFueSB0aW1lIGR1cmluZyB0aGUgZHJhZnTigJlzIGxp ZmV0aW1lIGFzIGEgd29ya2luZyBncm91cCBkb2N1bWVudC4gVGhlIHB1cnBvc2Ugb2YgdGhlIGVh cmx5IHJldmlldyBkZXBlbmRzIG9uIHRoZSBzdGFnZSB0aGF0IHRoZSBkb2N1bWVudCBoYXMgcmVh Y2hlZC4NCg0KQXMgdGhpcyBkb2N1bWVudCBoYXMgYmVlbiBzZW50IHRvIElFU0cgZm9yIHB1Ymxp Y2F0aW9uLCBteSBmb2N1cyBmb3IgdGhlIHJldmlldyB3YXMgdG8gZGV0ZXJtaW5lIHdoZXRoZXIg dGhlIGRvY3VtZW50IGlzIHJlYWR5IHRvIGJlIHB1Ymxpc2hlZC4gUGxlYXNlIGNvbnNpZGVyIG15 IGNvbW1lbnRzIGFsb25nIHdpdGggdGhlIG90aGVyIGxhc3QgY2FsbCBjb21tZW50cy4NCg0KRG9j dW1lbnQ6IGRyYWZ0LWlldGYtaWRyLWJncC1vcGVuLXBvbGljeS0xNS50eHQNClJldmlld2VyOiBN YWNoIENoZW4NClJldmlldyBEYXRlOiAyMDIxLzA1LzEzDQpJbnRlbmRlZCBTdGF0dXM6IFN0YW5k YXJkcyBUcmFjaw0KDQpTdW1tYXJ5Og0KDQpUaGlzIGRvY3VtZW50IGlzIGJhc2ljYWxseSByZWFk eSBmb3IgcHVibGljYXRpb24sIGJ1dCBoYXMgbml0cyBhbmQgbWlub3IgY29uY2VybnMgdGhhdCBz aG91bGQgYmUgY29uc2lkZXJlZCBwcmlvciB0byBiZWluZyBzdWJtaXR0ZWQgdG8gdGhlIElFU0cu DQoNCkNvbW1lbnRzOg0KDQpTZWN0aW9uIDYuDQpJdCBkb2VzIG5vdCBzcGVjaWZ5IGhvdyBhIHNw ZWFrZXIgaGFuZGxlIGEgcm91dGUgd2l0aCBPVEMgYXR0cmlidXRlIGJ1dCB0aGUgc2VuZGVyJ3Mg cm9sZSBpcyB1bmtub3duLg0KDQoNCk5pdHM6DQoNClNlY3Rpb24gMi4NCnMvIHRoZWlyIGN1c3Rv bWVycy9pdHMgY3VzdG9tZXJzDQoNClNlY3Rpb24gMy4NCnMvQWxsb3dlZCBSb2xlIHZhbHVlcy9B bGxvd2VkIFJvbGVzDQoNClNlY3Rpb24gNC4NCkl0J3MgYmV0dGVyIHRvIHVwZGF0ZSB0aGUgdGFi bGUgYXMgZm9sbG93czoNCg0KICAgICAgICAgICAgICAgICAgICAgICstLS0tLS0tKy0tLS0tLS0t LS0tLS0tLS0tLS0tLSsNCiAgICAgICAgICAgICAgICAgICAgICB8IFZhbHVlIHwgUm9sZSBuYW1l ICAgICAgICAgICB8DQogICAgICAgICAgICAgICAgICAgICAgKy0tLS0tLS0rLS0tLS0tLS0tLS0t LS0tLS0tLS0tKw0KICAgICAgICAgICAgICAgICAgICAgIHwgICAwICAgfCBTZW5kZXIgaXMgUHJv dmlkZXIgIHwNCiAgICAgICAgICAgICAgICAgICAgICB8ICAgMSAgIHwgU2VuZGVyIGlzIFJTICAg ICAgICB8DQogICAgICAgICAgICAgICAgICAgICAgfCAgIDIgICB8IFNlbmRlciBpcyBSUy1jbGll bnQgfA0KICAgICAgICAgICAgICAgICAgICAgIHwgICAzICAgfCBTZW5kZXIgaXMgQ3VzdG9tZXIg IHwNCiAgICAgICAgICAgICAgICAgICAgICB8ICAgNCAgIHwgU2VuZGVyIGlzIFBlZXIgICAgICB8 DQogICAgICAgICAgICAgICAgICAgICAgfCA1LTI1NSAgfCBSZXNlcnZlZCAgICAgIHwNCiAgICAg ICAgICAgICAgICAgICAgICArLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLS0tLS0rDQoNClNlY3Rp b24gNS4NCk9MRDoNCiJJZiB0aGUgcm9sZSBvZiB0aGUgcmVjZWl2aW5nIHNwZWFrZXIgZm9yIHRo ZSBlQkdQIHNlc3Npb24gaW4NCiAgIGNvbnNpZGVyYXRpb24gaXMgaW5jbHVkZWQgaW4gVGFibGUg MSBhbmQgdGhlIG9ic2VydmVkIFJvbGUgcGFpciBpcw0KICAgbm90IGluIHRoZSBhYm92ZSB0YWJs ZSwiDQpORVc6DQoNCiJJZiB0aGUgb2JzZXJ2ZWQgUm9sZSBwYWlyIGlzIG5vdCBpbiB0aGUgYWJv dmUgdGFibGUsIg0KDQpJTUhPLCBpdCdzIHJlZHVuZGFudCB0byBpbmNsdWRlICJJZiB0aGUgcm9s ZSBvZiB0aGUgcmVjZWl2aW5nIHNwZWFrZXIgZm9yIHRoZSBlQkdQIHNlc3Npb24gaW4gY29uc2lk ZXJhdGlvbiBpcyBpbmNsdWRlZCBpbiBUYWJsZSAxIiwganVzdCBrZWVwIHRoZSBzZWNvbmQgaGFs ZiBvZiB0aGUgc2VudGVuY2UgaXMgZW5vdWdoLg0KDQpTZWN0aW9uIDUuMQ0KDQpzL3NlbmQgYSBz ZW5kIGEvc2VuZCBhLCB0aGVyZSBpcyBhIHJlZHVuZGFudCAic2VuZCBhIi4NCg0KQmVzdCByZWdh cmRzLA0KTWFjaA0KDQoNCi0tDQpCZXN0IHJlZ2FyZHMsDQpBbGV4YW5kZXIgQXppbW92DQo= --_000_5b1c53aa2e9c4a18b03b95fb7b00abf2huaweicom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 5a6L5L2TOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseToiTVMgR290aGljIjsNCglwYW5vc2UtMToyIDExIDYgOSA3IDIgNSA4IDIgNDt9 DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIg NCA1IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0K CXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1p bHk6IlxA5a6L5L2TIjsNCglwYW5vc2UtMToyIDEgNiAwIDMgMSAxIDEgMSAxO30NCkBmb250LWZh Y2UNCgl7Zm9udC1mYW1pbHk6IlxATVMgR290aGljIjsNCglwYW5vc2UtMToyIDExIDYgOSA3IDIg NSA4IDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05v cm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFw dDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OuWui+S9kzt9DQphOmxpbmssIHNw YW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0K CXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlu a0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4 dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUt dHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsN Cgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9y dC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCkBwYWdlIFdvcmRT ZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzIuMHB0IDkwLjBwdCA3 Mi4wcHQgOTAuMHB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0K LS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpl eHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0 ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6 ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0t Pg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iWkgtQ04iIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUi Pg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+SGkgQWxleGFuZGVyLDxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjoj MUY0OTdEIj5QbGVhc2Ugc2VlIG1lIHJlc3BvbnNlIGlubGluZSB3aXRoIFtNYWNoXTxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRp diBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5n OjBjbSAwY20gMGNtIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3Jk ZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5Gcm9t Ojwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+IHJ0Zy1kaXIgW21haWx0 bzpydGctZGlyLWJvdW5jZXNAaWV0Zi5vcmddDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPkFsZXhhbmRl ciBBemltb3Y8YnI+DQo8Yj5TZW50OjwvYj4gU2F0dXJkYXksIE1heSAyOSwgMjAyMSA0OjA1IEFN PGJyPg0KPGI+VG86PC9iPiBNYWNoIENoZW4gJmx0O21hY2guY2hlbkBodWF3ZWkuY29tJmd0Ozxi cj4NCjxiPkNjOjwvYj4gZHJhZnQtaWV0Zi1pZHItYmdwLW9wZW4tcG9saWN5LmFsbEBpZXRmLm9y ZzsgaWRyLWNoYWlyc0BpZXRmLm9yZzsgaWRyQGlldGYub3JnOyBydGctZGlyQGlldGYub3JnPGJy Pg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbUlRHLURJUl0gUnRnRGlyIEVhcmx5IHJldmlldzogZHJh ZnQtaWV0Zi1pZHItYmdwLW9wZW4tcG9saWN5LTE1LnR4dDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIj5EZWFyJm5ic3A7TWFjaCw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIj5UaGFuayB5b3UgZm9yIHlvdXIgY29tbWVudHMsIGFsbCBuaXRz IGFyZSBhbHJlYWR5IGFwcGxpZWQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPltNYWNoXSBPSy48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPkJ1dCBpdCBwcm92ZWQgdGhhdCBk aWZmZXJlbnQgYXV0aG9ycyBoYXZlIGEgZGlmZmVyZW50IHJlYWRpbmcgb2YgeW91ciBjb21tZW50 IHJlbGF0ZWQgdG8gc2VjdGlvbiA2OjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGJs b2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4w cHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmln aHQ6MGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5TZWN0aW9u IDYuPGJyPg0KSXQgZG9lcyBub3Qgc3BlY2lmeSBob3cgYSBzcGVha2VyIGhhbmRsZSBhIHJvdXRl IHdpdGggT1RDIGF0dHJpYnV0ZSBidXQgdGhlIHNlbmRlcidzIHJvbGUgaXMgdW5rbm93bi48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPkFyZSB5b3Ugc3BlYWtpbmcmbmJzcDthYm91dCB0aGUg T1RDIHByb2Nlc3NpbmcgaW4gY2FzZSBvZiB0aGUgYWJzZW5jZSBvZiBhIGxvY2FsbHkgY29uZmln dXJlZCByb2xlPzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5PciBkb2VzIGl0IGFib3V0IHJlY2Vpdmlu ZyBPVEMgYXR0cmlidXRlIGZyb20gYSBuZWlnaGJvciZuYnNwO3RoYXQgZG9lc24ndCBwYXJ0aWNp cGF0ZSBpbiB0aGUgcm9sZSBuZWdvdGlhdGlvbj88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41 cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5 N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+W01hY2hdIEFjdHVhbGx5 LCBpbiBib3RoIGNhc2VzLCB0aGUgcm9sZSBvZiB0aGUgcGVlciBpcyB1bmNlcnRhaW4sIGlmIHNv IHdoYXQgd2lsbCB0aGUgaW5ncmVzcyBwb2xpY3kgYW5kIGVncmVzcyBwb2xpY3kgYmU/IEZvciBl eGFtcGxlLCByZWdhcmRpbmcNCiBpbmdyZXNzIHBvbGljeSwgaG93IHRvIGhhbmRsZSBhIHJvdXRl IHdpdGggT1RDIGF0dHJpYnV0ZSBidXQgbm90IHN1cmUgdGhlIHNlbmRlcuKAmXMgcm9sZS4gQW5k IHJlZ2FyZGluZyB0aGUgZWdyZXNzIHBvbGljeSwgaWYgdGhlIHBlZXLigJlzIHJvbGUgY2Fubm90 IGJlIGRldGVybWluZWQsIFdoZXRoZXIgdGhlIHJvdXRlIHNob3VsZCBiZSBzZW50IHRvIHRoZSBw ZWVyPyBTaG91bGQgdGhlIE9UQyBiZSBrZXB0Pw0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAu NXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0 OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkJlc3QgcmVnYXJkcyw8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPk1hY2g8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPtGH0YIsIDEzINC80LDRjyAyMDIxINCzLiDQsiAw OTo1MCwgTWFjaCBDaGVuICZsdDs8YSBocmVmPSJtYWlsdG86bWFjaC5jaGVuQGh1YXdlaS5jb20i Pm1hY2guY2hlbkBodWF3ZWkuY29tPC9hPiZndDs6PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0ND Q0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21h cmdpbi1yaWdodDowY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi PkhlbGxvPGJyPg0KPGJyPg0KSSBoYXZlIGJlZW4gc2VsZWN0ZWQgdG8gZG8gYSByb3V0aW5nIGRp cmVjdG9yYXRlIOKAnGVhcmx54oCdIHJldmlldyBvZiB0aGlzIGRyYWZ0Ljxicj4NCjwvc3Bhbj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O01TIEdvdGhpYyZxdW90 OyI+4oCLPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48YSBocmVmPSJodHRwczovL2RhdGF0cmFj a2VyLmlldGYub3JnL2RvYy8iIHRhcmdldD0iX2JsYW5rIj5odHRwczovL2RhdGF0cmFja2VyLmll dGYub3JnL2RvYy88L2E+IGRyYWZ0LWlldGYtaWRyLWJncC1vcGVuLXBvbGljeSAvPGJyPg0KPGJy Pg0KVGhlIHJvdXRpbmcgZGlyZWN0b3JhdGUgd2lsbCwgb24gcmVxdWVzdCBmcm9tIHRoZSB3b3Jr aW5nIGdyb3VwIGNoYWlyLCBwZXJmb3JtIGFuIOKAnGVhcmx54oCdIHJldmlldyBvZiBhIGRyYWZ0 IGJlZm9yZSBpdCBpcyBzdWJtaXR0ZWQgZm9yIHB1YmxpY2F0aW9uIHRvIHRoZSBJRVNHLiBUaGUg ZWFybHkgcmV2aWV3IGNhbiBiZSBwZXJmb3JtZWQgYXQgYW55IHRpbWUgZHVyaW5nIHRoZSBkcmFm dOKAmXMgbGlmZXRpbWUgYXMgYSB3b3JraW5nIGdyb3VwIGRvY3VtZW50Lg0KIFRoZSBwdXJwb3Nl IG9mIHRoZSBlYXJseSByZXZpZXcgZGVwZW5kcyBvbiB0aGUgc3RhZ2UgdGhhdCB0aGUgZG9jdW1l bnQgaGFzIHJlYWNoZWQuPGJyPg0KPGJyPg0KQXMgdGhpcyBkb2N1bWVudCBoYXMgYmVlbiBzZW50 IHRvIElFU0cgZm9yIHB1YmxpY2F0aW9uLCBteSBmb2N1cyBmb3IgdGhlIHJldmlldyB3YXMgdG8g ZGV0ZXJtaW5lIHdoZXRoZXIgdGhlIGRvY3VtZW50IGlzIHJlYWR5IHRvIGJlIHB1Ymxpc2hlZC4g UGxlYXNlIGNvbnNpZGVyIG15IGNvbW1lbnRzIGFsb25nIHdpdGggdGhlIG90aGVyIGxhc3QgY2Fs bCBjb21tZW50cy48YnI+DQo8YnI+DQpEb2N1bWVudDogZHJhZnQtaWV0Zi1pZHItYmdwLW9wZW4t cG9saWN5LTE1LnR4dDxicj4NClJldmlld2VyOiBNYWNoIENoZW48YnI+DQpSZXZpZXcgRGF0ZTog MjAyMS8wNS8xMzxicj4NCkludGVuZGVkIFN0YXR1czogU3RhbmRhcmRzIFRyYWNrPGJyPg0KPGJy Pg0KU3VtbWFyeTo8YnI+DQo8YnI+DQpUaGlzIGRvY3VtZW50IGlzIGJhc2ljYWxseSByZWFkeSBm b3IgcHVibGljYXRpb24sIGJ1dCBoYXMgbml0cyBhbmQgbWlub3IgY29uY2VybnMgdGhhdCBzaG91 bGQgYmUgY29uc2lkZXJlZCBwcmlvciB0byBiZWluZyBzdWJtaXR0ZWQgdG8gdGhlIElFU0cuPGJy Pg0KPGJyPg0KQ29tbWVudHM6PGJyPg0KPGJyPg0KU2VjdGlvbiA2LiA8YnI+DQpJdCBkb2VzIG5v dCBzcGVjaWZ5IGhvdyBhIHNwZWFrZXIgaGFuZGxlIGEgcm91dGUgd2l0aCBPVEMgYXR0cmlidXRl IGJ1dCB0aGUgc2VuZGVyJ3Mgcm9sZSBpcyB1bmtub3duLjxicj4NCjxicj4NCjxicj4NCk5pdHM6 PGJyPg0KPGJyPg0KU2VjdGlvbiAyLiA8YnI+DQpzLyB0aGVpciBjdXN0b21lcnMvaXRzIGN1c3Rv bWVyczxicj4NCjxicj4NClNlY3Rpb24gMy48YnI+DQpzL0FsbG93ZWQgUm9sZSB2YWx1ZXMvQWxs b3dlZCBSb2xlczxicj4NCjxicj4NClNlY3Rpb24gNC48YnI+DQpJdCdzIGJldHRlciB0byB1cGRh dGUgdGhlIHRhYmxlIGFzIGZvbGxvd3M6PGJyPg0KPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm IzQzOy0tLS0tLS0mIzQzOy0tLS0tLS0tLS0tLS0tLS0tLS0tLSYjNDM7PGJyPg0KJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyB8IFZhbHVlIHwgUm9sZSBuYW1lJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDt8PGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmIzQzOy0tLS0tLS0mIzQz Oy0tLS0tLS0tLS0tLS0tLS0tLS0tLSYjNDM7PGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyB8Jm5i c3A7ICZuYnNwOzAmbmJzcDsgJm5ic3A7fCBTZW5kZXIgaXMgUHJvdmlkZXImbmJzcDsgfDxicj4N CiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgfCZuYnNwOyAmbmJzcDsxJm5ic3A7ICZuYnNwO3wgU2VuZGVy IGlzIFJTJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IHw8YnI+DQombmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7IHwmbmJzcDsgJm5ic3A7MiZuYnNwOyAmbmJzcDt8IFNlbmRlciBpcyBSUy1jbGllbnQgfDxi cj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgfCZuYnNwOyAmbmJzcDszJm5ic3A7ICZuYnNwO3wgU2Vu ZGVyIGlzIEN1c3RvbWVyJm5ic3A7IHw8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IHwmbmJzcDsg Jm5ic3A7NCZuYnNwOyAmbmJzcDt8IFNlbmRlciBpcyBQZWVyJm5ic3A7ICZuYnNwOyAmbmJzcDsg fDxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgfCA1LTI1NSZuYnNwOyB8IFJlc2VydmVkJm5ic3A7 ICZuYnNwOyAmbmJzcDsgfCZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOzxicj4NCiZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJiM0MzstLS0tLS0tJiM0MzstLS0tLS0tLS0tLS0tLS0tLS0tLS0m IzQzOzxicj4NCjxicj4NClNlY3Rpb24gNS48YnI+DQpPTEQ6PGJyPg0KJnF1b3Q7SWYgdGhlIHJv bGUgb2YgdGhlIHJlY2VpdmluZyBzcGVha2VyIGZvciB0aGUgZUJHUCBzZXNzaW9uIGluPGJyPg0K Jm5ic3A7ICZuYnNwO2NvbnNpZGVyYXRpb24gaXMgaW5jbHVkZWQgaW4gVGFibGUgMSBhbmQgdGhl IG9ic2VydmVkIFJvbGUgcGFpciBpczxicj4NCiZuYnNwOyAmbmJzcDtub3QgaW4gdGhlIGFib3Zl IHRhYmxlLCZxdW90Ozxicj4NCk5FVzo8YnI+DQo8YnI+DQomcXVvdDtJZiB0aGUgb2JzZXJ2ZWQg Um9sZSBwYWlyIGlzIG5vdCBpbiB0aGUgYWJvdmUgdGFibGUsJnF1b3Q7PGJyPg0KPGJyPg0KSU1I TywgaXQncyByZWR1bmRhbnQgdG8gaW5jbHVkZSAmcXVvdDtJZiB0aGUgcm9sZSBvZiB0aGUgcmVj ZWl2aW5nIHNwZWFrZXIgZm9yIHRoZSBlQkdQIHNlc3Npb24gaW4gY29uc2lkZXJhdGlvbiBpcyBp bmNsdWRlZCBpbiBUYWJsZSAxJnF1b3Q7LCBqdXN0IGtlZXAgdGhlIHNlY29uZCBoYWxmIG9mIHRo ZSBzZW50ZW5jZSBpcyBlbm91Z2guPGJyPg0KPGJyPg0KU2VjdGlvbiA1LjE8YnI+DQo8YnI+DQpz L3NlbmQgYSBzZW5kIGEvc2VuZCBhLCB0aGVyZSBpcyBhIHJlZHVuZGFudCAmcXVvdDtzZW5kIGEm cXVvdDsuPGJyPg0KPGJyPg0KQmVzdCByZWdhcmRzLDxicj4NCk1hY2g8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIj48YnIgY2xlYXI9ImFsbCI+DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiPi0tIDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPkJlc3QgcmVnYXJkcyw8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiPkFsZXhhbmRlciBBemltb3Y8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_5b1c53aa2e9c4a18b03b95fb7b00abf2huaweicom_-- From nobody Sat May 29 14:20:06 2021 Return-Path: X-Original-To: rtg-dir@ietf.org Delivered-To: rtg-dir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 58E5B3A2065; Sat, 29 May 2021 14:20:00 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Adrian Farrel via Datatracker To: Cc: draft-ietf-idr-bgpls-srv6-ext.all@ietf.org, idr@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.30.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <162232320026.7852.16606328132879450829@ietfa.amsl.com> Reply-To: Adrian Farrel Date: Sat, 29 May 2021 14:20:00 -0700 Archived-At: Subject: [RTG-DIR] Rtgdir early review of draft-ietf-idr-bgpls-srv6-ext-07 X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 May 2021 21:20:01 -0000 Reviewer: Adrian Farrel Review result: Has Issues I have been selected to do a routing directorate "early" review of this draft. https://datatracker.ietf.org/doc/draft-ietf-idr-bgpls-srv6-ext 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. In this case, it appears that the review request was triggered by the request to the AD for publication. The purpose of this early review is to ensure as wide of a review as possible. For more information about the Routing Directorate, please see http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir Document: draft-ietf-idr-bgpls-srv6-ext-07.txt Reviewer: Adrian Farrel Review Date: 29-May-2021 Intended Status: Standards Track == Summary == Some minor issues and lot of nits. == Comments == I am one of the Designated Experts for the BGP-LS registries and I had previously considered the draft when an Early Allocation request was made. That request was approved. The document is clear enough and I believe I could implement it if I had to. The approach described in this document is consistent with the body of BGP-LS work, but I think it is important to note that the mechanism set out here differs slightly from the mechanism defined to do similar function with SR-MPLS. This distinction is clearly made in Appendix A. However, the WG chairs and AD will want to be sure that the WG recognise this difference and are OK with having two slightly different mechanisms running side by side. There are some Minor Issues that I think should be addressed before IETF Last Call in case they create any points that community review might object to. There are also quite a lot of nits in the document. I have tried to capture them below, but the large number means I may have missed some. I recommend fixing these before IETF Last Call so that other reviewers has a cleaner document to look at. == Minor Issues == You will need to reduce the number of front-page authors to five or fewer, or you will need to provide the document shepherd with a credible reason to diverge from this rule. --- Section 1 On the similar lines, introducing the SRv6 related information in BGP-LS allows consumer applications that require topological visibility to also receive the SRv6 SIDs from nodes across a domain or even across Autonomous Systems (AS), as required. I caution you to be *very* careful with the word "domain". The IESG has recently been concerned by the definition contained in 8402. In that document, the "SR domain" (also just "domain") is the collection of all interconnected SR-capable nodes. Here (and in other parts of the document) I think you are using "domain" in a more restricted sense. I don't know how you fix that, but I believe you should do something. Perhaps you can call out the terminology issues here by noting the 8402 definition and specifically defining what you mean by your local definition of "domain". --- Section 2 The SRv6 SIDs associated with the node are advertised using the BGP- LS SRv6 SID NLRI introduced in this document. This enables the BGP- LS encoding to scale to cover a potentially large set of SRv6 SIDs instantiated on a node with the granularity of individual SIDs and without affecting the size and scalability of the BGP-LS updates. The claims of scalability are not expanded here or anywhere else in the document. Scalability of BGP-LS is important, so I'd prefer some explanation. But if that isn't available, it might be better to leave out these mentions. --- 4.1, 4.2, and 7.2 You should consider asking IANA to create a registry for the flags fields. This would make it easier to keep track of future assignments. You should also state clearly that the three flags fields are aligned so that an addition to one is always also made to the other (if this is the case). --- 4.1 and 4.2 Sub-TLVs : Used to advertise sub-TLVs that provide additional attributes for the specific SRv6 SID. You need to say where these sub-TLVs are defined. If there are none defined yet, you should say so and explain why some might be defined in the future. You should also say where the sub-TLV type values are tracked. Compare with 5.1 --- 5.1 You should say where the sub-TLVs are tracked, and you should consider a registry for the flags. --- 7.1 The SRv6 Endpoint Behavior TLV is a mandatory TLV that MUST be included in the BGP-LS Attribute associated with the BGP-LS SRv6 SID NLRI. What if it is missing? --- 8. The total of the locator block, locator node, function and argument lengths MUST be less than or equal to 128. What if they add up to more than 128? --- Well done for including Appendix A. I assume that the WG discussed the relative merits of having a slightly different approach for SR-MPLS and SRv6, and contrasted that with the benefits of a consistent approach. I personally think that making a difference is unfortunate, but if the WG was happy with this decision then I guess it's OK. Without launching into a sales pitch, it might be nice if Appendix A was to very briefly explain why the difference. == Nits == You have: - "SR for [the] MPLS data-plane" (Abstract) - SR/MPLS (Section 4.1) - "SR with [the] MPLS data-plane" (Section 7.2) - "SR-MPLS" (Sections 10 and 11, Appendix A) 8402 has "SR-MPLS" --- Abstract s/Segment Routing (SR) over IPv6 (SRv6)/Segment Routing over IPv6 (SRv6)/ s/by the various/by various/ OLD BGP Link-state (BGP-LS) address-family solution for SRv6 is similar to BGP-LS for SR for MPLS data-plane. This draft defines extensions to the BGP-LS to advertise SRv6 Segments along with their behaviors and other attributes via BGP. NEW This document defines extensions to BGP Link-state (BGP-LS) to advertise SRv6 segments along with their behaviors and other attributes via BGP. The BGP-LS address-family solution for SRv6 described in this document is similar to BGP-LS for SR for the MPLS data-plane defined in a separate document. END --- Section 1 s/A SRv6 Segment/An SRv6 segment/ OLD The IS-IS [I-D.ietf-lsr-isis-srv6-extensions] and OSPFv3 [I-D.ietf-lsr-ospfv3-srv6-extensions] link-state routing protocols have been extended to advertise some of these SRv6 SIDs and SRv6-related information. NEW The IS-IS and OSPFv3 link-state routing protocols have been extended to advertise some of these SRv6 SIDs and SRv6-related information [I-D.ietf-lsr-isis-srv6-extensions], [I-D.ietf-lsr-ospfv3-srv6-extensions]. END s/Certain other/Other/ s/On the similar lines/On similar lines/ s/(e.g./(e.g.,/ --- Section 2 o SRv6 SID of the IGP Adjacency SID or the BGP EPE Peer Adjacency SID [RFC8402] is advertised via SRv6 End.X SID TLV introduced in this document (Section 4.1) o SRv6 SID of the IGP Adjacency SID to a non-Designated Router (DR) or non-Designated Intermediate-System (DIS) [RFC8402] is advertised via SRv6 LAN End.X SID TLV introduced in this document (Section 4.2) 1. s/SRv6 SID/The SRv6 SID/ twice 2. It is confusing that the first bullet talks about advertising the IGP Adjacency with no qualification, but the second bullet talks about the IGP Adjacnecy to a non-DR or non-DIS. That appears to make the first bullet a superset of the second bullet. Sections 4.1 and 4.2 make this a lot clearer: perhaps you could bring some of that clarity to these bullets. --- Section 2 o SRv6 Locator is advertised via SRv6 Locator TLV introduced in this document (Section 5.1) s/SRv6/The SRv6/ s/SRv6/the SRv6/ --- 2. The SRv6 SIDs associated with the node are advertised using the BGP- LS SRv6 SID NLRI introduced in this document. Please include a forward pointer to Section 6. --- 2. o The endpoint behavior of the SRv6 SID is advertised via SRv6 Endpoint Behavior TLV (Section 7.1) s/via SRv6/via the SRv6/ --- 2. o The BGP EPE Peer Node and Peer Set context for a Peer Node and Peer Set SID [RFC8402] respectively is advertised via SRv6 BGP EPE Peer Node SID TLV (Section 7.2) s/via SRv6/via the SRv6/ The text is hard to read. Maybe... o The BGP EPE Peer Node context for a Peer Node, and the Peer Set context for a Peer Set SID [RFC8402] are advertised via the SRv6 BGP EPE Peer Node SID TLV (Section 7.2). --- 2. s/(e.g./(e.g.,/ --- 2. When the BGP-LS router is advertising topology information that it sources from the underlying link-state routing protocol (as described in [RFC7752]), then it maps the corresponding SRv6 information from the SRv6 extensions for IS-IS [I-D.ietf-lsr-isis-srv6-extensions] and OSPFv3 [I-D.ietf-lsr-ospfv3-srv6-extensions] protocols to their BGP- LS TLVs/sub-TLVs for all SRv6 capable nodes in that routing protocol domain. When the BGP-LS router is advertising topology information from the BGP routing protocol (e.g. for EPE as described in [I-D.ietf-idr-bgpls-segment-routing-epe]), then it advertises the SRv6 information from the local node alone. I'd suggest moving this paragraph to be the second in the section as it explains what is going on. --- 3.1 and This TLV maps to the SRv6 Capabilities sub-TLV and the SRv6 Capabilities TLV of the IS-IS and OSPFv3 protocol SRv6 extensions respectively. : : o Flags: 2 octet field. The following flags are defined: 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |O| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2: SRv6 Capability TLV Flags Format * O-flag: If set, then router is capable of supporting SRH O-bit Flags, as specified in [I-D.ietf-6man-spring-srv6-oam]. * The rest of the bits are reserved for future use and MUST be set to 0 and ignored on receipt. Would be good to include references for the two capabilities TLVs. It would also help to not include the bit definitions here. I think I am correct that if a new bit is defined for inclusion in the ISIS SRv6 Capabilities sub-TLV flags field, you expect to pick it up here automatically. It looks like the mapping is in the wrong direction. I.e., this TLV maps from, not to, the IGP TLVs. I think you would say... This TLV maps from the SRv6 Capabilities sub-TLV of the IS-IS SRv6 extensions [ref] and the SRv6 Capabilities TLV of the OSPFv3 SRv6 extensions [ref]. : : o Flags: 2 octet field. The contents of this field are copied from the IS-IS or OSPF SRv6 Capabilities TLVs and have the same meaning. For what it's worth, it's a pitty that there is no registry for tracking the flags, but that's a problem with draft-ietf-lsr-isis-srv6-extensions and not with this document. --- 4.1 s/End.X with USP and/End.X with USP, and/ (twice) s/This TLV is also used by BGP/This TLV is also used by BGP-LS/ --- 4.1 Figures 3 and 5 Convetion is that if you show all of the bytes, you close the start and end of the lines with a vertical pipe "|". Or you can leave out bytes and close the line ends with a tilda "~" or double slash "//" (see Figure 9). --- 4.1, 4.2, 5.1, and 6.1 Can you say what the Length field is. "The length of the value part of the TLV in bytes including any sub-TLVs that may be present." ?? --- 4.1, 4.2, 5.1, and 7.1 Algorithm: 1 octet field. Algorithm associated with the SID. Algorithm values are defined in the IANA IGP Algorithm Type registry. It would be good to add a reference to RFC 8665 or to https://www.iana.org/assignments/igp-parameters/igp-parameters.xhtml. --- 4.2 s/normally an IGP node only/an IGP node normally only/ s/to announce SRv6 SID/to announce the SRv6 SID/ s/(i.e./(i.e.,/ s/End.X with USP and/End.X with USP, and/ (twice) --- 4.2 The IS-IS and OSPFv3 SRv6 LAN End.X SID TLVs have the following format: Do you mean the BGP-LS TLVs? --- 5.1 OLD As specified in [RFC8986], an SRv6 SID comprises of Locator, Function and Argument parts. NEW As specified in [RFC8986], an SRv6 SID comprises Locator, Function, and Argument parts. END --- 6. Figure 9 There is a broken format line in the middle of the figure. --- 6. The figure has | Identifier | | (64 bits) | and the text has o Identifier: 8 octet value as defined in [RFC7752]. Be consistent? --- 6. o Protocol-ID: 1 octet field that specifies the protocol component through which BGP-LS learns the SRv6 SIDs of the node. The Protocol-ID registry was created by [RFC7752] and then extended by other BGP-LS extensions. - s/Protocol-ID registry/BGP-LS Protocol-ID registry/ - Probably, "...and then additional assignments were made for other BGP-LS extensions." --- 7.1 s/are bound with a SID/are bound to a SID,/ --- 7.2 s/The similar/Similar/ --- 7.2 is an optional TLV for use in the BGP-LS Attribute for an SRv6 SID Is that "OPIONAL"? But then... This TLV MUST be included along with SRv6 SIDs that are associated with the BGP Peer Node or Peer Set functionality. ... is confusing. I suspect that the second sentence should be... If this TLV is present, it MUST be accompanied by the SRv6 SIDs that are associated with the BGP Peer Node or Peer Set functionality. --- 7.2 s/For a SRv6/For an SRv6/ --- 8. s/SRv6 SID Structure TLV is used/The SRv6 SID Structure TLV is used/ --- 8. optional TLV Is that "OPTIONAL"? --- 9. OLD This document requests assigning code-points from the IANA "Border Gateway Protocol - Link State (BGP-LS) Parameters" registry as described in the sub-sections below. NEW IANA has made early allocations of code points from the "Border Gateway Protocol - Link State (BGP-LS) Parameters" registry as described in the sub-sections below. IANA is requested to updated the references to indicate this document when it is published as an RFC. END --- 9.2 It would make sense to list the codepoints in numeric order. I.e., lift 518 to the top. --- 10. s/(e.g./(e.g.,/ --- 11. s/(e.g./(e.g.,/ --- Appendix A s/session(s)/session/ s/advertised as attribute/advertised as attributes/