Subject: [nfsv4] No WG meeting for IETF 91

From: Spencer Shepler <[email-masked]>
Date: Thu, 25 Sep 2014 15:57:38 +0000

Given the very small agenda (below) and most of it being updates on current work, I will NOT be requesting meeting time at IETF 91.

If discussion needs to occur between now and IETF 92, please use the WG alias or we can schedule a specific conference call as a design team discussion for a particular I-D.

Thanks,
Spencer

Tom Haynes
- 3530bis update
- NFSv4.2 update
- LNFS registry update
- Layout types update

Manoj Naik
- xattr draft

---

From: Andy Adamson <[email-masked]>
Date: Thu, 25 Sep 2014 13:42:58 -0400

Hi Spencer

If we do decide to have a meeting, I will present

gssv3 draft update

nfsv4 multi-domain access update

On Thu, Sep 25, 2014 at 11:57 AM, Spencer Shepler
<[email-masked]> wrote:
>
>
> Given the very small agenda (below) and most of it being updates on current
> work, I will NOT be requesting meeting time at IETF 91.
>
>
>
> If discussion needs to occur between now and IETF 92, please use the WG
> alias or we can schedule a specific conference call as a design team
> discussion for a particular I-D.
>
>
>
> Thanks,
>
> Spencer
>
>
>
> Tom Haynes
>
> - 3530bis update
>
> - NFSv4.2 update
>
> - LNFS registry update
>
> - Layout types update
>
>
>
> Manoj Naik
>
> - xattr draft
>
>
> _______________________________________________
> nfsv4 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/nfsv4
>

---

From: Marc Eshel <[email-masked]>
Date: Thu, 25 Sep 2014 20:58:08 -0700

I am not coming to the meeting this time but I don't think that we should 
cancel it. This group need to get energized and start making more progress 
like other protocols do. If NFSv4.2 is done we should start working on the 
next version. There is plenty more to do. These meetings are important not 
only for the official meeting but also for the face to face interaction 
around it. As long as there is more work to do we should keep meeting 
unconditionally. We keep talking about moving faster but we are still 
moving very slowly and starting to cancel meeting will lead only to more 
inactivity. Having to present and review draft always helps things to more 
activity and canceling meeting will only slow things. 
Marc. 

From:   Spencer Shepler <[email-masked]>
To:     "[email-masked]" <[email-masked]>, 
Date:   09/25/2014 08:58 AM
Subject:        [nfsv4] No WG meeting for IETF 91
Sent by:        "nfsv4" <[email-masked]>

Given the very small agenda (below) and most of it being updates on 
current work, I will NOT be requesting meeting time at IETF 91.

Thanks,
Spencer
 
Tom Haynes
- 3530bis update
- NFSv4.2 update
- LNFS registry update
- Layout types update
 
Manoj Naik
- xattr draft_______________________________________________
nfsv4 mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/nfsv4

---

From: David Noveck <[email-masked]>
Date: Fri, 26 Sep 2014 09:54:34 -0400

> I am not coming to the meeting this time

Neither am I.  Actually, given that we now have a pattern in which wg
meetings may be canceled about six weeks before the meeting date, we may be
in a situation in which it is essentially impossible for me to arrange
travel approval.

> but I don't think that we should cancel it.

I don't see any reason to cancel it either.

> This group need to get energized

Indeed.  I would have found a meeting in Honolulu quite energizing :-)

> and start making more progress like other protocols do.

