On 5/1/12 3:56 PM, "Nico Williams" <
nico@...> wrote:
>On Tue, May 1, 2012 at 11:17 AM, Haynes, Tom <
Tom.Haynes@...>
>wrote:
>> On 4/30/12 11:32 PM, "Dave Quigley" <
dpquigl@...> wrote:
>>>Section 4.7 with subsections
>>>
>>>It seems weird to have such a large section describing MLS semantics. It
>
>IMO we shouldn't have *any* text describing MLS or any other labeled
>security semantics. The protocol shouldn't care. Of course, we may
>need a required to implement labeled security domain of
>interpretation, but it's not clear to me that MLS should be it.
Yes, in the protocol description there should not be any mention of MLS
semantics. It should just describe the transport changes necessary to
convey labels.
This is however the Requirement's Document and it is valid to describe
some parts of schemes to help people see how we plan to facilitate these
real world use cases. As you say next:
>
>Alternatively, describing a number of schemes might help some readers.
>
>I'd classify labeled security semantics roughly into two broad
>classes: ones with strictly algorithmic label rules (e.g., MLS), and
>ones with not strictly algorithmic (and even strictly non-algorithmic)
>label rules (e.g., SMACK). This, I think, makes it easy to explain.
>
>Anyways, to me it seems simple to say that labeled security always
>involves a decision based on a subject's label, and object's label,
>and requested access. How that decision is made is what makes MLS,
>DTE, ... what they are -- they all differ in this one key question,
>but it should not be necessary to understand each scheme to understand
>labeled security in the first place.
>
>Nico
>--
_______________________________________________
nfsv4 mailing list
nfsv4@...
https://www.ietf.org/mailman/listinfo/nfsv4
