Re: [alto] Barry Leiba's No Objection on draft-ietf-alto-incr-update-sse-20: (with COMMENT)

[Barry Leiba <[e-mail]>]

Thanks, RIchard, for the quick response and for addressing my comments.

Barry

On Wed, Mar 11, 2020 at 4:36 PM Y. Richard Yang <[e-mail]> wrote:
>
> Dear Barry,
>
> Thanks for the review. Please see inline.
>
> On Wed, Mar 11, 2020 at 12:04 AM Barry Leiba via Datatracker <[e-mail]> wrote:
>>
>> Barry Leiba has entered the following ballot position for
>> draft-ietf-alto-incr-update-sse-20: No Objection
>>
>> 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-alto-incr-update-sse/
>>
>>
>>
>> ----------------------------------------------------------------------
>> COMMENT:
>> ----------------------------------------------------------------------
>>
>> Just some very minor things here:
>>
>> Please use the new BCP 14 boilerplate and add a normative reference to RFC 8174.
>>
>
> I am using a standard .xml file, and when I compare the xml2rfc output with the recent RFCs (e.g., RFC 8710, standard track), I do see the difference. Thanks for catching it and we will fix.
>
>>
>> — Section 2 —
>> It’s a small thing, but in the first paragraph is it really useful to list the
>> terms, only to have each one defined right below?  My eye can instead run down
>> the paragraphs and catch the list of terms that way.
>>
>
> The list in the paragraph could serve as a "checksum", but it is indeed quite close by and removing redundancy is a better principle than "checksum". We will remove.
>
>
>>
>> — Section 8 —
>> Just a note that I did not carefully review the examples.
>>
>
> OK.
>
>>
>> — Section 12 —
>> Please add “Fragment identifier considerations” to the templates, as required
>> by RFC 6838.  It would also not be a bad idea to separate the two templates
>> with whitespace or a text paragraph, for readability.
>>
>
> Good suggestion. We will add Fragment identifier considerations” to the templates; add RFC 6838 in the Section (RFC 6838 is already a normative reference, but we will add a sentence to refer to it in Sec. 12). Yes we will add whitespace for better readability.
>
> Thanks again!
>
> Richard
>
>