An important discussion to have somewhere (e.g. Bakeathon) is on the
question of why we are making such limited progress.  Analysis of what
other protocols are doing might help.  Then again, it might just depress us
:-(

> If NFSv4.2 is done

It's done when it is published as an RFC and there are some implementations
out there that people can test against.  Right now it is in last-call which
is nice but it is not the end of the 4.2-related work.

> we should start working on the next version.

I don't agree.  I think the minor versioning model has failed and should
not be pursued further.   The important thing is to develop and implement
features, and minor versioning is not contributing positively to that
process.  As an example, if we have good luck, v4.2 will be published as an
RFC about six years after the first individual draft defining an important
constituent feature.  Whether that is to be considered fast or slow is a
matter of opinion but personally I'm troubled about the length of the
process.

> These meetings are important not only for the official meeting but also
for the
> face to face interaction around it.

This point has been made repeatedly.  I haven't done a poll but I think
most members of the working group
agree with your perspective on this issue.

it seems that Spence (and Beepy/?) feel differently, but i'm not sure how
to resolve this major
disagreement about working group meetings.

> As long as there is more work to do we should keep meeting
unconditionally.

I think we should go back to where we were before Spencer started to assume
that the need for a meeting had to be established in the face of a
presumption that we would not meet .

Before that, we generally assumed that we would be meeting but people were
free to argue that there was some reason we shouldn't meet.

One possibility that I've considered is to make the last order of business
for each working group meeting, a discussion of plans for the next one.
With
one week of discussion on the working group list (to accommodate those who
did not attend), we'd still have a decision on this question in sufficient
time for people to have time to get travel approval.

> and starting to cancel meeting will lead only to more inactivity

What's most troubling is that Spencer seems to be making the lack of
progress an argument for cancelling the meeting.  Sounds to me like we have
the makings of  death-spiral :-(

> Having to present and review draft always helps things to more activity
and canceling meeting will only slow things

Agree but note that Spencer's assumption is that presentation of work in
progress (i.e. an  "update") is a not a reason to meet.

i think the working group members and the working group  co-chairs cannot
go on indefinitely having such divergent opinions about the function of
meetings.

This issue needs to be resolved somehow.

---

From: Thomas Haynes <[email-masked]>
Date: Fri, 26 Sep 2014 10:45:42 -0400

On Sep 26, 2014, at 9:54 AM, David Noveck <[email-masked]> wrote:

> What's most troubling is that Spencer seems to be making the lack of progress an argument for cancelling the meeting.  Sounds to me like we have the makings of  death-spiral :-(

I don't see it as a lack of progress, but rather that there is a lot of progress and nothing really controversial in open issues right now.

The way that there would be a death spiral is if the members had a lack of energy.

> 
> > Having to present and review draft always helps things to more activity and canceling meeting will only slow things
> 
> Agree but note that Spencer's assumption is that presentation of work in progress (i.e. an  "update") is a not a reason to meet.
> 

I'd like to see more activity spread out over the four months on the WG alias than status updates at the IETF venue.

I'd like to see draft updates be done outside of the window right before the meeting.

Do I think both approaches have benefit? Sure, some recent examples would be:

1) The editing and reviews of NFSv4.2 has worked better on the alias rather than in person.

2) Andy's presentation last year on the different server-to-server options worked better at the IETF meeting than online.

3) The recent RPCSEC_GSSv3 work has benefited from both styles of communication.

> i think the working group members and the working group  co-chairs cannot go on indefinitely having such divergent opinions about the function of meetings.  
> 

The co-chairs proposed a model where the group did not meet by default. The members decided they did not like that model. The co-chairs accepted that and have had meetings at all events since then.

They asked for agenda items and in my opinion were presented with a weak agenda. Given the same information, I would also not hold this meeting.

---

From: "J. Bruce Fields" <[email-masked]>
Date: Fri, 26 Sep 2014 17:10:07 -0400

On Fri, Sep 26, 2014 at 09:54:34AM -0400, David Noveck wrote:
> out there that people can test against.

Linux (client and server) has one 4.2 feature (labeled NFS) implemented
and in user's hands, more (SEEK, ALLOCATE) that look probably complete
and likely to be in released software soon, and more being actively
worked on.

> Right now it is in last-call which is nice but it is not the end of
> the 4.2-related work.

The publication of the RFC isn't *the* end either.  Individual features
need to get implemented and that will happen at various times.

