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

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:
> Dear IPFIX WG,
>
> In the text below, I explain the reason behind the second IETF LC:
>
>     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.
>
>
> 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 <iesg-secretary@ietf.org>
> Reply-To: 	<ietf@ietf.org>
> To: 	IETF-Announce <ietf-announce@ietf.org>
> CC: 	<ipfix@ietf.org>
>
>
>
> 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
> ietf@ietf.org  mailing lists by 2014-07-30. Exceptionally, comments may be
> sent toiesg@ietf.org  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.
>
>
> _______________________________________________
> IPFIX mailing list
> IPFIX@ietf.org
> https://www.ietf.org/mailman/listinfo/ipfix
> .
>
>
>
>
>
> _______________________________________________
> IPFIX mailing list
> IPFIX@ietf.org
> https://www.ietf.org/mailman/listinfo/ipfix