Subject: [nfsv4] [FedFS] Meeting Minutes, 6/3/2010

From: James Lentini <[email-masked]>
Date: Thu, 3 Jun 2010 15:57:43 -0400 (EDT)

FedFS Meeting Minutes, 6/3/2010
-------------------------------

Attendees
---------

Craig Everhart (NetApp)
Sorin Faibish (EMC)
Chuck Lever (Oracle)
Paul LeMahieu (EMC)
James Lentini (NetApp)
Trond Myklebust (NetApp)
Chris Stacey (EMC)
Renu Tewari (IBM)
Robert Thurlow (Oracle)

Minutes
-------

+ IETF Note Well Agreement

  This is a reminder that our discussions are governed by the 
  IETF Note Well Agreement. See:

    http://www.ietf.org/NOTEWELL.html

  We will start each week's meeting with this announcement.

+ Bake-a-thon

  Rob asked who would be bringing FedFS prototypes.

  Rob will be there with his FedFS prototype, an Admin 
  client, and an Admin server. The NFS server will generate 
  FedFS referrals. The tools built into OpenSolaris 
  that work with Solaris referrals have been extended 
  to work with FedFS referrals. Rob has also put together 
  some tools to create NSDB entries. The server code 
  that lookups up an FSN has also been updated. The 
  DNS SRV lookup is not implemented yet. If he has time, 
  Rob would like to work on the DNS SRV support.

  Trond will be there with his FedFS prototype and 
  he has made some updates to the Linux NFS client's 
  referral following code.

  Chuck has been working on an Admin server prototype. 
  He may put together an Admin client.

  Rob suggested that it would also be good to setup 
  some interesting referral test cases like they did 
  last time.

+ NSDB Draft Update

  We reviewed the NSDB draft updates outlined in the agenda:

  http://www.ietf.org/mail-archive/web/nfsv4/current/msg08020.html

  Renu pointed out a typo in Section 4.2.2.2 fedfsFsn and 
  Section 4.2.2.3 fedfsFsl. The text describing these 
  object classes does not match the LDAP schema definitions. 
  The LDAP schema definitions are correct; the fedfsNcePrefix 
  attribute should be removed from the required attribute list 
  in both descriptions.

+ Admin Draft Update

  We reviewed the Admin draft updates outlined in the agenda:

  http://www.ietf.org/mail-archive/web/nfsv4/current/msg08020.html

  Rob suggested that all data types containing UTF-8 strings 
  inherit from a single UTF-8 XDR type. If the FedFS and NFSv4
  types are exactly the same, Rob can potentially reuse some of 
  the NFSv4 UTF-8 string functions.

  James agreed that this would be a good idea. He noted that 
  the NFSv4.1 XDR description was used as a guide for defining 
  the FedFS types (e.g. a FedFsPathComponent). [Editor's Note: 
  After the meeting, I refreshed my memory on this. We did 
  use the NFSv4.1 XDR types as a guide, but since the 
  FedFsPathComponent is the only utf8str_cs string, we defined 
  it using a basic type when it was added in the -03 revision. 
  The potential code reuse Rob identified was not recognized 
  at that time.].

  Rob will review the XDR types and make specific recommendations.

  We discussed the placeholder for international string rules, 
  Section 6 in the draft.

  Chuck suggested that this section might be moved into a 
  subsection of Section 4, which describes the data types.

  James noted that the goal is to have all of the text 
  dealing with these issues in one place. This text will 
  reference rfc3530bis. Moving Section 6 to a subsection of 
  Section 4 would be compatible with that goal.

  Chuck suggested that Section 4.1, FedFsNsdbName Equality, 
  be updated to reference the internationalization section 
  so that domain names were compared consistently.

  Craig noted that we are not defining any new procedures 
  for DNS names. We will be referencing another document,
  rfc3530bis in this case.

  Chuck agreed that this was a good approach.

  James reviewed the procedures for a fileserver to 
  resolve an FSN.

  We discussed if the fileserver should cache the 
  LDAP root DSE, and if so for how long. The consensus 
  appeared to be that the rules in Section 2.4.2 
  "Caching of Fileset Locations" of the NSDB draft 
  were sufficient. We may want to update the text 
  on this point.

  Chunk asked if there had been discussion about adding the 
  NSDB Container location to the NSDB parameters. There had 
  been, but there were drawbacks to this approach. [Editor's 
  Note: I'm unable to recall the meeting this was discussed 
  at. My memory is that there were objections since it 
  would either require all FedFS objects in one namingContext
  or in the same place in different namingContexts.]

  Chuck asked if there had been any further discussion on a 
  procedure to enumerate NSDB Parameters. While there had not 
  been any further discussion on this topic, there was support 
  for discussing this in the future.

+ Meeting Schedule

  We will stick to our regular, fortnightly meeting schedule. 
  Our next meeting will be on June 17, during the Bake-a-thon. 
  We will discuss the schedule for subsequent meetings then.

---

From: Chuck Lever <[email-masked]>
Date: Tue, 08 Jun 2010 13:31:33 -0400

>    http://www.ietf.org/mail-archive/web/nfsv4/current/msg08020.html

  [ ... snip ... ]

>    for DNS names. We will be referencing another document,

RFC 4513 section 3.1.3.1 has some interesting (and quite clear) text 
regarding this issue.  Basically, internationalized DNS names are 
converted to ASCII for storage and collation.  If 3530bis does not have 
a clear description, can I suggest we reference this recommendation when 
storing and collating DNS names in the admin server's NSDB parameters 
database?

Section 3.1.3.2 discusses the same topic with regard to IP presentation 
addresses.

A few other nits in the new draft:

  o  Section 3 "Error Values" still lists the FEDFS_ERR_NSDB_NOFSL error 
code twice.  The second mention might be made a new error value.

  o  If a client passes a FedFsNsdbName argument that is too large, or 
that has a port value which is not an integer between 1 and 65535, is 
FEDFS_ERR_INVAL always the correct error value to return, or should 
there be specific error values for these failure mode?  If INVAL is 
correct, should the procedure descriptions in section 5 include mention 
of this failure mode?

  o  In light of other XDR changes in this draft, perhaps struct 
FedFsNsdbParams should rather be defined as a switched union, something 
like:

union FedFsNsdbParams switch (enum FedFsConnectionSec secType) {
  case FEDFS_SEC_NONE:
	void;
  case FEDFS_SEC_TLS:
	opaque		x509_cert<>;
};

or even

union FedFsNsdbParams switch (enum FedFsConnectionSec secType) {
  case FEDFS_SEC_TLS:
	opaque		x509_cert<>;
  default:
	void;
};

As above, is there a specific error value that indicates an invalid 
secType was specified by a client?  Would it be FEDFS_ERR_BADXDR? 
Should the relevant procedure descriptions include mention of this?

---

From: <[email-masked]>
Date: Tue, 8 Jun 2010 16:08:54 -0400

> storing and collating DNS names in the admin server's NSDB parameters

Unfortunately, it's not that simple ...

RFC 4513 (LDAP) references RFC 3490 (IDNA) for this functionality.
RFC 3490 (LDAP) references RFC 3491 (nameprep) and RFC 3454 (stringprep)
for the underlying ToASCII functionality.

Both RFC 3454 and RFC 3491 have been overtaken by the latest version of
international domain names (2008 vintage), and there is now a new IETF
WG, newprep, that is looking at updating at least the stringprep RFC.

Thanks,
--David

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
Of Chuck Lever
> Sent: Tuesday, June 08, 2010 1:32 PM
> To: James Lentini
> Cc: [email-masked]
> Subject: Re: [nfsv4] [FedFS] Meeting Minutes, 6/3/2010
> 
> _______________________________________________
> nfsv4 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/nfsv4

---

From: Chuck Lever <[email-masked]>
Date: Tue, 08 Jun 2010 16:47:51 -0400

> WG, newprep, that is looking at updating at least the stringprep RFC.

Well, I'm no expert, but it looks like changing the incoming 
FedFsNsdbName strings by using ToASCII before storing them might also 
cause trouble with subsequent TLS server certificate checking.  So maybe 
this is a non-starter anyway.

While I'm in the neighborhood, there appears to be a significant amount 
of LDAP client-side configuration necessary to make LDAP over TLS with 
server cert checking work (at least with OpenLDAP clients).  A small 
number of new specific FEDFS_ERR_ values might be considered so the 
admin server can helpfully reflect local LDAP client configuration 
problems back to admin clients.  At least an "I don't do FEDFS_SEC_TLS" 
error code might be useful.

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 8 Jun 2010 15:55:31 -0500

> WG, newprep, that is looking at updating at least the stringprep RFC.

We risk making no progress by blocking on IDNA work not widely
understood.  It'd be useful to have a summary of how application
protocols should handle IDNA in this brave new world.  Perhaps the I-D
authors could research newprep and the new IDNA work and report to the
WG.

