Re: [auth48] AUTH48: RFC-to-be 9479 <draft-ietf-lsr-rfc8919bis-04> for your review
"Les Ginsberg (ginsberg)" <ginsberg@cisco.com> Thu, 28 September 2023 22:15 UTC
Return-Path: <ginsberg@cisco.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 04F47C1388B7; Thu, 28 Sep 2023 15:15:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -11.906
X-Spam-Level:
X-Spam-Status: No, score=-11.906 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b="G0lw+3SD"; dkim=pass (1024-bit key) header.d=cisco.com header.b="Q5ZZWOjq"
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 XSdov3ASl5pP; Thu, 28 Sep 2023 15:15:49 -0700 (PDT)
Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (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 8E61DC139C65; Thu, 28 Sep 2023 15:15:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=41268; q=dns/txt; s=iport; t=1695939349; x=1697148949; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=3htIJuVbImm9nt7l7zuZa3GBGQPGIRfe4TgzBpgBPeI=; b=G0lw+3SDsAZnK6l3+asjYr+O+qsZXBgdLHd8YdzJzVaUZza86fhQDheP /Awz68JJOMrcdQvxaNo1KeRats4JgypfixgtQ/juKhnFKpKwZSWXaUr9Q SA9VFGlshDElaDxUh+XlpyKZBv9C7Ti0VACOcmNXLDpISj8IyY1252tHI c=;
X-CSE-ConnectionGUID: uXhqyyzxQXKOQbIJUlvSuQ==
X-CSE-MsgGUID: 2ZAXLj40Q5Kkk0seYvPLNA==
X-IPAS-Result: A0ADAAB7+hVlmJ1dJa1aGQEBAQEBAQEBAQEBAQEBAQEBARIBAQEBAQEBAQEBAQFAJYEWBAEBAQEBCwGBZFJ3AlkqEkeEUoNMA4ROX4ZAgiMDi1yFXoxCFIERA1YPAQEBDQEBOQsEAQGFBwIWhnUCJjQJDgECAgIBAQEBAwIDAQEBAQEBAQIBAQUBAQECAQcEFAEBAQEBAQEBHhkFDhAnhTsGJw2GSQEBAQEBAhIICQQNDAEBLAsBCwQCAQYCDgMBAwEBAQICJgICAh8RFQIGCAIEDgUIGoJcAYIqAzEDARAGmHGPTQGBQAKKKHp/M4EBggkBAQYEBbAWDYJJCYEaLgGHax4BgVCDaYRNJxuBSUSBFAFDgmg+giBCAgEBgSEEBAESASMKCw+DNTmCL4cpgh6CK0mCBQcOLgMEMoELDAmBBYJ3NSqBFAmCHod9CSGBCAhdgWo9Ag1UCwtdgRGCRAICETkUR3AbAwcDgQQQKwcEMhsHBgkWLSUGUQQtJAkTEj4EgWeBUQqBBj8RDhGCRCICBzY2GUuCWwkVDDROdhArBBQXbCgEagUaFR42ERIXDQMIdh0CESM8AwUDBDYKFQ0LIQUUQwNHBkwLAwIcBQMDBIE2BQ8eAhAaBg4pAwMZTgIQFAM+AwMGAwsyAzBXSwxVA0QdQAMLbT0UIRQbBQQ7KVkFoggDPDGBcgEICBVGBgEBKQcMJgQNAQYTAQoRDgIgJggCAyANBQsILRUEAR4FAQEECwEPGhEpjG2FQRAKMAeCWwFIi0CDTp1XCT9vCoQMjAGODoEGhigXhAFMgQqLGQMBhmqGOogagk1imDKCT4sTg3WIL4ZoghgDDAMKhH0CBAIEBQIOAQEGgWM6a3BwFRohgjMBATIJSRkPhBeKCQwNCYEwgiaFFIpldgI5AgcBCgEBAwmGTYIhLIFQXwEB
IronPort-PHdr: A9a23:rRrYHh3+3qy9PueEsmDPZ1BlVkEcU/3cJAUZ7N8gk71RN/3l9JX5N 0uZ7vJo3xfFXoTevupNkPGe87vhVmoJ/YubvTgcfYZNWR4IhYRenwEpDMOfT0yuBPXrdCc9W s9FUQwt5Gm1ZHBcA922fFjOuju35D8WFA/4MF96J+LuEIPIgOy81vu5/NvYZAAbzDa4aKl5e Q2/th6Z9tFDmJZrMK831hrPrzNEev8Dw2RuKBPbk0P359y7+9ho9CE4hg==
IronPort-Data: A9a23:yt5V1KJmauCvcyqeFE+R45UlxSXFcZb7ZxGr2PjKsXjdYENSgTFUm zdLCGuAPv7bYjf3Ldh+bI2/pkoFupDSyYIxTwEd+CA2RRqmiyZq6fd1j6vUF3nPRiEWZBs/t 63yUvGZcYZsCCea/0/xWlTYhSEU/bmSQbbhA/LzNCl0RAt1IA8skhsLd9QR2uaEuvDnRVvW0 T/Oi5eHYgT9imQkajl8B5+r8XuDgtyj4Fv0gXRmDRx7lAe2v2UYCpsZOZawIxPQKmWDNrfnL wpr5OjRElLxp3/BOPv8+lrIWhFirorpAOS7oiE+t55OLfR1jndaPq4TbJLwYKrM4tmDt4gZJ N5l7fRcReq1V0HBsLx1bvVWL81xFbB2+KbWMGqviPyw6HTMUlnRx+tVEXhjaOX0+s4vaY1P3 eYTJDZIZReZiqfohrm6UeJrwM8kKaEHPqtG5Somlm6fXK1gGM2cK0nJzYcwMDMYicFIBvzTf cUxYjt0ZxOGaBpKUrsSIMtnzbv02CKlLVW0rnrPl4MHx2qPlDUs87vuaMHYS8KyYeN8yxPwS mXupjSlXU5y2Mak4TOY7nLw1ubVliP6Ro86DrOzs/NmgUGU3CoUEhJ+fUG1qry0hk+iXMh3M UIfvycirLQ17gqsVNaVYvGjiGSPshhZUN1KHqhkrgqM0aHTpQ2eAwDoUwKtdvQ7hM8vVC04x ma5vPTQDx1NjbmLcm+ko+L8QSyJBQAZKmoLZCkhRAQD4sX+rIxbsv4pZos+eEJSpoCocQwc0 wxmvwBl2OpO1Z9jO7GTuAGY02j19/AlWyZsvl2PNl9J+D+Vc2JMWmBFwULQ4fAFJ4GDQxzf+ nMFgMOZqusJCPlhdRBhos1TR9lFBN7cYFUwZGKD+bF9rlxBHFb4LOhtDMlWfhsBDyr9UWaBj LXvkQ1Q/oRPG3ChcLV6ZYm8Y+xzk/m9RI64BquLNoUUCnSUSONh1H83DaJ39z61+HXAbYlkU XtmWZ/2VC1DWfgPIMSeHrlFi9fHORzSNUuKFcykkHxLIJKVZWWeTv8eIUCSY+UihJ5oUy2Lm +uzw/Cikk0FOMWnO3G/2ddKcTgicyNhbbio8JM/SwJ2Clc8cI3XI6WPkepJlk0Mt/k9q9okC VnnBR8AmAGv3iyeQehIA1g6AI7SsV9EhStTFQQnPE2j3D4oZoPH0UvVX8FfkWUPnAC78cNJc g==
IronPort-HdrOrdr: A9a23:36e/B6xQ6Si3+ptw8dKMKrPxaegkLtp133Aq2lEZdPULSL36qy n+ppQmPEHP6Qr5AEtQ6OxoWJPtfZvdnaQFmLX5To3SLDUO31HYYr2KjLGSjAEIfheOlNK1up 0QDpSWZOeAamSSyPyKnjVQcOxQgeVvkprY+ds2pk0FJWoFGsQQizuRSDzrbXGeLzM2fabRYa DsnPav0ADQAkj/AP7LYEUtbqzonfGOvpTgZhINGh4g7yezrR7A0tTHOind9C0zFxdUz5kf0U WtqWHED6OY3M2T+1v57Sv+/p5WkNzuxp9oH8qXkPUYLT3ql0KBeJlhc6fqhkF3nMifrHIR1P XcqRYpOMp+r1nLeHuunBfr0w78lB4z9n7Zz0OCi3eLm726eNt6MbsFuWtqSGqf16MShqA77E uN5RPBi3NjN2KFoM063amRa/glrDvunZNoq59hs5UWa/ptVFYWl/1ewKuQe61wQR4TL+scYb NTJdCZ6/BMfVyAaXfF+mFp3dy3R3w2WgyLW04Yp6WuonJrdV1CvgMlLfYk7zw93YN4T4MB6/ XPM6xumr0LRsgKbbhlDONERcesEGTCTR/FLWrXeD3cZe06EmOIr4Sy7KQ+5emsdpBNxJwumI 7ZWFcdsWIpYUrhBcCHwZUO+BHQR2e2Wyjr16hlltVEk6y5QKCuPTyISVgoncflq/IDAtfDU/ L2I55SC++LFxqmJW+I5XyJZ3B/EwhobCROgKdPZ7unmLO+FrHX
X-Talos-CUID: 9a23:Twpz3G+CQugGEYmkYY6Vv1MkGtk0Y2/N9UfzBHayKERUTKOuVGbFrQ==
X-Talos-MUID: 9a23:GK3EXwn7OH/VtYBQmGi5dno4Bu5Yx6byUHlQspYF49KJBDJIHxG02WE=
X-IronPort-Anti-Spam-Filtered: true
Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-9.cisco.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 28 Sep 2023 22:15:46 +0000
Received: from rcdn-opgw-1.cisco.com (rcdn-opgw-1.cisco.com [72.163.7.162]) by rcdn-core-6.cisco.com (8.15.2/8.15.2) with ESMTPS id 38SMFkXr018682 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 28 Sep 2023 22:15:46 GMT
X-CSE-ConnectionGUID: sGIBnPShQGCCxXJ1HGJzmA==
X-CSE-MsgGUID: SarpkkNoTdG3jSNtRAJ83A==
Authentication-Results: rcdn-opgw-1.cisco.com; dkim=pass (signature verified) header.i=@cisco.com; spf=Pass smtp.mailfrom=ginsberg@cisco.com; dmarc=pass (p=quarantine dis=none) d=cisco.com
X-IronPort-AV: E=Sophos;i="6.03,185,1694736000"; d="scan'208";a="3225477"
Received: from mail-sn1nam02lp2043.outbound.protection.outlook.com (HELO NAM02-SN1-obe.outbound.protection.outlook.com) ([104.47.57.43]) by rcdn-opgw-1.cisco.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 28 Sep 2023 22:15:45 +0000
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=VVUGNC3wuMIF7GMSNt0KNzr8nuCJ2zn2pongIB3Va/7BuQjWelTejLJOEgYrDHpXv/Jxd0AkiBE/vSjMQYwhKZkqY1Lk6FKVrLNhTA6Ju5kxxgLINDIDxylwqZD52fP/pH48oDeoFwIuNoS0TDAXnjLjLe8adjns+p7PcDJT0DQxE5IvC5V/xXgeCiMgJagPlKxcnZpC3Z7vmwp/vUQdbGTUnL3s5UHAHO/ayoElk9cy9NxGb6BhqtlcUjnouwyvaND7qsNq/7UI91JKF9ZZHJAic5G+tkltjS8gF5P3qktSZ9GwovLHmEmIajzCCRl/pj81Irgt5U4euVbYvGJCwQ==
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=3htIJuVbImm9nt7l7zuZa3GBGQPGIRfe4TgzBpgBPeI=; b=Bf+0sqGKbbTBCjwyGi7VjIlo2qOpKUIT//+JvozNIHdSDFCMmeHJoy1brQp0MtG8ucwSsH3/DBXJjYBC2osqxwyq4lTcLiaM9nlkcwWS0MIXuJl9UrQQ8Bq3qjOMGdBctKjeo0NpC/fpGSyKkjyJDeS68jK4C/LqJb1zjCmGBN6YfHE3Cux4MsSfzSQciMGT3ETATxFwK4tflTfNQ7nrbmvusRY/2Ge4/wrwK019RcAJTApDj/1Dt7F559OlnDGwEzUiko20VixY+kaJq0oNoS2MluRIpa4leF2nx2TJsJPsXdpwVgfGEZo7P9fYpd3MyW0wlxEXLL624kYE/67SiQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=3htIJuVbImm9nt7l7zuZa3GBGQPGIRfe4TgzBpgBPeI=; b=Q5ZZWOjqbga0cqXydu2GVsWyA77zohXX0eyhYp9anNeB6yWsQoXwSYDi3JvXTRn93q2jOJDZTqF6PfA+hjUOADEI8prihbAuBNaI/LnCyCOSylyRrQYQs7QDPuxugmlN/CDz4vHVJ8rY7zKz6NJXALrNCuRmGRT0ARncFGXoPKU=
Received: from MN2PR11MB4352.namprd11.prod.outlook.com (2603:10b6:208:18e::30) by SA3PR11MB7413.namprd11.prod.outlook.com (2603:10b6:806:31a::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6838.24; Thu, 28 Sep 2023 22:15:43 +0000
Received: from MN2PR11MB4352.namprd11.prod.outlook.com ([fe80::2b56:eba2:3878:e360]) by MN2PR11MB4352.namprd11.prod.outlook.com ([fe80::2b56:eba2:3878:e360%6]) with mapi id 15.20.6813.027; Thu, 28 Sep 2023 22:15:43 +0000
From: "Les Ginsberg (ginsberg)" <ginsberg@cisco.com>
To: Lynne Bartholomew <lbartholomew@amsl.com>
CC: Acee Lindem <acee.ietf@gmail.com>, "rfc-editor@rfc-editor.org" <rfc-editor@rfc-editor.org>, "Peter Psenak (ppsenak)" <ppsenak@cisco.com>, "stefano@previdi.net" <stefano@previdi.net>, "wim.henderickx@nokia.com" <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>
Thread-Topic: AUTH48: RFC-to-be 9479 <draft-ietf-lsr-rfc8919bis-04> for your review
Thread-Index: AQHZ5PrlX6QmfBKqVke2b16lT0hh57AsHwjwgAMdI4CAABUoMIABfzCAgAAXyXA=
Date: Thu, 28 Sep 2023 22:15:43 +0000
Message-ID: <MN2PR11MB4352EA4198E76460A58CF406C1C1A@MN2PR11MB4352.namprd11.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>
In-Reply-To: <96716D85-7E98-49CA-BF0C-81490F29403F@amsl.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: MN2PR11MB4352:EE_|SA3PR11MB7413:EE_
x-ms-office365-filtering-correlation-id: a7ec09ce-ac34-48ba-103a-08dbc0707516
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: PqImwttHafjNOwLZQGS/+0Sfj7DqKJhJKktPx832eUWiHzO41xPfrGnnvrKLGT/xq153zO/FrneOPtBdIAd5tyYWI//cfYuoWxSPHYIocA19oViJ18zcOis8BtWkgfbH7JKnwCjHb9uZ4GZfqAgDHRyGiMegMt5pE1ZpBd7AM6OFiB2O+pjO+MzraHLiF0PIgTJyB6cRPOpcCzj9DQMKMk8zXrHng9w0hcx03qWTaLRXwfMsw79krMEqpNscI3792tMQ4GxhdlRqXpvC/7dwjOpK0jJNRsFWUcULNkSvHSFc3tqVdAC4MnUN5A9WsxUegoKEE82JCUiiViwpnMSy/4KasqUK1Nd+zumDe7lwtovqwL2g0ph7ZLgJQfQuxKYt7gYPdp/b6bLJiZbKMCMJHbMJxyOl6MrPxHannALYNwkYlTDpK46TqO/HK3Z0eLwWwoYda3HWdnBwigdBBbVWXIcSUjYqF0FSVVPgwPAQvJcnHXVWOBRURQVOTGV/fmOGzZ1gx1kM+1z9nKd9Of0mXGERacx5BCaynlXrVwxwja93U49X00vTj3wfH+tumaOBgkRNaWochZg8/ND8n7bmLT7jvuiBTUQHU7EeUfc03/v2w9ZuvDDP+b1EzF8Z74nFPi2QxTCTbHDM4c5edRzXQw3Pmh3FLOoar1vbbUbkoLY=
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MN2PR11MB4352.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230031)(39860400002)(136003)(396003)(346002)(366004)(376002)(230922051799003)(451199024)(186009)(64100799003)(1800799009)(2906002)(9686003)(30864003)(316002)(4326008)(41300700001)(54906003)(8936002)(8676002)(64756008)(52536014)(7416002)(5660300002)(53546011)(55016003)(66556008)(66476007)(76116006)(19627235002)(86362001)(478600001)(71200400001)(7696005)(6506007)(33656002)(38100700002)(38070700005)(66574015)(26005)(122000001)(66446008)(66946007)(83380400001)(6916009)(966005)(579004)(559001)(19607625013); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: Wbnes7GrFzVlaQ72EmO1Efws21Km3bsflNauQVTUmIj4sdTL5fqz5yzawo9t9j737uw0eGB5XTk1UVBTlq5t4VqFDK5xtol7woQSY7ebVMAUntJ3JrG+U9t3/F45PAzC8ZAHvEyqR8Z2LYzylQcIbqUGMhwi2b4w+/m9BKQBreit3fSdq4EeYm3sKbPAYhZp3hZEqYjpr1otkT1Pzkz1mNosv6Uxtqd7yl6TjEljD5XxgpIofivqwtHULVH8aZtMHspSJ/cfKOhoFs2eB0hk+luPCUQl3AANQcxoCYiAGyU2jbGCq8Plkf11VqvZWzoJnAudbo+cqOGGPVLQtzB8cudYY/Ceq2VNr0NjwDw3eASxt8+DaltLotk+6QO6uC3tnWYeKxZWg2pPZRCcfjNSjqgwbKQqeo1MPW4UKXgi5+PORxYYtAqZWFFrQpU5qRnvYIm8RHiDX+i0bqM6ouhJPBqwHOPwM6ozanBHkWdjguVwaJzo42WYSDHAfuwTyRNlOU7Uu+du8ss0W+Fym+OaqlBFQqLfPXjOOjruA8RTVauluF1iwa1NkvTXlWef9gON3K/JMPUmIk7fOcjr2M001rUjQlPCLsS/IN6drmiSRj7kPpQfonMrZRR5SFEth99e8ZgScCb0lKgNa9etF2vpLU4xoDjzvOS5x/gEZ7lZ4vD7PEAc/Ci33V0GPr8V3hn6swiKNcxwLH1qTKc5rIoZA9UAxvsBQmtHeQGZuI81rpN9KEAYY4efDPsLRdKM9Mu2FOIwL7d6jXO+J7yTKiKbwRjevvJbLU5WW7sSRok02d9Ga1BGwKylZNUFEy4I+SLj8xaVkPCI/l6Lvzi/OpWnks6RSlCOgZd9nWt3lUJQoojQ+ZJuo8wgg0Q1hiNAUaZXXQeRQxQn0OfSVdLbAhtwuwKMAVQbtGlfpX/PJCqgSSa70YEJpQKr6ev5qIU9YjceGgXZe+AKXbMksR3lFT/TWMCd8ZRtiO71IEERYqbGIK2mRQ91NxXPgSuwHvZetpA6mFn0ZUcPXyq/bl/+ZfVf+AIMHA2VmL/jVcTnDkLOVH/JryeQp9Y5BWijx7l9HeSp6Q1y2amNtSYs68qdHAIK00iGmHE46M0I5PcIgsiw7XGUSdvkDMtTEwssqCUfBr2CH1a2Lgt0RNnV6v1+RD7bALdlgbOjj3TqdtF5alHFrxGWyGQWIf8bxe077RKPVM/1ShnbP8KBpGwvXVgagq/ow6YX0rsOy1ZO9bi/sRTu7cs1QWBgVD3kqvEePJVhiFZ2YzhmcWGTUtvjPBnv5XPbhtcC0/jXql/iVWFc1i5jaQQnpO8oEsihbrPsAVWcAG4Yc5b8/bLqqAtDXg2Q7tepicbQ9Du1pq2uH3GlUcVS3INpfyMlfGX+TgKJCPy5+tE/9OKKPo/H6Qla1kQUkg3QGjpy8k1IF9cOPY+gfu/HsTTZGVwjKwy3lWJKXRYwel3+mASoMzqP2Oa228zGw+Kieg2DE4HvIdGvBjy/voxF7rJ90tZk/1nVYscIdAy0KnQ8lyry9hcAh7u8M7anYoVhomCYsaanTxF80RofPd2gTYwRtjzhXPa+ENbzjgAqSM60
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: cisco.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: MN2PR11MB4352.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: a7ec09ce-ac34-48ba-103a-08dbc0707516
X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Sep 2023 22:15:43.6219 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: Oo0QPdCaAqmAm66ZiW2X7+X6ckaPukiOXmpEZsjz6433BhtyDaVXFfmjCsuSkk7lWV7K3iPwlcVRE2RW2XjpuQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA3PR11MB7413
X-Outbound-SMTP-Client: 72.163.7.162, rcdn-opgw-1.cisco.com
X-Outbound-Node: rcdn-core-6.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/auth48archive/oGoGFNBNLcyjeT4bHELUEC_7B4A>
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: Thu, 28 Sep 2023 22:15:54 -0000
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