Subject: Re: [Last-Call] [Gen-art] Genart last call review of draft-ietf-nfsv4-rfc5661sesqui-msns-03

From: David Noveck <[email-masked]>
Date: Thu, 2 Jan 2020 10:29:24 -0500

On Wed, Dec 18, 2019 at 5:53 PM Vijay Gurbani <[email-masked]>
wrote:

> All: This email serves as the second half of the review of
> draft-ietf-nsfv4-rfc5661sesqui-msns-03.
>
> I reviewed pages 297 to the end of the document, mostly for editorial and
> similar comments from a generalist point of view.
>
> The disposition remains the same as before ("Ready with Nits").  In
> addition to the nits I outlined in my previous email (reproduced below),
> here is one additional one:
>
> 1/ S18.51.1: What is the value of bracketing the code with <CODE BEGINS>
> ... <CODE ENDS> in this, and the next section?  Clearly, you have code in
> the previous section, and later sections, without such bracketing.
> Uniformity dictates that the code in these two sections be given the same
> treatment as the code in previous sections.  If, on the other hand, there
> is some significance to such bracketing, it may be good to comment on such
> a significance in S 18.51.1.
>

It's a mistake.  Will delete.

>
> Thanks,
>
> - vijay
>
> On Tue, Dec 17, 2019 at 6:17 PM Vijay Gurbani via Datatracker <
> [email-masked]> wrote:
>
>> Reviewer: Vijay Gurbani
>> Review result: Ready with Nits
>>
>> I am the assigned Gen-ART reviewer for this draft. The General Area
>> Review Team (Gen-ART) reviews all IETF documents being processed
>> by the IESG for the IETF Chair.  Please treat these comments just
>> like any other last call comments.
>>
>> For more information, please see the FAQ at
>>
>> <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.
>>
>> Document: draft-ietf-nfsv4-rfc5661sesqui-msns-??
>> Reviewer: Vijay K. Gurbani
>> Review Date: 2019-12-17
>> IETF LC End Date: 2019-11-25
>> IESG Telechat date: 2019-12-19
>>
>> I have reviewed about 1/2 of the I-D, up to Section 12 (page 297).  I will
>> review the remaining 1/2 before the telchat, but I suspect that given my
>> very
>> high level overview of the draft, my disposition will not change.
>>
>> Summary:  This draft is ready for publication as a Proposed Standard.  In
>> the
>> portion of the draft I reviewed, there are some minor nits that can
>> easily be
>> fixed.
>>
>> Major issues: 0
>>
>> Minor issues: 0
>>
>> Nits/editorial comments: 4 ("Sn" means Section n):
>> 1/ Appendix A: s/No correesponding explanation/No corresponding
>> explanation/
>> 2/ S1: s/authoritative complete/authoritatively complete/
>> 3/ S1.7 (page 12): "associable" or "associated to"
>> 4/ There are many long lines that go beyond 80 characters, see S1.9, the
>> bullet
>> that starts with “o  Open files can be …”,   Table 1, S4.2.1, etc.
>>
>> Thanks,
>>
>> - vijay
>>
>>
>> _______________________________________________
>> Gen-art mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/gen-art
>>
>

---

From: David Noveck <[email-masked]>
Date: Thu, 2 Jan 2020 10:29:45 -0500

On Tue, Dec 17, 2019 at 7:17 PM Vijay Gurbani via Datatracker <
[email-masked]> wrote:

> portion of the draft I reviewed, there are some minor nits that can easily
> be
> fixed.
>
> Major issues: 0
>
> Minor issues: 0
>

Fixed.

I went with "authoritative and complete"

Went with "can be associated with".

> that starts with “o  Open files can be …”,

I don't see sny long lines here, either in the .txt or .xml.

>  Table 1,

Here the .txt is OK but the .xml has long line.   WIll clean up  to make
future
editing of the .xml easier.

> S4.2.1, etc.

I don't see sny long lines here, either in the .txt or .xml.

---

From: Vijay Gurbani <[email-masked]>
Date: Thu, 2 Jan 2020 14:10:40 -0600

Dear David: Thanks for addressing my comments.  Regarding not being able to
see long lines as I report below, please see the attached screenshot
corresponding to the "htmlized" version of the draft.
Cheers,
- vijay

---

From: David Noveck <[email-masked]>
Date: Thu, 2 Jan 2020 17:28:35 -0500

On Thu, Jan 2, 2020 at 3:09 PM Vijay Gurbani <[email-masked]>
wrote:

> Dear David: Thanks for addressing my comments.  Regarding not being able
> to see long lines as I report below, please see the attached screenshot
> I see it now.   The same thing happens in the  "htmlized" version of
rfc5661.   This is due to a very long title within a reference to an open
group spec with xml2rfc deciding to reproduce this title in full in the
link and doing so without line folding.   I feel both are bugs but I'm sure
the second is a bug.  I was able to get around this by adding "abbrev='Open
Group'" to the <title> element.   The result looks reasonable to me but the
rfc editor might decide it is wrong in some way.

---

From: Vijay Gurbani <[email-masked]>
Date: Thu, 2 Jan 2020 16:33:38 -0600

Very well.  Thank you for attending to this.
Cheers,
- vijay