Subject: [nfsv4] Ben Campbell's Abstain on draft-ietf-nfsv4-mv1-msns-update-04: (with COMMENT)

From: Datatracker on behalf of Ben Campbell <[email-masked]>
Date: Tue, 05 Mar 2019 15:33:11 -0800

Ben Campbell has entered the following ballot position for
draft-ietf-nfsv4-mv1-msns-update-04: Abstain

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-nfsv4-mv1-msns-update/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thanks for the huge amount of work in this draft, but I cannot recommend
publishing it in it's current form. I am balloting "ABSTAIN" rather than
"DISCUSS", so that I do not get in the way of publication if the rest of the
IESG thinks it's fine as is. I apologize for not doing a more technical review,
but I think the structural issues need to be addressed first.

I once spent several weeks over a summer in high school applying page updates
to a shelf full of US Tax Code binders in a CPAs office. The IRS, (or whoever
published the code) would send out boxes of new page-sets, each labeled for
which original pages it would replace.  When we were done in the CPA office, we
had a coherent set of documents, at least to the degree you can apply words
like "coherent" to tax codes.

This draft does something akin to that, except that we don't end up with a
coherent document as a result. If the RFC Editor applied patches from RFCs that
 "UPDATE" other RFCs to render final text,  things would be different. But that
doesn't happen with RFCs.  That being said, I don't object to RFC updates in
general, as long as those updates are simple and fairly self-contained. But
this draft is over 100 pages of intricate updates, reorganizations, and
explanatory text. This will make life very hard for readers that were not
involved in the standards process.

I think the right approach for an update of this complexity is to just do a
5661bis draft, and use this one as an input to that. Such a bis draft could be
something as simple as applying the changes in this draft (and maybe
trunking-update)  and publishing the result.

---

From: David Noveck <[email-masked]>
Date: Thu, 7 Mar 2019 06:23:54 -0500

It couldn't be quite that simple since a bis document would need to address
a number of other things:

   - Replace the internationalization chapter so it coresponds to that of
RFC7530 and existing NFSv4.1 implementations.   The one in rfc5661 is
flat-out wrong and, as with the one in rfc3530, people never really read it.
    - There are a significant number of erratta accumulated for RFC5661
which would have to be addressed in a bis document.

In any case, I and many people within the group felt that, having lived
through the rfc3530bis experience, that "simple" was unlikely to be an
appropriate adjective to apply to the publication of a bis document for a
large document such as RFC5661.

Another option, short of a full bis, that I considered was simply to apply
the changes to Section eleven in
the document under review and include that full replacement section instead
of the detailed changes that are currently there.   The reason I didn't
take that approach is that, while that document might be much easier for a
NFSv4.1 neophyte to read, it would more difficult more those in the working
group (many of whom are implementers) to assimilate and review.  People
would be left to diff the two section 11's and figure out what changed.

I understand the issues that this approach raises for an important class of
readers but I feel that, practically speaking, the majority who would have
to act on this work are implementers who are already familiar with the
existing Section 11, with a large fraction of those involved in the work of
the working group.   Clearly the needs of others, with less familiarity
with NFSv4.1 would have to be met by a bis document, which I have started
on.

I know many people will not agree but I feel the most expedient path
forward is to address the technical and clarity issues that have been
raised and publish the document in essentially its current form, knowing
that the appropriate audience is not going to include NFSv4.1 neophytes.
 Some implementation work has started and publication would allow other
implementation work to proceed.   Then, when this work is included in a bis
document, we would have the benefit of that additional implementation work
and any possible  need for clarification or corrections that the
implementation work exposed.

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Thu, 7 Mar 2019 06:33:05 -0600

For the IESG ...

It's also worth noting that multiple ADs said "not standing in the way of
publication" in their Abstain ballots, but this is a standards-track draft
that requires 10 Yes or No Objection ballots for approval.

This is different from https://datatracker.ietf.org/doc/rfc8540/, which was
also an Abstain magnet, but was Informational, requiring one Yes and no
Discusses.

So, if the next IESG intends to block standards-track documents of this
style by collective action, it would be awesome to tell the community that,
rather than reveal it to one working group at a time during IESG Evaluation.

Spencer (D)

On Thu, Mar 7, 2019, 05:24 David Noveck <[email-masked]> wrote:

