Subject: Gen-ART LC/Telechat review of draft-ietf-ipfix-export-per-sctp-stream-06

From: Ben Campbell <[email-masked]>
Date: Mon, 1 Mar 2010 17:47:19 -0600

I 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.

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?

Nits/editorial comments:

-- section 4.1, description of dataRecordsReliability:

I find the first sentence hard to parse.

-- 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. 

-- 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.

-- section 4.3, last paragraph:

Why mention the alternative if it is not feasible in production?

--Examples, figure 3:

Is Data 257 a typo?

-- idnits has some warnings. Please check before publication.

---

From: Benoit Claise <[email-masked]>
Date: Thu, 18 Mar 2010 11:31:20 +0100

Dear Ben,

Thanks for your detailed review.
Sorry about the delay, we've been a little bit busy with IETF deadlines 
recently ;-)
> 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. Otherw…
We clarified the text in section 4.5 as follows
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 dataRecordsReliability Options Template is expected, but cannot be 
guaranteed, to only originate from a per-SCTP-stream compliant Exporting 
Process. In the case where the Exporting Process uses the 
per-SCTP-stream extension, the first Data Record received by the 
Collecting Process is associated with the Data Records Reliability 
Options Template. If the first Data Record is associated with any other 
(Options) Template, the Collecting Process MUST disable the extension 
for the specific Exporter on the Collecting side.

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).

2. A Data Record associated with a Data Record Reliability
Options Template is received on an SCTP stream for a (non-Options) 
Template that was defined on a different SCTP stream.

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.

4. A message is received with the SCTP U(nordered) flag set to 1, (i.e., 
the message was sent unordered) even if it is processed in order.

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

    The Collecting Process MUST accept other non-scope Information 
Elements in the Data Record Reliability 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?
Actually, there is nothing in RFC5101 that mandates that (Options) 
Template and associated Data Records must be sent in the same SCTP stream.
> I find the first sentence hard to parse.
OLD:

         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.

NEW

dataRecordsReliability

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.

> 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 SHO…

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
> 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…
Not pedantic, you're actually right.

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.
> Why mention the alternative if it is not feasible in production?
OLD:

         An alternative, which is not practical in
         operational networks, is to restart the SCTP association with an
         increased number of SCTP streams.

NEW
An 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
> Is Data 257 a typo?
Good catch.

> -- idnits has some warnings. Please check before publication.
The warnings are about: License, copyright year, and outdated references.
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.

---

From: Ben Campbell <[email-masked]>
Date: Wed, 24 Mar 2010 13:26:33 -0700

Benoit and I just had an offline discussion that helped me understand things a little better. That discussion, and this email resolve my issues, (pending the actual revised draft.)

Specific comments inline:

Thanks!

Ben.

On Mar 18, 2010, at 3:31 AM, Benoit Claise wrote:

> Sorry about the delay, we've been a little bit busy with IETF deadlines recently ;-)
>> 
>     - 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 dataRecordsReliability Options Template is expected, but cannot be guaranteed, to only originate from a per-SCTP-stream compliant Exporting Process.  In the case where the Exporting Process uses the per-SCTP-stream extension, the first Data Record received by the Collecting Process is associated with the Data Records Reliability Options Template.   If the first Data Record is associated with any other (Options) Template, the Collecting Process MUST disable the extension for the specific Exporter on the Collecting side.
>   
> 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). 
> 
> Options Template is received on an SCTP stream for a (non-Options) Template that was defined on a different SCTP stream.
>  
> 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.
> 
> 4. A message is received with the SCTP U(nordered) flag set to 1, (i.e., the message was sent unordered) even if it is processed in order.
>  
> 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.
> 
>    The Collecting Process MUST accept other non-scope Information Elements in the Data Record Reliability Options Template.
> 

This helps quite a bit, and I think it addresses my concern. It's now clearer to me that the Options Template triggers the assumption that the extension is being used, and the other heuristics are tests that allow you to fall back if the extension is not being used "properly". While a binary signal of some sort would be nice, I yield to the work groups expertise in the area.

> Actually, there is nothing in RFC5101 that mandates that (Options) Template and associated Data Records must be sent in the same SCTP stream.

Okay.

> 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.

That helps, thanks.

> 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

Okay, I think that solves it.

> All IPFIX Messages in an SCTP stream MUST be sent in order.

Okay.

> An 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

Okay.

> 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.
> 

You should coordinate that with the draft shepherd (and AD advisor).

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Wed, 24 Mar 2010 21:31:10 +0100

Benoit,
 
Do you plan to issue a revised ID that will allow Russ to clear his
DISCUSS?
 
Thanks and Regards,
 
Dan

________________________________

	From: Ben Campbell [mailto:[email-masked]] 
	Sent: Wednesday, March 24, 2010 10:27 PM
	To: Benoit Claise
	Cc: [email-masked]; [email-masked]; [email-masked];
General Area Review Team; Romascanu, Dan (Dan); [email-masked];
IETF-Discussion list; Russ Housley
	Subject: Re: Gen-ART LC/Telechat review of
