Subject: [IPFIX] Last Call: <draft-ietf-ipfix-text-adt-07.txt> (Textual Representation of IPFIX Abstract Data Types) to Proposed Standard

From: The IESG <[email-masked]>
Date: Wed, 16 Jul 2014 15:24:27 -0700

The IESG has received a request from the IP Flow Information Export WG
(ipfix) to consider the following document:
- 'Textual Representation of IPFIX Abstract Data Types'
  <draft-ietf-ipfix-text-adt-07.txt>

During the IESG telechat, the IESG concluded that this document should be 
Proposed Standard, and not Informational as initially proposed in v6.
This IETF LC should focus on the Proposed Standard changes in the 
latest version. 

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
[email-masked] mailing lists by 2014-07-30. Exceptionally, comments may be
sent to [email-masked] instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract

   This document defines UTF-8 representations for IPFIX abstract data
   types, to support interoperable usage of the IPFIX Information
   Elements with protocols based on textual encodings.

The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-ipfix-text-adt/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-ipfix-text-adt/ballot/

No IPR declarations have been submitted directly on this I-D.

---

From: Benoit Claise <[email-masked]>
Date: Thu, 17 Jul 2014 00:33:47 +0200

Dear IPFIX WG,

In the text below, I explain the reason behind the second IETF LC:

Regards, Benoit

-------- Original Message --------
Subject: 	[IPFIX] Last Call: <draft-ietf-ipfix-text-adt-07.txt> (Textual 
Representation of IPFIX Abstract Data Types) to Proposed Standard
Date: 	Wed, 16 Jul 2014 15:24:27 -0700
From: 	The IESG <[email-masked]>
Reply-To: 	<[email-masked]>
To: 	IETF-Announce <[email-masked]>
CC: 	<[email-masked]>

Abstract

_______________________________________________
IPFIX mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ipfix
.

---

From: Paul Aitken <[email-masked]>
Date: Thu, 17 Jul 2014 15:05:08 +0100

Benoit, Brian, All,

4.  Data Type Encodings

    Each subsection of this section defines a textual encoding for the
    abstract data types defined in [RFC7012].

