Subject: [IPFIX] AD review: draft-trammell-ipfix-text-adt

From: Benoit Claise <[email-masked]>
Date: Fri, 09 May 2014 17:40:38 -0500

Brian,

Below is my AD review

-
   However, present and future operations and management protocols and
    applications may use textual encodings, and generic framing and
    structure as in JSON or XML.

Please add references

-
  A definition of canonical textual
    encodings for the IPFIX abstract data types would allow this set of
    Information Elements to be used for such applications, and for these
    applications to interoperate with IPFIX applications at the
    Information Element definition level.

    Note that templating or other mechanisms for data description for
    _such applications and protocols_  are application specific, and
    therefore out of scope for this document: only Information Element
    identification and data value representation are defined here.

"such applications" don't refer to IPFIX applications from the previous paragraph

-

Note that templating or other mechanisms for data description for
    such applications and protocols are application specific, and
    therefore out of scope for this document:_only Information Element
    identification and data value representation are defined here.
_

and

  Enclosing Context
       Textual representation of IPFIX data values is applied to use the
       IPFIX Information Model within some existing textual format (e.g.
       XML, JSON).  This outer format is referred to as the Enclosing
       Context within this document.  Enclosing Contexts define escaping
       and quoting rules for represented data values.

what is "data value"? It should be Information Element value

-  Leading zeroes are allowed in any either encoding, and do not signify
    base-8 (octal) encoding.  Binary encoding is intended for use with
    Information Elements with flag semantics, but can be used in any
    case.

I guess you mean the "binary representation of unsigned"

  - Why should and not must?
    Instead, applications using textual representations of Information
    Elements should use Information Element names to identify them; see
    Appendix A for examples illustrating this principle.

- btw, I found the RFC 2119 keywords in http://tools.ietf.org/id/draft-trammell-ipfix-text-adt-03.txt more appropriate, so that implementations could be compliant with this future RFC.
However, I could live with that. Let's see what the other ADs will say.

-

Otherwise, the values of Information Elements of signed integer types
    should be represented as optionally-prefixed base-10 (decimal)
    strings.

should be -> must?
You are not consistent in the 4.X sections. For example, in 4.4:

        Otherwise, the values of Information Elements of float32 or float64
        types_are represented_  as an optionally sign-prefixed, optionally
        base-10 exponent-suffixed, floating point decimal number.

-
    If the Enclosing Context defines a representation for binary objects,
    that representation should be used.

The should is weird. If it's a should, you should specify the exception(s).
Otherwise, it's a must.
Anyway, you had to make it clear when someone is compliant with this spec.
Btw, why do you always need this sentence in 4.x?

-
I don't think it's appropriate to have [iana-ipfix-assignments] as a normative reference.
In RFC7011 and RFC7012, it is informative

- If figure 2 is the IPFIX Message, it should follow the same format as the RFC 7011 appendix examples.
Then people will be able to compare.
  
- change "Figure 2: IPFIX message containing sample flow" to "Figure 2: IPFIX Message containing sample Flow Records
change
    "A Message containing this Template and a Data Record
    is shown in Figure 2"
to
    "An IPFIX Message containing this Template and a Data Record
    is shown in Figure 2"

-
OLD:
    A Message containing this Template and a Data Record
    is shown in Figure 2, and a corresponding JSON Object using the text
    format defined in this document is shown in Figure 3.

NEW:

    An_IPFIX_Message containing this Template and a Data Record
    is shown in Figure 2, and a corresponding JSON Object using the text
    format defined in this document is shown in Figure 3.

Regards, Benoit

---

From: Benoit Claise <[email-masked]>
Date: Wed, 14 May 2014 10:03:41 -0700

Hi Brian,

Thanks for the new version 5 of the draft.

One small editorial point.
You correctly mention the references "XML [W3C-XML], JSON [RFC4627])" 
later in the text, but forgot the XML reference in the intro. See "JSON 
[RFC4627] or XML".
Please correct that in your temp version.

The draft is now sent to the IETF LC.

Regards, Benoit
> - btw, I found the RFC 2119 keywords inhttp://tools.ietf.org/id/draft-trammell-ipfix-text-adt-03.txt  more appropriate, so that implementations could be compliant with this future RFC.
> _______________________________________________
> IPFIX mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ipfix

---

From: Brian Trammell <[email-masked]>
Date: Thu, 15 May 2014 11:42:05 +0200

hi Benoit,

On 14 May 2014, at 19:03, Benoit Claise <[email-masked]> wrote:

> You correctly mention the references "XML [W3C-XML], JSON [RFC4627])" later in the text, but forgot the XML reference in the intro. See "JSON [RFC4627] or XML".

Oops, thanks for the catch.

> Please correct that in your temp version.

Already done.

> The draft is now sent to the IETF LC.

Thanks, cheers,

Brian

>>    types are represented as an optionally sign-prefixed, optionally
>>    An IPFIX Message containing this Template and a Data Record