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