Subject: Re: [PANRG] [irsg] IRSG review request draft-irtf-panrg-questions-07

From: Spencer Dawkins at IETF <[email-masked]>
Date: Fri, 11 Jun 2021 10:00:39 -0500

Hi, Brian and Laurent,

I am the Worst. Draft. Shepherd. Ever.

My apologies for my Long Winter's Nap, but I just noticed that I haven't
seen a response from either Laurent or "the RG chairs" about the changes in
-08 (for Laurent's review) and -09, and when Colin said he was waiting for
confirmation from "the RG chairs", he might have meant "the draft shepherd,
who is usually one of the RG chairs, but not for THIS draft". Assuming so,
and now that I'm awake, let's move forward. Please see below.

On Fri, Jan 15, 2021 at 12:21 PM Colin Perkins <[email-masked]> wrote:

> Brian, Laurent – thanks!
>
> At this stage, I’ll wait for confirmation from Laurent and the RG chairs
> that the changes are okay, before proceeding with the IRSG final poll.
>

 -08 seems, to my eye, to be a significant improvement over -07 - thank
you, Laurent - but I saw a couple of suggestions that don't seem to have
been translated into the draft yet.

Laurent suggested labeling the questions, for ease of reference (both in
the document and in the RG). I like that suggestion. Brian, do you have a
thought about this?

Laurent noted that the core topic in section 2.5 seemed to be focused on
privacy/protection against pervasive surveillance, and asked if there were
other known/foreseen implications for what is now "of Path Awareness for
the Transport and Application Layers".I did not see a response or text
change here. Brian, is there anything to add?

Laurent, if you could let me/Brian know what you think of the changes in
https://www.ietf.org/rfcdiff?url2=draft-irtf-panrg-questions-09.txt&url1=draft-irtf-panrg-questions-07.txt,
almost all of which are in response to your review, that would be AWESOME.

Best,

Spencer

---

From: "Ciavaglia, Laurent" <[email-masked]>
Date: Fri, 18 Jun 2021 17:36:35 +0000

Hello Spencer, Brian, Colin & All,

Please see in-line below for my replies.

Thank you.

Best regards, Laurent

From: irsg <[email-masked]> On Behalf Of Spencer Dawkins at IETF
Sent: vendredi 11 juin 2021 17:01
To: Colin Perkins <[email-masked]>
Cc: Ciavaglia, Laurent (Nokia - FR/Paris-Saclay) <[email-masked]>; [email-masked]; [email-masked]; The IRSG <[email-masked]>
Subject: Re: [irsg] [PANRG] IRSG review request draft-irtf-panrg-questions-07

Hi, Brian and Laurent,

My apologies for my Long Winter's Nap, but I just noticed that I haven't seen a response from either Laurent or "the RG chairs" about the changes in -08 (for Laurent's review) and -09, and when Colin said he was waiting for confirmation from "the RG chairs", he might have meant "the draft shepherd, who is usually one of the RG chairs, but not for THIS draft". Assuming so, and now that I'm awake, let's move forward. Please see below.

On Fri, Jan 15, 2021 at 12:21 PM Colin Perkins <[email-masked]<mailto:[email-masked]>> wrote:
Brian, Laurent – thanks!

At this stage, I’ll wait for confirmation from Laurent and the RG chairs that the changes are okay, before proceeding with the IRSG final poll.

 -08 seems, to my eye, to be a significant improvement over -07 - thank you, Laurent - but I saw a couple of suggestions that don't seem to have been translated into the draft yet.

Laurent suggested labeling the questions, for ease of reference (both in the document and in the RG). I like that suggestion. Brian, do you have a thought about this?

Laurent noted that the core topic in section 2.5 seemed to be focused on privacy/protection against pervasive surveillance, and asked if there were other known/foreseen implications for what is now "of Path Awareness for the Transport and Application Layers".I did not see a response or text change here. Brian, is there anything to add?

Laurent, if you could let me/Brian know what you think of the changes in https://www.ietf.org/rfcdiff?url2=draft-irtf-panrg-questions-09.txt&url1=draft-irtf-panrg-questions-07.txt, almost all of which are in response to your review, that would be AWESOME.
[Ciavaglia, Laurent] I’ve read the latest version (-09) and my comments have been well addressed (thank you). The document is fine to proceed for me.
I remain available if Brian works out a revision for the above points, but I trust he will “Do the right thing” 😉  (credits: Spencer and Spike)

Best,

Spencer

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Fri, 18 Jun 2021 15:09:38 -0500

Hi, Laurent,

On Fri, Jun 18, 2021 at 12:36 PM Ciavaglia, Laurent <
[email-masked]> wrote:

> *From:* irsg <[email-masked]> *On Behalf Of *Spencer Dawkins at
> IETF
> *Sent:* vendredi 11 juin 2021 17:01
> *To:* Colin Perkins <[email-masked]>
> *Cc:* Ciavaglia, Laurent (Nokia - FR/Paris-Saclay) <
> [email-masked]>; [email-masked];
> [email-masked]; The IRSG <[email-masked]>
> *Subject:* Re: [irsg] [PANRG] IRSG review request
> draft-irtf-panrg-questions-07
>
>
>
> Hi, Brian and Laurent,
>
>
>
> *[Ciavaglia, Laurent] I’ve read the latest version (-09) and my comments
> have been well addressed (thank you). The document is fine to proceed for
> me.*
>
> *I remain available if Brian works out a revision for the above points,
> but I trust he will “Do the right thing” **😉**  (credits: Spencer and
> Spike)*
>

Thank you for your follow-up on this!

I think I'm waiting for a response from Brian about whether a new revision
is needed for these last two points.

Best,

Spencer

---

From: Colin Perkins <[email-masked]>
Date: Mon, 21 Jun 2021 17:36:48 +0100

Hi,

There were some comments from Adrian Farrel in February - did they get addressed? https://mailarchive.ietf.org/arch/msg/panrg/w62vLVTaI-1Myr_u8jPUF8a0yRQ <https://mailarchive.ietf.org/arch/msg/panrg/w62vLVTaI-1Myr_u8jPUF8a0yRQ>

Colin

> On 11 Jun 2021, at 16:00, Spencer Dawkins at IETF <[email-masked]> wrote:
> 
> Hi, Brian and Laurent, 
> 
> On Fri, Jan 15, 2021 at 12:21 PM Colin Perkins <[email-masked] <mailto:[email-masked]>> wrote:
> Brian, Laurent – thanks!
> 
> Laurent, if you could let me/Brian know what you think of the changes in https://www.ietf.org/rfcdiff?url2=draft-irtf-panrg-questions-09.txt&url1=draft-irtf-panrg-questions-07.txt <https://www.ietf.org/rfcdiff?url2=draft-irtf-panrg-questions-09.txt&url1=draft-irtf-panrg-questions-07.txt>, almost all of which are in response to your review, that would be AWESOME.
> 
> Best,
> 
> Spencer

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Mon, 21 Jun 2021 15:38:03 -0500

Hi, Colin,

On Mon, Jun 21, 2021 at 11:37 AM Colin Perkins <[email-masked]> wrote:

> Hi,
>
> There were some comments from Adrian Farrel in February - did they get
> addressed?
> https://mailarchive.ietf.org/arch/msg/panrg/w62vLVTaI-1Myr_u8jPUF8a0yRQ
>
> Colin
>

I could reasonably let Brian answer this question, but if the shepherd
should know the answer ...

Adrian had two comments.

The first one was about the definition of a path, and that also affected
https://datatracker.ietf.org/doc/draft-irtf-panrg-what-not-to-do/. People
might remember that we chased around this for a bit, because the definitive
place where we defined terms was in
https://datatracker.ietf.org/doc/draft-irtf-panrg-path-properties/, which
was expected to be requested for publication after both
https://datatracker.ietf.org/doc/draft-irtf-panrg-what-not-to-do/ and
https://datatracker.ietf.org/doc/draft-irtf-panrg-questions/. So we
discussed adding normative references to both
https://datatracker.ietf.org/doc/draft-irtf-panrg-what-not-to-do/ and
https://datatracker.ietf.org/doc/draft-irtf-panrg-questions/, which was one
way of resolving the comment, at the cost of holding both drafts in
MISS-REF until
https://datatracker.ietf.org/doc/draft-irtf-panrg-path-properties/ was also
completed.

So my understanding (and Brian can correct me) is that the changes between
-07 and -09 in Section 1.1 are responsive to Adrian's comment. See
https://www.ietf.org/rfcdiff?url2=draft-irtf-panrg-questions-09.txt&url1=draft-irtf-panrg-questions-07.txt
.

Adrian's second comment, which was discussed in much more detail in private
email that I happened to be copied on, was about the idea that (Spencer's
paraphrase) PANRG is thinking about paths from an end-point's perspective,
but there's also an inside-the-network way of thinking about paths, that's
equally valid to think about, that includes what we commonly think of as
routing, plus traffic engineering, tunneling, and several other aspects of
packet forwarding.

 We had two or three exchanges that were pretty interesting, but I think we
left things with the idea that there may be a recursive situation going on,
where a path is

   - how you get from one host to another (which is mostly the way
   PANRG people have thought about paths, as best I can tell), OR
   - how you get from the edge router next to one host to either the edge
   router next to the other host or the router next to the "next network on
   the way to the other host", OR
   - how you get from one core router to another core router, OR
   - how you get from one physical layer box to another physical layer box,
   OR
   - well, it's just turtles all the way down.

I don't think Brian, or I, thought that PANRG intentionally planned to
exclude this layered view of paths, so the best way to take that forward
was to start publishing drafts that explained how "path awareness" at
various layers of the network was similar to, or different from, path
awareness from host to host, and that ought to be in scope for PANRG.

Brian, did I get that about right?

Best,

Spencer

---

From: "Adrian Farrel" <[email-masked]>
Date: Mon, 21 Jun 2021 22:50:30 +0100

Hi Spencer, Colin, RG,

Spencer does a fine job of summarising the discussions that went on and to pointing up the changes to the document that resulted.

To the first point, I think that it is good that 1.1 has more text on the definition of a “path” although (to me) it is unfortunate to dodge the question in this foundational document. If, as seems to be the case, the intention is to deliberately leave open to future research the meaning of “path” I feel that the document could more clearly articulate what it is about a path that is open for debate (i.e., explicitly pose the questions that the paragraph claims exist). I think that “technology dependent” may also be misleading if (as I believe is the intention) this definition is intended to apply at multiple layer of Ye Olde OSI Model.

However, I also accept that, as I am not willing/able to invest significantly in helping to craft text and drive it to consensus, I should get out of the way.

To the second point, the discussions of PCE were lengthy. It’s good that there is now a reference to 4655, but I wonder whether the text has simply introduced a new confusion: what is an endpoint? Is the end of a tunnel (i.e., a point of encapsulation or decapsulation) an endpoint? I would certainly argue it is. But, you see the problem with “endpoint”? Is it intended to mean “source of an IP packet”, in which case how does IP-in-IP relate? Is it intended to mean the source of the data flow (regardless of encapsulation) in which case it may extend beyond the IP domain. Or…

And I would claim that a PCE is precisely an endpoint-exposed approach. But perhaps the new text in 1.1 is ambiguous?

While

there are technologies that attempt better-than-best-effort delivery,

the interfaces to these are generally administrative as opposed to

endpoint-exposed (e.g.  PCE [RFC4655] and SD-WAN approaches), and

they are often restricted to single administrative domains.

Does the “e.g.” apply to “generally administrative” or “endpoint-exposed”?

But I agree that inspiring questions is the thing (we don’t do enough of that, IMHO), and without questions we can’t have answers. So, since this document clearly inspires me to ask more questions, it must be doing something right.

Cheers,

Adrian

From: Panrg <[email-masked]> On Behalf Of Spencer Dawkins at IETF
Sent: 21 June 2021 21:38
To: Colin Perkins <[email-masked]>
Cc: Ciavaglia, Laurent (Nokia - FR/Paris-Saclay) <[email-masked]>; Brian Trammell <[email-masked]>; [email-masked]; [email-masked]; The IRSG <[email-masked]>
Subject: Re: [PANRG] [irsg] IRSG review request draft-irtf-panrg-questions-07

Hi, Colin, 

On Mon, Jun 21, 2021 at 11:37 AM Colin Perkins <[email-masked] <mailto:[email-masked]> > wrote:

Hi,

There were some comments from Adrian Farrel in February - did they get addressed? https://mailarchive.ietf.org/arch/msg/panrg/w62vLVTaI-1Myr_u8jPUF8a0yRQ

Colin

I could reasonably let Brian answer this question, but if the shepherd should know the answer ... 

Adrian had two comments. 

The first one was about the definition of a path, and that also affected  https://datatracker.ietf.org/doc/draft-irtf-panrg-what-not-to-do/. People might remember that we chased around this for a bit, because the definitive place where we defined terms was in https://datatracker.ietf.org/doc/draft-irtf-panrg-path-properties/, which was expected to be requested for publication after both https://datatracker.ietf.org/doc/draft-irtf-panrg-what-not-to-do/ and https://datatracker.ietf.org/doc/draft-irtf-panrg-questions/. So we discussed adding normative references to both https://datatracker.ietf.org/doc/draft-irtf-panrg-what-not-to-do/ and https://datatracker.ietf.org/doc/draft-irtf-panrg-questions/, which was one way of resolving the comment, at the cost of holding both drafts in MISS-REF until https://datatracker.ietf.org/doc/draft-irtf-panrg-path-properties/ was also completed. 

So my understanding (and Brian can correct me) is that the changes between -07 and -09 in Section 1.1 are responsive to Adrian's comment. See https://www.ietf.org/rfcdiff?url2=draft-irtf-panrg-questions-09.txt <https://www.ietf.org/rfcdiff?url2=draft-irtf-panrg-questions-09.txt&url1=draft-irtf-panrg-questions-07.txt> &url1=draft-irtf-panrg-questions-07.txt.

Adrian's second comment, which was discussed in much more detail in private email that I happened to be copied on, was about the idea that (Spencer's paraphrase) PANRG is thinking about paths from an end-point's perspective, but there's also an inside-the-network way of thinking about paths, that's equally valid to think about, that includes what we commonly think of as routing, plus traffic engineering, tunneling, and several other aspects of packet forwarding.

 We had two or three exchanges that were pretty interesting, but I think we left things with the idea that there may be a recursive situation going on, where a path is 

*	how you get from one host to another (which is mostly the way PANRG people have thought about paths, as best I can tell), OR
*	how you get from the edge router next to one host to either the edge router next to the other host or the router next to the "next network on the way to the other host", OR
*	how you get from one core router to another core router, OR
*	how you get from one physical layer box to another physical layer box, OR 
*	well, it's just turtles all the way down.

I don't think Brian, or I, thought that PANRG intentionally planned to exclude this layered view of paths, so the best way to take that forward was to start publishing drafts that explained how "path awareness" at various layers of the network was similar to, or different from, path awareness from host to host, and that ought to be in scope for PANRG.

Best,

Spencer

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Thu, 24 Jun 2021 15:08:53 -0500

Hi, Colin,

So, just to wrap this up with a bow ...

On Mon, Jun 21, 2021 at 4:50 PM Adrian Farrel <[email-masked]> wrote:

> Hi Spencer, Colin, RG,
>
>
>
> Spencer does a fine job of summarising the discussions that went on and to
> pointing up the changes to the document that resulted.
>
>
>
> To the first point, I think that it is good that 1.1 has more text on the
> definition of a “path” although (to me) it is unfortunate to dodge the
> question in this foundational document. If, as seems to be the case, the
> intention is to deliberately leave open to future research the meaning of
> “path” I feel that the document could more clearly articulate what it is
> about a path that is open for debate (i.e., explicitly pose the questions
> that the paragraph claims exist). I think that “technology dependent” may
> also be misleading if (as I believe is the intention) this definition is
> intended to apply at multiple layer of Ye Olde OSI Model.
>
>
>
> However, I also accept that, as I am not willing/able to invest
> significantly in helping to craft text and drive it to consensus, I should
> get out of the way.
>
>
>
> To the second point, the discussions of PCE were lengthy. It’s good that
> there is now a reference to 4655, but I wonder whether the text has simply
> introduced a new confusion: what is an endpoint? Is the end of a tunnel
> (i.e., a point of encapsulation or decapsulation) an endpoint? I would
> certainly argue it is. But, you see the problem with “endpoint”? Is it
> intended to mean “source of an IP packet”, in which case how does IP-in-IP
> relate? Is it intended to mean the source of the data flow (regardless of
> encapsulation) in which case it may extend beyond the IP domain. Or…
>
>
>
> And I would claim that a PCE is precisely an endpoint-exposed approach.
> But perhaps the new text in 1.1 is ambiguous?
>
> While
>
> But I agree that inspiring questions is the thing (we don’t do enough of
> that, IMHO), and without questions we can’t have answers. So, since this
> document clearly inspires me to ask more questions, it must be doing
> something right.
>

After chatting with Brian and with Jen, all of us think that Adrian is
pointing to a potential (and important, and worthwhile) *new *work item, as
we take the heavily transport-influenced
https://datatracker.ietf.org/doc/draft-irtf-panrg-questions/ and
https://datatracker.ietf.org/doc/draft-irtf-panrg-what-not-to-do/ forward
to understand how much these questions, and lessons, translate into other
levels of the protocol stack, including topics like tunneling and
encapsulation, path selection, and routing strategies.

After looking at the diffs from -07 to -09, I do think -09 gives enough
hints about this to encourage that work, and I note that it also dovetails
with some of the items that
https://datatracker.ietf.org/doc/html/draft-irtf-panrg-what-not-to-do-19#section-5
identifies as "Future Work", so I think it's fair to publish
https://datatracker.ietf.org/doc/draft-irtf-panrg-questions/ at this time.

So I think you can change the IRTF state from "Waiting for Document
Shepherd" to "Waiting for IRTF Chair".

Best,

Spencer

> Cheers,
>
> Adrian
>
>
>
>
>
> *From:* Panrg <[email-masked]> *On Behalf Of *Spencer Dawkins at
> IETF
> *Sent:* 21 June 2021 21:38
> [email-masked]>; Brian Trammell <[email-masked]>;
> [email-masked]; [email-masked]; The IRSG <
> [email-masked]>
> *Subject:* Re: [PANRG] [irsg] IRSG review request
> https://datatracker.ietf.org/doc/draft-irtf-panrg-questions/, which was
> one way of resolving the comment, at the cost of holding both drafts in
> MISS-REF until
> https://datatracker.ietf.org/doc/draft-irtf-panrg-path-properties/ was
> also completed.
>
>
>
> Adrian's second comment, which was discussed in much more detail in
> private email that I happened to be copied on, was about the idea that
> (Spencer's paraphrase) PANRG is thinking about paths from an end-point's
> perspective, but there's also an inside-the-network way of thinking about
> paths, that's equally valid to think about, that includes what we commonly
> think of as routing, plus traffic engineering, tunneling, and several other
> aspects of packet forwarding.
>
>
>
>  We had two or three exchanges that were pretty interesting, but I think
> we left things with the idea that there may be a recursive situation going
> on, where a path is
>
>    - how you get from one physical layer box to another physical layer
>    box, OR

---

From: Colin Perkins <[email-masked]>
Date: Thu, 24 Jun 2021 22:49:13 +0100

Hi Spencer, Adrian, all,

Thank you for the detailed discussion. 

If there are no objections in the next week, I’ll move forward with the -09 draft to the IRSG approval ballot prior to publication.

Colin

> On 24 Jun 2021, at 21:08, Spencer Dawkins at IETF <[email-masked]> wrote:
> 
> Hi, Colin, 
> 
> On Mon, Jun 21, 2021 at 4:50 PM Adrian Farrel <[email-masked] <mailto:[email-masked]>> wrote:
> Hi Spencer, Colin, RG,
> 
>  
> 
> After chatting with Brian and with Jen, all of us think that Adrian is pointing to a potential (and important, and worthwhile) new work item, as we take the heavily transport-influenced https://datatracker.ietf.org/doc/draft-irtf-panrg-questions/ <https://datatracker.ietf.org/doc/draft-irtf-panrg-questions/> and https://datatracker.ietf.org/doc/draft-irtf-panrg-what-not-to-do/ <https://datatracker.ietf.org/doc/draft-irtf-panrg-what-not-to-do/> forward to understand how much these questions, and lessons, translate into other levels of the protocol stack, including topics like tunneling and encapsulation, path selection, and routing strategies. 
> 
> After looking at the diffs from -07 to -09, I do think -09 gives enough hints about this to encourage that work, and I note that it also dovetails with some of the items that https://datatracker.ietf.org/doc/html/draft-irtf-panrg-what-not-to-do-19#section-5 <https://datatracker.ietf.org/doc/html/draft-irtf-panrg-what-not-to-do-19#section-5> identifies as "Future Work", so I think it's fair to publish https://datatracker.ietf.org/doc/draft-irtf-panrg-questions/ <https://datatracker.ietf.org/doc/draft-irtf-panrg-questions/> at this time. 
> 
> So I think you can change the IRTF state from "Waiting for Document Shepherd" to "Waiting for IRTF Chair".
> 
> Best,
> 
> Spencer
>  
> Cheers,
> 
> Adrian
> 
>  
> 
>  
> 
> From: Panrg <[email-masked] <mailto:[email-masked]>> On Behalf Of Spencer Dawkins at IETF
> Sent: 21 June 2021 21:38
> To: Colin Perkins <[email-masked] <mailto:[email-masked]>>
> Cc: Ciavaglia, Laurent (Nokia - FR/Paris-Saclay) <[email-masked] <mailto:[email-masked]>>; Brian Trammell <[email-masked] <mailto:[email-masked]>>; [email-masked] <mailto:[email-masked]>; [email-masked] <mailto:[email-masked]>; The IRSG <[email-masked] <mailto:[email-masked]>>
> On Mon, Jun 21, 2021 at 11:37 AM Colin Perkins <[email-masked] <mailto:[email-masked]>> wrote:
> 
> Hi,
> 
>  
> 
> The first one was about the definition of a path, and that also affected  https://datatracker.ietf.org/doc/draft-irtf-panrg-what-not-to-do/ <https://datatracker.ietf.org/doc/draft-irtf-panrg-what-not-to-do/>. People might remember that we chased around this for a bit, because the definitive place where we defined terms was in https://datatracker.ietf.org/doc/draft-irtf-panrg-path-properties/ <https://datatracker.ietf.org/doc/draft-irtf-panrg-path-properties/>, which was expected to be requested for publication after both https://datatracker.ietf.org/doc/draft-irtf-panrg-what-not-to-do/ <https://datatracker.ietf.org/doc/draft-irtf-panrg-what-not-to-do/> and https://datatracker.ietf.org/doc/draft-irtf-panrg-questions/ <https://datatracker.ietf.org/doc/draft-irtf-panrg-questions/>. So we discussed adding normative references to both https://datatracker.ietf.org/doc/draft-irtf-panrg-what-not-to-do/ <https://datatracker.ietf.org/doc/draft-irtf-panrg-what-not-to-do/> and https://datatracker.ietf.org/doc/draft-irtf-panrg-questions/ <https://datatracker.ietf.org/doc/draft-irtf-panrg-questions/>, which was one way of resolving the comment, at the cost of holding both drafts in MISS-REF until https://datatracker.ietf.org/doc/draft-irtf-panrg-path-properties/ <https://datatracker.ietf.org/doc/draft-irtf-panrg-path-properties/> was also completed. 
> 
>  
> 
> So my understanding (and Brian can correct me) is that the changes between -07 and -09 in Section 1.1 are responsive to Adrian's comment. See https://www.ietf.org/rfcdiff?url2=draft-irtf-panrg-questions-09.txt&url1=draft-irtf-panrg-questions-07.txt <https://www.ietf.org/rfcdiff?url2=draft-irtf-panrg-questions-09.txt&url1=draft-irtf-panrg-questions-07.txt>.
> 
>  
> 
> how you get from one host to another (which is mostly the way PANRG people have thought about paths, as best I can tell), OR
> how you get from the edge router next to one host to either the edge router next to the other host or the router next to the "next network on the way to the other host", OR
> how you get from one core router to another core router, OR
> how you get from one physical layer box to another physical layer box, OR 
> well, it's just turtles all the way down.