[P2PSIP] Ben Campbell's No Objection on

Songhaibin (A)

2015-12-23 07:49:51 UTC

Thank you, Ben,

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

-----Original Message-----
Sent: Wednesday, December 16, 2015 9:38 AM
To: The IESG
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.
https://datatracker.ietf.org/doc/draft-ietf-p2psip-diagnostics/
----------------------------------------------------------------------
----------------------------------------------------------------------
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?

- 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."

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.

The MAYs seems like a statements of fact rather than normative requirements.

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

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.

Essentially, this document reuses RELOAD [RFC6940] specification and extends
them to introduce the new diagnostics methods.
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