Subject: Re: [nfsv4] NFSv4.1 I-D working group last call planning

From: Mike Eisler <[email-masked]>
Date: Mon, 7 Jan 2008 09:58:30 -0800 (PST)

Spencer is out this week.

As an editor, I formally request a WG last call for:

  http://www3.tools.ietf.org/html/draft-ietf-nfsv4-minorversion1-18.txt
     
http://www3.tools.ietf.org/html/draft-ietf-nfsv4-minorversion1-dot-x-02.txt

The proposed period of time for the Last Call is now through March 7.

Regarding, 

> [...]  The first half
> of the review will be completed around Feb 1st and the second
> half just before the next IETF meeting (roughly March 7th).
> 
> Specifics are forthcoming but the contents of the first half of
> the review will entail the portions of the I-D that are more
> expository in nature or that cover functionality that exists
> in NFSv4.0.  The second half will focus on the Sessions and pNFS
> functionality given that we have a bakeathon scheduled the
> week of Feb 18th.

I've no problem with taking comments on sessions and pNFS before Feb
18,
especially given that these are the key features of NFSv4.1.

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

---

From: "J. Bruce Fields" <[email-masked]>
Date: Mon, 7 Jan 2008 13:14:39 -0500

> especially given that these are the key features of NFSv4.1.

Basic questions: what does "Last Call" mean?

What specifically do you want from people at this point?  (Any
particular kinds of comments?)

--b.

---

From: Mike Eisler <[email-masked]>
Date: Mon, 7 Jan 2008 10:43:05 -0800 (PST)

> Basic questions: what does "Last Call" mean?

The last chance for this working group to make comments
on the two NFSv4.1 documents before the documents are
handed to the Area Advisor for review and ultimately
a decision to publish the documents as RFCs. 

> particular kinds of comments?)

Nits, errors, this won't work, this could be clearer
etc. Essentially if you are happy with the two documents 
being issued as RFCs as is, then say nothing. Otherwise, speak up.

(Remember: RFCs are forever.)

Jason Glasgow, for example, has already spoken.

---

From: "J. Bruce Fields" <[email-masked]>
Date: Mon, 7 Jan 2008 13:52:41 -0500

> a decision to publish the documents as RFCs. 

How are corrections going to be handled?  Will some kind of drafts still
be issued during this period?

> (Remember: RFCs are forever.)

What was the story with 3010 and 3530?  I assume that was the result of
discovering a serious protocol problem after issuing the first rfc, and
not something that's expected?

--b.

---

From: Dean Hildebrand <[email-masked]>
Date: Mon, 07 Jan 2008 10:56:38 -0800

> (Remember: RFCs are forever.)
How does issues found after march 7th due to development issues fit into 
this?  On the Linux side, I'm not sure draft-18 will be fully 
implemented by March 7th.

Also, I remember someone mentioning something about requiring 2 
inter-operating implementations before a rfc could be finalized.  Is 
this urban legend or is it referring to something else?

Thanks,
Dean

---

From: "Noveck, Dave" <[email-masked]>
Date: Mon, 7 Jan 2008 14:00:37 -0500

> discovering a serious protocol problem after issuing the first rfc, 

Yes.

> and

We hope not.  One of the reasons for the formal review sessions was to
make that as unlikely as we can.  Another way of preventing that sort of
things is careful review during the last-call period.

-----Original Message-----
From: J. Bruce Fields [mailto:[email-masked]] 
Sent: Monday, January 07, 2008 1:53 PM
To: Mike Eisler
Cc: Spencer Shepler; Pawlowski, Brian; [email-masked]
Subject: Re: [nfsv4] NFSv4.1 I-D working group last call planning

--b.

---

From: [email-masked]
Date: Mon, 7 Jan 2008 14:08:56 -0500

Dean,

See ftp://ftp.isi.edu/in-notes/rfc2026.txt 

Section 4 defines the maturity levels.  It would appear that the "2 
inter-operating implementations" requirement refers to moving from a
"Proposed Standard" to a "Draft Standard".

-Jason

-----Original Message-----
From: Dean Hildebrand [mailto:[email-masked]] 
Sent: Monday, January 07, 2008 1:57 PM
To: [email-masked]
Cc: J. Bruce Fields; Spencer Shepler; Brian Pawlowski; [email-masked]
Subject: Re: [nfsv4] NFSv4.1 I-D working group last call planning