We also have proposals for v4.3 stuff under discussion.

So it looks to me like progress is being made at all stages of the
pipeline.

I guess the interesting question to me is "who feels like their work is
being held up by IETF process".  And "would meeting in Honolulu help".

(Not planning to attend, so my opinion doesn't count much either way on
the Honolulu question).

--b.

---

From: David Noveck <[email-masked]>
Date: Sun, 28 Sep 2014 09:42:45 -0400

> and likely to be in released software soon, and more being actively

It's good to hear that work is proceeding on implementations, even the
absence of the IETF Stamp of Approval.

> We also have proposals for v4.3 stuff under discussion.

If you look at the history of v4.2, the gap from the first I-D describing a
feature (inter-server copy) to v4.2 WGLC, was about five and a half years.
The gap to RFC publication (if that matters) looks like six years at best.

Even though progress is being made, I'm troubled by delays of that length.

> being held up by IETF process".

That would be an interesting question to discuss at the next working group
meeting
(e.g. Dallas).  I'm not sure it would be considered a suitable agenda item,
however.
Still, it is important to understand problems in the process and talk about
fixing them
and think a face-to-face discussion would be helpful.

> And "would meeting in Honolulu help".

It might, but if attendance at a meeting is so limited, don't expect much
to come out of it.

Anyway, I don't see any prospect of changing the no-at-91 decision so let's
just consider Honolulu an undone deal.

> (Not planning to attend, so my opinion doesn't count much either way on the
Honolulu
> question).

Following that line of thought:

   - I'm not planning to attend so my opinion doesn't count much.
   - Marc isn't planning to attend so his opinion doesn't count much
   - Spencer isn't planning to attend so his opinion doesn't count much :-)

I think the real issue is how we should handle the decision about deciding
to meet and I think all members of the working group who have an opinion
should express it and have their opinion listened to seriously.

I have a problem with the decision-based-on-proposed-agenda model which
turns into a decision-made-at-the-last-minute model.  If we can't go back
to the meet-by-default model, which I think is desirable, we have to have
some meetings at least, where an early commitment to have a meeting is made
in advance.  If people know there will be a meeting and there is an
expectation that most people will attend, people will find  nfsv4-related
things to talk about.

Overall, I think having working group meetings has been helpful and that we
should have them whenever there is sufficient working group interest.  If
Spencer had polled working group members and found no interest in meeting
in Honolulu, I would have had no problem with that.

I think we need a clear statement by Spencer that we will meet at IETF 92
in Dallas. Honolulu is nicer but at least it's not Florida.

I'm not in a position now to commit to attend the meeting but I think a
useful agenda item would consider the question you raised about how the
process is helping or hurting progress.   That's the kind of thing we
should be talking about if there are no contentious open issues about specs
being developed.

---

From: Benny Halevy <[email-masked]>
Date: Mon, 29 Sep 2014 09:14:54 +0300

> absence of the IETF Stamp of Approval.

Retrospectively, although implementation is not a requirement to move a
spec from Internet Draft status
to RFC, that is de-facto standard, it is highly beneficial due to the
complexity of the protocol.
Getting the IETF Stamp of Approval on features that were not important
enough for someone to implement
at the draft stage and to prove their concept is questionable in my opinion.

> If you look at the history of v4.2, the gap from the first I-D describing
> a feature (inter-server copy) to v4.2 WGLC, was about five and a half
> years.  The gap to RFC publication (if that matters) looks like six years
> at best.
>

Me to, hence my position advocating a more modular and extensible protocol
that allows add-on features
to be added, discovered, and version-negotiated dynamically on top of the
base protocol.

I believe that specifying these protocol features (that may include, e.g.
 data structure definitions, operations,
and new attributes, flags, or options to existing operations) could be done
rapidly with relatively little marginal
effort - therefore shortening the innovation turnaround.

Benny