Nico
--

---

From: <[email-masked]>
Date: Tue, 8 Jun 2010 17:18:58 -0400

> Unfortunately, it's not that simple ... 

Exactly, but there is a difference between being not simple ("That's why
we make the big bucks" or at least what are thought of as big bucks
outside Wall Street), and being a total mess.

David has been good enough to explain some of this to me, but the
opinions and errors in explanation in what follow are my own.

Part of the problem is that stringprep and thus nameprep by derivation
are based on Unicode 3.2 which is nearly a decade old.  They are very
explicit that adding characters simply because Unicode added them is not
allowed.  So if there are internationalized domain names that include
characters defined by Unicode after this, these standards, while they
remain standard (or Proposed or Draft Standard or whatever they are) are
simply incorrect.

It appears that it is not simply possible to deal with such a situation
via the errata mechanism as there are just too many complexities for
people to argue about.  Stringprep is mixed up in many ways of which the
German character eszett will serve as my example.  For those who speak
German or remember some of their high school or college German, this is
the character that looks sort of like a beta and has an "s" sound (even
where an "s" in German would have a "z" sound).

Stringprep defined this character as being mapped to "ss" for the
purposes of case mapping since there is no upper-case eszett in Unicode
3.2.  Since normally someone who doesn't have an eszett on his keyboard
will make this mapping and not think too much about it, this seems to
make sense, even though historically the character arose as a
representation of the string "sz" (Isn't historical linguistics fun?).
It turns out this causes problems in that you have a non-invertible
mapping (you don't know whether to map a random "ss" to eszett or not).
Further, it turns out that in Austria (I think) there is a legal
requirement that names always be written in upper-case.  I'm not making
this up.  So Unicode 5.0 added an upper-case eszett to solve this
problem and without specifically intending to driving a stake through
the heart of stringprep (not bad from my point of view).

There is also an issue in Farsi which I don't have at my fingertips
where stringprep also made a significant mistake (it has to do with word
division and the fact that the form of some characters in Arabic script
will be affected be preceding and subsequent characters but not across
word boundaries) and I understand there are two other issues with regard
to other languages.

So far we have a series of mistakes and when you deal with the character
sets for every language in existence plus many ancient ones, you have to
expect those to happen from time to time.  The thing we have to avoid is
letting these cause utter chaos.

David has told us that these document are incorrect.  I agree that they
are.

But what should we do about that?  Is it the case that we should not add
to the considerable set of documents that make a normative reference to
them?  I can see the argument for that, but is it reasonable to be in a
state in which we cannot specify that strings that meet DNS
requirements?  Can't we say "Here is the official reference but it is
incorrect as to some details but this is the best we can do"?  That
doesn't sound so great but is simply waiting better?  And how long might
this situation continue?  

I have a parallel issue attempting to revise Chapter 11 of RFC3530bis to
bear some relation to what people have actually implemented and would
interoperate with what people have actually implemented.  If people are
interested in a talk about what the internationalization chapter of
RFC3530 actually said once you read stringprep, I might do such a
presentation if I get to Maastricht.  Let me know who would like to find
out all the ways you are violating RFC3530 with regard to this chapter.

I don't think that waiting until newprep comes to some sort of
conclusion on a general regime of string processing that would "minimize
the expected confusion for typical users around the world" or some such
and letting the IETF process build on that is very reasonable.  I think
we need either to reference the ultimate source documents for the
internationalized domain names or if that won't work for some reason, or
simply define something that matches actual practice, without waiting
for a general solution to string processing all over the world.

Clearly if there is something these RFCs don't match, that thing must
clearly define what it doesn't match (or else how could you know it
didn't match) and I don't see why we can't simply reference that.
People do have to write documents that reference internationalized
domain names and an unbounded wait for the ability to do that does not
seem reasonable.

Am I way off-base here?

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of [email-masked]
Sent: Tuesday, June 08, 2010 4:09 PM
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: Re: [nfsv4] [FedFS] Meeting Minutes, 6/3/2010

Thanks,
--David

Of Chuck Lever

---

From: <[email-masked]>
Date: Tue, 8 Jun 2010 17:24:27 -0400

That makes sense but if the result of research is that we have no idea
when we can confidently expect a replacement, don't we have to do
something?  Maybe that something is to make a fuss about an
unsatisfactory situation and mobilize others similarly affected.  If
those of more moderate disposition have a viable alternative, that would
certainly be preferable.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Nicolas Williams
Sent: Tuesday, June 08, 2010 4:56 PM
To: Black, David
Cc: [email-masked]
Subject: Re: [nfsv4] [FedFS] Meeting Minutes, 6/3/2010

Nico

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 8 Jun 2010 16:31:14 -0500

> those of more moderate disposition have a viable alternative, that would

I think having a "liason" of sorts to the IDN community and getting an
answer we can all agree on, even if it's "crap, we don't know what to
do" is better than not making any progress.  (Knowing that we have a
SNAFU is better than not knowing.)

Nico
--

---

From: <[email-masked]>
Date: Tue, 8 Jun 2010 17:36:00 -0400

That makes sense.

Thanks for volunteering :-)

We all appreciate it.

Seriously, if you can spare the time, I think this would be helpful.

-----Original Message-----
From: Nicolas Williams [mailto:[email-masked]] 
Sent: Tuesday, June 08, 2010 5:31 PM
To: Noveck, David
Cc: Black, David; [email-masked]
Subject: Re: [nfsv4] [FedFS] Meeting Minutes, 6/3/2010

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 8 Jun 2010 16:52:17 -0500

> Thanks for volunteering :-)

I volunteered the I-D authors.  If they cannot then we can look for
other volunteers.

Nico
--

---

From: "Everhart, Craig" <[email-masked]>
Date: Tue, 8 Jun 2010 18:02:12 -0400

Authors of, say, rfc3530?  Any I-D drafts for rfc3530bis?  I'm sure I
could find some I-D somewhere that has your name on it...

Personally, I can't say I have any standing in this, and precious little
understanding other than I'm trying not to stand in the way of an IDN
trainwreck.  Any dependency that the FedFS drafts have is orthogonal to
the current controversy.

		Craig

> Sent: Tuesday, June 08, 2010 5:52 PM
> To: [email-masked]
> Cc: [email-masked]; [email-masked]

---

From: <[email-masked]>
Date: Wed, 9 Jun 2010 11:57:39 -0400

I think there's a slight problem with your metaphor.

One stands in the way of a train, and I agree that that is not a good
thing to do.

A trainwreck typically stands in your way.  It seems like that is what
is happening here.

I'm not sure what controversy you are referring to but my impression is
that I'm stating "This trainwreck should be cleaned up with dispatch
(after all survivors are rescued, of course)" and for some reason that
is somehow controversial.  Regardless of what the argument is about the
future of IDN or string preparation, we should be able to refer to what
is actually implemented now.  Is there some controversy about that?

-----Original Message-----
From: Everhart, Craig [mailto:[email-masked]] 
Sent: Tuesday, June 08, 2010 6:02 PM
To: Nicolas Williams; Noveck, David
Cc: Black, David; [email-masked]
Subject: RE: [nfsv4] [FedFS] Meeting Minutes, 6/3/2010

		Craig

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 9 Jun 2010 11:28:18 -0500

> A trainwreck typically stands in your way.  It seems like that is what

If the trainwreck is in progress then you sure could be in its way
(though not for long).

> is actually implemented now.  Is there some controversy about that?

There could be: current implementations may themselves be either broken
or non-compliant with the original IDNA.

I bet that most NFSv4 implementations that support referrals treat
server names as non-IDN-aware domainname slots, which means that
compliance is up to the admins (they have to set encoded domainnames, if
they have non-ASCII domainnames to set).  That'd be a fine approach for
referrals.  Is it a fine approach for the ADMIN protocol?  IMO: yes, as
it kicks the can down the line.

We still have to workout the non-IDN-related stringprep issues, but
there we don't really depend on others -- we don't even have to make
reference to stringprep, and I strongly recommend that, indeed, we don't
make reference to stringprep at all.

Nico
--

---

From: <[email-masked]>
Date: Wed, 9 Jun 2010 12:51:28 -0400

I figure that if we have heard about it, the trainwreck (in the sense of
collision and bending of metal) is over although the clearance phase is
clearly not over.  Maybe the time scales show that this metaphor is not
the best one and we should just drop it.

> There could be: current implementations may themselves be either 
> broken or non-compliant with the original IDNA.

