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

From: Alissa Cooper <[email-masked]>
Date: Thu, 28 Jan 2016 13:27:58 -0800

Barry,

Does Haibin’s answer clear up your concern? 

Thanks,
Alissa

> On Dec 30, 2015, at 1:20 AM, Songhaibin (A) <[email-masked]> wrote:
> 
> Dear Barry,
> 
> See my reply in line. And copy Roni's new email address (as the author's email address has been updated).
> 
>> -----Original Message-----
>> From: P2PSIP [mailto:[email-masked]] On Behalf Of Barry Leiba
>> Sent: Wednesday, December 16, 2015 12:18 PM
>> To: The IESG
>> Cc: [email-masked]; [email-masked];
>> [email-masked]
>> Subject: [P2PSIP] Barry Leiba's Discuss on draft-ietf-p2psip-diagnostics-19:
>> (with DISCUSS and COMMENT)
>> 
>> Barry Leiba has entered the following ballot position for
>> draft-ietf-p2psip-diagnostics-19: Discuss
>> 
>> 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/
>> 
>> 
>> 
>> ----------------------------------------------------------------------
>> DISCUSS:
>> ----------------------------------------------------------------------
>> 
>> 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). 
> 
>> Important note on the previous comment: Please don't just change this:
>> talk with me.  I'm actually asking a question, and it might well be that
>> Standards Action is right.  I want to hear the answer and have a discussion
>> about it.
>> 
>> ----------------------------------------------------------------------
>> COMMENT:
>> ----------------------------------------------------------------------
>> 
>> In addition to what Ben has already said...
>> 
>>> From the shepherd writeup:
>> 
>> "The normal WG process was followed and the document has been discussed
>> for several years. The document as it is now, reflects WG consensus, with
>> nothing special worth noting."
>> 
>> Is it really the case that with *several years* of discussion there's
>> *nothing* worth pointing out as something that generated discussion?
>> What were those several years spent on?
>> 
>> "A review of Section 9.6 was requested to the APPS area and the authors
>> considered the received feedback."
>> 
>> Similarly: was there nothing about the feedback that was worth mentioning?
>> I'm glad the authors considered it... it would have been good to say "the
>> feedback was only on minor points," or to say what review brought up.
>> 
>> "The idnits tool returns 5 warnings and 1 comment. They do not seem to be a
>> problem."
>> 
>> Well, one of the things that idnits calls out is this:
>>  -- The draft header indicates that this document updates RFC6940, but the
>>     abstract doesn't seem to mention this, which it should.
>> 
>> I believe it's not a problem that the abstract doesn't mention it, but one
>> *reason* the abstract doesn't mention it is that the rest of the document
>> doesn't mention it either.  It's not at all clear WHY this document updates
>> 6940, and that *is* a problem.  Why?  (This is in support of Ben's comment,
>> as well as being a question to the shepherd.)
> 
> The document says it extends one RFC 6940 message and defines one new RELOAD message. I'm not clear whether it is an update or not.
> 
> 
>> The idnits tool also mentions the pre-5378 disclaimer, and the shepherd
>> writeup has no information about why the disclaimer is needed.  What text is
>> in this document that is not subject to the IETF Trust terms from BCP 78, and
>> why is it not?  I think this needs an explanation.
> 
> This has been resolved in another thread.
> 
> 
>> I strongly agree with Ben's comment about needing explanations for a number
>> of SHOULDs (and SHOULD NOTs) in the document.  RFC 2119 says that for
>> SHOULD, "the full implications must be understood and carefully weighed
>> before choosing a different course."  Without any explanation, there's no way
>> for implementors to understand the implications and to weigh anything, and I
>> tripped over that quite a number of times during my review.
> 
> It has been replied in another thread w.r.t. Ben's comments. And I agree that after carefully consideration, it's better to change them to "MUST"s.
> 
>> 
>> I agree with Spencer's comment that we don't usually strong-arm IANA with
>> 2119 key words.  It's a small point, and I don't think IANA are easily offended
>> [ :-) ], but "IANA is asked to create" is a better approach than "IANA SHALL
>> create", and so on.
> 
> We will revise the section and be carefully with those words in IANA section in future documents:)
> 
> BR,
> -Haibin Song
> 
>> 
>> _______________________________________________
>> P2PSIP mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/p2psip
>

---

From: Barry Leiba <[email-masked]>
Date: Thu, 28 Jan 2016 16:47:56 -0500

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

> 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

---

From: Alissa Cooper <[email-masked]>
Date: Fri, 29 Jan 2016 11:12:37 -0800

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-masked]> wrote:
>

---

From: Barry Leiba <[email-masked]>
Date: Fri, 29 Jan 2016 15:30:32 -0500

On Fri, Jan 29, 2016 at 2:12 PM, Alissa Cooper <[email-masked]> 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