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. _______________________________________________ P2PSIP mailing list [email protected] https://www.ietf.org/mailman/listinfo/p2psip
