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

Benoit Claise <[email protected]> Fri, 09 May 2014 17:40:38 -0500
Newsgroups gmane.ietf.ipfix
Message-ID <[email protected]>
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

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