Re: [IPFIX] WG Last Call for draft-ietf-ipfix-information-model-rfc5101bis-03.txt

Dear all,

I had a look at the differences between RFC5101 and the RFC5101bis draft 
(not at the unchanged parts). The changes in RFC5101bis make things much 
clearer.

As we see in Paul's review, there are many more smaller issues that need 
to be improved and those parts of the RFC which have not yet been 
touched. All in all, I agree with Paul's comments and with the comments 
made by the other reviewers.

Here are some additional comments:

There are occurrences of "template ID" and "template", but I think it 
should be "Template ID" and "Template" all over the place.
I suggest that you check the writing of all the other IPFIX terms as well.

In 4.1 and 4.2, it is unclear whether meteringProcessId is a mandatory 
or optional scope field. If it is mandatory (I don't think that it 
should be!), the "Note..." paragraphs below are superfluous. If it is 
optional as in RFC5101, please denote it in the description of the 
Template fields.

In 8.1, look for "allow receipt and processing of and Data Records" and 
correct it (and -> any).

Still in 8.1, I do not think that this paragraph applies to UDP where we 
now also allow TWM (as far as I understand):
"If a Collecting Process receives a new Template Record or Options 
Template Record for an already-allocated Template ID, without having 
received a withdrawal, it MUST ignore the new Template Record and 
discard the old Template Record for the allocated ID; it SHOULD log the 
error."

Last paragraph in 8.4: "...the Collecting Process SHOULD maintain the 
following for all the current Template Records and Options Template 
Records: <IPFIX Device, Exporter source UDP port, Observation Domain ID, 
Template ID, Template Definition, Last Received>."
The UDP Transport Session is defined by a four-tuple. Collector IP 
address and port are missing in the list. Nevertheless, a Collecting 
Process can easily listen on an interface which is assigned multiple IP 
addresses. So, at least Collector IP address must be included.

In 10.3.2, "Exporting Processes exporting IPFIX Messages via UDP MUST 
include a valid UDP checksum." does not make sense. The IPFIX Messages 
does not have a UDP checksum field. It's the underlying UDP datagram. I 
also suggest to add a reference to the RFC where the UDP checksum usage 
is explained.

In 9.2, I would prefer MAY over SHOULD in "If the Template Records (or 
other definitions such as Common Properties) have not been received at 
the time Data Records are received, the Collecting Process SHOULD store 
the Data Records for a short period of time and decode them after the 
Template Records (or other definitions) are received."
BTW, SHOULD contradicts the MAY used earlier in 8.
Also, it must be mentioned that at late arrival of the Template, the 
Export Time must be compared to the one of the earlier received Data 
Records.

Thanks,
Gerhard


On 23.11.2012 04:47, Nevil Brownlee wrote:
>
> Hi all:
>
> Following up on Brian's email dated 20 November ...
>
> The WG Last Call for this I-D starts now, and will run until Monday,
> 10 December.
>
> Do please read the draft, and post your comments to the list.  It's
> important that we can show it has been well-considered/reviewed within
> the WG, so short comments like "yes, this does clearly describe the
> IPFIX Information Model as we want it to be" are important and useful!
>
> Cheers, Nevil
>
_______________________________________________
IPFIX mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipfix