Subject: [nfsv4] Last Call: <draft-ietf-nfsv4-federated-fs-dns-srv-namespace-08.txt> (Using DNS SRV to Specify a Global File Name Space with NFS version 4) to Proposed Standard

From: The IESG <[email-masked]>
Date: Fri, 09 Sep 2011 15:33:26 -0700

The IESG has received a request from the Network File System Version 4 WG
(nfsv4) to consider the following document:
- 'Using DNS SRV to Specify a Global File Name Space with NFS version 4'
  <draft-ietf-nfsv4-federated-fs-dns-srv-namespace-08.txt> as a Proposed
Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
[email-masked] mailing lists by 2011-09-23. Exceptionally, comments may be
sent to [email-masked] instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract

   The NFS version 4 protocol provides a natural way for a collection of
   NFS file servers to collaborate in providing an organization-wide
   file name space.  The DNS SRV RR allows a simple and appropriate way
   for an organization to publish the root of its name space, even to
   clients that might not be intimately associated with such an
   organization.  The DNS SRV RR can be used to join these organization-
   wide file name spaces together to allow construction of a global,
   uniform NFS version 4 file name space.

The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-nfsv4-federated-fs-dns-srv-namespace/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-nfsv4-federated-fs-dns-srv-namespace/

No IPR declarations have been submitted directly on this I-D.

---

From: RJ Atkinson <[email-masked]>
Date: Sat, 10 Sep 2011 12:02:16 -0400

> beginning of the Subject line to allow automated sorting.

I am not an active participant in the NFSv4 WG, and 
I am not on their mailing list, but I have reviewed 
and am familiar with this I-D.

In principle, I support publishing it as a standards-track RFC.
I have some minor concerns that I would like to see resolved
prior to approval for standards-track RFC.  I believe these 
are each simple and easy to resolve.

1.  Terminology
	The term "spoofed" is jargon; its meaning is often unclear
	to people unfamiliar with the jargon.  The dictionary word is
	"forged".  Using the dictionary word ensures that the intended
	meaning is clear, not only to native English readers who might be
	unfamiliar with the jargon, but particularly also to non-native 
	readers of English.

	PROPOSED EDIT:  s/Spoofed/Forged/    

2.  NFS Client Authentication
	It is not clear from reading this document how a potential 
	NFSv4 client would learn which authentication method(s) 
	should be used/attempted with the NFSv4 server(s) that have 
	these SRV records associated with their fully qualified 
	domain-names (i.e. DNS owner names).  Some NFSv4 server 
	deployments use Kerberos, while other NFSv4 server deployments
	do not use Kerberos.  So this issue is practical and
	likely to arise in actual NFSv4 deployments.

    	PROPOSED RESOLUTION APPROACH:

	If there is some method whereby an NFSv4 client can learn which
	authentication method to use with an NFSv4 server that has a
	NFS SRV record published in the DNS, this ought to be made clear.
	Potentially this is as simple as a few sentences referring to a 
	specific section in some other already-published NFS-related RFC.

	If there is not any method whereby an NFSv4 client can learn which
	authentication method to use with an NFSv4 server that has an NFS
	SRV record published in the DNS, this fact ought to at least be
	documented (probably in Security Considerations).  In this case,
	it also seems fair to ask the authors whether it would be practical
	to structure this SRV record usage in a manner that would provide
 	a hint or (better) a clear indication of which authentication 
	method(s) to use wit this NFSv4 server.

3.  Use in existing Multicast DNS/DNS Service Discovery deployments
	mDNS and DNS-SD are very very widely deployed today, in many
	different operational environments, and are supported in most
	major operating systems (e.g. no-cost implementations exist
	for MacOS X and Microsoft Windows; at least one open-source
	implementation exists for UNIX).  The IETF seems to be
	(very slowly) moving towards standardisation of these two
	technologies.

	PROPOSED RESOLUTION:

	Please add a paragraph describing how this proposed SRV record format 
	would relate to and potentially interact with the existing widespread
	DNS Service Discovery and Multicast DNS deployments.  If such deployment
	would create security issues, those ought to be added to the Security
	Considerations section of this document.

