Subject: Re: [ippm] Review of the YANG data model in draft-ietf-ippm-twamp-yang-01

From: Kostas Pentikousis <[email-masked]>
Date: Wed, 22 Feb 2017 17:48:48 +0100 (CET)

Dear Marius, 

Many thanks for your review, and my sincere apologies for the delay. 

We took all comments into consideration as we worked in two steps (-02 and -03) to update the document. I believe we have addressed all points below. If you could spare the time, please kindly review the updated version (https://www.ietf.org/id/draft-ietf-ippm-twamp-yang-03.txt) and let us know if we can improve the draft further. 

Best regards, 

Kostas 

| From: "Marius Georgescu" <[email-masked]>
| To: "ippm" <[email-masked]>
| Sent: Monday, August 29, 2016 5:56:06 AM
| Subject: [ippm] Review of the YANG data model in draft-ietf-ippm-twamp-yang-01

| Hello IPPM,

| Following the promise I made in IETF96, this is my review of the YANG data model
| in [ https://tools.ietf.org/html/draft-ietf-ippm-twamp-yang-01 |
| https://tools.ietf.org/html/draft-ietf-ippm-twamp-yang-01 ] .
| As a disclaimer, I have to note that I am quite new to both TWAMP and YANG.
| Nevertheless, here are some comments that might be relevant:

| -1-
| typedef twamp-modes {
|       type bits {
|         bit unauthenticated {
|           position 0;
|           description
|              "Unauthenticated mode. See [ https://tools.ietf.org/html/rfc7717#section-7 | RFC
|               7717 Section 7 ] .";
|         }
| The description refers to RFC7717 Section 7, which in turn refers to RFC4656
| Section 3.4 . I was wondering if a short description wouldn’t be more
| disambiguating.
| The comment applies for the authenticated and encrypted modes as well.

| -2-

| leaf max-count {
|             type uint32 {
|               range 1024..4294967295;
|             }
|             default 32768;
|             description
|               "This parameter limits the maximum Count value.

|               If an attacking system sets the maximum value in
|               Count (2**32), then the system under attack would stall
|               for a significant period of time while it attempts to
|               generate keys.";
|           }

| I was wondering what a “significant amount of time” means, or if any reference
| value should be given.

| -3-

| leaf server-start-time {
|             type uint64;
|             config false;
|             description
|               "The Start-Time advertized by the Server in the
|              Server-Start message ( [ https://tools.ietf.org/html/rfc4656#section-3.1 | RFC
|               4656, Section 3.1 ] ). This is
|               a timestamp representing the time when the current
| instantiation of the Server started operating.";
|           }

| Maybe a time format would help. I think the same applies for leaf start-time {

| -4-
| leaf max-interval {
|                 type uint32;
|                 description
|                   "Indicates the maximum time between packet
|                   transmissions.";
| }
| Maybe a time unit should be mentioned.

| -5-
| <client-ip>203.0.113.1</client-ip>
|                <server-ip>203.0.113.2</server-ip>
|                <test-session-request>
|                   <name>Test1</name>
|                   <sender-ip>10.1.1.1</sender-ip>

| While the client/server IPs are using the RFC5737 documentation class, I was
| wondering why the sender-IP is not.
| Considering it is a private class, I am assuming a NAT box is considered along
| the path. If that’s the case, maybe it should be specified.

| Best regards,
| Marius Georgescu