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

[Ignas Bagdonas <[e-mail]>]

Hi Mahesh,


>> 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.

That seems to be a practical way and also aligned with the current 
charter. While there is a question of practicality of what a 
configuration-only model allows to do, this is better than nothing. 
Gaining operational experience is needed, and we better start with a 
partial solution.

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

Excellent. As Spencer mentioned, it may be good to have that stated 
specifically, as other models do.

>> 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.

That is understood and probably can be justified for this particular 
model. But the cost of this approach is yet another way of storing key 
information.

> 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?

I am happy with the answers, will clear the DISCUSS. The one that I am 
somewhat less happy with is the key storage one - from the perspective 
of both model developer and application developer, additional model that 
does mostly the same thing is getting towards both to the duplication of 
the work and encouraging the divergence of the ways how similar things 
are done. The root of the problem is far deeper than this draft - there 
does not appear to be an overall coordination of how the different 
models bind together into something that allows to use different models 
in the context of the whole system.


>
>> 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.

This might be a topic for a broader discussion of YANG model 
coordination - it is not in scope of this draft though. The fact is that 
JSON encoding looks to be easier to read than XML one, and maybe a 
common recommendation could be to use JSON for examples. Again, for the 
context of this draft this is a nit type suggestion - and it is up to 
authors and WG to decide whether a change is needed given that it was 
not discussed more broadly in the whole YANG development effort.

Thank you.

Ignas