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(_at_)netapp(_dot_)com; andros(_at_)netapp(_dot_)com;
jiayingz(_at_)google(_dot_)com; gen-art(_at_)ietf(_dot_)org; ietf
Cc: Black, David; nfsv4(_at_)ietf(_dot_)org; 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(_dot_)black(_at_)emc(_dot_)com Mobile: +1 (978) 394-7754
----------------------------------------------------
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf