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

From: Ignas Bagdonas <[email-masked]>
Date: Wed, 20 Jun 2018 08:50:46 -0700

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?

---

From: Mahesh Jethanandani <[email-masked]>
Date: Thu, 21 Jun 2018 13:46:40 -0700

Hi Ignas,

> On Jun 20, 2018, at 8:50 AM, Ignas Bagdonas <[email-masked]> wrote:
> 

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.

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

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
[email-masked]

---

From: "MORTON, ALFRED C (AL)" <[email-masked]>
Date: Thu, 21 Jun 2018 21:17:30 +0000

Hi Ignas and Mahesh,

> -----Original Message-----
> From: ippm [mailto:[email-masked]] On Behalf Of Mahesh Jethanandani
> Sent: Thursday, June 21, 2018 4:47 PM
> To: Ignas Bagdonas <[email-masked]>
> Cc: [email-masked]; [email-masked]; The IESG
> <[email-masked]>; [email-masked]
> Subject: Re: [ippm] Ignas Bagdonas' Discuss on draft-ietf-ippm-twamp-yang-
> 11: (with DISCUSS and COMMENT)
> 
> Hi Ignas,
> 
...
> 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.
[acm] 

One clarification on the response above. The TWAMP measurement protocol
is completely agnostic to *what* metrics are measured, but we made an 
exception in one case to take advantage of other IPPM work on the PM Registry.

It would be straightforward to build an independent model for the performance 
metrics/results in future, because the parameter and output formats are 
heavily specified in the Registry now, and that model would be applicable 
beyond TWAMP and available for any users of the Registry.

Al

...

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Thu, 21 Jun 2018 17:24:52 -0500

I'm not Ignas and can't answer whether these responses address his Discuss,
but if I might make a couple of comments ...

On Thu, Jun 21, 2018 at 3:46 PM Mahesh Jethanandani <[email-masked]>
wrote:

> > Please refer to
> https://www.ietf.org/iesg/statement/discuss-criteria.html
> 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.
>

Somewhere between this response and Al's related response, I suspect it
would be helpful to say this in the document, for readers who aren't
specialists like you folks.

> This model is compatible with NMDA.

The IESG has been balloting on several YANG model revisions lately, because
the original versions predated NMDA and needed to be updated to be
compatible with NMDA. That turned out to be big enough to appear in the
Abstract and Introduction - for example, in the protocol action for
draft-ietf-rtgwg-lne-model-09.txt, you'll see

RFC Editor Note:

Please update first sentence of Abstract from:

"This document defines a logical network element YANG module."
to:
This document defines a logical network element NMDA-compliant YANG module."

and the first line of the Introduction from:

"This document defines a YANG [RFC6020] module to support the creation
of logical network elements on a network device. "
to:
"This document defines an NMDA-compliant YANG [RFC6020] module to support
the
creation of logical network elements on a network device. "

This is to make sure the point is captured. Authors & RFC Editor are welcome
to improve the text or change how the point is made.

If you already did the work to make the model compatible with NMDA, the
IESG seems to want people to take credit for having done the work ;-)

I hope that's helpful, and not just in resolving Ignas's Discuss.

Spencer

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

---

From: Mahesh Jethanandani <[email-masked]>
Date: Thu, 21 Jun 2018 15:57:11 -0700

Hi Spencer,

See inline.

> On Jun 21, 2018, at 3:24 PM, Spencer Dawkins at IETF <[email-masked]> wrote:
> 
> I'm not Ignas and can't answer whether these responses address his Discuss, but if I might make a couple of comments ...
> 
> On Thu, Jun 21, 2018 at 3:46 PM Mahesh Jethanandani <[email-masked] <mailto:[email-masked]>> wrote:
> Hi Ignas,
> 
> > On Jun 20, 2018, at 8:50 AM, Ignas Bagdonas <[email-masked] <mailto:[email-masked]>> wrote:
> > 
> > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html <https://www.ietf.org/iesg/statement/discuss-criteria.html>
> > https://datatracker.ietf.org/doc/draft-ietf-ippm-twamp-yang/ <https://datatracker.ietf.org/doc/draft-ietf-ippm-twamp-yang/>
> > 
> > 
> > 
> Somewhere between this response and Al's related response, I suspect it would be helpful to say this in the document, for readers who aren't specialists like you folks.

Ok. Have added the following text:

"In addition, for operational state, current work in Registry for Performance Metrics[I-D.ietf-ippm-metric-registry], can be used to develop an independent model for the performance metrics that need to be captured and retrieved."

