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

[Barry Leiba <[e-mail]>]

On Fri, Jan 29, 2016 at 2:12 PM, Alissa Cooper <[e-mail]> wrote:
>
> 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.

I've also had some off-list discussion with Alissa, in which she adds
that new registrations aren't very likely, so the barrier probably
won't really matter.

So I'm going to accept this as sufficient discussion and will go clear
my DISCUSS now.  I think it's important that in future cases we urge
working groups to have explicit discussion of registration policies,
but I agree that it's not really the time to do that with this
document.

Thanks for the discussion we've had on it.

Barry

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