[nfsv4] updated comments re draft-ietf-nfsv4-lfs-registry-00

[David Noveck <[e-mail]>]

*Supersedes previous version (gmail sent it before it was ready).*

Here's my stab at an abstract of the document as I understood  its intent.
 You can adopt it, in whole or in part, if it works for you.


In the past Mandatory Access Control (MAC) systems have used particular
rigidly-specified policies which were implemented in particular protocols
and platforms.  As MAC systems become more widely deployed, additional
flexibility in mechanism and policy will be required.  While traditional
trusted systems implemented Multi-Level Security (MLS) and integrity
models, modern systems have expanded to include technologies such as
type enforcement.  Due to the wide range of policies and mechanisms which

need to be accommodated, it is unlikely that use of a single security label

format and model will be viable.


To allow multiple MAC mechanisms and label formats to co-exist in a
network, this document proposes a registry of label format
specifications.  This
registry would contain label format identifiers and would provide for the

association of each such identifier with a corresponding extensive document
document outlining the exact syntax and use of the particular label
format.


With regard to the second paragraph of section 1, I don't think you are
harsh enough about the complexity.  It is not enough to say the complexity
is "unneeded".  I'd say it is actively harmful.  How about the following:


One solution might be to define a single label format which consists of the

union of the requirements of all MAC models/implementations, known at a

given time. This approach is not desirable because it introduces an

environment where many MAC models would either have blank fields for many

of the label's components or where many implementations would ignore

many of values that are present altogether.  The resulting complexity

would be likely to result in a confusing situation in which the interaction

of fields that that derive from different MAC models is never clearly

specified and the addition of new models or extension of existing models

is unduly difficult.

   An additional consideration is that if a policy authority or identifier

field is specified in the label format it would require a robust

description that encompassed multiple MAC models in an environment in
which implementations would be likely to be MAC-model specific


It also seems to me that with some limited reworking the last paragraph
above and the existing last two paragraphs of section 1 could be made into
a new section 1.1 devoted to policy administration


In section 2, there's a problem with the definition of "label format
specification".  This same term has a different definition in section 6,
and the definition in section 2 seems to match "Label format selector" in
section 6.