Re: [nfsv4] Going forward on I18N in RFC3530 bis

> I was a bit more quiet on this point than I should 
> have been - I think we should be trying to avoid a 
> 3530tris unless we can make sure that the delta is 
> pretty small. 

It's interesting how attitudes can differ.  I think Tom and I have
similar attitudes towards RFC3530tris but neither said much.  Tom
regrets he didn't say more while I was patting myself on the back for
the restraint I showed.

I think the point is that despite the validity of Tom's position, there
isn't much we can do at this point.  There is some speculative set of
changes that precis might make desirable but it might be the null set.
There no way to tell and speculation is a waste of time.  We should do
what we can do now and leave what we can't do now to the future.

> We will not be winning friends with 
> the ADs with huge changes.

Granted but if they are required then we will make them.  We have to
decide whether the goal is making friends or properly specifying the
protocol.  If I was concerned with winning friends with the AD's, I
would have left the internationalization chapter pretty much as it was,
pretend that everything was OK, and have some more free time.  So I
realize I made a bad decision but that's life :-)

> If the i18n chapter is the same for 3530, 5661, and 
> whatever comes next, perhaps it should be a separate 
> document.

Perhaps, but I'd rather we didn't try to make that decision now and
complicate the process.  I believe that as we think about going to
group-last-call for RFC3530-bis, we should decide on whether we want to
split out the internationalization as a separate document that applies
to multiple minor versions.  If we decide to do that, it can be done is
a day or less.

And I really hope Tom is wrong about I18N churn.  We'll see.

-----Original Message-----
From: Thomas Haynes [mailto:thomas@netapp.com] 
Sent: Friday, September 10, 2010 10:33 AM
To: Trond Myklebust
Cc: Noveck, David; nfsv4@ietf.org
Subject: Re: [nfsv4] Going forward on I18N in RFC3530 bis

On Sep 9, 2010, at 6:38 PM, Trond Myklebust wrote:

> On Thu, 2010-09-09 at 18:35 -0400, david.noveck@emc.com wrote:
>> David Black (the man behind NFSv4.2 :-) has asked me to summarize the
>> situation with regard to I18N in RFC3530 and the current plan about
what
>> to do about it going forward in handling it in RFC3530bis.
>> ---- Discussion on call:
>> 
>> The big issue discussed was whether we should wait for precis to
finish
>> this up.
>> 
>> David Black came to the conclusion that since precis work was not
>> proceeding very fast, we should go ahead based on the current draft
plus
>> working group comments, with the potential of an additional update
>> (RFC3530tris?) when the precis work is finished and can be applied to
>> NFSv4.

I was a bit more quiet on this point than I should have been - I think
we should
be trying to avoid a 3530tris unless we can make sure that the delta is
pretty
small. We will not be winning friends with the ADs with huge changes.

If the i18n chapter is the same for 3530, 5661, and whatever comes next,
perhaps it should be a separate document.

I was okay pulling the ACL and Multi-Server Namespace chapters back from
5661 because in essence we were saying that implementation experience
has shown us what we should have originally put down and we know there
won't be wholesale changes in these areas again. I.e., fs_locations_info
is
already in place and will not be backported.

But the i18n seems ripe for a lot of churn.

>> 
>> There were arguments about his use of the word "patch" and the
probable
>> relative proportions of updates in RFC3530bis and its successor but
no
>> fundamental disagreement on the basic approach.
>> 
>> I will be working on an update to chapter 12 that will go into a new
>> draft of rfc3530-bis, targeted at the Beijing deadline.  May be able
to
>> get it out earlier but I hope people will have chance to look at the
>> current draft and give me their comments.
> 
> The other point that I heard being made (and for which we appeared to
> have consensus) was that in the short term, we should attempt to
> document existing practice (as Dave has indeed been doing). IOW:
> existing NFS implementations and best practices should be the
guideline
> for 3530bis while we wait for the IETF High Lords of
> Internationalisation to agree on basic procedure...
> 
> Cheers
>  Trond
> 
> _______________________________________________
> nfsv4 mailing list
> nfsv4@ietf.org
> https://www.ietf.org/mailman/listinfo/nfsv4