> (e.g. Dallas).  I'm not sure it would be considered a suitable agenda
> item, however.
> Still, it is important to understand problems in the process and talk
> about fixing them
> Anyway, I don't see any prospect of changing the no-at-91 decision so
> let's just consider Honolulu an undone deal.
>
> Overall, I think having working group meetings has been helpful and that
> we should have them whenever there is sufficient working group interest.
> If Spencer had polled working group members and found no interest in
> meeting in Honolulu, I would have had no problem with that.
>

---

From: Thomas Haynes <[email-masked]>
Date: Mon, 29 Sep 2014 09:10:24 -0400

On Sep 29, 2014, at 2:14 AM, Benny Halevy <[email-masked]> wrote:

> It's good to hear that work is proceeding on implementations, even the absence of the IETF Stamp of Approval.
> 
> Retrospectively, although implementation is not a requirement to move a spec from Internet Draft status
> to RFC, that is de-facto standard, it is highly beneficial due to the complexity of the protocol.
> Getting the IETF Stamp of Approval on features that were not important enough for someone to implement
> If you look at the history of v4.2, the gap from the first I-D describing a feature (inter-server copy) to v4.2 WGLC, was about five and a half years.  The gap to RFC publication (if that matters) looks like six years at best.
> 
> Me to, hence my position advocating a more modular and extensible protocol that allows add-on features
> to be added, discovered, and version-negotiated dynamically on top of the base protocol.

I'll claim that the top three reasons that the 4.2 work is delayed are:

1) 4.1 implementations not being feature complete
2) 4.2 prototypes not being started until the last year or so
3) A lack of energy in the WG

The first two are important because we need to deliver a protocol that can be implemented. It is great
to get some major feature in a release, but if there is no implementation experience, how do we know
we haven't painted ourselves in a corner that requires extensive rework to an XDR that can't change?

Migration is a great example here.

> 
> I believe that specifying these protocol features (that may include, e.g.  data structure definitions, operations,
> and new attributes, flags, or options to existing operations) could be done rapidly with relatively little marginal

This is the other reason for having a working N-1 implementation.

And this is a great example about the lack of energy in the WG. I've heard 3 people talk about wanting new minor versioning rules this last week. There is no real traffic on the WG and the couple of drafts on it seemed to have died down.

I.e., this is on track to be delivered in 5 years.

> That would be an interesting question to discuss at the next working group meeting
> (e.g. Dallas).  I'm not sure it would be considered a suitable agenda item, however.
> Still, it is important to understand problems in the process and talk about fixing them
> It might, but if attendance at a meeting is so limited, don't expect much to come out of it.
> 
> Anyway, I don't see any prospect of changing the no-at-91 decision so let's just consider Honolulu an undone deal.
> 
> > (Not planning to attend, so my opinion doesn't count much either way on the Honolulu 
> > question).
> 
> I'm not planning to attend so my opinion doesn't count much.
> Marc isn't planning to attend so his opinion doesn't count much
> Spencer isn't planning to attend so his opinion doesn't count much :-)
> I think the real issue is how we should handle the decision about deciding to meet and I think all members of the working group who have an opinion should express it and have their opinion listened to seriously.
> 
> I have a problem with the decision-based-on-proposed-agenda model which turns into a decision-made-at-the-last-minute model.  If we can't go back to the meet-by-default model, which I think is desirable, we have to have some meetings at least, where an early commitment to have a meeting is made in advance.  If people know there will be a meeting and there is an expectation that most people will attend, people will find  nfsv4-related things to talk about.
> 
> Overall, I think having working group meetings has been helpful and that we should have them whenever there is sufficient working group interest.  If Spencer had polled working group members and found no interest in meeting in Honolulu, I would have had no problem with that.
> 
> I think we need a clear statement by Spencer that we will meet at IETF 92 in Dallas. Honolulu is nicer but at least it's not Florida.  
> 
> I'm not in a position now to commit to attend the meeting but I think a useful agenda item would consider the question you raised about how the process is helping or hurting progress.   That's the kind of thing we should be talking about if there are no contentious open issues about specs being developed.
> 
> On Fri, Sep 26, 2014 at 5:10 PM, J. Bruce Fields <[email-masked]> wrote:

