Re: [P2PSIP] Barry Leiba's Discuss on draft-ietf-p2psip-diagnostics-19: (with DISCUSS and COMMENT)

[Alissa Cooper <[e-mail]>]

Barry,

Does Haibin’s answer clear up your concern? 

Thanks,
Alissa

> On Dec 30, 2015, at 1:20 AM, Songhaibin (A) <[e-mail]> 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:[e-mail]] On Behalf Of Barry Leiba
>> Sent: Wednesday, December 16, 2015 12:18 PM
>> To: The IESG
>> Cc: [e-mail]; [e-mail];
>> [e-mail]
>> 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
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/p2psip
>