As I understand it, what David has told us is that they must be either
broken or non-compliant with the original IDNA, i.e. that if you are
correctly implemented you have to be non-compliant with the original
IDNA.  That is the essence of the problem as I understand it.  We're
told we may not (or maybe it is we shouldn't) reference these documents
because changes to IDNA have made that document incorrect.

If it were possible to both be compliant and correctly functional, we
would be back in the "simple" world in which we could simply reference
the documents, and the fact that correct implementations might be rare,
or even non-existent would be somebody else's problem.

-----Original Message-----
From: Nicolas Williams [mailto:[email-masked]] 
Sent: Wednesday, June 09, 2010 12:28 PM
To: Noveck, David
Cc: [email-masked]; Black, David; [email-masked]
Subject: Re: [nfsv4] [FedFS] Meeting Minutes, 6/3/2010

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 9 Jun 2010 12:06:14 -0500

> because changes to IDNA have made that document incorrect.

Unless... all existing implementations [of NFSv4.0] treat domainname
slots as IDN-unaware.  In that case if the sysadmin configures all-ASCII
domainnames as referrals/replica server names, then everything should
work.  (Changes in IDNA might break some existing server name encodings,
but that'd not be brokenness in NFSv4 implementations.)

The only domainname slot in NFSv4.0 is fs_location4.server.  It seems to
me exceedingly likely that this is treated as IDN-unaware by all client
and server implementations that make use of it at all.

NFSv4.1 adds fs_locations_server4.fls_server, nfs_impl_id4.nii_domain.
The former almost certainly is exactly like NFSv4.0's
fs_location4.server w.r.t. IDN awareness, and the latter is purely
informative ("[t]he nii_domain field is the DNS domain name with which
the implementor is associated").

I.e., we can almost certainly declare all existing NFSv4.0 and NFSv4.1
domainname slots as IDN-unaware (meaning they carry A-labels).

So, the only concern is what to do in the ADMIN protocol.  Is there any
reason that we couldn't just declare the ADMIN protocol's domainname
slots to be IDN-unaware?

Also, to deal with any U-labels that might actually be used in these
slots in practice, all we need to do is have a MAY or SHOULD clause
about detecting these and calling ToASCII() on them.

This way all we need to do is refer to the latest IDNA RFCs and call it
a day.

Nico
--

---

From: Chuck Lever <[email-masked]>
Date: Wed, 09 Jun 2010 13:31:13 -0400

> reason that we couldn't just declare the ADMIN protocol's domainname

When an admin client sets NSDB parameters, a FedFsNsdbName is sent 
possibly accompanied by an X.509v3 credential for the server named in 
that FedFsNsdbName.

When a file or admin server binds to an NSDB, the domain name part of 
the FedFsNsdbName and the credential are used to authenticate the NSDB 
server.  I would think that the domain name part of the FedFsNsdbName 
and at least one hostname listed in the credential must match in order 
for this to work reliably.  That is my limited understanding.

Are server names listed in an X.509v3 credential IDN-aware?

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 9 Jun 2010 14:43:32 -0500

On Wed, Jun 09, 2010 at 01:31:13PM -0400, Chuck Lever wrote:
> possibly accompanied by an X.509v3 credential for the server named
> in that FedFsNsdbName.

All we need to do is declare FedFsNsdbName's IDN-awareness and
normatively reference IDNA.

> When a file or admin server binds to an NSDB, the domain name part
> of the FedFsNsdbName and the credential are used to authenticate the
> NSDB server.  I would think that the domain name part of the
> FedFsNsdbName and at least one hostname listed in the credential
> must match in order for this to work reliably.  That is my limited
> understanding.

A compliant implementation of TLS and PKIX would have to use the rules
from RFC5280 (see below).  In any case, as an NFSv4 implementor, this is
not your problem: it's your TLS library implementor's problem (unless
you're both :)  And since you'd be using TLS via LDAP, it'd really be
your LDAP library implementor's problem.

> Are server names listed in an X.509v3 credential IDN-aware?

RFC5280 section 7, specifically sections 7.2 (IDNs in dNSName fields)
and 7.3 (IDNs in DNs):

7.2.  Internationalized Domain Names in GeneralName

...

   IA5String is limited to the set of ASCII characters.  To accommodate
   internationalized domain names in the current structure, conforming
   implementations MUST convert internationalized domain names to the
   ASCII Compatible Encoding (ACE) format as specified in Section 4 of
   RFC 3490 before storage in the dNSName field.  Specifically,
   conforming implementations MUST perform the conversion operation
   specified in Section 4 of RFC 3490, with the following
   clarifications:

...

7.3.  Internationalized Domain Names in Distinguished Names

...

   Domain Names may also be represented as distinguished names using
   domain components in the subject field, the issuer field, the
   subjectAltName extension, or the issuerAltName extension.  As with
   the dNSName in the GeneralName type, the value of this attribute is
   defined as an IA5String.  Each domainComponent attribute represents a
   single label.  To represent a label from an IDN in the distinguished
   name, the implementation MUST perform the "ToASCII" label conversion
   specified in Section 4.1 of RFC 3490.  The label SHALL be considered
   a "stored string".  That is, the AllowUnassigned flag SHALL NOT be
   set.

...

IRIs and e-mail addresses are covered in sections 7.4 and 7.5,
respectively.

Names that aren't domainnames (or domainname labels) are encoded in
UTF-8 (see section 7.1).

Nico
--

---

From: "Mike Eisler" <[email-masked]>
Date: Wed, 9 Jun 2010 18:49:02 -0700

In RFC5661, NFSv4.1 clients are permitted to use delegation stateids in READ and WRITE.

Neither RFC3530 nor the bis I-D explicitly permits this.

Is it permitted?

Regardless of the answer, it should be explicit in the bis I-D.

---

From: Rick Macklem <[email-masked]>
Date: Wed, 9 Jun 2010 22:22:32 -0400 (EDT)

> Neither RFC3530 nor the bis I-D explicitly permits this.
I would say yes. Since delegations allow opens and locks to be done
locally on the client, the delegation stateid might be the only one
that the client has.

My code definitely assumes it is allowed and my client uses a delegation
stateid if one exists for the file (even if there are also open and
lock stateids).

Here is the snippet from RFC3530 [Page 188]:
    The stateid value for a READ request represents a value returned from
    a previous record lock or share reservation request.  The stateid is
    used by the server to verify that the associated share reservation
    and any record locks are still valid and to update lease timeouts for
    the client.

Since the delegation stateid is returned by a share reservation request
(open), why shouldn't it be allowed?

rick

---

From: "Mike Eisler" <[email-masked]>
Date: Wed, 9 Jun 2010 19:14:31 -0700

OK, but RFC3530-bis should be cleaned up.

Now, let's say a client has a delegation on a file, and then it sends CLOSE.

The delegation still exists, correct?

Can the client send a READ or WRITE using the delegation stateid?

> From: Rick Macklem [mailto:[email-masked]]
> Sent: Wednesday, June 09, 2010 7:23 PM
> To: Mike Eisler
> Cc: [email-masked]
> Subject: Re: [nfsv4] NFSv4.0: delegation stateid in READ and WRITE
> 
> 
>

---

From: Spencer <[email-masked]>
Date: Wed, 9 Jun 2010 21:24:15 -0500

> Can the client send a READ or WRITE using the delegation stateid?

Yes.  And the language should be updated.

Spencer

---

From: "Mike Eisler" <[email-masked]>
Date: Wed, 9 Jun 2010 19:36:13 -0700

> From: Spencer [mailto:[email-masked]]
> Sent: Wednesday, June 09, 2010 7:24 PM
> To: Mike Eisler
> Cc: 'Rick Macklem'; [email-masked]

Even though the file is not OPENed? Wow.

---

From: Rick Macklem <[email-masked]>
Date: Thu, 10 Jun 2010 11:41:18 -0400 (EDT)

> Can the client send a READ or WRITE using the delegation stateid?
That is what my FreeBSD client does and expects to happen. It Closes the
Open stateid when the posix open count goes to 0 (the vnode becomes
inactive), but expects to be able to use the delegation for doing I/O
after that, until the server recalls it. (It may still have dirty buffers
that need to be written back to the server, for example. This avoids the
overhead of needing to push writes to the server upon close to maintain
Close-to-Open consistency.)

rick

---

From: Rick Macklem <[email-masked]>
Date: Thu, 10 Jun 2010 11:46:14 -0400 (EDT)

> Even though the file is not OPENed? Wow.

Yes, because it can be "opened" locally within the client. It is my
understanding that, if a client holds a Write delegation (Read delegations
are obviously more restricted) it can 
open/close/cache/do-byte-range-locking on the file without talking to
the server, except an Access for cases that aren't explicitly permitted
by the ACE in the Write delegation reply.

Allowing these local activities on the client is what makes a delegation
useful, imho.

rick

---

From: <[email-masked]>
Date: Thu, 10 Jun 2010 12:44:05 -0400

Right now, I can't think of any particular reason that this wouldn't
work.

I agree the bis I-D should be explicit one way or the other.

As far as deciding which way to go on this, some pieces of info that
would be helpful:

     Information on any existing clients that do this.

     Information on existing servers as to whether they accept these
     and work properly, reject them, or accept them and do something
     not quite right.

     Reasons why this might be needed (indispensible or particularly
     helpful) functionality.

     Reasons why this would be very difficult or impossible to implement
     on v4.0 servers.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Mike Eisler
Sent: Wednesday, June 09, 2010 9:49 PM
To: [email-masked]
Subject: [nfsv4] NFSv4.0: delegation stateid in READ and WRITE

In RFC5661, NFSv4.1 clients are permitted to use delegation stateids in
READ and WRITE.

Is it permitted?

---

From: James Lentini <[email-masked]>
Date: Thu, 10 Jun 2010 12:58:26 -0400 (EDT)

Chunk,

Thank you for the valuable feedback. Replies below:

On Tue, 8 Jun 2010, Chuck Lever wrote:

>  o  Section 3 "Error Values" still lists the FEDFS_ERR_NSDB_NOFSL error code
> twice.  The second mention might be made a new error value.

The text in the second FEDFS_ERR_NSDB_NOFSL bullet is for the 
FEDFS_ERR_NSDB_RESPONSE error code. I'll correct this.

> that has a port value which is not an integer between 1 and 65535, 
> is FEDFS_ERR_INVAL always the correct error value to return, or 
> should there be specific error values for these failure mode?  If 
> INVAL is correct, should the procedure descriptions in section 5 
> include mention of this failure mode?

INVAL is what we have currently. We can create another error code for 
this case. Any recommendations on the name? I'll update the procedure 
descriptions with whatever approach is chosen.

> FedFsNsdbParams should rather be defined as a switched union, something like:
> 

The current definition is modeled after the RPC opaque_auth structure. 
Although there isn't a functional difference, I agree with your point 
regarding consistency with other Admin protocol types (e.g. the 
FedFsPath). I prefer the second definition above. Opinions?

> As above, is there a specific error value that indicates an invalid secType
> was specified by a client?  Would it be FEDFS_ERR_BADXDR? 

Yes, FEDFS_ERR_BADXDR.

> Should the relevant procedure descriptions include mention of this?

Yes.

---

From: <[email-masked]>
Date: Thu, 10 Jun 2010 13:30:53 -0400

> normatively reference IDNA.

I thought David Black just told us it "wasn't that simple".  We argued
about all the train-wreck metaphors and I don't want to go there again.

However, if there are things in this vicinity that are simple and can
avoid those dangers, what exactly is the line between those and what
I've come to call the IDN well-head explosion?  I certainly would like
to stay on the right side of that line and avoid having to deal directly
dealing with pollution sequelae, dispersant toxicity issues, etc.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Nicolas Williams
Sent: Wednesday, June 09, 2010 3:44 PM
To: Chuck Lever
Cc: [email-masked]
Subject: Re: [nfsv4] [FedFS] Meeting Minutes, 6/3/2010

...

...

...

...

Nico

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 10 Jun 2010 12:53:01 -0500

My proposal:

 - Declare all NFSv4.0, NFSv4.1 and ADMIN protocol domainname slots to
   be IDN-unaware -- they shall carry A-labels, not U-labels;

 - Normatively reference IDNA.

Note that this is completely separate from I18N for the rest of NFSv4.

Note also that resolvers are typically IDN-unaware (IDNAbis doesn't
change this), which means that existing implementations and deployments
of NFSv4 almost certainly are also IDN-unaware.  At most we might want
text saying clients/servers MAY/SHOULD accept U-labels.

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 10 Jun 2010 12:53:41 -0500

> about all the train-wreck metaphors and I don't want to go there again.

I believe it is that simple.

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 10 Jun 2010 13:16:21 -0500

> I believe it is that simple.

I should explain why.  There's a simple test too: put my proposal to the
IDNAbis mailing list ([email-masked]).

IDNAbis does not fundamentally change the architecture of IDNA: there's
still a notion of A-labels and U-labels (the terms are new, but the
concept goes back to IDNA 1.0), and there's still a notion of IDN
awareness.  Therefore the simplest thing to do is pick from the two
choices (IDN-aware vs. IDN-unaware) that we have.

IDNAbis does add a "domainname registration" procedure.  This applies to
creation of NFSv4 elements that contain domainnames.  Specifically it
applies to the ADMIN protocol: either the client or the server.  And
here we have three choices, not two:

 - the client sends server names in A-label and U-label forms;
 - the client sends server names in A-label form;
 - the client sends server names in U-label form.

The last is not recommends, and either of the first two will do.  The
first allows more validation to be performed than the second, but given
what the server will do with domainnames[*], the more limited validation
feasible with the second form is good enough.

For all issues relating to incompatibilities between IDNA and IDNAbis:
those are NOT our problem.  We normatively reference IDNAbis, and we're
done.

[* ] The server stores the given domainnames and subsequently passes
     them to the resolver and/or sends them back as-is to to clients,
     which in turn pass them to resolvers.

     The additional verification that can be done when validating a
     domainname input in both forms is especially desirable when
     inserting domainnames into DNS zones -- that's clearly not relevant
     here.

---

From: Chuck Lever <[email-masked]>
Date: Thu, 10 Jun 2010 14:57:46 -0400

> descriptions with whatever approach is chosen.

FEDFS_ERR_BAD_NSDBNAME seems obvious, although not terribly poetic.

> error code might be useful.

There are some legitimate cases where an ADMIN server might want to 
indicate that a security type, such as TLS, is not supported.  On older 
platforms without TLS support, platforms where the TLS or LDAP 
implementation is known to be broken, on embedded systems, or where the 
ADMIN server knows that TLS support is not locally configured, the 
server MAY indicate to an ADMIN client that TLS is not supported when it 
attempts to set NSDB parameters with a FEDFS_SEC_TLS security type.  May 
I suggest:

   FEDFS_ERR_UNSUPPORTED_SECTYPE

which means the client passed a valid FedFsConnectionSec value, but the 
local server implementation or configuration does not currently support it.

This error value MAY be returned for 
FEDFS_SET_NSDB_PARAMS(FEDFS_SEC_NONE) when the local administrator wants 
to ensure the use of transport layer security for all LDAP requests.

---

From: <[email-masked]>
Date: Thu, 10 Jun 2010 17:13:15 -0400

> > I believe it is that simple.

I definitely prefer your position :-)

So if we are to follow your approach for RFC3530bis, how exactly do I
normatively reference IDNAbis in the RFC3530bis draft?  There's a total
of five drafts but they are in the RFC editor queue.  Not sure how to
construct the references.

>  - the client sends server names in U-label form.

This may be a nit but most uses of domains in NFSv4 concern those sent
from the server to the client.  Does that change things?  

I'm OK with either the first or third (except for an issue discussed
below) but this is an area liable to generate dispute and I'd like to
understand the constraints as we try to work through to consensus.

Why is the third choice not recommended?

The specific context where I have a problem with options one and two is
id@domain.  This is the only case in which the domain is sent from the
client to the server.  Option two is quite discordant with a protocol
that addresses internationalization issues throughout by coding strings
in UTF8.  Requiring that stuff after the at-sign be Punycoded into ascii
seems unbelievably arbitrary.  

With regard to option one, there are additional difficulties.  Does it
really make sense to require that the server always accept
id@Punycode(x) if it accepts id@x and map those to the same id?  Also,
wouldn't a client have to be prepared for id's of the form
id@Punycode(x).  Given that this is just an id qualifier, it seems for
this option 3 makes most sense and options 1 and 2 just add
confusion/complexity.

I'm sure that there would people who argue the same for the other IDNA
cases in NFSv4, and I'm not saying they are wrong, but I wouldn't
bother.  I would go with an option one consensus on this.

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 10 Jun 2010 16:20:34 -0500

> I definitely prefer your position :-)

:)