---

From: David Noveck <[email-masked]>
Date: Mon, 29 Sep 2014 10:37:56 -0400

I think we're in agreement about the direction the working group needs to
move.   However, I don't see some of the obstacles to going forward that
you seem to.

> Me to, hence my position advocating a more modular and extensible
protocol that allows > add-on features to be added, discovered,

In fact. NFSv4 is already such a protocol.  It is designed to allow
optional features to be added (and discovered by seeing if NOTSUPP is
returned or not).  The only big problem is some versioning rules that have
 been interpreted as requiring us to batch features together.  It may be
time for the working group to step through the open door (or it may be time
to do that at IETF92 in Dallas).

> and version-negotiated dynamically on top of the base protocol.

I don't see that there is any need for negotiation here.  What I see
happening is the server saying what features it supports and the client
deciding to use them or not.    If the client doesn't like that set of
features, it can try using a different server but "negotiation" is not
really happening and using that word makes it seem that this is a more
difficult issue than it in fact is.  Real negotiation is a difficult
problem and we just need optional features and feature discovery, which are
things already in NFSv4.

> I believe that specifying these protocol features (that may include, e.g.
 data structure
> definitions, operations,and new attributes, flags, or options to existing
operations)

These are precisely the things that can be added in normal (i.e. not like
4.1) minor versions.  The protocol already has the wherewithal to have such
optional features added.  Tom provided the only missing piece by allowing
new switch cases or flags to be added to existing operations in v4.2. and
beyond.

> could be done rapidly with relatively little marginal effort - therefore
shortening the
> innovation turnaround.

The effort depends on the size of the feature.  Small features could be
done quite quickly while larger features could still take up considerable
time.   The major difficulty we have had with large features has been
assigning them to a specific minor version and then having them hold up
other features that are not so big.

Let me try to make this all more concrete by offering two proposals:

   - A proposal for a last-minute addition to the v4.2 spec to enable
   extensions within v4.2.  This is a straw-man proposal which I expect to be
   shot down, but it will show the wg what is possible, if we think this is a
   critical problem that must be resolved ASAP.
   - A proposal that we produce a v4.3 spec which consists of material to
   enable and further clarify the process of doing further incremental
   additions *and nothing else *.  The goal would be to get such a spec to
   WGLC in one year, i.e by 11/2015 (IETF 94?).  Development of individual
   features could proceed in parallel.

On Mon, Sep 29, 2014 at 2:14 AM, Benny Halevy <[email-masked]>
wrote:

> and new attributes, flags, or options to existing operations) could be
> done rapidly with relatively little marginal
>> I think the real issue is how we should handle the decision about
>> deciding to meet and I think all members of the working group who have an
>> opinion should express it and have their opinion listened to seriously.
>>

---

From: "J. Bruce Fields" <[email-masked]>
Date: Mon, 29 Sep 2014 10:51:46 -0400

>    features could proceed in parallel.

I've got no passionate objection, but absent an example it feels a bit
like, um, meta-feature-creep?

Is there some specific feature that, say, we *could* deliver to users in
2015, but won't be able to because of the batching requirements?

--b.

---

From: Chuck Lever <[email-masked]>
Date: Mon, 29 Sep 2014 11:00:58 -0400

On Sep 29, 2014, at 10:37 AM, David Noveck <[email-masked]> wrote:

> 	• A proposal for a last-minute addition to the v4.2 spec to enable extensions within v4.2.  This is a straw-man proposal which I expect to be shot down, but it will show the wg what is possible, if we think this is a critical problem that must be resolved ASAP.
> 	• A proposal that we produce a v4.3 spec which consists of material to enable and further clarify the process of doing further incremental additions and nothing else .  The goal would be to get such a spec to WGLC in one year, i.e by 11/2015 (IETF 94?).  Development of individual features could proceed in parallel.

