I've always thought that insistence on the use of RFC 2782 labels with SRV
records unreasonably overconstrained the use of SRV records; and thus, limited
their applicability.
Part of the problem, I suspect, is that at the time that 2782 was being drafted
there may have been some belief that SRV records could reasonably be
retroactively applied to all existing protocols, and thus there would be a need
for a uniform syntax for DNS labels used with SRV records. But if (as is IMO
appropriate) SRV records are only used with applications that are specified to
use them, there is little benefit for the format of DNS labels used with SRV to
be uniform across all uses of SRV.
(I won't say "no benefit". A DNS API designed to facilitate easy SRV record
lookup might benefit from a standard label syntax, but even then, it would make
more sense to not embed that knowledge in the API and let the application
construct the label to be queried.)
So IMO all uses of SRV records should not be constrained to use RFC 2782 DNS
labels.
Keith
On Sep 11, 2011, at 4:12 PM, Joe Touch wrote:
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).
-----
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf