Re: [Rum] Lars Eggert's No Objection on draft-ietf-rum-rue-09: (with COMMENT)

[Brian Rosen <[e-mail]>]

Thanks for the comments.  Please see inline.

> On Dec 16, 2021, at 9:29 AM, Lars Eggert via Datatracker <[e-mail]> wrote:
> 
> Lars Eggert has entered the following ballot position for
> draft-ietf-rum-rue-09: 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/blog/handling-iesg-ballot-positions/
> for more information about how to handle DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-rum-rue/
> 
> 
> 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> Document still refers to the "Simplified BSD License", which was corrected in
> the TLP on September 21, 2021. It should instead refer to the "Revised BSD
> License”.
Hmmm.  That would come from the ipr clause of the rfc statement, which is ipr=“trust200902”
Maybe that will fix itself in the next version

> 
> No reference entries found for: [RFC6655].
Fixed.  Should have been 6665

> 
> Found terminology that should be reviewed for inclusivity; see
> https://www.rfc-editor.org/part2/#inclusive_language for background and more
> guidance:
> 
> * Term "traditional"; alternatives might be "classic", "classical",
>   "common", "conventional", "customary", "fixed", "habitual", "historic",
>   "long-established", "popular", "prescribed", "regular", "rooted",
>   "time-honored", "universal", "widely used", "widespread".
> 
> Thanks to Matt Joras for their General Area Review Team (Gen-ART) review
> (https://mailarchive.ietf.org/arch/msg/gen-art/v7czr4R50Y-rupMcCDcnBbAtIJs).
> 
> -------------------------------------------------------------------------------
> All comments below are about very minor potential issues that you may choose to
> address in some way - or ignore - as you see fit. Some were flagged by
> automated tools (via https://github.com/larseggert/ietf-reviewtool), so there
> will likely be some false positives. There is no need to let me know what you
> did with these suggestions.
> 
> Section 6.2. , paragraph 3, nit:
> -    [RFC8865], using the WebRTC data chanel.  RFC 8865 also has some
> +    [RFC8865], using the WebRTC data channel.  RFC 8865 also has some
> +                                         +
> 
> Section 7.2. , paragraph 2, nit:
> -    xCard [RFC6351] xml format.
> -                    ^^^
> +    xCard [RFC6351] XML format.
> +                    ^^^
> 
> Section 8. , paragraph 2, nit:
> -    provider supports video mail at least one of these mechansism MUST be
> -                                                             -
> +    provider supports video mail at least one of these mechanisms MUST be
> +                                                                +
> 
> Section 9.1. , paragraph 6, nit:
> -    The V1.0 provider list is a json object consisting of an array where
> -                                ^^^^
> +    The V1.0 provider list is a JSON object consisting of an array where
> +                                ^^^^
> 
> Section 9.2. , paragraph 3, nit:
> -    "redexample.net", the provider configuration would be obtained from
> +    "red.example.net", the provider configuration would be obtained from
> +        +
> 
> Section 9.2. , paragraph 6, nit:
> -    The data returned is a json object consisting of an array of key/
> -                           ^^^^
> +    The data returned is a JSON object consisting of an array of key/
> +                           ^^^^
> 
> Section 9.2.1. , paragraph 2, nit:
> -    *  signup: (OPTIONAL) an array of json objects consisting of:
> -                                      ^^^^
> +    *  signup: (OPTIONAL) an array of JSON objects consisting of:
> +                                      ^^^^
> 
> Section 9.2.1. , paragraph 5, nit:
> -    *  dialAround: an array of json objects consisting of:
> -                               ^^^^
> +    *  dialAround: an array of JSON objects consisting of:
> +                               ^^^^
> 
> Section 9.2.1. , paragraph 9, nit:
> -    *  helpDesk: (OPTIONAL) an array of json objects consisting of:
> -                                        ^^^^
> +    *  helpDesk: (OPTIONAL) an array of JSON objects consisting of:
> +                                        ^^^^
> 
> Section 9.3. , paragraph 2, nit:
> -    with OpenAPI 3.0 ([OpenApi]) descriptions in yaml form.
> -                                                 ^^^^
> +    with OpenAPI 3.0 ([OpenApi]) descriptions in YAML form.
> +                                                 ^^^^
> 
> Section 10.1. , paragraph 4, nit:
> -    *  list entry point: a string is used to compose the uri to the
> -                                                         ^^^
> +    *  list entry point: a string is used to compose the URI to the
> +                                                         ^^^
> 
> "Table of Contents", paragraph 2, nit:
>> . . . . . . . . . . . . 12 5.3. Mid Call Signaling . . . . . . . . . . . .
>>                                 ^^^^^^^^
> This word is normally spelled with a hyphen.
> 
> "Table of Contents", paragraph 2, nit:
>> . . . . . . . . . . . . . 35 Acknowledgements . . . . . . . . . . . . . . .
>>                              ^^^^^^^^^^^^^^^^
> Do not mix variants of the same word ("acknowledgement" and "acknowledgment")
> within a single text.
> 
> Section 2. , paragraph 11, nit:
>> vice such as a laptop, tablet or smart phone; or proprietary equipment connec
>>                                 ^^^^^^^^^^^
> Nowadays, it's more common to write this as one word.
> 
> Section 5.1. , paragraph 4, nit:
>> ord) MUST be supplied within the credentials section of the configuration and
>>                                 ^^^^^^^^^^^
> An apostrophe may be missing.
> 
> Section 5.2.1. , paragraph 1, nit:
>> f this document. To allow time to timeout an unanswered call and direct it t
>>                                  ^^^^^^^
> The word "timeout" is a noun. The verb is spelled with a white space.
> 
> Section 5.2.4. , paragraph 3, nit:
>> might require the location to be pre-loaded in some entity prior to placing
>>                                 ^^^^^^^^^^
> This word is normally spelled as one.
> 
> Section 5.2.4. , paragraph 3, nit:
>> device location than the manual, pre-loaded entry. That information MAY be u
>>                                  ^^^^^^^^^^
> This word is normally spelled as one.
> 
> Section 5.2.5. , paragraph 2, nit:
>> bscriber Information blocks. 5.3. Mid Call Signaling Implementations MUST sup
>>                                  ^^^^^^^^
> This word is normally spelled with a hyphen.
> 
> Section 5.2.5. , paragraph 3, nit:
>> number" includes numbers such as toll free numbers that are not actually E.1
>>                                  ^^^^^^^^^
> This word is normally spelled with a hyphen.
> 
> Section 7.2. , paragraph 3, nit:
>> lished a registry that contains a two letter country code and an entry point
>>                                  ^^^^^^^^^^
> When "two-letter" is used as a modifier, it is usually spelled with a hyphen.
> 
> Section 7.2. , paragraph 4, nit:
>> ble for display, with a corresponding a entry point to obtain information abo
>>                                      ^
> Use "an" instead of "a" if the following word starts with a vowel sound, e.g.
> "an article", "an hour".
> 
> Section 9.1. , paragraph 2, nit:
>> ersions of the major version. The versions mechanism returns an array of supp
>>                                  ^^^^^^^^
> An apostrophe may be missing.
> 
> Section 9.1. , paragraph 10, nit:
>> figuration service MAY be different than the version of the provider list se
>>                                    ^^^^
> Did you mean "different from"? "Different than" is often considered colloquial
> style.
> 
> Section 11. , paragraph 27, nit:
>> rfc-editor.org/info/rfc8126>. Acknowledgements Brett Henderson and Jim Mallo
>>                              ^^^^^^^^^^^^^^^^
> Do not mix variants of the same word ("acknowledgement" and "acknowledgment")
> within a single text.
> 
> 
>