[Rum] Robert Wilton's Discuss on draft-ietf-rum-rue-09: (with DISCUSS and COMMENT)

[Robert Wilton via Datatracker <[e-mail]>]

Robert Wilton has entered the following ballot position for
draft-ietf-rum-rue-09: Discuss

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/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

There are a couple of points related to versioning that I would like to see
clarified, but I hope that it should be fairly easy to do so.

1.
   This means an implementation of a
   specific major version and minor version is backwards compatible with
   all minor versions of the major version.

Is it actually compatible with all other minor versions, or only other minor
versions with a greater minor version number.  E.g., could an implementation be
coded to use/expect a object added in a minor version but that is not present
in preceding minor versions?

2.
   The configuration API also provides the same version mechanism as
   specified above in Section 9.1.  The version of the configuration
   service MAY be different than the version of the provider list
   service.

It wasn't obvious to me, that for a given provider, how this is communicated. 
I'm not that familiar with OpenAPI, but looks like the /Versions path is a top
level API path, and the data that is contains seems to just be version numbers.
 Hence, how would a client know which versions apply to provider list service
and/or which versions apply to the provide configuration service.


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

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