[IPFIX] Fwd: I-D ACTION:draft-ietf-ipfix-export-per-sctp-stream-04.txt

[Brian Trammell <[e-mail]>]

Hi, Benoit, all,

I have a few comments on the -04 perstream draft.

In general the quality of the draft has improved greatly. I'm quite  
happy with the detail in section 4.5 for guaranteeing interoperability  
while still allowing CPs to get the benefits of per-stream, which was  
my main issue with the previous revision. I notice too the Intended  
Status is now Standards Track. I presume that this Standards Track  
designation is equivalent to that of e.g. 5103 (Biflow): this is an  
optional specification with specific applicability; otherwise, it's  
still fine IMO as Informational, but then you have to ditch all the  
2119 language. I think it was the appearance of 2119 language in an  
Informational draft that made the IESG suggest Standards Track; see  
5473 for an example of how to describe a mechanism with specific  
applicability in a non-normative way. Of course, then there's the  
problem with an Informative RFC contradicting a Standards Track one  
(5101), necessary for the CP to realize the perstream advantages... In  
any case, I'm not convinced the discussion is complete on this point.

Presuming we're talking about a restricted-applicability Standards  
Track draft, the applicability of the draft is now clearer in previous  
versions, but I would still suggest certain changes to the language in  
order to avoid confusion on this point, as follows.

2.2 Applicability para 1

OLD: The specifications are required in cases where we must know how  
many data records of a certain type...

NEW: The specifications contained in this document are applicable to  
cases where application requirements include knowing how many data  
records of a certain type...

[Yes, I know that required isn't a REQUIRED, but I want implementors  
to be sure they don't have to do perstream if they're not splitting  
templates by app; I believe the suggested text clarifies this point]


2.2 Applicability para 3

OLD: However, in order to benefit from the advantages, the Collecting  
Process specified in [RFC5101] must implement some additional  
specifications that this document introduces.

NEW: However, Collecting Processes may implement additional support  
for per-stream export specified in this document in order to realize  
all the benefits of the approach specified herein.

[Same thing. Make it clear we're not updating 5101.]


3.2.1 Transmission Order within an SCTP Stream / IPFIX Protocol  
Specifications Limitation paragraph 5

DELETE: In practice, Data Records without associated (Options)  
template records will most likely be discarded by the Collecting  
Process.

[Maybe true. Probably, even. Appropriate for an Informational draft or  
an implementation report. But this comes too close to contradicting a  
MAY in 5101 to be appropriate for a Standards Track draft.]


4. Specifications para 1

OLD: This section introduces improvements compared to the IPFIX  
specifications in [RFC5101].

NEW: This section specifies Exporting Process and Collecting Process  
behavior different from that in [RFC5101] in order to realize the  
benefits of per-stream export. Note that Exporting Processes following  
these Specifications will interoperate with [RFC5101]-compliant  
Collecting Processes, but that Collecting Processes will have to  
follow additional non-interoperable specifications to realize the full  
benefits of the technique.

[The current text does not take applicability under consideration.]


4.2 Template Management para 1

OLD: This section introduces some additional specifications compared  
to the Template Management section 8 in [RFC 5101]

NEW: 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].

[As for 4 above.]


4.3 SCTP para 1

OLD: This section introduces some more specific specifications  
compared to the SCTP section 10.2 in [RFC 5101], in particular the  
"Stream" section 10.2.4.3.

NEW: To take advantage of per-stream export, Exporting Processes  
should manage SCTP streams according to the specification in this  
section, in addition to Section 10.2.4.3, Stream, of [RFC5101].

[As for 4 above.]


4.4 Template Withdrawal Message para 1

OLD: This section introduces some more specific Template Withdrawal  
Message-related specifications compared to  [RFC 5101]

NEW: To take advantage of per-stream export, Exporting Processes  
should send Template Withdrawal Messages according to the  
specification in this section, in addition to Section 8, Template  
Management, of [RFC5101].