> It couldn't be quite that simple since a bis document would need to
> address a number of other things:
>
> the document under review and include that full replacement section
> instead of the detailed changes that are currently there.   The reason I
> didn't take that approach is that, while that document might be much easier
> for a NFSv4.1 neophyte to read, it would more difficult more those in the
> working group (many of whom are implementers) to assimilate and review.
> People would be left to diff the two section 11's and figure out what
> changed.
>
> I understand the issues that this approach raises for an important class
> of readers but I feel that, practically speaking, the majority who would
> have to act on this work are implementers who are already familiar with the

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Thu, 7 Mar 2019 12:24:35 -0600

Dear NFSv4,

After today's telechat, this draft is in AD follow-up, and the AD I'll be
handing off to at IETF 104 will be Magnus Westerlund.

My suggestion at this point is to wait until Magnus and I can discuss where
the IESG ended up, before the working group spends a lot of time trying to
figure out where the IESG ended up. We most often talk on Mondays, so look
for a note from us early next week.

And thanks for your patience.

Spencer

On Thu, Mar 7, 2019 at 6:33 AM Spencer Dawkins at IETF <
[email-masked]> wrote:

> This is different from https://datatracker.ietf.org/doc/rfc8540/, which
> was also an Abstain magnet, but was Informational, requiring one Yes and no
> Discusses.
>
>> Another option, short of a full bis, that I considered was simply to
>> apply the changes to Section eleven in
>>> Please refer to
>>> https://www.ietf.org/iesg/statement/discuss-criteria.html

---

From: Ben Campbell <[email-masked]>
Date: Thu, 7 Mar 2019 17:38:23 -0600

Hi, thanks for the response. A few comments inline:

Thanks!

Ben.

> On Mar 7, 2019, at 5:23 AM, David Noveck <[email-masked]> wrote:
> 
> It couldn't be quite that simple since a bis document would need to address a number of other things:
> 
>    - Replace the internationalization chapter so it coresponds to that of RFC7530 and existing NFSv4.1 implementations.   The one in rfc5661 is flat-out wrong and, as with the one in rfc3530, people never really read it.
>     - There are a significant number of erratta accumulated for RFC5661 which would have to be addressed in a bis document.
> 
> In any case, I and many people within the group felt that, having lived through the rfc3530bis experience, that "simple" was unlikely to be an appropriate adjective to apply to the publication of a bis document for a large document such as RFC5661.

On today’s telechat, multiple people suggested they could probably accept a bis draft that did not solve all known (or even all serious) problems, as long as there was text point that the material issues that remained unfixed. I think that was said in the abstract, so I can’t speak for how it would impact this particular document.

> 
> Another option, short of a full bis, that I considered was simply to apply the changes to Section eleven in
> the document under review and include that full replacement section instead of the detailed changes that are currently there.   The reason I didn't take that approach is that, while that document might be much easier for a NFSv4.1 neophyte to read, it would more difficult more those in the working group (many of whom are implementers) to assimilate and review.  People would be left to diff the two section 11's and figure out what changed.

While I would have to see text to really assess things, I think this would be better than the current state. At least, it would be much more likely that two different people would perceive the updated draft the same way.

As far as diffs are concerned, that’s commonly the case for any bis draft as well. (I regularly request people avoid non-essential changes to help keep the diffs useful.) The better bis drafts include sections that describe the material changes.

> 
> I understand the issues that this approach raises for an important class of readers but I feel that, practically speaking, the majority who would have to act on this work are implementers who are already familiar with the existing Section 11, with a large fraction of those involved in the work of the working group.   Clearly the needs of others, with less familiarity with NFSv4.1 would have to be met by a bis document, which I have started on.

I think it’s important that open standards be accessible by people new to a protocol. I am skeptical that people who are already familiar with the protocol would have that much trouble figuring out the changes, especially if the bis draft describes the material changes.

> 
> I know many people will not agree but I feel the most expedient path forward is to address the technical and clarity issues that have been raised and publish the document in essentially its current form, knowing that the appropriate audience is not going to include NFSv4.1 neophytes.   Some implementation work has started and publication would allow other implementation work to proceed.   Then, when this work is included in a bis document, we would have the benefit of that additional implementation work and any possible  need for clarification or corrections that the implementation work exposed.
> 
> On Tue, Mar 5, 2019 at 6:33 PM Datatracker on behalf of Ben Campbell <[email-masked] <mailto:[email-masked]>> wrote:
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html <https://www.ietf.org/iesg/statement/discuss-criteria.html>
> https://datatracker.ietf.org/doc/draft-ietf-nfsv4-mv1-msns-update/ <https://datatracker.ietf.org/doc/draft-ietf-nfsv4-mv1-msns-update/>
> 
> 
>