> construct the references.

RFC numbers are assigned already, but I think you'd want to use the I-D
names for now.  You'd want to reference this I-D:

    draft-ietf-idnabis-protocol-18.txt (RFC-to-be 5891)

> from the server to the client.  Does that change things?  

The quoted part was specifically in the context of the ADMIN protocol,
where we have domainnames going fromt he client to the server.

For NFSv4.* proper, we need only decide whether the domainname slots are
IDN-aware or not.

> Why is the third choice not recommended?

Again, this is in the context of "domainname registration", and is NOT
relevant to NFSv4 itself, just the ADMIN protocol.

(See draft-ietf-idnabis-protocol for the answer to your question, if you
still need it :)

Nico
--

---

From: Mike Mackovitch <[email-masked]>
Date: Thu, 10 Jun 2010 14:33:12 -0700

> Allowing these local activities on the client is what makes a delegation

For the record, the Mac OS X NFSv4 client does this as well.

Just because the server doesn't know about the OPEN (yet) doesn't
mean a client holding a write delegation does not have it open.

(Of course, if the delegation gets recalled, the client will need to
claim that delegated open (and any delegated locks) before returning
the delegation.  Then it would have an open (or lock) stateid to do
the I/O with.)

Thanks
--macko

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 10 Jun 2010 16:38:59 -0500

