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

From: Spencer Dawkins at IETF <[email-masked]>
Date: Wed, 1 Jul 2020 12:41:51 -0500

Dear PANRG, but especially Brian,

On Tue, Jun 30, 2020 at 8:54 PM Jen Linkova <[email-masked]> wrote:

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

This version of the draft contains the definition of "path awareness" that
we agreed on, which is perfect, but it's at the bottom of the second page
of the Introduction. Could you add a subsection heading so that other
drafts can point directly to it?

Thanks!

Best,

Spencer

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Thu, 2 Jul 2020 10:31:34 -0500

Just following up on this:

> drafts can point directly to it?

I've made the change to the what-not-to-do draft in
https://github.com/panrg/draft-dawkins-panrg-what-not-to-do/pull/3,
pointing to -questions for the defintion. It includes a note about the
location of the definition I requested as well, which would change the
what-not-to-do draft if it happens.

Comments on that PR are, of course, welcomed.

Best,

Spencer

---

From: Theresa Enghardt <[email-masked]>
Date: Sun, 5 Jul 2020 16:54:28 -0700

Dear PANRG,

I just read this document again and I think it's ready for publication.

In fact, I think this document nicely captures the key questions that
we're working on in PANRG, and I expect this to be interesting to people
outside of PANRG as well, so it really should be published.

Just a couple of nits that I found:

- Typo in abstract: "intetnetworks"

- Normative vs informative references: It's not clear to me why RFC 4302
(IP Authentication Header) and RFC 5246 (TLS 1.2) are Normative, while
RFC 7624 (on Passive Surveillance) and RFC 8170 (on Protocol Adoption
and Transition) are Informative. Maybe all of these should be Informative.

- For TLS, perhaps the reference should be updated to TLS 1.3.

Finally, one suggested addition:

Section 2.3, "Supporting Path Selection", states that "Path selection
   must, like path property information, be trustworthy, such that the
   result of a path selection at an endpoint is predictable."

I think it might be worth noting that results should not only be
predictable, but should also result in an outcome that is "better than
the default" or "better than random". Maybe surprisingly, this is not
trivial, as we also noted the Path Properties draft (Section 3.1) after
somebody (I forget who) brought up this point in a PANRG session.

I suggest to add something like the following phrase:

"Moreover, any path selection mechanism should aim to provide an outcome
that is not worse than using a single path, or selecting paths at
random, e.g., in terms of performance."

Best,
Theresa

---

From: <[email-masked]>
Date: Fri, 10 Jul 2020 17:07:44 +0000

Hi Jen, all,

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. 

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-irtf-panrg-questions-05-rev%20Med.pdf 

Cheers,
Med

> -----Message d'origine-----
> De : Panrg [mailto:[email-masked]] De la part de Jen
> Linkova
> Envoyé : mercredi 1 juillet 2020 03:54
> À : [email-masked]
> Cc : [email-masked]
> Objet : [PANRG] RG Last Call for draft-irtf-panrg-questions
> 
> --
> SY, Jen Linkova aka Furry
> 
> _______________________________________________
> Panrg mailing list
> [email-masked]
> 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.

---

From: Jen Linkova <[email-masked]>
Date: Tue, 21 Jul 2020 13:13:22 +1000

Hi Med,

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

If anyone feels strongly about either of the options please speak up.

> https://github.com/boucadair/IETF-Drafts-Reviews/blob/master/draft-irtf-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.