Subject: [nfsv4] NFSv4 Charter change proposal

From: Magnus Westerlund <[email-masked]>
Date: Mon, 6 Jul 2020 11:44:21 +0000

Hi,

I like to discuss the proposed charter change as written by David:

> I am now proposing replacing the second paragraph of the extensions section
> which now reads:
> 
> Similarly, associated ONC protocol components that have a versioning/
> extension framework can be incrementally extended, when necessary.
> 
> By the following three-paragraph replacement:
> 
> In dealing with needed extensions to areas that underlay NFSv4, the working
> group's role will depend on the specific area needing extension.  In the case
> of associated ONC protocol components, those that have a versioning/extension
> framework can be incrementally extended, when necessary.
> 
> In the case of  extensions needed to lower-layer transport facilities of
> particular importance to NFSv4, the working group will work with the
> responsible working group to make sure needed extensions are available. 
> 
> In cases in which there is no assigned working group,  the  Nfsv4 working
> group can, with coordination provided by the relevant Area Director(s), help
> by developing the necessary extension itself, as is being done in providing an
> extension to RDMAP, RFC5040/7306, for enhanced memory placement ("Push Mode").
> 
> 

So I am not a great fan of unspecific allowances. Especially when it comes cross
WG matters. Sorry if I am missing any context here, but if this is to enable a
mapping to QUIC. Then I think the WG and proponents for this can discuss a
individual draft until you think you understand the problem and what
requirements that puts on QUIC and if new functionality. Having that
understanding it is much clearer to determine how to best charter that work. 

I will note that the QUIC WG is kept on a short leash so far when it comes to
extensions. 

When it comes to the charter I am actually considering if we should do a
complete rewrite to a more focus charter that are more explicit on what 
set of work the WG is doing. 

I am happy to discuss this more on Thursday. 

Cheers

Magnus Westerlund 

----------------------------------------------------------------------
Networks, Ericsson Research
----------------------------------------------------------------------
Ericsson AB                 | Phone  +46 10 7148287
Torshamnsgatan 23           | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: [email-masked]
----------------------------------------------------------------------

---

From: David Noveck <[email-masked]>
Date: Tue, 7 Jul 2020 04:18:21 -0400

> I like to discuss the proposed charter change as written by David:

Just to provide the proper context, I'd like to state that the motivation
for this change is,  and has always been, to enable us to take part in the
work for Tom's push-mode draft.

> > framework can be incrementally extended, when necessary.

I thought that the existing paragraph, which dealt with extending
facilities for ONC, could be extended to deal with this situation.  It
appears, given the months that Tom has had to wait, it appears that I was
wrong 😞.

What I wanted to avoid was an unmotivated random statement saying
essentially, "By the way, the working group can also do Tom's
Push-mode draft". I wanted the charter to present a coherent area of
responsibility.  If that can be dispensed with, then we can cite the
specifics of Tom's proposal and go forward that way.

> > responsible working group to make sure needed extensions are available.

IIRC, this was inserted mainly to assure the IESG that we were not
intending to go poaching into other groups' work.  If there is something
specific about the wording that might confer undue license on the v4 wg,
I'm open to discussing changes to make this more limited.

