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

From: RJ Atkinson <[email-masked]>
Date: Tue, 1 Nov 2011 11:58:49 -0400

On 28  Oct 2011, at 10:04 , Everhart, Craig wrote:
> 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.  

I think there is a terminology confusion lurking here, 
either mine or others or everyone's.  For example, 
I wonder whether different people are associating 
different meanings to the phrase "DNS-SD".

For example, I have no idea what "discovery by DNS-SD" 
means in the above quoted text.  

DNS-SD is not a protocol for carrying SRV records,
it is simply the use of DNS SRV records to find services.

Ordinary use of unicast DNS to retrieve an SRV record 
is in fact DNS-based service discovery.

Also, DNS Service Discovery is *entirely separate from* 
the use of Multicast DNS (mDNS), which (I believe) is
why Stuart Cheshire has 2 separate I-Ds.

** Perhaps the quoted text meant to say "discovery by mDNS" ?

If the text above meant to say "discovery by mDNS", 
then that is fine with me.

> Another document could, in the future, define how
> DNS-SD relates to the discovery of file system domain roots.  

Again, I think there is a terminology confusion here.  

In my mind, at least, the whole point of defining this 
SRV record is to enable folks to learn about NFS Domain Roots 
via the DNS -- which is an example of DNS-based service 
discovery.

I think there are some points of agreement 
(please speak up, if I've gotten these wrong):

A) There is no need to cite the Stuart Cheshire's I-Ds.
B) The current text on Multicast DNS limitations is reasonable.

Additionally, I haven't heard objections to these items,
so perhaps there is also agreement here (please speak up 
if I'm confused):

C) RFC-6335 does need to be cited by this I-D, as that RFC
   is an official update to RFC-2782 and therefore applies
   to any new SRV record definitions.
D) The current text for the NFS Domain Root does not comply
   with RFC-6335 and needs to be edited to comply with RFC-6335.

Confusedly yours,

Ran

---

From: "Everhart, Craig" <[email-masked]>
Date: Tue, 1 Nov 2011 14:13:02 -0400

Hi, Ran,

I'm confused.  What is it that you meant by DNS-SD?

I'm trying to make sense of the pieces of DNS-SD that I'm aware of,
including both the site you cite (couldn't resist) and Chapter 5 of
Stuart Cheshire's Bonjour book.  I've tried to avoid downloading
somebody's source code and trying to figure out the protocols from that.

As far as I can tell, DNS-SD is a collection of at least three levels of
discovery.

(1) "Domain enumeration", inviting clients to browse "interesting"
domains
    This is done with prefixes for the given target domain
(example.com):
        b._dns-sd._udp.example.com. PTR <some-domain-here>
                                    PTR <other-domain-here>
    Other prefixes other than "b" may be appropriate here; I have little
guidance.

(2) Then there's the "List of named service entities":
    (Assume for now that we use "_nfs._domainroot")
    _nfs._domainroot._tcp.<some-domain-here> PTR Descriptive\
Name.example.com
                                             PTR Other\ Name.example.com

(3) Now the SRV (and TXT) records "describing each service entity named"
in (2)
      Descriptive\ Name._nfs._domainroot.example.com. SRV 0 0 2049
srv1.example.com.
      Other\ Name._nfs._domainroot.example.com.       SRV 0 0 2049
srv2.example.com.

Interestingly, each of (1) and (2) are ways to map from one name to
possibly many names.  Both levels appear to me to be types of discovery
that could be carried out over a WAN.

SRV records, used in (3), are obviously one-to-many names as well, but
those names aren't for presentation to users.

In any case, the one-to-many name mappings of (1) and (2) present
wrinkles to NFS that, to me, are an independent use of wide-area
discovery.  (I talked about the wrinkle in a message to the list on
Friday.)  I don't want to preclude someone defining this in the future,
but there's benefit even in just the simpler DNS use that the draft
describes.  Do you feel this an unreasonable position?

Thanks for your concurrence on the mDNS text.  Draft -10 cites RFC 6335.

		Craig

> -----Original Message-----
> From: RJ Atkinson [mailto:[email-masked]]
> Sent: Tuesday, November 01, 2011 11:59 AM
> To: [email-masked]
> Subject: Re: [nfsv4] I-DAction:draft-ietf-nfsv4-federated-fs-dns-srv-
> namespace-10.txt
> 
> 
> _______________________________________________
> nfsv4 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/nfsv4

---

From: RJ Atkinson <[email-masked]>
Date: Tue, 1 Nov 2011 14:59:34 -0400

On 01  Nov 2011, at 14:13 , Everhart, Craig wrote:
> I'm confused.  

(I've been confused by this thread for a while,
so that makes at least 2 of us now.  :-)

> What is it that you meant by DNS-SD?

Any use of DNS to discover services -- such as 
using an SRV record to determine the "Domain Root" 
for a given DNS FQDN.

Please let me propose a very slight revision to 
Section 4.4 -- with the goal being to side-step 
the question of what one means by "DNS-SD".

Candidate text:

   4.4.  Multicast DNS

   Location of the NFS domain root by this SRV record 
   is intended to be performed unicast by using the 
   IETF standard DNS protocol.

   It is not expected that this DNS SRV record format 
   will be used in conjunction with Multicast DNS (mDNS).  
   While mDNS could be used to locate a local domain root 
   via these SRV records, no other domain's root could be 
   discovered.  This means that mDNS has too little value
   to use in locating NFSv4 domain roots.

> Draft -10 cites RFC 6335.

Great.  

I see the syntax was also sorted out in -10, 
which is also great.

Thanks,

Ran