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

[Brian Rosen <[e-mail]>]

Thanks for your comments.  See inline for replies.

> On Dec 16, 2021, at 5:45 AM, Éric Vyncke via Datatracker <[e-mail]> wrote:
> 
> Éric Vyncke 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:
> ----------------------------------------------------------------------
> 
> Thank you for the work put into this document. This seems like a nice
> functionality to make the Internet more inclusive.
Thanks

> 
> Please find below some non-blocking COMMENT points (but replies would be
> appreciated even if only for my own education).
> 
> Special thanks to Paul Kyzivat for the shepherd's write-up including the
> section about the WG consensus. And being honest about the rough consensus and
> lack of energy. Thank you also Paul for the review of the 222 (!!!) IPR
> declarations (with some duplicates).
Yes, Paul has been really great as a co-chair
> 
> I hope that this helps to improve the document,
> 
> Regards,
> 
> -éric
> == COMMENTS ==
> 
> -- Abstract --
> Please expand “HoH”
Done

> 
> -- Section 4 --
> While I like "Implementations MUST support IPv4 and IPv6", it may be too strong
> though.
We’ve spent a good deal of time on this subject, and while there are participants who wanted this softened, the consensus was to leave it.

> 
> -- Section 6.7 --
> In "RUE MUST maintain any NAT bindings by periodically sending media packets",
> I wonder whether it is required in the case of IPv6 (usually no NAT but perhaps
> stateful devices on the path)... Perhaps change "NAT bindings" into "states in
> the network (e.g., NAT bindings)” ?
Done

> 
> -- Section 9.1 --
> I wonder why the focus is on the country and not the language... I.e., in my
> country, Belgium, there are 3 official languages and all of these languages are
> shared with other countries... I would suggest that either requesting by
> language or having the supported language(s) returned by the request.
There is a per-country list of providers.  That has to be per-country, because it’s most often some kind of regulatory thing, or at least organized within the country.  Then any given provider can support one or more languages.  That’s how the mechanism works.  There is s registry that points to the provider list, and then each provider has configuration data that is language sensitive.

> 
> 
>