On 17 Jul 2014, at 17:59, Paul Aitken <paitken(_at_)cisco(_dot_)com> wrote:
Brian, please see inline.
On 17/07/2014 15:40, Brian Trammell wrote:
hi Paul,
thanks for the comments/review. Commentcomments inline:
On 17 Jul 2014, at 16:05, Paul Aitken <paitken(_at_)cisco(_dot_)com> wrote:
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)
For IEs, yes. This is a reference to the abstract data types defined in
section 3.1 of RFC 7012, not the Information Element definitions.
Sure, the definitions are irrelevant here. Notice that I linked the IE *data
types* registry.
Section 3.1 of RFC 7012 is still normative for the data types. At least I can't
find anything in 7012 that suggests otherwise.
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?
I presume that this would have to be done by a future draft that updates
this RFC, referencing a draft that updates Section 3.1 of RFC 7012, but we
can say so explicitly.
Note that every ADT that's been added or considered since RFC 5102 has been
more or less a hack that only makes sense within the binary encoding, and as
such doesn't need a text representation. The RFC 6313 ADTs are only
interesting in the context of the RFC 7101 encoding of the ADTs, and are
explicitly noted as such in section 4.11.
mib-variable-export is a more interesting case, but I don't think it really
applies here. The point of this work is to allow interoperability for
textual representations of values for Information Elements taken from the
IPFIX Information Element registry. The point of mib-variable-export is to
allow IPFIX (or rather, the binary encoding of records defined in RFC 7011,
to which the representation is quite tightly bound) to export Information
Elements in a _different_ type space. And most probably, the right way to do
that would be to directly define textual representations for MIB data
directly (which I presume already exist; I'm not by any stretch of the
imagination an SNMP geek.)
My point wasn't about MIBs per se; rather, about adding new data types.
Yep, point taken.
But brain-fart, the mib-export draft adds new semantics (not types) - so it's
not a super example. However the point stands: mention extensibility at least
briefly.
Absolutely, will do.
Thanks, cheers,
Brian
signature.asc
Description: Message signed with OpenPGP using GPGMail