Subject: [clue] FW: CLUE Framework comments and general thoughts on organization of other documents

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Thu, 29 Aug 2013 11:13:13 +0000

This apparently disappeared in the mailing list glitch last night.

Keith

________________________________
From: DRAGE, Keith (Keith)
Sent: 29 August 2013 01:17
To: 'Mary Barnes'
Cc: CLUE
Subject: RE: [clue] CLUE Framework comments and general thoughts on organization of other documents

I did not say there were none. I said that I had quickly gone through the document and detected at least one example of each of the items I identified. Therefore it is not a case of replacing all "must" with "MUST" which is what one reading of your comment could infer.

But for the paragraph you quoted, why are these requirements not in the signalling document?

Keith

________________________________
From: Mary Barnes [mailto:[email-masked]]
Sent: 29 August 2013 00:39
To: DRAGE, Keith (Keith)
Cc: CLUE
Subject: Re: [clue] CLUE Framework comments and general thoughts on organization of other documents

You might want to read the document from start to finish more closely (I can't fathom you could have done that between the time I sent the email and you responded).   Here is one example that clearly has normative content (6.2.2):

   In the

   provider's Advertisement, this attribute can have multiple values,

   which means the provider supports each of the indicated policies.

   The consumer, when it requests media captures from this Capture

   Scene Entry, should also include this attribute but with only the

   single value (from among the values indicated by the provider)

   indicating the Consumer's choice for which policy it wants the

   provider to use.  The Consumer must choose the same value for all

   the Media Captures in the Capture Scene Entry.  If the provider

   does not support any of these policies, it should omit this

   attribute.

My suggestion is that the above be reworded something like:

   In the

   provider's Advertisement, this attribute MAY have multiple values,

   which means the provider supports each of the indicated policies.

   The consumer, when it requests media captures from this Capture

   Scene Entry, SHOULD also include this attribute but with only the

   single value (from among the values indicated by the provider)

   indicating the Consumer's choice for which policy it wants the

   provider to use.  The Consumer MUST choose the same value for all

   the Media Captures in the Capture Scene Entry.  If the provider

   does not support any of these policies, it SHOULD omit this

   attribute.

I don't expect there would be a lot of these, but these are key to the CLUE model and if the solution doesn't follow those, then we've wasted a lot of time on this document.

Also, we have done this for previous documents that have followed a similar model - e.g., XCON Framework.  That was originally targeted as PS (in the chartered deliverables), but the WG decided at one point that it thought it should be informational, so we changed it:
http://www.ietf.org/mail-archive/web/xcon/current/msg01974.html

We ended up changing it back during IETF Last call:
http://www.ietf.org/mail-archive/web/gen-art/current/msg02327.html

Mary.

On Wed, Aug 28, 2013 at 6:07 PM, DRAGE, Keith (Keith) <[email-masked]<mailto:[email-masked]>> wrote:
On 1) I don't think it is as simple as this.

Firstly, I am not really sure why it is a normative reference from the signalling document. Which particular reference from that document are you thinking is the normative one. Yes, I know it is listed in the normative references, but references only have impact when they are quoted from the main text.

Secondly, I did a quick scan of the "must"s in the framework document and found at least examples that:
-                      still need to be informative because they are part of descriptive text (we should probably reword)
-                      duplicate requirements that are probably elsewhere e.g. in the signalling document, and we should not double specify
-                      are statements about what other documents are meant to contain, rather than requirements on the implementation
None of these in my view should be upper case "MUST".

Regards

Keith

________________________________
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Mary Barnes
Sent: 28 August 2013 23:24
To: CLUE
Subject: [clue] CLUE Framework comments and general thoughts on organization of other documents

Here is another more general set of comments on the framework document.

Putting together text for the security requirements section for the framework has made me consider how we have the documents structured and the dependencies.

1) The CLUE Framework document needs to be standards track (it's already a normative reference in the signaling document) as it outlines normative implementation details.  So, the document needs to be revised to ensure that "must"s are "MUST"s and some text may need to be changed to be normative - e.g., "can be" -> MAY, etc.

2) As we've discussed we probably will not publish the Framework until the other detailed solution documents are near completion.  [Although, it is not a problem to have informative references as works in progress.]   So, I  think that the framework document should be more explicit about referencing the solution documents.  One reason I think this is that some of the details are very specific (e.g., the use of the names of specific data elements).  Also, it has been a while since I've carefully reviewed the framework from start to finish and it seems to me that it leaves you hanging without having references to where all the details are found. Adding that will also make it easier to reference specifics in the security analysis and be able to re-assure the security folks that the issues are addressed in the other solution documents. Thus, I think the framework would be a good document to outline the solution documents (e.g., there is already an indirect reference to the RTP document).

Thanks,
Mary.