Subject: Re: [IPFIX] WG Last Call for Implementation Guidelines starts today

From: "Boschi, Elisa" <[email-masked]>
Date: Mon, 19 Mar 2007 14:54:44 -0000

Hi Gerhard,

this addresses the rest of your comments:

> 
> 10.2:
>    [I-D.ietf-ipfix-protocol] specifies that the Exporting Process MAY
>    insert some padding octets to align Information Elements within a
>    Data Record.  The padding length MUST be shorter than any allowable
>    Record in that set.
> 
> Mistake! The padding octets are used to align the next Set, not the
> Information Elements.
>

right, the sentence should be:
[I-D.ietf-ipfix-protocol] specifies that the Exporting Process MAY
insert some padding octets to align Data Sets within a Message.
 
> 
> 10.3:
>    ... There is no way to tell that this is wrong,
>    if it wasn't meant as an enterprise-specific Information Element.
> 
> So what should the implementer do to prevent this?
>

we've rewritten this section for more clarity:

"Information Element numbers in IPFIX have the range 0-32767. Information Element numbers outside this range (i.e., with the high bit set) are taken to be enterprise-specific Information Elements, which have an additional four-byte Private Enterprise Number following the Information Element number and length. Inadvertently setting the high bit of the Information Element number by selecting a number out of this range will therefore cause template scanning errors."
 
> 
> 10.4:
>    Template IDs are generated as required by the Exporting Process.
>    ...  The collecting process
>    does not know in advance which Template ID a particular Template will
>    use.
> 
> Is this really a common implementation mistake? I think it is very clear
> from the protocol draft that the collector cannot expect any specific
> Template IDs.
> 

Any objections to remove this section?

thanks,
Elisa

> 
> Best regards,
> Gerhard
> 
> 
> On Wed, February 28, 2007 9:42 pm, Nevil Brownlee said:
>> Hi All:
>>
>> The 'IPFIX Implementations Guidelines' draft (-02) is now ready
>> for WG last call, so we'll start that today.  It will end on Saturday,
>> 17 March, just before the Prague IETF meeting.
>>
>> Cheers, Nevil
>>
>> -----------------------------------------------------------------------
>>   Nevil Brownlee                    Computer Science Department | ITS
>>   Phone: +64 9 373 7599 x88941             The University of Auckland
>>   FAX: +64 9 373 7453   Private Bag 92019, Auckland 1142, New Zealand
>>
>> -----------------------------------------------------------------------
>> This mail sent through University of Auckland http://www.auckland.ac.nz
>>
>>
>> _______________________________________________
>> IPFIX mailing list
>> [email-masked]
>> https://www1.ietf.org/mailman/listinfo/ipfix
>>
> 
> 
_______________________________________________
IPFIX mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ipfix

---

From: "Boschi, Elisa" <[email-masked]>
Date: Mon, 19 Mar 2007 18:39:40 -0000

Gerhard, Paul, Lutz,

there seem to be consensus that the text will not be removed from the Guidelines.

Gerhard Muenz wrote:
> Elisa, Paul, Lutz,
> 
> Ok, section 10.4 might be useful for people who are used to older
> Netflow versions like Netflow.v5 where no Templates existed. But if you
> keep the paragraph, consider rewriting the following sentence:
> 
>    When exporting Templates composed by the same set of Information
>    Elements at different times or using Templates composed by the same
>    set of Information Elements multiple times simultaneously, different
>    Template IDs are generated for each Template.
> 
> One can understand it, if she knows what you want to say. However, from
> "...different Template IDs are generated for each Template" your issue
> does not become clear since you always use different Template IDs if you
> have more than one Template. Also, the exporter might use the same
> Template ID - by accident or on purpose!
> 
> Maybe write like this:
> 
>    When the same set of Information Elements is exported at different
>    times, the corresponding Template is usually announced with different
>    Template IDs. Similarly, if multiple co-existing Templates are
>    composed of the same set of Information Elements, they are also
>    identified by different Template IDs.

Good suggestion. I only propose to change "the corresponding Template is usually announced with different Template IDs" with "the corresponding Template is usually identified by different Template IDs"

Thanks,
Elisa

> Feel free to further improve this.
> 
> Regards,
> Gerhard
> 
> 
> Paul Aitken wrote:
>> Elisa,
>>
>> I agree with Lutz to keep this note.
>>
>> Developers may design their system so that the same Template IDs are
>> always allocated to certain templates. That's not a problem.
>>
>> But then they may be tempted to optimise in some ways:
>>
>> eg, by not exporting templates at all, since the Collector can be
>> pre-programmed with the necessary Templates. This would work OK if the
>> Exporter and Collector were in a closed system, but obviously would not
>> work with third party collectors.
>>
>> Or, by supposing that certain Template IDs mean certain templates (so,
>> simply disregarding the received templates). Again, this might work for
>> a closed Exporter / Collector pair, but is a very bad design.
>>
>> We should point out that any such design is unacceptable, and the
>> Collector cannot and should not know in advance what each template may be.
>>
>> Cheers,
>> P.
>>
>> Lutz Mark wrote:
>>>>  > 10.4:
>>> yes, that's a common mistake.
>>> I know this from feedback we've got from
>>> developers using our IPFIX library.
>>>
>>> I'd prefer to keep the text.
>>>
>>> Best regards,
>>> Lutz
>>>
>>>

---

From: "Boschi, Elisa" <[email-masked]>
Date: Mon, 19 Mar 2007 18:39:40 -0000

Gerhard, Paul, Lutz,

Thanks,
Elisa

---

From: "Boschi, Elisa" <[email-masked]>
Date: Mon, 19 Mar 2007 18:42:03 -0000

Paul,

> This revision makes no sense to me because it confuses the paddingOctets 
> Information Element with some additional padding which has no name.
> 
> ie, if we want to align some records, then we put the paddingOctets 
> Information Element in each record to make a suitable length.
> 
> But if we want to align some data sets, then you do not use 
> paddingOctets. Instead, you increase the length in the set header, and 
> include a few extra octets and the end of the Set.
> 
> These have no name, and we should not call them "padding octets" because 
> that is very close to "paddingOctets". Instead, we may refer to them as 
> "octets of padding"?
>

what about "octets for set padding"?
 
>> "Information Element numbers in IPFIX have the range 0-32767. 
> 
> This may be more clearly expressed in hex, eg "0-32767 (0 - 0x7FFF).
>

ok, added

> 
>> Information Element numbers outside this range (i.e., with the high 
>> bit set) are taken to be enterprise-specific Information Elements, 
>> which have an additional four-byte Private Enterprise Number following 
>> the Information Element number and length. Inadvertently setting the 
>> high bit of the Information Element number by selecting a number out 
>> of this range will therefore cause template scanning errors."
>>
>>  >
>>  > 10.4:
> Per my earlier mail, yes, I object. Please keep this note.
> 

Per my earlier email, ok. We'll keep the section.

Thanks,
Elisa