Re: [PANRG] RG Last Call for draft-irtf-panrg-questions

[Spencer Dawkins at IETF <[e-mail]>]

Hi, Brian,

One nit ...

On Thu, Aug 13, 2020 at 3:47 PM Brian Trammell (IETF) <[e-mail]>
wrote:

> hi Med,
>
> (as individual, author of the questions draft)
>
> Apologies for the mix-up here; I thought I'd already addressed these in
> -02 (
> https://github.com/panrg/questions/commit/9c375169f15d36d80f9f865cf4bea999dd240199#diff-ac1187308763948092e6518e3ddeba00)...
> Took another look and it turns out I had apparently addressed an earlier
> set of comments, and mistaken these for those. Sorry about that! So: thanks
> for the detailed comments.
>
> Note in the message below, [MedXX] refers to the Microsoft Word comment
> label in the PDF you sent.
>
> Reviewing these, there are a few more changes to the document accepted or
> addressed without comment, thanks for these [Med5, Med7, Med11, Med14,
> Med16, Med27, Med29, Med36, Med38, Med45] -- they'll appear in a future
> revision collecting all LC feedback Real Soon Now (pull request is here:
> https://github.com/panrg/questions/pull/9, will merge shortly)
>
> There are also comments to which I guess I would generally agree, but for
> which no edit is necessary IMO, usually because the resulting edit would be
> at a level of detail not appropriate in the context of the rest of the
> document [Med9, Med21, Med22, Med23]
>
> Editorial comments which I considered, but won't make an edit, largely for
> stylistic and/or document consistency reasons [Med26, Med35, Med43]
>
> And comments I acknowledge, but can't figure out a useful to action to
> take in response to [Med10, Med30, Med34, Med40, Med41, Med44]
>
> Responses to the remaining comments appear below:
>
> Abstract edits: An endpoint may comprise an application in this view, so
> I'm not inclined to accept these.
>
> [Med1, Med2] question terms used in the RG charter, so I'm not sure
> whether it's appropriate to consider a reframing of them in this document.
>
> [Med3] questions why "Internet" is important here; see paragraph 4 of the
> introduction as to why we made this distinction in the chartering of the RG.
>
> [Med4] speculates as to the answerability of Question 3 in a restricted
> context ("strict source routing", which is a highly restricted subset of
> path selection), so I'm not sure what the action on the document should be
> here.
>
> [Med6] in this RG, and in this document, we are concerned primarily with
> the characteristics of the path; "service" is a highly overloaded term but
> in the context of the quoted RFCs what I think you mean "on-path packet
> manipulations", which are indeed path characteristics.
>
> [Med8] this document does not presuppose definition of path details,
> that's what the path properties draft is for.
>
> [Med13] You're right, working out how to do this in a multicast context
> would be interesting, however, that is not the scope of this document (that
> would indeed be too ambitious at this time IMO).
>
> [Med15] I've cited 7624 for the problem statement; this is but one
> example, and after all, it is research
>
> [Med17] hands these tools to network operators; PAN seeks to hand
> equivalent tools to the endpoints.
>
> [Med18, Med25] I would call the nouns in a data model the vocabulary, and
> this really is about the nouns.
>
> [Med19] is addressed in section 2.7
>
> [Med20] is addressed in section 2.8 (or rather, must be addressed by any
> answer to 2.8)
>
> [Med31] the difference here is intentional: it's interfaces to transport
> and application that are important, because that's how path properties and
> selection actually get used.
>
> [Med32] hm, "for some definition of path" is indeed doing a lot of work in
> this sentence; changed the paragraph to "In the current Internet, the basic
> assumption that at a given time all
> traffic for a given flow will receive the same network treatment and
> traverse
> the same path or equivalend paths often holds. In a path aware network,
> this assumption is more easily violated holds. The weakening of this
> assumption
>

Is this "holds" extraneous? I think the sentence should end with
"violated", no?

Best,

Spencer


> has implications for the design of protocols above any path-aware network
> layer."
>
> [Med33] raises an interesting point that points toward potential answers
> to sections 2.7/2.8... how and whether gatewaying interacts with a PAN.
> Indeed, a student of mine who was working on PAN stuff a couple of years
> ago built a proof of concept PAN based around linking access network egress
> interfaces to bits in the v6 source address. I think this probably belongs
> in the domain of "answers" rather than "questions", though.
>
> [Med37] Or paths that exist outside the space of Gao-Rexford policies, or
> that exist due to what Geoff Huston refers to as "senseless routing
> vandalism", or for other reasons, yes. AIUI many networks do actually
> connect to each other at multiple interconnection points, so I think it's
> safe to assume available physical interconnection is richer than a
> simplified model provided by the BGP AS adjacency graph.
>
> [Med42] The path aware architecture with which I am most familiar, and
> which has seen the most actual deployment AFAIK, is SCION, which does
> indeed pre-establish paths to select from (though these are not committed:
> they represent possibilities, not circuits).
>
> Thanks, cheers,
>
> Brian
>
> > On 21 Jul 2020, at 14:05, [e-mail] wrote:
> >
> > Hi Jen,
> >
> > Please see inline.
> >
> > Cheers,
> > Med
> >
> >> -----Message d'origine-----
> >> De : Panrg [mailto:[e-mail]] De la part de Jen
> >> Linkova
> >> Envoyé : mardi 21 juillet 2020 05:13
> >> À : BOUCADAIR Mohamed TGI/OLN <[e-mail]>
> >> Cc : [e-mail]; [e-mail]
> >> Objet : Re: [PANRG] RG Last Call for draft-irtf-panrg-questions
> >>
> >> Hi Med,
> >>
> >> On Sat, Jul 11, 2020 at 3:07 AM <[e-mail]>
> >> wrote:
> >>> I re-read this draft but I fail to see a value in publishing it
> >> as an RFC. The document can serve as an internal document for the
> >> RG to drive the work but no more than that.
> >>
> >> My recollection of discussions we have had during the last few
> >> meetings is that some people do see value in publishing it while
> >> some don't.
> >> So let me ask you this: while you do not see value in publishing
> >> it, would you strongly object to it?
> >
> > [Med] I would not object if at least comments that were raised were
> discussed, but unfortunately many comments raised since 04/2019 are still
> open including basic things such as normative references. See the full
> list:
> https://github.com/boucadair/IETF-Drafts-Reviews/blob/master/draft-irtf-panrg-questions-01-rev%20Med.pdf.
>
> >
> >> IMHO one of the benefits of having it published include but are
> >> not limited to:
> >> - the group and the author do not need to keep refreshing it
> >> unnecessary;
> >> - it could be referenced by other documents;
> >> - the status is more clear for an outside reader.
> >
> > [Med] All this is possible with an RG adopted draft or even a charter.
> Please note that the document falls under the category in this statement:
> https://www.ietf.org/about/groups/iesg/statements/support-documents/ (I
> know, that's an IESG statement).
> >
> >>
> >> If anyone feels strongly about either of the options please speak
> >> up.
> >>
> >>> FWIW, some comments on the first three pages of the draft can be
> >> seen at:
> >>> https://github.com/boucadair/IETF-Drafts-
> >> Reviews/blob/master/draft-irt
> >>> f-panrg-questions-05-rev%20Med.pdf
> >>
> >> Thanks for reviewing!
> >> As the Datatracker is locked, I'd not expect the updated version
> >> until next week at least.
> >>
> >>
> >>>> -----Message d'origine-----
> >>>> De : Panrg [mailto:[e-mail]] De la part de Jen
> >> Linkova
> >>>> Envoyé : mercredi 1 juillet 2020 03:54 À : [e-mail] Cc :
> >>>> [e-mail]
> >>>> Objet : [PANRG] RG Last Call for draft-irtf-panrg-questions
> >>>>
> >>>> This email starts a RG Last Call for draft-irtf-panrg-
> >> questions
> >>>> https://datatracker.ietf.org/doc/draft-irtf-panrg-questions/
> >>>>
> >>>> The Last Call ends on Wed, July 15th, 23:59:59 UTC.
> >>>>
> >>>> Thanks!
> >>>>
> >>>> --
> >>>> SY, Jen Linkova aka Furry
> >>>>
> >>>> _______________________________________________
> >>>> Panrg mailing list
> >>>> [e-mail]
> >>>> https://www.irtf.org/mailman/listinfo/panrg
> >>>
> >>>
> >> __________________________________________________________________
> >> ____
> >>> ___________________________________________________
> >>>
> >>> Ce message et ses pieces jointes peuvent contenir des
> >> informations
> >>> confidentielles ou privilegiees et ne doivent donc pas etre
> >> diffuses,
> >>> exploites ou copies sans autorisation. Si vous avez recu ce
> >> message
> >>> par erreur, veuillez le signaler a l'expediteur et le detruire
> >> ainsi que les pieces jointes. Les messages electroniques etant
> >> susceptibles d'alteration, Orange decline toute responsabilite si
> >> ce message a ete altere, deforme ou falsifie. Merci.
> >>>
> >>> This message and its attachments may contain confidential or
> >>> privileged information that may be protected by law; they should
> >> not be distributed, used or copied without authorisation.
> >>> If you have received this email in error, please notify the
> >> sender and delete this message and its attachments.
> >>> As emails may be altered, Orange is not liable for messages that
> >> have been modified, changed or falsified.
> >>> Thank you.
> >>>
> >>
> >>
> >> --
> >> SY, Jen Linkova aka Furry
> >>
> >> _______________________________________________
> >> Panrg mailing list
> >> [e-mail]
> >> https://www.irtf.org/mailman/listinfo/panrg
> >
> >
> _________________________________________________________________________________________________________________________
> >
> > Ce message et ses pieces jointes peuvent contenir des informations
> confidentielles ou privilegiees et ne doivent donc
> > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez
> recu ce message par erreur, veuillez le signaler
> > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages
> electroniques etant susceptibles d'alteration,
> > Orange decline toute responsabilite si ce message a ete altere, deforme
> ou falsifie. Merci.
> >
> > This message and its attachments may contain confidential or privileged
> information that may be protected by law;
> > they should not be distributed, used or copied without authorisation.
> > If you have received this email in error, please notify the sender and
> delete this message and its attachments.
> > As emails may be altered, Orange is not liable for messages that have
> been modified, changed or falsified.
> > Thank you.
> >
> > _______________________________________________
> > Panrg mailing list
> > [e-mail]
> > https://www.irtf.org/mailman/listinfo/panrg
>
> _______________________________________________
> Panrg mailing list
> [e-mail]
> https://www.irtf.org/mailman/listinfo/panrg
>