The Gen-ART review of the -08 version raised two significant open issues. I will defer to the DNS experts in the INT area to determine whether the changes in the -09 version resolve the issues around the format of the service name in the DNS SRV records [1], although based on IESG Evaluation Record, this issue does not appear to have been resolved, and I strongly recommend a DNS Directorate review of this draft. The -09 version of this draft resolves the UDP issue [2]. I noticed one additional minor issue: Due to the change in primary service name from "_nfs4" to "_nfs", something should be said about the applicability of this draft to versions of NFS other than v4 (e.g., v3). Here's a suggestion for a change in Section 3: OLD: The Service name is "_nfs._domainroot". The Protocol as of this writing could be either "_tcp" or "_sctp"; version 4 NFS is not defined over UDP. Other transport protocols could be defined in the future, and SRV records that advertise domain root file services with other transport protocols would use the same Service name. The Target fields give the domain names of the NFS servers that export filesystems for the domain's root. An NFS client may then interpret any of the exported root filesystems as the filesystem published by the organization with the given domain name. NEW The Service name is "_nfs._domainroot". The Protocol as of this writing could be either "_tcp" or "_sctp"; version 4 NFS is not defined over UDP. Other transport protocols could be defined in the future, and SRV records that advertise domain root file services with other transport protocols would use the same Service name. The Target fields give the domain names of the NFS servers that export filesystems for the domain's root. An NFS client may then interpret any of the exported root filesystems as the filesystem published by the organization with the given domain name. The domain root service is not useful for NFS versions prior to v4, as the fs_locations attribute was introduced in NFSv4 (see Section 2). The "_nfs." Service name prefix is not limited to NFSv4; it is possible to use that prefix to define additional DNS SRV records for services that are also applicable to other versions of NFS (e.g., NFSv3 [RFC1813]). In addition, an informative reference to RFC 1813 should be added . Thanks, --David > -----Original Message----- > From: Black, David > Sent: Friday, September 23, 2011 3:20 PM > To: everhart@xxxxxxxxxx; andros@xxxxxxxxxx; jiayingz@xxxxxxxxxx; gen-art@xxxxxxxx; ietf > Cc: Black, David; nfsv4@xxxxxxxx; Brian Pawlowski; Spencer Shepler; David Harrington > Subject: Gen-ART review of draft-ietf-nfsv4-federated-fs-dns-srv-namespace-08 > > I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at > <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>. > > Please resolve these comments along with any other Last Call comments you may receive. > > Document: draft-ietf-nfsv4-federated-fs-dns-srv-namespace-08 > Reviewer: David L. Black > Review Date: September 23, 2011 > IETF LC End Date: September 23, 2011 > > Summary: This draft is on the right track but has open issues, described in the review. > > This draft specifies the use of DNS to locate the root of a federated filesystem namespace > based on the fs_locations functionality in NFSv4. > > I have two significant open issues: > > [1] There has been an extensive Last Call discussion of this draft, focusing on the use > of a composite two-component service name in DNS SRV records, and the apparent > incompatibility of that format with RFC 2782. This discussion has surfaced a proposed > resolution in the form of unitary single-level service name specified without a port > number. It is *vital* that this proposed resolution be reviewed by DNS experts (probably > the DNS directorate) for consistency with DNS as currently specified and deployed. > Another IETF Last Call may be appropriate, as this change has a significant impact on > this draft, involving a serious rewrite of the portion of Section 4.2 that discusses the > possible use of more than two components in a service name and presents a three-component > example. > > [2] While NFSv4.1 (RFC 5661) is restricted to TCP, this draft also references NFSv4.0 > (RFC 3530) as applicable, and the latter is defined over both UDP and TCP. Unfortunately, > this draft is written as if TCP is the only transport protocol for NFS - that's not the > case for NFSv4.0, so either this draft needs to say something about use with NFSv4.0 over > UDP, or needs to explicitly prohibit use of this DNS SRV record with NFS over UDP. If > the former approach is pursued, RFC 5405 on Unicast UDP Usage Guidelines for Application > Designers is an important consideration in writing that text and RFC 5405 should be > added as an informative reference. > > idnits 2.12.12 ran clean. > > Thanks, > --David > ---------------------------------------------------- > David L. Black, Distinguished Engineer > EMC Corporation, 176 South St., Hopkinton, MA 01748 > +1 (508) 293-7953 FAX: +1 (508) 293-7786 > david.black@xxxxxxx Mobile: +1 (978) 394-7754 > ---------------------------------------------------- > _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf