Re: [IPFIX] Write-up for draft-ietf-ipfix-protocol-rfc5101bis-06

Hi Juergen, Secretariat,

Thanks for this.
See inline for two small corrections.
Secretariat, can you please use those corrections when posting the write-up.

> Dear Benoit and dear IESG Secretary,
>
> Below please find the write up for
> draft-ietf-ipfix-protocol-rfc5101bis-06.
> The draft is ready for forwarding to the IESG
> for publication as Internet Standard.
>
> Best regards,
>      Juergen
>
>
> ====================================================
> Write-up for draft-ietf-ipfix-protocol-rfc5101bis-06
> ====================================================
>
> (1) What type of RFC is being requested (BCP, Proposed Standard,
> Internet Standard, Informational, Experimental, or Historic)?
> Why is this the proper type of RFC? Is this type of RFC indicated
> in the title page header?
>
>     Internet Standard. The header indicates: "Category: Standards Track".
>     It is appropriate.  The RFC obsoletes standards track RFC 5201.
OLD: RFC 5201
NEW: RFC 5101
>     there3 are multiple experimental and commercial implementations
>     of RFC5101.  They have been tested at interop events.  Errata's
>     of RFC5101 have been solved without invalidating existing
>     implementations.
>
> (2) 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 the IP Flow Information Export (IPFIX)
>     protocol that serves for transmitting Traffic Flow information over
>     the network. In order to transmit Traffic Flow information from an
>     Exporting Process to a Collecting Process, a common representation of
>     flow data and a standard means of communicating them is required.
>     This document describes how the IPFIX Data and Template Records are
>     carried over a number of transport protocols from an IPFIX Exporting
>     Process to an IPFIX Collecting Process. This document obsoletes RFC
>     5101.
>
>
> Working Group Summary:
>
>     The documents obsoletes RFC 5101.  It does not change the technical
>     content of the RFC5101 protocol specification, but it add several
>     clarifications.  The WG jointly worked on improving RFC5101 based
>     on implementations experience and document reviews.  There is strong
>     consensus on the document.
>
> Document Quality:
>
>     This is an update of RFC 5101 based on a lot of practical experiences
>     with implementing and operating the IPFIX protocol.  Changes compared
>     to RFC 5101 result from these experiences.
>
> Personnel:
>
> Who is the Document Shepherd? Who is the Responsible Area Director?
>
>     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.
>
> (3) Briefly describe the review of this document that was performed
> by the Document Shepherd. If this version of the document is not
> ready for publication, please explain why the document is being
> forwarded to the IESG.
>
>     The document shepherd has reviewed the draft and is fully convinced
>     that it is ready for publication.
>
> (4) 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
>     during WG last call.  Several comments were made and have been
>     addressed when updating the document after the reviews. The
>     shepherd has no concern about the depth or breadth of the reviews.
>
> (5) Do portions of the document need review from a particular or
> from broader perspective, e.g., security, operational complexity,
> AAA, DNS, DHCP, XML, or internationalization? If so, describe the
> review that took place.
>
>     No.
>
> (6) Describe any specific concerns or issues that the Document
> Shepherd has 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.
>
>     There are no such issues.
>
> (7) Has each author confirmed that any and all appropriate IPR
> disclosures required for full conformance with the provisions of
> BCP 78 and BCP 79 have already been filed. If not, explain why?
>
>     Yes.
>     
> (8) Has an IPR disclosure been filed that references this
> document? If so, summarize any WG discussion and conclusion
> regarding the IPR disclosures.
>
>     There is one IPR disclosure filed.  It is known by the WG
>     and has been discussed.  It is not different from the IPR
>     disclosures that had already been filed for RFC 5101.
>
> (9) 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?
>
>     The WG as a whole understands and agrees with it.
>
> (10) Has anyone threatened an appeal or otherwise indicated extreme
> discontent? If so, please summarise the areas of conflict in
> separate email messages to the Responsible Area Director. (It should
> be in a separate email because this questionnaire is publicly
> available.)
>
>     No.
>
> (11) Identify any ID nits the Document Shepherd has found in this
> document. (See http://www.ietf.org/tools/idnits/ and the Internet-
> Drafts Checklist). Boilerplate checks are not enough; this check
> needs to be thorough.
>
>     There are a few nits.
>     - The reference to draft-claise-ipfix-
>     information-model-rfc5102bis-01 is outdated and has a wrong
>     author list.
>     - The reference to draft-ietf-ipfix-mediation-protocol-03
>     is outdated.
>     These can be fixed in an update after IETF last call.
>     
> (12) Describe how the document meets any required formal review
> criteria, such as the MIB Doctor, media type, and URI type reviews.
>
>     No further formal review required except for a thorough review
>     by IANA which will be conducted anyway.
>
> (13) Have all references within this document been identified as
> either normative or informative?
>
>     Yes.
>
> (14) 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 plan for their completion?
>
>     Yes, there is a references to draft-ietf-ipfix-information-model-
>     rfc5101bis which is already in the RFC editor queue.
OLD: draft-ietf-ipfix-information-model- rfc5101bis
NEW: draft-ietf-ipfix-information-model-rfc5102bis

Regards, Benoit

>
> (15) Are there downward normative references references (see RFC
> 3967)? If so, list these downward references to support the Area
> Director in the Last Call procedure.
>
>     No.
>
> (16) Will publication of this document change the status of any
> existing RFCs? Are those RFCs listed on the title page header,
> listed in the abstract, and discussed in the introduction? If the
> RFCs are not listed in the Abstract and Introduction, explain why,
> and point to the part of the document where the relationship of this
> document to the other RFCs is discussed. If this information is not
> in the document, explain why the WG considers it unnecessary.
>
>     RFC 5101 will be obsoleted by this document.  This is explicitly
>     mentioned in the abstract and introduction.
>
> (17) Describe the Document Shepherd's review of the IANA
> considerations section, especially with regard to its consistency
> with the body of the document. Confirm that all protocol extensions
> that the document makes are associated with the appropriate
> reservations in IANA registries. Confirm that any referenced IANA
> registries have been clearly identified. Confirm that newly created
> IANA registries include a detailed specification of the initial
> contents for the registry, that allocations procedures for future
> registrations are defined, and a reasonable name for the new registry
> has been suggested (see RFC 5226).
>
>    Most tet in the IANA considerations section repeats what has
>    already been stated in RFC5101.  The only new action for IANA
>    is replacing references in IANA registries to RFC5101 with
>    references to this document.
>    
> (18) List any new IANA registries that require Expert Review for
> future allocations. Provide any public guidance that the IESG would
> find useful in selecting the IANA Experts for these new registries.
>
>    There are no new IANA registries requested by this document.
>
> (19) Describe reviews and automated checks performed by the Document
> Shepherd to validate sections of the document written in a formal
> language, such as XML code, BNF rules, MIB definitions, etc.
>
>     None to be done.
>
>
>
>

_______________________________________________
IPFIX mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipfix