Dear Barry, See my reply in line. And copy Roni's new email address (as the author's email address has been updated).
> -----Original Message----- > From: P2PSIP [mailto:[email protected]] On Behalf Of Barry Leiba > Sent: Wednesday, December 16, 2015 12:18 PM > To: The IESG > Cc: [email protected]; [email protected]; > [email protected] > Subject: [P2PSIP] Barry Leiba's Discuss on draft-ietf-p2psip-diagnostics-19: > (with DISCUSS and COMMENT) > > 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? > 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). > 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 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. > 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. 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. > > 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. We will revise the section and be carefully with those words in IANA section in future documents:) BR, -Haibin Song > > _______________________________________________ > P2PSIP mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/p2psip _______________________________________________ P2PSIP mailing list [email protected] https://www.ietf.org/mailman/listinfo/p2psip
