[Green] Reminder: Model Design Team meeting on Monday + Previous Minutes

["Rob Wilton (rwilton)" <[e-mail]>]

Hi Green WG,



The next model design meeting will today, Monday 26th Jan, you should already have a webex meeting for this.  If not, I have just forwarded the calendar invite to the mail alias last Thursday.

Actions:

  *   Please can the design authors send out a pointer to the latest draft.
  *   WG, if you get a chance to read before the meeting on Monday that may be helpful.

Here are my somewhat rough minutes from the Monday 15th Model Design meeting.  The slides that were presented are also attached.





Slides 2-4: New Draft Posted

The draft has been updated and will be (or perhaps has been) posted.  As per the action above, I asked for the latest link to be sent out.

Questions are in the same order as previously (for consistency).

Slide 4: Please review the model structure (and ideally comment on the Green WG mail alias).



Discussion regarding whether this is a device or network model.  Confirmed that this is representing a device model.



Discussion about whether we should have 1 or 2 drafts.  Don't need to decide now.  Perhaps easiest at the moment to stick to a single draft while issues are being worked on, but longer term expectation is that we can/will split into 2 separate drafts, which may be beneficial for vendors/consumers, e.g., if they only implement a single model and hence a single RFC rather than just half a RFC.



Slide 4: The identities are for both accuracy & precision, and the text should be reworked to cover this.



Slide 5/6 - Question 5: What about Precision?

 - We should be about certification rather then requiring vendors to report precision?

  *   from vendor, the accuracy of equipment is not documented
  *   Jan: should not document but be certified.  Precision is done in number of digits; sometimes a fraction of

a digit with bad accuracy, precision is not relevant

  *   Rob: power of LC in kilowatts versus optics in W
  *   Jan: this is what I explained last time
  *   Diego: gold, silver, bronze, this sounds like marketing
  *   Jan: colors comes from electrical ...percent is good as a start … but the text should also include …

  *   Do we need identities for certification?  Benoit/Jan supportive.
  *   Gen: certification is the best way; high load with documenting everything otherwise.
  *   Marisol: shall we list all certifications.
  *   Certification could be anything?
  *   Jan: Could define some standard classes of certification with some defaults.
  *   Roland: Would be useful to have a reference to where it is defined?
  *   Identities are used, and hence new ones can be added.
  *   Identities needs to be for the entire (or a subset of) sensor tree, not for each sensor, otherwise it would be too much noise.
  *   Benoit: hardware tree allows sensor information to be done hierarchically.  E.g., if you have the information for a device then do you also need it to be reported for each of the optics?
  *   Benoit: To operators, what level of accuracy is needed?
  *   Roland (DT): Aggregation is sufficient, generally, for operational data.
  *   Benoit: Perhaps not in a lab environment.
  *   Diego: Is this IETF's problem?  Can we push the specification elsewhere, e.g., for certification.
  *   Benoit: Not clear if that will work, cannot assume that all schemes will fit into the same labels.
  *   Benoit: send separate identities for different certification institutes
  *   Benoit: Have general identities but also allow more specific identities.
  *   Diego: Bronze is accuracy within 10%.
  *   Benoit: Bronze is 10% ,with a pointer to a spec that mentions "bronze is 10% in that certification C" will not work
  *   Rob: So are you suggesting general identities/definitions?
  *   Benoit: Yes, define some general ones, but also some identity series that derive from different certifications.  E.g., ask vendors/operators what they use/require (which may differ by market).
  *   Rob: How do you aggregate identities, e.g., if you are getting different identity schemes for DC power supplies vs HVAC, vs the network devices?
  *   Jan: That is a bigger issue.
  *   Benoit proposal:
     *   Have generic gold/silver/bronze
     *   Also define a few certifications at the same time.  No mapping to go from other certifications back to this one (i.e., out of scope for now).  We are leaving as an open issue for now on how a controller will aggregate values that are certified at different levels of accuracy.
     *   Question for operators as whether this be sufficient?
     *   Question to operators (and perhaps vendors) which certifications do they require.
     *   Model also needs to be able to report accuracy/precision in an efficient way.




Slide 8 - Question 6: : Can we Assume YANG-Push for Data Collection?

  *   Proposal is that we don't need Energy ParametersTable, only some of the fields in the Energy Table.
  *   Don't need extra table.  Treat as generic telemetry data.
  *   Roland asked about the need to store data (e.g., if the controller isn't available to collect the data).  Consensus seemed to be out of scope, this a question for YANG Push, or YANG Push v2.

Please send any comments/clarifications/questions to the list, or you can raise them on Monday.

Kind regards,
Rob