Cisco Systems Export of Application Information in IP Flow Information Export (IPFIX)
RFC 6759

[Ballot comment]
To the AD:

Could you update the ballot and approval notes to reflect the new
name of the document, please.

---

To the Authors

The first section could really do with having text that explains (per
the title and Abstract - but in a little more detail) that this is a
Cisco-proprietary extension to IPFIX.

I found a very skimpy sentence in Section 2 (which made me recall that
I like it when the first section of a document is the Introduction :-)

[Ballot comment]
To the AD:

Could you update the ballot and approval notes to reflect the new
name of the document, please.

---

To the Authors / ISE:

The first section could really do with having text that explains (per
the title and Abstract - but in a little more detail) that this is a
Cisco-proprietary extension to IPFIX.

I found a very skimpy sentence in Section 2 (which made me recall that
I like it when the first section of a document is the Introduction :-)

[Ballot comment]
I agree with the comments that the boilerplate for this sort of document is odd.  I think we need to look at the choices we have for what to say at the beginnings of documents, and make sure there's a good, standard option for "this is not a consensus document; we're just putting it out for information."  Or maybe this says that this should have gone through the ISE.

In any case, I have no objection to publishing this, so here we go.

[Ballot discuss]
Sorry for this late discuss but what about user privacy?
(I'm not a security AD, but I wonder anyhow)

The document says
    Today service providers and network administrators are
      looking for visibility into the packet content rather than
      just the packet header.

When talking about packet content and identifying applications used,  we are already at the door sill to see what individuals are doing in the network.

I've read the Security Considerations to see if the privacy aspects are being disucssed there and was very much disappointed. Especially also that the reference RFC 5101 is also not discussing user privacy.

[Ballot comment]
I am also wondering about the boiler plate, such as Wes does. Why is this presenting IETF consensus if it is a company's protocol only?

[Ballot comment]
As with similar "Company X's FooBar" documents, I think it is bizarre to let the boilerplate say that the IETF has consensus that this is what Cisco does.

Though I am opposed to IETF work on DPI and supporting technologies like this as they are clearly hopeless and fundamentally harmful to the Internet, I have no technical arguments with this document and no objection to publishing what Cisco is doing in this regard.

[Ballot discuss]
(Hoping this is easy to clear). The header/boilerplate seems to be what would happen normally following RFC5741. What's the EDITOR NOTES: block there for? Are there clear instructions to remove it somewhere?

[Ballot discuss]

  In response to the Gen-ART Review by Roni Even the authors created
  Appendix C, which references [CISCO-APPLICATION-REGISTRY].  We have
  been waiting for the referenced web page to appear since 29 May 2012.
  I do not think that the IESG should approve the document to a web page
  that cannot be reviewed.  Please remove Appendix C and the reference.

[Ballot discuss]
This is a useful and well written document.

I am concerned that what is described is the Cisco specification for this protocol without a full disclosure of this being made at the beginning of the document.

I also understand from the authors that one of the goals of this document is to be referenced from an ITU-T Recomemndation, however the document cannot be referenced by them without the IETF Consensus note.

For the reason indicated below, I am inclined to suggest that this draft be published as a informational in the same style as Netflow V9, and a new standards track version be published using a new information element identifier that is under full IETF control.

============ 
       
    7.1.4. classificationEngineId

I have a concern with this section. There are a number of "private"
assignments that are simply marked as reserved.

I note that this is one of the Cisco range of IPFIX information elements
and wonder whether we need to consider this information element
as a partial disclosure of the Cisco Implementation and to create
a new information element in the IANA managed range for a
standards based version of this specification.

[Ballot discuss]
This got bumped off the 5/24 telechat right before I was about to submit these.  I figured I do it anyway- might come up with more before the 6/7 telechat.

1) s2: Skype is a registered trademark (http://www.skype.com/intl/en-us/legal/terms/trademark-guidelines/).  I think you have to submit an IPR statement to use it in the draft.  I'd also note that "skype" doesn't follow the rules set out in the link.

s6.5: Citrix is too (https://www.citrix.com/English/aboutCitrix/legal/secondLevel.asp?level2ID=2210).

2) s2.1: is it really "Application Visibility" or "Throttle Control"?

3) s4.1: PANA IDs: I'm not following how their guaranteed to be unique.  Wouldn't you have to carve up the space somewhere to say this is company x's value, and then here's the value?  Otherwise, what's going to stop me and the great widget company from using 2..90 like the example in 6.3?

