Re: [auth48] AUTH48: RFC-to-be 9479 <draft-ietf-lsr-rfc8919bis-04> for your review
"Wim Henderickx (Nokia)" <wim.henderickx@nokia.com> Sun, 01 October 2023 04:57 UTC
Return-Path: <wim.henderickx@nokia.com>
X-Original-To: auth48archive@ietfa.amsl.com
Delivered-To: auth48archive@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD650C1524AC; Sat, 30 Sep 2023 21:57:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.105
X-Spam-Level:
X-Spam-Status: No, score=-2.105 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=nokia.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PRu_OJFTxdAK; Sat, 30 Sep 2023 21:57:07 -0700 (PDT)
Received: from EUR05-VI1-obe.outbound.protection.outlook.com (mail-vi1eur05on20702.outbound.protection.outlook.com [IPv6:2a01:111:f400:7d00::702]) (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 78B46C1522D9; Sat, 30 Sep 2023 21:57:06 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=SQygNkitw0oW22rCfXCKQkMjpJSle2hITqfsEkgGVvb8Kqq766XlCFJBkX6b1EdyL85H4EdVjluTpOuJkVT/6OptMK5/YgG8+7H0E7p6X3IBvJHEEv8ZsN6Dws5MUIXoc+AdSUzjqHIVtNTtv7j+M+f8MCEYG/GSlmgxBNGpeU59XQbZM/tRfstAGBbwuclcVOVhDvjntafjWTTuITqU34PUqjoTnAhPHB1dw88PXfMTQSLdHaQdHjPVPFCfbW7sf0OXgW8jsWt/yCwTaNWHy0ndA1nWw8YrE6WKEGP+V8kjDa+qO/hQe5+d2PsYdTSbBZkhPat7vYLJnidystgAPg==
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-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=BQfMMAceWYsbsBTa1kkdhPxe6zfGUxN0yvhrBSa9gfA=; b=RmOQIJjDExjUa+o8bjKkZ6DIy4l62tME3jAMA7VKbM5hR2AiedQxVV3wGM5S8Opgub0/TApa6lMu81WGlHChL/E6jP50Wp0pX6T4npzk4s5Rf4nhaEDWvpcu4DlUG+HDrEQ+QAK1lyfwY0EAAiqj/CDhhxH298VR2seySG0ZWUZkMSWoD5YpJUwpLLTlqbZXpx5wCD/rVHmrfdWMoM1Ly8v41UlE8MlMsOiZ5Kx1F6OslHwKYllTD9EcPF/+hTRhnhSnBuPnE5wAucPyslydsMEaGQMk25q5eFW625BMPeGh7rDe9KGIKqg5iFPTYOBBu8rXA/CICwK5pYZoBQrCMg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=nokia.com; dmarc=pass action=none header.from=nokia.com; dkim=pass header.d=nokia.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=BQfMMAceWYsbsBTa1kkdhPxe6zfGUxN0yvhrBSa9gfA=; b=Ocmx9qL53dWIHsCICR0AlUKXu8Ug1sKYKcnO/xPlTuKkYvc1h19o3+2WcE2y5e0Sp6sdBwqCMGx17gOsputYf94C5pa6T7K8bdP9gVR6nsBzBHW9C543Ex14Z+uasfQDdQ0+0qBAJyP7WVyf5KUDbIXvliDzCapJfofcCGHkK/4E+gpu4wbaVE+Dz/JwNVrdW//kCATaSa7fulNB+zZAV1UfwH5FopteidngNF9ypg5Cg2//yZYF3UEphn18Iumz8iE95hIzhTvKHA0O8UBf2DuSK/kEtkPQ5p8g0+GdrHvDzIZSqx/j37wZbjq8ubcEjSRMfEGFCi7PQeHnPvrHUw==
Received: from DB7PR07MB4506.eurprd07.prod.outlook.com (2603:10a6:5:2c::17) by PAXPR07MB8421.eurprd07.prod.outlook.com (2603:10a6:102:2bc::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6838.28; Sun, 1 Oct 2023 04:57:01 +0000
Received: from DB7PR07MB4506.eurprd07.prod.outlook.com ([fe80::d9d2:ac96:462f:ba7f]) by DB7PR07MB4506.eurprd07.prod.outlook.com ([fe80::d9d2:ac96:462f:ba7f%6]) with mapi id 15.20.6838.024; Sun, 1 Oct 2023 04:57:00 +0000
From: "Wim Henderickx (Nokia)" <wim.henderickx@nokia.com>
To: Peter Psenak <ppsenak@cisco.com>, Lynne Bartholomew <lbartholomew@amsl.com>, "Les Ginsberg (ginsberg)" <ginsberg@cisco.com>
CC: Acee Lindem <acee.ietf@gmail.com>, "rfc-editor@rfc-editor.org" <rfc-editor@rfc-editor.org>, "stefano@previdi.net" <stefano@previdi.net>, "jdrake@juniper.net" <jdrake@juniper.net>, "lsr-ads@ietf.org" <lsr-ads@ietf.org>, "lsr-chairs@ietf.org" <lsr-chairs@ietf.org>, "chopps@chopps.org" <chopps@chopps.org>, "jgs@juniper.net" <jgs@juniper.net>, "auth48archive@rfc-editor.org" <auth48archive@rfc-editor.org>
Thread-Topic: AUTH48: RFC-to-be 9479 <draft-ietf-lsr-rfc8919bis-04> for your review
Thread-Index: AQHZ5PrhBsCKEsRUukWBSEIUeJIZD7AsMFSAgAML14CAABjIAIABe5CAgAAYK4CAAStngIABKEuAgAFBDMk=
Date: Sun, 01 Oct 2023 04:57:00 +0000
Message-ID: <DB7PR07MB450650767BA325CC10E164BE83C6A@DB7PR07MB4506.eurprd07.prod.outlook.com>
References: <20230911215652.590128541C@rfcpa.amsl.com> <BY5PR11MB433786974EDDE64AC8B5C032C1FCA@BY5PR11MB4337.namprd11.prod.outlook.com> <EB21DBF6-F384-4244-B29A-8E2D245C10BB@amsl.com> <MN2PR11MB43523266A1F09B842571C8D3C1C2A@MN2PR11MB4352.namprd11.prod.outlook.com> <96716D85-7E98-49CA-BF0C-81490F29403F@amsl.com> <MN2PR11MB4352EA4198E76460A58CF406C1C1A@MN2PR11MB4352.namprd11.prod.outlook.com> <22E4F0B2-84A5-4275-B196-5760C123982F@amsl.com> <f2366083-ea7b-20da-f93e-a13bbfbcd0db@cisco.com>
In-Reply-To: <f2366083-ea7b-20da-f93e-a13bbfbcd0db@cisco.com>
Accept-Language: nl-BE, en-US
Content-Language: en-GB
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=nokia.com;
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: DB7PR07MB4506:EE_|PAXPR07MB8421:EE_
x-ms-office365-filtering-correlation-id: f344aeaa-9029-4879-b221-08dbc23ad8fa
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: K9T8xOEx2dTS5LXXt6VBywPqFGVUFQV0B4nk0MU1t9IidPnocYIX9rhyF8i4IzejEXqqd+80bAgjOGoSUBtEGYKzbPtHQRfM19G2z8K7R6XQe6rzDpx8xNLEHAO46XJ1ZokS5MYAVlSHnIBZSQz2WRcMLgCh+ODdVA3BafHcXIrB3bvhAHfOcFKZY+TkPMb67kLyjmiBs3QieUCPqxjz+xpTTtSsvzLZMY6MR4TUE9h/4zFue6avJLDjnekbfsGtqR+VU9dvBw+c23N9actizz96hsxowmqVv5Mz0ULvgVrDPc/GfemKF1ABxncL1xn13T3hP0sWmHhAHRKCu2yPqoyGWVgcGN6x1nfma9z/g4++2J3Pv9nkV0hhWU+jHf7OuMCghQg/CjLd11bFwVn1y983qpDQictmfLfSe4oKJh+DhMrJCNxA0S61XCtV+RbagIrRNCquR5shGHTSwuk/aP2wYRlSEdXibgO8HiFBfQIKLPmb6T8ZAcDLXM1o4olqeYbqDffSFuY9n5Sz67pvBxvH0ulny2PERwLCZHS5pBgyWV+RAQHYze5gd8Yk0ueToAzkXAIUjuj5gmPU+KmTiMAlpvWuU6IDcZsyY/AbrbRtjlyH5nUtzFubidTtF4+pSpfCubJFYMjBp/bWRSPqcwQpNTX/U0LaQugLh4/diYyGTKXwZZcSlI6uRzpkxBwY
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DB7PR07MB4506.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230031)(39860400002)(136003)(346002)(396003)(376002)(366004)(230922051799003)(451199024)(186009)(64100799003)(1800799009)(33656002)(86362001)(84970400001)(55016003)(26005)(66574015)(55236004)(2906002)(53546011)(9686003)(82960400001)(30864003)(7416002)(122000001)(6506007)(7696005)(71200400001)(83380400001)(966005)(478600001)(8936002)(4326008)(8676002)(38100700002)(52536014)(166002)(38070700005)(64756008)(66556008)(54906003)(66446008)(66476007)(21615005)(76116006)(41300700001)(316002)(5660300002)(110136005)(66946007)(579004)(559001); DIR:OUT; SFP:1102;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: b4CSOiXwYg/XBZta5F+tHukJs3yyB7DaG84KjI/+Y5TVk77AUk3bNofPKEw4L8277qq7qb6Sbt/Y/Cu9MVQCUAmheQwB6W+JkKSeotcwj+NV01bTYGgnJA4nGadFSnkJGk1W/ZZJteUjGsTjQb1wW5DcPWb5wcHS0ZxzCUCpaRoCAQ7Zqa79w5Qj82r+4DM/KgTguglRiaelXLmN8EQQx8tmnjnlMtuXVoeDEPq/PdYBHP9aPztoGTGCpnbrcQQmJv2V2lIK/3rYboVxdbYUvQcL78tIi9do1j0f0APBNHBl249kXCctcQjm7b5iPcVkjj48ePyWRJ2mUgbjVjttn8cL+V3sA20uRKp7ipRDtBCkpg+tOIw5eWVa8HUlXc8JLKXrPefje176RfDOyYIN67wr8YTHbBVr386Oafxxm1wbkuJ1xac5UK34gIzZTQDYJwDOHXbWBR/3/YKWcpouva/o8wlLKtyhjtwYCuCM5X1LcbybpLnd0x277GncjAwVY0uvaphOASZ67cQRjw0XQQ6qmXbWuOdQamvllp66XzfhGKWCS3aSTo64BBq+6oOqMQ/gFj2pUqUZwDJ0/DZcq1cHMBORbq9/mDSMmTK/vJk9efF3irHipybMKaZ0ZY11ZeaqcMAPCSXG05MehderIV3TBMFwBJHMVU3rIJnx8IDyxk8tf/3zaywxV7cXduk+ngq+2PpcgH99p76sXDkDqoFoGh7i8HRCFb8OyA4f2zkWmNIuQItVW8bRPwGkwZAEEbIzAFNvd12DD8A8FF0c0QHgZzJqGEZVWCPziX8675xwjX48DEX2Fj9T1iUXApx7PZTmx82c8v5HQyGVfhkUytGI+4wuMVE86vl+udYYMQ1+uRRJvaaBC28qf34QXmpx28xSHzJcUJV9CuU8SaQ4eagUe9x3WrRZ5eBnBAvhsBMK3wXsF6JdCcB0USVVaJPaFaWJ9iLzmWaBz8eLGYv5MEUamXc5G1Lh2+dWXMw2M2vBRgm0iPdehjMEee2mjOlD/1SQS6xcTlAfiIoVgEjOdKtf9mWXN2VJhD2ojzm4serDssCzNOfpqXCXPZGqrJM6t48bGieb9954xbzkvF8odX97Uf6jQO6b0o+yH2pxi7FsjNKjal3m25q38hBmvH2FrsyDrV7yF0MKYGa496n4YxXSbf0BcvpA2o4VEUWAvE6D/ILjKBa+6s0ZG66abMtOOtwpmdy1Yw+yUTBAHVDBbT0PAa9F/XrByh8MqqTHarZ4qFaYqZZdGOy5Lh7xOrXHSaSCkHO3nKEdqTVs5y6OFeO2hA9VYKduhMsRAhXVb8BAMkJmuPuO5ZPB8GNMuFJm9P65QJ89ZyzlkpN7r2ossOttTnBlXmFfRGwSxzxkIPMwalnhjYyDXgSbB+hIKEdmJVUvHdFnEQsdUmqSu6Z97u23QomeBc/EDy0gm/iHMsnvbZb8dQUnNtpstEz5Xiaa+tT4iaV+KsfoZyMCPIbceQHq7hQEXMz56nDn38GeRfpoYX9Y6lpTEBpyg5k/hoRRlFY9E6xkKu5pvBV4HWc4zNKOUWT6/m51r5ZsWKgE+RdJ5ZCozW5VO9uNA4lz/Ge1+dezBRm1ketL3ygYGrXHMA==
Content-Type: multipart/alternative; boundary="_000_DB7PR07MB450650767BA325CC10E164BE83C6ADB7PR07MB4506eurp_"
MIME-Version: 1.0
X-OriginatorOrg: nokia.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: DB7PR07MB4506.eurprd07.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: f344aeaa-9029-4879-b221-08dbc23ad8fa
X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Oct 2023 04:57:00.6971 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: mHT9tQYyUxtaoTZFhzuCzvqpAlMp+ZMXtAD4yhKULB1FklLHOgYj4tmhVsp7oQOCLxX/79PIwTJc5yGek+0DSlEDRndNC1M+xzy+OmqiKFw=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PAXPR07MB8421
Archived-At: <https://mailarchive.ietf.org/arch/msg/auth48archive/JiADm0udarsc-LB0q0dYx4qXe88>
Subject: Re: [auth48] AUTH48: RFC-to-be 9479 <draft-ietf-lsr-rfc8919bis-04> for your review
X-BeenThere: auth48archive@rfc-editor.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: "Archiving AUTH48 exchanges between the RFC Production Center, the authors, and other related parties" <auth48archive.rfc-editor.org>
List-Unsubscribe: <https://mailman.rfc-editor.org/mailman/options/auth48archive>, <mailto:auth48archive-request@rfc-editor.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/auth48archive/>
List-Post: <mailto:auth48archive@rfc-editor.org>
List-Help: <mailto:auth48archive-request@rfc-editor.org?subject=help>
List-Subscribe: <https://mailman.rfc-editor.org/mailman/listinfo/auth48archive>, <mailto:auth48archive-request@rfc-editor.org?subject=subscribe>
X-List-Received-Date: Sun, 01 Oct 2023 04:57:11 -0000
I also approve From: Peter Psenak <ppsenak@cisco.com> Date: Saturday, 30 September 2023 at 11:48 To: Lynne Bartholomew <lbartholomew@amsl.com>, Les Ginsberg (ginsberg) <ginsberg@cisco.com> Cc: Acee Lindem <acee.ietf@gmail.com>, rfc-editor@rfc-editor.org <rfc-editor@rfc-editor.org>, stefano@previdi.net <stefano@previdi.net>, Wim Henderickx (Nokia) <wim.henderickx@nokia.com>, jdrake@juniper.net <jdrake@juniper.net>, lsr-ads@ietf.org <lsr-ads@ietf.org>, lsr-chairs@ietf.org <lsr-chairs@ietf.org>, chopps@chopps.org <chopps@chopps.org>, jgs@juniper.net <jgs@juniper.net>, auth48archive@rfc-editor.org <auth48archive@rfc-editor.org> Subject: Re: AUTH48: RFC-to-be 9479 <draft-ietf-lsr-rfc8919bis-04> for your review CAUTION: This is an external email. Please be very careful when clicking links or opening attachments. See the URL nok.it/ext for additional information. Hi Lynne, you have my approval as well. thanks, Peter On 29/09/2023 18:07, Lynne Bartholomew wrote: > Hi, Les. > > Thanks for the email. We have noted your approval (set to 9/27/2023, per your previous email) on the AUTH48 status page: > > https://www.rfc-editor.org/auth48/rfc9479 > > Thanks again for helping us with AUTH48! > > RFC Editor/lb > >> On Sep 28, 2023, at 3:15 PM, Les Ginsberg (ginsberg) <ginsberg@cisco.com> wrote: >> >> Lynne - >> >> Thanx for the clarification. >> I still prefer no table names - I can live with the format limitations. >> >> Les >> >>> -----Original Message----- >>> From: Lynne Bartholomew <lbartholomew@amsl.com> >>> Sent: Thursday, September 28, 2023 1:49 PM >>> To: Les Ginsberg (ginsberg) <ginsberg@cisco.com> >>> Cc: Acee Lindem <acee.ietf@gmail.com>; rfc-editor@rfc-editor.org; Peter >>> Psenak (ppsenak) <ppsenak@cisco.com>; stefano@previdi.net; >>> wim.henderickx@nokia.com; jdrake@juniper.net; lsr-ads@ietf.org; lsr- >>> chairs@ietf.org; chopps@chopps.org; jgs@juniper.net; auth48archive@rfc- >>> editor.org >>> Subject: Re: AUTH48: RFC-to-be 9479 <draft-ietf-lsr-rfc8919bis-04> for your >>> review >>> >>> Hi, Les. >>> >>> Thank you for the clarification re. question 14)b) and the erratum text. >>> >>> As for the placement of the "Table X" lines in the PDF and HTML files, this is a >>> feature of xml2rfc v3, and we're not able to center the "Table X" lines in PDF or >>> HTML. >>> >>> We know that the topic of table titles in this document was covered earlier -- >>> not to use any for this document -- but if the tables had titles, this effect would >>> not be so jarring in the PDF and HTML files. >>> >>> Please let us know what you think; we'll wait to hear from you again before >>> noting your approval. >>> >>> Thanks for your patience! >>> >>> RFC Editor/lb >>> >>>> On Sep 27, 2023, at 3:10 PM, Les Ginsberg (ginsberg) >>> <ginsberg@cisco.com> wrote: >>>> >>>> Lynne - >>>> >>>> I have checked all of the additional changes - they have all been completed to >>> my satisfaction. >>>> >>>> One minor formatting request - the "Table X" titles associated with each >>> table appear centered in the .txt file - but are left aligned (at the table >>> boundary) in the PDF and HTML files. >>>> Is it possible to have them centered in the PDF/HTML files as well? >>>> >>>> In regards to Question 14b - sorry for overlooking that. >>>> When I began work on the bis version, I noted that the Errata that had been >>> filed had a cut and paste error - there actually were no changes required to >>> Section 6.2 - but I had mistakenly cut and pasted the changes for Section 4.2 a >>> second time as if they should also be applied to Section 6.2. >>>> No one noticed this when discussing the Errata - and since the Errata is >>> formally marked as rejected (in favor of doing a bis version of the RFC) I saw >>> no reason to correct the already rejected Errata. >>>> >>>> Bravo to you for noticing this - but this is why there are no changes to >>> Section 6.2. 😊 >>>> >>>> Other than the minor format correction mentioned above, this latest version >>> has my approval. >>>> Thanx for all that you do. >>>> >>>> Les >>>> >>>>> -----Original Message----- >>>>> From: Lynne Bartholomew <lbartholomew@amsl.com> >>>>> Sent: Wednesday, September 27, 2023 1:42 PM >>>>> To: Les Ginsberg (ginsberg) <ginsberg@cisco.com>; Acee Lindem >>>>> <acee.ietf@gmail.com> >>>>> Cc: rfc-editor@rfc-editor.org; Peter Psenak (ppsenak) >>> <ppsenak@cisco.com>; >>>>> stefano@previdi.net; wim.henderickx@nokia.com; jdrake@juniper.net; lsr- >>>>> ads@ietf.org; lsr-chairs@ietf.org; chopps@chopps.org; jgs@juniper.net; >>>>> auth48archive@rfc-editor.org >>>>> Subject: Re: AUTH48: RFC-to-be 9479 <draft-ietf-lsr-rfc8919bis-04> for >>> your >>>>> review >>>>> >>>>> Hi, Les and Acee. >>>>> >>>>> Thank you for the emails. Les, thank you for your thorough review and >>> replies >>>>> to our questions. >>>>> >>>>> Les, we took a look at the five most recent RFCs that obsolete other RFCs >>>>> (RFCs 9399, 9411, 9436, 9438, and 9457) and found that in all five cases >>> the >>>>> RFC or RFCs being obsoleted were listed under Informative References. As >>> you >>>>> noted below, Informative Reference is indeed the appropriate choice here as >>>>> well, and we've moved the listing accordingly. Apologies for any confusion. >>>>> >>>>> Please advise re. our question 14)b): >>>>> >>>>>>> b) We see that the "NEW" text for Section 4.2 was applied per >>>>>>> <https://www.rfc-editor.org/errata/eid6630> but the "NEW" text for >>>>>>> Section 6.2 was not. Is this as desired (i.e., does "subject to the >>>>>>> restrictions specified in Section 4.2" in the first paragraph of >>>>>>> Section 6.2 handle the erratum information adequately?)? --> >>>>> >>>>> >>>>> The latest files are posted here (please refresh your browser): >>>>> >>>>> https://www.rfc-editor.org/authors/rfc9479.txt >>>>> https://www.rfc-editor.org/authors/rfc9479.pdf >>>>> https://www.rfc-editor.org/authors/rfc9479.html >>>>> https://www.rfc-editor.org/authors/rfc9479.xml >>>>> https://www.rfc-editor.org/authors/rfc9479-diff.html >>>>> https://www.rfc-editor.org/authors/rfc9479-rfcdiff.html >>>>> https://www.rfc-editor.org/authors/rfc9479-auth48diff.html >>>>> >>>>> https://www.rfc-editor.org/authors/rfc9479-xmldiff1.html >>>>> https://www.rfc-editor.org/authors/rfc9479-xmldiff2.html >>>>> >>>>> Please review our updates carefully, and let us know if anything is incorrect >>> or >>>>> we missed anything. >>>>> >>>>> Thanks again! >>>>> >>>>> RFC Editor/lb >>>>> >>>>> >>>>>> On Sep 26, 2023, at 8:11 AM, Les Ginsberg (ginsberg) >>>>> <ginsberg=40cisco.com@dmarc.ietf.org> wrote: >>>>>> >>>>>> Acee - >>>>>> >>>>>> >>>>>> I agree - but at most this is only informational. >>>>>> The discussion of what changed from RFC 8919 is informative from a >>>>> historical perspective - and may be useful to implementors who wrote code >>>>> based on RFC 8919 and want to check whether they need to make any >>>>> changes to be conformant to RFC 9479, but RFC 9479 should stand on its >>>>> own. If an implementor never knew of the existence of RFC 8919 it should >>> not >>>>> matter. >>>>>> >>>>>> So maybe Informative Reference is the appropriate choice here? >>>>>> >>>>>> Les >>>>> >>>>> >>>>> >>>>>> On Sep 26, 2023, at 7:55 AM, Acee Lindem <acee.ietf@gmail.com> wrote: >>>>>> >>>>>> I think it is common practice to reference the obsoleted draft in the >>>>> “Differences from RFCxxxx” text. >>>>>> >>>>>> Thanks, >>>>>> Acee >>>>> >>>>> >>>>> >>>>>> On Sep 25, 2023, at 8:13 PM, Les Ginsberg (ginsberg) >>>>> <ginsberg=40cisco.com@dmarc.ietf.org> wrote: >>>>>> >>>>>> And one other issue, highlighted in the review of RFC8920bis (to become >>>>> RFC9492) >>>>>> >>>>>> >>>>>> References to: >>>>>> >>>>>> [SEGMENT-ROUTING] >>>>>> Filsfils, C., Talaulikar, K., Ed., Voyer, D., Bogdanov, >>>>>> A., and P. Mattes, "Segment Routing Policy Architecture", >>>>>> RFC 9256, DOI 10.17487/RFC9256, July 2022, >>>>>> <https://www.rfc-editor.org/info/rfc9256>. >>>>>> >>>>>> Need to be changed to use [RFC9256]. >>>>>> The name [SEGMENT_ROUTING] occurs because when RFC 8919 was >>>>> published RFC9256 did not exist - it was still in draft form. >>>>>> >>>>>> Les >>>>> >>>>> >>>>> >>>>>> On Sep 25, 2023, at 7:50 PM, Les Ginsberg (ginsberg) >>>>> <ginsberg=40cisco.com@dmarc.ietf.org> wrote: >>>>>> >>>>>> One correction to my responses: >>>>>> >>>>>> Given that this document obsoletes RFC8919, it seems inappropriate to >>>>> include RFC 8919 as a reference at all. >>>>>> At a minimum, it seems odd to have an obsoleted document as a >>> Normative >>>>> Reference. >>>>>> >>>>>> What is the correct policy here? >>>>>> >>>>>> (Sorry for missing this earlier) >>>>>> >>>>>> Les >>>>> >>>>> >>>>> >>>>>> On Sep 25, 2023, at 3:39 PM, Les Ginsberg (ginsberg) >>>>> <ginsberg=40cisco.com@dmarc.ietf.org> wrote: >>>>>> >>>>>> Folks - >>>>>> >>>>>> Please find my responses to your questions inline below. >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: rfc-editor@rfc-editor.org <rfc-editor@rfc-editor.org> >>>>>>> Sent: Monday, September 11, 2023 2:59 PM >>>>>>> To: Les Ginsberg (ginsberg) <ginsberg@cisco.com>; Peter Psenak >>> (ppsenak) >>>>>>> <ppsenak@cisco.com>; stefano@previdi.net; >>> wim.henderickx@nokia.com; >>>>>>> jdrake@juniper.net >>>>>>> Cc: rfc-editor@rfc-editor.org; lsr-ads@ietf.org; lsr-chairs@ietf.org; >>>>>>> chopps@chopps.org; jgs@juniper.net; auth48archive@rfc-editor.org >>>>>>> Subject: Re: AUTH48: RFC-to-be 9479 <draft-ietf-lsr-rfc8919bis-04> for >>>>> your >>>>>>> review >>>>>>> >>>>>>> Authors, >>>>>>> >>>>>>> While reviewing this document during AUTH48, please resolve (as >>>>> necessary) >>>>>>> the following questions, which are also in the XML file. >>>>>>> >>>>>>> 1) <!-- [rfced] Please note that because the XML file for this document >>>>>>> was submitted in "prepped" format, we created a "nonprepped" copy of >>>>>>> the file in order to edit the document properly. This does not >>>>>>> impact the document's text but resulted in many changes to the XML >>>>>>> code (as can be viewed in the "xmldiff" files that will be provided >>>>>>> when this document moves to the AUTH48 state). --> >>>>>>> >>>>>> [LES:] Understood. Out of an abundance of caution I started with the XML >>>>> available from Datatracker for RFC 8919. It had a number of >>> "strangenesses" >>>>> (at least to me) - but I chose not to modify them as I wanted the >>> text/format >>>>> to be as close as possible to RFC 8919. >>>>>> I wish there had been a more "up to date" version of the XML for me to >>> start >>>>> with - but there was not. >>>>>> >>>>>>> >>>>>>> 2) <!-- [rfced] Please insert any keywords (beyond those that appear in >>> the >>>>>>> title) for use on <https://www.rfc-editor.org/search>. --> >>>>>>> >>>>>> [LES:] None added. >>>>>> >>>>>>> >>>>>>> 3) <!-- [rfced] Section 2: Please confirm that the citation for >>>>>>> RFC 7855 ("Source Packet Routing in Networking (SPRING) Problem >>>>>>> Statement and Requirements") is correct and will be clear to readers. >>>>>>> We are unsure if "Source Packet Routing" and "Segment Routing" mean >>> the >>>>>>> same thing. >>>>>>> >>>>>> [LES:] It is fine as is. Segment Routing is an instance of the more general >>>>> concept of "Source Packet Routing". >>>>>> >>>>>>> Original: >>>>>>> [RFC7855] discusses use cases and requirements for Segment Routing >>>>>>> (SR). --> >>>>>>> >>>>>>> >>>>>>> 4) <!-- [rfced] Sections 3 and subsequent: We see that the instances of >>>>>>> "TLVs 22, 23, 25, 141, 222, and 223" in RFC 8919 have been replaced >>>>>>> by "TLVs Advertising Neighbor Information" in running text in this >>>>>>> document. In some places, the new text reads oddly. Should "TLVs >>>>>>> Advertising Neighbor Information" be "TLVs advertising neighbor >>>>>>> information", as is done in the text on >>>>>>> <https://www.iana.org/assignments/isis-tlv-codepoints/>? >>>>>>> >>>>>> [LES:] I have looked at the use cases - I think the text is fine as is. >>>>>> >>>>>>> Original: >>>>>>> Existing advertisements used in support of RSVP-TE include sub-TLVs >>>>>>> for TLVs Advertising Neighbor Information and TLVs for Shared Risk >>>>>>> Link Group (SRLG) advertisement. >>>>>>> ... >>>>>>> 1) Application-Specific Link Attributes sub-TLV for TLVs Advertising >>>>>>> Neighbor Information (defined in Section 4.2). >>>>>>> ... >>>>>>> A new sub-TLV for TLVs Advertising Neighbor Information is defined >>>>>>> that supports specification of the applications and application- >>>>>>> specific attribute values. >>>>>>> ... >>>>>>> When the L-flag is set in the Application Identifier Bit Mask, all of >>>>>>> the applications specified in the bit mask MUST use the legacy >>>>>>> advertisements for the corresponding link found in TLVs Advertising >>>>>>> Neighbor Information. --> >>>>>>> >>>>>>> >>>>>>> 5) <!--[rfced] Tables 1 and 5: We have changed "TE Default Metric" to >>>>>>> "TE Default metric" per RFC 5305. We will ask that IANA make this >>>>>>> capitalization consistent in its registies prior to publication. >>>>>>> Please let us know of any objections. --> >>>>>>> >>>>>> [LES:] No objection >>>>>> >>>>>>> >>>>>>> 6) <!-- [rfced] We see that Table 1 has a title but Tables 2 through 7 >>>>>>> do not. Would you like all of the tables to have titles? If yes, >>>>>>> please provide them. >>>>>>> >>>>>> [LES:] Honestly, I think there is no need for a title for any of the tables - it is >>>>> the table format that is useful for presentation. >>>>>> So my choice would be to remove the title for Table I. >>>>>> If you insist, I can come up with names for the other tables, but I don’t >>> think >>>>> they add any value. >>>>>> >>>>>> >>>>>>> Original: >>>>>>> Table 1: Sub-TLVs for TLVs Advertising >>>>>>> Neighbor Information >>>>>>> Table 2 >>>>>>> Table 3 >>>>>>> Table 4 >>>>>>> Table 5 >>>>>>> Table 6 >>>>>>> Table 7 --> >>>>>>> >>>>>>> >>>>>>> 7) <!-- [rfced] Section 4.1: Should the section title be "Application >>>>>>> Identifier Bit Masks" or "Application Identifier Bit Mask Types"? >>>>>>> We ask because we see "two bit masks" in the sentence that follows, >>>>>>> as well as "zero-length Application Identifier Bit Masks" elsewhere. >>>>>>> >>>>>> [LES:] Title is fine as is. >>>>>> Application Identifier Bit Masks is the name of the set of fields (SABM >>>>> Length, UDABM Length, SABM bit mask, UDABM bit mask) which are >>> encoded >>>>> in the ASLA sub-TLV. >>>>>> >>>>>>> Original: >>>>>>> 4.1. Application Identifier Bit Mask --> >>>>>>> >>>>>>> >>>>>>> 8) <!-- [rfced] Sections 4.2 and 4.3: We cannot tell whether "SABM" in >>>>>>> these sentences refers to the SABM field or the SABM Length field. >>>>>>> Will these sentences be clear to readers, or should "SABM or UDABM >>>>>>> Length" be "SABM Length or UDABM Length"? >>>>>>> >>>>>> [LES:] It is probably clearer to say "SABM Length or UDABM length" >>>>>> >>>>>>> Original: >>>>>>> If the SABM or UDABM Length in the Application Identifier Bit Mask is >>>>>>> greater than 8, the entire sub-TLV MUST be ignored. >>>>>>> >>>>>>> When SABM or UDABM Length is non-zero and the L-flag is NOT set, all >>>>>>> applications specified in the bit mask MUST use the link attribute >>>>>>> advertisements in the sub-TLV. >>>>>>> ... >>>>>>> If the SABM or UDABM Length in the Application Identifier Bit Mask is >>>>>>> greater than 8, the entire sub-TLV MUST be ignored. >>>>>>> >>>>>>> When SABM or UDABM Length is non-zero and the L-flag is NOT set, all >>>>>>> applications specified in the bit mask MUST use SRLG advertisements >>>>>>> in the Application-Specific SRLG TLV. --> >>>>>>> >>>>>>> >>>>>>> 9) <!-- [rfced] Section 4.2: For ease of the reader, should "LSP" be >>>>>>> defined as "Label-Switched Path" per RFC 3209 or "Link State Protocol >>>>>>> Data Unit" per RFC 5305? >>>>>> >>>>>> [LES:] "Link State Protocol Data Unit" >>>>>> >>>>>>> >>>>>>> Original: >>>>>>> In cases where conflicting values for the same >>>>>>> application/attribute/link are advertised, the first advertisement >>>>>>> received in the lowest-numbered LSP MUST be used, and subsequent >>>>>>> advertisements of the same attribute MUST be ignored. --> >>>>>>> >>>>>>> >>>>>>> 10) <!-- [rfced] Section 4.3: As it appears that "a single TLV" refers >>>>>>> to the new Application-Specific SRLG TLV and not to some other type >>>>>>> of TLV, we changed "a single TLV" to "this new single TLV" here. >>>>>>> If this is incorrect, please provide clarifying text. >>>>>> >>>>>> [LES:] This is fine. >>>>>> >>>>>>> >>>>>>> Original (the previous sentence is included for context): >>>>>>> A new TLV is defined to advertise application-specific SRLGs for a >>>>>>> given link. Although similar in functionality to TLV 138 [RFC5307] >>>>>>> and TLV 139 [RFC6119], a single TLV provides support for IPv4, IPv6, >>>>>>> and unnumbered identifiers for a link. >>>>>>> >>>>>>> Currently: >>>>>>> Although similar in functionality to TLV 138 [RFC5307] >>>>>>> and TLV 139 [RFC6119], this new single TLV provides support for IPv4, >>>>>>> IPv6, and unnumbered identifiers for a link. --> >>>>>>> >>>>>>> >>>>>>> 11) <!-- [rfced] Sections 5 and 6: We changed lowercased instances of >>>>>>> "application-specific link attribute(s)" to "ASLA(s)" per the >>>>>>> expansion provided in Section 4. Please review, and let us know any >>>>>>> objections. --> >>>>>>> >>>>>> [LES:] No objection >>>>>> >>>>>>> >>>>>>> 12) <!-- [rfced] Sections 5 and subsequent: The following instances of >>>>>>> "LFA" in these sentences read oddly. Should they be plural or >>>>>>> perhaps "LFA Policy"? >>>>>>> >>>>>> [LES:] "LFA" is correct. This refers to the application types defined in >>> Section >>>>> 4.1 >>>>>> >>>>>>> Original: >>>>>>> In the case of LFA, the advertisement of application-specific link >>>>>>> attributes does not indicate enablement of LFA on that link. >>>>>>> ... >>>>>>> * The application is SR Policy or LFA, and RSVP-TE is not deployed >>>>>>> anywhere in the network. >>>>>>> >>>>>>> * The application is SR Policy or LFA, RSVP-TE is deployed in the >>>>>>> network, and both the set of links on which SR Policy and/or LFA >>>>>>> advertisements are required and the attribute values used by SR >>>>>>> Policy and/or LFA on all such links are fully congruent with the >>>>>>> links and attribute values used by RSVP-TE. >>>>>>> >>>>>>> Under the conditions defined above, implementations that support the >>>>>>> extensions defined in this document have the choice of using legacy >>>>>>> advertisements or application-specific advertisements in support of >>>>>>> SR Policy and/or LFA. >>>>>>> ... >>>>>>> Existing deployments of RSVP-TE, SR Policy, and/or LFA utilize the >>>>>>> legacy advertisements listed in Section 3. --> >>>>>>> >>>>>>> >>>>>>> 13) <!-- [rfced] Section 5: Per previous text in this document, we >>>>>>> changed "advertisement of link attribute advertisements" to >>>>>>> "advertisement of link attributes". If this is incorrect, please >>>>>>> provide alternative text. >>>>>>> >>>>>> [LES:] This is fine. >>>>>> >>>>>>> Original: >>>>>>> In the presence of >>>>>>> an application where the advertisement of link attribute >>>>>>> advertisements is used to infer the enablement of an application on >>>>>>> that link (e.g., RSVP-TE), the absence of the application identifier >>>>>>> leaves ambiguous whether that application is enabled on such a link. >>>>>>> >>>>>>> Currently: >>>>>>> In the presence of >>>>>>> an application where the advertisement of link attributes is used to >>>>>>> infer the enablement of an application on that link (e.g., RSVP-TE), >>>>>>> the absence of the application identifier leaves ambiguous whether >>>>>>> that application is enabled on such a link. --> >>>>>>> >>>>>>> >>>>>>> 14) <!-- [rfced] Section 9: >>>>>>> >>>>>>> a) We could not locate the discussion in question via the information >>>>>>> in the current text. Searching by thread on >>>>>>> <https://mailarchive.ietf.org/arch/browse/lsr/> for >>>>>>> "Proposed Errata for RFCs 8919/8920" directed us to >>>>>>> <https://mailarchive.ietf.org/arch/>, which provides an >>>>>>> "Enter list name or search query..." box, which did not yield the >>>>>>> desired information. >>>>>>> >>>>>> [LES:] The removal of the URL was done based on feedback during IESG >>>>> review. IT was commented that any such URL might not be valid >>> indefinitely. >>>>>> >>>>>> When I put "Proposed Errata for RFCs 8919/8920" into the search bar at >>>>> https://mailarchive.ietf.org/arch/browse/lsr/ I do find the relevant thread. >>>>>> >>>>>> >>>>>> >>>>>>> However, when looking at <https://www.rfc-editor.org/errata/eid6630> >>>>>>> (the erratum page for RFC 8919), we found >>>>>>> >>>>> >>> <https://mailarchive.ietf.org/arch/msg/lsr/_15rAwElfpGLDRxqjUuUJHiGdrQ/ >>>>>>>> . >>>>>>> Would pointing to this link instead of 'the thread "Proposed Errata >>>>>>> for RFCs 8919/8920"' be acceptable? If not, please provide a URL >>>>>>> that can be listed as a good starting point for readers interested in >>>>>>> this information. >>>>>>> >>>>>>> Original (the previous sentence is included for context): >>>>>>> Discussion within the LSR WG indicated that there was confusion >>>>>>> regarding the use of ASLA advertisements that had a zero length SABM/ >>>>>>> UDABM. The discussion can be seen by searching the LSR WG mailing >>>>>>> list archives for the thread "Proposed Errata for RFCs 8919/8920" >>>>>>> starting on 15 June 2021. >>>>>>> >>>>>>> Possibly: >>>>>>> Discussion within the LSR WG indicated that there was confusion >>>>>>> regarding the use of ASLA advertisements that had a zero-length SABM/ >>>>>>> UDABM. The discussion can be seen on >>>>>>> >>>>>>> >>>>> >>> <https://mailarchive.ietf.org/arch/msg/lsr/_15rAwElfpGLDRxqjUuUJHiGdrQ/ >>>>>>>> . >>>>>>> >>>>>>> b) We see that the "NEW" text for Section 4.2 was applied per >>>>>>> <https://www.rfc-editor.org/errata/eid6630> but the "NEW" text for >>>>>>> Section 6.2 was not. Is this as desired (i.e., does "subject to the >>>>>>> restrictions specified in Section 4.2" in the first paragraph of >>>>>>> Section 6.2 handle the erratum information adequately?)? --> >>>>>>> >>>>>>> >>>>>>> 15) <!-- [rfced] We added RFC 8919 to the list of Normative References. >>>>>>> Please let us know if it should be an Informative Reference instead. >>>>>> >>>>>> [LES:] Fine as a normative reference. >>>>>> >>>>>>> --> >>>>>>> >>>>>>> >>>>>>> 16) <!-- [rfced] Please review the "Inclusive Language" portion of the >>>>>>> online Style Guide at >>>>>>> <https://www.rfc-editor.org/styleguide/part2/#inclusive_language>, >>>>>>> and let us know if any changes are needed. >>>>>>> >>>>>>> Note that our script did not flag any words in particular, but this >>>>>>> should still be reviewed as a best practice. --> >>>>>> >>>>>> [LES:] No changes are needed that I can see. >>>>>> >>>>>>> >>>>>>> >>>>>>> 17) <!-- [rfced] The following term appears to be used inconsistently in >>>>>>> this document. Please let us know which form is preferred. >>>>>>> >>>>>> [LES:] Please use lower case "legacy". >>>>>> >>>>>> Les >>>>>> >>>>>>> Legacy sub-TLV / legacy sub-TLV (text in Section 4.2) --> >>>>>>> >>>>>>> >>>>>>> Thank you. >>>>>>> >>>>>>> RFC Editor/lb/ap >>>>> >>>>> >>>>>> On Sep 25, 2023, at 3:10 PM, Les Ginsberg (ginsberg) >>>>> <ginsberg=40cisco.com@dmarc.ietf.org> wrote: >>>>>> >>>>>> Folks - >>>>>> >>>>>> I am fine with the changes introduced with the following exceptions: >>>>>> >>>>>> 1)Section 6.3.3 >>>>>> >>>>>> "while continuing to use legacy advertisements" >>>>>> >>>>>> Please change this to >>>>>> >>>>>> "while continuing to advertise legacy advertisements" >>>>>> >>>>>> The point is to indicate that both forms need to be advertised(sic). >>>>>> The last sentence in the paragraph clearly states what is used. >>>>>> >>>>>> 2)Section 7.2 >>>>>> >>>>>> You have changed column #2 to be "Name" - but the corresponding >>> registry >>>>> uses the original term "Description". >>>>>> Please revert this change. >>>>>> >>>>>> 3)Section 7.5 >>>>>> >>>>>> You changed the title to "IS-IS Sub-TLVs for Application-Specific SRLG TLV >>>>> Registry (for TLV 238)". >>>>>> >>>>>> This does not match the title in the registry: >>>>> https://www.iana.org/assignments/isis-tlv-codepoints/isis-tlv- >>>>> codepoints.xhtml#tlv-238 >>>>>> >>>>>> "IS-IS Sub-TLVs for Application-Specific SRLG TLV" >>>>>> >>>>>> Les >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: rfc-editor@rfc-editor.org <rfc-editor@rfc-editor.org> >>>>>>> Sent: Monday, September 11, 2023 2:57 PM >>>>>>> To: Les Ginsberg (ginsberg) <ginsberg@cisco.com>; Peter Psenak >>> (ppsenak) >>>>>>> <ppsenak@cisco.com>; stefano@previdi.net; >>> wim.henderickx@nokia.com; >>>>>>> jdrake@juniper.net >>>>>>> Cc: rfc-editor@rfc-editor.org; lsr-ads@ietf.org; lsr-chairs@ietf.org; >>>>>>> chopps@chopps.org; jgs@juniper.net; auth48archive@rfc-editor.org >>>>>>> Subject: AUTH48: RFC-to-be 9479 <draft-ietf-lsr-rfc8919bis-04> for your >>>>>>> review >>>>>>> >>>>>>> *****IMPORTANT***** >>>>>>> >>>>>>> Updated 2023/09/11 >>>>>>> >>>>>>> RFC Author(s): >>>>>>> -------------- >>>>>>> >>>>>>> Instructions for Completing AUTH48 >>>>>>> >>>>>>> Your document has now entered AUTH48. Once it has been reviewed >>> and >>>>>>> approved by you and all coauthors, it will be published as an RFC. >>>>>>> If an author is no longer available, there are several remedies >>>>>>> available as listed in the FAQ (https://www.rfc-editor.org/faq/). >>>>>>> >>>>>>> You and you coauthors are responsible for engaging other parties >>>>>>> (e.g., Contributors or Working Group) as necessary before providing >>>>>>> your approval. >>>>>>> >>>>>>> Planning your review >>>>>>> --------------------- >>>>>>> >>>>>>> Please review the following aspects of your document: >>>>>>> >>>>>>> * RFC Editor questions >>>>>>> >>>>>>> Please review and resolve any questions raised by the RFC Editor >>>>>>> that have been included in the XML file as comments marked as >>>>>>> follows: >>>>>>> >>>>>>> <!-- [rfced] ... --> >>>>>>> >>>>>>> These questions will also be sent in a subsequent email. >>>>>>> >>>>>>> * Changes submitted by coauthors >>>>>>> >>>>>>> Please ensure that you review any changes submitted by your >>>>>>> coauthors. We assume that if you do not speak up that you >>>>>>> agree to changes submitted by your coauthors. >>>>>>> >>>>>>> * Content >>>>>>> >>>>>>> Please review the full content of the document, as this cannot >>>>>>> change once the RFC is published. Please pay particular attention to: >>>>>>> - IANA considerations updates (if applicable) >>>>>>> - contact information >>>>>>> - references >>>>>>> >>>>>>> * Copyright notices and legends >>>>>>> >>>>>>> Please review the copyright notice and legends as defined in >>>>>>> RFC 5378 and the Trust Legal Provisions >>>>>>> (TLP – https://trustee.ietf.org/license-info/). >>>>>>> >>>>>>> * Semantic markup >>>>>>> >>>>>>> Please review the markup in the XML file to ensure that elements of >>>>>>> content are correctly tagged. For example, ensure that <sourcecode> >>>>>>> and <artwork> are set correctly. See details at >>>>>>> <https://authors.ietf.org/rfcxml-vocabulary>. >>>>>>> >>>>>>> * Formatted output >>>>>>> >>>>>>> Please review the PDF, HTML, and TXT files to ensure that the >>>>>>> formatted output, as generated from the markup in the XML file, is >>>>>>> reasonable. Please note that the TXT will have formatting >>>>>>> limitations compared to the PDF and HTML. >>>>>>> >>>>>>> >>>>>>> Submitting changes >>>>>>> ------------------ >>>>>>> >>>>>>> To submit changes, please reply to this email using ‘REPLY ALL’ as all >>>>>>> the parties CCed on this message need to see your changes. The parties >>>>>>> include: >>>>>>> >>>>>>> * your coauthors >>>>>>> >>>>>>> * rfc-editor@rfc-editor.org (the RPC team) >>>>>>> >>>>>>> * other document participants, depending on the stream (e.g., >>>>>>> IETF Stream participants are your working group chairs, the >>>>>>> responsible ADs, and the document shepherd). >>>>>>> >>>>>>> * auth48archive@rfc-editor.org, which is a new archival mailing list >>>>>>> to preserve AUTH48 conversations; it is not an active discussion >>>>>>> list: >>>>>>> >>>>>>> * More info: >>>>>>> https://mailarchive.ietf.org/arch/msg/ietf-announce/yb6lpIGh- >>>>>>> 4Q9l2USxIAe6P8O4Zc >>>>>>> >>>>>>> * The archive itself: >>>>>>> https://mailarchive.ietf.org/arch/browse/auth48archive/ >>>>>>> >>>>>>> * Note: If only absolutely necessary, you may temporarily opt out >>>>>>> of the archiving of messages (e.g., to discuss a sensitive matter). >>>>>>> If needed, please add a note at the top of the message that you >>>>>>> have dropped the address. When the discussion is concluded, >>>>>>> auth48archive@rfc-editor.org will be re-added to the CC list and >>>>>>> its addition will be noted at the top of the message. >>>>>>> >>>>>>> You may submit your changes in one of two ways: >>>>>>> >>>>>>> An update to the provided XML file >>>>>>> — OR — >>>>>>> An explicit list of changes in this format >>>>>>> >>>>>>> Section # (or indicate Global) >>>>>>> >>>>>>> OLD: >>>>>>> old text >>>>>>> >>>>>>> NEW: >>>>>>> new text >>>>>>> >>>>>>> You do not need to reply with both an updated XML file and an explicit >>>>>>> list of changes, as either form is sufficient. >>>>>>> >>>>>>> We will ask a stream manager to review and approve any changes that >>>>> seem >>>>>>> beyond editorial in nature, e.g., addition of new text, deletion of text, >>>>>>> and technical changes. Information about stream managers can be >>> found >>>>> in >>>>>>> the FAQ. Editorial changes do not require approval from a stream >>> manager. >>>>>>> >>>>>>> >>>>>>> Approving for publication >>>>>>> -------------------------- >>>>>>> >>>>>>> To approve your RFC for publication, please reply to this email stating >>>>>>> that you approve this RFC for publication. Please use ‘REPLY ALL’, >>>>>>> as all the parties CCed on this message need to see your approval. >>>>>>> >>>>>>> >>>>>>> Files >>>>>>> ----- >>>>>>> >>>>>>> The files are available here: >>>>>>> https://www.rfc-editor.org/authors/rfc9479.xml >>>>>>> https://www.rfc-editor.org/authors/rfc9479.html >>>>>>> https://www.rfc-editor.org/authors/rfc9479.pdf >>>>>>> https://www.rfc-editor.org/authors/rfc9479.txt >>>>>>> >>>>>>> Diff file of the text: >>>>>>> https://www.rfc-editor.org/authors/rfc9479-diff.html >>>>>>> https://www.rfc-editor.org/authors/rfc9479-rfcdiff.html (side by side) >>>>>>> >>>>>>> Diff of the XML: >>>>>>> https://www.rfc-editor.org/authors/rfc9479-xmldiff1.html >>>>>>> >>>>>>> >>>>>>> Tracking progress >>>>>>> ----------------- >>>>>>> >>>>>>> The details of the AUTH48 status of your document are here: >>>>>>> https://www.rfc-editor.org/auth48/rfc9479 >>>>>>> >>>>>>> Please let us know if you have any questions. >>>>>>> >>>>>>> Thank you for your cooperation, >>>>>>> >>>>>>> RFC Editor >>>>>>> >>>>>>> -------------------------------------- >>>>>>> RFC9479 (draft-ietf-lsr-rfc8919bis-04) >>>>>>> >>>>>>> Title : IS-IS Application-Specific Link Attributes >>>>>>> Author(s) : L. Ginsberg, P. Psenak, S. Previdi, W. Henderickx, J. Drake >>>>>>> WG Chair(s) : Acee Lindem, Christian Hopps >>>>>>> Area Director(s) : Alvaro Retana, John Scudder, Andrew Alston >>>>>>> >>>>>> >>>> >> > >
- [auth48] AUTH48: RFC-to-be 9479 <draft-ietf-lsr-r… rfc-editor
- Re: [auth48] AUTH48: RFC-to-be 9479 <draft-ietf-l… rfc-editor
- Re: [auth48] AUTH48: RFC-to-be 9479 <draft-ietf-l… Peter Psenak
- Re: [auth48] AUTH48: RFC-to-be 9479 <draft-ietf-l… Lynne Bartholomew
- Re: [auth48] AUTH48: RFC-to-be 9479 <draft-ietf-l… Les Ginsberg (ginsberg)
- Re: [auth48] AUTH48: RFC-to-be 9479 <draft-ietf-l… Les Ginsberg (ginsberg)
- Re: [auth48] AUTH48: RFC-to-be 9479 <draft-ietf-l… Les Ginsberg (ginsberg)
- Re: [auth48] AUTH48: RFC-to-be 9479 <draft-ietf-l… Les Ginsberg (ginsberg)
- Re: [auth48] AUTH48: RFC-to-be 9479 <draft-ietf-l… Acee Lindem
- Re: [auth48] AUTH48: RFC-to-be 9479 <draft-ietf-l… Les Ginsberg (ginsberg)
- Re: [auth48] AUTH48: RFC-to-be 9479 <draft-ietf-l… Lynne Bartholomew
- Re: [auth48] AUTH48: RFC-to-be 9479 <draft-ietf-l… Lynne Bartholomew
- Re: [auth48] AUTH48: RFC-to-be 9479 <draft-ietf-l… Les Ginsberg (ginsberg)
- Re: [auth48] AUTH48: RFC-to-be 9479 <draft-ietf-l… Les Ginsberg (ginsberg)
- Re: [auth48] AUTH48: RFC-to-be 9479 <draft-ietf-l… Lynne Bartholomew
- Re: [auth48] AUTH48: RFC-to-be 9479 <draft-ietf-l… Lynne Bartholomew
- Re: [auth48] AUTH48: RFC-to-be 9479 <draft-ietf-l… Lynne Bartholomew
- Re: [auth48] AUTH48: RFC-to-be 9479 <draft-ietf-l… Lynne Bartholomew
- Re: [auth48] AUTH48: RFC-to-be 9479 <draft-ietf-l… Les Ginsberg (ginsberg)
- Re: [auth48] AUTH48: RFC-to-be 9479 <draft-ietf-l… Lynne Bartholomew
- Re: [auth48] AUTH48: RFC-to-be 9479 <draft-ietf-l… Peter Psenak
- Re: [auth48] AUTH48: RFC-to-be 9479 <draft-ietf-l… Wim Henderickx (Nokia)
- Re: [auth48] AUTH48: RFC-to-be 9479 <draft-ietf-l… Acee Lindem
- Re: [auth48] AUTH48: RFC-to-be 9479 <draft-ietf-l… Stefano Previdi
- Re: [auth48] AUTH48: RFC-to-be 9479 <draft-ietf-l… Lynne Bartholomew
- Re: [auth48] AUTH48: RFC-to-be 9479 <draft-ietf-l… Lynne Bartholomew
- Re: [auth48] AUTH48: RFC-to-be 9479 <draft-ietf-l… Acee Lindem
- Re: [auth48] AUTH48: RFC-to-be 9479 <draft-ietf-l… Lynne Bartholomew
- Re: [auth48] AUTH48: RFC-to-be 9479 <draft-ietf-l… Acee Lindem
- Re: [auth48] AUTH48: RFC-to-be 9479 <draft-ietf-l… Lynne Bartholomew
- Re: [auth48] AUTH48: RFC-to-be 9479 <draft-ietf-l… John E Drake
- Re: [auth48] AUTH48: RFC-to-be 9479 <draft-ietf-l… Acee Lindem
- Re: [auth48] AUTH48: RFC-to-be 9479 <draft-ietf-l… Lynne Bartholomew
- [auth48] [IANA] Re: AUTH48: RFC-to-be 9479 <draft… Lynne Bartholomew
- [auth48] [IANA #1283317] [IANA] Re: AUTH48: RFC-t… Sabrina Tanamal via RT
- Re: [auth48] AUTH48: RFC-to-be 9479 <draft-ietf-l… Acee Lindem
- Re: [auth48] [IANA #1283317] [IANA] Re: AUTH48: R… Lynne Bartholomew
- Re: [auth48] AUTH48: RFC-to-be 9479 <draft-ietf-l… Lynne Bartholomew
- Re: [auth48] AUTH48: RFC-to-be 9479 <draft-ietf-l… Lynne Bartholomew
- Re: [auth48] AUTH48: RFC-to-be 9479 <draft-ietf-l… Les Ginsberg (ginsberg)
- Re: [auth48] AUTH48: RFC-to-be 9479 <draft-ietf-l… Lynne Bartholomew
- Re: [auth48] AUTH48: RFC-to-be 9479 <draft-ietf-l… Les Ginsberg (ginsberg)
- Re: [auth48] AUTH48: RFC-to-be 9479 <draft-ietf-l… Lynne Bartholomew
- Re: [auth48] AUTH48: RFC-to-be 9479 <draft-ietf-l… Lynne Bartholomew