Subject: [P2PSIP] Barry Leiba's Discuss on draft-ietf-p2psip-diagnostics-19: (with DISCUSS and COMMENT)

From: "Barry Leiba" <[email-masked]>
Date: Tue, 15 Dec 2015 20:18:27 -0800

Barry Leiba has entered the following ballot position for
draft-ietf-p2psip-diagnostics-19: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-p2psip-diagnostics/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

For Sections 9.1 and 9.2, I would like to see some evidence of discussion
that resulted in the decision to make the registry policies Standards
Action.  Did the working group actually discuss this and make a decision
that Standards Action is right?  What's the reasoning for not using some
softer policy, such as "IETF Review" (which might allow for registrations
from Experimental documents) or Specification Required (which would allow
review by a designated expert of a non-RFC specification)?  Why is
Standards Action the right thing?

Important note on the previous comment: Please don't just change this:
talk with me.  I'm actually asking a question, and it might well be that
Standards Action is right.  I want to hear the answer and have a
discussion about it.

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

In addition to what Ben has already said...

>From the shepherd writeup:

"The normal WG process was followed and the document has been discussed
for
several years. The document as it is now, reflects WG consensus, with
nothing
special worth noting."

Is it really the case that with *several years* of discussion there's
*nothing* worth pointing out as something that generated discussion? 
What were those several years spent on?

"A review of Section 9.6 was requested to the APPS area and the authors
considered the received feedback."

Similarly: was there nothing about the feedback that was worth
mentioning?  I'm glad the authors considered it... it would have been
good to say "the feedback was only on minor points," or to say what
review brought up.

"The idnits tool returns 5 warnings and 1 comment. They do not seem to be
a
problem."

Well, one of the things that idnits calls out is this:
  -- The draft header indicates that this document updates RFC6940, but
the
     abstract doesn't seem to mention this, which it should.

I believe it's not a problem that the abstract doesn't mention it, but
one *reason* the abstract doesn't mention it is that the rest of the
document doesn't mention it either.  It's not at all clear WHY this
document updates 6940, and that *is* a problem.  Why?  (This is in
support of Ben's comment, as well as being a question to the shepherd.)

The idnits tool also mentions the pre-5378 disclaimer, and the shepherd
writeup has no information about why the disclaimer is needed.  What text
is in this document that is not subject to the IETF Trust terms from BCP
78, and why is it not?  I think this needs an explanation.

I strongly agree with Ben's comment about needing explanations for a
number of SHOULDs (and SHOULD NOTs) in the document.  RFC 2119 says that
for SHOULD, "the full implications must be understood and carefully
weighed before choosing a different course."  Without any explanation,
there's no way for implementors to understand the implications and to
weigh anything, and I tripped over that quite a number of times during my
review.

I agree with Spencer's comment that we don't usually strong-arm IANA with
2119 key words.  It's a small point, and I don't think IANA are easily
offended [ :-) ], but "IANA is asked to create" is a better approach than
"IANA SHALL create", and so on.

---

From: Alissa Cooper <[email-masked]>
Date: Wed, 16 Dec 2015 15:09:24 -0500

Hi Barry,

A little context about this document might be useful here. The original version dates back to 2007 when there was a larger pool of people interested in the p2psip work than there have been any time in the last several years. A valiant few have carried this work forward but it’s possible that folks’ memory of specific discussion about the IANA registration policies may be fuzzy or may require digging through long-ago mailing list archives. That’s also why the write-up mentions “years” of discussion, because while the document has been around for a long time, discussion has waxed and waned. The document’s age is also the reason for the pre-5378 disclaimer.

Authors should chime in on the substance but wanted the background to be clear.

Alissa

> On Dec 15, 2015, at 11:18 PM, Barry Leiba <[email-masked]> wrote:
>

---

From: Barry Leiba <[email-masked]>
Date: Wed, 16 Dec 2015 15:56:27 -0500

> A little context about this document might be useful here.

Yes, and thanks!

> The document’s age is also the reason for the pre-5378 disclaimer.

I've checked the history of the pre-working-group draft, and I see
that Zheng Hewen (Huawei Nanjing) is the only early author whose name
is not on a post-5378 version.  If he is, indeed, not contactable,
then the pre-5378 disclaimer is needed.  But if Hewen can be contacted
and can agree to the 5378 terms, we could get rid of the disclaimer.

I presume we're not able to contact him now, and that the disclaimer
is needed.  Ah, well.

Barry

---

From: Carlos Jesús Bernardos Cano <[email-masked]>
Date: Wed, 16 Dec 2015 22:09:46 +0100

Hi Barry,

As document shepherd, I can also try to answer some of your comments:

- On the "several years of discussion" comment, well, I just agree on
what Alissa already said.

- On the APPS area review, I could have been more specific (sorry).
There was not really any big issue and the authors did take care of
addressing the received comments.

Thanks,

Carlos

---

From: "Songhaibin (A)" <[email-masked]>
Date: Wed, 23 Dec 2015 08:42:17 +0000

Yes. That's the problem. But I can still contact with Hewen. Do we need an oral agreement or the written agreement from him? If it is just an oral agreement. I can do it quickly and change the disclaimer when we revise the draft.

Best Regards!
-Haibin