> The IESG has been balloting on several YANG model revisions lately, because the original versions predated NMDA and needed to be updated to be compatible with NMDA. That turned out to be big enough to appear in the Abstract and Introduction - for example, in the protocol action for draft-ietf-rtgwg-lne-model-09.txt, you'll see
> 
> RFC Editor Note:
> 
> "This document defines an NMDA-compliant YANG [RFC6020] module to support the
> If you already did the work to make the model compatible with NMDA, the IESG seems to want people to take credit for having done the work ;-)

Have updated Abstract to say:

“… and formally specifies it with a NDMA-compliant YANG model”

and Introduction to say:

"This document addresses this gap by formally specifying a NMDA[RFC8342]-complaint TWAMP data model using YANG 1.1 [RFC7950]."

> I hope that's helpful, and not just in resolving Ignas's Discuss. 

It is.

Thanks.

> [email-masked] <mailto:[email-masked]>
> 

Mahesh Jethanandani
[email-masked]

---

From: Ignas Bagdonas <[email-masked]>
Date: Tue, 26 Jun 2018 17:32:12 +0100

Hi Mahesh,

> 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 Perform…

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.

> This model is compatible with NMDA.

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

> 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 fol…

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.

> 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

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Thu, 28 Jun 2018 09:24:31 -0500

Dear Authors,

Thank you for a quick and productive Discussion on Ignas's ballot position
on this draft.

> model. But the cost of this approach is yet another way of storing key

I saw that Ignas cleared his Discuss here, but did have a question about
where the resolution ended up.

I understood Ignas to be asking two things - where did this way of storing
keys come from, and why was an existing way of storing the keys not chosen?

I understand that Ignas cleared his Discuss, based on the explanation in
this e-mail thread.

I wonder if it is worth a sentence or two, to explain that in the draft
("we started with this key storage model, and left out parts we didn't
need", or something like that).

I'm reviewing changes today, so expect to be sending the e-mail approving
publication pretty soon.

Spencer

---

From: "MORTON, ALFRED C (AL)" <[email-masked]>
Date: Thu, 28 Jun 2018 14:32:16 +0000

Hi Spencer,

From: Spencer Dawkins at IETF [mailto:[email-masked]]
Sent: Thursday, June 28, 2018 10:25 AM
To: Ignas Bagdonas <[email-masked]>
Cc: Mahesh Jethanandani <[email-masked]>; [email-masked]; [email-masked]; IESG <[email-masked]>; [email-masked]; Nalini Elkins <[email-masked]>
Subject: Re: Ignas Bagdonas' Discuss on draft-ietf-ippm-twamp-yang-11: (with DISCUSS and COMMENT)

Dear Authors,

Thank you for a quick and productive Discussion on Ignas's ballot position on this draft.

I saw that Ignas cleared his Discuss here, but did have a question about where the resolution ended up.

I understood Ignas to be asking two things - where did this way of storing keys come from, and why was an existing way of storing the keys not chosen?

I understand that Ignas cleared his Discuss, based on the explanation in this e-mail thread.

I wonder if it is worth a sentence or two, to explain that in the draft ("we started with this key storage model, and left out parts we didn't  need", or something like that).
[acm]
That’s exactly how I described what I did when the authors first
discussed the topic, and again in reply to Ignas’ DISCUSS.
Another aspect was the overlapping development of the model memos.
I don’t have a problem qualifying what we did here,
as an explanation. As Ignas points out, there is a larger
model problem to solve.

Al

I'm reviewing changes today, so expect to be sending the e-mail approving publication pretty soon.

Spencer

---

From: "t.petch" <[email-masked]>
Date: Fri, 29 Jun 2018 11:41:12 +0100

Spencer

Perhaps one for a Note to the RFC Editor

-12 still has
         bit unauth-test-encrpyt-control {
which AM suggested should be
         bit unauth-test-encrypt-control {

Tom Petch

----- Original Message -----
From: "Spencer Dawkins at IETF" <[email-masked]>
To: "Ignas Bagdonas" <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>;
<[email-masked]>; "IESG" <[email-masked]>
Sent: Thursday, June 28, 2018 3:24 PM

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

---

From: "MORTON, ALFRED C (AL)" <[email-masked]>
Date: Fri, 29 Jun 2018 18:24:53 +0000

-encrypt- is still misspelled, thanks for catching that.
Al

> From: t.petch [mailto:[email-masked]]
> Sent: Friday, June 29, 2018 6:41 AM
> To: Spencer Dawkins at IETF <[email-masked]>
> Cc: [email-masked]; [email-masked]; draft-ietf-ippm-twamp-
> [email-masked]; IESG <[email-masked]>