This note is being sent to the NFSv4 mailing list, with a copy
to the IESG.  As I am not a member of the NFSv4 mailing list,
it is quite possible that this note would be caught in a
non-subscriber/spam filter covering that list.  There seems 
little point in bothering the entire IETF discussion list 
for this particular note, so I decline to do so.

Yours,

Ran Atkinson

---

From: Robert Thurlow <[email-masked]>
Date: Mon, 12 Sep 2011 09:56:04 -0600

> 	PROPOSED EDIT:  s/Spoofed/Forged/    

I support this change.

> 	method(s) to use wit this NFSv4 server.

We should describe this.  In my opinion, this is a read-only
connectivity solution that should be accessible by any security
flavor, including AUTH_NONE and AUTH_UNIX, like the server
namespace solution in RFC 3530.  All implemented security flavors
should be supported on the root fileservers.  If a client uses
RPCSEC_GSS with Kerberos V5 and the server is not configured for
it, the usual WRONGSEC exchange should suffice.

> 	Considerations section of this document.

I support this change.

Rob T

---

From: Nico Williams <[email-masked]>
Date: Mon, 12 Sep 2011 11:13:21 -0500

>        PROPOSED EDIT:  s/Spoofed/Forged/

It's all jargon :)  I like spoofed.  If necessary I'd be OK with
putting forged in parenthesis after spoofed.

(Are our glossaries up to date?  Is this a matter of updating our
glossaries to have current jargon^H^H^H^H^H^Hterminology?  Maybe we
need an IANA-managed glossary, probably with expert review and fcfs
rules :)

>        likely to arise in actual NFSv4 deployments.

NFSv4 has a security mechanism negotiation facility.  None need be added here.

>        NFS SRV record published in the DNS, this ought to be made clear.

Clearly implementors of this I-D have to be familiar with NFSv4, and
thus they would know that NFSv4 provides a security mechanism
negotiation facility.

Would there be any harm from mentioning that here?  Yes: we can't
repeat everything that is potentially relevant from other RFCs in
every new RFC.  It suffices that we have the proper normative
references.

>        (very slowly) moving towards standardisation of these two

I'm not sure what you have in mind.  Multicast in general, and mDNS in
particular, might be appropriate for *local* NFSv4 domain root
discovery, but not for Internet-scale NFSv4 namespace construction.
But I probably misunderstood what you meant.

>        Considerations section of this document.

Do you have proposed text?

Nico
--

---

From: RJ Atkinson <[email-masked]>
Date: Mon, 12 Sep 2011 12:54:37 -0400

> putting forged in parenthesis after spoofed.

I'm terribly sorry, but that would not be adequate to resolve 
my concern.  "Spoof" isn't actually a word in the English language.

We ought to be trying to stick to well-defined and very clear terms 
whenever possible.  In this case it is easy to use a well-defined 
and very clear term, since the "Forged" is the correct dictionary term.

> every new RFC.  It suffices that we have the proper normative

This document is not only for implementers.  

This document also will be read by potential users of NFS and of this 
particular DNS SRV extension, for example those who want to understand 
potential operational implications, including operational security implications.  

The IETF does not expect, nor should we, all users of NFS to be experts 
at all implementation details.  Also, the IETF tries to make its specifications
and other documents accessible to users, as well as to implementers.

There would be much benefit and zero harm to add a sentence or three
pointing folks to the parts of the existing documentation that 
cover "the security mechanism negotiation facility" of NFSv4.

> Do you have proposed text?

I proposed that the authors add text PRECISELY because it is not clear
to me (as an NFS user and mDNS/DNS-SD user) how they will interact/relate.  
It seems obvious there will be non-zero interaction/relationship 
between this record and DNS-SD/mDNS deployments.  If this hasn't been
considered by the authors, that would tend to indicate that the 
proposal is not ready for publication as an RFC and that the authors
need more time to think through the details of their proposal.

