Subject: [ippm] AD Evaluation of draft-ietf-ippm-twamp-yang-06

From: Spencer Dawkins at IETF <[email-masked]>
Date: Thu, 29 Mar 2018 15:44:59 -0500

Dear IPPMers,

I apologize for a slow AD Evaluation for this draft.

In general, I found this document to be pretty clear, and I liked the
multiple levels of detail as a service to readers and implementers. Thank
you for that.

I have a decent number of questions, but almost none of them are technical
observations. I'd expect they'd be easy to consider, before I request IETF
Last Call.

Please let me know when you're ready to proceed with this draft.

Thanks,

Spencer

In this text,

   To date, TWAMP implementations do not
   come with a standard management framework and, as such, configuration
   depends on proprietary mechanisms developed by the corresponding
   TWAMP vendor.

is it correct to say that there is no standardized configuration mechanism
for TWAMP, so that implementers have no choice except to provide
proprietary mechanisms?

In this text,

   From an operations
   perspective, dealing with several vendor-specific TWAMP configuration
   mechanisms is simply unsustainable in this context.

I'm not sure this is true in all cases, because some people just keep doing
things that cost money and don't make sense. But would it be correct to say
this?

   From an operations
   perspective, using several vendor-specific TWAMP configuration
   mechanisms when one standardized mechanism could provide an alternative
   is expensive and inefficient.

I'm confused by

  Note to RFC Editor:

   Please replace the date in the draft of the format 2018-02-13 with
   the date of publication of this draft.  Also, replace reference to
   draft-ietf-ippm-twamp-yang, and draft-ietf-ippm-metric-registry with
   the RFC numbers assigned to the draft.

for several reasons.

Did you mean "date of publication of this draft", or "date of publication
of this draft as an RFC? Either way, saying "in Section 5.2" is probably
helpful for the RFC Editor. If there's only two, you could put this note in
Section 5.2, which they'd likely appreciate.

Did you mean to replace the draft name that appears in
[email-masked]? You might consider using
something like RFCXXX, and asking the RFC editor to replace RFCXXX with the
eventual RFC number.

I'd say the same thing about draft-ietf-ippm-metric-registry, except that
ISTM that you could just use the existing reference to
[I-D.ietf-ippm-metric-registry], and the RFC editor would Do The Right
Thing.

I note that [I-D.ietf-ippm-metric-registry] is listed as an Informative
reference. Could you understand this draft without reading
[I-D.ietf-ippm-metric-registry]? If that draft is as Normative as I think
it might be, the RFC Editor would automatically hold this document until
[I-D.ietf-ippm-metric-registry] is published, and then make the usual
substitutions.

Is there a particular reference for UML that you could provide? I don't
happen to have that on my bookshelf. Perhaps other readers would find it
useful, too.

I note at least one use of RFC 2119 language in lower case ("must"). I'd
suggest either shifting any lower-case requirements language to upper case
or using https://tools.ietf.org/html/rfc8174 for the definition of
requirements language. RFC 2119 was a frequent topic among Gen-ART
reviewers when I was part of the review team.

I'm not questioning this text,

  If the user has no network access to the Control-Client device, then
   the only option is to retrieve all test-session instances from the
   Session-Reflector device.  This could be problematic if a large
   number of test sessions are currently active on that device.

but I am trying to understand what type of problems you're thinking of
(delays in starting testing from the Control-Client device, because the
Session-Reflector is heavily loaded? Interference with current test
sessions? Or something else), and find myself guessing.

When I read

   This section presents a simplified graphical representation of the
   TWAMP data model using a YANG tree diagram.  Readers should keep in
   mind that the limit of 72 characters per line forces us to introduce
   artificial line breaks in some tree diagram nodes.

I'm not sure how I would know which line breaks are artificial. Is this
just about the breaks in the middle of a word on longer lines, so that the
word appears to wrap around to the left side of the page, or something
else?

(As an aside, I haven't done AD evaluations for YANG data models
previously, but this data model doesn't seem to be excessively nested or to
use excessively long names. Perhaps there's a convention that would
indicate continuation more clearly?)

I found myself wondering if

   There are a number of nodes defined in this YANG module which are
   writeable.  These data nodes may be considered sensitive and
   vulnerable to attacks in some network environments.  Ability to write
   into these nodes without proper protection can have a negative effect
   on the devices that support this feature.

