Dear Ben No problem, we will also update with Roni's new email address.
BR, -Haibin Song > -----Original Message----- > From: Ben Campbell [mailto:[email protected]] > Sent: Wednesday, December 16, 2015 11:00 AM > To: The IESG > Cc: [email protected]; [email protected]; > [email protected]; [email protected]; Roni Even > Subject: Re: Ben Campbell's No Objection on draft-ietf-p2psip-diagnostics-19: > (with COMMENT) > > BTW, I think the draft has the wrong address for Roni. > [email protected] bounces. > > On 15 Dec 2015, at 19:38, Ben Campbell wrote: > > > 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. > > > > 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.) > > > > 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? > > > > -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. > > > > - 6.4, first and last paragraphs: > > The MAYs seems like a statements of fact rather than normative > > requirements. > > > > -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.) > > > > 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.) > > > > 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. _______________________________________________ P2PSIP mailing list [email protected] https://www.ietf.org/mailman/listinfo/p2psip
