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

From: Mary Barnes <[email-masked]>
Date: Wed, 28 Aug 2013 17:24:24 -0500

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.

---

From: Mary Barnes <[email-masked]>
Date: Thu, 29 Aug 2013 08:01:18 -0500

On Wed, Aug 28, 2013 at 7:16 PM, DRAGE, Keith (Keith) <
[email-masked]> wrote:

> ******
>
> 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.
>
[MB] I did not say that the task was a merely a global change of "must" to
"MUST"   The etc. implies that you do what is sensible.  As usual, each
occurrence needs to be reviewed and a decision made as to whether there is
a normative state there.  FYI, this is some text I sent to Mark as he did
ask for clarification on that and maybe this will help you understand
better:

.... I think you can make a first (and probably fairly accurate pass) by
searching on the lower case versions of the words and IF they are stating
something normative, changing them to all CAPs.  Folks debate as to whether
alternative words should be used if the text isn't really stating anything
normative - e.g., should -> ought, may-> can, etc.  Related to this, you
should revisit the "cans" to see if they ought to be MAYs.  I am a bit OCD
about this, but it doesn't have to be perfect as long as the basic
normative stuff is at least highlighted.....

[/MB]

>  **
>
> But for the paragraph you quoted, why are these requirements not in the
> signalling document?
>
[MB]  Those requirements absolutely should be reflected in the solution
document, but will be much more specific, referring to specific messages
carrying the data and would likely occur in a different context.  The
framework is a higher level description of the messaging and information
required to support the CLUE functionality. The data model and signaling
are the realization of the framework and are what will ensure
interoperability on the wire.

BTW, if you think this text isn't needed in the FW, please feel free to
suggest where this text should be moved into the signaling solution
document. [/MB]

> 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]> 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]] *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.***
> *
>
>  ****
>
> dependencies.  ****
>  ****
> normative - e.g., "can be" -> **MAY**, etc.   ****
>
>  ****
>
> 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. ****
>
>  ****
>
>  ****
>
>  ****
>
> ** **
>