Subject: Re: [sipcore] draft-ietf-sipcore-sec-flows-01: document scope and intent

From: Brian Hibbard <[email-masked]>
Date: Thu, 7 Jan 2010 16:08:29 -0600

OK, it seems there is heavy agreement that this SHOULD be  
informational and not standards track.  Do we have agreement on that?

Specifically, Cullen, are you OK with that?  Do you want to weigh in  
on the rationale for normative-strength  statements?

If there are no remaining objections, I can go ahead and make the  
draft informational and remove section 2 and references to RFC 2119.   
I'll make sure we have no  normative-sounding  SHOULDs, MUSTs, et al.

-b
On Dec 11, 2009, at 8:07 AM, DRAGE, Keith (Keith) wrote:

> If so, you arbitrarily decided to change it because as far as I know  
> it was informational during its complete lifetime in the SIP group,  
> and I remember no discussion in the transfer to SIPCORE that made it  
> standards track. Certainly my final SIP status slides (and the ones  
> before and the ones before that ...) also say "Candidate:  
> Informational". The first version that carries an "intended status"  
> line is the 1st sipcore version, and this is at variance with the  
> charter pages.
>
> The last SIP charter pages clearly say:
> Mar 2009    Example security flows to WGLC (Informational)
> Jul 2009    Example security flows to IESG (Informational)
>
> And the SIPCORE charter pages state:
>
> Oct 2009    Example security flows to IESG (Informational)
>
> And from my own perspective this should still be informational. If  
> you feel there is standards track information in here, then pull it  
> out and submit it as a separate draft, and then the WG can decide  
> whether they want to proceed with such a standards track document.
>
> I'd also note to all authors that if you receive private messages of  
> interest, then at least please let the WG chairs know that you have  
> had those expressions of interest. If you received any of those  
> messages on sec-flows during its SIP lifetime, the ex SIP WG chairs  
> certainly have no evidence of them ever having been received - and  
> that is essential information to the PROTO writeups. I assume the  
> SIPCORE chairs are now in the same boat, having no email evidence  
> because a small set of exchanges in the past on SIP and SIPCORE that  
> anyone is even interested in this document.
>
> regards
>
> Keith
>
>> -----Original Message-----
>> From: [email-masked]
>> [mailto:[email-masked]] On Behalf Of Cullen Jennings
>> Sent: Thursday, December 10, 2009 6:14 AM
>> To: Brian Hibbard
>> Cc: SIPCORE; Kumiko Ono
>> Subject: Re: [sipcore] draft-ietf-sipcore-sec-flows-01:
>> document scope and intent
>>
>>
>> On Nov 24, 2009, at 2:25 PM, Brian Hibbard wrote:
>>
>>> The draft states in the first line of the introduction that
>> it is not normative for SIP.  That raises the question as to
>> whether this should be on the standards track. Should this be
>> informational or BCP?
>>
>> I think we decided it need to be standards track when we
>> added the normative statements about binary a long time ago.
>> (I note that the "should" should be a "SHOULD".
>>
>> _______________________________________________
>> sipcore mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/sipcore
>>
> _______________________________________________
> sipcore mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sipcore

---

From: Brian Hibbard <[email-masked]>
Date: Thu, 7 Jan 2010 16:26:15 -0600

On Dec 9, 2009, at 1:27 PM, Robert Sparks wrote:

>
> On Nov 24, 2009, at 3:25 PM, Brian Hibbard wrote:
>
>>
>> == Tutorial or Reference ==
>>
>> Is the draft intended to be a hitchhikers' guide to security for  
>> SIP implementers?
> I don't believe so - it was a set of examples.
>>
>> Does the draft intend to be a training tool to educate implementers  
>> in PKI?
> No.
>> How far do we want to go in teaching developers how to generate and  
>> manage certificates?
> Only to the point that it's needed in order to explain what's  
> happening in the examples.
>> For example, are we trying to teach how to administer a Certificate  
>> Authority and want to deal with how certs are generated in the real  
>> world?
> Very much no. Is something in the draft looking like it does that to  
> you now?

Not the draft itself, but at least one reviewer wanted elaboration on  
certificate requests and some explanation on how to use the OpenSSL CA  
tools.  I felt that was well beyond the intent of the draft, but I  
didn't want to squash consensus in the event that I was wrong on that.

>> Or are we only concerned with the cryptography of the messages, and  
>> we are only providing certificates and
>>
>> Are we only trying to provide specific reference examples for  
>> helping verify implementations?
> The last.
>>
>> If so, should we be providing test vectors instead?
> I think you're focusing only on the crypto generation part of the  
> draft (it is the hard part you jumped in to help with), but the  
> examples
> frame when what type of security mechanisms get used.

Ah yes. I meant all of that to be constrained to  the context of PKI  
within the draft.  It didn't help that it looks like I made a copy/ 
paste error.  Basically, the draft is not at all intended to be a PKI  
tutorial, but some hand-picked crypto examples, nuggets of interop  
wisdom, and reference certs for interop testing.

>> Is the document intending to recommend how things should be done,  
>> how they might be done, or how they must be done?
> The document provides some example flows. It is not intended to be  
> comprehensive. In some cases it shows the only way
> to do a certain thing. In others, it chooses from a range of options.
>
>>
>> == Document Title ==
>>
>> Depending on the resolution of the above, we may need to consider  
>> changing the document's title.
> I don't think we should be changing the document's scope to that  
> degree at this time.
>

I appreciate that very much.

---

From: Cullen Jennings <[email-masked]>
Date: Wed, 27 Jan 2010 11:07:24 -0700

On Jan 7, 2010, at 3:08 PM, Brian Hibbard wrote:

> OK, it seems there is heavy agreement that this SHOULD be informational and not standards track.  Do we have agreement on that?
> 
> Specifically, Cullen, are you OK with that?

No problem - this is a chair issue/AD (Robert) issue and glad to do whatever they want. 

>  Do you want to weigh in on the rationale for normative-strength  statements?
> 
> If there are no remaining objections, I can go ahead and make the draft informational and remove section 2 and references to RFC 2119.  I'll make sure we have no  normative-sounding  SHOULDs, MUSTs, et al.

Uh, we have all kinds of normative language in RAI  Information RFC so don't water things down such that implementers don't know what to do. The point of this doc is to help implementers get it right so as long as the language changes are consistent with helping implementors get it right. I'm fine with them. 

>> If so, you arbitrarily decided to change it because as far as I know it was informational during its complete lifetime in the SIP group, and I remember no discussion in the transfer to SIPCORE that made it standards track. Certainly my final SIP status slides (and the ones before and the ones before that ...) also say "Candidate: Informational". The first version that carries an "intended status" line is the 1st sipcore version, and this is at variance with the charter pages.
>> 
>> And from my own perspective this should still be informational. If you feel there is standards track information in here, then pull it out and submit it as a separate draft, and then the WG can decide whether they want to proceed with such a standards track document.
>> 
>> I'd also note to all authors that if you receive private messages of interest, then at least please let the WG chairs know that you have had those expressions of interest. If you received any of those messages on sec-flows during its SIP lifetime, the ex SIP WG chairs certainly have no evidence of them ever having been received - and that is essential information to the PROTO writeups. I assume the SIPCORE chairs are now in the same boat, having no email evidence because a small set of exchanges in the past on SIP and SIPCORE that anyone is even interested in this document.
>> 
>> regards
>> 
>> Keith
>>

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Thu, 28 Jan 2010 13:11:53 +0100

The key thing here is whether any of those normative like statements need to appear at standards track level. 

If they do, they belong in another document, as this document is definitely informative.

If they don't belong in another document they still need careful consideration as to whether they appear as 

XXX MUST do this, 

as opposed to a commentary on what appears elsewhere:

Based on the requirements in document zzz, the correct usage of those requirements results in XXX doing this.

There is certainly no point in circulating normative statements in a document just because that is the way they were first formulated. We need to consider if that is the best way of presenting that particular item of information.

regards

Keith

> From: Cullen Jennings [mailto:[email-masked]] 
> Sent: Wednesday, January 27, 2010 6:07 PM
> To: Brian Hibbard
> Cc: DRAGE, Keith (Keith); SIPCORE; Kumiko Ono
> > If there are no remaining objections, I can go ahead and 
> make the draft informational and remove section 2 and 
> references to RFC 2119.  I'll make sure we have no  
> normative-sounding  SHOULDs, MUSTs, et al.
> 
> Uh, we have all kinds of normative language in RAI  
> Information RFC so don't water things down such that 
> implementers don't know what to do. The point of this doc is 
> to help implementers get it right so as long as the language 
> changes are consistent with helping implementors get it 
> right. I'm fine with them. 
> 
> > 
> > -b
> >> If so, you arbitrarily decided to change it because as far 
> as I know it was informational during its complete lifetime 
> in the SIP group, and I remember no discussion in the 
> transfer to SIPCORE that made it standards track. Certainly 
> my final SIP status slides (and the ones before and the ones 
> before that ...) also say "Candidate: Informational". The 
> first version that carries an "intended status" line is the 
> 1st sipcore version, and this is at variance with the charter pages.
> >> 
> >> And from my own perspective this should still be 
> informational. If you feel there is standards track 
> information in here, then pull it out and submit it as a 
> separate draft, and then the WG can decide whether they want 
> to proceed with such a standards track document.
> >> 
> >> I'd also note to all authors that if you receive private 
> messages of interest, then at least please let the WG chairs 
> know that you have had those expressions of interest. If you 
> received any of those messages on sec-flows during its SIP 
> lifetime, the ex SIP WG chairs certainly have no evidence of 
> them ever having been received - and that is essential 
> information to the PROTO writeups. I assume the SIPCORE 
> chairs are now in the same boat, having no email evidence 
> because a small set of exchanges in the past on SIP and 
> SIPCORE that anyone is even interested in this document.
> >> 
> >> regards
> >> 
> >> Keith
> >> 
> >>> it is not normative for SIP.  That raises the question as 
> to whether 
> >>> this should be on the standards track. Should this be 
> informational 
> >>> or BCP?
> >>> 
> added the 
> >>> normative statements about binary a long time ago.