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

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

Paul,

>>  >
>>  > 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.
> 
> 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"?
 
> 
>>  > 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. 
> 
> 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:
>>  >    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?
> 
> Per my earlier mail, yes, I object. Please keep this note.
> 

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

Thanks,
Elisa

_______________________________________________
IPFIX mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ipfix

---

From: Paul Aitken <[email-masked]>
Date: Mon, 19 Mar 2007 22:06:37 +0000

Elisa,

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

OK. At least it's clearly different from "paddingOctets".

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

---

From: Paul Aitken <[email-masked]>
Date: Mon, 19 Mar 2007 22:06:37 +0000

Elisa,