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

["[e-mail]" <[e-mail]>]

Hi Rob,

Thanks Rob.
>
> 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.*
>
Latest posted draft: 
https://datatracker.ietf.org/doc/draft-bcmj-green-power-and-energy-yang/
Latest temp version: 
https://github.com/ietf-wg-green/green-design-work/blob/main/draft-bcmj-green-power-and-energy-yang.md

Talk to you in a couple of hours.

Regards, Benoit
>
>   * *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:
>       o Have generic gold/silver/bronze
>       o 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.
>       o Question for operators as whether this be sufficient?
>       o Question to operators (and perhaps vendors) which
>         certifications do they require.
>       o 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
>
>
> _______________________________________________
> Green mailing list [e-mail]
> To unsubscribe send an email [e-mail]