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

[Alissa Cooper <[e-mail]>]

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 <[e-mail]> wrote:
> 
> 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.
> 
>