Elwyn,
Hi Colin and Paul.
Thanks for your responses. I think -10 clears up most of the points
below. There is one point and a query that don't seem to be addressed:
s5.4.2, last para and Figure 5: It would be helpful to remind people
that the
value 0xffff/65535 indicates variable length encoding per RFC 7011
Section
3.2 and that the RECOMMENDED use of variable length encoding for
mibObjectIdentifier fields is indicated in subsequent figures by
placing 65535
in the relevant length fields. ******Presumably Collector
implementations MUST
accept a specific length encoding in the usual IETF spirit! It might
be worth
being explicit about this (this might usefully be said in Section
8).******
PJ: done.
Thoughts on an addendum to s8?
Collectors must accept both fixed and variable length per the MUST in
section 7 of RFC 7011.
I didn't see a need to re-state that here, though there's no harm in
doing so.See the suggested text below.
s5.7.2: is there any need to explain how withdrawal is achieved? I am
not an
IPFIX expert so I am not aware how the withdrawal might be achieved.
Does this need to be explained or a reference added?
It's explained in section 8.1 of RFC 7011 (IPFIX Protocol
Specification). I think it would be reasonable to expect that
implementers should already be familiar with that.
Again, there's no need and no harm in adding a note. See the suggested
text below.
Please let us know whether you're happy with these additions, and
whether you'd like to see a -11 or are happy for them to be inserted in
the AUTH48.
Suggested texts:
5.7.2 Template Withdrawal and Reuse
IPFIX Template Withdrawal is discussed in Section 8.1 of RFC 7011.
Data Records containing mibObjectValue Information Elements MUST NOT
be exported if their corresponding Data Template or MIB Field Options
Template has been withdrawn, since the MIB Field Options Template
MUST be exported in the same IPFIX Message as the Data Template which
it annotates, except as allowed by the caveat ofSection 5.7.1
<https://tools.ietf.org/html/draft-ietf-ipfix-mib-variable-export-10#section-5.7.1>.
MIB Field Options Template IDs MUST NOT bewithdrawn or reused while they are
required by any existing Data Templates.
(Alternatively, the new paragraph could be added to the end of the
section instead.)
8. The Collecting Process's Side
The specifications insection 9 of [RFC7011]
<https://tools.ietf.org/html/rfc7011#section-9> also apply to Collectors
that implement this specification. In addition, the following
specifications should be noted.
A Collecting Process that implements this specification MUST store
the data records containing the OID Object Type Definitions with the
same retention policy as templates.
A Collecting Process that implements this specification SHOULD have
access to MIB modules in order to look up the received MIB Object
Identifiers and find the full type definition and name of MIB OID
fields used in received templates.
It should be noted that since reduced size encoding MAY be used by
the Exporting Process, the Collecting Process cannot assume a
received size for a field is the maximum size it should expect for
that field.
SincemibObjectIdentifier fields may be exported using variable length
mibObjectIdentifier fields, the Collecting Process MUST support
Variable-Length Information Element encoding per Section 7 of RFC 7011.
If a Collecting Process receives a MIB Object Identifier that it
cannot decode, it MAY log a warning.
A Collecting Process MUST support the 3 options for handling columnar
objects detailed inSection 5.8
<https://tools.ietf.org/html/draft-ietf-ipfix-mib-variable-export-10#section-5.8>.
P.
_______________________________________________
Gen-art mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/gen-art
