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

[Spencer Dawkins at IETF <[e-mail]>]

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 <[e-mail]> 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.
>
> 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.
>
> On Tue, Mar 5, 2019 at 6:33 PM Datatracker on behalf of Ben Campbell <
> [e-mail]> wrote:
>
>> 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.
>>
>>
>>