Subject: [nfsv4] Referrals and RFC3530bis

From: "Noveck, Dave" <[email-masked]>
Date: Mon, 27 Jul 2009 21:12:52 -0400

This issue originally was brought up by people working on FedFS but I
think it has more general applicability.
 
The issue is how to describe referrals in v4.0.  In RFC3530, they are
not described.  Although the concept of migration does lead to referrals
as a limiting case, that fact was not recognized when RFC3530 was
published.  As a result ,there is not a description of how to deal with
this situation and implementers of clients and servers could wind up
with non-interoperable implementations.
 
We did work on a working group draft describing referrals but given
other stuff that was gong on, we (mainly I) dropped the ball on that and
as a result the draft expired.  As a result we have a number of possible
choices.
 
The first is to do nothing.  In this case we have the issue of the
aforementioned non-interoperable implementations.  What would most
likely happen is that implementers would use the description of
referrals in the v4.1 spec, with the v4.1-specific features dropped out.
This would not be a good idea.  The v4.1 spec is intended to describe
v4.1 and RFC3530 is intended to describe v4.0.  The more people get
these confused (and having to look in the v4.1 spec for description of
v4.0 referrals would add to this confusion), the more problems we will
have.
 
A second choice is to revive the referrals draft and see it through to
publication as an RFC.  That RFC would describe referrals in v4.0.
Until we were doing RFC3530bis, this seemed like a natural choice,
referrals were not described in RFC3530
 
The third choice is to incorporate the referrals material in RFC3530bis.
The changes for referrals would be significantly bigger than the sorts
of changes that we had been anticipating in RFC3530, but the nice thing
is that this would result in a unified treatment of referrals with other
protocol element in RFC3530bis for v4.0, just as we have in the v4.1
spec for v4.1.
 
I'm leaning to that third choice.  Even though it is somewhat more work,
I think it would produce a better result.
 
What do other people think?

---

From: "Mike Eisler" <[email-masked]>
Date: Tue, 28 Jul 2009 05:54:35 -0700

> v4.0 referrals would add to this confusion), the more problems we will

Nothing is not an option because there is NFSv4.0 referral
code shipping today.

> I think it would produce a better result.

The second or third works for me, but the second only works if RFC3530bis
makes the proper references to the referrals draft and vice versa.

I suspect the ADs, IESG, and RFC Editor would prefer the second choice ...
i.e. would prefer to deal with two smaller documents than a document
that will exceed RFC3530 in length.

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

-- 
Mike Eisler, Senior Technical Director, NetApp, 719 599 9026,
http://blogs.netapp.com/eislers_nfs_blog/

---

From: Spencer Shepler <[email-masked]>
Date: Tue, 28 Jul 2009 08:58:34 -0500

> that will exceed RFC3530 in length.

Two documents are best.  However, they can be done at the same
time to ensure consistency.  Tom Haynes has volunteered to work
on rfc3530bis and has, I believe, started the editorial work.

Spencer

---

From: <[email-masked]>
Date: Tue, 28 Jul 2009 10:12:01 -0400

>> -----Original Message-----
>> From: [email-masked] [mailto:[email-masked]] 
>> On Behalf Of Spencer Shepler
>> Sent: Tuesday, July 28, 2009 9:59 AM
>> To: [email-masked]
>> Subject: Re: [nfsv4] Referrals and RFC3530bis
>> 
>> 
>> >> published.  As a result ,there is not a description of 
>> how to deal  
>> >> with
>> >> referrals in the v4.1 spec, with the v4.1-specific 
>> features dropped  
>> >> out.
>> >> these confused (and having to look in the v4.1 spec for 
>> description  
>> >> of
>> >> v4.0 referrals would add to this confusion), the more 
>> problems we  
>> >> will
>> >> have.
>> >
>> >> A second choice is to revive the referrals draft and see 
>> it through  
>> >> to
>> >> of changes that we had been anticipating in RFC3530, but 
>> the nice  
>> >> thing
>> >> is that this would result in a unified treatment of 
>> referrals with  
>> >> other
>> >> I'm leaning to that third choice.  Even though it is 
>> somewhat more  
>> >> work,

Even though two separate documents may seem simpler now, in the long run
it could generate more confusion, where people would refer to RFC3530bis
only.

Mario

---

From: Spencer Shepler <[email-masked]>
Date: Tue, 28 Jul 2009 09:16:24 -0500

> it could generate more confusion, where people would refer to  

Yes, it could.  However, with the appropriate care, the documents can be
effectively linked together with normative references and the like.