was understated - when are writeable nodes not "sensitive and vulnerable to
attacks" without "proper protection"? I see

  The YANG module defined in Section 5 is designed to be accessed,
   among other protocols, via NETCONF [RFC6241].  Protocols like NETCONF
   use a secure transport layer like SSH that is mandatory to implement.

a bit further up the page, but would it make sense to prohibit the use of a
protocol that doesn't have a mandatory-to-implement secure transport
mechanism? This may be well-traveled ground in the YANG community, so the
current text could be fine, but I wanted to ask before SECDIR reviewers are
doing Last Call reviews ...

---

From: Mahesh Jethanandani <[email-masked]>
Date: Thu, 29 Mar 2018 21:45:01 -0700

Spencer,

Let me take a crack at responding to some of the questions you raised.

On 3/29/18 1:44 PM, Spencer Dawkins at IETF wrote:
> multiple levels of detail as a service to readers and implementers. 
> Thank you for that.
>
> I have a decent number of questions, but almost none of them are 
> technical observations. I'd expect they'd be easy to consider, before 
> I request IETF Last Call.
>
> is it correct to say that there is no standardized configuration 
> mechanism for TWAMP, so that implementers have no choice except to 
> provide proprietary mechanisms?
Since we are talking both configuration and monitoring, I would rather say:

To date, TWAMP implementations do not come with a standard management 
framework, and, as such, management depends on proprietary mechanism 
developed by the corresponding TWAMP vendor.
> I'm not sure this is true in all cases, because some people just keep 
> doing things that cost money and don't make sense. But would it be 
> correct to say this?
>
>    From an operations
Fair enough.
> Did you mean "date of publication of this draft", or "date of 
> publication of this draft as an RFC?
Yes.
> Either way, saying "in Section 5.2" is probably helpful for the RFC 
> Editor. If there's only two, you could put this note in Section 5.2, 
> which they'd likely appreciate.
We can do that.
> [email-masked] 
> <mailto:[email-masked]>? You might consider 
> using
> something like RFCXXX, and asking the RFC editor to replace RFCXXX 
> with the eventual RFC number.
Ok.
>
> I'd say the same thing about draft-ietf-ippm-metric-registry, except 
> that ISTM that you could just use the existing reference to 
> I note that [I-D.ietf-ippm-metric-registry] is listed as an 
> Informative reference. Could you understand this draft without reading 
> [I-D.ietf-ippm-metric-registry]? If that draft is as Normative as I 
> think it might be, the RFC Editor would automatically hold this 
> document until [I-D.ietf-ippm-metric-registry] is published, and then 
> make the usual substitutions.
>
> Is there a particular reference for UML that you could provide? I 
> don't happen to have that on my bookshelf. Perhaps other readers would 
> find it useful, too.
We can add that.
>
> I note at least one use of RFC 2119 language in lower case ("must"). 
> I'd suggest either shifting any lower-case requirements language to 
> upper case or using https://tools.ietf.org/html/rfc8174 for the 
> definition of requirements language. RFC 2119 was a frequent topic 
> among Gen-ART reviewers when I was part of the review team.
There are two lower case "must". These "must" are the normal English 
language use of must rather than the RFC 2119 version of must. We will 
therefore update section 1.2 with:

       The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
       NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED",
       "MAY", and "OPTIONAL" in this document are to be interpreted as
       described inBCP 14 <https://tools.ietf.org/html/bcp14>  [RFC2119 <https://tools.ietf.org/html/rfc2119>] [RFC8174 <https://tools.ietf.org/html/rfc8174>] when, and only when, they
       appear in all capitals, as shown here.

> (delays in starting testing from the Control-Client device, because 
> the Session-Reflector is heavily loaded? Interference with current 
> test sessions? Or something else), and find myself guessing.
Good question. I am going to see if one of my co-authors could answer 
this question better than me.
> I'm not sure how I would know which line breaks are artificial. Is 
> this just about the breaks in the middle of a word on longer lines, so 
> that the word appears to wrap around to the left side of the page, or 
> something else?
It is the latter. Would it help if we actually put a "\" character at 
the end of the line to indicate a line break?
> previously, but this data model doesn't seem to be excessively nested 
> or to use excessively long names. Perhaps there's a convention that 
> would indicate continuation more clearly?)
There isn't a conventions currently. But I have used the "\" character 
in some of the other models that I have authored.
> was understated - when are writeable nodes not "sensitive and 
> vulnerable to attacks" without "proper protection"? I see
>
> a bit further up the page, but would it make sense to prohibit the use 
> of a protocol that doesn't have a mandatory-to-implement secure 
> transport mechanism? This may be well-traveled ground in the YANG 
> community, so the current text could be fine, but I wanted to ask 
> before SECDIR reviewers are doing Last Call reviews ...
We (as in YANG doctors), have gone several rounds with SECDIR on the 
language that all YANG modules are supposed to carry as part of Security 
Considerations, and this was the language we seem to have agreed upon 
and documented in rfc6087bis. That is not to say that they might not 
still call it into question.

