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

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
> 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 inhttp://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

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