Subject: Re: [nfsv4] I-D Action:draft-ietf-nfsv4-federated-fs-dns-srv-namespace-10.txt

From: RJ Atkinson <[email-masked]>
Date: Thu, 27 Oct 2011 05:40:37 -0400

Hi,

(ASIDE:		First, I do apologise for the terse form of this email, 
along with whichever spelling/grammar errors I might have made.  I have 
only intermittent network access just now, and I'm writing quite rapidly.  
So please understand that I'm trying to be helpful with this note.)

1) Service Name syntax issue (RFC-6335 compliance)

As near as I can tell, and I've checked with at least one expert,
the I-D does not comply with the rules on Service Names (RFC-6335),
and compliance with that RFC appears to be mandatory for SRV records.
Minor edits to pages 5 & 10 of the I-D might be needed to achieve 
compliance with that RFC.  

For example, RFC-6335 Section 10.1 clarifies that Service Names used 
with SRV records MUST NOT contain certain "illegal" characters, 
such as the 'underscore' character (apparently the 'underscore' is 
prohibited from the Service Name precisely because the 'underscore' 
character is used in a special syntactic way inside SRV records).[1]

I'm not certain, partly because I'm writing this note so quickly,
but I think that a change from the current syntax:

	_nfs._domainroot._tcp IN SRV 0 0 2049 nfs1tr.example.net.

to something more like the syntax below might be required 
for RFC-6335 compliance:

	_nfs-domainroot._tcp IN SRV 0 0 2049 nfs1tr.example.net

2) DNS-SD discussion

Separately, while the discussion in Section 4.4 is correct for the
case of DNS Service Discovery used with Multicast DNS, that discussion 
is incomplete and not correct for the case of ordinary non-multicast 
DNS Service Discovery.  In short, DNS-SD can be used in at least two
different ways:
	(A) in conjunction with Multicast DNS to discover "local" services
	(B) in conjunction with the ordinary DNS to discover services
	    in any DNS domain located anywhere on the Internet.
Several widely deployed desktop OSs have support for the latter form
(B) of DNS-SD.  So that use case seems directly relevant to this I-D.

A quick summary of wide-area (type B above) DNS-SD is available at
this URL:
	http://www.dns-sd.org/
in the section titled:
	- Setting up DNS for Zero-Configuration Wide-Area 
	  Service Discovery by Clients

I'll try to follow up next week (when I expect to have more regular
network access).

Yours,

Ran Atkinson

[1] I am neither a DNS-SD expert nor a DNS syntax expert.  I use both.
    (It might be helpful, and speed publication of this document as an RFC,
    if an expert on both DNS-SD and DNS syntax could be recruited now
    to provide the document authors with a DNS-focused review, to avoid
    accidentally tripping on a DNS issue during IETF review later on. :-)

---

From: Spencer Shepler <[email-masked]>
Date: Thu, 27 Oct 2011 16:33:47 +0000

Ran,

With respect to the DNS-SD discussion, it certainly seems relevant but
given that the DNS-SD work does not have RFCs to reference, I am
trying to decide how best to incorporate a reference to it in this I-D.
With a cursory understanding, that the mechanism defined in this I-D
is separate from DNS-SD usage.  If so, what reference, if any, should
be made to DNS-SD?  If someone wants to define DNS-SD usage for location
of the NFSv4 namespace root, that can be done.

Anyone else have an opinion?

Spencer

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> RJ Atkinson
> Sent: Thursday, October 27, 2011 2:41 AM
> To: [email-masked]
> Subject: Re: [nfsv4] I-D Action:draft-ietf-nfsv4-federated-fs-dns-srv-
> namespace-10.txt
> 
> Hi,
> 
> _______________________________________________
> nfsv4 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/nfsv4

---

From: RJ Atkinson <[email-masked]>
Date: Fri, 28 Oct 2011 04:42:47 -0400

