Subject: [ippm] I-D Action: draft-ietf-ippm-twamp-yang-10.txt

From: [email-masked]
Date: Thu, 03 May 2018 10:37:31 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the IP Performance Measurement WG of the IETF.

        Title           : Two-Way Active Measurement Protocol (TWAMP) Data Model
        Authors         : Ruth Civil
                          Al Morton
                          Reshad Rahman
                          Mahesh Jethanandani
                          Kostas Pentikousis
	Filename        : draft-ietf-ippm-twamp-yang-10.txt
	Pages           : 68
	Date            : 2018-05-03

Abstract:
   This document specifies a data model for client and server
   implementations of the Two-Way Active Measurement Protocol (TWAMP).
   The document defines the TWAMP data model through Unified Modeling
   Language (UML) class diagrams and formally specifies it using YANG.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-ippm-twamp-yang/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-ippm-twamp-yang-10
https://datatracker.ietf.org/doc/html/draft-ietf-ippm-twamp-yang-10

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-ippm-twamp-yang-10

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Mahesh Jethanandani <[email-masked]>
Date: Thu, 3 May 2018 10:40:34 -0700

This version of the draft address comments from SecDir and Tom Petch. We believe, we have addressed all outstanding comments on the draft.

Thanks.

> On May 3, 2018, at 10:37 AM, [email-masked] wrote:
> 
> 
> _______________________________________________
> ippm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ippm

Mahesh Jethanandani
[email-masked]

---

From: "t.petch" <[email-masked]>
Date: Fri, 4 May 2018 12:12:27 +0100

Right

One sentence that has remained unchanged is
"The secret-key is the shared secret, an octet
   string of arbitrary length whose interpretation as a text string is
   unspecified. "
and I do not know what that is telling me when it tells me that that is
an octet string although it does answer a question that I might have had
about the key length.  I see octets as a user-friendly way of
representing binary, except that here that is not used so I remain
uncertain.  .

Tom Petch

----- Original Message -----
From: "Mahesh Jethanandani" <[email-masked]>
To: <[email-masked]>
Sent: Thursday, May 03, 2018 6:40 PM

> This version of the draft address comments from SecDir and Tom Petch.
We believe, we have addressed all outstanding comments on the draft.

---

From: Fred Baker <[email-masked]>
Date: Fri, 4 May 2018 08:01:50 -0400

> On May 4, 2018, at 7:12 AM, t.petch <[email-masked]> wrote:
> 
> I do not know what that is telling me when it tells me that that is
> about the key length.

I would imagine it tells you the format in which it is stored. If this were an SNMP document, it would tell you that it was an ASN.1 OCTET STRING, which is pretty general about what it contains, but very specific about the container. I have to believe the same here.

---

From: [email-masked] (Dale R. Worley)
Date: Fri, 04 May 2018 22:45:14 -0400

> representing binary, except that here that is not used so I remain

OK... being totally naive about this document (which may place me well
as a generic reader), I take it to mean that the universe of secret-keys
is one-to-one with the set of octet strings.  In particular, I can
choose any octet string and use it as a secret-key.  Conversely, strings
of bits whose length is not a multiple of 8 are not allowed.  It also
suggests that some uses or users might choose to interpret a secret-key
as a representation of a text string or limit the secret-keys that they
use to ones that represent text strings, but that the document
prescribes no particular way to do that, and secret-keys are not limited
to octet strings that can be interpreted as text strings.

Dale

---

From: "t.petch" <[email-masked]>
Date: Sat, 5 May 2018 12:31:09 +0100

----- Original Message -----
From: "Dale R. Worley" <[email-masked]>
Sent: Saturday, May 05, 2018 3:45 AM

> to octet strings that can be interpreted as text strings.

Sorry if I was not specific enough - it is the use of 'string' that
gives me pause.  The data type is binary, in YANG, and that is described
in RFC7950 as a 'a sequence of octets.' so if this I-D used sequence
instead of string I would be content.  It is the use of string that, for
me, brings in images of characters, Unicode and such like which I think
are not intended.

Tom Petch