Re: [P2PSIP] Ben Campbell's No Objection on draft-ietf-p2psip-diagnostics-19: (with COMMENT)

["Songhaibin (A)" <[e-mail]>]

Thank you, Ben,

Sorry for the late reply due to the business trip recently.

> -----Original Message-----
> From: Ben Campbell [mailto:[e-mail]]
> Sent: Wednesday, December 16, 2015 9:38 AM
> To: The IESG
> Cc: [e-mail]; [e-mail];
> [e-mail]; [e-mail]
> Subject: Ben Campbell's No Objection on draft-ietf-p2psip-diagnostics-19: (with
> COMMENT)
> 
> Ben Campbell has entered the following ballot position for
> draft-ietf-p2psip-diagnostics-19: No Objection
> 
> 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/
> 
> 
> 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> General comments:
> 
> The draft styles itself as P2PSIP diagnostics. But P2PSIP is a usage of RELOAD,
> and the draft mentions it is generally applicable to RELOAD. This is misleading,
> and might artificially limit it's applicability.  Perhaps this should be called
> RELOAD diagnostics? Or if it is really specific to P2PSIP, that should be clarified.
> 

There was discussion on this, and the result was to make it general P2P overlay diagnostics, that's why the title had been changed from "P2PSIP..." to "P2P Overlay...", and I guess the title is not misleading. The authors removed a lot of terminologies related to P2PSIP to make it general, but still left some ambiguity terms inside. And you are right, we will revise the draft and eliminate inappropriate "P2PSIP" sentences to make it clean.

> The headers show that this draft updates RFC 6940. As far as I can tell, it
> extends 6940 along defined extension points. If so, that's not really an update.
> (Also, the shepherd write up says it does not update
> anything.)

I'm not sure, but we can discuss, there was a request to change it to "update". This document makes extensions to the RELOAD Ping message and defines a new message Path_Track. IMHO, "extension" might be better. Any thought?

> 
> Specific comments:
> 
> - 4.1, 2nd to last paragraph: "The default policy or access rule for a type of
> diagnostic information is "permit" unless specified in the diagnostics extension
> document."
> 
> Can you elaborate on this? I assume "diagnostic extension document"
> refers to a spec that registers something in one of the new registries defined
> herein?  How does a policy of "permit" interact with the authorization
> requirements and security considerations elsewhere in the draft?
> 

There is a mistake in the referred sentence. As it is said in Section 5.3, " Access to each kind of diagnostic information MUST NOT be allowed unless compliant to the rules defined in Section 7." So the actual default access rule is "deny" instead of "permit". The sentence should be changed to " The default policy or access rule for a type of diagnostic information is "deny" unless specified in the overlay configuration file."


> -6.2:
> The section has lots of SHOULDs, where the reasons they are not MUSTs are
> not obvious. Please offer reasons why an implementation might choose not to
> follow the SHOULD.

I would like to change them to "MUST"s.

> 
> - 6.4, first and last paragraphs:
> The MAYs seems like a statements of fact rather than normative requirements.

I agree. So we will change them from "MAY" to "may".

> 
> -6.4, 2nd paragraph:
> Does this document have requirements for clock resolution or skew? (It seems
> odd to mention the NTP capabilities unless they matter.)
> 

It has requirement for time synchronization and leaves clock resolution or skew to implementation. NTP is just for reference (one example method for time synchronization).

> 9.1 (and others in the IANA section)
> 
> Where should these new registries be created? (I imagine IANA can figure it
> out, but it's best to be explicit.)
> 

Shall we mention that they are created under the protocol RELOAD? If that is necessary, I can add a little text for that.


> Editorial:
> 
> - 4.1, 2nd paragraph:
> OLD:
> Essentially, this document reuses RELOAD [RFC6940] specification and extends
> them to introduce the new diagnostics methods.
> NEW:
> Essentially, this document reuses the RELOAD [RFC6940] specification and
> extends it to introduce the new diagnostics methods.
> END.
> 

Thank you very much for the comments, please check if the above answers your questions.

BR,
-Haibin Song