[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