> > extension to RDMAP, RFC5040/7306, for enhanced memory placement ("Push

So if there is something that provides the wg broad discretion, it is this,
which only deals with working groups which we depend on that don't exist,
only applies to RDDP.  I don't see how this is a real worry.

>
> So I am not a great fan of unspecific allowances.

So we gather, although it seems to me that this
significantly understates the matter.

> Especially when it comes cross
> WG matters.

You've made that clear but I want us to focus on how we can most
expeditiously enable Tom to proceed on the push-mode draft about which
there seems to be no debate as to the suitability of the v4 wg as a home.

> Sorry if I am missing any context here, but if this is to enable a
> mapping to QUIC.

I don't think it is.

> Then I think the WG and proponents for this can discuss a

I agree that such extensions would best be addressed in that way.

> Understood, but if that is the case, then that "short leash" would apply
to us, if we were to co-ordinate work with them, any such "short leash"
would apply to us as well.

> set of work the WG is doing.

I don't see the need for this as the current charter, not all that old, has
been satisfactory.  Is there some specific difficulty that would motivate a
rechartering at this point? I realize that it is not as tightly constrained
as you might prefer, but doing a complete rewrite now would be a
considerable effort and it is not clear who is available to drive such an
effort.  In particular, I'm busy enough balancing the demans of 5661bis and
my day job as it is.   I have no cycles available to deal with a charter
rewrite.  Is there anyone else who does?

GIven that this group deals with maintenance, a tightly constrained charter
could undercut the effectiveness of the group, since it is often hard to
know, in advance, what is broken.  This could result in broken things not
getting fixed in a timely fashion if any proposal to fix them needs to
involve a lengthy charter discussion.

We created the v4 extension mechanism to simplify the process of making
simple discrete v4 extensions.  The kind of charter you are considering
would undercut that by involving the IESG in such matters. I don't think
the working group or the IESG is prepared for that.

> The agenda is pretty full.   I can carve out five or ten minutes but there
is no time to resolve the major philosophical differences that appear to
exist.

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

---

From: Tom Talpey <[email-masked]>
Date: Tue, 7 Jul 2020 09:09:32 -0400

On 7/7/2020 4:18 AM, David Noveck wrote:
> 
> 
> On Mon, Jul 6, 2020 at 7:44 AM Magnus Westerlund 
> <magnus.westerlund=[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
>  ...

Just to confirm, no, there is no linkage at all to QUIC from Push Mode.
It is a straight-up RDMA extension, with no transport implication on
TCP, QUIC, or any other lower layer.

Tom.

---

From: "Black, David" <[email-masked]>
Date: Tue, 7 Jul 2020 16:22:44 +0000

Hi Magnus,

> So I am not a great fan of unspecific allowances. Especially when it comes cross WG
> matters.

Ok ... as Tom subsequently wrote:

Tom> Just to confirm, no, there is no linkage at all to QUIC from Push Mode.
Tom> It is a straight-up RDMA extension, with no transport implication on TCP, QUIC, or any other lower layer.

I understand the specific intent here is to have the NFSV4 WG take on responsibility for maintenance and extension of the RDMA protocols originally developed by the RDDP WG (RFCs 5040-5045, e.g., RDMAP, DDP and MPA) and subsequently maintained by the STORM WG (i.e., RFCs 6580, 6581 and 7306).  The draft that Tom is working on is akin to RFC 7306 - it's primarily a functional extension to RDMAP (RFC 5040), but also has some impacts on DDP (RFC 5041).

I'd suggest updating the charter with a paragraph that states that scope explicitly, e.g.:

	The NFSv4 working group is also responsible for maintenance and extension
	of the RDMA protocols originally developed by the now-concluded RDDP WG
	(RFCs 5040-5045, e.g., RDMAP, DDP and MPA) , whose maintenance and
	extension were previously handled by the now-concluded STORM WG.

The overall structural goal here is not to send that activity to TSVWG, as the relevant expertise is in the NFSV4 WG rather than in the TSVWG WG, and TSVWG has more than enough work to keep it busy ;-).

Thanks, --David

> -----Original Message-----
> From: nfsv4 <[email-masked]> On Behalf Of Magnus Westerlund
> Sent: Monday, July 6, 2020 7:44 AM
> To: [email-masked]
> Subject: [nfsv4] NFSv4 Charter change proposal
> 
> 
> [EXTERNAL EMAIL]
> 
> Hi,
> 
> > I am now proposing replacing the second paragraph of the extensions
> > section which now reads:
> >
> > In dealing with needed extensions to areas that underlay NFSv4, the
> > working group's role will depend on the specific area needing
> > extension.  In the case of associated ONC protocol components, those
> > that have a versioning/extension framework can be incrementally extended,
> when necessary.
> >
> > In the case of  extensions needed to lower-layer transport facilities
> > of particular importance to NFSv4, the working group will work with
> > the responsible working group to make sure needed extensions are available.
> >
> > In cases in which there is no assigned working group,  the  Nfsv4
> > working group can, with coordination provided by the relevant Area
> > Director(s), help by developing the necessary extension itself, as is
> > being done in providing an extension to RDMAP, RFC5040/7306, for enhanced
> memory placement ("Push Mode").
> >
> >
> 
> So I am not a great fan of unspecific allowances. Especially when it comes cross WG
> matters. Sorry if I am missing any context here, but if this is to enable a mapping to
> QUIC. Then I think the WG and proponents for this can discuss a individual draft
> until you think you understand the problem and what requirements that puts on
> QUIC and if new functionality. Having that understanding it is much clearer to
> determine how to best charter that work.
> 
> When it comes to the charter I am actually considering if we should do a complete
> rewrite to a more focus charter that are more explicit on what set of work the WG
> is doing.
>

---

From: David Noveck <[email-masked]>
Date: Tue, 7 Jul 2020 12:57:33 -0400

Works for me.

On Tue, Jul 7, 2020, 12:23 PM Black, David <[email-masked]> wrote:

> I understand the specific intent here is to have the NFSV4 WG take on
> responsibility for maintenance and extension of the RDMA protocols
> originally developed by the RDDP WG (RFCs 5040-5045, e.g., RDMAP, DDP and
> MPA) and subsequently maintained by the STORM WG (i.e., RFCs 6580, 6581 and
> 7306).  The draft that Tom is working on is akin to RFC 7306 - it's
> primarily a functional extension to RDMAP (RFC 5040), but also has some
> impacts on DDP (RFC 5041).
>
> The overall structural goal here is not to send that activity to TSVWG, as
> the relevant expertise is in the NFSV4 WG rather than in the TSVWG WG, and
> TSVWG has more than enough work to keep it busy ;-).
>
> Thanks, --David
>
> complete

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 8 Jul 2020 07:07:20 +0000

Thanks David,

I think your proposed text is a good start as that at least avoids the issue of
dragging cross WG into the charter and makes clear the WG's being the home for
RDMA maintenance and extension.

From my perspective I would prefer an additional statement for what extension 
actually are intended to be done. To my understanding that is a push mode. Can
we formulate that in one or a few sentences? 

