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

Before getting excited about document separation, let's work through
the review of the details and use that as a means to determine the
best method of document management.

As an aside: The clear goal for rfc35030bis is to fix the bugs with respect to
successful implementation from the text.  Is there any desire from the
WG to consider the document update as attempt to move the
protocol beyond proposed standard or is the sense that it is still
too early or not within the energy envelope of the WG?

Spencer

> -----Original Message-----
> From: nfsv4-bounces@ietf.org [mailto:nfsv4-bounces@ietf.org] On Behalf
> Of Thomas Haynes
> Sent: Friday, September 10, 2010 7:33 AM
> To: Trond Myklebust
> Cc: 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
> 
> _______________________________________________
> nfsv4 mailing list
> nfsv4@ietf.org
> https://www.ietf.org/mailman/listinfo/nfsv4