Subject: Re: [sfc] draft-ietf-sfc-proof-of-transit-04 ready for WGLC? (was RE: PoT review/comments)

From: "Shwetha Bhandari (shwethab)" <[email-masked]>
Date: Wed, 1 Apr 2020 17:14:40 +0000

+1 to the below suggestions from Frank and Carlos:

It does make sense to keep/update draft-ietf-sfc-proof-of-transit with:
- normative reference to draft-ietf-ippm-ioam-data
- Example encapsulation with an informative reference to draft-ietf-sfc-ioam-nsh

Thanks,
Shwetha
    
    > -----Original Message-----
    > From: sfc <[email-masked]> On Behalf Of Frank Brockners (fbrockne)
    > Sent: Wed, 25 March 2020 20:11 UTC
    > To: Carlos Pignataro (cpignata) <cpignata=[email-masked]>; Joel
    > M. Halpern <[email-masked]>
    > Cc: [email-masked]
    > Subject: Re: [sfc] draft-ietf-sfc-proof-of-transit-04 ready for WGLC? (was RE:
    > PoT review/comments)
    > 
    > Hi Joel,
    > 
    > I'd second Carlos suggestions and thoughts - but would also appreciate
    > additional thoughts from the WG on how to progress.
    > 
    > * draft-ietf-sfc-proof-of-transit :
    >    - adding a normative reference to draft-ietf-ippm-ioam-data is a no brainer
    > and an obvious edit
    >    - given that POT can be used with a variety of transports, we're best served if
    > we mention at least one example.
    >      draft-ietf-sfc-ioam-nsh is the obvious example, but others could apply as well.
    > As such, an informative reference might be the better choice IMHO.
    >      Much like Carlos, I'm happy to also use a normative reference if others feel
    > strongly about it.
    > 
    > * draft-ietf-sfc-ioam-nsh
    >    - we can add a short section mentioning that for use-cases that require
    > checking proof of transit in an NSH deployment, POT could be leveraged.
    >      In this context we can add an informative reference to draft-ietf-sfc-proof-
    > of-transit.
    > 
    > Thanks, Frank
    > 
    > > -----Original Message-----
    > > From: sfc <[email-masked]> On Behalf Of Carlos Pignataro
    > > (cpignata)
    > > Sent: Dienstag, 24. März 2020 22:38
    > > To: Joel M. Halpern <[email-masked]>
    > > Cc: [email-masked]
    > > Subject: Re: [sfc] draft-ietf-sfc-proof-of-transit-04 ready for WGLC? (was RE:
    > > PoT review/comments)
    > >
    > > Hi, Joel,
    > >
    > > > 2020/03/24 午後5:24、Joel M. Halpern <[email-masked]>のメール:
    > > >
    > > > I think we all agree that draft-ietf-sfc-proof-of-transit requires
    > > > the normative
    > > reference to draft-ietf-ippm-ioam-data.
    > >
    > > I agree. That seems clear, I was laying it out for completeness.
    > >
    > > >
    > > > Regarding a reference from draft-ietf-sfc-proof-of-transit to
    > > > draft-ietf-sfc-
    > > ioam-nsh, I think we agree that it is needed.  The question then is
    > > normative or informative.  If we use the usual IETF rule that there
    > > has to be a defined normative way to interoperably implement a
    > > protocol spec (with other options allowed), my inclination is that the reference
    > should be normative.
    > >
    > > Similarly, I think the document is improved if it is added.
    > >
    > > In regards to Normative or Informative, my initial thinking was the latter.
    > > However, I believe either option can be genuinely argued and I am OK
    > > either way.
    > >
    > > I thought of Informative because PoT can be understood without
    > > IOAM-over- NSH and, strictly, the technology of
    > > draft-ietf-sfc-ioam-nsh is not necessary to implement. We can easily have PoT
    > in IOAM over something-other-than-NSH.
    > > This seems to align with
    > > <https://www.ietf.org/about/groups/iesg/statements/normative-informati
    > > ve-
    > > references/>.
    > >
    > > That said, another equally plausible argument is to specify
    > > implementable technology all the way down the stack, and make
    > > proof-of-transit a stronger RFC. Although, that might imply a
    > > normative reference to the NSH RFC itself, etc.
    > >
    > > While I tend to slightly favor Informative, I see the other angle and
    > > I’m happy to support Normative if it is the WG’s preference.
    > >
    > > >
    > > > Regarding the informative reference in the other direction from
    > > > draft-ietf-sfc-
    > > ioam-nsh to draft-ietf-sfc-proof-of-transit, while I personally like
    > > the idea, that is up to you / the working group.
    > > >
    > >
    > > I like that idea as it provides a bit more context information. I
    > > believe we should add this other Informative one.
    > >
    > > Best,
    > >
    > > Carlos.
    > >
    > > > Yours,
    > > > Joel
    > > >
    > > > On 3/24/2020 5:20 PM, Carlos Pignataro (cpignata) wrote:
    > > >> Hi, Joel,
    > > >> The way in which the doc hierarchy and relationship is structure
    > > >> seems to
    > > support and potentially even require:
    > > >> From draft-ietf-sfc-proof-of-transit:
    > > >> * A normative reference to [I-D.ietf-ippm-ioam-data], since PoT
    > > >> gives over
    > > IOAM explicitly, and that exists.
    > > >> * Optionally, an Informative reference to draft-ietf-sfc-ioam-nsh,
    > > >> since that’s
    > > really one out of many ways to carry IOAM over NSH, but separated by
    > > document indirection. This does not exist but can be added.
    > > >> From draft-ietf-sfc-ioam-nsh:
    > > >> * Optionally, an Informative reference to
    > > >> draft-ietf-sfc-proof-of-transit, since
    > > that’s one out of many applications. This does not exist but can be added.
    > > >> Thoughts?
    > > >> Best,
    > > >> Carlos.
    > > >>> 2020/03/24 午後5:10、Joel M. Halpern <[email-masked]
    > > <mailto:[email-masked]>>のメール:
    > > >>>
    > > >>> Carlos, it sounds like there should probably be a normative
    > > >>> reference from
    > > draft-ietf-sfc-proof of transit to draft-ietf-sfc-ioam-nsh? Possibly
    > > in the same sentence that refers to draft-ietf-ippm-ioam-data?
    > > >>>
    > > >>> Yours,
    > > >>> Joel
    > > >>>
    > > >>> On 3/24/2020 4:54 PM, Carlos Pignataro (cpignata) wrote:
    > > >>>> Greg,
    > > >>>> The very first sentence of the PoT document reads:
    > > >>>>    Several technologies such as Traffic Engineering (TE), Service
    > > >>>>    Function Chaining (SFC), and policy based routing are used to steer
    > > >>>>    traffic through a specific, user-defined path.  This document
    > > >>>> defines Explaining how this document is applicable to various
    > > >>>> traffic-
    > > steering technologies.
    > > >>>> Section 3 then explains:
    > > >>>>    The POT information is encapsulated in packets as an IOAM Proof Of
    > > >>>>    Transit Option.  The details and format of the encapsulation and the
    > > >>>>    POT Option format are specified in [I-D.ietf-ippm-ioam-data].
    > > >>>> Which shows how to carry PoT in IOAM, with an appropriate pointer.
    > > >>>> Lastly, draft-ietf-sfc-ioam-nsh-03 defines IOAM over an NSH
    > > encapsulation.
    > > >>>> This arrangements maximizes specification modularity and
    > > portability/reusability.
    > > >>>> Best,
    > > >>>> Carlos.
    > > >>>>> 2020/03/24 午後4:48、Greg Mirsky <[email-masked]
    > > <mailto:[email-masked]> <mailto:[email-masked]>>のメー
    > ル:
    > > >>>>>
    > > >>>>> Hi Joel,
    > > >>>>> thank you for the most expedient response. As I understand it,
    > > >>>>> iOAM Data
    > > draft describes the format of the informational element that carries
    > > POT-related information but it does not define how the element to be
    > > carried in case of NSH encapsulation. And that is what I was asking,
    > > apologies for not being clear in my first note.
    > > >>>>>
    > > >>>>> Regards,
    > > >>>>> Greg
    > > >>>>>
    > > >>>>> On Tue, Mar 24, 2020 at 1:42 PM Joel M.. Halpern
    > > <[email-masked]<mailto:[email-masked]>
    > > <mailto:[email-masked]>> wrote:
    > > >>>>>
    > > >>>>>    Regarding the information carriage, the PoT document points to the
    > > >>>>>    IOAM
    > > >>>>>    document.
    > > >>>>> https://tools.ietf.org/html/draft-ietf-ippm-ioam-data-08#section-4.5
    > > >>>>>    gives the format (and ways to have other formats if needed.)
    > > >>>>>
    > > >>>>>    Yours,
    > > >>>>>    Joel
    > > >>>>>
    > > >>>>>    On 3/24/2020 4:26 PM, Greg Mirsky wrote:
    > > >>>>>    > Hi Frank,
    > > >>>>>    > thank you for reminding us about this important work, indeed we
    > > >>>>>    should
    > > >>>>>    > complete it. I've reviewed the draft and have several questions.
    > > >>>>>    Please
    > > >>>>>    > kindly consider:
    > > >>>>>    >
    > > >>>>>    >   * I couldn't find information where, relative to NSH, RND and
    > > >>>>>    CML are
    > > >>>>>    >     transported
    > > >>>>>    >   * for YANG data models using "reference" is strongly
    > > >>>>>    encouraged as it
    > > >>>>>    >     provides a pointer to the specification. Since the POT data
    > > >>>>>    model is
    > > >>>>>    >     in the same document as the POT specification, listing the
    > > >>>>>    >     appropriate section should suffice
    > > >>>>>    >
    > > >>>>>    > Regards,
    > > >>>>>    > Greg
    > > >>>>>    >
    > > >>>>>    > On Thu, Mar 19, 2020 at 6:45 AM Frank Brockners (fbrockne)
    > > >>>>>    > <fbrockne=[email-masked]
    > > <mailto:fbrockne=[email-masked]>
    > > >>>>>    <mailto:[email-masked]>
    > > >>>>>    > <mailto:[email-masked]
    > > >>>>>    <mailto:[email-masked]>>> wrote:
    > > >>>>>    >
    > > >>>>>    >     Dear SFC WG,____
    > > >>>>>    >
    > > >>>>>    >     __ __
    > > >>>>>    >
    > > >>>>>    >     It’s been a while since we posted
    > > >>>>>    draft-ietf-sfc-proof-of-transit-04
    > > >>>>>    >     which addressed all known comments – see below.
    > > >>>>>    >     I’ve not seen any more recent comments or questions come up
    > > >>>>>    – and
    > > >>>>>    >     we’ve been through quite a few discussions and reviews of this
    > > >>>>>    >     document already.____
    > > >>>>>    >
    > > >>>>>    >     __ __
    > > >>>>>    >
    > > >>>>>    >     Thus the question: Are we ready for WG LC?____
    > > >>>>>    >
    > > >>>>>    >     __ __
    > > >>>>>    >
    > > >>>>>    >     Thanks, Frank____
    > > >>>>>    >
    > > >>>>>    >     __ __
    > > >>>>>    >
    > > >>>>>    >     *From:* Frank Brockners (fbrockne)
    > > >>>>>    >     *Sent:* Donnerstag, 21. November 2019 08:21
    > > >>>>>    >     *To:* Alejandro Aguado FI <[email-masked]
    > > <mailto:[email-masked]>
    > > >>>>>    <mailto:[email-masked]>
    > > >>>>>    >     <mailto:[email-masked]
    > <mailto:[email-masked]>>>;
    > > >>>>>    Diego R. Lopez
    > > >>>>>    >     <[email-masked]
    > > <mailto:[email-masked]>
    > > >>>>>    <mailto:[email-masked]>
    > > >>>>>    >     <mailto:[email-masked]
    > > >>>>>    <mailto:[email-masked]>>>; Carlos Pignataro
    > (cpignata)
    > > >>>>>    >     <[email-masked] <mailto:[email-masked]>
    > > <mailto:[email-masked]>
    > > >>>>>    <mailto:[email-masked] <mailto:cpignata@cisco..com>>>;
    > > >>>>>    ALEJANDRO AGUADO
    > > >>>>>    >     MARTIN
    > >
    > <[email-masked]<mailto:alejandro.aguadomartin.
    > > [email-masked]>
    > > >>>>>    <mailto:[email-masked]>
    > > >>>>>    >     <mailto:[email-masked]
    > > >>>>>    <mailto:[email-masked]>>>; Shwetha
    > > >>>>>    >     Bhandari (shwethab) <[email-masked]
    > > <mailto:[email-masked]>
    > > >>>>>    <mailto:[email-masked]>
    > > >>>>>    >     <mailto:[email-masked] <mailto:[email-masked]>>>;
    > > >>>>>    Tal Mizrahi <[email-masked]
    > > <mailto:[email-masked]>
    > > >>>>>    <mailto:[email-masked]>
    > > >>>>>    >     <mailto:[email-masked]
    > > >>>>>    <mailto:[email-masked]>>>
    > > >>>>>    >     *Cc:* [email-masked] <mailto:[email-masked]> <mailto:[email-masked]>
    > > >>>>>    <mailto:[email-masked] <mailto:[email-masked]>>
    > > >>>>>    >     *Subject:* RE: PoT review/comments____
    > > >>>>>    >
    > > >>>>>    >     __ __
    > > >>>>>    >
    > > >>>>>    >     We’ve just posted revision -04 of
    > > >>>>>    draft-ietf-sfc-proof-of-transit
    > > >>>>>    >     which now includes support for OPOT configuration in the
    > > >>>>>    yang model;____
    > > >>>>>    >
    > > >>>>>    >     see section 5.2.3 in
    > > >>>>>    > https://www.ietf.org/id/draft-ietf-sfc-proof-of-transit-04.txt. ____
    > > >>>>>    >
    > > >>>>>    >     The main addition is a grouping opot-profile, which adds
    > > >>>>>    upstream
    > > >>>>>    >     and downstream masks that OPOT requires.____
    > > >>>>>    >
    > > >>>>>    >     Thanks to Alejandro for suggesting these updates.____
    > > >>>>>    >
    > > >>>>>    >     __ __
    > > >>>>>    >
    > > >>>>>    >     This fixes the last “known issue” in
    > > >>>>>    >     draft-ietf-sfc-proof-of-transit. It would be great if you
    > > >>>>>    could give
    > > >>>>>    >     the document another careful read through.
    > > >>>>>    >     Are we ready for WGLC?____
    > > >>>>>    >
    > > >>>>>    >     __ __
    > > >>>>>    >
    > > >>>>>    >     Thanks, Frank____
    > > >>>>>    >
    > > >>>>>    >     __ __
    > > >>>>>    >
    > > >>>>>    >     __ __
    > > >>>>>    >
    > > >>>>>    >     *From:* Alejandro Aguado FI <[email-masked]
    > > <mailto:[email-masked]>
    > > >>>>>    <mailto:[email-masked]>
    > > >>>>>    >     <mailto:[email-masked]
    > <mailto:[email-masked]>>>
    > > >>>>>    >     *Sent:* Donnerstag, 12. September 2019 15:40
    > > >>>>>    >     *To:* Diego R. Lopez
    > > <[email-masked]<mailto:[email-masked]>
    > > >>>>>    <mailto:[email-masked]>
    > > >>>>>    >     <mailto:[email-masked]
    > > >>>>>    <mailto:[email-masked]>>>; Carlos Pignataro
    > (cpignata)
    > > >>>>>    >     <[email-masked] <mailto:[email-masked]>
    > > <mailto:[email-masked]>
    > > >>>>>    <mailto:[email-masked] <mailto:cpignata@cisco..com>>>; Frank
    > > >>>>>    Brockners
    > > >>>>>    >     (fbrockne) <[email-masked] <mailto:[email-masked]>
    > > <mailto:[email-masked]>
    > > >>>>>    <mailto:[email-masked] <mailto:[email-masked]>>>;
    > > >>>>>    >     ALEJANDRO AGUADO MARTIN
    > > >>>>>
    > >
    > <[email-masked]<mailto:alejandro.aguadomartin.
    > > [email-masked]>
    > > >>>>>    <mailto:[email-masked]>
    > > >>>>>    >     <mailto:[email-masked]
    > > >>>>>    <mailto:[email-masked]>>>; Shwetha
    > > >>>>>    >     Bhandari (shwethab) <[email-masked]
    > > <mailto:[email-masked]>
    > > >>>>>    <mailto:[email-masked]>
    > > >>>>>    >     <mailto:[email-masked] <mailto:[email-masked]>>>;
    > > >>>>>    Tal Mizrahi <[email-masked]
    > > <mailto:[email-masked]>
    > > >>>>>    <mailto:[email-masked]>
    > > >>>>>    >     <mailto:[email-masked]
    > > >>>>>    <mailto:[email-masked]>>>
    > > >>>>>    >     *Cc:* [email-masked] <mailto:[email-masked]> <mailto:[email-masked]>
    > > >>>>>    <mailto:[email-masked] <mailto:[email-masked]>>
    > > >>>>>    >     *Subject:* Re: PoT review/comments____
    > > >>>>>    >
    > > >>>>>    >     __ __
    > > >>>>>    >
    > > >>>>>    >     Hi Shwetha,____
    > > >>>>>    >
    > > >>>>>    >     __ __
    > > >>>>>    >
    > > >>>>>    >     Yes, I think it is a good idea. From your points, the second
    > > >>>>>    one is
    > > >>>>>    >     a bit confusing to me... But I do not fully remember how the
    > > >>>>>    model
    > > >>>>>    >     was structured, so I need to revise the document.____
    > > >>>>>    >
    > > >>>>>    >     __ __
    > > >>>>>    >
    > > >>>>>    >     Give me a day or two to explore again the model, and either we
    > > >>>>>    >     exchange few emails with proposals for the extension, or we can
    > > >>>>>    >     organise a quick call during next week to close a final
    > > >>>>>    proposal to
    > > >>>>>    >     share with other contributors.____
    > > >>>>>    >
    > > >>>>>    >     __ __
    > > >>>>>    >
    > > >>>>>    >     Thanks!____
    > > >>>>>    >
    > > >>>>>    >     __ __
    > > >>>>>    >
    > > >>>>>    >     Best,____
    > > >>>>>    >
    > > >>>>>    >     Alejandro____
    > > >>>>>    >
    > > >>>>>    >     __ __
    > > >>>>>    >
    > > >>>>>    >     __ __
    > > >>>>>    >
    > > >>>>>    >     El 12 de septiembre de 2019 a las 8:52:44, Shwetha Bhandari
    > > >>>>>    >     (shwethab) ([email-masked]
    > <mailto:[email-masked]>
    > > <mailto:[email-masked]>
    > > >>>>>    <mailto:[email-masked] <mailto:[email-masked]>>)
    > > >>>>>    >     escribió:____
    > > >>>>>    >
    > > >>>>>    >     Hi Alejandro, Diego,____
    > > >>>>>    >
    > > >>>>>    >     ____
    > > >>>>>    >
    > > >>>>>    >     Since you added extension to do OPoT, should we extend the
    > > >>>>>    model in
    > > >>>>>    >     draft-ietf-sfc-proof-of-transit to enable OPoT and any
    > > >>>>>    parameters
    > > >>>>>    >     required for it  shared masks per link. If yes my proposal
    > > >>>>>    will be
    > > >>>>>    >     to:____
    > > >>>>>    >
    > > >>>>>    >      1. Augment existing pot-profile with fields to Enable OPoT
    > > >>>>>    and a
    > > >>>>>    >         cipher scheme if needed.____
    > > >>>>>    >      2. Separate container in the model to define a map of (Node
    > > >>>>>    >         link/interface, mask) to distribute pair wise masks. For
    > > >>>>>    e.g.
    > > >>>>>    >         Node link/interface identifier can be UUID as defined in
    > > >>>>>    rfc8348
    > > >>>>>    >         Or____
    > > >>>>>    >      3. Masks can be part of pot-profile.____
    > > >>>>>    >
    > > >>>>>    >     ____
    > > >>>>>    >
    > > >>>>>    >     What do you think about revising the model with this?____
    > > >>>>>    >
    > > >>>>>    >     ____
    > > >>>>>    >
    > > >>>>>    >     Thanks,____
    > > >>>>>    >
    > > >>>>>    >     Shwetha____
    > > >>>>>    >
    > > >>>>>    >     ____
    > > >>>>>    >
    > > >>>>>    >     *From: *"Frank Brockners (fbrockne)" <[email-masked]
    > > <mailto:[email-masked]>
    > > >>>>>    <mailto:[email-masked]>
    > > >>>>>    >     <mailto:[email-masked] <mailto:[email-masked]>>>
    > > >>>>>    >     *Date: *Wednesday, September 11, 2019 at 2:34 PM
    > > >>>>>    >     *To: *ALEJANDRO AGUADO MARTIN
    > > >>>>>    >
    > >
    > <[email-masked]<mailto:alejandro.aguadomartin.
    > > [email-masked]>
    > > >>>>>    <mailto:[email-masked]>
    > > >>>>>    >     <mailto:[email-masked]
    > > >>>>>    <mailto:[email-masked]>>>, "Diego R.
    > > >>>>>    >     Lopez" <[email-masked]
    > > <mailto:[email-masked]>
    > > >>>>>    <mailto:[email-masked]>
    > > >>>>>    >     <mailto:[email-masked]
    > > >>>>>    <mailto:[email-masked]>>>, Carlos Pignataro
    > > >>>>>    >     <cpignata@cisco..com <mailto:[email-masked]
    > > >>>>>    <mailto:[email-masked]>>>, Shwetha bhandari
    > > >>>>>    >     <[email-masked] <mailto:[email-masked]>
    > > <mailto:[email-masked]>
    > > >>>>>    <mailto:[email-masked] <mailto:shwethab@cisco..com>>>,
    > > >>>>> Tal
    > > Mizrahi
    > > >>>>>    >     <[email-masked]
    > <mailto:[email-masked]>
    > > >>>>>    <mailto:[email-masked]>
    > > >>>>>    <mailto:[email-masked]
    > > <mailto:[email-masked]>>>
    > > >>>>>    >     *Cc: *"[email-masked] <mailto:[email-masked]>
    > > <mailto:[email-masked]>
    > > >>>>>    <mailto:[email-masked] <mailto:[email-masked]>>"
    > > >>>>>    >     <[email-masked] <mailto:[email-masked]>
    > > <mailto:[email-masked]>
    > > >>>>>    <mailto:[email-masked] <mailto:[email-masked]>>>,
    > > >>>>>    "[email-masked] <mailto:[email-masked]> <mailto:[email-masked]>
    > > >>>>>    >     <mailto:[email-masked] <mailto:[email-masked]>>" <[email-masked]
    > > <mailto:[email-masked]>
    > > >>>>>    <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>>
    > > >>>>>    >     *Subject: *RE: PoT review/comments____
    > > >>>>>    >
    > > >>>>>    >     ____
    > > >>>>>    >
    > > >>>>>    >     Hi Alejandro,____
    > > >>>>>    >
    > > >>>>>    >     ____
    > > >>>>>    >
    > > >>>>>    >     Thanks again for the review. Your comments have been
    > > >>>>>    integrated into
    > > >>>>>    >     draft-ietf-sfc-proof-of-transit-03 which just got posted.____
    > > >>>>>    >
    > > >>>>>    >     ____
    > > >>>>>    >
    > > >>>>>    >     Cheers, Frank____
    > > >>>>>    >
    > > >>>>>    >     ____
    > > >>>>>    >
    > > >>>>>    >     *From:*Frank Brockners (fbrockne)
    > > >>>>>    >     *Sent:* Montag, 27. Mai 2019 18:18
    > > >>>>>    >     *To:* ALEJANDRO AGUADO MARTIN
    > > >>>>>    >
    > >
    > <[email-masked]<mailto:alejandro.aguadomartin.
    > > [email-masked]>
    > > >>>>>    <mailto:[email-masked]>
    > > >>>>>    >     <mailto:[email-masked]
    > > >>>>>    <mailto:[email-masked]>>>; Diego R.
    > > Lopez
    > > >>>>>    >     <[email-masked]
    > > <mailto:[email-masked]>
    > > >>>>>    <mailto:[email-masked]>
    > > >>>>>    >     <mailto:[email-masked]
    > > >>>>>    <mailto:[email-masked]>>>; Carlos Pignataro
    > (cpignata)
    > > >>>>>    >     <[email-masked] <mailto:[email-masked]>
    > > <mailto:[email-masked]>
    > > >>>>>    <mailto:[email-masked] <mailto:cpignata@cisco..com>>>;
    > > Shwetha
    > > >>>>>    Bhandari
    > > >>>>>    >     (shwethab) <[email-masked]
    > <mailto:[email-masked]>
    > > <mailto:[email-masked]>
    > > >>>>>    <mailto:[email-masked] <mailto:[email-masked]>>>; Tal
    > > >>>>>    >     Mizrahi <[email-masked]
    > > <mailto:[email-masked]>
    > > >>>>>    <mailto:tal.mizrahi.phd@gmail..com>
    > > >>>>>    <mailto:[email-masked]
    > > <mailto:[email-masked]>>>
    > > >>>>>    >     *Cc:* [email-masked] <mailto:[email-masked]>
    > > <mailto:[email-masked]>
    > > >>>>>    <mailto:[email-masked] <mailto:[email-masked]>>;
    > > >>>>> [email-masked] <mailto:[email-masked]> <mailto:[email-masked]>
    > > >>>>>    >     <mailto:[email-masked] <mailto:[email-masked]>>
    > > >>>>>    >     *Subject:* RE: PoT review/comments____
    > > >>>>>    >
    > > >>>>>    >     ____
    > > >>>>>    >
    > > >>>>>    >     Hi Alejandro,____
    > > >>>>>    >
    > > >>>>>    >     ____
    > > >>>>>    >
    > > >>>>>    >     Many thanks for the comments – and sorry for the delay –
    > > >>>>>    >     unfortunately your email somehow got dropped from my todo
    > list.
    > > >>>>>    >     Please see inline…____
    > > >>>>>    >
    > > >>>>>    >     ____
    > > >>>>>    >
    > > >>>>>    >     (cc’ing the list as well).____
    > > >>>>>    >
    > > >>>>>    >     ____
    > > >>>>>    >
    > > >>>>>    >     *From:*ALEJANDRO AGUADO MARTIN
    > > >>>>>    >
    > > <[email-masked]<mailto:alejandro.aguadomar
    > > tin
    > > [email-masked]>
    > > >>>>>    <mailto:[email-masked]>
    > > >>>>>    >     <mailto:[email-masked]
    > > >>>>>    <mailto:[email-masked]>>>
    > > >>>>>    >     *Sent:* Montag, 15. April 2019 17:27
    > > >>>>>    >     *To:* Diego R. Lopez
    > > <[email-masked]<mailto:[email-masked]>
    > > >>>>>    <mailto:[email-masked]>
    > > >>>>>    >     <mailto:[email-masked]
    > > >>>>>    <mailto:[email-masked]>>>; Carlos Pignataro
    > (cpignata)
    > > >>>>>    >     <[email-masked] <mailto:[email-masked]>
    > > <mailto:[email-masked]>
    > > >>>>>    <mailto:[email-masked] <mailto:cpignata@cisco..com>>>; Frank
    > > >>>>>    Brockners
    > > >>>>>    >     (fbrockne) <[email-masked] <mailto:[email-masked]>
    > > <mailto:[email-masked]>
    > > >>>>>    <mailto:[email-masked] <mailto:[email-masked]>>>;
    > > Shwetha
    > > >>>>>    >     Bhandari (shwethab) <[email-masked]
    > > <mailto:[email-masked]>
    > > >>>>>    <mailto:[email-masked]>
    > > >>>>>    >     <mailto:[email-masked] <mailto:[email-masked]>>>;
    > > >>>>>    Tal Mizrahi <[email-masked]
    > > <mailto:[email-masked]>
    > > >>>>>    <mailto:[email-masked]>
    > > >>>>>    >     <mailto:[email-masked]
    > > >>>>>    <mailto:[email-masked]>>>
    > > >>>>>    >     *Cc:* [email-masked] <mailto:[email-masked]>
    > > <mailto:[email-masked]>
    > > >>>>>    <mailto:[email-masked] <mailto:[email-masked]>>
    > > >>>>>    >     *Subject:* PoT review/comments____
    > > >>>>>    >
    > > >>>>>    >     ____
    > > >>>>>    >
    > > >>>>>    >     Dear all,____
    > > >>>>>    >
    > > >>>>>    >     ____
    > > >>>>>    >
    > > >>>>>    >     I gave a quick review to the PoT document. Some comments:____
    > > >>>>>    >
    > > >>>>>    >     ____
    > > >>>>>    >
    > > >>>>>    >     - I read “The non-constant coefficients are used to generate the
    > > >>>>>    >     Lagrange Polynomial Constants (LPC).” As far as I
    > > >>>>>    understood, the
    > > >>>>>    >     points assigned to each node (Xi) are the ones used for
    > > >>>>>    generating
    > > >>>>>    >     the LPCi, aren’t they?____
    > > >>>>>    >
    > > >>>>>    >     */…FB: Good catch. The LPCs are of course computed using (x_i,
    > > >>>>>    >     y_i)./*____
    > > >>>>>    >
    > > >>>>>    >     - If we go for including the YANG in the current document
    > > >>>>>    (which I
    > > >>>>>    >     agree), parameters should be described before the yang
    > > >>>>>    definition,
    > > >>>>>    >     and maybe it would be helpful to have the yang tree (see the
    > > >>>>>    current
    > > >>>>>    >     version attached).____
    > > >>>>>    >
    > > >>>>>    >     */…FB: Thanks. IMHO it makes sense to keep the YANG model in
    > the
    > > >>>>>    >     current doc, given that the model and the description go hand in
    > > >>>>>    >     hand. We can of course also include the yang tree to make
    > > >>>>>    reading
    > > >>>>>    >     easier. This is consistent with other documents which
    > > >>>>>    specify YANG
    > > >>>>>    >     models./*____
    > > >>>>>    >
    > > >>>>>    >     - I include in the attached file few questions about naming
    > > >>>>>    of some
    > > >>>>>    >     parameters.____
    > > >>>>>    >
    > > >>>>>    >     *//*____
    > > >>>>>    >
    > > >>>>>    >     */…FB:
    > > >>>>>    >     - naming F_i(x_i, y_i) – I agree that a better name could be
    > > >>>>>    used.
    > > >>>>>    >     The only potential concern would be that the open source
    > > >>>>>    >     implementation in OpenDaylight uses this naming – changing
    > > >>>>>    it might
    > > >>>>>    >     lead to confusion.. We can start with adding a comment to make
    > > >>>>>    >     things clearer./*____
    > > >>>>>    >
    > > >>>>>    >     *//*____
    > > >>>>>    >
    > > >>>>>    >     */- secret key – this is the constant part of the first
    > > >>>>>    polynomial
    > > >>>>>    >     which serves as the secret – and which is re-retrieved.
    > > >>>>>    Again, we
    > > >>>>>    >     can update the description to make things clearer./*____
    > > >>>>>    >
    > > >>>>>    >     *//*____
    > > >>>>>    >
    > > >>>>>    >     */- size of the random number: This is unrelated to OPOT.
    > > >>>>>    The random
    > > >>>>>    >     number is to uniquely identify a packet. There is a trade-off
    > > >>>>>    >     between the size of the random number and how often you need
    > to
    > > >>>>>    >     re-key your system. At high speeds, the random number – which
    > > >>>>>    >     identifies a particular packet – is used up quite quickly if
    > > >>>>>    it is
    > > >>>>>    >     only 32-bit wide. See section 4
    > > >>>>>    >        /*https://tools.ietf.org/html/draft-ietf-sfc-proof-of-transit-
    > > 02#section-4____
    > > >>>>>    >
    > > >>>>>    >     *//*____
    > > >>>>>    >
    > > >>>>>    >     */- number of profiles: For a deployment which is expected
    > > >>>>>    to renew
    > > >>>>>    >     keys every now and then (e.g. you run with 32-bit random
    > > >>>>>    numbers at
    > > >>>>>    >     reasonably high speeds), you need at least 2 profiles – an
    > > >>>>>    active
    > > >>>>>    >     one and one that you can activate once you run out of random
    > > >>>>>    numbers
    > > >>>>>    >     (which is what the encapsulating node would decide).. /*____
    > > >>>>>    >
    > > >>>>>    >     - I have checked some of the existing YANG files within the
    > > >>>>>    IETF to
    > > >>>>>    >     see in which it would be helpful to include. From the (not
    > > >>>>>    so) old
    > > >>>>>    >     OpenFlow, I assume that one match is necessary (for identify the
    > > >>>>>    >     iOAM/PoT header) whilst the source node can use any existing
    > > >>>>>    match
    > > >>>>>    >     field to identify packets where to apply the PoT scheme. In
    > > >>>>>    terms of
    > > >>>>>    >     actions, I would say that two may be required: for any node, an
    > > >>>>>    >     update-pot is necessary, while the verifier would need a
    > > >>>>>    verify-pot
    > > >>>>>    >     type of action, that would ideally either remove the header
    > > >>>>>    or drop
    > > >>>>>    >     the packet if fails (I do not know if you are thinking in more
    > > >>>>>    >     complex scenarios).____
    > > >>>>>    >
    > > >>>>>    >     *//*____
    > > >>>>>    >
    > > >>>>>    >     */…FB: From an OF perspective, that sounds feasible.. That
    > > >>>>>    said, we
    > > >>>>>    >     probably want to avoid making the spec specific to a
    > > >>>>>    technology like
    > > >>>>>    >     OF, hence would suggest that we don’t specify such a behavior as
    > > >>>>>    >     part of this document./*____
    > > >>>>>    >
    > > >>>>>    >     *//*____
    > > >>>>>    >
    > > >>>>>    >     - For this last point, I have seen the definitions within
    > > >>>>>    >     draft-asechoud-rtgwg-qos-model-08, where matched could map
    > > >>>>>    (if I am
    > > >>>>>    >     not wrong) to classifiers/filters, and actions to actions. I
    > > >>>>>    send
    > > >>>>>    >     you the models in a zip file. In this sense the model to be
    > > >>>>>    defined
    > > >>>>>    >     in the PoT shall be an augment of the models defined in that
    > > >>>>>    >     document. I have not done a very deep revision on the model,
    > > >>>>>    but I
    > > >>>>>    >     think it could fit there. If you have check this or other
    > > >>>>>    models,
    > > >>>>>    >     let me know so I could also help.____
    > > >>>>>    >
    > > >>>>>    >     *//*____
    > > >>>>>    >
    > > >>>>>    >     */…FB: Per my note above: In order to keep POT generic and
    > > >>>>>    not link
    > > >>>>>    >     it to a particular classification mechanism, I’d prefer to
    > > >>>>>    keep the
    > > >>>>>    >     classification question as out of scope for the current
    > > >>>>>    document.
    > > >>>>>    >     That way it can also apply to technologies which come with
    > > >>>>>    their own
    > > >>>>>    >     way to classify – and which might fully decouple the tunneling
    > > >>>>>    >     aspects from the classification aspects. /*____
    > > >>>>>    >
    > > >>>>>    >     ____
    > > >>>>>    >
    > > >>>>>    >     Thanks a lot and sorry for such long email.____
    > > >>>>>    >
    > > >>>>>    >     ____
    > > >>>>>    >
    > > >>>>>    >     */..FB: Thanks again for all your comments. We’ll get them
    > > >>>>>    included
    > > >>>>>    >     in the next revision. /*____
    > > >>>>>    >
    > > >>>>>    >     *//*____
    > > >>>>>    >
    > > >>>>>    >     */Cheers, Frank/*____
    > > >>>>>    >
    > > >>>>>    >     ____
    > > >>>>>    >
    > > >>>>>    >     ____
    > > >>>>>    >
    > > >>>>>    >     ____
    > > >>>>>    >
    > > >>>>>    >     Best,____
    > > >>>>>    >
    > > >>>>>    >     Alejandro____
    > > >>>>>    >
    > > >>>>>    >     ____
    > > >>>>>    >
    > > >>>>>    >     ____
    > > >>>>>    >
    > > >>>>>    >     ____
    > > >>>>>    >
    > > >>>>>    >     ____
    > > >>>>>    >
    > > >>>>>    >        ------------------------------------------------------------------------
    > > >>>>>    >
    > > >>>>>    >
    > > >>>>>    >     Este mensaje y sus adjuntos se dirigen exclusivamente a su
    > > >>>>>    >     destinatario, puede contener información privilegiada o
    > > >>>>>    confidencial
    > > >>>>>    >     y es para uso exclusivo de la persona o entidad de destino.
    > > >>>>>    Si no es
    > > >>>>>    >     usted. el destinatario indicado, queda notificado de que la
    > > >>>>>    lectura,
    > > >>>>>    >     utilización, divulgación y/o copia sin autorización puede estar
    > > >>>>>    >     prohibida en virtud de la legislación vigente. Si ha
    > > >>>>>    recibido este
    > > >>>>>    >     mensaje por error, le rogamos que nos lo comunique
    > > >>>>>    inmediatamente
    > > >>>>>    >     por esta misma vía y proceda a su destrucción.
    > > >>>>>    >
    > > >>>>>    >     The information contained in this transmission is privileged and
    > > >>>>>    >     confidential information intended only for the use of the
    > > >>>>>    individual
    > > >>>>>    >     or entity named above. If the reader of this message is not the
    > > >>>>>    >     intended recipient, you are hereby notified that any
    > > >>>>>    dissemination,
    > > >>>>>    >     distribution or copying of this communication is strictly
    > > >>>>>    >     prohibited. If you have received this transmission in error,
    > > >>>>>    do not
    > > >>>>>    >     read it. Please immediately reply to the sender that you have
    > > >>>>>    >     received this communication in error and then delete it.
    > > >>>>>    >
    > > >>>>>    >     Esta mensagem e seus anexos se dirigem exclusivamente ao seu
    > > >>>>>    >     destinatário, pode conter informação privilegiada ou
    > > >>>>>    confidencial e
    > > >>>>>    >     é para uso exclusivo da pessoa ou entidade de destino. Se não é
    > > >>>>>    >     vossa senhoria o destinatário indicado, fica notificado de que a
    > > >>>>>    >     leitura, utilização, divulgação e/ou cópia sem autorização pode
    > > >>>>>    >     estar proibida em virtude da legislação vigente. Se recebeu esta
    > > >>>>>    >     mensagem por erro, rogamos-lhe que nos o comunique
    > > >>>>>    imediatamente por
    > > >>>>>    >     esta mesma via e proceda a sua destruição____
    > > >>>>>    >
    > > >>>>>    >     _______________________________________________
    > > >>>>>    >     sfc mailing list
    > > >>>>>    > [email-masked] <mailto:[email-masked]> <mailto:[email-masked]>
    > > <mailto:[email-masked]
    > > >>>>>    <mailto:[email-masked]>>
    > > >>>>>    > https://www.ietf.org/mailman/listinfo/sfc
    > > >>>>>    >
    > > >>>>>    >
    > > >>>>>    > _______________________________________________
    > > >>>>>    > sfc mailing list
    > > >>>>>    > [email-masked] <mailto:[email-masked]> <mailto:[email-masked]>
    > > >>>>>    > https://www.ietf.org/mailman/listinfo/sfc
    > > >>>>>    >
    > > >>>>>
    > > >>>>> _______________________________________________
    > > >>>>> sfc mailing list
    > > >>>>> [email-masked] <mailto:[email-masked]> <mailto:[email-masked]>
    > > >>>>> https://www.ietf.org/mailman/listinfo/sfc
    > >
    > > _______________________________________________
    > > sfc mailing list
    > > [email-masked]
    > > https://www.ietf.org/mailman/listinfo/sfc
    > _______________________________________________
    > sfc mailing list
    > [email-masked]
    > https://www.ietf.org/mailman/listinfo/sfc

---

From: Greg Mirsky <[email-masked]>
Date: Wed, 1 Apr 2020 11:59:58 -0700

Dear All,
I agree with Joel that the reference in draft-ietf-sfc-proof-of-transit to
draft-ietf-ippm-ioam-data should be normative. I also support the proposal
to add in draft-ietf-sfc-proof-of-transit a normative reference to
draft-ietf-sfc-ioam-nsh. SFC WG is working on defining SFC that is based on
NSH (SFC NSH), and while SFC might be realized using other techniques,
draft-ietf-sfc-ioam-nsh is, and likely will remain, the only document that
is describing iOAM encapsulation in SFC NSH. Thus, I believe, for SFC WG,
implementation of PoT based on iOAM requires implementation of iOAM
encapsulation in SFC NSH, as defined in draft-ietf-sfc-ioam-nsh. Hence, the
reference must be normative.

Regards,
Greg

On Tue, Mar 24, 2020 at 2:25 PM Joel M. Halpern <[email-masked]> wrote:

> I think we all agree that draft-ietf-sfc-proof-of-transit requires the
> normative reference to draft-ietf-ippm-ioam-data.
>
> draft-ietf-sfc-ioam-nsh, I think we agree that it is needed.  The
> question then is normative or informative.  If we use the usual IETF
> rule that there has to be a defined normative way to interoperably
> implement a protocol spec (with other options allowed), my inclination
> is that the reference should be normative.
>
> draft-ietf-sfc-ioam-nsh to draft-ietf-sfc-proof-of-transit, while I
> personally like the idea, that is up to you / the working group.
>
> Yours,
> Joel
>
> > The way in which the doc hierarchy and relationship is structure seems
> > to support and potentially even require:
> >
> > * A normative reference to [I-D.ietf-ippm-ioam-data], since PoT gives
> > over IOAM explicitly, and that exists.
> > * Optionally, an Informative reference to draft-ietf-sfc-ioam-nsh, since
> > that’s really one out of many ways to carry IOAM over NSH, but separated
> > by document indirection. This does not exist but can be added.
> >
> > draft-ietf-sfc-proof-of-transit, since that’s one out of many
> > applications. This does not exist but can be added.
> >
> > Thoughts?
> >
> > Best,
> >
> > Carlos.
> >
> >> Carlos, it sounds like there should probably be a normative reference
> >> from draft-ietf-sfc-proof of transit to draft-ietf-sfc-ioam-nsh?
> >> Possibly in the same sentence that refers to draft-ietf-ippm-ioam-data?
> >>
> >> Yours,
> >> Joel
> >>
> defines
> >>> Explaining how this document is applicable to various
> >>> traffic-steering technologies.
> >>> Section 3 then explains:
> >>>> <mailto:[email-masked]> <mailto:[email-masked]>>のメール:
> >>>>
> >>>> Hi Joel,
> >>>> thank you for the most expedient response. As I understand it, iOAM
> >>>> Data draft describes the format of the informational element that
> >>>> carries POT-related information but it does not define how the
> >>>> element to be carried in case of NSH encapsulation. And that is what
> >>>> I was asking, apologies for not being clear in my first note.
> >>>>
> >>>> Regards,
> >>>> Greg
> >>>>
> >>>> <[email-masked] <mailto:[email-masked]>
> >>>>    >     <mailto:[email-masked] <mailto:[email-masked]>>>;
> >>>>    Diego R. Lopez
> >>>>    >     MARTIN <[email-masked]
> >>>>    >     <mailto:[email-masked] <mailto:[email-masked]>>>
> >>>>    >     *To:* Diego R. Lopez <[email-masked]
> >>>>    <[email-masked]
> >>>>    >     (shwethab) ([email-masked] <mailto:[email-masked]>
> >>>>    >     <[email-masked]
> >>>>    <mailto:[email-masked] <mailto:shwethab@cisco..com>>>, Tal
> >>>> Mizrahi
> >>>>    >     <[email-masked] <mailto:[email-masked]
> >
> >>>>    >     <[email-masked]
> >>>>    <mailto:[email-masked] <mailto:cpignata@cisco..com>>>; Shwetha
> >>>>    Bhandari
> >>>>    >     (shwethab) <[email-masked] <mailto:[email-masked]>
> >>>>    >     <[email-masked]
> >>>>    >     *To:* Diego R. Lopez <[email-masked]
> >>>>    <mailto:[email-masked] <mailto:[email-masked]>>>; Shwetha
> >>>>    >     */…FB: Thanks. IMHO it makes sense to keep the YANG model
> >>>> in the
> >>>>        /*
> https://tools.ietf.org/html/draft-ietf-sfc-proof-of-transit-02#section-4____
> >>>>    >
> >>>>    >     *//*____
> >>>>    >

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Wed, 1 Apr 2020 19:16:48 +0000

Dear Greg,

> 2020/04/01 午後2:59、Greg Mirsky <[email-masked]>のメール:
> 
> Dear All,
> I agree with Joel that the reference in draft-ietf-sfc-proof-of-transit to draft-ietf-ippm-ioam-data should be normative.

Great. Everyone seems to be aligned on this point.

> I also support the proposal to add in draft-ietf-sfc-proof-of-transit a normative reference to draft-ietf-sfc-ioam-nsh. SFC WG is working on defining SFC that is based on NSH (SFC NSH), and while SFC might be realized using other techniques, draft-ietf-sfc-ioam-nsh is, and likely will remain, the only document that is describing iOAM encapsulation in SFC NSH. Thus, I believe, for SFC WG, implementation of PoT based on iOAM requires implementation of iOAM encapsulation in SFC NSH, as defined in draft-ietf-sfc-ioam-nsh. Hence, the reference must be normative.

This logic is flawed in the onset. The main point is that POT can be realized with a variety of transports and technologies and use-cases, one of which is SFC, and then further within SFC one of which is NSH. 

You seem to argue that NSH is somehow in practice the only SFC realization, and because of that the reference “must be normative”.

I disagree with the premise, but regardless, it does not matter since POT applies to other non-SFC(-non-NSH) technologies. Therefore that since-then logic does not apply.

Copying the very first sentence of the Abstract:

   Several technologies such as Traffic Engineering (TE), Service
   Function Chaining (SFC), and policy based routing [...]

And now looking at this fragment, I am more convinced that this is one example and as such Informative. 

I would not object to Normative for the right reasons, but the reason above, in my mind, does not follow.

Thanks,

Carlos.

> >>>    traffic through a specific, user-defined path.  This document defines
> >>>>    <mailto:[email-masked]>>>; Carlos Pignataro (cpignata)
> >>>>    <mailto:[email-masked]>>>; Carlos Pignataro (cpignata)
> >>>>    >     <[email-masked] <mailto:[email-masked]>
> >>>>    <mailto:[email-masked]>>>; Diego R. Lopez
> >>>>    <mailto:[email-masked]>>>; Carlos Pignataro (cpignata)
> >>>>    >     unfortunately your email somehow got dropped from my todo list.
> >>>>    >     Please see inline…____
> >>>>    >
> >>>>    >     ____
> >>>>    >
> >>>>    <mailto:[email-masked]>>>; Carlos Pignataro (cpignata)
> >>>>    >     between the size of the random number and how often you need to
> >>>>        /*https://tools.ietf.org/html/draft-ietf-sfc-proof-of-transit-02#section-4____
> >>>>    >
> >>>>    >     *//*____
> >>>>    >

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 1 Apr 2020 15:30:29 -0400

To be clear up front, I can live with an informative reference from 
sfc-proof-of-transit to sfc-ioam-nsh.

However, it seems to me that as a Proposed Standard, we are expected to 
define an interoperable and implementable protocol.  Without a normative 
reference to some encoding (and sfc-ioam-nsh does seem the obvious one 
to reference) we do not seem to have a full PS.  That is not to say that 
there can not be other encodings.  But NSH is the SFC agreed header 
format.  So for an SFC document, this seems natural as the MTI.

Yours,
Joel

---

From: Greg Mirsky <[email-masked]>
Date: Wed, 1 Apr 2020 12:36:31 -0700

Dear Carlos,
in my previous note I have recognized that POT, as SFC, can be realized
using different techniques. But this is SFC WG document and, as I
understand the charter of SFC WG, we're defining technologies that use SFC
NSH. Hence my conclusion that the reference to draft-ietf-sfc-ioam-nsh
should be normative, as that is the only document that defines iOAM
encapsulation in NSH. Making the reference informational could be
interpreted as suggestion that POT in SFC NSH might be encapsulated not as
iOAM but in some other manner. And while that is possible, I don't see a
proposal that describes such alternative encapsulation. So, it appears that
the WG has agreed that POT in SFC NSH should use encapsulation as defined
in draft-ietf-sfc-ioam-nsh.

Regards,
Greg

On Wed, Apr 1, 2020 at 12:16 PM Carlos Pignataro (cpignata) <
[email-masked]> wrote:

> > I agree with Joel that the reference in draft-ietf-sfc-proof-of-transit
> to draft-ietf-ippm-ioam-data should be normative.
>
> > I also support the proposal to add in draft-ietf-sfc-proof-of-transit a
> normative reference to draft-ietf-sfc-ioam-nsh. SFC WG is working on
> defining SFC that is based on NSH (SFC NSH), and while SFC might be
> realized using other techniques, draft-ietf-sfc-ioam-nsh is, and likely
> will remain, the only document that is describing iOAM encapsulation in SFC
> NSH. Thus, I believe, for SFC WG, implementation of PoT based on iOAM
> requires implementation of iOAM encapsulation in SFC NSH, as defined in
> draft-ietf-sfc-ioam-nsh. Hence, the reference must be normative.
>
>
> This logic is flawed in the onset. The main point is that POT can be
> realized with a variety of transports and technologies and use-cases, one
> of which is SFC, and then further within SFC one of which is NSH.
>
> You seem to argue that NSH is somehow in practice the only SFC
> realization, and because of that the reference “must be normative”.
>
> I disagree with the premise, but regardless, it does not matter since POT
> applies to other non-SFC(-non-NSH) technologies. Therefore that since-then
> logic does not apply.
>
> since
> > >>>>    >     <mailto:[email-masked] <mailto:[email-masked]
> >>>;
> > >>>>    Diego R. Lopez
> > >>>>    > https://www.ietf.org/id/draft-ietf-sfc-proof-of-transit-04.txt.
>
> > >>>> ____
> > >>>>    >
> > >>>>    <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]
> >>>
> > >>>>    >     estar proibida em virtude da legislação vigente. Se
> recebeu
> > >>>> esta

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Wed, 1 Apr 2020 22:50:31 +0000

Same here, Joel, I am happy with either normative or informative.

However, mostly for my understanding and beyond this specific draft:
The MTI concept seems does not seem to be yes/no binary. I’ve never fully understood MTI as a requirement beyond security features and professional judgement. For example, RFC 8200 does not say how to carry IPv6 over any layer-2 — not ethernet, not PPP. RFC 8300 does not explain how to carry (i.e., transportation encapsulation) NSH over anything. 

MTI makes sense to me within a given layer — but it is less clear to me how far down the layers MTI really applies. For a spec defining how to encapsulate something, sure. For a spec defiling information elements at a given Layer that need to interoperate within themselves regardless the encap, less clear to me.

Also, MTI seems to be better define within security features, less so as a general criteria for spec completeness. 

Do you have any pointers or normative definitions?

Thanks,

Carlos.

> 2020/04/01 午後3:30、Joel M. Halpern <[email-masked]>のメール:
> 
> To be clear up front, I can live with an informative reference from sfc-proof-of-transit to sfc-ioam-nsh.
> 
> However, it seems to me that as a Proposed Standard, we are expected to define an interoperable and implementable protocol.  Without a normative reference to some encoding (and sfc-ioam-nsh does seem the obvious one to reference) we do not seem to have a full PS.  That is not to say that there can not be other encodings.  But NSH is the SFC agreed header format.  So for an SFC document, this seems natural as the MTI.
> 
> Yours,
> Joel
>

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Wed, 1 Apr 2020 23:13:28 +0000

Dear Greg,

This seems to be a rephrase of the previous email, yet I still do not follow the cause-effect in your argument.

Normative does not mean “a reference that defines technology within the same Working Group’s documents that can be used”.

The definition and clarification statement at [1] says “documents that must be read to understand or implement the technology in the new RFC”. It does not speak to WG charters or.

Is the technology in draft-ietf-sfc-ioam-nsh a “must” for draft-ietf-sfc-proof-of-transit? It seems to me that the only “must” technology is ippm-ioam-data. I appreciate that this is also not necessarily a yes/no binary answer...

[Again, I am OK either way, for the right reason]

Carlos.

[1] https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/

> 2020/04/01 午後3:36、Greg Mirsky <[email-masked]>のメール:
> 
> Dear Carlos,
> in my previous note I have recognized that POT, as SFC, can be realized using different techniques. But this is SFC WG document and, as I understand the charter of SFC WG, we're defining technologies that use SFC NSH. Hence my conclusion that the reference to draft-ietf-sfc-ioam-nsh should be normative, as that is the only document that defines iOAM encapsulation in NSH. Making the reference informational could be interpreted as suggestion that POT in SFC NSH might be encapsulated not as iOAM but in some other manner. And while that is possible, I don't see a proposal that describes such alternative encapsulation. So, it appears that the WG has agreed that POT in SFC NSH should use encapsulation as defined in draft-ietf-sfc-ioam-nsh. 
> 
> Regards,
> Greg
> 
> On Wed, Apr 1, 2020 at 12:16 PM Carlos Pignataro (cpignata) <[email-masked]> wrote:
> Dear Greg,
>

---

From: Joel Halpern Direct <[email-masked]>
Date: Wed, 1 Apr 2020 19:16:07 -0400

Fair question.  No, I do not have any pointers.  The rule of thumb I am 
following (and if the WG disagrees, the WG carriees the day) is that the 
specification has to be implementable.  In the case of IP over Foo, we 
have understood that we will put it in a separate spec.  And people know 
to look for that spec.  Arguably, the informative reference you propose 
provides the "people know to look" mechanism.  At which point it is a 
judgment call.
And I admit, part of my reasoning on the judgment call is that we said 
this is an SFC document, and the normative header for SFC is NSH.  Even 
if other working groups are also doing other things.

Trying to find the right balance (because the suitability for other 
things is important) we said something like:
     When used in conjunct with NSH (RFC 8300), the PoT MUST be carried 
as specified in ...
And made the reference normative.   Essentially a conditional MUST, 
which is allowed my the rules.

Yours,
Joel

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Wed, 1 Apr 2020 23:28:09 +0000

Hi, Joel,

> 2020/04/01 午後7:16、Joel Halpern Direct <[email-masked]>のメール:
> 
> Fair question.  No, I do not have any pointers.  The rule of thumb I am following (and if the WG disagrees, the WG carriees the day) is that the specification has to be implementable.  In the case of IP over Foo, we have understood that we will put it in a separate spec.  And people know to look for that spec.  Arguably, the informative reference you propose provides the "people know to look" mechanism.  At which point it is a judgment call.
> And I admit, part of my reasoning on the judgment call is that we said this is an SFC document, and the normative header for SFC is NSH.  Even if other working groups are also doing other things.

Thank you for this. I agree and appreciate the 'judgement call' need.

My view is also that technology and RFCs are long-lived while WGs are not, and as such I usually prefer not to optimize on the WG (which, for cross-technology innovations like IOAM, is a relative placeholder sometimes. 

> 
> Trying to find the right balance (because the suitability for other things is important) we said something like:
>    When used in conjunct with NSH (RFC 8300), the PoT MUST be carried as specified in ...
> And made the reference normative.   Essentially a conditional MUST, which is allowed my the rules.

Strictly, POT is carried in IOAM (hence Normative to ippm-ioam-data), and beyond that is second order. Sfc-nsh-ioam ought to have that MUST.

In practice, your proposal of a conditional MUST is fully appropriate - I like it. It also (in practice) suggest it would be best to advance both SFC documents simultaneously.

Thanks,

Carlos.

---

From: Greg Mirsky <[email-masked]>
Date: Wed, 1 Apr 2020 16:28:55 -0700

Dear Carlos,
I believe that Joel has expressed it clearly and I concur with his
reasoning.

Regards,
Greg

On Wed, Apr 1, 2020 at 4:13 PM Carlos Pignataro (cpignata) <
[email-masked]> wrote:

> Dear Greg,
>
> This seems to be a rephrase of the previous email, yet I still do not
> follow the cause-effect in your argument.
>
> Normative does not mean “a reference that defines technology within the
> same Working Group’s documents that can be used”.
>
> The definition and clarification statement at [1] says “documents that
> must be read to understand or implement the technology in the new RFC”. It
> does not speak to WG charters or.
>
> Is the technology in draft-ietf-sfc-ioam-nsh a “must” for
> draft-ietf-sfc-proof-of-transit? It seems to me that the only “must”
> technology is ippm-ioam-data. I appreciate that this is also not
> necessarily a yes/no binary answer...
>
> [1]
> https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
>
>
> > > I agree with Joel that the reference in
> draft-ietf-sfc-proof-of-transit to draft-ietf-ippm-ioam-data should be
> normative.
> >
> > > I also support the proposal to add in draft-ietf-sfc-proof-of-transit
> a normative reference to draft-ietf-sfc-ioam-nsh. SFC WG is working on
> > I disagree with the premise, but regardless, it does not matter since
> POT applies to other non-SFC(-non-NSH) technologies. Therefore that
> since-then logic does not apply.
> >
> seems
> gives
> reference
> > > >>>> <mailto:[email-masked]> <mailto:[email-masked]
> >>のメール:
> > > >>>>
> > > >>>> Hi Joel,
> iOAM
> > > >>>>    >     <mailto:[email-masked] <mailto:[email-masked]
> >>>;
> Frank
> > > >>>>    >     <mailto:[email-masked] <mailto:[email-masked]
> >>>;
> Frank
> > > >>>>    >     <mailto:[email-masked] <mailto:[email-masked]
> >>>;
> > > >>>>    >     vossa senhoria o destinatário indicado, fica notificado
> de
> > > >>>> que a

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Wed, 1 Apr 2020 23:47:20 +0000

Greg,

I understood Joel’s reasoning to be different than yours, and different his position also (I understood Joel to be OK either way with a preference for Normative, and later he gave a suggestion of a conditional MUST, while your position seemed to me an absolute MUST, more terminal and inflexible).

For completeness, this was the question I asked you, under the context of the IESG note in [1] below:

Is the technology in draft-ietf-sfc-ioam-nsh a “must” for draft-ietf-sfc-proof-of-transit?

What do you think?

Best,

Carlos.

2020/04/01 午後7:28、Greg Mirsky <[email-masked]<mailto:[email-masked]>>のメール:

Dear Carlos,
I believe that Joel has expressed it clearly and I concur with his reasoning.

Regards,
Greg

On Wed, Apr 1, 2020 at 4:13 PM Carlos Pignataro (cpignata) <[email-masked]<mailto:[email-masked]>> wrote:
Dear Greg,

Carlos.

> 2020/04/01 午後3:36、Greg Mirsky <[email-masked]<mailto:[email-masked]>>のメール:
>
> Dear Carlos,
> On Wed, Apr 1, 2020 at 12:16 PM Carlos Pignataro (cpignata) <[email-masked]<mailto:[email-masked]>> wrote:
> Dear Greg,
>
> > 2020/04/01 午後2:59、Greg Mirsky <[email-masked]<mailto:[email-masked]>>のメール:
> >
> > Dear All,
> > On Tue, Mar 24, 2020 at 2:25 PM Joel M. Halpern <[email-masked]<mailto:[email-masked]>> wrote:
> > >> 2020/03/24 午後5:10、Joel M. Halpern <[email-masked]<mailto:[email-masked]>
> > >> <mailto:[email-masked]<mailto:[email-masked]>>>のメール:
> > >>
> > >>>> 2020/03/24 午後4:48、Greg Mirsky <[email-masked]<mailto:[email-masked]>
> > >>>> <mailto:[email-masked]<mailto:[email-masked]>> <mailto:[email-masked]<mailto:[email-masked]>>>のメール:
> > >>>>
> > >>>> Hi Joel,
> > >>>> <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>
> > >>>> <mailto:[email-masked]<mailto:[email-masked]>>> wrote:
> > >>>>
> > >>>>    > <fbrockne=[email-masked]<mailto:[email-masked]>
> > >>>> <mailto:fbrockne<mailto:fbrockne>=[email-masked]<mailto:[email-masked]>>
> > >>>>    <mailto:[email-masked]<mailto:[email-masked]>>
> > >>>>    > <mailto:[email-masked]<mailto:[email-masked]>
> > >>>>    <mailto:[email-masked]<mailto:[email-masked]>>>> wrote:
> > >>>>    >
> > >>>>    >     Dear SFC WG,____
> > >>>>    >
> > >>>>    >     __ __
> > >>>>    >
> > >>>>    >     *To:* Alejandro Aguado FI <[email-masked]<mailto:[email-masked]>
> > >>>> <mailto:[email-masked]<mailto:[email-masked]>>
> > >>>>    <mailto:[email-masked]<mailto:[email-masked]>>
> > >>>>    >     <mailto:[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>>>;
> > >>>>    Diego R. Lopez
> > >>>> <mailto:[email-masked]<mailto:[email-masked]>>
> > >>>>    <mailto:[email-masked]<mailto:[email-masked]>>
> > >>>>    >     <mailto:[email-masked]<mailto:[email-masked]>
> > >>>>    <mailto:[email-masked]<mailto:[email-masked]>>>>; Carlos Pignataro (cpignata)
> > >>>>    >     <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>
> > >>>> <mailto:[email-masked]<mailto:[email-masked]>>
> > >>>>    <mailto:[email-masked]<mailto:[email-masked]> <mailto:cpignata@cisco.<mailto:cpignata@cisco.>.com>>>;
> > >>>>    ALEJANDRO AGUADO
> > >>>>    >     MARTIN <[email-masked]<mailto:[email-masked]>
> > >>>> <mailto:[email-masked]<mailto:[email-masked]>>
> > >>>>    <mailto:[email-masked]<mailto:[email-masked]>>
> > >>>>    >     <mailto:[email-masked]<mailto:[email-masked]>
> > >>>>    <mailto:[email-masked]<mailto:[email-masked]>>>>; Shwetha
> > >>>>    >     Bhandari (shwethab) <[email-masked]<mailto:[email-masked]>
> > >>>> <mailto:[email-masked]<mailto:[email-masked]>>
> > >>>>    <mailto:[email-masked]<mailto:[email-masked]>>
> > >>>>    >     <mailto:[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>>>;
> > >>>>    Tal Mizrahi <[email-masked]<mailto:[email-masked]>
> > >>>> <mailto:[email-masked]<mailto:[email-masked]>>
> > >>>>    <mailto:[email-masked]<mailto:[email-masked]>>
> > >>>>    >     <mailto:[email-masked]<mailto:[email-masked]>
> > >>>>    <mailto:[email-masked]<mailto:[email-masked]>>>>
> > >>>>    >     *Cc:* [email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>> <mailto:[email-masked]<mailto:[email-masked]>>
> > >>>>    <mailto:[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>>
> > >>>>    >     *From:* Alejandro Aguado FI <[email-masked]<mailto:[email-masked]>
> > >>>> <mailto:[email-masked]<mailto:[email-masked]>>
> > >>>>    <mailto:[email-masked]<mailto:[email-masked]>>
> > >>>>    >     <mailto:[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>>>
> > >>>>    >     *To:* Diego R. Lopez <[email-masked]<mailto:[email-masked]>
> > >>>> <mailto:[email-masked]<mailto:[email-masked]>>
> > >>>>    <mailto:[email-masked]<mailto:[email-masked]>>
> > >>>>    >     <mailto:[email-masked]<mailto:[email-masked]>
> > >>>>    <mailto:[email-masked]<mailto:[email-masked]>>>>; Carlos Pignataro (cpignata)
> > >>>>    >     <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>
> > >>>> <mailto:[email-masked]<mailto:[email-masked]>>
> > >>>>    <mailto:[email-masked]<mailto:[email-masked]> <mailto:cpignata@cisco.<mailto:cpignata@cisco.>.com>>>; Frank
> > >>>>    Brockners
> > >>>>    >     (fbrockne) <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>
> > >>>> <mailto:[email-masked]<mailto:[email-masked]>>
> > >>>>    <mailto:[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>>>;
> > >>>>    >     ALEJANDRO AGUADO MARTIN
> > >>>>    <[email-masked]<mailto:[email-masked]>
> > >>>> <mailto:[email-masked]<mailto:[email-masked]>>
> > >>>>    <mailto:[email-masked]<mailto:[email-masked]>>
> > >>>>    >     <mailto:[email-masked]<mailto:[email-masked]>
> > >>>>    <mailto:[email-masked]<mailto:[email-masked]>>>>; Shwetha
> > >>>>    >     Bhandari (shwethab) <[email-masked]<mailto:[email-masked]>
> > >>>> <mailto:[email-masked]<mailto:[email-masked]>>
> > >>>>    <mailto:[email-masked]<mailto:[email-masked]>>
> > >>>>    >     <mailto:[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>>>;
> > >>>>    Tal Mizrahi <[email-masked]<mailto:[email-masked]>
> > >>>> <mailto:[email-masked]<mailto:[email-masked]>>
> > >>>>    <mailto:[email-masked]<mailto:[email-masked]>>
> > >>>>    >     <mailto:[email-masked]<mailto:[email-masked]>
> > >>>>    <mailto:[email-masked]<mailto:[email-masked]>>>>
> > >>>>    >     *Cc:* [email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>> <mailto:[email-masked]<mailto:[email-masked]>>
> > >>>>    <mailto:[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>>
> > >>>>    >     (shwethab) ([email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>
> > >>>> <mailto:[email-masked]<mailto:[email-masked]>>
> > >>>>    <mailto:[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>>)
> > >>>>    >     escribió:____
> > >>>>    >
> > >>>>    >     Hi Alejandro, Diego,____
> > >>>>    >
> > >>>>    >     ____
> > >>>>    >
> > >>>>    >     *From: *"Frank Brockners (fbrockne)" <[email-masked]<mailto:[email-masked]>
> > >>>> <mailto:[email-masked]<mailto:[email-masked]>>
> > >>>>    <mailto:[email-masked]<mailto:[email-masked]>>
> > >>>>    >     <mailto:[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>>>
> > >>>>    >     <[email-masked]<mailto:[email-masked]>
> > >>>> <mailto:[email-masked]<mailto:[email-masked]>>
> > >>>>    <mailto:[email-masked]<mailto:[email-masked]>>
> > >>>>    >     <mailto:[email-masked]<mailto:[email-masked]>
> > >>>>    <mailto:[email-masked]<mailto:[email-masked]>>>>, "Diego R.
> > >>>>    >     Lopez" <[email-masked]<mailto:[email-masked]>
> > >>>> <mailto:[email-masked]<mailto:[email-masked]>>
> > >>>>    <mailto:[email-masked]<mailto:[email-masked]>>
> > >>>>    >     <mailto:[email-masked]<mailto:[email-masked]>
> > >>>>    <mailto:[email-masked]<mailto:[email-masked]>>>>, Carlos Pignataro
> > >>>>    >     <cpignata@cisco..com <mailto:[email-masked]<mailto:[email-masked]>
> > >>>>    <mailto:[email-masked]<mailto:[email-masked]>>>>, Shwetha bhandari
> > >>>>    >     <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>
> > >>>> <mailto:[email-masked]<mailto:[email-masked]>>
> > >>>>    <mailto:[email-masked]<mailto:[email-masked]> <mailto:shwethab@cisco.<mailto:shwethab@cisco.>.com>>>, Tal
> > >>>> Mizrahi
> > >>>>    >     <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>
> > >>>>    <mailto:[email-masked]<mailto:[email-masked]>>
> > >>>>    <mailto:[email-masked]<mailto:[email-masked]>
> > >>>> <mailto:[email-masked]<mailto:[email-masked]>>>>
> > >>>>    >     *Cc: *"[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>
> > >>>> <mailto:[email-masked]<mailto:[email-masked]>>
> > >>>>    <mailto:[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>>"
> > >>>>    >     <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>
> > >>>> <mailto:[email-masked]<mailto:[email-masked]>>
> > >>>>    <mailto:[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>>>,
> > >>>>    "[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>> <mailto:[email-masked]<mailto:[email-masked]>>
> > >>>>    >     <mailto:[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>>" <[email-masked]<mailto:[email-masked]>
> > >>>> <mailto:[email-masked]<mailto:[email-masked]>>
> > >>>>    <mailto:[email-masked]<mailto:[email-masked]>> <mailto:[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>>>
> > >>>>    >     <[email-masked]<mailto:[email-masked]>
> > >>>> <mailto:[email-masked]<mailto:[email-masked]>>
> > >>>>    <mailto:[email-masked]<mailto:[email-masked]>>
> > >>>>    >     <mailto:[email-masked]<mailto:[email-masked]>
> > >>>>    <mailto:[email-masked]<mailto:[email-masked]>>>>; Diego R. Lopez
> > >>>> <mailto:[email-masked]<mailto:[email-masked]>>
> > >>>>    <mailto:[email-masked]<mailto:[email-masked]>>
> > >>>>    >     <mailto:[email-masked]<mailto:[email-masked]>
> > >>>>    <mailto:[email-masked]<mailto:[email-masked]>>>>; Carlos Pignataro (cpignata)
> > >>>>    >     <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>
> > >>>> <mailto:[email-masked]<mailto:[email-masked]>>
> > >>>>    <mailto:[email-masked]<mailto:[email-masked]> <mailto:cpignata@cisco.<mailto:cpignata@cisco.>.com>>>; Shwetha
> > >>>>    Bhandari
> > >>>>    >     (shwethab) <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>
> > >>>> <mailto:[email-masked]<mailto:[email-masked]>>
> > >>>>    <mailto:[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>>>; Tal
> > >>>>    >     Mizrahi <[email-masked]<mailto:[email-masked]>
> > >>>> <mailto:[email-masked]<mailto:[email-masked]>>
> > >>>>    <mailto:tal.mizrahi.phd@gmail.<mailto:tal.mizrahi.phd@gmail.>.com>
> > >>>>    <mailto:[email-masked]<mailto:[email-masked]>
> > >>>> <mailto:[email-masked]<mailto:[email-masked]>>>>
> > >>>>    >     *Cc:* [email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>
> > >>>> <mailto:[email-masked]<mailto:[email-masked]>>
> > >>>>    <mailto:[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>>;
> > >>>> [email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>> <mailto:[email-masked]<mailto:[email-masked]>>
> > >>>>    >     <mailto:[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>>
> > >>>>    >     <[email-masked]<mailto:[email-masked]>
> > >>>> <mailto:[email-masked]<mailto:[email-masked]>>
> > >>>>    <mailto:[email-masked]<mailto:[email-masked]>>
> > >>>>    >     <mailto:[email-masked]<mailto:[email-masked]>
> > >>>>    <mailto:[email-masked]<mailto:[email-masked]>>>>
> > >>>>    >     *To:* Diego R. Lopez <[email-masked]<mailto:[email-masked]>
> > >>>> <mailto:[email-masked]<mailto:[email-masked]>>
> > >>>>    <mailto:[email-masked]<mailto:[email-masked]>>
> > >>>>    >     <mailto:[email-masked]<mailto:[email-masked]>
> > >>>>    <mailto:[email-masked]<mailto:[email-masked]>>>>; Carlos Pignataro (cpignata)
> > >>>>    >     <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>
> > >>>> <mailto:[email-masked]<mailto:[email-masked]>>
> > >>>>    <mailto:[email-masked]<mailto:[email-masked]> <mailto:cpignata@cisco.<mailto:cpignata@cisco.>.com>>>; Frank
> > >>>>    Brockners
> > >>>>    >     (fbrockne) <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>
> > >>>> <mailto:[email-masked]<mailto:[email-masked]>>
> > >>>>    <mailto:[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>>>; Shwetha
> > >>>>    >     Bhandari (shwethab) <[email-masked]<mailto:[email-masked]>
> > >>>> <mailto:[email-masked]<mailto:[email-masked]>>
> > >>>>    <mailto:[email-masked]<mailto:[email-masked]>>
> > >>>>    >     <mailto:[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>>>;
> > >>>>    Tal Mizrahi <[email-masked]<mailto:[email-masked]>
> > >>>> <mailto:[email-masked]<mailto:[email-masked]>>
> > >>>>    <mailto:[email-masked]<mailto:[email-masked]>>
> > >>>>    >     <mailto:[email-masked]<mailto:[email-masked]>
> > >>>>    <mailto:[email-masked]<mailto:[email-masked]>>>>
> > >>>>    >     *Cc:* [email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>
> > >>>> <mailto:[email-masked]<mailto:[email-masked]>>
> > >>>>    <mailto:[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>>
> > >>>>    > [email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>> <mailto:[email-masked]<mailto:[email-masked]>>
> > >>>> <mailto:[email-masked]<mailto:[email-masked]>
> > >>>>    <mailto:[email-masked]<mailto:[email-masked]>>>
> > >>>>    > [email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>> <mailto:[email-masked]<mailto:[email-masked]>>
> > >>>> [email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>> <mailto:[email-masked]<mailto:[email-masked]>>
> > [email-masked]<mailto:[email-masked]>

---

From: Greg Mirsky <[email-masked]>
Date: Wed, 1 Apr 2020 16:58:16 -0700

Carlos,
after reading Joel's conditional MUST I've reconsidered my position. I
agree with the text he proposed.

Regards,
Greg

On Wed, Apr 1, 2020 at 4:47 PM Carlos Pignataro (cpignata) <
[email-masked]> wrote:

> Greg,
>
> I understood Joel’s reasoning to be different than yours, and different
> his position also (I understood Joel to be OK either way with a preference
> for Normative, and later he gave a suggestion of a conditional MUST, while
> your position seemed to me an absolute MUST, more terminal and inflexible).
>
>> draft-ietf-sfc-proof-of-transit?
>
>
> What do you think?
>
> Best,
>
> Carlos.
>
>
> 2020/04/01 午後7:28、Greg Mirsky <[email-masked]>のメール:
>
> Dear Carlos,
>> > > >>>>    >     <mailto:[email-masked] <mailto:[email-masked]
>> >>>
>> > > >>>>    >     current doc, given that the model and the description
>> go
>> > > >>>> hand in

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Thu, 2 Apr 2020 00:01:47 +0000

Dear Greg,

Thanks for this update.

For completeness:

What do you think?

That would give the more strict definition of the type of reference it is — understanding of course that the WG can find additional more fitting solutions, conditional / compromised approaches that are in-between Informative and Normative.

Thank,

Carlos.

2020/04/01 午後7:58、Greg Mirsky <[email-masked]<mailto:[email-masked]>>のメール:

Carlos,
after reading Joel's conditional MUST I've reconsidered my position. I agree with the text he proposed.

Regards,
Greg

On Wed, Apr 1, 2020 at 4:47 PM Carlos Pignataro (cpignata) <[email-masked]<mailto:[email-masked]>> wrote:
Greg,

What do you think?

Best,

Carlos.

Dear Carlos,

Regards,
Greg

Carlos.