Re: [IPFIX] WG Last Call for draft-ietf-ipfix-information-model-rfc5101bis-03.txt
Gerhard Muenz <[email protected]>
| Newsgroups | gmane.ietf.ipfix |
|---|---|
| Message-ID | <[email protected]> |
Brian, Thanks for the clarification. In 8.4, you write about Templates which are "expired" at the Exporting Process. Is it clear to the reader what "expiration" means in the context of Templates? Particularly, I do not understand what the EP is supposed to do in order to "allow the old Template to expire" as written in this sentence: "Template IDs MAY be reused by Exporting Processes by simply allowing the old Template to expire and exporting a new Template for the Template ID." My suggestion is to look for another wording and to avoid "expire". You could replace all occurrences of "expir*" in 8.4. and write about Templates which are no longer used by the Exporting Process. Apart from this minor issue, the spec is clear. Regards, Gerhard On 07.01.2013 11:53, Brian Trammell wrote: > Hi, Gerhard, > > Thanks for your comments; sorry for missing them in the last revision of 5101bis. I'm applying these to a -05 revision now. One comments inline (as always, points without comment are accepted into the revision without discussion)... > > On Dec 10, 2012, at 10:57 PM, Gerhard Muenz <[email protected]> wrote: > >> 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." > > Per the discussion we had last year about the tradeoff between code reuse among transport protocols and interoperability between 5101 and 5101bis, template withdrawals are now no longer specified as allowed on UDP. > > See also the new (in -04) language on template management errors. As the 5101 language is basically not self-interoperable (collectors are forbidden from attempting to recover from errors which, depending on interpretation, can only result from badly implemented or malicious exporters), the final three paragraphs of section 8.1 are the current suggestion for resolving this situation; do you see any issue with this arrangement? > > Many thanks, best regards, > > Brian > > _______________________________________________ IPFIX mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipfix