Ballot for draft-ietf-rum-rue
Yes
No Objection
Note: This ballot was opened for revision 09 and is now closed.
[S5; nit] * Both RFCs 6655 and 6665 are mentioned. I think the 6655 reference should actually be to 6665 (unless "AES-CCM Cipher Suites for TLS" is of specific importance). [S6; nit] * W.R.T.: "Mandatory to Implement" means a conforming implementation must implement the specified capability. It seems like, since 8174 is in use, this "must" might be a "MUST", to avoid any ambiguity.
Thank you for the work on this document. Many thanks to Rich Salz for his review: https://mailarchive.ietf.org/arch/msg/art/FAnGx_MrrlJVdU8WxbGG_BOFVe8/ . I only had time to scan the document, but did not find any major ART issues. Francesca
I appreciate your work on this topic. I do have one question I’d like answered: RFC 3261 is updated by a long list of other RFCs. In the course of developing this spec, did you consider, for each of those, whether it should be listed as a normative reference? My guess is that the answer is “yes”, since §5 makes it appear some careful consideration was given to this question and several of the RFCs that update 3261 are listed in that section. Still, I’d be more comfortable if you’d confirm. (Another way to think of this is, for all the RFCs that update 3261 and are NOT already referenced by your spec, are you confident they don’t need to be referenced?)
Thank you to Russ Mundy for the SECDIR review. Thank you for addressing my DISCUSS and COMMENT feedback.
I have very little substantive to add -- other ADs are already holding DISCUSSes for the concerns that I had. I would like to note though that I find this sort of document (e.g: "Implementations of the RUE Interface MUST conform to the following core SIP standards: [ <many many documents> ]") really useful. When a customer (or pointy-haired-boss) asks you to implement or deploy some new protocol you've never even heard of, it is incredibly helpful to have 1: a use-case/requirements doc so you know what the protocol does, 2: an overview / architecture, 3: a list of other important docs and 4: an operational/deployment doc. This document covers a number of these parts.
Thanks for addressing the comments in the Discuss. The changes made in version -10 look good to me.
Thank you for the work put into this document. This seems like a nice functionality to make the Internet more inclusive. 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). I hope that this helps to improve the document, Regards, -éric == COMMENTS == -- Abstract -- Please expand "HoH" -- Section 4 -- While I like "Implementations MUST support IPv4 and IPv6", it may be too strong though. -- 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)" ? -- 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.
Many thanks for the updates in the -10; we look to be nice and self-consistent (modulo carddav-domain, see below) now. I especially like the example passwords -- good entropy there :) There are some editorial/formatting nits that crept in, but I'm sure the RFC Editor can fix those up and didn't bother enumerating them here. A few final comments/suggestions: The description of "carddav-domain" uses "server address" in the OpenAPI description string but in the prose description we call it "contacts-domain" (not "carddav-domain") and we describe it as just "a domain name" (vs address). It would be good to tighten those up into closer alignment. Section 9.2 The data returned is a JSON object consisting of an array of key/ value configuration parameters to be used by the RUE. s/consisting of an array of/consisting of/, I think -- the openAPI looks like just an object, no array. Section 9.2.2 * contacts: (optional) An HTTPS URI ("contacts-uri"), (optional) user name ("contacts-username") and password ("contacts-password") that may be used to export (retrieve) the subscriber's complete [...] * carddav: (optional) A domain name ("contacts-domain"), (optional) user name ("carddav-username") and password ("carddav-password") identifying a "CardDAV" server and account that can be used to I'd go with "An object containing [URI/domain name], and optional [user name and password]," for both of these. The OpenAPI description is clear (and authoritative, thanks for that!), but this is an easy tweak to help readability.
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". No reference entries found for: [RFC6655]. 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.
Thanks for addressing my DISCUSS, and your work to make the internet more accessible for all.
[Clearing discuss points based on Brian's clarification and proposed resolution text.] Hi Brian, Thank you for working on this. This technology is quite a long way outside of my expertise, and hence my review is primarily focused on the Configuration section (section 9). Nit: when used with the following interface => when used with the following OpenAPI interface Nit: with a corresponding a entry point -> with a corresponding entry point Minor version definitions SHALL only add objects, non-required members of existing objects, and non-mandatory-to use functions and SHALL NOT delete any objects, members of objects or functions. Would "delete or change" be more correct than just "delete" here? Somewhat related to the discuss comment, but it wasn't clear to me why the versioning is described as part of the "Rue Provider Selection" section and I think that the document would arguably be clearer if the versioning moved to its own separate 9.X section, making it clear that the versioning applies to the entire API? Nit: The method the API Key is obtained is not specified in this document. => Perhaps "The method used to obtain the API key ..." The provider MAY refuse to provide service to an implementation presenting an API Key it does not recognize. Why is this not a MUST? Is the "instance-identifier" arbitrarily chosen by the client? Otherwise, it wasn't clear to me how a client would discover or know what "instance-identifier" to use. It might be helpful if the text clarified this, and possibly even the parameter name could be changed to make it more obvious that it is a client provided value? Regards, Rob