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

From: Paul Kyzivat <[email-masked]>
Date: Tue, 03 Sep 2013 16:01:14 -0400

On 8/28/13 6:24 PM, Mary Barnes wrote:
> 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.

Lets think about this. Do we *want* the framework to be normative? Or 
are you just saying it needs to be normative because of how we have the 
other documents structured? If we don't want it to be normative, then we 
just need to take steps to move all the normative stuff elsewhere, and 
leave non-normative abstractions/platitudes in the framework. (I meant 
that in a good way.)

I don't have a strong feeling about it. But in general I would expect 
that a framework might not need to be normative.

	Thanks,
	Paul

> 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: Tue, 3 Sep 2013 15:14:00 -0500

I should clarify and qualify that I don't think there are a lot of changes
at all in terms of normative text.  I gave one example in my response to
Keith.

If we want to make the FW non-normative, I really think you are going to
remove a whole lot more than I'm suggesting should be updated to make the
document normative.  We have iterated over the FW many, many times in terms
of what belongs and what doesn't.  I think we almost have it right.   I
don't see that it causes harm to make it normative and in the end, I
believe it provides an appropriate structure around the solution.

Mary.

On Tue, Sep 3, 2013 at 3:01 PM, Paul Kyzivat <[email-masked]> wrote:

> Lets think about this. Do we *want* the framework to be normative? Or are
> you just saying it needs to be normative because of how we have the other
> documents structured? If we don't want it to be normative, then we just
> need to take steps to move all the normative stuff elsewhere, and leave
> non-normative abstractions/platitudes in the framework. (I meant that in a
> good way.)
>
> I don't have a strong feeling about it. But in general I would expect that
> a framework might not need to be normative.
>
>         Thanks,
>         Paul
>
>

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 03 Sep 2013 16:43:22 -0400

On 9/3/13 4:14 PM, Mary Barnes wrote:
> I should clarify and qualify that I don't think there are a lot of
> changes at all in terms of normative text.  I gave one example in my
> response to Keith.
>
> remove a whole lot more than I'm suggesting should be updated to make
> the document normative.  We have iterated over the FW many, many times
> in terms of what belongs and what doesn't.  I think we almost have it
> right.   I don't see that it causes harm to make it normative and in the
> end, I believe it provides an appropriate structure around the solution.

Since I don't have a strong opinion one way or the other, IMO if its 
easy to make it normative and hard to make it non-normative, then I 
agree with making it normative.

	Thanks,
	Paul

> Mary.
>
>
> On Tue, Sep 3, 2013 at 3:01 PM, Paul Kyzivat <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     Lets think about this. Do we *want* the framework to be normative?
>     Or are you just saying it needs to be normative because of how we
>     have the other documents structured? If we don't want it to be
>     normative, then we just need to take steps to move all the normative
>     stuff elsewhere, and leave non-normative abstractions/platitudes in
>     the framework. (I meant that in a good way.)
>
>     I don't have a strong feeling about it. But in general I would
>     expect that a framework might not need to be normative.
>
>              Thanks,
>              Paul
>
>