Oracle would like to see these proposals move forward.

--
Chuck Lever
chuck[dot]lever[at]oracle[dot]com

---

From: Tom Haynes <[email-masked]>
Date: Mon, 29 Sep 2014 11:16:01 -0400

On Sep 29, 2014, at 10:37 AM, David Noveck <[email-masked]> wrote:

> A proposal for a last-minute addition to the v4.2 spec to enable extensions within v4.2.  This is a straw-man proposal which I expect to be shot down, but it will show the wg what is possible, if we think this is a critical problem that must be resolved ASAP.

You have 3 pages in the document. :-)

I.e., one of the goals is to keep the spec less than 100 pages.

> A proposal that we produce a v4.3 spec which consists of material to enable and further clarify the process of doing further incremental additions and nothing else .  The goal would be to get such a spec to WGLC in one year, i.e by 11/2015 (IETF 94?).  Development of individual features could proceed in parallel.  

Why does this have to be NFSv4.3?

I’d love to see us get away from monolithic draft proposals. Small and concise drafts are easier to get through the process. And there is no need to have them tied to a given release.

---

From: Marc Eshel <[email-masked]>
Date: Mon, 29 Sep 2014 08:17:43 -0700

"nfsv4" <[email-masked]> wrote on 09/29/2014 08:00:58 AM:

> From: Chuck Lever <[email-masked]>
> To: David Noveck <[email-masked]>, 
> Cc: "J. Bruce Fields" <[email-masked]>, "[email-masked]" 
> <[email-masked]>
> Date: 09/29/2014 08:02 AM
> Subject: Re: [nfsv4] No WG meeting for IETF 91
> >    ? A proposal for a last-minute addition to the v4.2 spec to 
> enable extensions within v4.2.  This is a straw-man proposal which I
> expect to be shot down, but it will show the wg what is possible, if
> we think this is a critical problem that must be resolved ASAP.
> >    ? A proposal that we produce a v4.3 spec which consists of 
> material to enable and further clarify the process of doing further 
> incremental additions and nothing else .  The goal would be to get 
> such a spec to WGLC in one year, i.e by 11/2015 (IETF 94?). 
> Development of individual features could proceed in parallel.
> 

+ IBM

---

From: Marc Eshel <[email-masked]>
Date: Mon, 29 Sep 2014 08:17:51 -0700

"nfsv4" <[email-masked]> wrote on 09/29/2014 07:51:46 AM:

> From: "J. Bruce Fields" <[email-masked]>
> Cc: "[email-masked]" <[email-masked]>
> Date: 09/29/2014 07:52 AM

Yes, xattr.

---

From: "J. Bruce Fields" <[email-masked]>
Date: Mon, 29 Sep 2014 11:50:33 -0400

> > 2015, but won't be able to because of the batching requirements?

Apologies, remind me of the status: you have a draft

	http://datatracker.ietf.org/doc/draft-naik-nfsv4-xattrs/

but not yet code that's ready to submit, is that right?

Who else was interested?  Is there enough consensus for some kind of
xattr's that it'd be worth adopting as a test case?

If it were completely up to you, and if you were doing all the work,
when do you think you'd have code in user's hands?

As far as I can tell, it doesn't depend on any 4.2 features, introduces
nothing mandatory, doesn't require that anything else be deprecated.

We don't want to add it to any existing document for fear that document
will never make progress, so it'd go in a separate document.

But as long as we exercise some minimal caution with assigned op,
attribute, and other numbers, there'd be no interoperability problems if
implementations introduced it now with whatever minor version is
convenient, right?

--b.

---

From: Tom Haynes <[email-masked]>
Date: Mon, 29 Sep 2014 11:50:37 -0400