Ah so now I see in 6.5 there's a registry maintained by Cisco for the layer 7 definitions (13).  Is there one for 2, 4, and 12?

4) s7.1.4/Appendix A: The definitions in 7.1.4 and Appendix A don't seem to match those in s4.1 and s6.5 for classificationEngineId value #13.  I thought the values were assigned by Cisco for this one?

5) Appendix A: I'm no XML expert but I don't think I've seen a schema be extended by just "appending" some new values before.  Hoping the Apps ADs can find an XML expert to confirm.

[Ballot comment]
1) s4: selectorId is defined in RFC 5477, wouldn't it be better to point there?  Also, it's "similar" how similar?

2) s4.1: I don't see how [IANA-PROTO], [IANA-PORTS], and [CISCO] are normative references based on their use in s4.1.  If you're going to use those classification engine IDs and these references tell you how to do certain ones aren't they normative?

3) s4.1: I found this interesting:

  Hopefully the same Selector IDs will be
  maintained after the IANA standardization. 

Is Cisco not planning on maintaining the values?
Also, are you saying you're hoping that the same values will be assigned by IANA?

4) s4.1:  Is 255 reserved?

5) Tables 3 and 4: Characterizing them as collisions seems wrong.  Maybe title them: different protocols on UDP/TCP and SCTP/TCP.  I'm also a little concerned about copying the entire table…maybe you could trim it down to:

  exec              512/tcp
  comsat/biff    512/udp

and leave off the protocol description?

6) s4.4/s4.1: probably worth pointing out in s4.1 that 13 is dumping ground for the lesser support SCTP protocols.

7) s5: Please insert a section reference to where the information elements are defined.

8) Table 5: The tile is "existing …" couldn't you just strike the word existing?

9) s6.4: r/'2..90'/'3..161'

10) BTW - I clicked on ipfix-iana@cisco.com in the IANA registry and got a page doesn't exist response.  I think that's supposed to be a mailto URI?

[Ballot discuss]
What is described in section 2.1 as "congestion control" is definitely NOT.  You could consider it a form of provider "congestion management" ala RFC 6057, but it definitely isn't congestion control (which implies a closed loop end-to-end control algorithm, not an in-network DPI-based management function).

In section 4.4, I do not understand the statement about DCCP ports, since DCCP uses service codes.  Any discussion of DCCP should be in terms of service codes, I believe.

[Ballot comment]

- The reference to http://www.cisco.com/ seems wonderfully
vague, but unfortunately useless. What are the "Cisco
systems assigned numbers"? (I agree with this bit of
Stewart's discuss)

- 2.1: I don't think I buy the congestion control use
case. (While I don't like the security use case, I do
agree others might like it.)

- 4.1: is this encouraging folks to guess what IANA might
allocate for IANA to act? Seems like a bad idea.o

- 4.2: PANA-L* - I don't get how this works.  How can you
assign selector lengths for the PANA-L* in 4.2?

- section 7: I don't get how some ElementId's are assigned
here already but are marked as reserved in the IANA
registry.

- AppA: How is section 7 of an informative document
normative?

[Ballot discuss]
Not withstanding the Discusses and concerns WRT net neutrality and privacy, this is basically a well written document that pragmatically solves a real problem, and I strongly support publication.

From an IETF perspective I think that it is important that it is made clear up front that this documents
a Cisco Proprietryvprotocol and is not an IETF specification.

If there is a plan to produce an IETF ST version of this protocol it would be useful to note that up front.
If that is the case a number of my comments concerning the design should be considered as inputs to the design of the IETF version.

=============

   
                  Export of Application Information in IPFIX
              draft-claise-export-application-info-in-ipfix-07

This draft is a description of a Cisco proprietary protocol and this should
should be reflected in the title and abstrct so that it is clearto readers that this is not  an IETF protocol