Cheers.

Mahesh Jethanandani
[email-masked]

---

From: Spencer Dawkins <[email-masked]>
Date: Fri, 30 Mar 2018 08:00:49 -0500

Hi, Manesh,

I had one point below, but all your other responses will be fine.

Spencer

> developed by the corresponding TWAMP vendor.
If this data model is replacing an existing standardized management 
framework, I misunderstood. But if it's not replacing an existing 
standardized management framework, my point was that

- there is no existing standardized management framework, so
- if an implementer wants to ship a management framework, it will not be 
a standardized framework

;-)

Do the right thing, of course ;-)

Spencer

>> <mailto:[email-masked]>? You might 
>> consider using
>> [I-D.ietf-ippm-metric-registry], and the RFC editor would Do The 
>> Right Thing.
>>
>> Informative reference. Could you understand this draft without 
>> reading [I-D.ietf-ippm-metric-registry]? If that draft is as 
>> Normative as I think it might be, the RFC Editor would automatically 
>> hold this document until [I-D.ietf-ippm-metric-registry] is 
>> published, and then make the usual substitutions.
>>
>> don't happen to have that on my bookshelf. Perhaps other readers 
>> would find it useful, too.
> We can add that.
>>
>> but I am trying to understand what type of problems you're thinking 
>> of (delays in starting testing from the Control-Client device, 
>> because the Session-Reflector is heavily loaded? Interference with 
>> current test sessions? Or something else), and find myself guessing.
>> this just about the breaks in the middle of a word on longer lines, 
>> so that the word appears to wrap around to the left side of the page, 
>> or something else?
>> a bit further up the page, but would it make sense to prohibit the 
>> use of a protocol that doesn't have a mandatory-to-implement secure 
> language that all YANG modules are supposed to carry as part of 
> Security Considerations, and this was the language we seem to have 
> agreed upon and documented in rfc6087bis. That is not to say that they 
> might not still call it into question.
>
> Cheers.
>
> Mahesh Jethanandani
> [email-masked]
>

---

From: Mahesh Jethanandani <[email-masked]>
Date: Sat, 31 Mar 2018 09:15:35 -0700

Spencer,

> On Mar 30, 2018, at 6:00 AM, Spencer Dawkins <[email-masked]> wrote:
> 
> Hi, Manesh,
> 
>>> In general, I found this document to be pretty clear, and I liked the multiple levels of detail as a service to readers and implementers. Thank you for that.
>>> 
>>> I have a decent number of questions, but almost none of them are technical observations. I'd expect they'd be easy to consider, before I request IETF Last Call.
>>> 
>>> is it correct to say that there is no standardized configuration mechanism for TWAMP, so that implementers have no choice except to provide proprietary mechanisms?
>> To date, TWAMP implementations do not come with a standard management framework, and, as such, management depends on proprietary mechanism developed by the corresponding TWAMP vendor.
> If this data model is replacing an existing standardized management framework, I misunderstood. But if it's not replacing an existing standardized management framework, my point was that
> 
> - if an implementer wants to ship a management framework, it will not be a standardized framework

You are right. We are not replacing an existing standardized management framework.

How does this sound?

OLD:

NEW:

   To date, TWAMP implementations do not
   come with a standard management framework, and, as such, implementors
   have no choice except to provide a proprietary mechanism.

Cheers