On Sep 29, 2014, at 11:17 AM, Marc Eshel <[email-masked]> wrote:

> <Mail Attachment.gif> 

I thought we still hadn’t accepted xattr as something we were going to pursue?

I.e., I don’t want us to rush them in just to prove it as an example.

---

From: Marc Eshel <[email-masked]>
Date: Mon, 29 Sep 2014 16:50:29 -0700

Tom Haynes <[email-masked]> wrote on 09/29/2014 08:50:37 
AM:

> From: Tom Haynes <[email-masked]>
> To: Marc Eshel/Almaden/IBM@IBMUS, 
> Cc: "J. Bruce Fields" <[email-masked]>, nfsv4 <nfsv4-
> [email-masked]>, "[email-masked]" <[email-masked]>
> Date: 09/29/2014 08:50 AM
> > > returned or not).  The only big problem is some versioning rulesthat 

have
> > > These are precisely the things that can be added in normal (i.e. not 

like
> > > > could be done rapidly with relatively little marginal effort 
-therefore
> > > shortening the
> > > > innovation turnaround.
> > > 
> > > The effort depends on the size of the feature.  Small features could 

be
> > > assigning them to a specific minor version and then having them hold 

up
> > >    additions *and nothing else *.  The goal would be to get sucha 
spec to

> 
> I thought we still hadn?t accepted xattr as something we were going to 
pursue?

I am not sure why not, I did not hear any objection after presenting it 3 
times, other than some comments on how to do it right.
I think that this is one problem of our model where we don't start the 
next train before the last one is done, and I think we should work in 
parallel as was suggested. And if we take the suggestion of independent 
feature I think xattr will be a good example since it is self contained.  
> 
> I.e., I don?t want us to rush them in just to prove it as an example.

---

From: Marc Eshel <[email-masked]>
Date: Mon, 29 Sep 2014 16:50:29 -0700

"J. Bruce Fields" <[email-masked]> wrote on 09/29/2014 08:50:33 AM:

> Cc: David Noveck <[email-masked]>, "[email-masked]" 
> <[email-masked]>, nfsv4 <[email-masked]>

We were just waiting to see that the interface is acceptable before 
staring to code.

> xattr's that it'd be worth adopting as a test case?

I think that many people are interested and more importantly customers 
are.
 
> when do you think you'd have code in user's hands?

I can do the server side with Ganesha in a couple of weeks but I will need 
help on the client side.

> nothing mandatory, doesn't require that anything else be deprecated.

Right.

> will never make progress, so it'd go in a separate document.

Sure if we all agree on this new model.
> implementations introduced it now with whatever minor version is

Not sure, we need to agree on how we add those new independent features.

---

From: Thomas Haynes <[email-masked]>
Date: Mon, 29 Sep 2014 20:51:00 -0400

On Sep 29, 2014, at 7:50 PM, Marc Eshel <[email-masked]> wrote:

> 
> Tom Haynes <[email-masked]> wrote on 09/29/2014 08:50:37 AM:
> 
> > > > returned or not).  The only big problem is some versioning rulesthat have
> > > > > could be done rapidly with relatively little marginal effort -therefore
> > > > shortening the
> > > > > innovation turnaround.
> > > > 
> > > >    additions *and nothing else *.  The goal would be to get sucha spec to
> I am not sure why not, I did not hear any objection after presenting it 3 times, other than some comments on how to do it right. 

I have consistently asked for the use cases, i.e., why do we want to do it other than it is available?

I have heard others ask for that as well.

Your current draft details uses of current xattr implementations, but it does not motivate why we want
to take this into NFS nor what are the requirements.

As I've pointed out in the past, we had a problem getting Labeled NFS going until we provide a requirements
document and use cases for labels over the wire. The 3-4 cases (most notably seVirt for selinux) really
allowed us to sell the need, even though we ended up removing them from the final requirements document.

The other thing missing from your document is how different clients (and by abstraction the applications which would
use xattrs) are going to be able to interoperate with the provided xattrs.

