Re: [sfc] IETF WG state changed for draft-ietf-sfc-proof-of-transit
mohamed.boucadair@orange.com Fri, 19 June 2020 06:35 UTC
Return-Path: <mohamed.boucadair@orange.com>
X-Original-To: sfc@ietfa.amsl.com
Delivered-To: sfc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 772283A00B0; Thu, 18 Jun 2020 23:35:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.096
X-Spam-Level:
X-Spam-Status: No, score=-2.096 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, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=orange.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wZpByRjISe7E; Thu, 18 Jun 2020 23:35:35 -0700 (PDT)
Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.70.35]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9BD733A00AD; Thu, 18 Jun 2020 23:35:35 -0700 (PDT)
Received: from opfednr02.francetelecom.fr (unknown [xx.xx.xx.66]) by opfednr27.francetelecom.fr (ESMTP service) with ESMTP id 49p8FK5vqsz4wRg; Fri, 19 Jun 2020 08:35:33 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1592548533; bh=8NfW0vTyP4KIUboVW527eUsfhJj9tNVXtlz2d/d5p8s=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=pcbLqbcJUXDuZUdjB4tp6zlx0ahy1AkC5hx4Axd1WV2/NYwkIQY3om8dXvjwgfwVj KdtIYhLD2/lQVS27XWOuK9xb9yDkdkpgTIjV1//abqviQ7nUxjqaTfpkJxZzA/R9yG 07k4Zuh/cim2ieqeI5D8mXiO7PYW6F+Jsi9NTLz8jsT9D/l/Lng/Kr1d5fXZFURCP8 b3tzGNM1MaSzBtiiSu4qZR77FUOx3GDq4LYYBg0gmJYPs+6SKWe4UAUdy85cwhqHvK ezE4vmLDHS9wmIMfrk2hLqrh2ik7z/cX+s9sr6lAeqd9TRvragBGTffKFcwohpc8Lp OGPePSijgPGxg==
Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.23]) by opfednr02.francetelecom.fr (ESMTP service) with ESMTP id 49p8FK4zC1z8sY7; Fri, 19 Jun 2020 08:35:33 +0200 (CEST)
From: mohamed.boucadair@orange.com
To: "draft-ietf-sfc-proof-of-transit@ietf.org" <draft-ietf-sfc-proof-of-transit@ietf.org>
CC: "Joel M. Halpern" <jmh@joelhalpern.com>, "sfc@ietf.org" <sfc@ietf.org>
Thread-Topic: [sfc] IETF WG state changed for draft-ietf-sfc-proof-of-transit
Thread-Index: AQHWQ+P59HQNTyavG0yPHGrQcpcDYajfcqyg
Date: Fri, 19 Jun 2020 06:35:32 +0000
Message-ID: <9345_1592548533_5EEC5CB5_9345_73_1_787AE7BB302AE849A7480A190F8B9330314E39A6@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
References: <159231433807.30534.15301055086560120997@ietfa.amsl.com> <024644e7-22e8-f266-4591-6789dc283713@joelhalpern.com>
In-Reply-To: <024644e7-22e8-f266-4591-6789dc283713@joelhalpern.com>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.114.13.245]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/sfc/KY1plLiCuDdSdVYmKi6aRhPZu5g>
Subject: Re: [sfc] IETF WG state changed for draft-ietf-sfc-proof-of-transit
X-BeenThere: sfc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Network Service Chaining <sfc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sfc>, <mailto:sfc-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sfc/>
List-Post: <mailto:sfc@ietf.org>
List-Help: <mailto:sfc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sfc>, <mailto:sfc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 19 Jun 2020 06:35:38 -0000
Hi Franck, all, I know that you are working on this since a while. Please find below some comments on the YANG part to hopefully save you some cycles during upcoming reviews: (1) Remove "?" from the explanation text in Section 5.2.1 (2) OLD: The meaning of the symbols in these diagrams is as follows: o Brackets "[" and "]" enclose list keys. o Abbreviations before data node names: "rw" means configuration (read-write), and "ro" means state data (read-only). o Symbols after data node names: "?" means an optional node, "!" means a presence container, and "*" denotes a list and leaf-list. o Parentheses enclose choice and case nodes, and case nodes are also marked with a colon (":"). o Ellipsis ("...") stands for contents of subtrees that are not shown. NEW: The meaning of the symbols in YANG tree diagrams is defined in [RFC8340]. (3) Remove <CODE BEGINS> and <CODE ENDS> from the tree diagram (4) Instead of: +--rw active-profile-index? profile-index-range You can define a status leaf under pot-profile-list to indicate the activation status. (5) Any reason why are you using version 1? If not, please update to "1.1" (6) As your groupings are called only once, and unless you want to define them as reusable by other modules, you may just define those as part of the main container. (7) IANA Section should be updated as follows: OLD: This document does not require any actions from IANA. NEW: IANA is requested to register the following URI in the "ns" subregistry within the "IETF XML Registry" [RFC3688]: URI: urn:ietf:params:xml:ns:yang:ietf-pot-profile Registrant Contact: The IESG. XML: N/A; the requested URI is an XML namespace. IANA is requested to register the following YANG module in the "YANG Module Names" subregistry [RFC7950] within the "YANG Parameters" registry. Name: ietf-pot-profile Maintained by IANA: N Namespace: urn:ietf:params:xml:ns:yang:ietf-pot-profile Prefix: ietf-pot-profile Reference: RFC XXXX (7) You should update the Security Section as per https://trac.ietf.org/trac/ops/wiki/yang-security-guideline. And a more general note: == Several deployments use Traffic Engineering, policy routing, Segment Routing (SR), and Service Function Chaining (SFC) [RFC7665] to steer packets through a specific set of nodes. In certain cases, regulatory obligations or a compliance policy require operators to ^^^^^^^^^^^^^^^^^^^^^^ prove that all packets that are supposed to follow a specific path are indeed being forwarded across and exact set of pre-determined nodes. == Do you have pointers to such regulatory obligations? It would be good to add a pointer if you are aware of any. Thanks. Hope this helps. Cheers, Med > -----Message d'origine----- > De : sfc [mailto:sfc-bounces@ietf.org] De la part de Joel M. Halpern > Envoyé : mardi 16 juin 2020 15:42 > À : sfc@ietf.org > Objet : Re: [sfc] IETF WG state changed for draft-ietf-sfc-proof-of-transit > > The chairs are starting the WG last call for > draft-ietf-sfc-proof-of-transit. Please reply explicitly whether you > think this is ready to go to the IETF for publication as a Experimental > RFC. > As noted below, the call runs through June 30. > > Note that silence does not imply consent, so please speak up. > > Yours, > Joel (& Jim) > > On 6/16/2020 9:32 AM, IETF Secretariat wrote: > > > > The IETF WG state of draft-ietf-sfc-proof-of-transit has been changed to > "In > > WG Last Call" from "WG Document" by Joel Halpern: > > > > https://datatracker.ietf.org/doc/draft-ietf-sfc-proof-of-transit/ > > > > Comment: > > This starts WG last call for this document, ending June 30. > > > > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc _________________________________________________________________________________________________________________________ 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.
- Re: [sfc] IETF WG state changed for draft-ietf-sf… Joel M. Halpern
- Re: [sfc] IETF WG state changed for draft-ietf-sf… Carlos Pignataro (cpignata)
- Re: [sfc] IETF WG state changed for draft-ietf-sf… mohamed.boucadair
- Re: [sfc] IETF WG state changed for draft-ietf-sf… Frank Brockners (fbrockne)
- Re: [sfc] IETF WG state changed for draft-ietf-sf… mohamed.boucadair
- Re: [sfc] IETF WG state changed for draft-ietf-sf… Greg Mirsky
- Re: [sfc] IETF WG state changed for draft-ietf-sf… Shwetha Bhandari (shwethab)
- Re: [sfc] IETF WG state changed for draft-ietf-sf… Sashank Dara
- Re: [sfc] IETF WG state changed for draft-ietf-sf… Frank Brockners (fbrockne)
- Re: [sfc] IETF WG state changed for draft-ietf-sf… Vengada Prasad Govindan (venggovi)
- Re: [sfc] IETF WG state changed for draft-ietf-sf… Nagendra Kumar Nainar (naikumar)
- Re: [sfc] IETF WG state changed for draft-ietf-sf… mohamed.boucadair
- Re: [sfc] IETF WG state changed for draft-ietf-sf… Eric Voit (evoit)
- Re: [sfc] IETF WG state changed for draft-ietf-sf… Diego R. Lopez
- Re: [sfc] IETF WG state changed for draft-ietf-sf… Dhruv Dhody
- Re: [sfc] IETF WG state changed for draft-ietf-sf… Frank Brockners (fbrockne)
- Re: [sfc] IETF WG state changed for draft-ietf-sf… Vengada Prasad Govindan (venggovi)