[As for 4 above.]


4.5 The Collecting Process's Side para 1

OLD: This section introduces some more specific specifications to the  
Collection Process compared to section 9 in [RFC5101]. However, the  
new specifications are backwards compatible with RFC5101- compliant  
Collecting Processes and are only needed to benefit from the  
advantages offered by the per-SCTP-stream extension.

NEW: 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 for 4. Clarified that CPs need to interoperate with EPs, not "have  
backward compatibility" with other CPs.]


A suggestion not strictly limited to applicability:


4.1 dataRecordsReliability Information Element

[This information element is specified to only apply to Template ID  
scopes. Could it not also be scoped to other things (SCTP Stream ID,  
for instance) for a generalization of the approach? suggest the  
following:]

OLD:
    dataRecordsReliability

          Description:
               The Data Records reliability associated with this
               Template ID.  The true value means that the Data Records
               are sent reliably, while the false value means that the
               Data Records are not sent reliably.

NEW:
   dataRecordsReliability

     Description:

       The Data Records reliability associated with the elements in
        the Options Template scope, usually a templateID. A true value
        means that the Data Records are sent reliably, while a false  
value
        means that the Data Records are not sent reliably.


In addition, on review I found the following editorial issues:

Subsections of 3, stylistic: The structure of this section reads a  
little like a sales pitch (with the subsubsections IPFIX limitations /  
perstream advantages per each subsection). Further, I don't actually  
think the split into subsubsections is necessary; the text flows fine  
without the headings. If you really want to keep the subsubsections,  
name the 3.x.1 "IPFIX Protocol Specification Limitations" for  
plurality agreement with 3.x.2.


3.2.1 Transmission Order within an SCTP Stream / IPFIX Protocol  
Specifications Limitation paragraph 1

OLD: The IPFIX protocol specification foresees:

NEW: [RFC5101] specifies:


3.3.2 No Transmission Order across SCTP Streams / IPFIX Export Per  
SCTP Stream Advantages, general

[This section should mention Options Templates, since 3.3.1 does.]


4.1 dataRecordsReliability

[should have an IANA NOTE pointing out that IANA should change the  
xxx. They'll probably figure it out anyway but why not be helpful? :) ]


Further, I suspect you'll get a Security question asking about what  
SCTP-RESET does to the SCTP-relevant bits of the 5101 security  
considerations, so a paragraph exploring the potential risks (and  
then, therefore, one hopes, dismissing them) would be useful here.

hm. That seems to be about it (it was a little longer than I  
originally intended). Hope this helps. :)

Cheers,

Brian

On Oct 26, 2009, at 6:00 PM, [e-mail] wrote:

> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> This draft is a work item of the IP Flow Information Export Working  
> Group of the IETF.
>
> 	Title		: IPFIX Export per SCTP Stream
> 	Author(s)	: B. Claise, P. Aitken, A. Johnson, G. Muenz
> 	Filename	: draft-ietf-ipfix-export-per-sctp-stream-04.txt
> 	Pages		: 22
> 	Date		: 2009-10-26
> 	
> This document specifies an extension to the specifications
>       in RFC5101, IP Flow Information Export (IPFIX), when using
>       the Partial Reliability extension of SCTP (PR-SCTP, Partial
>       Reliability Stream Control Transmission Protocol).
>       When implemented at both the Exporting and Collecting Processes,
>       this method offers several advantages such as the ability to
>       calculate Data Record losses for PR-SCTP, immediate export of
>       Template Withdrawal Messages, immediate reuse of Template IDs
>       within an SCTP stream, reduced likelihood of Data Record loss,
>       and reduced demands on the Collecting Process.  When implemented
>       in only the Collecting or Exporting Process then normal IPFIX
>       behavior will be seen without these additional benefits.
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-ipfix-export-per-sctp-stream-04.txt
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
> <mime-attachment>_______________________________________________
> IPFIX mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ipfix