Re: [sfc] IETF WG state changed for draft-ietf-sfc-proof-of-transit

mohamed.boucadair@orange.com Wed, 24 June 2020 16:18 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 83FB13A1001; Wed, 24 Jun 2020 09:18:58 -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 FoF6LV2suICq; Wed, 24 Jun 2020 09:18:56 -0700 (PDT)
Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.70.34]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 813B63A1002; Wed, 24 Jun 2020 09:18:55 -0700 (PDT)
Received: from opfednr05.francetelecom.fr (unknown [xx.xx.xx.69]) by opfednr24.francetelecom.fr (ESMTP service) with ESMTP id 49sSy56klGz1yCv; Wed, 24 Jun 2020 18:18:53 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1593015533; bh=x5ekDL2lO5KkK2WG2U7/wCEuILCwsQ8Uqf1C44GAxmM=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=P9xICr9ThqsVrd/RFUxAenhqDZwwlCWoYDbY0EYN6QKJT7HQqJkyL4XhuB8StKyeb SyEIPAosmX0t7W2B3c0rCH6nE3+VuDuyGWh6Wjo4p2yHCQZi61lJ2Yp3rOHjiZRfWg 3GQW4qMLno2XdihRMzYPzFXAWeB+rawMos9ZKulKQNb4os3XhIGpe7cP2VnCW6GllR HZrwiUxvTGOIACsl1cevS6M6q0mQn1CxA9vU4kJdSJucUyGOxAqzsnVBVtNeDrbNYo o4T6rsgRAG2v/F6C97JK3Fmj4xi18/gkIIXQTEq6vi8yha3V/B3aZsHYtJyTpEIZ2q 8gS1lcjYt25yA==
Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.70]) by opfednr05.francetelecom.fr (ESMTP service) with ESMTP id 49sSy55xZfzyPk; Wed, 24 Jun 2020 18:18:53 +0200 (CEST)
From: mohamed.boucadair@orange.com
To: "Frank Brockners (fbrockne)" <fbrockne@cisco.com>, "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>, "Srihari Raghavan (srihari)" <srihari@cisco.com>, "stephen.youell@jpmorgan.com" <stephen.youell@jpmorgan.com>
Thread-Topic: [sfc] IETF WG state changed for draft-ietf-sfc-proof-of-transit
Thread-Index: AQHWQ+KV17ns9PWWfk+W2kvQHKZt5qjbQB0AgAQ/xwCACHVj8IAACGcg
Date: Wed, 24 Jun 2020 16:18:53 +0000
Message-ID: <10976_1593015533_5EF37CED_10976_370_1_787AE7BB302AE849A7480A190F8B9330314E6854@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
References: <159231433807.30534.15301055086560120997@ietfa.amsl.com> <024644e7-22e8-f266-4591-6789dc283713@joelhalpern.com> <9345_1592548533_5EEC5CB5_9345_73_1_787AE7BB302AE849A7480A190F8B9330314E39A6@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <BYAPR11MB25842A7DDCA9BF5FCB5A28DBDA950@BYAPR11MB2584.namprd11.prod.outlook.com>
In-Reply-To: <BYAPR11MB25842A7DDCA9BF5FCB5A28DBDA950@BYAPR11MB2584.namprd11.prod.outlook.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.247]
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/yeYF_Je_7nTO8vNCw5VTbYVZ1Ao>
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: Wed, 24 Jun 2020 16:18:59 -0000

Hi Franck, 

Thanks for the follow-up.

Please see inline. 

Cheers,
Med

> -----Message d'origine-----
> De : Frank Brockners (fbrockne) [mailto:fbrockne@cisco.com]
> Envoyé : mercredi 24 juin 2020 18:12
> À : BOUCADAIR Mohamed TGI/OLN; draft-ietf-sfc-proof-of-transit@ietf.org
> Cc : Joel M. Halpern; sfc@ietf.org; Srihari Raghavan (srihari);
> stephen.youell@jpmorgan.com
> Objet : RE: [sfc] IETF WG state changed for draft-ietf-sfc-proof-of-transit
> 
> Hi Med,
> 
> Thanks a lot for your comments. Please see inline (...FB)
> 
> > -----Original Message-----
> > From: mohamed.boucadair@orange.com <mohamed.boucadair@orange.com>
> > Sent: Freitag, 19. Juni 2020 08:36
> > To: draft-ietf-sfc-proof-of-transit@ietf.org
> > Cc: Joel M. Halpern <jmh@joelhalpern.com>; sfc@ietf.org
> > Subject: RE: [sfc] IETF WG state changed for draft-ietf-sfc-proof-of-
> transit
> >
> > 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
> 
> ...FB: Will do.
> >
> > (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].
> 
> ...FB: Good point. We can indeed get rid of the legacy text and refer to
> RFC8340.
> >
> > (3) Remove <CODE BEGINS> and <CODE ENDS> from the tree diagram
> 
> ...FB: Will do.
> >
> > (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.
> 
> ...FB: Very doable - especially since the open source implementation in VPP
> also only uses and active and a standby profile.

[Med] Great. Thanks.

> >
> > (5) Any reason why are you using version 1? If not, please update to
> "1.1"
> 
> ...FB: Nothing specific. The model got defined (and implemented as part of
> OpenDaylight) back in 2016.
> 

[Med] Then, please update the module to use 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.
> 
> ...FB: We could consider doing so. The reason why we kept the model fairly
> stable so far was that there is an existing implementation in open source
> (Opendaylight), hence the preference to not change things unless there is a
> real need. Would you be ok to stay with the current structure?
> 

[Med] Fair enough. 

> >
> > (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.
> 
> ...FB: ACK on both points above.
> >
> > 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.
> 
> ...FB: One of the co-authors and initiators of POT, Stephen, might have
> more specific references available.
> From what I know, there are company policies that require path
> verification. In case we don't find a formal reference, we'll change the
> statement in the next revision and avoid mentioning "regulatory
> obligations".
> 

[Med] Looks like a good plan.

> 
> >
> > Hope this helps.
> 
> Very helpful indeed. Thanks again.
> 
> Cheers, Frank
> >
> > 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.