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: Lutz Mark <[email-masked]>
Date: Mon, 19 Mar 2007 17:49:41 +0100

>  > from the protocol draft that the collector cannot expect any specific

yes, that's a common mistake.
I know this from feedback we've got from
developers using our IPFIX library.

> Any objections to remove this section?

I'd prefer to keep the text.

Best regards,
Lutz

---

From: Lutz Mark <[email-masked]>
Date: Mon, 19 Mar 2007 17:49:41 +0100

Best regards,
Lutz

---

From: Paul Aitken <[email-masked]>
Date: Mon, 19 Mar 2007 17:08:59 +0000

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.

-- 
Paul Aitken
Cisco Systems Ltd, Edinburgh, Scotland.

---

From: Paul Aitken <[email-masked]>
Date: Mon, 19 Mar 2007 17:08:59 +0000

Elisa,

Cheers,
P.

---

From: Gerhard Muenz <[email-masked]>
Date: Mon, 19 Mar 2007 18:52:32 +0100

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.

Feel free to further improve this.

Regards,
Gerhard

-- 
Dipl.-Ing. Gerhard Münz
Computer Networks and Internet
Wilhelm Schickard Institute for Computer Science
University of Tuebingen
Sand 13 (Room B309), D-72076 Tuebingen, Germany
Phone:  +49 7071 29-70534       Fax: +49 7071 29-5220
E-mail: [email-masked]
WWW:    http://net.informatik.uni-tuebingen.de/~muenz
_______________________________________________
IPFIX mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ipfix

---

From: Gerhard Muenz <[email-masked]>
Date: Mon, 19 Mar 2007 18:52:32 +0100

Elisa, Paul, Lutz,

Maybe write like this:

Regards,
Gerhard

---

From: Paul Aitken <[email-masked]>
Date: Mon, 19 Mar 2007 18:02:08 +0000

Elisa, Gerhard,

> insert some padding octets to align Data Sets within a Message.

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"?

> "Information Element numbers in IPFIX have the range 0-32767. 

This may be more clearly expressed in hex, eg "0-32767 (0 - 0x7FFF).

> 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.

---

From: Paul Aitken <[email-masked]>
Date: Mon, 19 Mar 2007 18:02:08 +0000

Elisa, Gerhard,