Folks proposing new SRV record usages ought to describe those interactions, 
rather than make users guess about such interactions.

GENERAL:
I do not understand Nico's apparent hostility to the several 
small/easy clarifying edits I have proposed.  None of my proposals
ought to be controversial.  I'm baffled.

Yours,

Ran Atkinson

---

From: Thomas Haynes <[email-masked]>
Date: Mon, 12 Sep 2011 12:09:29 -0500

> my concern.  "Spoof" isn't actually a word in the English language.

I'll forgo wikipedia, but http://dictionary.reference.com/browse/spoof

> and very clear term, since the "Forged" is the correct dictionary term.

And also:
http://foldoc.org/spoof

"spoof" is a common computer term.

---

From: Spencer Shepler <[email-masked]>
Date: Mon, 12 Sep 2011 17:12:51 +0000

Ran's point is valid and the document author can make the final
decision about the language selection and any parenthesis that
might be used.

Now, let's move on to the larger issues that have been raised.

Spencer

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Thomas Haynes
> Sent: Monday, September 12, 2011 10:09 AM
> To: RJ Atkinson
> Cc: [email-masked]
> Subject: Re: [nfsv4] Last Call: <draft-ietf-nfsv4-federated-fs-dns-srv-
> namespace-08.txt> (Using DNS SRV to Specify a Global File Name Space with
> NFS version 4) to Proposed Standard
> 
> 
> > I'm terribly sorry, but that would not be adequate to resolve my
> > concern.  "Spoof" isn't actually a word in the English language.
> 
> > whenever possible.  In this case it is easy to use a well-defined and
> > very clear term, since the "Forged" is the correct dictionary term.
> 
> 
> And also:
> http://foldoc.org/spoof
> 
> _______________________________________________
> nfsv4 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/nfsv4

---

From: "Spencer Shepler" <[email-masked]>
Date: Mon, 12 Sep 2011 10:15:45 -0700

SM,

I am forwarding your comments to the WG list and document
authors so they have a chance to be commented upon.

Spencer

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of SM
Sent: Monday, September 12, 2011 2:57 AM
To: [email-masked]
Subject: Re: Last Call:
<draft-ietf-nfsv4-federated-fs-dns-srv-namespace-08.txt> (Using DNS SRV to
Specify a Global File Name Space with NFS version 4) to Proposed Standard

At 15:33 09-09-2011, The IESG wrote:
>   <draft-ietf-nfsv4-federated-fs-dns-srv-namespace-08.txt> as a 
>Proposed Standard
>

 From Section 3:

   "We propose the use of the DNS SRV resource record type [RFC2782] to
    fulfill this function"

However, the IANA Considerations section says "None".

I suggest that the working group at least puts in a minimal effort in filing
the IANA book-keeping details.

   "As with the AFSDB resource record type [RFC1183], the
    client need only utter the (relatively) constant domain name for an
    organization in order to locate its filesystem name space service."

RFC 5864 deprecates the use of the AFSDB RR to locate AFS cell database
servers.

There are a lot of SHOULDs in this draft.  The following sentence in Section
5 looks odd:

   "NFS clients compliant to this standard MUST implement this
    functionality."

Although draft-ietf-nfsv4-federated-fs-dns-srv-namespace-08 is well-written,
it is unclear to me why the SRV RR is not defined according to RFC 2782.

 From Section 3:

   "In order to allow the NFSv4 servers so given to export a variety of
    filesystems, those file servers SHOULD export the given domain's root
    filesystems at "/.domainroot-{Name}" within their pseudo-filesystems,
    where the "{Name}" is the name of the organization as used in the SRV
    RR."

Given the normative references to STD 13, it would be better to align the
wording with DNS terms.

In Section 4.3:

  "A further refinement is advisable, and SHOULD be deployed"

It is not possible to mandate deployment.

In Section 5:

   "In either case, the result of the DNS lookup should be cached
    (obeying TTL) so that the result could be returned more quickly
    the next time."

There is some discussion in RFC 5864 and errata about TTLs.

Regards,
-sm 

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

---

