[I2nsf] Robert Wilton's No Objection on draft-ietf-i2nsf-registration-interface-dm-24: (with COMMENT)

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

Robert Wilton has entered the following ballot position for
draft-ietf-i2nsf-registration-interface-dm-24: 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/about/groups/iesg/statements/handling-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-i2nsf-registration-interface-dm/



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

Hi,

I found this document harder to read, and this probably isn't quite the
approach that I would have taken.  Specifically, why not just export the
capabilities as a regular operational data model that returns the current
capabilities?

A couple more specific comments/suggestions below.

(1) p 18, sec 5.2.  YANG Data Module

     rpc nsf-capability-registration {
       description
         "Description of the capabilities that the
          Security Controller requests to the DMS";
       input {
         container query-nsf-capability {
           description
             "Description of the capabilities to request";

I'm not a big fan of this approach, but if please be very clear in the
description here for the input exactly what the input means.  E.g., does it
restrict, or filter, the output that is returned?

(2) p 18, sec 5.2.  YANG Data Module

           uses i2nsfcap:nsf-capabilities;
           reference "RFC YYYY: I2NSF Capability YANG Data Model";
         //RFC Ed.: replace YYYY with actual RFC number of
         //draft-ietf-i2nsf-capability-data-model and remove this note.
         }
       }
       output {
         list nsf {
           key "nsf-name";
           description
             "Network access information of an NSF
              with the requested capabilities";

In the description here, please be very clear about exactly what capabilities
are returned.  E.g., are they filtered by the input query?

(3) p 19, sec 5.2.  YANG Data Module

       output {
         container nsf {
           description
             "The update for the NSF";

Does this just return the current capabilities (which would probably be the
obvious choice), or is this filtered relative to what was returned previously
in the last nsf-capability-registration request?  If so, what happens if
another nsf-capability-registration request has been made?  E.g., it feels like
you are possibly holding on to some adhoc state between the RPC calls which may
prove to be fragile, particularly if you have more than one client that is
requesting the information.  I don't really understand why you don't have
return the current capabilities, and perhaps define a YANG notification to
notify clients if the capabilities have changed.

Nit level comments:

(4) p 6, sec 4.1.1.1.  NSF Specification

   temporarily, i.e., Random Access Memory (RAM).  The information
   consists of RAM maximum capacity and RAM speed.  The disk

I don't think that RAM speed is specified in the model, so perhaps this text
should be updated.

Thanks,
Rob