[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.
- [nfsv4] Comments on draft-ietf-nfsv4-lfs-registry… David Noveck
- Re: [nfsv4] Comments on draft-ietf-nfsv4-lfs-regi… Thomas Haynes