Re: [IPFIX] AD Review of draft-ietf-ipfix-export-per-sctp-stream-02 -> reference

[Benoit Claise <[e-mail]>]

Dan,

See this email:

    -------- Original Message -------- 

    Subject: 	Re: [Tsvwg] WG adoption of draft-stewart-tsvwg-sctpstrrst
    Date: 	Mon, 27 Apr 2009 16:28:41 -0400
    From: 	Lars Eggert <[e-mail]>
    To: 	tsvwg <[e-mail]>
    CC: 	[e-mail]
    References: 	<[e-mail]>



    The consensus from SF has been confirmed. Authors, please submit the  
    next version of this document as draft-ietf-tsvwg-sctp-strrst-00.

    Lars

    On 2009-4-8, at 11:12, Eggert Lars (Nokia-NRC/Espoo) wrote:

    > Hi,
    >
    > during the WG meeting in SF, there was consensus to take on draft- 
    > stewart-tsvwg-sctpstrrst as a WG item in TSVWG. As always, we'd like  
    > to confirm this result on the list. If you disagree with this  
    > consensus decision, please speak up by April 15.
    >
    > Thanks,
    > Lars


However, draft-stewart-tsvwg-sctpstrrst has not been posted yet

Some background information from 
http://www.ietf.org/proceedings/08nov/minutes/ipfix.txt

    Dan (AD): 
    This draft cannot be a normative reference as long as it is
    not adopted by a the TSVWG. Suggestion: describe the mechanism in the 
    normative part of the text and add an informative reference to the 
    SCTP-RESET document. Once the document is included in the Transport WG 
    charter it can be used as a normative reference. 
      

I propose that we keep our plan, without waiting for a dependency on the 
(future) TSV WG item.
Are we still in sync?

Regards, Benoit.
> Please find below the AD review for
> draft-ietf-ipfix-export-per-sctp-stream-02. The document is mature
> enough to go to IETF Last Call. Unless there are any special comments or
> concerns I will send it to IETF Last Call by tomorrow. 
>
> Please consider the comments below together with the other IETF Last
> Call comments. The comments are divided into Technical and Editorial
>
> T1. There is not information concerning the impact on performance and
> capacity of the reporting and collecting processes. Should we expect any
> considerable impact on performance and/or capacity? If any
> implementation experience is available I would suggest that we record
> it. 
>
>
>
> E1. idnits complains about a number of IPR boilerplate issues and
> obsolete references issues: 
>
> tmp/draft-ietf-ipfix-export-per-sctp-stream-02.txt:
>
>   Checking boilerplate required by RFC 5378 and the IETF Trust (see
>   http://trustee.ietf.org/license-info):
>  
> ------------------------------------------------------------------------
> ----
>
>   ** You're using the IETF Trust Provisions Section 6.b License Notice
> from
>      10 Nov 2008 rather than the newer Notice from 12 Feb 2009, which is
>      required now.  (See http://trustee.ietf.org/license-info/)
>
>
>   Checking nits according to
> http://www.ietf.org/ietf/1id-guidelines.txt:
>  
> ------------------------------------------------------------------------
> ----
>
>      No issues found here.
>
>   Checking nits according to http://www.ietf.org/ID-Checklist.html:
>  
> ------------------------------------------------------------------------
> ----
>
>      No issues found here.
>
>   Miscellaneous warnings:
>  
> ------------------------------------------------------------------------
> ----
>
>   == The document seems to lack a disclaimer for pre-RFC5378 work, but
> was
>      first submitted before 10 November 2008.  Should you add the
> disclaimer?
>      (See the Legal Provisions document at
>      http://trustee.ietf.org/license-info for more information.). 
>
>      trust-12-feb-2009 Section 6.c.iii text:
>      "This document may contain material from IETF Documents or IETF
>       Contributions published or made publicly available before November
>       10, 2008.  The person(s) controlling the copyright in some of this
>       material may not have granted the IETF Trust the right to allow
>       modifications of such material outside the IETF Standards Process.
>
>       Without obtaining an adequate license from the person(s)
>       controlling the copyright in such materials, this document may not
>       be modified outside the IETF Standards Process, and derivative
>       works of it may not be created outside the IETF Standards Process,
>       except to format it for publication as an RFC or to translate it
>       into languages other than English."
>
>
>   Checking references for intended status: Informational
>  
> ------------------------------------------------------------------------
> ----
>
>   == Outdated reference: draft-ietf-psamp-sample-tech has been published
> as
>      RFC 5475
>
>   == Outdated reference: draft-ietf-ipfix-architecture has been
> published as
>      RFC 5470
>
>   == Outdated reference: draft-ietf-ipfix-as has been published as RFC
> 5472
>
>   == Outdated reference: draft-ietf-psamp-protocol has been published as
> RFC
>      5476
>
>   == Outdated reference: draft-ietf-psamp-framework has been published
> as RFC
>      5474
>
>   == Outdated reference: draft-ietf-ipfix-reducing-redundancy has been
>      published as RFC 5473
>
>   == Outdated reference: A later version (-01) exists of
>      draft-stewart-tsvwg-sctpstrrst-00
>
>
>      Summary: 1 error (**), 8 warnings (==), 0 comments (--)
>
> E2. PR-SCTP is not expanded at first occurrence in the Abstract 
>
> E3. I suggest to change the sentence in the IANA considerations as
> follows: According to the process defined in RFC 5202 IANA will allocate
> the dataRecordsRelability Information element defined in Section 4.2
>
> _______________________________________________
> IPFIX mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ipfix
>