Subject: Re: [nfsv4] Fwd: [[email-masked]: I-D ACTION:draft-mesta-nfsv4-domain-00.txt]

From: Rick Mesta <[email-masked]>
Date: Mon, 1 Nov 2004 09:41:17 -0600

On Fri, Oct 29, 2004 at 12:35:20PM -0400, Ted Anderson wrote:
| On 10/21/2004 18:56, Rick Mesta wrote:
| >	Title		: NFSv4 Cross-Domain Considerations
| >	Author(s)	: R. Mesta
| >	Filename	: draft-mesta-nfsv4-domain-00.txt
| >	Pages		: 9
| >	Date		: 2004-10-21
| >	
| >The purpose of this document is to elicit discussion on configuration
| >   schemes for determining the domain name to be used by NFSv4
| >   implementations that do not natively support users and groups from
| >   multiple domains.
| >
| >   This document also describes a method by which NFSv4 clients and
| >   servers can discover a domain name value appropriate for qualifying
| >   NFSv4 user and group names, by leveraging DNS TXT resource records.
| >
| >A URL for this Internet-Draft is:
| >http://www.ietf.org/internet-drafts/draft-mesta-nfsv4-domain-00.txt
| 
| The concept of this ID seems reasonable.
| 
| I wonder, though, if it wouldn't be better to avoid adding yet another 
| undifferentiated usage of DNS TXT resource records and instead expand 
| the use of a more application specific RR.  I was thinking you might use 
| a new subtype of the AFSDB record.  Subtype 1 and 2 apply to AFS and 
| DFS, respectively, so subtype 3 could be NFSv4IDMAP.  Since AFSDB 
| records already apply to the application domain shared by NFSv4, namely, 
| distributed file systems, this would seem logical.  Further, the domain 
| of AFS and DFS users is usually (though not necessarily) defined by the 
| name of the AFSDB record, so the usage is even similar.
| 
| The analogy is not exact, however, since the AFSDB record identify 
| servers given a domain, while the intent of the NFSv4IPMAP reords is to 
| identify domains give a (client or server?) host.  Still, it seems 
| better to aggregate DNS records for distributed file systems rather than 
| dump them into the vast pool of TXT record uses.
| 
| Ted Anderson

	Thx for your feedback, Ted...

	Indeed, we are aware of the fact that overloading a DNS TXT RR
	is non-kosher w/in the IETF community and thus the reasoning for
	the wording of section 2.3 (second paragraph).

	We took a calculated risk of using DNS TXT RR's in the Solaris
	mapping mechanism implementation as we felt that once this I-D
	went out, we could gain consensus as to what the right approach
	would be to accomodate most of the NFSv4 implementors. 

	In short, I also believe that the long term solution (barring a
	more general mapping scheme) should be to add a new application
	specific record for holding the domain name for NFSv4 id mappings.

		rick

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

---

From: Bill Sommerfeld <[email-masked]>
Date: Mon, 01 Nov 2004 17:06:37 -0500

> | name of the AFSDB record, so the usage is even similar.

I pointed the subtyping problem out to Rick when the proposal went
through internal review at Sun.

But subtyping AFSDB has the same (conceptual) problem as subtyping TXT. 

as I understand it (mostly repeating rote what I've learned from
others):

subtypes of any kind are bad news, because it means that clients have to
filter the retrieved resource records and can't just ask for the precise
type they want -- you wind up possibly needing to fail over to TCP for
queries, you complicate signature validation and dynamic update, etc.,
etc.,