Re: TSVDIR review of draft-ietf-nfsv4-federated-dns-srv-namespace

Hi Keith,

On 9/11/2011 1:22 PM, Keith Moore wrote:
> 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.
We've been discussing this in the Transport area lately.

DNS SRVs are defined in RFC 2782 as I have described. Additional info is 
passed in TXT records for current DNS SRVs.
I.e. what I have proposed is what is both current spec and current 
widespread practice.
Before proposing a change (which would need to happen before we would 
use it in a new spec anyway), is there something the current syntax (and 
use of TXTs for additional info) cannot do that you want?
Joe

> 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