>     draft-ietf-idnabis-protocol-18.txt (RFC-to-be 5891)

That I-D references the other normative IDNA2008 I-Ds, which is why just
referencing that one is sufficient, but also, it seems to me that the
protocol document is much more useful as the main reference than any of
the other Standards-Track IDNA2008 I-Ds.

Also, for the ADMIN protocol we'll probably also want to reference
(informatively) draft-resman-idna2008-mappings-01, since that deals with
user interfaces.  That one is not relevant to NFSv4 because there's no
place in NFSv4 where a user enters a domainname (domainnames NFS URIs
and mount command lines are covered elsewhere, implicitly or otherwise).

Nico
--

---

From: <[email-masked]>
Date: Thu, 10 Jun 2010 18:16:07 -0400

> I definitely prefer your position :-)

Without going into details, I think the fundamental disagreement here comes down to where the responsibility is placed for normalizing Unicode string input, and as a consequence where that normalization has to be done.  This is about everything that is UTF8 and could be compared for equality, not just domain names.  The general principle here is that unnormalized Unicode strings should not be compared for equality if either of them was originally input by a human - doing so risks strings that should be equal failing to match due to different binary representations.

My "wasn't that simple" comment was in response to a suggestion that NFS specify this normalization by referencing what LDAP does - LDAP uses stringprep & newprep is figuring out what to do about stringprep in light of IDNA2008/IDNAbis.

As I understand his position, Nico is effectively arguing that NFS can ignore this Unicode normalization problem by pushing it into other components.  The crux of Nico's argument is this from his most recent post:

	... there's no place in NFSv4 where a user enters a domainname (domainnames
	NFS URIs and mount command lines are covered elsewhere, implicitly or otherwise).