From: Robert Thurlow <[email-masked]>
Date: Mon, 12 Sep 2011 11:16:40 -0600

> discovery, but not for Internet-scale NFSv4 namespace construction.

Hi Nico,

I thought you could use mDNS mechanisms to query DNS information
in general, with non-authoritative information coming from a peer.
I would find it reasonable to set expectations for the interaction
between these features, even in brief.

Rob T

---

From: Chuck Lever <[email-masked]>
Date: Mon, 12 Sep 2011 15:11:13 -0400

> But I probably misunderstood what you meant.

I agree that mDNS is possibly not appropriate for wide-area domain root discovery.  Wide area discovery may be appropriate for a separate I-D, however.

Some of us have already considered mDNS for local domain root discovery.  In my opinion, it would be a positive addition to this draft to have a standard local domain root discovery mechanism other than "assume your own domain name is the local FedFS domain."

It's been problematic for NFSv4 implementations, for example, that no standard mechanism exists for discovering the local NFSv4 ID map domain space (other than "assume your own domain name is your ID map domain").  To resolve this issue, implementations I'm aware of use persistent configuration state on clients or a non-standard discovery mechanism.

A goal of FedFS is to reduce client administration burden.  I'd rather not see FedFS require more persistent configuration state added to FedFS-enabled clients.

We should resolve this now for FedFS.

-- 
Chuck Lever
chuck[dot]lever[at]oracle[dot]com

---

From: Spencer Shepler <[email-masked]>
Date: Mon, 12 Sep 2011 19:23:05 +0000

> Sent: Monday, September 12, 2011 12:11 PM
> To: [email-masked]
> Cc: RJ Atkinson
> I agree that mDNS is possibly not appropriate for wide-area domain root
> discovery.  Wide area discovery may be appropriate for a separate I-D,
> however.
> 
> Some of us have already considered mDNS for local domain root discovery.
> In my opinion, it would be a positive addition to this draft to have a
> standard local domain root discovery mechanism other than "assume your own
> domain name is the local FedFS domain."
> 
> It's been problematic for NFSv4 implementations, for example, that no
> standard mechanism exists for discovering the local NFSv4 ID map domain
> space (other than "assume your own domain name is your ID map domain").
> To resolve this issue, implementations I'm aware of use persistent
> configuration state on clients or a non-standard discovery mechanism.

Are you referring to this one that is in Solaris that uses DNS TXT records?
http://download.oracle.com/docs/cd/E19082-01/819-1634/epubp/index.html

And in case we forgot, a very old/expired I-D on the topic:
http://tools.ietf.org/id/draft-ietf-nfsv4-dns-rr-00.txt

Spencer

> 
> A goal of FedFS is to reduce client administration burden.  I'd rather not
> see FedFS require more persistent configuration state added to FedFS-
> enabled clients.
>

---

From: Chuck Lever <[email-masked]>
Date: Mon, 12 Sep 2011 15:41:45 -0400

> Are you referring to this one that is in Solaris that uses DNS TXT records?

Yes.

---

From: Nico Williams <[email-masked]>
Date: Mon, 12 Sep 2011 14:45:00 -0500

> need more time to think through the details of their proposal.

I believe there's no relationship nor interaction between this and mDNS.

mDNS *could* be used to locate a *local* domain root via these SRV
RRs, but not any other domains' roots, therefore it has too little
value for NFSv4 domain root location purposes.

Is it now a requirement that any document that specifies the use of
*DNS* RRs should also say anything about mDNS?  I was not aware of
such a requirement.  I do not oppose such a requirement, but I would
find it odd.

> rather than make users guess about such interactions.

If we didn't mention mDNS, then I think it's fair that we expect no
interaction with it.

> ought to be controversial.  I'm baffled.

I meant no hostility.  I had a smiley to denote the lack of hostility.
 I meant to communicate skepticism rather than hostility.