----------

      However, a reference to
      the Cisco Systems assigned numbers for the Application Id and
      the different attribute assignments can be found at [CISCO]. 
     
See later comment wrt [CISCO]
.
----------   
   
       
      2. Congestion Control
       
        While traffic demand is increasing (mainly due to the high
        usage of peer to peer applications, video applications and
        web download applications), the providers revenue doesn't
        grow.  Providers are looking at a more efficient way to
        control and prioritize the network utilization.  An
        application aware bandwidth control system is used to
        prioritize the traffic based on the applications, giving
        the critical applications priority over the non-critical
        applications.

This is reality and I acknowledge it, but I think that the IETF has a position on net neutrality if so it  should be referenced and discussed. This text is not needed to describe the protocol, and could easily be removed.

----------
     
                                   
          IANA-L3        1      The IANA protocol (layer 3 (L3))
                                    number is exported in the
                                    Selector ID.
                                    See [IANA-PROTO].

These are actually "Assigned Internet Protocol Numbers"

----------
                                   
          PANA-L3        2      Proprietary layer 3 definition. A
                                    company can export its own layer
                                    3 protocol numbers, while waiting
                                    for IANA to assign it. The
                                    Selector ID has a global
                                    significance for all devices from
                                    the same company. Hopefully the
                                    same Selector IDs will be
                                    maintained after the IANA
                                    standardization.

This is a protocol spec. It needs precision and process, not hope. A better process would be to use early allocation (or FCFS) + a small number of experimental identifiers. Hopefully we will get to the point where we define the company to remove ambiguity.

                                   
-------------
                                   
          PANA-L4        4      Proprietary layer 4 definition. A
                                    company can export its own layer
                                    4 port numbers, while waiting for
                                    IANA to assign it. The Selector
                                    ID has global significance for
                                    devices from the same company.
                                    Hopefully the same Selector IDs
                                    will be maintained after the IANA
                                    standardization. Example: IPFIX
                                    had the port 4739 pre-assigned in
                                    the IETF draft for years. While
                                    waiting for the RFC and its
                                    associated IANA registration, the
                                    Selector ID 4739 was used with
                                    this PANA-L4.

Again no hope allowed. You also need to consider that there is now a split in the port registries by transport protocol type.
                                   
-----------------
       
        Enterprises may assign company-wide Application Id values
        for the PANA-L7 Classification Engine.  In this case, a
        possible optimization for the Collector is to keep the
        mappings between the Application Ids and the Application
        Names per enterprise, as opposed to per Exporter.  The
        mechanism for the Collector to know about Exporter
        enterprise IDs is out of scope of this document.  Possible
        tracks are: SNMP polling, an Options Template export,
        hardcoded value, etc.

SB> ... but if I receive a record how do I know which company
SB> issued it? A collector could receive multiple prop. idents
SB> even from the same monitoring point
       
     
    4.4. Resolving IANA L4 port collisions

        Even though the IANA L4 ports usually point to the same
        protocols for both UDP, TCP or other transport types, there
        are some exceptions.

SB> please specifically this is policy going forward

        The following table lists the 10
        ports that have different protocols assigned for TCP and
        UDP (at the time of writing this document):

SB> The table could usefully have references to the specifications
SB> I am a bit worried about including these lists. Why is
SB> it not adequate to state their existance and point the reader
SB> at the registry?

    7.1.4. classificationEngineId

      Name: classificationEngineId
      Description:
      A unique identifier for the engine which determined the
      Selector ID.  Thus the Classification Engine ID defines the
      context for the Selector ID. The Classification Engine can
      be considered as a specific registry for application
      assignments.
       
      Initial values for this field are listed below. Further
      values may be assigned by IANA in the Classification Engine
      Ids registry.

Using what AS the IANA assignment policy? BTW I am concerned about the type specification  text appearing three times in the RFC, since it raises the question of how to resolve errors       

      and filled it with the initial list from the description
      Information Element #101, classificationEngineId.
     
      New assignments for Classification Engine Ids will be
      administered by IANA through Expert Review [RFC5226], i.e.,
      review by one of a group of experts designated by an IETF Area
      Director.  The group of experts must double check the new
      definitions with already defined Classification Engine Ids for
      completeness, accuracy, and redundancy.  The specification of
      Classification Engine Ids MUST be published using a well-
      established and persistent publication medium.

