IP Flow Information Export (IPFIX) Per Stream Control Transmission Protocol (SCTP) Stream
draft-ietf-ipfix-export-per-sctp-stream-08

[Ballot discuss]
4.5. The Collecting Process's Side


The text
"The Sequence Number of the first lost IPFIX Message can
be calculated as the Sequence Number of the last IPFIX Message
before the sequence of lost IPFIX Messages (S0) plus the number
of Data Records in that IPFIX Message (N0). 
       
S1  = S0 + N0 
loss = S2 - S1 = S2 - (S0 + N0)"

Does not address the wrapping case.

Whilst I understand the imperative to be backwards compatible, I agree with Russ's discuss, and would like to be sure we cannot address the backwards compatibility issue in a more positive way.

[Ballot comment]
The Gen-ART Review by Ben Campbell on 1 March 2010 includes some
  minor issues n addition to the major one that prompted my DISCUSS
  position.  Please consider them.

[Ballot discuss]
The Gen-ART Review by Ben Campbell on 1 March 2010 raised a major
  issue.  Ben said:
 
  > -- 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.

  Are heuristics the best that can be done to determine whether the
  exporter supports the per-SCTP-stream extension?

[Note]: 'This document was already reviewed and approved by the IESG. The IETF Last Call is redone for Proposed Status following the DISCUSS by Alexey.' added by Dan Romascanu

[Ballot comment]
The RFC Editor is bound to ask you to move the Introduction to be Section 1.

- - - -

I agree with the question about Informational status.

[Ballot discuss]
Section 7

  According to the process defined in [RFC5102], IANA will
  allocate the dataRecordsReliability Information element defined
  in Section 4.2. in the IANA IPFIX Information Elements registry.

As far as I can tell, the assignment policy for this registry is Expert Review. Can someone clarify that this review has happened?

Furthermore, is it necessary to advise IANA as two which of the ranges should be used for the new allocation?

[Ballot discuss]
DISCUSS DISCUSS:
I have 2 relatively minor issues with the document. I am likely to clear my DISCUSS or downgrade it to a COMMENT after the IESG telechat.

1). Why is this document says "Intended Status: Informational"? It looks fairly normative to me.

2).
Section 4.3 says:

      In the future, the Exporting Process may attempt to increase the
      number of outbound streams it is able to send to, per [SCTP-
      RESET].

Section 4.5 says:

      In the future, a Collecting Process should support the procedure
      for the addition of an SCTP stream [SCTP-RESET].

These look fairly normative to me.
These requirements should either be normative (and then they need to use RFC 2119 language + [SCTP-RESET] should be moved to the Normative References), or they should be removed. The text as written seems to apply to some unspecified point in the future, so this really doesn't help.

[Ballot comment]
I agree with the point raised by Lars' Discuss.

With respect to Alexey's Discuss, I think the current SCTP-RESET reference
and text is just the right way to handle reference to future work that
would otherwise block this RFC from proceeding.

[Ballot comment]
I agree with the point raised by Lars' Discuss.

With respect to Alexey's Discuss, I think the SCTP-RESET reference
is just the right way to handle reference to future work that would
otherwise block this RFC from proceeding.

[Ballot comment]
I agree with the point raised by Lars' Discuss.

With respect to Adrian's Discuss, I think the SCTP-RESET reference
is just the right way to handle reference to future work that would
otherwise block this RFC from proceeding.

[Ballot discuss]
INTRODUCTION, paragraph 38:
>    2.1. Relationship with IPFIX and PSAMP

  DISCUSS-DISCUSS: This section reads as if this document should be
  formally updating RFC5101 and RFC4576 (and be on the standards track
  for that reason). I'm also a bit unclear if this proposed change is
  backwards-compatible (if one end implements it and the other doesn't,
  can they talk?) and if not, how the use is negotiated.

[Ballot discuss]
I have 2 relatively minor issues with the document:

1). DISCUSS DISCUSS:

Why is this document says "Intended Status: Informational"? It looks fairly normative to me.

2).
Section 4.3 says:

      In the future, the Exporting Process may attempt to increase the
      number of outbound streams it is able to send to, per [SCTP-
      RESET].

Section 4.5 says:

      In the future, a Collecting Process should support the procedure
      for the addition of an SCTP stream [SCTP-RESET].


These requirements should either be normative (and then they need to use RFC 2119 language + [SCTP-RESET] should be moved to the Normative References), or they should be removed. The text as written seems to apply to some unspecified point in the future, so this really doesn't help.

IANA Last Call comments:

Upon approval of this document, the IANA will make the following assignments
in the "IP Flow Information Export (IPFIX) Information Elements" registry located at
http://www.iana.org/assignments/ipfix/ipfix.xhtml
sub-registry "IPFIX Information Elements"


Value: TBD
Name: dataRecordsReliability
Data Type: boolean
Data Type Semantics: identifier
Staus: current
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.
Units:
Range:
References: [RFC-ipfix-export-per-sctp-stream-02]
Requester: [RFC-ipfix-export-per-sctp-stream-02]

We understand the above to be the only IANA Action for this document.

Juergen Quittek is the document shepherd.