On 27  Oct 2011, at 12:33 , Spencer Shepler wrote:
> With respect to the DNS-SD discussion, it certainly seems relevant
> but given that the DNS-SD work does not have RFCs to reference,

RFC-6335

> I am trying to decide how best to incorporate a reference to it
> in this I-D.  With a cursory understanding, that the mechanism defined
> in this I-D is separate from DNS-SD usage.  

(NB: I'm a long-time DNS user, just as I'm a long-time NFS user,
but I am pretty far from being a DNS expert.  My goal here 
is to encourage simple edits now that will avoid delays later 
in the IETF-track publication process.)

As near as I can tell, DNS service discovery is simply 
an explanation of how DNS SRV records are used, along with 
a discussion of how DNS TXT records might, in some cases, 
be combined with DNS SRV records.  

So anytime a new SRV record type is defined, one is
unavoidably defining DNS records that will be used
to discovery services.

> If so, what reference, if any, should be made to DNS-SD?  

As near as I can tell, this document doesn't need to cite 
the [DNS-SD] Internet-Draft, as I've already noted off-list 
to at least person who asked roughly the same question.  

Purely as an aside, I will note the RFC-6335, which
is an IETF standards-track RFC, does cite [DNS-SD].
So there is some precedent for citing that particular
I-D in an IETF standards-track RFC.

I believe a reference to RFC-6335 is required here, 
since RFC-6335 formally and officially updates RFC-2782,
and RFC-2782 is the definition of DNS SRV records.  

Also, the syntax used for the SRV record defined within 
this I-D needs to comply with RFC-6335, because RFC-6335
formally tightened the syntax rules for SRV records.
I've proposed a minor edit that I think would make
the proposed syntax compliant, but perhaps folks prefer
some slightly different edit that would be equally
compliant.

Cheers,

Ran Atkinson

---

From: "Everhart, Craig" <[email-masked]>
Date: Fri, 28 Oct 2011 10:04:19 -0400

Ran,

To the DNS-SD points, I agree that DNS-SD is related.  I intended the
document to take the position that discovery by DNS-SD is not precluded
by the SRV use specified in this draft, but that such discovery is not
defined in this document.  Another document could, in the future, define
how DNS-SD relates to the discovery of file system domain roots.  Is
that a reasonable position to hold, however we might arrive at language
to describe it?

RFC 6335 indeed offers an informative reference to DNS-SD, but it
appears to be referring to a list of service names, authority for which
has since been transferred to the registry that RFC 6335 describes.

		Craig

> From: Spencer Shepler [mailto:[email-masked]]
> Sent: Thursday, October 27, 2011 12:34 PM
> To: RJ Atkinson; [email-masked]
> Subject: Re: [nfsv4]I-D Action:draft-ietf-nfsv4-federated-fs-dns-srv-
> namespace-10.txt
> 
> 
> Ran,
> 
> >     (It might be helpful, and speed publication of this document as
> an
> > RFC,

---

From: "Everhart, Craig" <[email-masked]>
Date: Fri, 28 Oct 2011 18:21:35 -0400

About NFS using DNS-SD....

The limitations on wide-area discovery are pretty severe in the NFS
context, at least with the regime envisioned in this draft.

With wide-area discovery, the client starts by naming a (likely remote)
domain name.  The way the NFS client would do this is with a vn_lookup
operation.  This operation can succeed or fail, possibly by mounting a
new filesystem underneath the covers, but it really doesn't have the
option of returning a set of possible names.  With the draft as it
stands, what you get under that name is an NFS filesystem (as
"/nfs4/example.com/").

Now there could be other uses of discovered wide-area information.  If
DNS-SD revealed sub-names, they could be seen as, say, a sub-directory
of that /nfs4/example.com/ name, putting their discovered names in the
subdirectory.  Alternatively, using DNS-SD could seed the name cache
under /nfs4/ with any discovered names.

In any case, it feels like a different piece of work to define wide-area
DNS-SD in this context.

		Craig