draft-ietf-ipfix-export-per-sctp-stream-06

	Benoit and I just had an offline discussion that helped me
understand things a little better. That discussion, and this email
resolve my issues, (pending the actual revised draft.)

	Thanks!

	Ben.

		Dear Ben,
		
		Thanks for your detailed review.
		Sorry about the delay, we've been a little bit busy with
IETF deadlines recently ;-) 

			I have been selected as the General Area Review
Team (Gen-ART)
			reviewer for this draft (for background on
Gen-ART, please see

			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.

		We clarified the text in section 4.5 as follows
		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 dataRecordsReliability Options Template is expected,
but cannot be guaranteed, to only originate from a per-SCTP-stream
compliant Exporting Process.  In the case where the Exporting Process
uses the per-SCTP-stream extension, the first Data Record received by
the Collecting Process is associated with the Data Records Reliability
Options Template.   If the first Data Record is associated with any
other (Options) Template, the Collecting Process MUST disable the
extension for the specific Exporter on the Collecting side.

		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). 
		
		2. A Data Record associated with a Data Record
Reliability 
		Options Template is received on an SCTP stream for a
(non-Options) Template that was defined on a different SCTP stream.

		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.

		4. A message is received with the SCTP U(nordered) flag
set to 1, (i.e., the message was sent unordered) even if it is processed
in order.

		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.

		
		   The Collecting Process MUST accept other non-scope
Information Elements in the Data Record Reliability Options Template.

	This helps quite a bit, and I think it addresses my concern.
It's now clearer to me that the Options Template triggers the assumption
that the extension is being used, and the other heuristics are tests
that allow you to fall back if the extension is not being used
"properly". While a binary signal of some sort would be nice, I yield to
the work groups expertise in the area.

		   ...

			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?

		Actually, there is nothing in RFC5101 that mandates that
(Options) Template and associated Data Records must be sent in the same
SCTP stream. 

	Okay.

			Nits/editorial comments:
			
			-- section 4.1, description of
dataRecordsReliability:

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

		dataRecordsReliability

		   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.

	That helps, thanks.

			-- 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. 

		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 

			
			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.

	Okay.

			Why mention the alternative if it is not
feasible in production?

		OLD:
		
		        An alternative, which is not practical in
		        operational networks, is to restart the SCTP
association with an
		        increased number of SCTP streams.
		NEW
		
		An 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

	Okay.

			--Examples, figure 3:
			
			Is Data 257 a typo?

		Good catch.

			-- idnits has some warnings. Please check before
publication.

		The warnings are about: License, copyright year, and
outdated references.
		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.

	You should coordinate that with the draft shepherd (and AD
advisor).

		Regards, Benoit.

---

From: Benoit Claise <[email-masked]>
Date: Wed, 24 Mar 2010 14:02:17 -0700

Dan,

OK, I'll do that!

Regards, Benoit.
>     ------------------------------------------------------------------------
>     *From:* Ben Campbell [mailto:[email-masked]]
>     *Sent:* Wednesday, March 24, 2010 10:27 PM
>     *To:* Benoit Claise
>     *Cc:* [email-masked]; [email-masked]; [email-masked];
>     *Subject:* Re: Gen-ART LC/Telechat review of
>>     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.
>>
>>     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 dataRecordsReliability Options Template is expected, but
>>     cannot be guaranteed, to only originate from a per-SCTP-stream
>>     compliant Exporting Process. In the case where the Exporting
>>     Process uses the per-SCTP-stream extension, the first Data Record
>>     received by the Collecting Process is associated with the Data
>>     Records Reliability Options Template. If the first Data Record is
>>     associated with any other (Options) Template, the Collecting
>>     Process MUST disable the extension for the specific Exporter on
>>     the Collecting side.
>>
>>
>>     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:
>>
>>     associated with the Data Records Reliability Options Template has
>>     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.
>>
>>
>>     4. A message is received with the SCTP U(nordered) flag set to 1,
>>     (i.e., the message was sent unordered) even if it is processed in
>>     order.
>>
>>     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.
>>
>>
>     This helps quite a bit, and I think it addresses my concern. It's
>     now clearer to me that the Options Template triggers the
>     assumption that the extension is being used, and the other
>     heuristics are tests that allow you to fall back if the extension
>     is not being used "properly". While a binary signal of some sort
>     would be nice, I yield to the work groups expertise in the area.
>
>>        ...
>>
>>>     Minor issues:
>>>
>>     (Options) Template and associated Data Records must be sent in
>>     the same SCTP stream.
>
>     Okay.
>
>>>     Nits/editorial comments:
>>>
>>     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.
>>
>
>     That helps, thanks.
>
>>
>>     To take advantage of per-stream export, Exporting Processes
>>     should follow the specification in this section in addition to
>>     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].
>>
>>     example, due to lack of buffering on the Exporter), is to restart
>>     the SCTP association with an increased number of SCTP streams
>
>     Okay.
>
>>>     --Examples, figure 3:
>>>
>>>     Is Data 257 a typo?
>>>        
>>     Good catch.
>>
>>     version. Anyway, I have all those changes above in my private
>>     copy of the draft.
>>
>