Thanks,
Dean

---

From: Spencer Shepler <[email-masked]>
Date: Mon, 07 Jan 2008 13:18:16 -0600

On Jan 7, 2008, at 12:56 PM, Dean Hildebrand wrote:
>>
> How does issues found after march 7th due to development issues fit  
> into this?  On the Linux side, I'm not sure draft-18 will be fully  
> inter-operating implementations before a rfc could be finalized.   
> Is this urban legend or is it referring to something else?

You will find an overview of the IETF standards process here:
http://www.ietf.org/IESG/content/ions/ion-procdocs.html

In response to the "what happens after March 7th"...

What we have started now is the working group last call.
This is the work that the working group goes through to ensure
the quality and content of the I-D before it is submitted
to the IESG for overall IETF review (which may include things
like expert review, an IETF last call and will include review
by IANA and the the IETF editors, etc.).

So this is an iterative process.

Comments received at March 7th may be feed back into the
working group because we  are in another WG last call or
it may be directed at the IESG because the I-Ds are in
last call processing there.

As for implementation requirements, for an I-D to become
an RFC at the "Proposed" standard level, there are no
implementation requirements what so ever.  The move from
"Proposed" to "Draft" is where the implementation requirements
are introduced.  These issues are spelled out in RFC 2026
ftp://ftp.isi.edu/in-notes/rfc2026.txt

Spencer

---

From: Mike Eisler <[email-masked]>
Date: Mon, 7 Jan 2008 11:30:26 -0800 (PST)

--- "J. Bruce Fields" <[email-masked]> wrote:

> > handed to the Area Adviser for review and ultimately

Corrections will be checked into the cvs respository, and will
appear in the documents before they become RFCs.
Depending on the number/scope of corrections, new drafts might be
issued between now and the end of WG last call, or just one pair of
drafts will be issued before handing to Area Adviser. I'm hoping for
the best, planning for the worst [no extended holidays for me from now
through the end of April], expecting as with most things in life for
the outcome to fall somewhere between.

---

From: Lars Eggert <[email-masked]>
Date: Tue, 8 Jan 2008 06:33:06 +0200

On 2008-1-7, at 20:43, ext Mike Eisler wrote:
> Essentially if you are happy with the two documents

Please also speak up if you're happy with the documents. Makes it  
easier to differentiate disinterest from approval.

Thanks,
Lars

---

From: Lars Eggert <[email-masked]>
Date: Tue, 8 Jan 2008 06:34:34 +0200

> this urban legend or is it referring to something else?

You need two independent, interoperating implementations for a Draft  
Standard RFC. This ID is going for  Proposed Standard, for which no  
such requirement exists.

Lars

---

From: [email-masked]
Date: Tue, 8 Jan 2008 08:27:33 -0500

> From: Lars Eggert [mailto:[email-masked]] 
> Sent: Monday, January 07, 2008 11:35 PM
> To: ext Dean Hildebrand
> Cc: [email-masked]; J. Bruce Fields; Spencer 
> Shepler; Brian Pawlowski; [email-masked]
Does this mean that we need two servers and two client implementations,
or at least one server and one client that interoperate ?
Mario

---

From: Lars Eggert <[email-masked]>
Date: Tue, 8 Jan 2008 23:15:43 +0100

> or at least one server and one client that interoperate ?

Good question. I polled the IESG, and our interpretation of RFC2026 is  
that going to Draft Standard requires two independent and  
interoperable implementation of each protocol *feature*. Because  
server implementations implement one aspect of a feature and client  
implementations implement the complementary aspect of a given feature,  
you'd need two independent client implementations and two independent  
server implementations, and show pairwise interoperability.

Lars

---

From: Brian Pawlowski <[email-masked]>
Date: Tue, 8 Jan 2008 14:28:51 -0800 (PST)

> server implementations, and show pairwise interoperability.

I would argue that within Linux, the NFS server and the NFS client
are distinct and unique implementations. For example.

So, I might argue that two OS client/server interoperation could
be demonstrated solely with Solaris and Linux client/server
interoperating.

