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

[Alissa Cooper <[e-mail]>]

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