|
Dear Ben, Thanks for your detailed review. Sorry about the delay, we've been a little bit busy with IETF deadlines recently ;-) We clarified the text in section 4.5 as followsI have been selected as the General Area Review Team (Gen-ART) reviewer for this draft (for background on Gen-ART, please see http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html). Please wait for direction from your document shepherd or AD before posting a new version of the draft. Document: draft-ietf-ipfix-export-per-sctp-stream-06 Reviewer: Ben Campbell Review Date: 1 March 2010 IESG Telechat date: 4 March 2010 Summary: This document is almost ready for publication as a proposed standard, but there is an open issue that should be considered first. Major issues: -- section 4.5, general: I am confused as to how the collector determines the exporter supports this extension. If I understand correctly (and it's probable that I do not, since this is my first real exposure to IPFix), the collector basically has to infer exporter support from the behavior of the exporter. But then the second paragraph after the numbered list (i.e. 2 paragraphs after item 4) says: "In the case where the Exporting Process does not support the per-SCTP-stream extension, then the first Data Record received by the Collecting Process will disable the extension for the specific Exporter on the Collecting side." This seems to conflict. Why would the collector need to worry about items 1-4 if it can categorically determine exporter support from the first data record? In general, though, I think that having the collector infer support is not the right way to do this. It would be far better to explicitly signal support, if that is at all possible in IPFix. Otherwise, it seems like the collector has to watch every record for violations of 1-4, and make fairly complex decisions on a per-record basis. Note that - the paragraphs 1, 2, 3, 7, 8, 9, 10, and 11 are unchanged, but copied for completeness - we mainly rearranged the order so that it provides a more logical reading. Collecting Processes must operate slightly contrary
to
[RFC5101] in order to realize the full benefits of per-stream export.
However,
the specification in this section contains a mechanism which allows
per-stream-capable Collecting Processes to selectively enable
per-stream
export, in order to ensure interoperability of per-stream-capable
Collecting Processes
with Exporting Processes which do not implement per-stream export. As
specified in [RFC5101], the Collecting Process SHOULD listen for a new
association request from the Exporting Process.
The Exporting Process will request a number of SCTP streams to
use for
export. A
Collecting Process SHOULD support the procedure for the addition of an
SCTP
stream [SCTP-RESET]. In
IPFIX, there is no explicit notification of the Exporting Process's
capabilities. There is also no return channel for the Collecting
Process
to communicate its capabilities.
The
Collecting Process MUST check that the Exporter is compliant with the
specifications in this document. For
example, nothing prevents an implementation that does not meet the
specification
of the per-SCTP-stream extension from sending a Template that looks
like a
dataRecordsReliability Options Template.
Therefore, a Collecting Process MUST detect if the Exporter
fails to
meet the specification fully. If any of the conditions below is met,
the
Exporting Process does not properly use the per-SCTP-stream extension.
In
this case, the Collecting Process MUST disable the per-SCTP-stream
extension for
the given Exporter and report an error message: 1. A
Data Record is received before the appropriate Data Record associated
with the
Data Records Reliability Options Template has been received on the same
SCTP
stream (see section 4.1). 3. Loss
of Data Records is detected within a stream where there has not been
received a
Data Record associated with the Data Record Reliability Options
Template
indicating unreliable transmission for any template.
Note that it is
not an error to receive a Data Record
reliably if that Data Record is associated with a Template whose Data
Records
are expected to be sent unreliably. Continuing below the paragraphs are unchanged
Actually, there is nothing in RFC5101 that mandates that (Options) Template and associated Data Records must be sent in the same SCTP stream.Minor issues: -- section 4.2, 3rd paragraph from end, starting with "When an Options Template..." I'm confused by this paragraph. Would exporters using this extension ever send the options template and associated data records in different streams? OLD:Nits/editorial comments: -- section 4.1, description of dataRecordsReliability: I find the first sentence hard to parse. dataRecordsReliability
Description:
The reliability of the export of Data Records, within
this SCTP stream, for the element(s) in the Options
Template scope, usually a templateID. A value of 'true'
means that the Exporting Process MUST send any Data
Records associated with the element(s) reliably within
this SCTP stream. A value of 'false' means that the
Exporting Process MAY send any Data Records associated
with the element(s) unreliably within this SCTP stream.
NEWdataRecordsReliability Description: The export reliability of Data
Records, within this SCTP stream, for the element(s) in the Options
Template
scope. A typical example of element for
which the export reliability must be reported is the templateID, as a
specified
in the Data Record Reliability
Options Template. A value of
'true' means that the Exporting Process MUST send any Data Records
associated
with the element(s) reliably within this SCTP stream. A value of
'false'
means that the Exporting Process MAY send any Data Records associated
with the element(s)
unreliably within this SCTP stream. -- section 4.2, first paragraph" "...exporting processes should follow..." (Note that an identical comment applies to the first paragraph of several of the specification sections.) It would be best to avoid the word "should" in this context. Even though we all know a lower case should is not normative, it's still enough to confuse a reader into interpreting as a normative SHOULD, which is actually weaker than the real requirement. That is, I don't think you mean to say that, in order to take advantage of this extension and implementation SHOULD follow this specification. Actually, this should be a "MUST" OLD To take advantage of per-stream export, Exporting Processes should follow the specification in this section in addition to Section 8, Template Management, of [RFC5101]. NEW To take advantage of per-stream export, Exporting Processes MUST follow the specification in this section in addition to Section 8, Template Management, of [RFC5101]. We have corrected the other first paragraph of several of the specification sections Not pedantic, you're actually right.-- section 4.3, paragraph 3: pedantic nit - I think you mean all IPFIX messages in a single stream MUST be sent in order--not that all messages have to be in a single stream, right? The current wording is (slightly) ambiguous on that point. OLD: All IPFIX Messages MUST be sent in order within an SCTP stream. NEW: All IPFIX Messages in an SCTP stream MUST be sent in order. OLD:-- section 4.3, last paragraph: Why mention the alternative if it is not feasible in production? An alternative, which is not practical in
operational networks, is to restart the SCTP association with an
increased number of SCTP streams.
NEWAn alternative, which may result in the loss of Flow Records (for example, due to lack of buffering on the Exporter), is to restart the SCTP association with an increased number of SCTP streams Good catch.--Examples, figure 3: Is Data 257 a typo? The warnings are about: License, copyright year, and outdated references.-- idnits has some warnings. Please check before publication. I'll correct these. Not sure whether I should publish a new draft version. Anyway, I have all those changes above in my private copy of the draft. Please let us know if this clarifies the situation. Regards, Benoit. |
_______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf