Dear Alissa and all, I did the editing job and have submitted a new version of the document according to the comments received and the discussion in the list. I also add some text in the change history appendix for it. Please check if the updated version has addressed your comments.
https://tools.ietf.org/html/draft-ietf-p2psip-diagnostics-20 I keep the intended status of the document as it is. Alvaro thought Experimental might be a better status, when I check the change history in the document, as it is defined as a mandatory RELOAD extension, the current intended status seems suitable. Otherwise we need go through another WGLC to change the intended status. "C.7. Changes in version -10 Resolve the authorization issue and other comments (e.g. define diagnostics as a mandatory extension) from WGLC. And check for the languages. " Best Regards! -Haibin > -----Original Message----- > From: Alissa Cooper [mailto:[email protected]] > Sent: Saturday, January 30, 2016 3:13 AM > To: Barry Leiba > Cc: IESG; Roni Even; [email protected]; > [email protected]; [email protected]; Songhaibin (A) > Subject: Re: [P2PSIP] Barry Leiba's Discuss on > draft-ietf-p2psip-diagnostics-19: > (with DISCUSS and COMMENT) > > I looked through the mailing list archives and the meeting minutes from the > meetings around the time when the registration policy was added to the > document (the -01). I did not see any discussion of the registration policy. > > I fully agree with Haibin’s analysis, though, which is that the potential for > introducing sensitive diagnostic types (e.g., location) is sufficient to make > Standards Action or IETF Review a good choice. These should get IETF-wide > security review before being added to the registries. > > Alissa > > > On Jan 28, 2016, at 1:47 PM, Barry Leiba <[email protected]> wrote: > > > >> Does Haibin’s answer clear up your concern? > > > > Sorry, it must have gotten lost in the end-of-year mess. > > > > No, it doesn't: Haibin gives his thoughts on the question, but I asked > > about what discussion the working group had in coming to the decision. > > Further comment: > > > >>> 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). > > > > Yes, "Specification Required" allows non-RFC specifications, with a > > designated expert to review the request and sanity-check it. Why does > > the working group think this registry needs only Standards Track RFCs > > to make registrations? Why can't IETF consensus approve a > > non-Standards-Track RFC (as with "IETF Review")? Why couldn't a > > designated expert handle the review, consulting with whatever > > appropriate working group(s) exist at the time (as with "Specification > > Required")? > > > > I'm honest OK with Standards Action if that's really what the working > > group wants, and they have a reasonable explanation for why that's > > necessary here. I'm asking because I can't see any evidence that it > > was actually discussed, and I'm concerned that we consistently use > > too-strict registration policies because we think they're necessary, > > and that often bites us later on, when we wish we hadn't been so > > strict. > > > > Can you point me at any messages or minutes that show the working > > group discussion about the registration policy? Can the working group > > explain what harm could be caused if registrations were allowed to be > > made without Standards Track RFCs? > > > > Barry _______________________________________________ P2PSIP mailing list [email protected] https://www.ietf.org/mailman/listinfo/p2psip