>>> I'm not sure this is true in all cases, because some people just keep doing things that cost money and don't make sense. But would it be correct to say this?
>>> 
>>>    From an operations
>>> Did you mean "date of publication of this draft", or "date of publication of this draft as an RFC?
>> Yes.
>>> Either way, saying "in Section 5.2" is probably helpful for the RFC Editor. If there's only two, you could put this note in Section 5.2, which they'd               likely appreciate.
>> We can do that.
>>> 
>>> Did you mean to replace the draft name that appears in  [email-masked] <mailto:[email-masked]>? You might consider using 
>>> something like RFCXXX, and asking the RFC editor to replace RFCXXX with the eventual RFC number.
>> Ok.
>>> 
>>> I'd say the same thing about draft-ietf-ippm-metric-registry, except that ISTM that you could just use the existing reference to [I-D.ietf-ippm-metric-registry], and the RFC editor would Do The Right Thing.
>>> 
>>> I note that [I-D.ietf-ippm-metric-registry] is listed as an Informative reference. Could you understand this draft without reading [I-D.ietf-ippm-metric-registry]? If that draft is as Normative as I think it might be, the RFC Editor would automatically hold this document until [I-D.ietf-ippm-metric-registry] is published, and then make the usual substitutions. 
>>> 
>>> Is there a particular reference for UML that you could provide? I don't happen to have that on my bookshelf. Perhaps other readers would find it useful, too.
>> We can add that.
>>> 
>>> I note at least one use of RFC 2119 language in lower case ("must"). I'd suggest either shifting any lower-case requirements language to upper case or using https://tools.ietf.org/html/rfc8174 <https://tools.ietf.org/html/rfc8174> for the definition of requirements language. RFC 2119 was a frequent topic among Gen-ART reviewers when I was part of the review team.
>> There are two lower case "must". These "must" are the normal English language use of must rather than the RFC 2119 version of must. We will therefore update section 1.2 with:
>> 
>> 
>>       described in BCP 14 <https://tools.ietf.org/html/bcp14> [RFC2119 <https://tools.ietf.org/html/rfc2119>] [RFC8174 <https://tools.ietf.org/html/rfc8174>] when, and only when, they
>>> but I am trying to understand what type of problems you're thinking of (delays in starting testing from the Control-Client device, because the Session-Reflector is heavily loaded? Interference with current test sessions? Or something else), and find myself guessing.
>> Good question. I am going to see if one of my co-authors could answer this question better than me.
>>> 
>>> When I read 
>>> 
>>> I'm not sure how I would know which line breaks are artificial. Is this just about the breaks in the middle of a word on longer lines, so that the word appears to wrap around to the left side of the page, or something else? 
>> It is the latter. Would it help if we actually put a "\" character at the end of the line to indicate a line break?
>>> 
>>> (As an aside, I haven't done AD evaluations for YANG data models previously, but this data model doesn't seem to be excessively nested or to use excessively long names. Perhaps there's a convention that would indicate continuation more clearly?)
>> There isn't a conventions currently. But I have used the "\" character in some of the other models that I have authored.
>>> 
>>> was understated - when are writeable nodes not "sensitive and vulnerable to attacks" without "proper protection"? I see 
>>> 
>>> a bit further up the page, but would it make sense to prohibit the use of a protocol that doesn't have a mandatory-to-implement secure transport mechanism? This may be well-traveled ground in the YANG community, so the current text could be fine, but I wanted to ask before SECDIR reviewers are doing Last Call reviews ...
>> We (as in YANG doctors), have gone several rounds with SECDIR on the language that all YANG modules are supposed to carry as part of Security Considerations, and this was the language we seem to have agreed upon and documented in rfc6087bis. That is not to say that they might not still call it into question.
>> 
>> Cheers.
>> 
>> Mahesh Jethanandani
>> [email-masked] <mailto:[email-masked]>
>> 
> 

Mahesh Jethanandani
[email-masked]

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Sat, 31 Mar 2018 21:08:13 +0000

Hi, Manesh,

Top posting - this is close enough for Last Call of your next version.

Thanks for the quick responses.

Spencer

On Sat, Mar 31, 2018, 11:14 Mahesh Jethanandani <[email-masked]>
wrote:

> doing things that cost money and don't make sense. But would it be correct
> to say this?
>
>    From an operations
> of this draft as an RFC?
> Editor. If there's only two, you could put this note in Section 5.2, which
> they'd likely appreciate.
>
> We can do that.
>
>
> It is the latter. Would it help if we actually put a "\" character at the
> end of the line to indicate a line break?
>
>
> There isn't a conventions currently. But I have used the "\" character in
> some of the other models that I have authored.
>
>
> was understated - when are writeable nodes not "sensitive and vulnerable
> to attacks" without "proper protection"? I see
>
> a bit further up the page, but would it make sense to prohibit the use of
> a protocol that doesn't have a mandatory-to-implement secure transport
> Considerations, and this was the language we seem to have agreed upon and
> documented in rfc6087bis. That is not to say that they might not still call
> it into question.
>
> Cheers.
>
> Mahesh Jethanandani
> [email-masked]
>
>
>
> Mahesh Jethanandani
> [email-masked]
>
>