> -----Original Message-----
> From: P2PSIP [mailto:[email-masked]] On Behalf Of Barry Leiba
> Sent: Thursday, December 17, 2015 4:56 AM
> To: Alissa Cooper
> Cc: [email-masked]; [email-masked]; IESG; p2psip
> Subject: Re: [P2PSIP] Barry Leiba's Discuss on draft-ietf-p2psip-diagnostics-19:
> (with DISCUSS and COMMENT)
> 
> I've checked the history of the pre-working-group draft, and I see that Zheng
> Hewen (Huawei Nanjing) is the only early author whose name is not on a
> post-5378 version.  If he is, indeed, not contactable, then the pre-5378
> disclaimer is needed.  But if Hewen can be contacted and can agree to the
> 5378 terms, we could get rid of the disclaimer.
> 
> I presume we're not able to contact him now, and that the disclaimer is needed.
> Ah, well.
> 
> Barry
> 
> _______________________________________________
> P2PSIP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/p2psip

---

From: Barry Leiba <[email-masked]>
Date: Wed, 23 Dec 2015 09:54:33 -0500

> Yes. That's the problem. But I can still contact with Hewen. Do we
> need an oral agreement or the written agreement from him? If it is
> just an oral agreement. I can do it quickly and change the disclaimer
> when we revise the draft.
>
> Best Regards!
> -Haibin

It would be good to have email on record (a post to the mailing list),
just in case, but oral will work -- you could post a note about what
he said to you by telephone or in person.

Barry

---

From: "Songhaibin (A)" <[email-masked]>
Date: Wed, 30 Dec 2015 09:18:00 +0000

Dear Barry,

See my reply in line.

> Sent: Wednesday, December 16, 2015 12:18 PM
> To: The IESG
> Cc: [email-masked]; [email-masked];
> [email-masked]
> Subject: [P2PSIP] Barry Leiba's Discuss on draft-ietf-p2psip-diagnostics-19:
> When responding, please keep the subject line intact and reply to all email
> addresses included in the To and CC lines. (Feel free to cut this introductory
> paragraph, however.)
> 
> 
> For Sections 9.1 and 9.2, I would like to see some evidence of discussion that
> resulted in the decision to make the registry policies Standards Action.  Did
> the working group actually discuss this and make a decision that Standards
> Action is right?  What's the reasoning for not using some softer policy, such as
> "IETF Review" (which might allow for registrations from Experimental
> documents) or Specification Required (which would allow review by a
> designated expert of a non-RFC specification)?  Why is Standards Action the
> right thing?
> 
The thought was that if a new value would be used for experimental purpose, then there are reserved values accordingly for overlay local use. And then if people want that value can be used across different RELOAD overlays, then they'd better need a standard track document to define it (that's why we assume it would be standard track). "Specification Required" allows non-RFC specifications, not sure that would reflect the IETF consensus (certain concerns might exist about certain kinds of diagnostic information). 

> Standards Action is right.  I want to hear the answer and have a discussion
> about it.
> 
> for several years. The document as it is now, reflects WG consensus, with
> nothing special worth noting."
> 
> Similarly: was there nothing about the feedback that was worth mentioning?
> I'm glad the authors considered it... it would have been good to say "the
> feedback was only on minor points," or to say what review brought up.
> 
> "The idnits tool returns 5 warnings and 1 comment. They do not seem to be a
> problem."
> 
>   -- The draft header indicates that this document updates RFC6940, but the
> I believe it's not a problem that the abstract doesn't mention it, but one
> *reason* the abstract doesn't mention it is that the rest of the document
> doesn't mention it either.  It's not at all clear WHY this document updates
> 6940, and that *is* a problem.  Why?  (This is in support of Ben's comment,
> as well as being a question to the shepherd.)

The document says it extends one RFC 6940 message and defines one new RELOAD message. I'm not clear whether it is an update or not.

> writeup has no information about why the disclaimer is needed.  What text is
> in this document that is not subject to the IETF Trust terms from BCP 78, and
> why is it not?  I think this needs an explanation.

This has been resolved in another thread.

> I strongly agree with Ben's comment about needing explanations for a number
> of SHOULDs (and SHOULD NOTs) in the document.  RFC 2119 says that for
> SHOULD, "the full implications must be understood and carefully weighed
> before choosing a different course."  Without any explanation, there's no way
> for implementors to understand the implications and to weigh anything, and I
> tripped over that quite a number of times during my review.

It has been replied in another thread w.r.t. Ben's comments. And I agree that after carefully consideration, it's better to change them to "MUST"s.

> 2119 key words.  It's a small point, and I don't think IANA are easily offended
> [ :-) ], but "IANA is asked to create" is a better approach than "IANA SHALL
> create", and so on.

We will revise the section and be carefully with those words in IANA section in future documents:)

BR,
-Haibin Song

---

From: "Songhaibin (A)" <[email-masked]>
Date: Wed, 30 Dec 2015 09:20:26 +0000

Dear Barry,

See my reply in line. And copy Roni's new email address (as the author's email address has been updated).

> https://datatracker.ietf.org/doc/draft-ietf-p2psip-diagnostics/
The thought was that if a new value would be used for experimental purpose, then there are reserved values accordingly for overlay local use (0xF000-0xFFFE). And then if people want that value can be used across different RELOAD overlays, then they'd better need a standard track document to define it (that's why we assume it would be standard track). "Specification Required" allows non-RFC specifications, not sure that would reflect the IETF consensus (certain concerns might exist about certain kinds of diagnostic information). 

BR,
-Haibin Song