[P2PSIP] Barry Leiba's No Objection on draft-ietf-p2psip-diagnostics-19: (with COMMENT)

["Barry Leiba" <[e-mail]>]

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

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/



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

For Sections 9.1 and 9.2, I wish there had been some working group
discussion that resulted in the decision to make the registry policies
Standards Action.  It seems that 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) would work OK for this registry, and I
would have liked the working group to have actively considered that.  But
that ship has sailed for this document and this working group, and it's
not likely to box us in for this case, so this is now a non-blocking
comment.  Thanks for the discussion we've had on this point.

In addition to what Ben has already said...

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.  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 this has been
resolved, so the disclaimer should be removed when the draft is updated.

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.