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

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

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:[e-mail]]
> Sent: Saturday, January 30, 2016 3:13 AM
> To: Barry Leiba
> Cc: IESG; Roni Even; [e-mail];
> [e-mail]; [e-mail]; 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 <[e-mail]> 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