Besides my earlier question on client max size being larger than the size of all attributes for a file, you can explore issues with character sets (i18n/case sensitivity/etc) in both keys and values, which of the four namespaces are supported (an earlier draft had a requirement, it is gone now), etc.

I know the draft states:

   Future versions of this document or other related IETF documents may
   define specific values for xattr key names, or mechanisms for
   encoding namespace in xattrname4. 
But I was pretty sure there were security implications on using namespaces other than "user".

---

From: David Noveck <[email-masked]>
Date: Tue, 30 Sep 2014 09:28:55 -0400

> you can explore issues with character sets (i18n/case sensitivity/etc) in
both keys and values,

One can, but as a former sufferer from IETF-I18n Dysphoria (not in the
DSM), my advice is to try to do as little exploration of this area as you
can get away with.  Specifically,

   - stress that values are opaque data, like user file data and symlink
   contents and thus are not subject to internationalization-related
   processing within the scope of the NFSv4 client and server.  Thus they are
   out of scope in the context of protocol definitions for NFSv4.2 or
   extensions thereof.
   - with regard to i18n issues for the keys, the simplest thing is to
   state that these will be governed by the same rules as apply to filenames
   in NFSv4.2.  Since v4.2 makes no change from v4.1 this means that the rules
   in RFC5661 apply.  Those rules are clear, have been approved by the IESG,
   have never been implemented and never will be implemented,  but that's
   someone else's problem.
   - with regard to case sensitivity of keys, state they will follow the
   case-sensitivity/case-preservation attributes of the current filesystem,
   with processing as defined in RFC5661.  Make the issue of dotted-capital-i
   in Turkish and Azeri someone else's problem.

On Mon, Sep 29, 2014 at 8:51 PM, Thomas Haynes <
[email-masked]> wrote:

> The other thing missing from your document is how different clients (and
> by abstraction the applications which would
> Besides my earlier question on client max size being larger than the size
> of all attributes for a file, you can explore issues with character sets
> (i18n/case sensitivity/etc) in both keys and values, which of the four
> namespaces are supported (an earlier draft had a requirement, it is gone
> now), etc.
>
> I know the draft states:
>

---

From: Spencer Shepler <[email-masked]>
Date: Tue, 30 Sep 2014 16:22:37 +0000

From: nfsv4 [mailto:[email-masked]] On Behalf Of Thomas Haynes
Sent: Monday, September 29, 2014 5:51 PM
To: Marc Eshel
Cc: J. Bruce Fields; [email-masked]; nfsv4
Subject: Re: [nfsv4] No WG meeting for IETF 91

On Sep 29, 2014, at 7:50 PM, Marc Eshel <[email-masked]<mailto:[email-masked]>> wrote:

Tom Haynes <[email-masked]<mailto:[email-masked]>> wrote on 09/29/2014 08:50:37 AM:

> From: Tom Haynes <[email-masked]<mailto:[email-masked]>>
> Cc: "J. Bruce Fields" <[email-masked]<mailto:[email-masked]>>, nfsv4 <nfsv4-
> [email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
> On Sep 29, 2014, at 11:17 AM, Marc Eshel <[email-masked]<mailto:[email-masked]>> wrote:
>
> <Mail Attachment.gif>
>
> "nfsv4" <[email-masked]<mailto:[email-masked]>> wrote on 09/29/2014 07:51:46 AM:
>
> > From: "J. Bruce Fields" <[email-masked]<mailto:[email-masked]>>
> > To: David Noveck <[email-masked]<mailto:[email-masked]>>,
> > Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
> > Sent by: "nfsv4" <[email-masked]<mailto:[email-masked]>>
> >

>
> I thought we still hadn't accepted xattr as something we were going to pursue?

[Spencer]

Tom's request for use cases, etc. is reasonable - it will provide the appropriate motivation and help with bringing the work in as a full WG item.

Spencer