Subject: [nfsv4] Re: draft-mesta-nfs4id-dns-rr-01

From: Rick Mesta <[email-masked]>
Date: Wed, 18 May 2005 11:32:39 -0500

Hi Olaf,

	 And thx for posting to the alias =:),

	<in-lined comments below...>

On Mon, May 09, 2005 at 03:02:00PM +0200, Olaf M. Kolkman wrote:
| 
| 
| Dear colleagues,
| 
| 
| Rick Mesta has recently posted the following I-D:
|  A DNS RR for NFSv4 ID Domains
|  draft-mesta-nfs4id-dns-rr-01
| 
| The document would benefit from some review by the DNS community.
| 
| I've had some private communication with the editor and one of the issues
| that came up during the conversation was that the NFS client is supposed
| to know its "default domain".
| 
| (The "default domain" being what e.g. the res_init() function would
| return).
| 
| AFAIK the "default domain" is not something that is part of the DNS
| specs but I am afraid I am overlooking something. What would be a
| proper specification or reference for the "default domain"?

	In case there is no bonafide DNS specification DNS for a
	"default domain", I wonder if having "default domain" be
	loosely defined as being an Operating Environment artifact
	(e.g. the configured /etc/resolv.conf domain, for UNIX type
	systems) would be good enough for a specification.

	Thoughts ?

		rick
| 
| Please try to CC the list on issues that are within scope and try to
| keep out-of-scope issues off list.
| 
| Thanks a lot.
| 
| -- Olaf
| 
-- 

_______________________________________________
nfsv4 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nfsv4

---

From: Rick Mesta <[email-masked]>
Date: Tue, 31 May 2005 17:35:56 -0500

Hi Rob / Andreas,

	 I believe we're slowly diverging from the original intent
	of this draft.

	 In the I-D, I incorrectly emphasized the aspect of "default
	domain" and how it is derived when using it as a motivating
	example. It is primarily an implementation suggestion to use
	the DNS domain as the NFSv4 domain in the absence of other
	configuration information. I would have been more correct to
	talk about the use of the "current DNS domain".

 	 What we're really trying to accomplish by the introduction
	of the NFS4ID RR is to provide a way to determine the NFSv4
	domain name for a given DNS domain.

	 NFSv4 clients and servers may interact with multiple other
	clients and servers in many different DNS domains. While it
	is suggested that the NFSv4 domain be exactly the DNS domain,
	it is not required. Therefore, for the system to use the
	correct domain for user and group, it needs to know what the
	NFSv4 domain, for the given DNS domain, is.

	DHCP is primarily for providing per-host configuration
	parameters. Not unlike an MX record, the NFSv4 domain is
	a per DNS domain parameter.

	Using a DNS record allows:

        1) A DNS domain wide configuration of a NFSv4 domain name
	   that is different from the DNS domain. For example, a
	   domain hierarchy that has a flat user space may want a
	   common "foo.com" NFSv4 domain similar to how organizations
	   place all e-mail accounts in the highest common domain.

        2) An NFSv4 node may be interacting with multiple other
	   nodes in different domains and need to know the other's
	   NFSv4 domain name. The interaction may be dynamic and
	   such that there is no apriori knowledge of which domains
	   it will access. Thus it is not reasonable to configure
	   DHCP to provide all possible domains via DHCP.

	3) NFSv4 is not necessarily a single per-host service. There
	   are user level (e.g. browsers) implementations that may
	   not desire to have the common per-host DHCP parameters.

	The NFSv4 domain name is a per domain network parameter that
	needs also to be visible between domains. Therefore, a per
	host protocol such as DHCP is not appropriate.

		rick

On Fri, May 27, 2005 at 02:20:57PM +0300, Andreas Gustafsson wrote:
| I have some comments on draft-mesta-nfs4id-dns-rr-01.
| 
| As others have pointed out, the DNS protocol and the DNS standards
| have no concept of a "default domain".  Some stub resolver
| implementations do, but even there it tends to be deprecated in favor
| of a "domain search list".
| 
| It seems to me that there is no need to create, or any advantage to
| creating, a connection or dependency between NFSv4 and the DNS other
| than simply saying that the thing following the @ has the syntactic
| form of a domain name, and _by convention_ it is equal to some DNS
| domain belonging to the organization at hand.
| 
| Rather than tying the NFSv4 ID to the ill-defined concept of a
| "default domain", it should simply be configured separately, using the
| same mechanisms used to configure other network parameters of the
| host.  Typically this would be DHCP, or if DHCP cannot be used, a
| configuration file.  Instead of defining a NFS4ID RR type, it would
| therefore make more sense to define a NFS4ID DHCP option.
| 
| Regards,
| -- 
| Andreas Gustafsson, [email-masked]

--