There is a formal name for this : ER Spec Req. YouCshould just ref the policy by name.
     

    8. Security Considerations

      The same security considerations as for the IPFIX Protocol
      [RFC5101] apply.
     
      As mentioned in Section 2.1. , the application knowledge is
      useful in security based applications.  Security applications
      may impose supplementary requirements on the export of
      application information, and these need to be examined on a
      case by case basis.


SB>  I am suprised that this does not impose even greater  privacy and net neutrality concerns than original IPFIX protocol

[Ballot comment]
        The list in table 1 is maintained by IANA thanks to the
        registry within the classificationEngineId Information
        Element.

Is or will be?

        See the "IANA Considerations" section.  The
        Classification Engine Id is part of the Application Id
        encoding, so the classificationEngineId Information Element
        is currently not required by these specifications. 
        However, this Information Element was created for
        completeness.

I do not understand this. If it is not needed why is it assigned. If the purpose is to create the sub-registry, then why not just create the registry.
         
       
        Application Ids MAY be encoded with a larger length. 
        For example, a normal IANA L3 protocol encoding would take 2
        bytes since the Selector ID represents protocol field from
        the IP header encoded in one byte.  However, an IANA L3
        protocol encoding may be encoded with 3 bytes.  In such a
        case, the Selector ID value MUST always be encoded in the
        least significant bits as shown in Figure 2.

It is not clear why this mode is needed
       
--------

        Instead of imposing the transport protocol
        (UDP/TCP/SCTP/etc.) in the scope of the "Application Name
        Options Template Record" for all applications (on top of
        having the transport protocol as key-field in the Flow Record
        definition), the convention is that the L4 application is
        always TCP related.  So, whenever the Collector has a
        conflict in looking up IANA, it would choose the TCP choice. 
        As a result, the UDP L4 applications from Table 3 and the
        SCTP L4 applications from Table 4 are assigned in the PANA_L7
        Application Id range, i.e. under Classification Engine ID 13.

SB> It would seem to have been better to define the ident as
SB>  Then there would have been no ambiguity.
SB> However this is a prop. spec any it is what it is.
       

            0                  1                  2
            0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
          |      18      |            35020            |
          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       
        So the Application Id has the decimal value of 1214668.

SB> A strange way of thinking of a compound identifier

SB> If it had been me I would have put the long list
SB> of examples in an appendix so as not to distract
SB> from the high level view of the spec.

------------

IANA has a question about the IANA actions requested in this document.

IANA understands that there is a single IANA Action that must be
completed upon approval of this document.

First, in the IPFIX Information Elements subregistry of the IP Flow
Information Export (IPFIX) Entities registry located at:

http://www.iana.org/assignments/ipfix/ipfix.xml

ten new entries are to be added to the registry as follows:

IANA QUESTION --> IANA understands that 10 new IPFIX Information
Elements are being defined. However, not all of the fields that are in
the registry are supplied in the definitions in section 7.1 of the
document. Would the authors like to supply the missing fields or leave
them blank in the new entires for the registry.


IANA understands that the authors have requested specific values for
seven of the ten IPFIX Information Elements defined below. They are:

application Description (requested value: 94)
applicationId (requested value: 95)
applicationName (requested value: 96)
classificationEngineId (requested value: 101)
p2pTechnology (requested value: 288)
tunnelTechnology (requested value: 289)
encryptedTechnology (requested value: 290)

Value: tbd
Name: applicationDescription
Data Type: string
Data Type Semantics:
Status: current
Description:Specifies the description of an application.
Units:
Range:
References:
Requestor:[ RFC-to-be ]

Value: tbd
Name: applicationId
Data Type: octetArray
Data Type Semantics: identifier
Status: current
Description: Specifies an Application Id.
Units:
Range:
References: See section 4. of [ RFC-to-be ] for the applicationId
Information
Element Specification.
Requestor:[ RFC-to-be ]

