Re: [Gen-art] Gen-art Last Call/Telechat Review of draft-ietf-ipfix-mib-variable-export-09

[Paul Aitken <[e-mail]>]

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.