Cheers

Magnus

On Tue, 2020-07-07 at 16:22 +0000, Black, David wrote:
> Tom> Just to confirm, no, there is no linkage at all to QUIC from Push Mode..
> responsibility for maintenance and extension of the RDMA protocols originally
> developed by the RDDP WG (RFCs 5040-5045, e.g., RDMAP, DDP and MPA) and
> subsequently maintained by the STORM WG (i.e., RFCs 6580, 6581 and 7306).  The
> draft that Tom is working on is akin to RFC 7306 - it's primarily a functional
> extension to RDMAP (RFC 5040), but also has some impacts on DDP (RFC 5041).
> 
> The overall structural goal here is not to send that activity to TSVWG, as the
> relevant expertise is in the NFSV4 WG rather than in the TSVWG WG, and TSVWG
> has more than enough work to keep it busy ;-).
> 
> Thanks, --David
> 
-- 
Cheers

Magnus Westerlund

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 8 Jul 2020 07:38:01 +0000

Hi David,

Please see inline. 

On Tue, 2020-07-07 at 04:18 -0400, David Noveck wrote:
> 
> 
> On Mon, Jul 6, 2020 at 7:44 AM Magnus Westerlund <
> magnus.westerlund=[email-masked]> wrote:
> > Hi,
> > 
> Just to provide the proper context, I'd like to state that the motivation for
> this change is,  and has always been, to enable us to take part in the work
> for Tom's push-mode draft.
> 
> > section
> > working
> I thought that the existing paragraph, which dealt with extending facilities
> for ONC, could be extended to deal with this situation.  It appears, given the
> months that Tom has had to wait, it appears that I was wrong 😞.

Sorry for not being sufficient clear. What I really desire is a descriptive
sentence or two of the actual work the wG planned to do. So describe PUSH mode
RDMA in a sentence or two.  

The clarification on RDMA maintenace that David Black proposed sets the context
for RDMA. 

I do hope that we will arrive on a charter extension that is agreeable during
the WG interim. I think with David Black's proposal this appears feasible. If we
succeed I can put this rechartering on next week's IESG Telechat. 

> 
> What I wanted to avoid was an unmotivated random statement saying essentially,
> "By the way, the working group can also do Tom's Push-mode draft". I wanted
> the charter to present a coherent area of responsibility.  If that can be
> dispensed with, then we can cite the specifics of Tom's proposal and go
> forward that way.

So describing the area of responsibility is fine. However, I do want the charter
to be explicit on extensions. Basically have the charter have a structure of. 

General responsibilty describing the areas of responsibility that is Foo and Bar

Specific work items in area Foo
 - Work#1 description 
 - Work#2 description

Specific work items in area Bar
 - Work #3 description

I think the issue is primarily how things are formulated not the actual content.
And lets just fix this extension for now. A rewrite will be for the future. 

However, let me give one aspect why I am pushing for more explicitness. The TSV
AD is unlikely to have particular deep insight to the storage area, which
definitely is true for me. Thus, have a charter that is clear on both scope and
what specific work items actually are. 

Being specific will help make it clear what focus and committed work the WG is
working on. It would help with the work planning and ensuring that the WG isn't
spreading itself to thin. 

Cheers

Magnus Westerlund

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 8 Jul 2020 07:58:30 +0000

> TCP, QUIC, or any other lower layer.

Thanks,

Sorry, I was obviously mixing up the proposals. 

So this is draft-talpey-rdma-commit or?
 
Cheers

Magnus Westerlund

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 8 Jul 2020 08:05:18 +0000

Hi,

Attached is a charter proposal that I think would resolve the RDMA Push
extension. Please go ahead and word smith.

Cheers

Magnus

---

From: Brian Pawlowski <[email-masked]>
Date: Wed, 8 Jul 2020 01:16:00 -0700

Seems reasonable to me - picks up David Black's clarifying wording we seem
to agree on, and gets specific on the RDMA focus at end.

Tom: Any wordsmithing on the RDMA paragraph at end?

---

From: Tom Talpey <[email-masked]>
Date: Wed, 8 Jul 2020 09:52:54 -0400

On 7/8/2020 3:58 AM, Magnus Westerlund wrote:
> So this is draft-talpey-rdma-commit

Yep. To be updated and republished shortly, once we decide the WG
applicability.

Tom.

> or?

---

From: Tom Talpey <[email-masked]>
Date: Wed, 8 Jul 2020 12:24:02 -0400

Looks good but Flush is the most important operation so I suggest
placing it first:

   The WG will extend RDMA to enhance the Memory Placement operations
   such as Flush, Atomic Write and Validation using Integrity Signatures.

As for schedule, I'd suggest March-ish (8 months).

Tom.

On 7/8/2020 4:16 AM, Brian Pawlowski wrote:
> Seems reasonable to me - picks up David Black's clarifying wording we 
> seem to agree on, and gets specific on the RDMA focus at end.
> 
> On Wed, Jul 8, 2020 at 1:05 AM Magnus Westerlund 
>     [email-masked] <mailto:[email-masked]>