Value: tbd
Name: applicationName
Data Type: string
Data Type Semantics:
Status: current
Description: Specifies the name of an application.
Units:
Range:
References:
Requestor:[ RFC-to-be ]

Value: tbd
Name: classificationEngineId
Data Type: unsigned8
Data Type Semantics: identifier
Status: current
Description: A unique identifier for the engine which determined the
Selector ID. Thus the Classification Engine ID defines the context for
the Selector ID. The Classification Engine can be considered as a
specific registry for application assignments.
Initial values for this field are listed below. Further values may be
assigned by IANA in the Classification Engine Ids registry.

0 Invalid.

1 IANA-L3: The IANA protocol (layer 3) number is exported in the
Selector ID.
See http://www.iana.org/assignments/protocol-numbers.

2 PANA-L3: Proprietary layer 3 definition. A company can export its own
layer 3 protocol numbers, while waiting for IANA to assign it. The
Selector ID has a global significance for all devices from the same
company. Hopefully the same Selector IDs will be maintained after the
IANA standardization.

3 IANA-L4: The IANA layer 4 well-known port number is exported in the
Selector ID. See http://www.iana.org/assignments/port-numbers. Note:as
an IPFIX flow is unidirectional, it contains the destination port in a
flow from the client to the server.

4 PANA-L4: Proprietary layer 4 definition. A company can export its own
layer 4 port numbers, while waiting for IANA to assign it. The Selector
ID has global significance for devices from the same company. Hopefully
the same Selector IDs will be maintained after the IANA standardization.
Example: IPFIX had the port 4739 pre-assigned in the IETF draft for
years. While waiting for the RFC and its associated IANA registration,
the Selector ID 4739 was used with this PANA-L4.

5 Reserved

6 USER-Defined: The Selector ID represents applications defined by the
user (using CLI or GUI) based on the methods described in section 2. The
Selector ID has a local significance per device.

7 Reserved

8 Reserved

9 Reserved

10 Reserved

11 Reserved

12 PANA-L2: Proprietary layer 2 definition. A company can export its own
layer 2 identifiers. The Selector ID represents the company unique
global layer 2 applications. The Selector ID has a global significance
for all devices from the same company. Examples include Cisco Subnetwork
Access Protocol (SNAP).

13 PANA-L7: Proprietary layer 7 definition. The Selector ID represents
the company unique global ID for the layer 7 applications. The Selector
ID has a global significance for all devices from the company.

14 Reserved

15 Reserved

16 Reserved

17 Reserved

18 ETHERTYPE: The Selector ID represents the well-known Ethertype. See
http://standards.ieee.org/develop/regauth/ethertype/eth.txt. Note that
the Ethertype is usually expressed in hexadecimal. However, the
corresponding decimal value is used in this Selector ID.

19 LLC: The Selector ID represents the well-known IEEE 802.2 Link Layer
Control (LLC) Destination Service Access Point (DSAP). See
http://standards.ieee.org/develop/regauth/ethertype/eth.txt. Note that
LLC DSAP is usually expressed in hexadecimal. However, the corresponding
decimal value is used in this Selector ID.

Units:
Range:
References:
Requestor:[ RFC-to-be ]

Value: tbd
Name: applicationCategoryName
Data Type: string
Data Type Semantics:
Status: current
Description: An attribute that provides a first level categorization for
each Application Id.
Units:
Range:
References:
Requestor:[ RFC-to-be ]

Value: tbd
Name: applicationSubCategoryName
Data Type: string
Data Type Semantics:
Status: current
Description: An attribute that provides a second level categorization
for each Application Id.
Units:
Range:
References:
Requestor:[ RFC-to-be ]

Value: tbd
Name: applicationGroupName
Data Type: string
Data Type Semantics:
Status: current
Description: An attribute that groups multiple Application Ids that
belong to the same networking application.
Units:
Range:
References:
Requestor:[ RFC-to-be ]

