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

From: Brian Hibbard <[email-masked]>
Date: Tue, 2 Feb 2010 16:33:15 -0600

My guess is that there are three categories of normative-sounding statements in the document.
  
  1) statements that are repeating or paraphrasing actual normative statements from authoritative documents, 

  2) statements that are normal english usage of the words "should" and "must", but don't (and mustn't) actually claim any normative authority

  3) statements that really NEED to be normative, but simply aren't.

I haven't yet taken an inventory of which statements we have and which categories to which they belong to yet, but what sounds right to me is:

  1)  For category 1 statements we use normative-like conventions of RFC 2119 AND specifically reference the RFC that has the authority.  I am advocating that we NOT add an RFC 2119 convention section.  Since we are not actually making authoritative statements, I would think that SHOULD be fine.

  2)  Category 2 statements remain as they are, which is to say they do not adopt RFC 2119 convention, and are only intended to recommend and suggest.  Use of the word "must" should therefore be avoided in this class of statement.

  3)  Category 3 statements should probably be specifically identified in the body of the document as statements that we think should be made normative somewhere else but ARE NOT.  I think these would be worthwhile information and fair game for this document, if we have any.  

My belief is that this will help clarify our intentions and our recommendations, while helping us avoid the confusion implementers may have as to whether this document is actually a normative source.

Does this sound agreeable?  If so, I can go find the relevant statements and we can start nailing down which camp they belong to, and if they are category 1, which documents authorize them. 

-b

On Jan 28, 2010, at 6:11 AM, DRAGE, Keith (Keith) wrote:

> 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
> 
>> -----Original Message-----
>> From: Cullen Jennings [mailto:[email-masked]] 
>> Sent: Wednesday, January 27, 2010 6:07 PM
>> To: Brian Hibbard
>> Cc: DRAGE, Keith (Keith); SIPCORE; Kumiko Ono
>> Subject: Re: [sipcore] draft-ietf-sipcore-sec-flows-01: 
>> document scope and intent
>> 
>> 
>> 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. 
>> 
>>> 
>>> -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: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Wed, 3 Feb 2010 00:23:00 +0100

Thanks for thinking about this.

For 1) I recommend we do what we did in draft-ietf-sip-sips which was to quote at least the line containing the RFC 2119 word from the original RFC, and use quotation marks to emphasise it was a quote. 

For 2) there are no rules defining this, but I personally think it is best to try and reword to avoid lower case "may" and "should" as well as lower case "must". It only takes a slip of the keyboard for it to become upper case in a future edit. What words get used depends on context, but "can" or "might" usually work instead of "may", and "is expected to" in many cases works for "should". The must one is usually easiest of the lot. In many cases thinking about what was really meant in terms of trying to do this does also make the text clearer.

And every RFC writer should be thinking through there RFC 2119 language in terms of these three categories. Many people use RFC 2119 language because it is the first form that comes from brain to keyboard. It needs to be reserved for conformable requirements.

regards

Keith

> From: Brian Hibbard [mailto:[email-masked]] 
> Sent: Tuesday, February 02, 2010 10:33 PM
> To: DRAGE, Keith (Keith)
> Cc: Cullen Jennings; SIPCORE; Kumiko Ono
> My guess is that there are three categories of 
> normative-sounding statements in the document.
>   
>   1) statements that are repeating or paraphrasing actual 
> normative statements from authoritative documents, 
> 
>   2) statements that are normal english usage of the words 
> "should" and "must", but don't (and mustn't) actually claim 
> any normative authority
> 
> I haven't yet taken an inventory of which statements we have 
> and which categories to which they belong to yet, but what 
> sounds right to me is:
> 
>   1)  For category 1 statements we use normative-like 
> conventions of RFC 2119 AND specifically reference the RFC 
> that has the authority.  I am advocating that we NOT add an 
> RFC 2119 convention section.  Since we are not actually 
> making authoritative statements, I would think that SHOULD be fine.
> 
>   2)  Category 2 statements remain as they are, which is to 
> say they do not adopt RFC 2119 convention, and are only 
> intended to recommend and suggest.  Use of the word "must" 
> should therefore be avoided in this class of statement.
> 
>   3)  Category 3 statements should probably be specifically 
> identified in the body of the document as statements that we 
> think should be made normative somewhere else but ARE NOT.  I 
> think these would be worthwhile information and fair game for 
> this document, if we have any.  
> 
> My belief is that this will help clarify our intentions and 
> our recommendations, while helping us avoid the confusion 
> implementers may have as to whether this document is actually 
> a normative source.
> 
> Does this sound agreeable?  If so, I can go find the relevant 
> statements and we can start nailing down which camp they 
> belong to, and if they are category 1, which documents 
> authorize them. 
> 
> -b
> 
> 
> > The key thing here is whether any of those normative like 
> statements need to appear at standards track level. 
> > 
> > If they don't belong in another document they still need careful 
> > consideration as to whether they appear as
> > 
> > XXX MUST do this,
> > 
> > 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
> > 
> >> No problem - this is a chair issue/AD (Robert) issue and 
> glad to do 
> >> whatever they want.
> >> 
> references to 
> >> RFC 2119.  I'll make sure we have no normative-sounding  SHOULDs, 
> >> MUSTs, et al.
> >> 
> 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
> >> 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.
> >>>> 
> >> 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.
> >>>> 
> >> 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 
> SIPCORE that 
> >> anyone is even interested in this document.
> >>>> 
> >>>> regards
> >>>> 
> >>>> Keith
> >>>>