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

[Ignas Bagdonas <[e-mail]>]

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.

2. What is the compatibility of this model 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?


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

RFC1305 is obsoleted by RFC5905.

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

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