Re: [ippm] Ignas Bagdonas' Discuss on draft-ietf-ippm-twamp-yang-11: (with DISCUSS and COMMENT)

[Mahesh Jethanandani <[e-mail]>]

Hi Ignas,

> On Jun 20, 2018, at 8:50 AM, Ignas Bagdonas <[e-mail]> wrote:
> 
> Ignas Bagdonas has entered the following ballot position for
> draft-ietf-ippm-twamp-yang-11: 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/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-ippm-twamp-yang/
> 
> 
> 
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
> 
> I have three large areas of questions related to this model. They are not
> related to the contents of the module itself but to the broader scope of where
> this model can and should fit in the overall context of practical manageability
> and usability.
> 
> 1. Operational state. Section 2 defines operational aspects of the configured
> TWAMP mechanisms as being out of scope. How does that relate to the motivation
> goals in section 1? Having no common machine readable mechanism for retrieving
> measurement results and verifying the operation of measurement processes does
> not seem to help in reducing the need for proprietary mechanisms.

The idea behind describing operational part of the model as out of scope, particularly as they relate to measurement results, relates the work that is currently going on in the “Registry of Performance Metrics (PM)”, something the IPPM WG is trying to finish. Once that work is complete, this model can be enhanced or another one written to provide the data needed for PM.

> 
> 2. What is the compatibility of this model with NMDA?

This model is compatible with NMDA.

> 
> 3. Key storage. The document defines its own way of storing keys - while there
> are multiple existing ways to store keys (routing key-chain model, I2NSF, IPsec
> model, netconf-keystore). Why yet another key storage mechanism is required?
> What could be reused from other existing mechanisms?

Precisely. When we started work on this draft, there were plethora of ideas on how to store keys. We borrowed the idea from what is now the ietf-key-chain module to define the key chain. And we followed the KISS principle by incorporating what was absolutely needed by TWAMP.

Having the answers for the three points that you have raised, would you still have a DISCUSS. If so, which issue, do you want to see addressed?

> 
> 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> RFC1305 is obsoleted by RFC5905.

Updated.

> 
> A nit suggestion - YANG examples typically look more readable in JSON encoding.

I am reading this is more as a suggestion than as a nit.

> 
> IANA considerations section - likley the registrant contact should be the IESG and not the IPPM WG?

Will fix.

Thanks.

> 
> 

Mahesh Jethanandani
[e-mail]