Speaking for myself, I don't care where Unicode normalization is done, but it has to be done, and NFS has to be clear about whose responsibility it is and what's acceptable output in order to avoid bad comparison results (strings that are equivalent wrt Unicode rules don't match "on the wire").  I would also oppose an "on the wire" requirement to normalize a received Unicode string (IMHO, normalization should happen before NFS sees the string).

Thanks,
--David
----------------------------------------------------
David L. Black, Distinguished Engineer
EMC Corporation, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953             FAX: +1 (508) 293-7786
[email-masked]        Mobile: +1 (978) 394-7754
----------------------------------------------------

---

From: Chuck Lever <[email-masked]>
Date: Thu, 10 Jun 2010 18:51:47 -0400

On 06/10/10 06:16 PM, [email-masked] wrote:
> Without going into details, I think the fundamental disagreement here comes
> down to where the responsibility is placed for normalizing Unicode string
> input, and as a consequence where that normalization has to be done.  This
 > is about everything that is UTF8 and could be compared for equality, not
> just domain names.  The general principle here is that unnormalized Unicode
> strings should not be compared for equality if either of them was originally
 > input by a human - doing so risks strings that should be equal failing to
> match due to different binary representations.
>
> My "wasn't that simple" comment was in response to a suggestion that NFS
 > specify this normalization by referencing what LDAP does - LDAP uses
> stringprep&  newprep is figuring out what to do about stringprep in light
 > of IDNA2008/IDNAbis.

To be clear, I was suggesting this LDAP reference _only_ for the 
FedFsNsdbName data type defined in the proposed FedFS ADMIN protocol. 
Sorry for the confusion.

A FedFsNsdbName is used only for communication and authentication 
between a file or ADMIN server and an LDAP server, thus this data type 
never appears in the NFS wire protocol.  It seems to me that therefore 
this data type ought to cleave more closely to LDAP and X.509 rather 
than NFS.

---

From: Rick Macklem <[email-masked]>
Date: Thu, 10 Jun 2010 19:24:15 -0400 (EDT)

>     Information on any existing clients that do this.

Probably already obvious, but the client I've written for FreeBSD8
does this.

>     and work properly, reject them, or accept them and do something

The server in FreeBSD8 handles these.

>     Reasons why this might be needed (indispensible or particularly

I think/hope the client will get to the point where it needs to do
very little communication with the server (Access Ops for the cases
where the write delegation ACE doesn't explicitly allow it) for files
that are write delegated. This should allow for much better performance
over WAN connections and reduce the per-client RPC load on the server.
(The FreeBSD8 client currently does do some of this, but whole file
caching on the client's disk for write delegated files isn't in place
yet. It does issue opens locally in the client when it holds a write
delegation, so it will break for clients that do not support this.

>     Reasons why this would be very difficult or impossible to implement
Wasn't difficult for the FreeBSD8 server and I also believe that the
Solaris server handles this, since I haven't seen any problems when
testing against it.

rick

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 10 Jun 2010 18:29:54 -0500

On Thu, Jun 10, 2010 at 06:16:07PM -0400, [email-masked] wrote:
> Without going into details, I think the fundamental disagreement here
> comes down to where the responsibility is placed for normalizing
> Unicode string input, and as a consequence where that normalization
> has to be done.  This is about everything that is UTF8 and could be
> compared for equality, not just domain names.  The general principle
> here is that unnormalized Unicode strings should not be compared for
> equality if either of them was originally input by a human - doing so
> risks strings that should be equal failing to match due to different
> binary representations.

With respect to IDNs (the subject of this thread), normalization is one
of many details of IDNA, properly encapsulated.  IDNA already provides
all the information we need to know what to do with the protocol.

Also, with respect to NFSv4's (and the ADMIN protocol's) domainname
slots, their values are never compared for equality.  In the case of
NFSv4 (and the fedfs domain root SRV RRs) they are merely resolved to IP
addresses.  In the case of the ADMIN protocol they are stored for
subsequent resolution to IP addresses.  There are no comparisons, for
equality or anything else, but if there were, we'd want to use A-labels
for equality comparisons (since A-labels are canonical for IDNs), and
U-labels for collating.

> My "wasn't that simple" comment was in response to a suggestion that
> NFS specify this normalization by referencing what LDAP does - LDAP
> uses stringprep & newprep is figuring out what to do about stringprep
> in light of IDNA2008/IDNAbis.

NFSv4 has not business making any statements whatsoever with regard to
Unicode normalization of IDNs.  That's the province of IDNA.

> As I understand his position, Nico is effectively arguing that NFS can
> ignore this Unicode normalization problem by pushing it into other
> components.  The crux of Nico's argument is this from his most recent
> post:

No, that's not it.

> 	... there's no place in NFSv4 where a user enters a domainname
> 	(domainnames NFS URIs and mount command lines are covered
> 	elsewhere, implicitly or otherwise).

You're quoting out of context.

> Speaking for myself, I don't care where Unicode normalization is done,
> but it has to be done, and NFS has to be clear about whose

No, IDNA has to be applied -- normalization is a detail of IDNA.  And
like you, I don't care exactly where IDNA is applied, as long as it
happens before IDNs are put on the wire (or as long as IDNs are expected
to already be in A-label form).

> responsibility it is and what's acceptable output in order to avoid
> bad comparison results (strings that are equivalent wrt Unicode rules
> don't match "on the wire").  I would also oppose an "on the wire"
> requirement to normalize a received Unicode string (IMHO,
> normalization should happen before NFS sees the string).

We need to be careful to separate I18N matters relating to IDN from all
other I18N matters.  Normalization is something we definitely have to
take into account explicitly, but only for items such as file names, NOT
for IDNs, because for IDNs normalization is a detail of IDNA.

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 10 Jun 2010 18:41:52 -0500

> for IDNs, because for IDNs normalization is a detail of IDNA.

I should also point out that we don't have domainname slots embedded in
other kinds of strings (unlike, for example, e-mail addresses), so
there's no risk of normalizing first to, say, NFKC, then applying IDNA
(which would not work correctly for all possible IDNs, since IDNA uses
NFC, not NFKC).  If we were to have that unfortunate problem, then
things wouldn't be simple (but they still wouldn't be too complicated).

This thread is about IDNs.  Let's stick to the topic.

Nico
--

---

From: "Peter Varga" <[email-masked]>
Date: Fri, 11 Jun 2010 10:29:26 -0400

I'll answer for Open Text/Hummingbird:

Our server allows the use of delegation stateids on READ/WRITE. And, it
allows its use whether or not the corresponding OPEN stateid still
exists or not. 

Our client will use the delegation stateid on READ/WRITE if it has one.
It will not send any OPEN/CLOSE to the server while it has the
appropriate delegation. From our testing, major server implementers
(Linux, Solaris, NetApp) at Connectathon allow the use of a delegation
stateid on READ/WRITE.

I suppose you could add restrictions to prevent the use of delegation
stateid on READ/WRITE, or to prevent READ/WRITE if a file is not OPENed,
but why? The presence of a delegation prevents any other client (local
or remote) from modifying the file. So what's the harm with writing a
file that isn't OPENed (from a NFS protocol standpoint at least) if the
client has a write delegation?

Restricting this would evidently create some headaches for all parties
that have so far replied.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of [email-masked]
Sent: Thursday, June 10, 2010 12:44 PM
To: [email-masked]; [email-masked]
Subject: Re: [nfsv4] NFSv4.0: delegation stateid in READ and WRITE

-----Original Message-----

Is it permitted?

---

From: <[email-masked]>
Date: Fri, 11 Jun 2010 16:46:43 -0400

> There are no comparisons, for
> equality or anything else, but if there were, we'd want to 
> use A-labels for equality comparisons (since A-labels are 
> canonical for IDNs), 

I don't get this.

Two different A-labels map to two different U-labels and two different
U-labels map to two different A-labels.  Otherwise the encoding would
not be a good one.  And with regard to normalization, the sets of valid
labels are again in one-to-one correspondence.  That is, if a unicode
string is not appropriately normalized the Punycode equivalent is also
invalid, for that very reason, that it represents a Unicode string which
is not a valid domain name.  Similarly in the reverse direction.

So comparing A-labels and U-labels that each reflect the appropriate
normalization should indicate equality under exactly the same
conditions.

Where does this attribute of being canonical come in?

> and U-labels for collating. 

So for two U-labels A, and B, either A > B, B > A, or A = B.

So if that is ok for collating then you accept the results as valid for
A > B and for B > A.  Therefore, you are accepting the results as valid
for A > B || B > A and the complement of that, A = B.

As long as they are properly normalized U-labels should be fine as
comparison for equality. 

-----Original Message-----
From: Nicolas Williams [mailto:[email-masked]] 
Sent: Thursday, June 10, 2010 7:30 PM
To: Black, David
Cc: Noveck, David; [email-masked]
Subject: Re: i18n: Where's the problem?

No, that's not it.

Nico
--

---

From: Chuck Lever <[email-masked]>
Date: Fri, 11 Jun 2010 16:55:12 -0400

> for equality comparisons (since A-labels are canonical for IDNs), and

Unless I'm gravely mistaken, FedFsNsdbNames are both stored and compared 
for equality.  These names are used to key the ADMIN server's store of 
X.509 certs.  There is language throughout the ADMIN protocol draft that 
discusses what FedFsNsdbName "equality" means.

The FEDFS_SET_NSDB_PARAMS procedure explicitly stores a FedFsNsdbName 
and X.509 cert binding for use in subsequent junction resolution, via an 
LDAP search over TLS.

---

From: Nicolas Williams <[email-masked]>
Date: Fri, 11 Jun 2010 16:05:20 -0500

> > use A-labels for equality comparisons (since A-labels are 

Do you mean that you think that NFSv4 implementations do comparisons on
replica/referral server names?  Or did you just mean to pick nits at the
"but if there were" part?  :)  I'm guessing the latter.

> is not a valid domain name.  Similarly in the reverse direction.

Two U-labels can map to the same A-label, of course.  The reverse is not
true -- a valid A-label maps to a single U-label.  How is any of that
relevant here?  Why discuss details of IDNA that are meant to be
abstracted from us?

> normalization should indicate equality under exactly the same

You'd want to compare A-labels.  (For non-IDN strings you'd want to
compare normalized strings, or else do normalization-insensitive
comparison.  A-labels are punycoded, _normalized_ strings.  You could
compare U-labels by applying all steps of ToASCII() but the punycode
step, but why bother?)

> Where does this attribute of being canonical come in?

When you do equality comparisons of items you want to either compare
canonical versions of them (so that aliases compare as equal) or to do a
comparison operation that internally does the same thing (e.g.,
normalization-insensitive comparison).

> As long as they are properly normalized U-labels should be fine as

U-labels aren't necessarily normalized.  True, if you get the U-label
from an A-label, then the U-label is canonical as well, and you could do
all comparisons based on U-labels.  If that was your point, well, point
taken.  Can we get back to what we're going to do to NFSv4 regarding
IDNA?

Nico
--

---

From: <[email-masked]>
Date: Fri, 11 Jun 2010 17:12:05 -0400

> unnormalized Unicode strings should not be compared for equality 
> if either of them was originally input by a human 

Why do you specify "originally input by a human" here?  I don't see that it is relevant.  

If they are unnormalized and they are compared for equality in a context where Unicode canonical equality is the appropriate form of comparison, then they must either be normalized as a preparatory part of the comparison procedure (with an strcmp comparison following), or compared by code that can determine Unicode canonical equality directly without normalization (rather than strcmp-equality) as Nico has been advocating (n/i, n/p).  The result of either is a comparison for canonical equality although with the latter, we don't lose information about the original string (i.e. which remember of the Unicode canonical equality equivalence class it is).

That applies whether the strings were input by a human being, generated by my uninspired code, or sent by something that can pass the Turing test.

-----Original Message-----
From: Black, David 
Sent: Thursday, June 10, 2010 6:16 PM
To: Noveck, David; [email-masked]
Cc: [email-masked]; Black, David
Subject: i18n: Where's the problem?

Thanks,
--David

---

From: Nicolas Williams <[email-masked]>
Date: Fri, 11 Jun 2010 16:12:16 -0500

On Fri, Jun 11, 2010 at 04:55:12PM -0400, Chuck Lever wrote:
> Unless I'm gravely mistaken, FedFsNsdbNames are both stored and
> compared for equality.  These names are used to key the ADMIN
> server's store of X.509 certs.  There is language throughout the
> ADMIN protocol draft that discusses what FedFsNsdbName "equality"
> means.

If we pass A-labels on the wire then you can just compare those.  The
question is whether the ADMIN client should send A-labels, U-labels, or
both to the ADMIN server.  The fact that these are then used for string
equality comparisons is not relevant to that question.  IMO the client
should send A-labels.

Of course, LDAP may well make DC elements of DNs IDN-aware or -unaware,
and we may want to check this, but LDAP implementations might hide that
detail and allow callers to use either kind of labels.  However, if
we're passing DNs on the wire, then we should pass them in whatever form
LDAP considers canonical.

(Also, as Dave Noveck points out, IIU him correctly, that we could
always use U-labels output by ToUnicode() to do IDN comparisons if we
need anything more than equality comparisons.  He's right about that,
though again, I don't think that's relevant here.)

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Fri, 11 Jun 2010 16:30:38 -0500

> LDAP considers canonical.

I've inquired about LDAP and received this answer from Kurt Zeilenga: "DC
predate IDNA, so should be label as it appears in DNS (e.g., the A
label)" and this is covered by "[section] 2.4 of RFC 4519".

Can we settle the matter of what form we send IDNs on the wire in?  Can
we settle on always sending them in A-label form?

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Fri, 11 Jun 2010 16:53:04 -0500

> relevant here?  Why discuss details of IDNA that are meant to be

CORRECTION: a U-label is canonical.  Users cannot reliably enter
U-labels, so user input is generally not a U-label until IDN processing
has been applied to produce a U-label.

What that means is that choosing to have U-labels on the wire won't help
simplify implementations in any significant way.  But I believe that
sending A-labels does, since that way servers are simplified: at most
they need only validate that host names are LDH (one might want to
validate A-labels, but given what is done with domainnames in NFSv4 and
ADMIN, I think there's no need to).

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Fri, 11 Jun 2010 18:08:49 -0500

David Black and I have discussed this a bit off-list.  The current state
of our discussion is this: David believes that the choice of XDR
typename for NFSv4's domainname slots is indicative of intention to send
IDNs in U-label form, while I believe that the choice of XDR typename is
not sufficiently dispositive on this matter, that what actual
implementations do is dispositive.

I believe that all existing NFSv4 implementations fail to treat NFSv4
domainname slots as IDN-aware.  That is:

 - existing NFSv4 implementations they fail to apply ToASCII() to DNS
   labels obtained from NFSv4 domainname slots when placing those
   domainnames in other IDN-unaware slots,

 AND

 - they also fail to apply ToUnicode() to any A-labels before placing
   them into NFSv4 domainname slots,

 AND

 - they also fail to validate/canonicalize [e.g., by applying
   ToUnicode(ToASCII()) to] Unicode inputs from users prior to placing
   those inputs into NFSv4 domainname slots.

The above is almost certainly true of all existing NFSv4
implementations.  I'd welcome evidence to the contrary, if anyone has
any.

I'll point out too that RFC5661 does not even mention IDNA, nor even
reference IDNA (it only normatively references Stringprep), to say
nothing of RFC3530.

I believe all the evidence is that NFSv4's domainname slots are
historically IDN-unaware, and that as such only A-labels belong there,
regardless of what the XDR typenames might imply to some.

Nico
--

---

From: Chuck Lever <[email-masked]>
Date: Fri, 11 Jun 2010 20:13:53 -0400

> we settle on always sending them in A-label form?

I believe that making the domain name component of a FedFsNsdbName be an 
A-label is the correct choice, for all the reasons discussed in this thread.

For consistency, however, the ADMIN protocol draft authors want to copy 
what RFC 5661 proscribes for domain name slots.  I can live with either 
outcome as long as the ADMIN protocol draft is clear what is required of 
implementations.

---

From: Nicolas Williams <[email-masked]>
Date: Fri, 11 Jun 2010 19:23:43 -0500

On Fri, Jun 11, 2010 at 08:13:53PM -0400, Chuck Lever wrote:
> I believe that making the domain name component of a FedFsNsdbName
> be an A-label is the correct choice, for all the reasons discussed
> in this thread.

Great.

> For consistency, however, the ADMIN protocol draft authors want to
> copy what RFC 5661 proscribes for domain name slots.  I can live
> with either outcome as long as the ADMIN protocol draft is clear
> what is required of implementations.

RFC5661 does not even mention IDNA.  It only references Stringprep,
which is not sufficient to handle IDNA.  What little is even said about
utf8str_cis ("[i]ts primary use in NFSv4.1 is for naming NFS servers")
says nothing about IDNs.

It's clear that utf8str_cis must have been intended to carry IDNs in
UTF-8 form, but almost certainly has not been used that way, and none of
the necessary requirements for doing so were actually stated explicitly.

Heck, the definition of utf8str_cis' stringprep profile is almost
certainly in conflict with IDNA2008 (e.g., no normalization form is
given, and by allowing the use of Unicode > 3.2 it's certainly in
conflict with the original IDNA).

In other words: we have to "fix" NFSv4.1, not just determine what to do
for FedFS.

Nico
--

---

From: Trond Myklebust <[email-masked]>
Date: Mon, 14 Jun 2010 11:09:30 -0400

> Allowing these local activities on the client is what makes a delegation

Agreed. There is no point in having functionality to 'cache opens' if
that doesn't allow you to read or write to the file.

Furthermore, since nobody else is allowed to set up conflicting shares
or locks, nor can they change file permissions without causing the
delegation to be recalled, there is no good argument for requiring any
extra state in order to ensure reads and writes can succeed.

That said, we definitely do need to ensure that the server can identify
our client as the holder of the delegation since otherwise it may decide
that a recall is needed. Hence the client SHOULD send the delegation
stateid in the READ and WRITE call.

Cheers
  Trond

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 14 Jun 2010 11:35:49 -0500

>    domainnames in other IDN-unaware slots,

[Having thought this over over the weekend...]

The first is the one big problem, and, it might not be a problem at all
were getaddrinfo()/getnameinfo() themselves IDN-(and locale-)aware.  If
they were, then we could send completely un-pre-processed UTF-8 on the
wire -- user input would be perfectly OK, unnormalized and all.

draft-iab-idn-encoding, which targets Informational status, and which is
only in I-D-Exists state, discusses getaddrinfo() in some detail.

I think, perhaps, this is the biggest failure of IDNA: it pushed too
much into applications and completely ignored the existence of name
service switches on most modern operating systems.  It isn't really
possible to have an application be IDNA-aware (i.e., it knows when to
call ToASCII()/ToUnicode()) on such operating systems without also
forcing IDNA on name services other than DNS or without forcing the
application to side-step the local name services client facilities and
talk DNS directly -- both lousy consequences.

If, instead, IDNA specifically gave advice or, better, requirements as
to name services clients, then life would be a lot easier for us.  Pity,
then, that draft-iab-idn-encoding only aims for Informational status!
(Oh, and getnameinfo() is a tougher cookie than getaddrinfo(), but
draft-iab-idn-encoding doesn't even mention it!  *sigh*  I guess I'll be
composing a post to the IDNA list about that.  At least getnameinfo)

I agree with David that saying that we must put ASCII-only in
utf8str_cis seems silly.  I think we should only because that's going to
be closest to what's been deployed in practice, but I don't think this
is critical.  Declaring NFSv4's domainname slots to be IDN-aware
wouldn't bother me very much if we could assume that IDNA-awareness is
coming to implementors' getaddrinfo()/getnameinfo(), which I think is a
fair bet.

So, I'm now happy to go either way: U-labels-only, A-labels-only, and
maybe even both OK.  In terms of immediate server implementor simplicity
A-labels-only seems like a big win, but longer term this won't matter as
much.  Longer term allowing U-labels seems like the simplest solution.

One caveat: if we are to allow U-labels, we must make sure that
utf8str_cis is defined in such a way as to be compatible with IDNA; I've
not checked carefully for conflicts, but my impression is that there are
some.

Sorry for the whiplash!

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 14 Jun 2010 11:43:10 -0500

On Fri, Jun 11, 2010 at 10:46:11PM -0400, [email-masked] wrote:
> Once upon a time, the entire Internet was ASCII (unaware of both IDN and
> Unicode), and Nico seems determined to drag NFSv4 back to those days :-)
> :-).

:)