Write-up for draft-ietf-ipfix-export-per-sctp-stream-02
=======================================================

  (1.a)  Who is the Document Shepherd for this document?  Has the
          Document Shepherd personally reviewed this version of the
          document and, in particular, does he or she believe this
          version is ready for forwarding to the IESG for publication?
         
Juergen Quittek is the document shepherd. He has reviewed it personally
and believes that this version is ready for forwarding to the IESG
for publication.

  (1.b)  Has the document had adequate review both from key WG members
          and from key non-WG members?  Does the Document Shepherd have
          any concerns about the depth or breadth of the reviews that
          have been performed?

The document had multiple individual reviews from key WG members.
The shepherd has no concern about the depth or breadth of the reviews.

  (1.c)  Does the Document Shepherd have concerns that the document
          needs more review from a particular or broader perspective,
          e.g., security, operational complexity, someone familiar with
          AAA, internationalization, or XML?

The document shepherd sees no need for an additional particular review.
Particular issues of SCTP have been checked by the TSVWG.

  (1.d)  Does the Document Shepherd have any specific concerns or
          issues with this document that the Responsible Area Director
          and/or the IESG should be aware of?  For example, perhaps he
          or she is uncomfortable with certain parts of the document, or
          has concerns whether there really is a need for it.  In any
          event, if the WG has discussed those issues and has indicated
          that it still wishes to advance the document, detail those
          concerns here.  Has an IPR disclosure related to this document
          been filed?  If so, please include a reference to the
          disclosure and summarize the WG discussion and conclusion on
          this issue.

There is no such concern.

  (1.e)  How solid is the WG consensus behind this document?  Does it
          represent the strong concurrence of a few individuals, with
          others being silent, or does the WG as a whole understand and
          agree with it?

There is a strong consensus in the IPFIX WG to publish this version
of the document. There are no particular issues in the document
without strong consensus in the IPFIX WG.

  (1.f)  Has anyone threatened an appeal or otherwise indicated extreme
          discontent?  If so, please summarize the areas of conflict in
          separate email messages to the Responsible Area Director.  (It
          should be in a separate email because this questionnaire is
          entered into the ID Tracker.)

There was no appeal.

  (1.g)  Has the Document Shepherd personally verified that the
          document satisfies all ID nits?  (See
          http://www.ietf.org/ID-Checklist.html and
          http://tools.ietf.org/tools/idnits/.)  Boilerplate checks are
          not enough; this check needs to be thorough.  Has the document
          met all formal review criteria it needs to, such as the MIB
          Doctor, media type, and URI type reviews?  If the document
          does not already indicate its intended status at the top of
          the first page, please indicate the intended status here.

The document shepherd checked for ID nits. The IETF Trust Provisions
Section needs to be updated, since it changed after the current version
was posted. Also some references need to be updated, because they
have been published recently as RFCs. All of these changes can be made
in the next update that is expected after IETF last call.

  (1.h)  Has the document split its references into normative and
          informative?  Are there normative references to documents that
          are not ready for advancement or are otherwise in an unclear
          state?  If such normative references exist, what is the
          strategy for their completion?  Are there normative references
          that are downward references, as described in [RFC3967]?  If
          so, list these downward references to support the Area
          Director in the Last Call procedure for them [RFC3967].

Six reference have been outdated since the document was submitted.
Five of them are PSAMP and IPFIX documents that have been published
as RFCs. The remaining one is a draft from the TSVWG for which an update
has been posted. This should be fixed after IETF last call. More
references may need an update by then.

  (1.i)  Has the Document Shepherd verified that the document's IANA
          Considerations section exists and is consistent with the body
          of the document?  If the document specifies protocol
          extensions, are reservations requested in appropriate IANA
          registries?  Are the IANA registries clearly identified?  If
          the document creates a new registry, does it define the
          proposed initial contents of the registry and an allocation
          procedure for future registrations?  Does it suggest a
          reasonable name for the new registry?  See [RFC2434].  If the
          document describes an Expert Review process, has the Document
          Shepherd conferred with the Responsible Area Director so that
          the IESG can appoint the needed Expert during IESG Evaluation?

IANA considerations have been checked.

  (1.j)  Has the Document Shepherd verified that sections of the
          document that are written in a formal language, such as XML
          code, BNF rules, MIB definitions, etc., validate correctly in
          an automated checker?

No.

  (1.k)  The IESG approval announcement includes a Document
          Announcement Write-Up.  Please provide such a Document
          Announcement Write-Up.  Recent examples can be found in the
          "Action" announcements for approved documents.  The approval
          announcement contains the following sections:

Technical Summary

  This document specifies an improvement to the PR-SCTP
  export specified in the IPFIX specifications in RFC5101.
  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, and reduced demands on the Collecting
  Process.


Working Group Summary

  This document describes an extension to the IPFIX protocol. It
  was motivated by experiences made with early IPFIX implementations.
  It was accepted with consensus as WG work item and progressed
  within the WG. WG last call was conducted in August 2008.
  Modifications based on received comments were applied until
  November 2008. No more issues were brought up since then and
  at the IETF meeting in March 2009 the WG confirmed at the session
  that the document is ready for requesting publication.

Document Quality

  The document underwent several reviews and a WG last call in
  the IPFIX WG. This way, a high document quality has been achieved
  already.

Personnel

  Juergen Quittek is shepherding this document. Dan Romascanu is the
  responsible Area director.