That said - we have more implementations in flight (NetApp NFS
server for example, and FreeBSD (MacOS) client).

We won't lack implementations - the more subtle question will
be features support and pruning unimplemented features moving
from Proposed to Draft status.

All THAT said - NFS V4.1 (currently in last call) I assume is teed
up for approval as Proposed Standard (as NFS V4 
http://www.ietf.org/rfc/rfc3530.txt is currently).
We will not advance RFC 3530 to Draft Standard.

beepy

---

From: Lars Eggert <[email-masked]>
Date: Tue, 8 Jan 2008 23:41:11 +0100

> be demonstrated solely with Solaris and Linux client/server

That's probably correct, but my understanding of how the  
implementations interrelate is spotty at best. In any event, the  
implementation activity around NFSv4 leaves me confident that a lack  
of implementations won't be an issue when the time comes to move the  
spec to Draft Standard. (FYI, RFC2026 defines "independent  
implementations" a bit more precisely than I did.)

> We will not advance RFC 3530 to Draft Standard.

That's my understanding, too.

Lars

---

From: Mike Eisler <[email-masked]>
Date: Tue, 8 Jan 2008 15:11:11 -0800 (PST)

> server implementations, and show pairwise interoperability.

This is interesting to know. However, my 
understanding is that in order for a technical 
specification X to rise to Draft, all technical 
specifications that X makes normative references 
too must be at Draft or Standard.

NFSv4.1 currently makes normative references 
to 13 standards track RFCs or I-Ds. One, 
XDR, is at Draft or higher. In most
cases, reasons of inertia, not technical, are 
preventing these from being advanced. (E.g. do we
really think there are not 2-4 interoperable,
independent implementations of IPv6 addressing
architecture?).

Practically, unless IETF makes it a policy to
review mature proposed standards and proactively
advanced them to Draft, I'm certain I will be
dead before NFSv4.1 becomes a Draft Standard.

And yes, the NFSv4.1 WG has responsibility for at
least two of the normative Proposed Standards.

So if people think it is important to have NFSv4.1
be a Draft Standard, get busy writing implementation
reports for the normative RFCs. Bill Janssen and I took care 
of one already,

  http://www.ietf.org/IESG/Implementations/XDR-implementation :-)

---

From: "Noveck, Dave" <[email-masked]>
Date: Tue, 8 Jan 2008 18:40:24 -0500

If we (or as Mike might point out, our successors) do move v4.1 to Draft
Standard, then I think we are supposed to remove features for which
there are not the requisite independent interoperating implmentations.
If there are some of these then we may have a situation in which there
is a feature in the Proposed Standard for v4.0, RFC3530, and not in the
Draft Standard for v4.1, making the latter not a superset of the former.
I would hope/assume that we (or they) can deal with this be making the
features in question mandatory to not implement, rather than actually
deleting them, which would break the minor-versioning connection between
v4.0 and v4.1. 

-----Original Message-----
From: Lars Eggert [mailto:[email-masked]] 
Sent: Tuesday, January 08, 2008 5:41 PM
To: Pawlowski, Brian
Cc: [email-masked]; [email-masked]; [email-masked];
[email-masked]; [email-masked]
Subject: Re: [nfsv4] NFSv4.1 I-D working group last call planning

On 2008-1-8, at 23:28, ext Brian Pawlowski wrote:
> I would argue that within Linux, the NFS server and the NFS client are

> distinct and unique implementations. For example.
>
> So, I might argue that two OS client/server interoperation could be 
> demonstrated solely with Solaris and Linux client/server 
> interoperating.

That's probably correct, but my understanding of how the implementations
interrelate is spotty at best. In any event, the implementation activity
around NFSv4 leaves me confident that a lack of implementations won't be
an issue when the time comes to move the spec to Draft Standard. (FYI,
RFC2026 defines "independent implementations" a bit more precisely than
I did.)

> That said - we have more implementations in flight (NetApp NFS server 
> for example, and FreeBSD (MacOS) client).
>
> We won't lack implementations - the more subtle question will be 
> features support and pruning unimplemented features moving from 
> Proposed to Draft status.
>
> All THAT said - NFS V4.1 (currently in last call) I assume is teed up 
> for approval as Proposed Standard (as NFS V4 

Lars

---

From: Lars Eggert <[email-masked]>
Date: Wed, 9 Jan 2008 10:31:39 +0100

> too must be at Draft or Standard.

Correct.

>  http://www.ietf.org/IESG/Implementations/XDR-implementation :-)

Yes, there is some busy work associated with moving things to DS. The  
NFSv4 charter also explicitly states in a few places that "advancing  
RFC so-and-so along the standards track" is a work item, because we  
knew this was going to be needed.

Lars

---

From: Lars Eggert <[email-masked]>
Date: Wed, 9 Jan 2008 10:36:43 +0100

> Draft Standard for v4.1, making the latter not a superset of the  

Correct. If for some protocol features of a PS document  
interoperability cannot be documented, they cannot remain part of the  
DS.

> deleting them, which would break the minor-versioning connection  

I'm not quite sure what you mean by "not mandatory to implement." One  
approach is to make protocol features that can't move to DS optional  
extensions that remain at PS when the main part of the spec moves to  
DS. But I'm not sure how this interacts with the NFSv4 versioning  
rules, because these optional extensions will not be part of the  
required-to-implement set that specified NFSv4.1.

Lars

---

From: "Noveck, Dave" <[email-masked]>
Date: Wed, 9 Jan 2008 09:30:14 -0500

> I'm not quite sure what you mean by "not mandatory to implement." 

It's not "not mandatory to implement", but rather "mandatory to not
implement".  

This is associated with the v4 minor-versioning rules.  Since, the basic
structure of minor versioning is to add things, we need some way to
delete things, but we don't want to have inconsistent XDR definitions
within the framework of a single RPC program version.  So, for example,
given that SETCLIENTID has been superseded in v4.1, it still retains the
operation number it had in v4.0 (and we wouldn't want it reassigned).
But since SETCLIENTID is in fact superseded, servers, just not implement
it and MUST return NFS4ERR_NOTSUPP.  It is "mandatory to not implement".

> One  

This sounds like a recipe for chaos.  You have a document that includes
some optional features (and we are only talking about optional features
here) that is at PS and a second document that describes a subset of
those features (including all the mandatory ones and some of the
optional ones) and they are both advertised as descriptions of v4.1.
Normally I'd rely on the more complete one, but I suppose that when we
create the DS version, we will fix and clarify things as well as
deleting from this document certain optional features.  Now I want to
understand how to implement something.  Which one do I look at,
particularly if I want to implement the optional feature.  Suppose that
certain forms of notification don't make it and I'm implementing some op
where the PS text refers to that sort of notification and the DS text
doesn't and has some other subtle differences.  What I would need to
implement is a synthesized description where the DS version is primary
except where the PS version is different and that difference is
motivated, whether explicitly or implicitly, by the potential presence
of that feature.  And the DS document, since it doesn't refer to the
removed feature will not be much help in defining where the PS version
may disagree and have priority.

Given all these issues, I suspect that interest in moving to DS is going
to be pretty limited unless the set of features to remove is empty, and
that would probably take a long time.

> But I'm not sure how this interacts with the NFSv4 versioning  

The problem is not really with the minor version rules.  You seem to be
saying that we can retain optional features in v4.1 (as optional
features), while creating an RFC that describes v4.1 (and is the
official document with that role) that doesn't mention them and that
seems really problematic.  I think you have to be able to remove the
features that don't make it and given that the DS v4.1 protocol had
better be able to interoperate with those implementing the PS v4.1
protocol, I think the best way to do that is to make the dropped
features mandatory to not implement for v4.1 and we would still have the
option of bringing them back in a subsequent minor version.

-----Original Message-----
From: Lars Eggert [mailto:[email-masked]] 
Sent: Wednesday, January 09, 2008 4:37 AM
To: Noveck, Dave
Cc: [email-masked]; [email-masked]; [email-masked];
[email-masked]; [email-masked]; Pawlowski, Brian
Subject: Re: [nfsv4] NFSv4.1 I-D working group last call planning

Lars

---

From: Benny Halevy <[email-masked]>
Date: Wed, 09 Jan 2008 19:02:33 +0200

> it and MUST return NFS4ERR_NOTSUPP.  It is "mandatory to not implement".

Seems like saying "mandatory to implement as non-supported" may be 
even clearer.