--- 1/draft-ietf-nfsv4-lfs-registry-04.txt 2015-04-09 11:15:05.832875140 -0700 +++ 2/draft-ietf-nfsv4-lfs-registry-05.txt 2015-04-09 11:15:05.856875728 -0700 @@ -1,22 +1,22 @@ NFSv4 D. Quigley Internet-Draft Intended status: Standards Track J. Lu -Expires: September 28, 2015 Oracle +Expires: October 10, 2015 Oracle T. Haynes Primary Data - March 27, 2015 + April 08, 2015 Registry Specification for Mandatory Access Control (MAC) Security Label Formats - draft-ietf-nfsv4-lfs-registry-04.txt + draft-ietf-nfsv4-lfs-registry-05.txt Abstract In the past Mandatory Access Control (MAC) systems have used very rigid policies which were implemented in particular protocols and platforms. As MAC systems became 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 @@ -38,21 +38,21 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on September 28, 2015. + This Internet-Draft will expire on October 10, 2015. Copyright Notice Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -277,20 +277,31 @@ to this registry. If the label format document is inside the RFC path, then The IANA Consideration section of the label format document should clearly reference the Label Format Selection registry and request allocation of a new entry. The well-known IANA policy, Specification Required, as defined in section 4.1 of [RFC5226], will be used to handle such requests. Note that "Specification Required" policy implies this process requires a Designated Expert reviewer, i.e., adding a new entry to this registry requires both a published label format specification and a Designated Expert review. + In reviewing the published label format specification, the Designated + Expert should consider whether or not the specification provides + sufficient semantics for the object and subject labels to enforce the + MAC model and policy administration when deployed within an + organization. Another consideration is if the label format allows a + correct and complete implementation of the protocol to process and + enforce labels as a policy administration mechanism. Finally, to + reduce interoperability issues, the review must determine if the new + label format specification has clearly defined syntax and semantics + for the proposed new labels. + 5.3. Obsoleting a Label Format Specifier In the case that a label format selector number is assigned to a label format and the label format specification is changed later, a new selector assignment should be requested. The same Specification Required IANA policy applies to such requests. The IANA Consideration section of the updated label format specification should be explicit in which old label selector assignment it obsoletes. Below is an example of obsoleted entry in the registry: