Re: [PANRG] Dependence on https://datatracker.ietf.org/doc/draft-irtf-panrg-path-properties/

hi Spencer,

(and hi Adrian, this message touches on peripheral questions in your message last week, though I'll answer the actual questions in another thread, hopefully today but I'm not optimistic about cycles)

<chair hat off, -questions editor hat on>

When I originally proposed/wrote the questions draft, I meant the title of the document to be taken literally: "we don't quite yet know what we are doing, we're informed by kinda-related work in a few inter-network and intra-network architectures, let's figure out whether there is a here here". So from that originalist viewpoint, references to -questions are fine, but not if those references are there because -questions has answers.

Scoping the work in the RG such that even knowing what we're talking about requires the questions draft to define "path-aware networking", which it now does in section 1.1. Aside to Adrian's main point, he points out that that definition itself uses the word "path", which is also quite overloaded depending on your viewpoint. 

So my original desire to leave "path" explicitly undefined in -questions (indeed, question 1 in section 2.1 is "what is a path" with more words) is probably not going to fly.

<-questions editor hat off, chair hat on>

As co-chair, I do prefer not to have all three of the documents depend on each other in a cluster. I'm not sure where we are with the completion of the path properties draft, though I suspect there remains much more to talk about than with questions and what-not-to-do. 

What we care about, though, for the document dependency graph is merely the definition of path. The current state of the definition of path in path properties is as follows:

>    Path:  A sequence of adjacent path elements over which a packet can
>       be transmitted, starting and ending with a node.  A path is
>       unidirectional.  Paths are time-dependent, i.e., the sequence of
>       path elements over which packets are sent from one node to another
>       may change.  A path is defined between two nodes.  For multicast
>       or broadcast, a packet may be sent by one node and received by
>       multiple nodes.  In this case, the packet is sent over multiple
>       paths at once, one path for each combination of sending and
>       receiving node; these paths do not have to be disjoint.  Note that
>       an entity may have only partial visibility of the path elements
>       that comprise a path and visibility may change over time.
>       Different entities may have different visibility of a path and/or
>       treat path elements at different levels of abstraction.  For
>       example, a path may be given as a sequence of physical nodes and
>       the links connecting these nodes, or it may be given as a sequence
>       of logical nodes such as a sequence of ASes or an Explicit Route
>       Object (ERO).  Similarly, the representation of a path and its
>       properties, as it is known to a specific entity, may be more
>       complex and include details about the physical layer technology,
>       or it may be more abstract and only consist of a specific source
>       and destination which is known to be reachable from that source.

This is precise, but not succinct; this looks like a definition we need to talk about some more. However, I suspect that we as an RG would endorse the essence of the definition, something like:

"Path:  A unidirectional sequence of nodes and links over which a packet can be transmitted, such that nodes represent devices which process packets at some layer(s), and links connect the nodes."

and that we could lift this into Section 1.1 of -questions.

Thoughts?

Cheers,

Brian

> On 8 Feb 2021, at 02:33, Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com> wrote:
> 
> Hi, Brian and Jen, 
> 
> I apologize for causing confusion, but between the insertion of explanations of "Path" and "Path Aware" in https://datatracker.ietf.org/doc/draft-irtf-panrg-what-not-to-do/, it looks like I now have a dependency on both https://datatracker.ietf.org/doc/draft-irtf-panrg-questions/  (for "Path Aware") and https://datatracker.ietf.org/doc/draft-irtf-panrg-path-properties/ (for "Path"). 
> 
> The dependence on https://datatracker.ietf.org/doc/draft-irtf-panrg-questions/ seems like no problem, because it's also in the publication process. 
> 
> The dependence on https://datatracker.ietf.org/doc/draft-irtf-panrg-path-properties/ is a bit more problematic, because that draft is still in the RG.
> 
> So, two questions.
> 	• Do we have any thoughts about when we're likely to request publication on https://datatracker.ietf.org/doc/draft-irtf-panrg-path-properties/?
> 	• Assuming that the answer is "not very soon", I note in the current text in https://github.com/panrg/draft-dawkins-panrg-what-not-to-do/commit/c9e40e60e854b19bf9acee0be31120f438226ac0 hasically says "here's the definitions of 'Path' and 'Path Aware' that the RG is using, but all of the contributions contained in this draft predate the formation of PANRG, so may not reflect the descriptions in the drafts where those terms are defined". How wrong would it be to make that clearer in the next version of the draft, so that there isn't a dependency on https://datatracker.ietf.org/doc/draft-irtf-panrg-path-properties/?
> I'd like to do the right thing, but I was included in the recent "AUTH48" for cluster 248 with the RFC Editor, so I'd love to not delay publication unless there's a really compelling reason to do that ... 
> 
> Please advise, of course. 
> 
> Best,
> 
> Spencer
> _______________________________________________
> Panrg mailing list
> Panrg@irtf.org
> https://www.irtf.org/mailman/listinfo/panrg