We have had fairly strong feedback that very large documents like  
NFSv4 and 4.1
are not well received by the IETF review and editorial process.   It  
isn't the
content but that the process isn't well suited to very large  
documents.  We can
make our efforts (and those of the reviewers and editorial staff)  
easier if
we take care in how we build and deliver our work.

Spencer

---

From: Robert Thurlow <[email-masked]>
Date: Tue, 28 Jul 2009 09:19:42 -0600

Noveck, Dave wrote:

> The third choice is to incorporate the referrals material in 
> RFC3530bis.  The changes for referrals would be significantly bigger 
> than the sorts of changes that we had been anticipating in RFC3530, but 
> the nice thing is that this would result in a unified treatment of 
> referrals with other protocol element in RFC3530bis for v4.0, just as we 
> have in the v4.1 spec for v4.1.

Hi Dave, thanks for raising this.  I agree that we need to
get a spec for this stuff.

The third choice would be nice in several ways, but it is a
lot of work and churn.  Reviving the referrals draft seems
easy - it's already saying what needs to be said, and just
needs to run through the process to become an Informational
RFC, so that feels more practical.

Rob T

---

From: "Noveck, Dave" <[email-masked]>
Date: Fri, 31 Jul 2009 13:06:03 -0400

Now we are talking about something entirely different.

If this is an informational RFC, then RFC3530bis cannot make normative
references to it.  Right?

There are parts of the current document that could fit in the
informational model.  Half the document is the examples and I think
those might fit in the informational model.  Also there is soem
introductory material that might fit in that.  

But if RFC3530bis says that there are referrals and that how they work
is described in this other document, how can it be anything other than
part of the v4.0 standard and thus not informational.

-----Original Message-----
From: Robert Thurlow [mailto:[email-masked]] 
Sent: Tuesday, July 28, 2009 11:20 AM
To: Noveck, Dave
Cc: [email-masked]
Subject: Re: [nfsv4] Referrals and RFC3530bis

Rob T

---

From: "Noveck, Dave" <[email-masked]>
Date: Fri, 31 Jul 2009 13:35:23 -0400

> I suspect the ADs, IESG, and RFC Editor would 
> prefer the second choice ... i.e. would prefer 
> to deal with two smaller documents than a 
> document that will exceed RFC3530 in length.

Any clarifications of any sort will add length to RFC3530bis relative to
RFC3530.

Also, although the ADs, IESG, and RFC Editor have their views, don't the
user's needs have to be taken into account.  As a user, I would hate
having two documents.

Also, we will then have the issue of what happens if there is
inconsistency.  What controls?  I know that Tom and me making any
mistakes of that sort is inconceivable, but still, anything can happen.

Wouldn't RCF3530bis in introducing that subject have to address the
consistency issue.

We're not talking about something that approaches the v4.1 spec in
length.  Doing this via refercnes to another spec is not gong to take no
space.  It will take a page two.

Is this really such a problem.  If we kept the additions to say 7-10
pages, is this worth having a separate spec?  Can we not reply on the
at-least-it's-a-lot-smaller-than-v4.1 effect?

-----Original Message-----
From: Mike Eisler [mailto:[email-masked]] 
Sent: Tuesday, July 28, 2009 8:55 AM
To: Noveck, Dave
Cc: [email-masked]
Subject: Re: [nfsv4] Referrals and RFC3530bis

> The third choice is to incorporate the referrals material in
RFC3530bis.
> I think it would produce a better result.

The second or third works for me, but the second only works if
RFC3530bis
makes the proper references to the referrals draft and vice versa.

I suspect the ADs, IESG, and RFC Editor would prefer the second choice
...
i.e. would prefer to deal with two smaller documents than a document
that will exceed RFC3530 in length.

---

From: Robert Thurlow <[email-masked]>
Date: Fri, 31 Jul 2009 11:37:27 -0600

> part of the v4.0 standard and thus not informational.

If it should be standards-track, that's fine.  I mentioned
informational since no new protocol elements are introduced
and the referrals draft is about interpretation of how
data and ops are handled in a new case.  But it does also
specify new and useful behaviours, so I was probably not
correct in my thinking.

Rob T

---

From: Spencer Shepler <[email-masked]>
Date: Fri, 31 Jul 2009 12:41:26 -0500

> at-least-it's-a-lot-smaller-than-v4.1 effect?

http://tools.ietf.org/html/draft-ietf-nfsv4-rfc3530bis-00

Is currently at 240 pages.  Provide your updates to Tom and
let's see where it leads us.

Having the content first and then working on form a little
later is a reasonable path to follow.

Spencer