Re: [nfsv4] Benjamin Kaduk's Discuss on draft-ietf-nfsv4-mv1-msns-update-04: (with DISCUSS and COMMENT)

[David Noveck <[e-mail]>]

> IESG, so the new document is this :
> https://datatracker.ietf.org/doc/draft-ietf-nfsv4-rfc5661-msns-update/

> I have looked at this now a bit more in detail and have some comments. I
> am also looking at this document in the context of a proposal for a
> process update that could be applied in this type of case. NFSv4 WG you
> are very welcome to comment on what is proposed in this document
> https://datatracker.ietf.org/doc/draft-roach-bis-documents/ from your
> perspective.

>From my point of view, it should eliminate what had been the prime obtacle
to
presenting this document in the form of an rfc5661bis, the need to evalluate
a Security Considerations secton for that document in a way that would be
appropriate to a new Proposed Standard.

By providing the non-major updates previously poposed in the form of a bis
document, as the IESG has been requesting, I think we could avoid this
difficulty.

> I do note that with your update document the RFC diff is possible to use
> to find the changes, but gets quite cluttered up by the introduction and
> many pages of excluded chapters. See for yourself here:
>
https://tools.ietf.org/rfcdiff?url1=https://www.rfc-editor.org/rfc/rfc5661.txt&url2=https://www.ietf.org/id/draft-ietf-nfsv4-rfc5661-msns-update-00.txt
.
> I think an update according to this proposal with the full document
> would have a cleaner DIFF.

Agree that it woud.

There would no longer be pointless diffs reporting the deletion of the
excluded (unchanged) chapter.

With regard to the introductory/explanatory text, that would still be there
but it would no longer be perceived as clutter.  Instead it would be marked
in the diff as additions,

> To my understanding your document in a full form would meet the Basic
> Qualifications in 3.1 of the process proposal. Do the WG agree?

I agree. I think the best way to find out if the working group agrees is
for me
to produce a -01 along the lines suggested, adding back the deleted
sections,
have any necessary working group discussion, and then see if we can move
toward WGLC on the document.

> IESG, I do want to you to consider if you think this form of an update
> would be sufficient in this case. As you note it is still a long
> document of 130+ pages. We should arrive as soon as possible to an
> direction for this document.

I think I need to give the IESG fair warning that the document we are
talking about
would be much  longer than 13O oages, and in fact longer than rfc5661,
because of
the new explanatory sections and the material on transparent state
migration.

> Still some more detailed comments on the document.

> 1. The section headers. I do propose that all the "Update section" or
"New Section" text are removed.

I'm OK with doing that in -01 but I realize there might be pushback down
the line.

> 2. If it is desired to have inline reference to the corresponding
> section in RFC 5661 then I think one can add that as bracketed comment
> in the beginning of the body of the section.

OK.


On Wed, May 8, 2019 at 10:20 AM Magnus Westerlund <
[e-mail]> wrote:

> Editors, WG and IESG,
>
> IESG, so the new document is this :
> https://datatracker.ietf.org/doc/draft-ietf-nfsv4-rfc5661-msns-update/
>
> I have looked at this now a bit more in detail and have some comments. I
> am also looking at this document in the context of a proposal for a
> process update that could be applied in this type of case. NFSv4 WG you
> are very welcome to comment on what is proposed in this document
> https://datatracker.ietf.org/doc/draft-roach-bis-documents/ from your
> perspective.
>
> I do note that with your update document the RFC diff is possible to use
> to find the changes, but gets quite cluttered up by the introduction and
> many pages of excluded chapters. See for yourself here:
>
> https://tools.ietf.org/rfcdiff?url1=https://www.rfc-editor.org/rfc/rfc5661.txt&url2=https://www.ietf.org/id/draft-ietf-nfsv4-rfc5661-msns-update-00.txt
> .
> I think an update according to this proposal with the full document
> would have a cleaner DIFF.
>
> To my understanding your document in a full form would meet the Basic
> Qualifications in 3.1 of the process proposal. Do the WG agree?
>
> IESG, I do want to you to consider if you think this form of an update
> would be sufficient in this case. As you note it is still a long
> document of 130+ pages. We should arrive as soon as possible to an
> direction for this document.
>
> Still some more detailed comments on the document.
>
> 1. The section headers. I do propose that all the "Update section" or
> "New Section" text are removed.
>
> 2. If it is desired to have inline reference to the corresponding
> section in RFC 5661 then I think one can add that as bracketed comment
> in the beginning of the body of the section.
>
> I only read in detail until the end of Section 3.
>
> Cheers
>
> Magnus Westerlund
>
>
>
>
>
>
>