Barry, Does Haibin’s answer clear up your concern?
Thanks, Alissa > On Dec 30, 2015, at 1:20 AM, Songhaibin (A) <[email protected]> wrote: > > 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
