I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments ust like any other last call comments. Short version: I think the draft is ready. This draft is intended to be Informational. It does not specify any standard. Instead, it describes the operating environment and assumptions behind labeled NFS. Labeled NFS associates labels with resources (usually files) and processes, where the resources reside on a file server, while the resources run on a client. Such labels (Multi-Level Security is but one example) are then used as a basis for policy decisions. The draft is intended for people not familiar with NFS, and does a good job of explaining the different scenarios. For example, with a limited server, it is up to the client to decide about authorization for accessing resources, and the server functions solely as a store. This model is surprising to people familiar with, for example, web servers, where the resources are considered to belong to the server, and it is up to the server to make authorization decisions. Other NFS servers, called "MAC-functional" have authorization decisions on both client and server. I found the draft to be well-written and informative. I have a few comments, but I consider none of them show-stoppers: - The introduction has this text: "DAC systems offer no real protection against malicious or flawed software due to each program running with the full permissions of the user executing it.". Put like that, this sentence is inflammatory. Discretionary Access Control protects you against unauthorized users running malicious software. It just doesn't protect against "good" users being tricked into running bad software. - Section 3.3 uses the term "opaque". This is a surprising term, considering this sentence about the opaque component: "The LFS component provides a mechanism for identifying the structure and semantics of the opaque component." So it's not really opaque, is it? The term "opaque" is commonly used when the data is unparseable by the participants in the protocol. Here, the client and a MAC-functional server can parse this data just fine. - I think the security considerations is missing some text on what additional security is needed in the case of a limited server that only stores the information. Something should protect the data so that client A's data is not served to client B, even if client B is malicious. Yoav