[nfsv4] Comments on draft-ietf-nfsv4-lfs-registry-00

David Noveck <davenoveck@gmail.com> Sun, 31 August 2014 13:58 UTC

Return-Path: <davenoveck@gmail.com>
X-Original-To: nfsv4@ietfa.amsl.com
Delivered-To: nfsv4@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCDFF1A023F for <nfsv4@ietfa.amsl.com>; Sun, 31 Aug 2014 06:58:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.1
X-Spam-Level:
X-Spam-Status: No, score=-0.1 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PN_7464vqYty for <nfsv4@ietfa.amsl.com>; Sun, 31 Aug 2014 06:58:45 -0700 (PDT)
Received: from mail-ob0-x22c.google.com (mail-ob0-x22c.google.com [IPv6:2607:f8b0:4003:c01::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F22CB1A01E5 for <nfsv4@ietf.org>; Sun, 31 Aug 2014 06:58:44 -0700 (PDT)
Received: by mail-ob0-f172.google.com with SMTP id wo20so3134231obc.3 for <nfsv4@ietf.org>; Sun, 31 Aug 2014 06:58:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=yQMfowcJgRW+9dJvI3t1QWHT1SZOFqLQ4QX0f5xzV+Q=; b=ojbLhuQoQ+7QEt3+pOjiY0EJAFhXnp3yONWPKwlfiCpFYgj4erLPSycWYukiIYxHyO iuFwaSS9PFypAqoOQUwaRX0NAVgQxkfK2vsTXdMQDD+0EzgGXjOUN0GJ7aIOs5cS7JUv kHgHRmrGuS4UZFSvPy4rt1odbCunpHl2YkKuWFWh2jD78ekcrjsMUbo8is/My5o04QOZ UNw/oLxt69A+DdvexG/d60IYyDmdtjJbnlz/8bH8wkNF3UAH+8RckRReydLhxLA3D5JH BqrKu6ATlm8axgd/4f3QVNoLL75xXSj9P0nVC0InwIL86zpcvPwvTC9eR/+CfksHFIkB xl4w==
MIME-Version: 1.0
X-Received: by 10.182.60.98 with SMTP id g2mr21495586obr.6.1409493524309; Sun, 31 Aug 2014 06:58:44 -0700 (PDT)
Received: by 10.182.66.11 with HTTP; Sun, 31 Aug 2014 06:58:44 -0700 (PDT)
Date: Sun, 31 Aug 2014 09:58:44 -0400
Message-ID: <CADaq8jfMc88AGhTwp3jcP6+NT9Oi11+njDh9E2q+-3kB12_WCA@mail.gmail.com>
From: David Noveck <davenoveck@gmail.com>
To: "Haynes, Tom" <tom.haynes@netapp.com>, dpquigl@davequigley.com, jarret.lu@oracle.com
Content-Type: multipart/alternative; boundary="089e0158aaa0d46be10501ed485d"
Archived-At: http://mailarchive.ietf.org/arch/msg/nfsv4/zSs9Udw0_w7oHj647DKQlr-HNY8
Cc: "nfsv4@ietf.org" <nfsv4@ietf.org>
Subject: [nfsv4] Comments on draft-ietf-nfsv4-lfs-registry-00
X-BeenThere: nfsv4@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NFSv4 Working Group <nfsv4.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/nfsv4>, <mailto:nfsv4-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/nfsv4/>
List-Post: <mailto:nfsv4@ietf.org>
List-Help: <mailto:nfsv4-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/nfsv4>, <mailto:nfsv4-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 31 Aug 2014 13:58:47 -0000

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 where implaementation
would lock policy administration into the

   described model.


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.