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

["Brian Trammell (IETF)" <[e-mail]>]

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 
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