I just changed my mind back to neutral on this though.  See my other
post just now.  A re-reading of draft-iab-idn-encoding prompted a
re-think.

> Seriously, if the only place that Unicode turned up in NFSv4 was domain
> names, sending punycode A-labels on the wire could be a fine end to this
> discussion.  This is about more than just the XDR type - RFC5661
> specifies use of stringprep on all UTF-8 strings (which Nico brushes off
> as not relevant, and seems to think we ought to abandon - at least
> that's my impression).

I don't see the relevance of the use of UTF-8 in other parts of the
protocol, especially given that domainname slots are clearly separated
in the wire encoding.

> Moreover, for all the information on what NFS implementations don't do,
> a crucial (IMHO) question was never asked:
> 
> 	Do any NFS implementations or installations currently use
> punycode A-labels
> 		for domain names?

Hard to tell -- we'd have to go ask customers.  Using A-labels would
work though, while using U-labels almost certainly wouldn't.

> Unicode is and/or will be necessary for NFSv4 filenames and user names
> (e.g., in ACLs).  Given that, I think forcing Unicode domain names to
> ASCII punycode is the wrong design decision, even though it can be made
> to work, and I think punycoding every UTF-8 string in NFS would be a bad
> idea.

Ah, yes, there's the domainname in usernames and groups, which would be
domainname slots (I'm not sure that they are intended to be DNS
domainnames, but in practice that's how we use them, at least in Solaris
when joined to AD forests).  I would think that the same answers apply
to this domainname slot as to the others.

Nico
--

---

From: <[email-masked]>
Date: Mon, 14 Jun 2010 12:49:50 -0400

Basically, I'm just trying to understand this situation, so that we can
proceed with addressing what we are going to do about IDNA for NFSv4.  I
agree we want to do that.  I'm trying to get a new draft of RFC3530bis
together including a major revision of the internationalization chapter
in time for Maastricht.  I agree that we need to resolve the IDNA
question, in as simple a fashion as we can.

As to whether implementations do comparisons on replica/referral server
names, I agree they don't but there is another piece of domain
internationalization and that is that concerned with id@domain and in
that case the server does compare the domain name the client sends
against a prespecified value or a list and that affects how we define
the other piece of domain-related internationalization.

So you've clarified the A-label/U-label situation.  In the abstraction
we are presented with, canonicalization and conversion to Punycode are
combined in a single operation and there does not seem even to be a name
for a canonical UTF8/unicode domain.  That's kind of a problem for a
protocol which was designed to handle to internationalization throughout
via using UTF8.  How serious a problem depends on ones attitude to
protocol design.

Anyway, as you alluded to with regard to collation, you can get a
canonical U-label without breaking the abstraction simply by converting
an A-label to Unicode.  Instead of not doing the conversion to Punycode
we do it and then undo it.  (If you want to optimize things by breaking
the abstraction avoiding those two conversions that when composed are
the identity, just don't tell anybody :-).  Given how you arrived at it,
you could call it an AU-label.  So I'll call it a Gold-label.
Gold-labels can be compared for equality and collated in a sensible way,
whereas A-labels can only be compared for equality using strcmp, while
two U-labels in general can only be compared for equality by first
rendering them canonical by converting each to an A-label or by
converting each to a Gold-label.

As far as I can see we have two separate questions to resolve: handling
of IDNA for servers for replica/referral/migration and handling of IDNA
for domains for users/groups.  As far as I can see, we are best off
treating these issues separately.  

I'll be sending out mail, each with the options that I can think of for
that area.  If you have additional choices to present, please do, but
please state your option completely.  A tree of options defined by small
deltas relative to one another will get confusing.  I hope everyone,
despite their preference for one choice will try to arrive at something
that we can develop a consensus around.  I will be asking in a bit for a
preference-ordered list for each set of options with a line at the point
beyond which you are not prepared to go.  Please think about how far
down you can put this to enable us to get a consensus we can go forward
with.  I'm hoping we can get something that everybody can live with even
though it might not be anybody's first choice.

-----Original Message-----
From: Nicolas Williams [mailto:[email-masked]] 
Sent: Friday, June 11, 2010 5:05 PM
To: Noveck, David
Cc: Black, David; [email-masked]
Subject: Re: i18n: Where's the problem?

Nico
--

---

From: <[email-masked]>
Date: Mon, 14 Jun 2010 12:51:27 -0400

Agreed that we have to fix NFSv4.1.

My expectation would be that it would match pretty closely match what
would be done for RFC3530bis.

The stringprep problems apply not only to IDNA.  If you look at what
RFC3530 says about internationalization and compare it to what people
implement, there are enormous differences, and I don't think that it is
the implementations which have to change in most cases.

I'll give a talk in Maastricht on what RFC3530 says about
internationalization and hopefully what the current draft of RFC3530bis
say about it.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Nicolas Williams
Sent: Friday, June 11, 2010 8:24 PM
To: Chuck Lever
Cc: [email-masked]
Subject: Re: [nfsv4] i18n: Where's the problem?

Great.

Nico

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 14 Jun 2010 11:55:49 -0500

> the implementations which have to change in most cases.

True, but the two problems are separable.  I believe we're more likely
to make progress by treating IDNA separately from file names.

> internationalization and hopefully what the current draft of RFC3530bis

Cool.

Nico
--

---

From: <[email-masked]>
Date: Mon, 14 Jun 2010 15:13:22 -0400

> to make progress by treating IDNA separately from file names. 

Separate decisions, sure, but there has to be a chapter that deals with
both of them and discusses, at the highest level, why they are separate
issues.

-----Original Message-----
From: Nicolas Williams [mailto:[email-masked]] 
Sent: Monday, June 14, 2010 12:56 PM
To: Noveck, David
Cc: [email-masked]; [email-masked]
Subject: Re: [nfsv4] i18n: Where's the problem?

Cool.

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 14 Jun 2010 14:32:47 -0500

> both of them and discusses, at the highest level, why they are separate

Of course, though even then I'd strongly suggest having separate
sub-sections for the two problems, with only introductory text
discussing both issues.

---

From: <[email-masked]>
Date: Mon, 14 Jun 2010 18:02:20 -0400

Something is very strange about the term IDN-unaware.

> what actual implementations do is dispositive. 

"Dispositive" seems a little strong but let's try that.

OK.  They are IDN-aware and so they don't have code to canonicalize or
to convert Punycode or the inverse.  If you are IDN-unaware and somebody
asks you whether you do these things, you say "Huh?".

So if you are IDN-unaware, then there is no code to change things to
A-labels.

So it cannot be the case that such implementations would be consistent
with requiring that you always return A-labels.

In fact, they are consistent with returning A-labels or UTF-8 domain
strings (whether canonical or not).  So it sounds to me like being
IDN-unaware would be consistent with what I listed as SVR-2 and not
SVR-1. 

I think the problem here is that if you have an Ascii type string then
being IDN-unaware does mean A-labels, but that is not true if you have a
UTF-8 type string.  In that case, being IDN-unaware means that you can
return A-labels or UTF-8 string, whether canonical or not.

I think this confusion about "IDN-unaware" has been part of what it has
made it so hard to resolve this.  At least I hope so.

So my preference list is:

    SVR-2
    SVR-3
    SVR-7
    SVR-5
    SVR-6
    SVR-4
    SVR-1

----- No go below line

    Do nothing.

-----Original Message-----
From: Nicolas Williams [mailto:[email-masked]] 
Sent: Friday, June 11, 2010 7:09 PM
To: Black, David
Cc: Noveck, David; [email-masked]
Subject: Re: i18n: Where's the problem?

 AND

 AND

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 14 Jun 2010 18:33:21 -0500

> "Dispositive" seems a little strong but let's try that.

True.  We could say that we have to fix deployed implementations.  That
doesn't always go over very well.  We'll see.

> asks you whether you do these things, you say "Huh?".

IDN-unaware means that typically only A-labels will interop correctly.
Users may or may not see punycode garbage, depending on whether the _UI_
part of the system can handle IDNA.

> So if you are IDN-unaware, then there is no code to change things to

Right.  So you'd better be using A-labels, else no/limited interop.

> with requiring that you always return A-labels.

Why not?  If you send A-labels then those implementations will work.

For example, assume all NFSv4 implementations are IDN-unaware, then
setting A-labels for replicas and referrals will work.  Thus simply
checking at the admin interfaces that these names look like valid
A-labels would suffice.  Clients might still want, though not
necessarily _need_, ToUnicode() for displaying these values in UIs.

For the domain part of user/group names it's a bit more complicated,
since more is done with those than merely storing/sending/resolving
them.  Specifically, an implementation may have to derive LDAP base DNs,
NIS domain names, etcetera, from user/group domainnames.  It may well be
that even A-labels won't work for some implementations, that only all
ASCII, NR-LDH (non-reserved LDH) labels will work; such implementation
would require fixing no matter what.

> IDN-unaware would be consistent with what I listed as SVR-2 and not

No, not quite.  If you return UTF-8 then IDN-unaware clients will likely
fail to resolve those replica/referral server names: when they pass
those names to their IDN-unaware name services APIs, or to IDN-unaware
DNS resolvers, they'll get back NXDOMAIN because they will send the
non-ASCII names as-is and the DNS server will almost certainly not match
any RRs (yeah, maybe if the server is AD and the name you're looking up
is NFC-normal already...).

> return A-labels or UTF-8 string, whether canonical or not.

See above.

> made it so hard to resolve this.  At least I hope so.

IDN-unaware means that regardless of what the protocol element's type
is, you can only send A-labels if you want to interop reliably.

For example, DNS domainnames are actually 8-bit-clean byte arrays on the
wire (so you _can_ use UTF-8 on the wire with DNS, but only if all nodes
agree that non-ASCII will be interpreted as UTF-8).  But for most things
we're limited to LDH and hostname character subsets of the US-ASCII
character repertoire.  Also, because DNS requires ASCII case-insensitive
matching, it's not really entirely 8-bit clean (you couldn't send
non-ASCII, non-UTF-8 strings and expect correct behavior, or even
non-ASCII UTF-8 strings, since the server won't know to do
case-insensitive matching for the non-ASCII parts).

In other words: it's not the protocol element type that matters, but
what implementations do with it.

Now, to follow the normal I18N tradition here we should look at the cost
of fixing deployed implementations, and possibly (likely!) settle on
officially labeling these domainname slots as IDN-unaware.  But perhaps
the cost of fixing deployed implementations is low enough that that
declaring these slots to be IDN-aware is not a big deal.  Also, it's
possible that I'm wrong and that enough implementations treat these
slots as IDN-aware that either it will be simpler to make them
officially so, or that it's a toss up, in which case we'd be free to
pick whatever we want.

Some data would be nice now.  Tomorrow I'll take a look at what
OpenSolaris does, exactly (I'm pretty sure it treats all these slots as
IDN-unaware), and then will report back.  I'd love to hear about others.

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 15 Jun 2010 16:36:45 -0500

> IDN-unaware), and then will report back.  I'd love to hear about others.

Near as I can tell, the OpenSolaris NFS stack does not do anything to
ensure that unprepared Unicode strings and U-labels in NFS domainname
slots get mapped to A-labels prior to doing DNS lookups on them.

This may be different on Linux given that glibc's getnameinfo() and
getaddrinfo() support IDNA.

I suspect fixing this will be relatively simple -- enough that we may
not want to declare NFSv4's domainname slots to be IDN-unaware just
because that's what they are in practice _now_.  Deployment is also
probably not that big a deal.

And dealing with legacy deployments (i.e., unpatched implementations) is
also easy: _administratively_ stick to A-labels on the wire (that is,
let admins toggle IDN-awareness on the server-side, possibly by simply
not converting admin-provided A-labels to U-labels).

So I remain neutral on this.  In terms of cleanliness, I'd prefer to say
that NFSv4 implementations are allowed to send un-pre-processed UTF-8 in
NFSv4 domainname slots, that implementations must be prepare to apply
ToASCII() and ToUnicode() as necessary.

Nico
--