Requirements for Labeled NFS
draft-ietf-nfsv4-labreqs-05
Yes
(Martin Stiemerling)
No Objection
(Adrian Farrel)
(Barry Leiba)
(Benoît Claise)
(Brian Haberman)
(Gonzalo Camarillo)
(Jari Arkko)
(Richard Barnes)
(Spencer Dawkins)
Note: This ballot was opened for revision 04 and is now closed.
Martin Stiemerling Former IESG member
Yes
Yes
(for -04)
Unknown
Adrian Farrel Former IESG member
No Objection
No Objection
(for -04)
Unknown
Barry Leiba Former IESG member
No Objection
No Objection
(for -04)
Unknown
Benoît Claise Former IESG member
No Objection
No Objection
(for -04)
Unknown
Brian Haberman Former IESG member
No Objection
No Objection
(for -04)
Unknown
Gonzalo Camarillo Former IESG member
No Objection
No Objection
(for -04)
Unknown
Jari Arkko Former IESG member
No Objection
No Objection
(for -04)
Unknown
Joel Jaeggli Former IESG member
No Objection
No Objection
(2013-11-20 for -04)
Unknown
Comments from mehmet during the ops dir review. ** The document lacks an IANA Considerations section. http://www.ietf.org/id-info/checklist#anchor4 says: “If there is no action for IANA, the section should say that, e.g., including something like "This document has no actions for IANA." == Outdated reference: A later version (-20) exists of draft-ietf-nfsv4-minorversion2-19 Mehmet
Richard Barnes Former IESG member
No Objection
No Objection
(for -04)
Unknown
Sean Turner Former IESG member
(was Discuss)
No Objection
No Objection
(2013-11-20)
Unknown
0) Note RFC 4949 has a definition for MAC that you might refer to. 1) In s3.1, there is a discussion about the security attribute of the subject. Isn't this more commonly referred to as the client's privileges? And it might make sense to add this to the Definitions section. 2) s3.1 #4: Ever heard of a SPIF or looked at ISO 15816? The were attempts to do just that. 3) s4: Reads a little awkward: Labeled NFS SHOULD support that the following security services are provided for all NFSv4.2 messaging. These services may be provided by lower layers even if NFS has to be aware of and leverage them: maybe: Labeled NFS or the underlying system on which the Labeled NFS operates SHOULD provide the following security services for all NFSv4.2 messaging: 4) s3.2: Could you better define strong mutual authentication - is that certificate-based mutual authentication? Or is it that MD5-based security shouldn't be used ;) Also: r/will be required/is required 5) s3.3: Instead of: MAC models base access decisions on security attributes bound to subjects and objects. I would have said: MAC models base access decisions on security attributes and privileges bound to objects and subjects, respectively. 6) s3.3: I'd probably add the following to the end of this sentence: With a given MAC model, all systems have semantically coherent labeling - a security label MUST always mean exactly the same thing on every system. add: because otherwise the label cannot be properly interpreted. 7) s3.3: What does the "this" in this sentence refer to the binding of stuff to objects/subjects or to having labels mean the same thing: While this may not be necessary for simple MAC models it is recommended that most label formats assigned an LFS incorporate this concept into their label format. 8) (no action required) s3.3: I think you're more likely to get weighed down by corner cases than a global scheme :)
Spencer Dawkins Former IESG member
No Objection
No Objection
(for -04)
Unknown
Stephen Farrell Former IESG member
No Objection
No Objection
(2013-11-21 for -04)
Unknown
- general: some systems have a requirement that some labels are visible in clear, whereas others are encrypted, when passed over the network at least. Is that a requirement you want to impose/meet here? Either way, it might be good to say. - 3.2: s/Privacy/Confidentiality/ would be better here and elsewhere. - 4.3: the term foreign label is not used in 3.3 - 5.3: Whis is a US-specific section included here? Surely this ought be more international? This section should really be generalised or deleted. - 5.4: You could explain what "legal hold" means. I assume its where someone is suing someone and a court says "don't you go changing X" - is that right?
Stewart Bryant Former IESG member
No Objection
No Objection
(2013-11-18 for -04)
Unknown
The case is well made without cases 5.3. International Traffic in Arms Regulations (ITAR) . . . . . 12 5.4. Legal Hold/eDiscovery . . . . . . . . . . . . . . . . . . 13 Traditionally the IETF stays well away from such areas, are we sure we want to make any comment on them in this text?