Value: tbd
Name: p2pTechnology
Data Type: string
Data Type Semantics:
Status: current
Description: Specifies if the Application Id is based on
peer-to-peertechnology.
Possible values are: { "yes", "y", 1 },{ "no", "n", 2 } and { "unassigned" ,
"u", 0 }.
Units:
Range:
References:
Requestor:[ RFC-to-be ]

Value: tbd
Name:tunnelTechnology
Data Type: string
Data Type Semantics:
Status: current
Description: Specifies if the Application Id is used as a tunnel technology.
Possible values are: { "yes", "y", 1 }, { "no", "n", 2 } and {
"unassigned" ,
"u", 0 }.
Units:
Range:
References:
Requestor:[ RFC-to-be ]

Value: tbd
Name: encryptedTechnology
Data Type: string
Data Type Semantics:
Status: current
Description: Specifies if the Application Id is an encrypted networking
protocol. Possible values are: { "yes", "y", 1 }, { "no", "n", 2 } and {
"unassigned" , "u", 0 }.
Units:
Range:
References:
Requestor:[ RFC-to-be ]

Second, a new subregistry for Information Element #101, named
"Classification Engine identifiers" will be created (in a manner similar
to the existing IPFIX MPLS label types (Value 46)).

IANA will create a new registry for Classification Engine Ids and fill
it with the initial list from the description Information Element #101,
classificationEngineId.

New assignments for Classification Engine Ids will be administered by
IANA through Expert Review [RFC5226], i.e., review by one of a group of
experts designated by an IETF Area Director. The group of experts must
double check the new definitions with already defined Classification
Engine Ids for completeness, accuracy, and redundancy. The specification
of Classification Engine Ids MUST be published using a well-established
and persistent publication medium.

IANA understands these two actions are the only ones required upon
approval of the document.

Note: The actions requested in this document will not be completed
until the document has been approved for publication as an RFC. This
message is only to confirm what actions will be performed.

State changed to In Last Call from Last Call Requested

The following Last Call Announcement was sent out:

From: The IESG

To: IETF-Announce

Reply-To: ietf@ietf.org

Subject: Last Call:  (Export of Application Information in IPFIX) to Informational RFC





The IESG has received a request from an individual submitter to consider

the following document:

- 'Export of Application Information in IPFIX'

  as an

Informational RFC



The IESG plans to make a decision in the next few weeks, and solicits

final comments on this action. Please send substantive comments to the

ietf@ietf.org mailing lists by 2012-04-17. Exceptionally, comments may be

sent to iesg@ietf.org instead. In either case, please retain the

beginning of the Subject line to allow automated sorting.



Abstract





        This document specifies an extension to the IPFIX information

        model specified in [RFC5102] to export application

        information.





   







The file can be obtained via

http://datatracker.ietf.org/doc/draft-claise-export-application-info-in-ipfix/



IESG discussion can be tracked via

http://datatracker.ietf.org/doc/draft-claise-export-application-info-in-ipfix/ballot/





No IPR declarations have been submitted directly on this I-D.

