Re: [auth48] AUTH48: RFC-to-be 9408 <draft-ietf-opsawg-sap-15> for your review
"Victor Lopez (Nokia)" <victor.lopez@nokia.com> Wed, 31 May 2023 13:16 UTC
Return-Path: <victor.lopez@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 282DDC151084; Wed, 31 May 2023 06:16:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.094
X-Spam-Level:
X-Spam-Status: No, score=-2.094 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 SF9ATNvyfmjQ; Wed, 31 May 2023 06:16:22 -0700 (PDT)
Received: from EUR02-DB5-obe.outbound.protection.outlook.com (mail-db5eur02on2070e.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe12::70e]) (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 56055C14CF12; Wed, 31 May 2023 06:16:04 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=lOFKieCHSVm0oIX6LeouGPZpKU+acJcCxssAeh32lX7rPm9tFfMA22hi351mJ6vleLmA6/UXP7do3f2fzUXNnPp2/LBIujcLVUWjrIkWQiHUHKOtn2DKZHdXBdn/LGX3RDThdi/SB+Jn0ogJwDWdNmZsWnXd7N0NOT9HRnShhVFfa5r/0+uTQrW9RG7RpOIzTcLDEMBt1qXljV7RHXxXT4pGmUk8mxMGKBrdoEM+vHnml4yBaoY+dBz0ePEKuOTkqgI4tQAKHsq6J3GtKMFUkmusaLmh0VW0ByTXEtlSmBv+F4Ou259dzSC4igetAtvSymZRb9ZIM7wOodt98ohxEQ==
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=6pVjQhGij42gUvo/ARVlu3cM866sp+xYnzueubYcJIo=; b=BEw0Zuyp5oR5WgUiFZD9kHqrIfw1J4pgeXklSZ4Fb/tSNu4CqeVHwVLSSu9DEb1cev7Wik3vMWUwsUdmtLAA0TvsYZwP1oH0cRK1VXpsP2La3i0ci5gs9dX4OaF/AyNgg0eoFDWeqVIc0fVUFtj3jA1n++f+MmPUcqmG0dzBfiAmaLG5ChXj0xeT65bWZU7Jz6LkxwOrCopCpUlsTZjwlLZNitpjCeuGBEoxewqv02/54wdl4sRoNrwcnR9yibIqeILqGitRv6wsPHX9IsGYS0a3mTI/rzHIlRhPjxbyoPiK2ROy22Hw4j/Eztj8YNj6fAUwkIFkjkoCuMdHj7cY2w==
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=6pVjQhGij42gUvo/ARVlu3cM866sp+xYnzueubYcJIo=; b=iVPNh1UY+or6kUoPhR/PQv89XLCi1c2oHxkaZ5QwcPZxRex9PcScVY2wL+aTDKDOD9mVdutnIHNVVOPBve95UlZWvPHYQP9Xj1/pEYkrxZd0bVyjlYUohi7vTc3Gt3g5iMZE/X2sJ86uIb06PgW4B5lT/coeSyL3tbosZlljXw5H0HtffvOUlUbGuTCJkM7E2nfMUBtH/GZjVMB/JgNi2iKiknLUMz8V4I2osqlRmgu+s6u6Wd6PbdTejOUrAX5eDgwsvfQ0HXhtBRA8uKIx4J/RWFv5JML9xV6tfHB4BmuyYjoOfr8xCKZ8ZGT5n3Mnw8EeeXnJNfn//BlCxir6tw==
Received: from AM6PR07MB5042.eurprd07.prod.outlook.com (2603:10a6:20b:32::11) by AS2PR07MB9301.eurprd07.prod.outlook.com (2603:10a6:20b:60e::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6433.24; Wed, 31 May 2023 13:15:56 +0000
Received: from AM6PR07MB5042.eurprd07.prod.outlook.com ([fe80::455:f1db:8e29:7e5a]) by AM6PR07MB5042.eurprd07.prod.outlook.com ([fe80::455:f1db:8e29:7e5a%5]) with mapi id 15.20.6433.024; Wed, 31 May 2023 13:15:56 +0000
From: "Victor Lopez (Nokia)" <victor.lopez@nokia.com>
To: "Samier Barguil Giraldo (Nokia)" <samier.barguil_giraldo@nokia.com>, Lynne Bartholomew <lbartholomew@amsl.com>, "mohamed.boucadair@orange.com" <mohamed.boucadair@orange.com>
CC: "rfc-editor@rfc-editor.org" <rfc-editor@rfc-editor.org>, "oscar.gonzalezdedios@telefonica.com" <oscar.gonzalezdedios@telefonica.com>, "bill.wu@huawei.com" <bill.wu@huawei.com>, "opsawg-ads@ietf.org" <opsawg-ads@ietf.org>, "opsawg-chairs@ietf.org" <opsawg-chairs@ietf.org>, "adrian@olddog.co.uk" <adrian@olddog.co.uk>, "rwilton@cisco.com" <rwilton@cisco.com>, "auth48archive@rfc-editor.org" <auth48archive@rfc-editor.org>
Thread-Topic: AUTH48: RFC-to-be 9408 <draft-ietf-opsawg-sap-15> for your review
Thread-Index: AQHZjO4zmmjMaoEO9k2xtCc5qcKtfa9nfDeAgAJJOYCAALk4AIACR2yAgAeE4QCAAB8Eyw==
Date: Wed, 31 May 2023 13:15:51 +0000
Message-ID: <AM6PR07MB50423F1FEC3D3E67392EA0A880489@AM6PR07MB5042.eurprd07.prod.outlook.com>
References: <20230522204421.EB9471A24CAF@rfcpa.amsl.com> <18908_1684828144_646C6FF0_18908_314_1_PAVPR02MB96732B64071D914119A9268A88409@PAVPR02MB9673.eurprd02.prod.outlook.com> <655870B8-2292-4B96-8325-0A5352C67D47@amsl.com> <28689_1684993596_646EF63C_28689_95_1_PAVPR02MB96736180E4801A5C51A7F98088469@PAVPR02MB9673.eurprd02.prod.outlook.com> <CCA835DB-2EDE-45A5-9439-1A7C77E40386@amsl.com> <AM0PR07MB5235DFBC55D140528D5D8939BB489@AM0PR07MB5235.eurprd07.prod.outlook.com>
In-Reply-To: <AM0PR07MB5235DFBC55D140528D5D8939BB489@AM0PR07MB5235.eurprd07.prod.outlook.com>
Accept-Language: en-US, en-150, es-ES
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: AM6PR07MB5042:EE_|AS2PR07MB9301:EE_
x-ms-office365-filtering-correlation-id: bacc1535-5a38-4b97-af18-08db61d92b40
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: HzStbNSDYp5HzfoxwbJJvnQazMIULdmQQEFgNCZkbFY1FRHlLm0tQfmKoMYU4sbq4mPADlhl+jRA49bmj2zmlCh/SvLR9quU1ljOLoXztovhDt66JWNv7l8SgvaAO0jL8FpH6AAhUZQ5fzJLGenrVKytDUJ8TvU+0BQMY0p8MHVFULf7Cq8/xXTsUZ+VvkeaGFgCHiPO6z3XfSm00K84/zqePXNJoe7tYnLgbBhlieNcQwtpcm4M3zMK87DPToUgvn/RTypvAiUm96Wa7qKZPcYCJvEttWOxOoDgNi8RgHW49QLHGzoUTpN2fadDBDiaTCEn/DR+1fyHJqf4CKcuUAnII/jyPEhUBMecgTa0EHTVN2jx8iT2XdQ8r4bqkJP2dOsIj7TUxBL7NrBXr/wFVHU/eRdLHFnLdONkt/MlTant9pORWtgLAuJUWU8mvpBJnKwgZ9u0YhmZtc9vEfWlvcc9uF2NBAJDmTuSrGEJGVdIS/1nijjOOl/ftKtpda0YxMa3XMnb7z6gNzNIXpZlcePAE86PWnJ7Hcri78bxDaUTrT0o5AKVqG/VXjth702qnsq4sT9f1nFPFa0nZ14NsAFV8Y3ff1UU/IkrjRwHPtAfCrhnVH1PMnQICot7X1syetbq2cEtIkDSpoovm2yZ3Q==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM6PR07MB5042.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230028)(4636009)(39860400002)(346002)(376002)(396003)(366004)(136003)(451199021)(66574015)(83380400001)(186003)(30864003)(2906002)(64756008)(4326008)(66446008)(66556008)(91956017)(66476007)(76116006)(66946007)(71200400001)(316002)(6666004)(7696005)(110136005)(54906003)(478600001)(45080400002)(7416002)(5660300002)(26005)(52536014)(9686003)(53546011)(6506007)(21615005)(41300700001)(966005)(8936002)(8676002)(55016003)(38100700002)(122000001)(82960400001)(38070700005)(166002)(33656002)(86362001)(84970400001)(559001)(579004); DIR:OUT; SFP:1102;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: j3w7RrW8uSVedIMg9p3NaZo1a61T94c5B4U7uEXmPK0obDzdp4oT/vFO1hGeiBY0yHrbfYYXNlFVo8GJ28jtwGw7ypHOuw5aVOCnzWlGT+85f8dKE32duUHGifXVUav5NN1R8PnKLP9z8p9YcTOa3G3MaXBebu68vY0oPTBmA5JcMH4ShT7wvs3NJSXg5fm+0ZfNBSP3jzmRPENwxSmQXU0YVE1D6hjKuXML/qSR8FmJKtC5tKvZFWTbOcbmN3y9TsgoBb36duZPXmT1oR0ieF+mU9mepyg87gEFIs+JR+/hSi3/R3j2z5I2Q4pWVUUX3gCgRVJqw6CM0iOWLjSUaVH3oIRPwwzHOUSNFzQk7xht3gNBqvfZuyJ1WOltD3zk4Xjev2YzJXm0NkTD18bV5CgNPybkSzw50NYitiFfpRmkcuFgb/NABdUXszx4Im88Si+2hovg0191CHIehntulSqJDWQJcu6A93Q6lhKHIFjvRBb9OlwLKGHbgzGmcVZ4kJDxbY19Bd5Dt3Mhx/HUcyNntZ4lOlo2oWynuDkvLah1CzWS6rcK6Nql4UsSZGMlKMw1sYcs6vICDrKwO3r5WDgpIX0N5vaI2KJ6R+6+oItQTKeCCXALcesvi1zaORyV+CEtXDNnY+cP0JBROzFG9vnjdqLdVyHfhwBiPOdG3+48oWL/0yMfLfloyfXGLBbRA4UKUwMYAoG6L/45RCg9xDIdGxuB92kHtrLOxKDPCDED3QSG7X9npTHreqZ46IcqSJs+t3HMErZQKmypqfx6xhif5t5fdYLm3IlZtbxGD03cv9+Iy2cyQYKbd6pgBp27TZRH28dtPYJS0YshPJLMPDsQXiR0VkRUtze4PMMNvNJR/e5jbQgUTdWhtupOTMLm90XoCX1DG6FGtsJrwIYE7VBlldCU7b6R/j8+/jlhnWH6olrmu6Ih2CJNI5LWuOAPcM+tdNgvwE5A56/QJqIVhTVBWIKzokg41TN/XFi3fjxEM9bvqKdebTdzsU8UOM3C89sD7ST44uhYAOCy82TJJYT2O4AeZCX0vh7MTutNHXSal7G76dz7XLXfQVDeqwzx6hX3h04iOejQ0hpLOQ0k2uauBfEYYAYCVhNYxz41LXYySzTUdCUDbAgKJYlUVwTdMMpF8px94MQDluJjIBBUevTBpFpvzVkfZGTrji+i5KyQ0dlD+PRllwD80gXE7V3gaBIhSt5vSW+RoGGeZKo2IC795La7Pl+uJMr1a4PlBkfaC1S0FWqWl9f64nxG+KyU7jYqWEAsrQxMS+EGz+H9NiKM3RwGXuZz7GpeXzJty8U+UaCgv6VGWH9yKqU3Xk5oIVADyV89KUKTlX26MkcvYQsFoJu5kLK3hEIpdOZbIz4XZOsKuBVxTkmVOwz9CPzXWq79Fi6u/bumVOd0AfTugjZCaoM7f9QGhC9dUBawtbNFZ63VMColde2eeWZdl4JP5YbJn2MjQ0NpLJv/kcFEKsV6H1bU4ILWTUMNlDGGlF5evDpHssQybIJinavY/Hj3/zHUNt2qg1n2WAMWez1AiSx0MFESOX4ynuG7DJzpyyXbZLMu5IMum0gu+PAiSZRs
Content-Type: multipart/alternative; boundary="_000_AM6PR07MB50423F1FEC3D3E67392EA0A880489AM6PR07MB5042eurp_"
MIME-Version: 1.0
X-OriginatorOrg: nokia.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: AM6PR07MB5042.eurprd07.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: bacc1535-5a38-4b97-af18-08db61d92b40
X-MS-Exchange-CrossTenant-originalarrivaltime: 31 May 2023 13:15:56.3907 (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: LGetWFYmNWC/nj3o2dn/wsdFitpqwmjWid6VuY1o5jIbfpgpmtnpsVt1chdw4H9kUzi5FIpEw/ZYK5kJpZcdAg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS2PR07MB9301
Archived-At: <https://mailarchive.ietf.org/arch/msg/auth48archive/hMKZbeQGRq2QU6I8RwhzM_VI2r4>
Subject: Re: [auth48] AUTH48: RFC-to-be 9408 <draft-ietf-opsawg-sap-15> 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: Wed, 31 May 2023 13:16:27 -0000
Hi I’m good to go too. Thanks Regards, Victor From: Samier Barguil Giraldo (Nokia) <samier.barguil_giraldo@nokia.com> Date: Wednesday, 31 May 2023 at 07:24 To: Lynne Bartholomew <lbartholomew@amsl.com>, mohamed.boucadair@orange.com <mohamed.boucadair@orange.com> Cc: rfc-editor@rfc-editor.org <rfc-editor@rfc-editor.org>, oscar.gonzalezdedios@telefonica.com <oscar.gonzalezdedios@telefonica.com>, bill.wu@huawei.com <bill.wu@huawei.com>, Victor Lopez (Nokia) <victor.lopez@nokia.com>, opsawg-ads@ietf.org <opsawg-ads@ietf.org>, opsawg-chairs@ietf.org <opsawg-chairs@ietf.org>, adrian@olddog.co.uk <adrian@olddog.co.uk>, rwilton@cisco.com <rwilton@cisco.com>, auth48archive@rfc-editor.org <auth48archive@rfc-editor.org> Subject: RE: AUTH48: RFC-to-be 9408 <draft-ietf-opsawg-sap-15> for your review Hello Lynne, This version looks good to me and I approve its publication. Regards, Samier Barguil -----Original Message----- From: Lynne Bartholomew <lbartholomew@amsl.com> Sent: Friday, May 26, 2023 6:35 PM To: mohamed.boucadair@orange.com Cc: rfc-editor@rfc-editor.org; oscar.gonzalezdedios@telefonica.com; Samier Barguil Giraldo (Nokia) <samier.barguil_giraldo@nokia.com>; bill.wu@huawei.com; Victor Lopez (Nokia) <victor.lopez@nokia.com>; opsawg-ads@ietf.org; opsawg-chairs@ietf.org; adrian@olddog.co.uk; rwilton@cisco.com; auth48archive@rfc-editor.org Subject: Re: AUTH48: RFC-to-be 9408 <draft-ietf-opsawg-sap-15> 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, Med. We have changed "which" to "that" per your note below. The latest files are posted here. Please refresh your browser: https://www.rfc-editor.org/authors/rfc9408.txt https://www.rfc-editor.org/authors/rfc9408.pdf https://www.rfc-editor.org/authors/rfc9408.html https://www.rfc-editor.org/authors/rfc9408.xml https://www.rfc-editor.org/authors/rfc9408-diff.html https://www.rfc-editor.org/authors/rfc9408-rfcdiff.html https://www.rfc-editor.org/authors/rfc9408-auth48diff.html https://www.rfc-editor.org/authors/rfc9408-lastdiff.html https://www.rfc-editor.org/authors/rfc9408-lastrfcdiff.html https://www.rfc-editor.org/authors/rfc9408-xmldiff1.html https://www.rfc-editor.org/authors/rfc9408-xmldiff2.html https://www.rfc-editor.org/authors/rfc9408-alt-diff.html We have also noted your approval on the AUTH48 status page: https://www.rfc-editor.org/auth48/rfc9408 Many thanks to you for your help and patience! RFC Editor/lb > On May 24, 2023, at 10:46 PM, <mohamed.boucadair@orange.com> <mohamed.boucadair@orange.com> wrote: > > Hi Lynne, > > Thank you for taking care of the changes. > > For item 17: s/which/that > > Other than that, this version looks good to me and I approve its publication. > > Many thanks for your careful edits. Much appreciated as usual. > > Cheers, > Med > >> -----Message d'origine----- >> De : Lynne Bartholomew <lbartholomew@amsl.com> Envoyé : mercredi 24 >> mai 2023 20:44 À : BOUCADAIR Mohamed INNOV/NET >> <mohamed.boucadair@orange.com> Cc : rfc-editor@rfc-editor.org; >> oscar.gonzalezdedios@telefonica.com; >> samier.barguil_giraldo@nokia.com; bill.wu@huawei.com; >> victor.lopez@nokia.com; opsawg-ads@ietf.org; opsawg-chairs@ietf.org; >> adrian@olddog.co.uk; rwilton@cisco.com; auth48archive@rfc-editor.org >> Objet : Re: AUTH48: RFC-to-be 9408 <draft-ietf-opsawg-sap-15> for >> your review >> >> Hi, Med. >> >> Thank you for the emails and clarifications! We have updated this >> document per your notes below. >> >> Regarding singular vs. plural: We reverted to the style used in the >> original, even though there are several instances of "VPNs" as used >> in the original (e.g., the second sentence of the Introduction). We >> followed suit with UNI/NNI vs. UNIs/NNIs and UNI-N (i.e., reverted >> our updates). >> >> = = = = = >> >> Regarding this question and your reply: >> >>>> 1) <!-- [rfced] We changed "A YANG Model" to "A YANG Network >> Model" >>>> in the abbreviated (running) document title to match "Network >> Model" >>>> in the full title. Please let us know any concerns. >>>> >>>> Original: >>>> A YANG Model for SAPs >>>> >>>> Currently: >>>> A YANG Network Model for SAPs --> >>>> >>>> >>> >>> [Med] The mention of "network model" is important here to insist >> that this is not about a device data model. We can update the title >> to align with the usage in RFC9182/9291: >>> >>> NEW: >>> A YANG Network Data Model for Service Attachment Points (SAPs) >> >> Perhaps we misunderstood your request. The expanded "SAPs" made the >> abbreviated title too long. We received this warning: >> >> Warning: Expected a title or title abbreviation of not more than 40 >> character for the page header, found 62 characters >> >> We changed the full title to "A YANG Network Data Model for Service >> Attachment Points (SAPs)" and the abbreviated title to "A YANG >> Network Data Model for SAPs". Please let us know any concerns. >> >> = = = = = >> >> Regarding this question and your "NEW" text: >> >>>> 17) <!-- [rfced] Appendix D: This sentence did not parse. We >>>> updated the text per the last sentence of Appendix A, Paragraph >> 1. >>>> If this update is incorrect, please clarify the meaning of "and >> that >>>> none of ...". >>>> >>>> Original: >>>> This is >>>> particularly inferred from the administrative 'service-status' >>>> which >>>> is set to 'ietf-vpn-common:admin-down' for all the services that >> are >>>> supported by these two SAPs and that none of the anomalies >> discussed >>>> in Section 5 are detected. >>>> >>>> Currently: >>>> This is >>>> particularly inferred from the administrative 'service-status', >> which >>>> is set to 'ietf-vpn-common:admin-down' for all the services that >> are >>>> supported by these two SAPs. Note that none of the anomalies >>>> discussed in Section 5 are detected. --> >>>> >>> >>> [Med] What about: >>> >>> NEW: >>> This is >>> particularly inferred from (1) the administrative 'service- >> status' which >>> is set to 'ietf-vpn-common:admin-down' for all the services that >> are >>> supported by these two SAPs and (2) the absence of the anomalies >> discussed >>> in Section 5. >> >> Is the administrative 'service-status' only sometimes set to 'ietf- >> vpn-common:admin-down' (in which case "which" should be "that"), or >> is it always set to 'ietf-vpn-common:admin-down' (in which case a >> comma should precede the "which")? >> >> = = = = = >> >> The latest files are posted here. Please refresh your browser: >> >> > https://www.rfc-editor.org/authors/rfc9408.txt > https://www.rfc-editor.org/authors/rfc9408.pdf > https://www.rfc-editor.org/authors/rfc9408.html > https://www.rfc-editor.org/authors/rfc9408.xml > https://www.rfc-editor.org/authors/rfc9408-diff.html > https://www.rfc-editor.org/authors/rfc9408-rfcdiff.html > https://www.rfc-editor.org/authors/rfc9408-auth48diff.html > > https://www.rfc-editor.org/authors/rfc9408-alt-diff.html > https://www.rfc-editor.org/authors/rfc9408-xmldiff1.html > https://www.rfc-editor.org/authors/rfc9408-xmldiff2.html > https://www.rfc-editor.org/authors/rfc9408-alt-diff.html >> Thanks again! >> >> RFC Editor/lb >> >> >>> On May 23, 2023, at 10:29 AM, mohamed.boucadair@orange.com wrote: >>> >>> Hi Lynne, >>> >>> Sure. The proposed change is as follows: >>> >>> OLD: >>> * L3VPNs [RFC4364] >>> >>> * Virtual Private LAN Services (VPLSs) [RFC4761] [RFC4762] >>> >>> * Virtual Private Wire Services (VPWSs) [RFC8214] >>> >>> * BGP MPLS-based Ethernet VPNs [RFC7432] >>> >>> * VPWSs in Ethernet VPNs [RFC8214] >>> >>> * Provider Backbone Bridging combined with Ethernet VPNs (PBB- >> EVPNs) >>> [RFC7623] >>> >>> * VXLAN-based EVPNs [RFC8365] ("VXLAN" stands for "Virtual >>> eXtensible Local Area Network") >>> >>> * Virtual Networks [RFC8453] >>> >>> * Enhanced VPN (VPN+) [ENHANCED-VPN] >>> >>> * Network slices [IETF-NETWORK-SLICES] >>> >>> * SD-WAN overlay networks [BGP-SDWAN-USAGE] >>> >>> * Basic IP connectivity >>> >>> NEW: >>> * L3VPN [RFC4364] >>> >>> * Virtual Private LAN Service (VPLS) [RFC4761] [RFC4762] >>> >>> * Virtual Private Wire Service (VPWS) [RFC8214] >>> >>> * BGP MPLS-based Ethernet VPN [RFC7432] >>> >>> * VPWS in Ethernet VPN [RFC8214] >>> >>> * Provider Backbone Bridging combined with Ethernet VPN (PBB- >> EVPN) >>> [RFC7623] >>> >>> * VXLAN-based EVPN [RFC8365] ("VXLAN" stands for "Virtual >>> eXtensible Local Area Network") >>> >>> * Virtual Networks [RFC8453] >>> >>> * Enhanced VPN (VPN+) [ENHANCED-VPN] >>> >>> * Network slice service [IETF-NETWORK-SLICES] >>> >>> * SD-WAN [BGP-SDWAN-USAGE] >>> >>> * Basic IP connectivity >>> >>> Cheers, >>> Med >> >> >> = = = = = = = = >> >>> On May 23, 2023, at 4:28 AM, mohamed.boucadair@orange.com wrote: >>> >>> Re-, >>> >>> Thanks for sharing this edited version. Overall, the edits look >> good. However: >>> >>> (1) Rather than using the plural form as suggested in the edited >> version, I would maintain the singular form of the services >> (Original) listed right after: >>> >>> A SAP network topology can be used for one or multiple service >> types >>> ('service-type'). Examples of supported service types are as >>> follows: >>> >>> For example, we are referring to "VPN" as a service, not the VPN >> instances of the service. FWIW, this would be consistent with the >> usage in Section 3 of RFC9181. >>> >>> The same apply for the changes in the abstract, but I'm OK to >> maintain the edits in the abstract if you prefer. >>> >>> (2) I'm not sure we need to add "see" when pointing to refs. I >> would revert to the OLD versions. There are many occurrences in the >> edited version. >>> >>> (3) Please make this change in Section 2: >>> >>> OLD: >>> Attachment Circuit (AC): A channel that connects a Customer >> Edge >>> (CE) to a Provider Edge (PE). The AC may be a physical or >> logical >>> link (Section 6.1 of [RFC4026]). >>> >>> NEW: >>> Attachment Circuit (AC): A channel that connects a Customer >> Edge >>> (CE) to a Provider Edge (PE). >>> >>> FWIW, this change was shared with the WG since 02/23. The >> rationale can be seen at: >> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fma >> ilarchive.ietf.org%2Farch%2Fmsg%2Fopsawg%2F_Iiv16zSUnnGuSxywvXlROqh2 >> AI%2F&data=05%7C01%7Cmohamed.boucadair%40orange.com%7C0db08cfbe50745 >> 6f7f9f08db5c871280%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C6382 >> 05510092419895%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV >> 2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=DF8f31Dp >> wQBzL0SCCEm1WQaz1Z2aBOT1i2IVVt83m4c%3D&reserved=0. >>> >>> Thank you. >>> >>> Cheers, >>> Med >> >> = = = = = = = = >> >>> On May 23, 2023, at 12:49 AM, mohamed.boucadair@orange.com wrote: >>> >>> Dear RFC Editor, all, >>> >>> Please see inline. >>> >>> Cheers, >>> Med >>> >>>> -----Message d'origine----- >>>> De : rfc-editor@rfc-editor.org <rfc-editor@rfc-editor.org> Envoyé : >>>> lundi 22 mai 2023 22:44 À : BOUCADAIR Mohamed INNOV/NET >>>> <mohamed.boucadair@orange.com>; >>>> oscar.gonzalezdedios@telefonica.com; >>>> samier.barguil_giraldo@nokia.com; bill.wu@huawei.com; >>>> victor.lopez@nokia.com Cc : rfc-editor@rfc-editor.org; >>>> opsawg-ads@ietf.org; opsawg- chairs@ietf.org; adrian@olddog.co.uk; >>>> rwilton@cisco.com; auth48archive@rfc-editor.org Objet : Re: AUTH48: >>>> RFC-to-be 9408 <draft-ietf-opsawg-sap-15> 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] We changed "A YANG Model" to "A YANG Network >>>> Model" in the abbreviated (running) document title to match >>>> "Network Model" in the full title. Please let us know any >>>> concerns. >>>> >>>> Original: >>>> A YANG Model for SAPs >>>> >>>> Currently: >>>> A YANG Network Model for SAPs --> >>>> >>>> >>> >>> [Med] The mention of "network model" is important here to insist >> that this is not about a device data model. We can update the title >> to align with the usage in RFC9182/9291: >>> >>> NEW: >>> A YANG Network Data Model for Service Attachment Points (SAPs) >>> >>> >>>> 2) <!-- [rfced] Abstract and subsequent: It looks a bit odd to >>>> use "User-Network Interface" for "UNI" but "Network-to-Network >>>> Interface" >>>> for "NNI" and "UNI-N (User-to-Network Interface, Network side) >>>> [RFC6215]" as seen in Section 3. >>>> >>>> Does "User-Network Interface" mean "User-to-Network Interface", >>> >>> [Med] Yes. Both are actually used in existing RFCs. "User-Network >> Interface" is what is used by some other SDOs (see, e.g., the MEF >> refs in the I-D). That's said, we need to be consistent and use the >> same form for both UNI and NNI. >>> >>> as >>>> used in some RFCs? Or does it mean "the user network's >>>> interface"? >>>> >>>> (Side note: We see a few instances of "Network-Network >> Interface" >>>> in published RFCs, but "Network-to-Network Interface" is used >> more >>>> often.) >>> >>> [Med] OK to use "*-to-*" for both UNI/NNI. >>> >>>> >>>> Original: >>>> Both User-Network Interface (UNI) and Network-to- Network >>>> Interface (NNI) are supported in the SAP data model. >>>> ... >>>> Given that User-Network Interface (UNI) and Network-to-Network >>>> Interface (NNI) are reference points that are widely used by >>>> operators to indicate the demarcation points when delivering >>>> services, both UNI and NNI SAPs are supported in the document. >>>> ... >>>> etc. --> >>>> >>>> >>>> 3) <!-- [rfced] Section 1: This sentence did not parse. We >>>> updated it as follows. If this is incorrect, please provide >>>> clarifying text. >>>> >>>> Original: >>>> Whether a SAP topology is dedicated to services of a specific >>>> service type, an individual service, or shared among many >> services >>>> of different types is deployment specific. >>>> >>>> Currently: >>>> Whether a SAP topology is dedicated to services of a specific >>>> service type or an individual service, or is shared among many >>>> services of different types, is deployment specific. --> >>>> >>> >>> [Med] Works for me. Thanks. >>> >>>> >>>> 4) <!-- [rfced] Section 3: We changed "the module" to "the >> model" >>>> in the second sentence here, as it appears that the text refers >> to >>>> the model and not to the YANG module provided in Section 6. If >>>> this update is incorrect, please provide clarifying text. >>>> >>>> Original (the previous sentence is included for context): >>>> The model is also used to retrieve the network reference points >>>> where a service is being delivered to customers. For services >>>> that require resources from peer networks, the module can also >> be >>>> used to expose NNIs. >>>> >>>> Currently: >>>> The model is also used to retrieve the network reference points >>>> where a service is being delivered to customers. >>>> For services that require resources from peer networks, the model >>>> can also be used to expose NNIs. --> >>>> >>> >>> [Med] OK. >>> >>>> >>>> 5) <!-- [rfced] Please review each artwork element in this >>>> document. >>>> Specifically, should any artwork element be tagged as sourcecode >>>> or another element? For example, are Figures 7, 9, 10, and 12 in >>>> the appendices JSON? >>> >>> [Med] Yes. >>> >>> If yes, should an Informative Reference be >>>> provided - perhaps to RFC 8259 - in text just prior to Figure 7? >>> >>> [Med] I suggest to add the following + list 7951 as an Informative >> Reference: >>> >>> NEW: >>> The message body depicted in the figures is encoded following the >>> the JSON encoding of YANG-modeled data as per [[RFC7951]. >>> >>>> >>>> If the current list of preferred values for "type" >>>> >> (https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2 >>>> Fwww.rfc-editor.org%2Fmaterials%2Fsourcecode- >>>> >> types.txt&data=05%7C01%7Cmohamed.boucadair%40orange.com%7Caa068512 >>>> >> cee44609f0ca08db5b055b54%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C >>>> >> 0%7C638203851114072726%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDA >>>> >> iLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sd >>>> >> ata=5NjV1F%2B24%2F8MtaBk3IgE0S0PTB9M31fHpqEG%2BjJoI2k%3D&reserved= >>>> 0) >>>> does not contain an applicable type, then feel free to let us >>>> know. >>>> Also, it is acceptable to leave the "type" attribute not set. --> >>>> >>>> >>>> 6) <!-- [rfced] Section 3: As we don't see "P node" or "P nodes" >>>> mentioned anywhere else in this document and the next sentence >>>> after >>>> this text mentions Figure 2 (which shows PE nodes), we changed >>>> "P nodes" to "PE nodes" here. If this is incorrect, please >>>> provide >>>> text that clarifies the meaning of "P nodes". >>> >>> [Med] The OLD version is correct. Please revert back. >>> >>> "P" nodes are hidden in the cloud shown in Figure 2, for example. >> We used to have these nodes drawn there but we removed them to >> simplify the figures. >>> >>> FWIW, please see >> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fda >> tatracker.ietf.org%2Fdoc%2Fhtml%2Frfc4026%23autoid- >> 37&data=05%7C01%7Cmohamed.boucadair%40orange.com%7C0db08cfbe507456f7 >> f9f08db5c871280%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C6382055 >> 10092419895%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2lu >> MzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=4Ad1rENUXqN >> VFtbzWrWtrTpD7n70XxR4SnEKvVPuB3w%3D&reserved=0. >>> >>> If needed, we can make this change: s/P nodes/P nodes (Section >> 5.3.1 of [RFC4026]) >>> >>>> >>>> Original (the next sentence is included for context): >>>> The service orchestration layer does not need to know about all >>>> the >>>> internals of the underlying network (e.g., P nodes). Figure 2 >>>> shows >>>> the abstract network view as seen by a service orchestrator. >>>> >>>> Currently: >>>> The service orchestration layer does not need to know about all >>>> the >>>> internals of the underlying network (e.g., PE nodes). --> >>>> >>>> >>>> 7) <!-- [rfced] Section 4: We had trouble following the use of >>>> capitalization in this sentence (for example, as compared to >>>> "SAP network model"). >>>> >>>> Original: >>>> The SAP network model augments the Network model [RFC8345] >>>> and imports the Network Topology model, while other technology- >>>> specific topology models (e.g., Traffic Engineering (TE) >>>> Topologies >>>> model [RFC8795] or Layer 3 Topologies model [RFC8346]) augment >>>> the >>>> Network Topology model. >>>> >>>> Possibly: >>>> The SAP network model augments the network model defined in >>>> [RFC8345] and imports the network topology model defined in >>>> [RFC8345], while other technology-specific topology models (e.g., >>>> the model for Traffic Engineering (TE) topologies [RFC8795] or >>>> the >>>> model for Layer 3 topologies [RFC8346]) augment the network >>>> topology model defined in [RFC8345]. --> >>>> >>> >>> [Med] OK. >>> >>>> >>>> 8) <!-- [rfced] Section 4: We see that "TP" and "TTP" are >> defined >>>> in >>>> this paragraph, but these abbreviations are not used again. >> Which >>>> of >>>> the following update options would you prefer? >>>> >>>> 1. Use "TP" instead of "termination point" in the eight >> subsequent >>>> instances of this term (except for Section 6, where we would >>>> change >>>> "parent termination point" to "parent termination point (TP)" and >>>> then use "TP" in the next sentence). >>>> >>>> 2. Remove the abbreviations from this paragraph and spell out >>>> "termination point". >>>> >>>> Original: >>>> SAPs can be seen as customer-facing termination points (TPs) with >>>> specific service provisions. However, a difference between SAPs >>>> and >>>> TPs is that links are terminated by a single TP (Section 4.4.6 of >>>> [RFC8345]) while an AC can be terminated by multiple SAPs. Also, >>>> a >>>> SAP is not a tunnel termination point (TTP) (Section 3.6 of >>>> [RFC8795]) nor a link. --> >>>> >>> >>> [Med] I prefer to leave the Original version with "termination >> point" expanded. The abbreviations are included to help readers >> correlate with other context. I don't think a change is needed here. >>> >>>> >>>> 9) <!-- [rfced] Section 5: Should "network modules" and "SAP >>>> network >>>> module" in these sentences be "network models" and "SAP network >>>> model"? We ask (particularly in the case of "SAP network >> module") >>>> because of this sentence from Section 4.4 of [RFC8969], as it >> does >>>> not use the word "module": >>>> >>>> "Service Decomposition allows to decompose service models at the >>>> service level or network models at the network level into a set >>>> of >>>> device models at the device level." >>>> >>>> Original: >>>> | Leveraging the service types defined in [RFC9181] is meant to >>>> | ease the correlation between the SAP topology and the >>>> | corresponding network modules that are used to provision a >>>> | specific service over a provider's network. >>>> ... >>>> That mapping is used, for example, >>>> when the controller translates this SAP network module into >>>> device >>>> modules (Section 4.4 of [RFC8969]). >>>> >>>> Possibly: >>>> | Leveraging the service types defined in [RFC9181] is meant to >>>> | ease the correlation between the SAP topology and the >>>> | corresponding network models that are used to provision a >>>> | specific service over a provider's network. >>>> ... >>>> That mapping is used, for example, >>>> when the controller translates this SAP network model into device >>>> models (Section 4.4 of [RFC8969]). --> >>>> >>> >>> [Med] Works for me. Thanks. >>> >>>> >>>> 10) <!-- [rfced] Section 5: Please clarify the meaning of "in >>>> association" in this sentence. >>>> >>>> Original (the previous sentence is included for context): >>>> The same SAP may appear under distinct service types. In such a >>>> case, the same identifier is used for these service types in >>>> association. >>>> >>>> Possibly: >>>> The same SAP may appear under distinct service types. In such a >>>> case, the same identifier is used for these service types in >>>> order to associate them. --> >>>> >>> >>> [Med] What about: >>> >>> NEW: >>> The same SAP may appear under distinct service types. In such a >>> case, the same identifier is used for a shared SAP for each of >> these >>> service types. >>> >>> >>>> >>>> 11) <!-- [rfced] Section 5: As we do not see "mode" or "modes" >>>> used >>>> anywhere else in this document, we changed "device modes" to >>>> "device >>>> models" in this sentence. >>> >>> [Med] The change is correct. Thanks for catching this. >>> >>> >>> If this is incorrect, should the use of >>>> "modes" be clarified for readers? >>>> >>>> Original: >>>> It >>>> is the responsibility of the controller to ensure that consistent >>>> references are used in the SAP and underlying device modes or any >>>> other device inventory mechanism. >>>> >>>> Currently: >>>> The controller is responsible for ensuring that consistent >>>> references are used in the SAP and underlying device models or >>>> any >>>> other device inventory mechanism. --> >>>> >>>> >>>> 12) <!-- [rfced] Sections 5 and 6: We defined "IRB" as >>>> "Integrated >>>> Routing and Bridging (IRB) interface", per RFC 9135 and other >>>> post-6000 published RFCs. >>>> >>>> Also, please note that in Section 6 we expanded "IP-VRF" as "IP >>>> Virtual Routing and Forwarding" for ease of the reader. >>>> >>> >>> [Med] OK. >>> >>>> Please let us know any concerns. >>>> >>>> Original: >>>> 'interface-type': Indicates whether a SAP is bound to a physical >>>> port, a loopback interface, a Link Aggregation Group (LAG) >>>> interface [IEEE802.1AX], an Integrated Routing Bridge (IRB) >>>> (e.g., >>>> [RFC9135]), a local bridge reference, etc. >>>> ... >>>> "Integrated Routing Bridge (IRB). An IRB typically >>>> connects an IP-VRF to a bridge domain."; >>>> >>>> Currently: >>>> 'interface-type': Indicates whether a SAP is bound to a physical >>>> port, a loopback interface, a Link Aggregation Group (LAG) >>>> interface [IEEE802.1AX], an Integrated Routing and Bridging >>>> (IRB) >>>> interface (e.g., see [RFC9135]), a local bridge reference, >>>> etc. >>>> ... >>>> "Integrated Routing and Bridging (IRB) interface. An IRB >>>> interface typically connects an IP Virtual Routing and >>>> Forwarding (IP-VRF) entity to a bridge domain."; --> >>>> >>>> >>>> 13) <!-- [rfced] Section 5: The latest version of >>>> draft-ietf-teas-ietf-network-slices (-19) does not have a >>>> Section 2.1, nor does the version (-18) provided in the original >>>> copy of this document. >>> >>> [Med] That section was renumbered to Section 3.2 >> (https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fa >> uthor-tools.ietf.org%2Fiddiff%3Furl1%3Ddraft-ietf-teas-ietf-network- >> slices-16%26url2%3Ddraft-ietf-teas-ietf-network-slices- >> 17%26difftype%3D-- >> html&data=05%7C01%7Cmohamed.boucadair%40orange.com%7C0db08cfbe507456 >> f7f9f08db5c871280%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C63820 >> 5510092576163%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2 >> luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=KkFAYskXL >> 21ew74%2Fntlb1YH7PhVpXlR%2BLMs13aBX5kc%3D&reserved=0). >>> >>> What about: >>> >>> s/Section 2.1 of [I-D.ietf-teas-ietf-network-slices]/the "Core >> Terminology" Section of [I-D.ietf-teas-ietf-network-slices] >>> >>> >>> Please see >>>> >> <https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2 >>>> Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-teas-ietf- >> network- >>>> slices- >>>> >> 19&data=05%7C01%7Cmohamed.boucadair%40orange.com%7Caa068512cee4460 >>>> >> 9f0ca08db5b055b54%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C638 >>>> >> 203851114072726%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIj >>>> >> oiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=4p4 >>>> ZMp%2Fa%2FEGEBxPsKQEOs1bVFLF21uIZx8M0kDSexOQ%3D&reserved=0>, >>>> and let us know which section number should be cited. >>>> >>>> Original: >>>> Examples of such a reference are: a site identifier (Section 6.3 >>>> of [RFC8299]), a Service Demarcation Point (SDP) identifier >>>> (Section 2.1 of [I-D.ietf-teas-ietf-network-slices]), and the IP >>>> address of a peer Autonomous System Border Router (ASBR). --> >>>> >>>> >>>> 14) <!-- [rfced] Section 6: Informative Reference RFC 8343 is >> not >>>> mentioned anywhere else in this document. Is an "import" >>>> statement >>>> missing in the YANG module (in which case it should be a >> Normative >>>> Reference instead)? >>>> >>> >>> [Med] We used to have an import in a previous version, but forgot >> to remove it when we updated the design. Please remove 8343 for the >> references and make this change: >>> >>> OLD: >>> This module imports types from [RFC6991], [RFC8343], [RFC8345], >> and >>> [RFC9181]. >>> >>> NEW: >>> This module imports types from [RFC6991], [RFC8345], and >>> [RFC9181]. >>> >>>> Also, because RFC 8453 is referenced in the YANG module, may we >>>> add >>>> "This module also references [RFC8453]." after the "This module >>>> imports" sentence? >>>> >>> >>> [Med] We don't need this change as the ref is already called out >> in Section 5. >>> >>>> Original: >>>> This module imports types from [RFC6991], [RFC8343], [RFC8345], >>>> and >>>> [RFC9181]. >>>> ... >>>> reference >>>> "RFC 8453: Framework for Abstraction and Control of TE >>>> Networks (ACTN)"; >>>> ... >>>> Under Informative References: >>>> [RFC8343] Bjorklund, M., "A YANG Data Model for Interface >>>> Management", RFC 8343, DOI 10.17487/RFC8343, March >>>> 2018, >>>> >>>> >> <https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2 >>>> Fwww.rfc- >>>> >> editor.org%2Finfo%2Frfc8343&data=05%7C01%7Cmohamed.boucadair%40ora >>>> >> nge.com%7Caa068512cee44609f0ca08db5b055b54%7C90c7a20af34b40bfbc48b >>>> >> 9253b6f5d20%7C0%7C0%7C638203851114072726%7CUnknown%7CTWFpbGZsb3d8e >>>> >> yJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D% >>>> >> 7C3000%7C%7C%7C&sdata=bg339ojOWZvxVQkbkw9eXQtuazGdWaM6dX5iy62NXqM% >>>> 3D&reserved=0>. --> >>>> >>>> >>>> 15) <!-- [rfced] Section 6: Does "independent" refer to >>>> "Indicates" >>>> (in which case it should be "independently"), or does it refer to >>>> "operational status" (in which case the current text is correct)? >>>> >>> >>> [Med] It refers to the "operational status". >>> >>>> Original: >>>> "Indicates the operational status of the SAP, >>>> independent of any service provisioned over it."; --> >>>> >>>> >>>> 16) <!-- [rfced] Security Considerations: It appears that RPC >>>> operations >>>> do not apply to this document. Please confirm. >>>> >>> >>> [Med] ACK. >>> >>>> If you have any questions, please see >>>> >> <https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2 >>>> Fwiki.ietf.org%2Fgroup%2Fops%2Fyang-security- >>>> >> guidelines&data=05%7C01%7Cmohamed.boucadair%40orange.com%7Caa06851 >>>> >> 2cee44609f0ca08db5b055b54%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7 >>>> >> C0%7C638203851114072726%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMD >>>> >> AiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&s >>>> >> data=7hC%2FMAswX%2Fot7p8qwtaWrZfrRRzpOwwLl2EUWnWlZjU%3D&reserved=0 >>>>> >>>> for details. --> >>>> >>>> >>>> 17) <!-- [rfced] Appendix D: This sentence did not parse. We >>>> updated >>>> the text per the last sentence of Appendix A, Paragraph 1. If >>>> this >>>> update is incorrect, please clarify the meaning of "and that none >>>> of ...". >>>> >>>> Original: >>>> This is >>>> particularly inferred from the administrative 'service-status' >>>> which >>>> is set to 'ietf-vpn-common:admin-down' for all the services that >>>> are >>>> supported by these two SAPs and that none of the anomalies >>>> discussed >>>> in Section 5 are detected. >>>> >>>> Currently: >>>> This is >>>> particularly inferred from the administrative 'service-status', >>>> which >>>> is set to 'ietf-vpn-common:admin-down' for all the services that >>>> are >>>> supported by these two SAPs. Note that none of the anomalies >>>> discussed in Section 5 are detected. --> >>>> >>> >>> [Med] What about: >>> >>> NEW: >>> This is >>> particularly inferred from (1) the administrative 'service- >> status' which >>> is set to 'ietf-vpn-common:admin-down' for all the services that >> are >>> supported by these two SAPs and (2) the absence of the anomalies >> discussed >>> in Section 5. >>> >>>> >>>> 18) <!-- [rfced] Please review the "Inclusive Language" portion >> of >>>> the >>>> online Style Guide at >>>> >> <https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2 >>>> Fwww.rfc- >>>> >> editor.org%2Fstyleguide%2Fpart2%2F%23inclusive_language&data=05%7C >>>> >> 01%7Cmohamed.boucadair%40orange.com%7Caa068512cee44609f0ca08db5b05 >>>> >> 5b54%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C6382038511140727 >>>> >> 26%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJ >>>> >> BTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=%2FxEg4CmJqMrsXj >>>> xFxczqrWX%2FhaHMphrGkImd8eCWeHE%3D&reserved=0>, >>>> 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. --> >>>> >>>> >>> >>> [Med] ACK. >>> >>>> 19) <!-- [rfced] The following term was used inconsistently in >>>> this >>>> document. We chose to use the latter form. Please let us know >>>> any >>>> objections. >>>> >>>> IETF network slice / IETF Network Slice (per >>>> draft-ietf-teas-ietf-network-slices-19) --> >>>> >>> >>> [Med] OK. >>> >>>> >>>> Thank you. >>>> >>>> RFC Editor/lb/rv >>>> >>>> >>>> >>>> On May 22, 2023, at 1:30 PM, rfc-editor@rfc-editor.org wrote: >>>> >>>> *****IMPORTANT***** >>>> >>>> Updated 2023/05/22 >>>> >>>> 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://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2 >>>> Fwww.rfc- >>>> >> editor.org%2Ffaq%2F&data=05%7C01%7Cmohamed.boucadair%40orange.com% >>>> >> 7Caa068512cee44609f0ca08db5b055b54%7C90c7a20af34b40bfbc48b9253b6f5 >>>> >> d20%7C0%7C0%7C638203851114072726%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiM >>>> >> C4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7 >>>> >> C%7C%7C&sdata=3X0NPJbD6s7SjNjcCgf3d4pr7%2FD3w7esNWzUEH0TK%2Fw%3D&r >>>> eserved=0). >>>> >>>> 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://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2F >>>> trustee.ietf.org%2Flicense- >>>> >> info%2F&data=05%7C01%7Cmohamed.boucadair%40orange.com%7Caa068512ce >>>> >> e44609f0ca08db5b055b54%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0% >>>> >> 7C638203851114072726%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiL >>>> >> CJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdat >>>> a=B0gciAKpYepmwZWLRH6Tbv4JE6IEMdCZWUaybG3OrMc%3D&reserved=0). >>>> >>>> * 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://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2 >>>> Fauthors.ietf.org%2Frfcxml- >>>> >> vocabulary&data=05%7C01%7Cmohamed.boucadair%40orange.com%7Caa06851 >>>> >> 2cee44609f0ca08db5b055b54%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7 >>>> >> C0%7C638203851114072726%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMD >>>> >> AiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&s >>>> >> data=IcRNNGnHecShyTp1hHzpP2vQPzREsoWILEQ%2B%2BsbNXn8%3D&reserved=0 >>>>> . >>>> >>>> * 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://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2F >>>> mailarchive.ietf.org%2Farch%2Fmsg%2Fietf-announce%2Fyb6lpIGh- >>>> >> 4Q9l2USxIAe6P8O4Zc&data=05%7C01%7Cmohamed.boucadair%40orange.com%7 >>>> >> Caa068512cee44609f0ca08db5b055b54%7C90c7a20af34b40bfbc48b9253b6f5d >>>> >> 20%7C0%7C0%7C638203851114072726%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC >>>> >> 4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C >>>> >> %7C%7C&sdata=5K2ALQOAyoHogs8kmSa6eYHpDGLAfUtNE8ojWfxcOEQ%3D&reserv >>>> ed=0 >>>> >>>> * The archive itself: >>>> >>>> >> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2F >>>> >> mailarchive.ietf.org%2Farch%2Fbrowse%2Fauth48archive%2F&data=05%7C >>>> >> 01%7Cmohamed.boucadair%40orange.com%7Caa068512cee44609f0ca08db5b05 >>>> >> 5b54%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C6382038511140727 >>>> >> 26%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJ >>>> >> BTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=%2BRtJa3WaEgZliR >>>> ajCaGS%2FdUC5tFiu3axU9yZXszk8tE%3D&reserved=0 >>>> >>>> * 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. >>>> >>> >>> > > > _________________________________________________________________________________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. > > This message and its attachments may contain confidential or privileged information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and delete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. > Thank you. >
- [auth48] AUTH48: RFC-to-be 9408 <draft-ietf-opsaw… rfc-editor
- Re: [auth48] AUTH48: RFC-to-be 9408 <draft-ietf-o… rfc-editor
- Re: [auth48] AUTH48: RFC-to-be 9408 <draft-ietf-o… mohamed.boucadair
- Re: [auth48] AUTH48: RFC-to-be 9408 <draft-ietf-o… mohamed.boucadair
- Re: [auth48] AUTH48: RFC-to-be 9408 <draft-ietf-o… Lynne Bartholomew
- Re: [auth48] AUTH48: RFC-to-be 9408 <draft-ietf-o… mohamed.boucadair
- Re: [auth48] AUTH48: RFC-to-be 9408 <draft-ietf-o… Lynne Bartholomew
- Re: [auth48] AUTH48: RFC-to-be 9408 <draft-ietf-o… mohamed.boucadair
- Re: [auth48] AUTH48: RFC-to-be 9408 <draft-ietf-o… Lynne Bartholomew
- Re: [auth48] AUTH48: RFC-to-be 9408 <draft-ietf-o… Victor Lopez (Nokia)
- Re: [auth48] AUTH48: RFC-to-be 9408 <draft-ietf-o… Lynne Bartholomew
- Re: [auth48] AUTH48: RFC-to-be 9408 <draft-ietf-o… Oscar González de Dios
- Re: [auth48] AUTH48: RFC-to-be 9408 <draft-ietf-o… Lynne Bartholomew
- Re: [auth48] AUTH48: RFC-to-be 9408 <draft-ietf-o… Qin Wu
- Re: [auth48] AUTH48: RFC-to-be 9408 <draft-ietf-o… Lynne Bartholomew
- [auth48] [IANA] Re: AUTH48: RFC-to-be 9408 <draft… Lynne Bartholomew
- [auth48] [IANA #1274572] [IANA] Re: AUTH48: RFC-t… Amanda Baber via RT
- Re: [auth48] [IANA #1274572] [IANA] Re: AUTH48: R… Lynne Bartholomew