Hi,
Thanks, Joe, for the thoughtful review.
Extracting some light from yesterday's discussion and RFCs 6335 and
2782, much of the contention seems to be around whether there could be
two assigned names for related services that both happen to be provided
over a given assigned port number.
I'd like to propose an adjustment of the request, in light of the RFC
text, and ask your judgment on how that adjusted request would fit
within the services rubric that's outlined.
In RFC 6335, explicit room is carved out for "assigned service name[s]
without [a] corresponding fixed port number" with explicit reference to
RFC 2782. Such a service name assignment would be completely adequate
for purposes of the "NFS domain root" concept. As I read RFC 6335, such
assignments are RECOMMENDED, and that IANA strives to assign such names
under a first-come first-served policy (with reference to RFC 5226).
In this formulation, the existing "nfs" service could stand unaffected.
The proposed service, "nfsdomainroot", would request name assignment
without a port number. The NFS client would seek SRV records under
names such as "_nfsdomainroot._tcp.example.com". The result processing
would continue as before, with SRV records indicating the hosts
providing NFS service for the root of "example.com"'s file system.
The SRV record then includes the port number on which the target NFS
hosts provide "nfsdomainroot" service, which is given as an application
of the NFS protocol in the subject I-D (including a mount point).
The I-D would also need to propose, in the IANA section, that IANA
assign the service name
SRV nfsdomainroot TCP
to this protocol. UDP service name allocation is unnecessary.
In the judgment of the TSVDIR, would this take the I-D in a more
acceptable direction?
Craig
-----Original Message-----
From: Joe Touch [mailto:touch(_at_)isi(_dot_)edu]
Sent: Sunday, September 11, 2011 4:12 PM
To:
draft-ietf-nfsv4-federated-dns-srv-namespace(_at_)tools(_dot_)ietf(_dot_)org;
tsv-
ads(_at_)tools(_dot_)ietf(_dot_)org; ietf(_at_)ietf(_dot_)org;
nfsv4(_at_)ietf(_dot_)org
Cc: tsv-dir(_at_)ietf(_dot_)org
Subject: [nfsv4] TSVDIR review ofdraft-ietf-nfsv4-federated-dns-srv-
namespace
Hi, all,
I've reviewed this document as part of the transport area
directorate's
ongoing effort to review key IETF documents. These comments were
written primarily for the transport area directors, but are copied to
the document's authors for their information and to allow them to
address any issues raised. The authors should consider this review
together with any other last-call comments they receive. Please always
CC tsv-dir(_at_)ietf(_dot_)org if you reply to or forward this review.
This document describes the use of DNS SRV records to coordinate NFS4
use and a global file namespace across a groups of clients and
servers.
There are no transport protocol issues in this document. The key
transport issue is the definition of a new DNS SRV record and its
associated syntax.
There are issues with the intended syntax of the proposed DNS SRV
record. The current syntax is defined in RFC 2782 as:
_service._transport.NAME
service is an IANA SRV name, the namespace of which is defined
in
RFC 6335
transport is _TCP or _UDP
NAME is a DNS FQDN
Given other considerations below (on versioning), the record should be
one of the following
_nfs._tcp.example.com TTL Class SRV Priority Weight Port Target
_nfs._udp.example.com TTL Class SRV Priority Weight Port Target
All other information specific to the exchange, e.g., organization
(which may or may not be a suffix of the Target, FWIW), desired mount
point, and various NFS-specific capabilities (e.g., mount options)
ought to be expressed in an associated TXT record as defined fields,
as
is the case with other services that use SRV records. These options
can
have defaults if not otherwise present.
Some other issues are discussed below.
Overall, the above is the key concern, and needs to be addressed
before
proceeding. Issues below are indicated as either critical or
suggestions for clarification.
Joe
------------------------
Critical issues:
- the IANA section is incomplete
This document needs to request IANA assign an SRV service name, e.g.:
SRV nfs TCP
SRV nfs UDP
It is not clear whether an additional assignment of "SRV nfs SCTP" is
required; recent discussions on other SCTP SRV uses suggest that UDP
is
indexed in these cases instead. This might warrant further discussion.
- the service name should not include the version number
As per RFC 6335, and to be consistent with the existing port
assignments for NFS Version 4.
- the discussion of list of organizations as with root.afs should be
described in a little more detail
The current sentence is a bit cryptic; this could be a full paragraph,
perhaps with an example.
- there is no appropriate place to indicate write vs read-only in the
DNS request
The DNS request should return all available options, and indicate
write
vs. read-only in the associated TXT records. The client should then
determine which is desired.
----------------------
Other issues (intended as suggestions):
- version 4
Throughout this document, "version 4" is used wherever NFS is used.
Since V4 (more specifically, 4.1) is the current common version, it
does not seem necessary to include this marking in most places except
where differences in the NFS versions are being highlighted.
- colloquial advice
Terms like "appropriate" and "useful" should be removed throughout.
They represent judgements whose evaluation criteria is not discussed.
- overall writing style
The document is written in the tense and style of a proposal. It
should
be revised to read as the intended specification it will become. "We
propose" and "We use", and similar styles should be replaced with
"this
document specifies" and "this record uses".
- clarify overloaded terms
Terms like "root" and "name space" are widely used in different ways
in
the DNS and file systems. Because this document combines the two, each
use should be clarified by a preceding term, e.g., DNS name space or
file system name space, DNS root or file system root.
- the use of RFC 2119 terms should be reviewed
In particular, SHOULD should be used only where a specific exception
is
currently known or suspected, and that exception described. This
provides the motivation for the selection of SHOULD vs. MAY or MUST.
- the discussion of client vs server implementation (sec 4.3, as well
as partly in sec 4.2) should consider client-specific DNS responses
The DNS could provide responses that vary based on the IP of the
client.
This could be a desirable feature. Further, the client knows whether
it
wants write or read-write copies. AFAICT, the client is not only the
better place to implement this capability, it is the only viable
place.
- I found the hidden directory name discussion odd
It does not make sense to overload read-only with directory
visibility;
these are orthogonal issues. The desired mount point should be
indicated in the TXT record; if a default convention is desired, it
should be indicated in the description of that field.
- the AMD reference is only a web page
Not sure which particular reference is best, but a permanent reference
would be useful, e.g.: Matthew Crosby. 1997. AMD-AutoMount Daemon.
Linux J. 1997, 35es, Article 4 (March 1997).
-----
_______________________________________________
nfsv4 mailing list
nfsv4(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/nfsv4
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf