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 just like any other last call comments. This document describes the notion of "federated filesystem namespace" and requirements for specifications of an actual set of federated filesystem namespace components and even some requirements of actual implementations. A federated namespace is one where multiple filesystems (or, rather, "filesets") are put together into a larger filesystem-like namespace, but where the various filesystems involved can be owned and administered by widely varying entities. Authorization issues arise when filesystems migrate, and these are neatly resolved in the federated namespace concept by separating the location of references to filesystems from the location of fileset location information. References to filesets ("junctions") live in actual filesystem (think of a magic symlink or "shortcut"). Fileset location information lives in a directory whose name is part of the fileset's name as referenced by any junction that refers to it. Authorization of junction administration is a matter local to the filesystems where the junctions live. Authorization of fileset location administration is a matter local to the directory where the fileset location information is published. There is one more level of separation as well, to allow for filesets with replicas owned and administered by different entities. "Fileset names" (FSNs) refer to directory objects which in turn refer to "fileset location" objects (FSLs); both, FSNs and FSLs include the name of the containing directory in their canonical name forms. The document does not describe the authorization separation involved. And though it isn't strictly necessary, I believe that it would be beneficial to have such a description. The document also does not clearly explain that junctions are not published in any directory, which confused me greatly at first, as in my opinion publishing FSN and FSL objects does not make the directories in which they are published "namespace databases" (NSDBs). This is not a security concern, of course. The document also does not explain that FSNs are intended to be small, even fixed sized, or with highly compressible variable size portions[*]. But a moment's thought about filesystem designs quickly reveals that such a requirement is important. In my opinion such a requirement should be documented. This too is not a security concern. The Security Considerations section is a bit skimpy. Its claims are correct in my opinion. I would, however, add to it the following: - A note that the federated namespace concept helps distribute responsibility for authorization (a very good thing). - A note that orphaned FSNs and FSLs cannot be easily distinguished from ones referenced by junctions and FSNs, respectively. Therefore objects will tend to pile up. This is a resource consumption consideration. Resource control issues are, IMO, a security consideration. Finally, I'm not sure if it's worth saying anything about the fact that with the NSDB choice being up to the FSN and FSL publishers, there can be a plethora of NSDBs in a federation, which brings scalability of distributed authentication and trust into the picture. For example, consider an NSDB that uses TLS and a self-signed server certificate to authenticate itself, then a fingerprint of the certificate will have to be part and parcel of the FSN/FSL names stored by junctions/FSNs (respectively). A PKI would help, of course, but in a sufficiently large federation it may be necessary to have multiple trust anchors, rather than a single PKI root, which brings TA administration issues into the picture. This is really nothing new, and so perhaps not worth noting, but the potential for having to store, and the consequences thereof, FSN NSDB authentication information in junctions, and FSL NSDB authentication information in FSNs, does seem to me to be worth noting. [*] For example, assuming many FSNs but relatively few NSDBs, filesystem implementors could choose store FSNs as {reference to NSDB name, FSN object name relative to NSDB}. If the second item of the tuple is itself fixed-sized then the whole tuple can be fixed sized. A table of {NSDB name, reference} would be needed too, but it may be critical to keep "inodes" fixed-sized, with little wastage, in which case "interning" NSDB names as described above is a sufficient compression technique. In fact, draft-ietf-nfsv4-federated-fs-protocol-03 does use UUIDs for naming FSNs and FSLs, so that the above technique is certainly a feasible way to keep inodes fixed-sized in spite of the fact that FSNs are actually variable sized (the NSDB name where the FSN resides is part of the FSN's name). Nico --