Is 7012 the correct reference? Isn't IANA's IPFIX registry now 
understood to be the master reference?
(ie, 
http://www.iana.org/assignments/ipfix/ipfix.xhtml#ipfix-information-element-data-types)

With a view to extensibility, this document doesn't say what to do 
if/when new data types are added to IANA (eg, see 
ietf-ipfix-mib-variable-export).
eg even one line to say that they can be represented in a default or 
limited way, or that they cannot be represented at all -  in which case, 
how should the representation be extended in future, if needs be?

Appendix A / Figure 1:

While Figure 1 in this draft initially seems identical to Figure 1 in 
section10.2 of 7013, there are some important differences between them:

7013:

	 sourceIPv4Address(8)<ipv4Address>[4]{key}
	 destinationIPv4Address(12)<ipv4Address>[4]{key}

Figure 1:

          sourceIPv6Address(27)<ipv4Address>[4]{key}
          destinationIPv6Address(28)<ipv4Address>[4]{key}
	 ...
          tcpControlBits(6)<unsigned8>[1]
          flowEndReason(136)<unsigned8>[1]

This has been wrong since -00 :

          sourceIPv6Address(27)<ipv4Address>[4]{key}
          destinationIPv6Address(28)<ipv4Address>[4]{key}

(Figure 2 shows a length of 16 for these, so presumably s/v4/v6/ and 
s/[4]/[16]/ in the above definitions.)

And tcpControlBits:

          tcpControlBits(6)<unsigned8>[1]

- has been revised to unsigned16 [RFC7125]. Changing this would also 
make Figure 2 align more neatly.

Figure 3: it's not clear how the strings for the timestamp, IPv6 
address, and protocol identifier fields get mapped to the corresponding 
dateTimeMilliseconds, ipv6address, and unsigned8 types shown in Figures 
1 and 2. eg, conversion is required between "tcp" and 6, so the draft 
should mention that.

P.

On 16/07/2014 23:33, Benoit Claise wrote:
> Subject: 	[IPFIX] Last Call: <draft-ietf-ipfix-text-adt-07.txt> 
> (Textual Representation of IPFIX Abstract Data Types) to Proposed 
> Standard
> sent [email-masked]  instead. In either case, please retain the

---

From: Brian Trammell <[email-masked]>
Date: Thu, 17 Jul 2014 16:40:13 +0200

hi Paul,

thanks for the comments/review. Commentcomments inline:

On 17 Jul 2014, at 16:05, Paul Aitken <[email-masked]> wrote:

> Is 7012 the correct reference? Isn't IANA's IPFIX registry now understood to be the master reference?
> (ie, http://www.iana.org/assignments/ipfix/ipfix.xhtml#ipfix-information-element-data-types)

For IEs, yes. This is a reference to the abstract data types defined in section 3.1 of RFC 7012, not the Information Element definitions.

> With a view to extensibility, this document doesn't say what to do if/when new data types are added to IANA (eg, see ietf-ipfix-mib-variable-export).
> eg even one line to say that they can be represented in a default or limited way, or that they cannot be represented at all -  in which case, how should the representation be extended in future, if needs be?

I presume that this would have to be done by a future draft that updates this RFC, referencing a draft that updates Section 3.1 of RFC 7012, but we can say so explicitly.

Note that every ADT that's been added or considered since RFC 5102 has been more or less a hack that only makes sense within the binary encoding, and as such doesn't need a text representation. The RFC 6313 ADTs are only interesting in the context of the RFC 7101 encoding of the ADTs, and are explicitly noted as such in section 4.11.

mib-variable-export is a more interesting case, but I don't think it really applies here. The point of this work is to allow interoperability for textual representations of values for Information Elements taken from the IPFIX Information Element registry. The point of mib-variable-export is to allow IPFIX (or rather, the binary encoding of records defined in RFC 7011, to which the representation is quite tightly bound) to export Information Elements in a _different_ type space. And most probably, the right way to do that would be to directly define textual representations for MIB data directly (which I presume already exist; I'm not by any stretch of the imagination an SNMP geek.) 

> Appendix A / Figure 1:
> 
> While Figure 1 in this draft initially seems identical to Figure 1 in section10.2 of 7013, there are some important differences between them:
> 
> 7013:
> (Figure 2 shows a length of 16 for these, so presumably s/v4/v6/ and s/[4]/[16]/ in the above definitions.)

Yep, thanks for the catch.

> - has been revised to unsigned16 [RFC7125]. Changing this would also make Figure 2 align more neatly.

It'll probably still be exported as 1 byte everywhere, but the type is indeed unsigned16

> Figure 3: it's not clear how the strings for the timestamp, IPv6 address, and protocol identifier fields get mapped to the corresponding dateTimeMilliseconds, ipv6address, and unsigned8 types shown in Figures 1 and 2. eg, conversion is required between "tcp" and 6, so the draft should mention that.

It does:  section 4.2, paragraph 2:

   In the special case that the unsigned Information Element has
   identifier semantics, and refers to a set of codepoints, either in an
   external registry, a sub-registry, or directly in the description of
   the Information Element, then the name or short description for that
   codepoint as a string MAY be used to improve readability.

Thanks, cheers,

Brian

>> Subject:	[IPFIX] Last Call: <draft-ietf-ipfix-text-adt-07.txt> (Textual Representation of IPFIX Abstract Data Types) to Proposed Standard
>> [email-masked]
>>  mailing lists by 2014-07-30. Exceptionally, comments may be
>> sent to 
>> [email-masked]
>>  instead. In either case, please retain the

---

From: Paul Aitken <[email-masked]>
Date: Thu, 17 Jul 2014 16:59:16 +0100

Brian, please see inline.

> For IEs, yes. This is a reference to the abstract data types defined in section 3.1 of RFC 7012, not the Information Element definitions.

Sure, the definitions are irrelevant here. Notice that I linked the IE 
*data types* registry.

> mib-variable-export is a more interesting case, but I don't think it really applies here. The point of this work is to allow interoperability for textual representations of values for Information E…

My point wasn't about MIBs per se; rather, about adding new data types. 
But brain-fart, the mib-export draft adds new semantics (not types) - so 
it's not a super example. However the point stands: mention 
extensibility at least briefly.

Thanks,
P.

---

From: Brian Trammell <[email-masked]>
Date: Thu, 17 Jul 2014 22:16:04 +0200

On 17 Jul 2014, at 17:59, Paul Aitken <[email-masked]> wrote:

> Sure, the definitions are irrelevant here. Notice that I linked the IE *data types* registry.

Section 3.1 of RFC 7012 is still normative for the data types. At least I can't find anything in 7012 that suggests otherwise.

> My point wasn't about MIBs per se; rather, about adding new data types.

Yep, point taken.

> But brain-fart, the mib-export draft adds new semantics (not types) - so it's not a super example. However the point stands: mention extensibility at least briefly.

Absolutely, will do.

Thanks, cheers,

Brian