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

[David Noveck <[e-mail]>]

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.
>
>
>