Regarding terminology: I don't understand the problem with "spoofed".
Someone else could come along and propose some other such change, and
at some point we're just picking nits.  Perhaps the fault lies in me
for not realizing that "spoof" is actually quite misunderstood.
However, I really don't care very much about that particular issue.  I
care rather more about the mDNS case, and there I propose to say
nothing more than "there's no expected interaction with mDNS".  I
asked you to propose text because I wasn't sure what interactions you
had in mind.  Now I understand that you were asking what interactions
there could be.

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Mon, 12 Sep 2011 14:51:09 -0500

> Some of us have already considered mDNS for local domain root discovery.  In my opinion, it would be a positive addition to this draft to have a standard local domain root discovery mechanism other…

I think the latter is quite appropriate, particularly given that we
have DHCP and other discovery mechanisms for discovering client
configuration parameters, which is what "local domain" is, as far the
client goes.  How would these SRV RRs in mDNS help a client find its
domain?  We'd need a TXT RR for that.

> It's been problematic for NFSv4 implementations, for example, that no standard mechanism exists for discovering the local NFSv4 ID map domain space (other than "assume your own domain name is your…

That's a completely different issue though!  It has to do with the way
Unix name services for users and groups work, and it has nothing to do
with FedFS.  There's a whole separate I-D for dealing with ID mapping
for NFSv4.

Nico
--

---

From: RJ Atkinson <[email-masked]>
Date: Mon, 12 Sep 2011 16:43:08 -0400

> value for NFSv4 domain root location purposes.

I'd propose adding a slight edit to that sentence above 
for addition to the specification.  

Candidate new text for the I-D follows:

	"It is not expected that this DNS SRV record format will be
	used in conjunction with Multicast DNS (mDNS) or DNS Service 
	Discovery (DNS-SD).  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 with DNS-SD 
	has too little value for locating NFSv4 domain roots."

> such a requirement.  I do not oppose such a requirement, but I would

As a practical matter, any document that specifies use of SRV
records really ought to discuss (expected/possible) interactions
of that SRV type with mDNS and DNS-SD.

At present, and for the foreseeable future, that combination 
(i.e. mDNS + DNS-SD) is the dominant use of SRV records 
in the deployed world -- by some very wide margin.  Put another
way, multicast access of SRV records is much much more common
than unicast access of SRV records.

> If we didn't mention mDNS, then I think it's fair that we expect no

Omission of the most common deployed use of SRV records begged the question.   
I'm pleased to hear you didn't overlook the case, but would hope you'd add 
some brief clarifying text (specific text proposal above, modeled on
the words you provided).

> Regarding terminology:   Perhaps the fault lies in me

I believe it is quite confusing, especially to non-native readers
of English.  I have had to explain that term in the past more than
once to non-native readers, who patiently had tried to look up
the non-word "spoof" in their dictionaries -- without success.

Yours,

Ran Atkinson

---

From: Nico Williams <[email-masked]>
Date: Mon, 12 Sep 2011 15:51:07 -0500

>        has too little value for locating NFSv4 domain roots."

+1

> than unicast access of SRV records.

I see.  Fair enough!

> the non-word "spoof" in their dictionaries -- without success.

I've had the same problem.  However, I've observed so many different
sets of different (and at times partially conflicting) terminology,
even within the IETF Security area, that I've given up trying to unify
them.  I carry a terminology dictionary, embedded in my brain.
Perhaps I'm just more jaded than you are in this respect :(

Nico
--

---

From: RJ Atkinson <[email-masked]>
Date: Mon, 12 Sep 2011 16:52:15 -0400

> NFSv4 has a security mechanism negotiation facility.  None need be added here.

Candidate new text for 'Security Considerations' for this I-D:

	"NFSv4 has a security mechanism negotiation facility,
	specified in Section A.B of RFC-XXXX, so there is no
	need for this SRV record use definition to indicate 
	which security method(s) an NFSv4 client should use 
	when contacting the specified NFSv4 domain root."

As an ordinary user, I have no idea off-hand what the values "A.B" 
or "RFC-XXXX" are; I hope the fragment above is sufficient to clarify 
what kind of edit I'd like to see made.

Yours,

Ran Atkinson