Updated write-up by Nevil Brownlee:

  (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?

Nevil Brownlee.  I read this draft and raised issues on it
earlier, these have been fixed.  I believe it is now ready
for submission to the IESG.

  (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? 

This is an Individual Submission.  However, it has been discussed in
the IPFIX WG, where it received clear support.  In particular,
Chris Inaccio from CERT at Carnegie-Mellon offered to host its
'Proprietary Applications' registry.

  (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?

No.

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

It has no IPR disclosures.  Since it describes a naming scheme for
applications in rather general terms, I don't believe it has any
IPR implications.

  (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? 

The document was originally an Independent Submission documenting
how Cisco handle IPFIX application reporting.  It has now been generalised,
to the point where I think it fits well in the IETF Stream.

  (1.f) 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
        entered into the ID Tracker.)

No.

  (1.g) Has the Document Shepherd personally verified that the
        document satisfies all ID nits? (See the Internet-Drafts Checklist
        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?

Yes.

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

Yes.

  (1.i) Has the Document Shepherd verified that the document IANA
        consideration 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 [RFC5226]. If the
        document describes an Expert Review process has Shepherd
        conferred with the Responsible Area Director so that the IESG
        can appoint the needed Expert during the IESG Evaluation?

Its IANA Considerations section requests a set of new IPFIX Information
Elements from IANA.  These seem sensible to me; this document will
be their reference in the IANA IE Registry.

  (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?

Yes (used W3C's http://validator.w3.org/)

  (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's title is "Export of Application Information in
  IPFIX."  It points out that various vendors implement different
  ways of determining the type of application producing a flow, but
  that we need an RFC-specified way of exporting that information
  using IPFIX.  The document describes a taxonomy of application
  types, ordered by 'classification engine IDs.'  These IDs are
  mostly IANA registries, but the document also proposes new one
  called PANA-Lx (where Lx can be L2, L3 or L4) for Proprietary Layer
  3 definitions.  The intention here is that vendors could publish
  their own sets of Application IDs, so that they would be freely
  available.

    Working Group Summary

  This is an Individual Submission, but - as mentioned above - it has
  been discussed, and received considerable support in the IPFIX
  Working Group.

    Document Quality

  The document does not define a new protocol, instead it defines a
  set of new IPFIX Information IDs; I see no difficulties with these.

- - - - - - - - - -

Shepherding wrte-up by Nevil Brownlee:

  (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?

Nevil Brownlee.  I read this draft and raised issues on it
earlier, these have been fixed.  I believe it is now ready
for submission to the IESG.

  (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? 

This is an Individual Submission.  However, it has been discussed in
the IPFIX WG, where it received clear support.  In particular,
Chris Inaccio from CERT at Carnegie-Mellon offered to host its
'Proprietary Applications' registry.

  (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?

No.

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

It has no IPR disclosures.  Since it describes a naming scheme for
applications in rather general terms, I don't believe it has any
IPR implications.

  (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? 

The document was originally an Independent Submission documenting
how Cisco handle IPFIX application reporting.  It has now been generalised,
to the point where I think it fits well in the IETF Stream.

  (1.f) 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
        entered into the ID Tracker.)

No.

  (1.g) Has the Document Shepherd personally verified that the
        document satisfies all ID nits? (See the Internet-Drafts Checklist
        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?

Yes.

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

Yes.

  (1.i) Has the Document Shepherd verified that the document IANA
        consideration 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 [RFC5226]. If the
        document describes an Expert Review process has Shepherd
        conferred with the Responsible Area Director so that the IESG
        can appoint the needed Expert during the IESG Evaluation?

Its IANA Considerations section requests a set of new IPFIX Information
Elements from IANA.  These seem sensible to me; this document will
be their reference in the IANA IE Registry.

  (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?

Yes (used W3C's http://validator.w3.org/)

  (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
        Relevant content can frequently be found in the abstract
        and/or introduction of the document. If not, this may be
        an indication that there are deficiencies in the abstract
        or introduction.

    Working Group Summary
        Was there anything in WG process that is worth noting? For
        example, was there controversy about particular points or
        were there decisions where the consensus was particularly
        rough?

    Document Quality
        Are there existing implementations of the protocol? Have a
        significant number of vendors indicated their plan to
        implement the specification? Are there any reviewers that
        merit special mention as having done a thorough review,
        e.g., one that resulted in important changes or a
        conclusion that the document had no substantive issues? If
        there was a MIB Doctor, Media Type or other expert review,
        what was its course (briefly)? In the case of a Media Type
        review, on what date was the request posted?

This document's title is "Export of Application Information in IPFIX."
It points out that various vendors implement different ways of
determining the type of application producing a flow, but that we need
an RFC-specified way of exporting that information using IPFIX.  The
document describes a taxonomy of application types, ordered by
'classification engine IDs.'  These IDs are mostly IANA registries,
but the document also proposes new one called PANA-Lx (where Lx can be
L2, L3 or L4) for Proprietary Layer 3 definitions.  The intention here
is that vendors could publish their own sets of Application IDs,
so that they would be freely available.

This is an Individual Submission, but - as mentioned above - it
has been discussed, and received considerable support in the IPFIX
Working Group.

The document does not define a new protocol, instead it defines a
set of new IPFIX Information IDs; I see no difficulties with these.

- - - - - - - - - -