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

[Elwyn Davies <[e-mail]>]

Hi.

Thanks for the response.

I think that the suggested text for s5.7.2 is fine.

To be clear, on s5.4.2 and s8, the point I was trying to get across is 
that the variable length encoding is a MAY/RECOMMENDED. Accordingly 
agents can alternatively use a fixed length encoding.  I was suggesting 
that it would probably be worth mentioning in s8 that the collector MUST 
be prepared to accept the fixed length encoding as well as variable 
length encoding.  Possibly this is the default situation (I am not 
familiar with the innards of IPFIX) but I thought collector implementers 
needed to be reminded of the need to support fixed length encoding as 
well as variable length encoding for the relevant fields so that they 
are liberal in what they accept!

I have no problem with -11 or AUTH48 as long as the text gets in. 
Depends if you have sent it to the RFC Editor already I guess.

Cheers,
Elwyn

On 30/11/2015 20:59, Paul Aitken wrote:
> 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.
>  Since mibObjectIdentifier 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.
>