Guidelines for Authors and Reviewers of IP Flow Information Export (IPFIX) Information Elements
draft-ietf-ipfix-ie-doctors-07
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2013-09-04
|
07 | (System) | RFC Editor state changed to AUTH48-DONE from AUTH48 |
2013-08-29
|
07 | (System) | RFC Editor state changed to AUTH48 from RFC-EDITOR |
2013-08-12
|
07 | (System) | RFC Editor state changed to RFC-EDITOR from REF |
2013-08-09
|
07 | (System) | RFC Editor state changed to REF from EDIT |
2013-07-16
|
07 | (System) | RFC Editor state changed to EDIT from MISSREF |
2013-04-24
|
07 | Benoît Claise | Document shepherd changed to Juergen Quittek |
2013-04-09
|
07 | Benoît Claise | Shepherding AD changed to Joel Jaeggli |
2012-12-03
|
07 | Cindy Morgan | State changed to RFC Ed Queue from Approved-announcement sent |
2012-12-03
|
07 | (System) | IANA Action state changed to No IC |
2012-12-03
|
07 | Amy Vezza | State changed to Approved-announcement sent from Approved-announcement to be sent |
2012-12-03
|
07 | Amy Vezza | IESG has approved the document |
2012-12-03
|
07 | Amy Vezza | Closed "Approve" ballot |
2012-12-03
|
07 | Amy Vezza | Ballot approval text was generated |
2012-12-03
|
07 | Amy Vezza | Ballot writeup was changed |
2012-11-25
|
07 | Ron Bonica | State changed to Approved-announcement to be sent from IESG Evaluation::AD Followup |
2012-11-24
|
07 | Adrian Farrel | [Ballot comment] Thanks for addressing my Discuss and Comments. IANA's hold that I had can be released as all IANA actions have been moved to … [Ballot comment] Thanks for addressing my Discuss and Comments. IANA's hold that I had can be released as all IANA actions have been moved to another document. |
2012-11-24
|
07 | Adrian Farrel | [Ballot Position Update] Position for Adrian Farrel has been changed to No Objection from Discuss |
2012-10-03
|
07 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2012-10-03
|
07 | Brian Trammell | New version available: draft-ietf-ipfix-ie-doctors-07.txt |
2012-10-02
|
06 | Roni Even | Request for Telechat review by GENART Completed: Ready. Reviewer: Roni Even. |
2012-09-27
|
06 | Cindy Morgan | State changed to IESG Evaluation::Revised ID Needed from IESG Evaluation |
2012-09-27
|
06 | Adrian Farrel | [Ballot discuss] Updated Discuss further after email exchange with Brian and discussions with Benoit. Please note that I am also holding my Discuss for IANA … [Ballot discuss] Updated Discuss further after email exchange with Brian and discussions with Benoit. Please note that I am also holding my Discuss for IANA to ensure they are fully happy with their actions for this I-D. --- This document appears to update RFC 5102. That RFC defined the registry and sets up the guidelines for expert review of allocation requests.This document is changing those guidelines. Not quite sure how that will fit in when you come to publish I-D.ietf-ipfix-information-model-rfc5102bis, and I know that this I-D has a normative reference to that I-D so they will pop out together. A way to fix this would be to yank all of the IANA stuff and put it in 5102bis. Then this document simply instruct the IE-doctors to ensure the IANA allocation requests match the rules. --- Section 4 o The Information Element MUST be unique within the registry. Its description MUST represent a substantially different meaning from that of any existing Information Element. A proposed Information Element which is a substantial duplicate of an existing Information Element is to be represented using the existing Information Element. Surely this is too subjective. What does "substantially different" actually mean? I tried to rewrite this for you in terms of data type, units, and range, but I think that is probably only a part of what you are talking about. For re-use of an existing Information Element you presumably need those three parameters to be the same, *and* some other quality has to be the same. Depending on the description being similar seems really doubtful. Can you clarify this? --- Section 4 o The Information Element SHOULD be generally applicable to the application at hand, which SHOULD be of general interest to the community. I find this a bit worrying. What are you saying about proposals from outside the IETF? How is the "general interest to the community" to be measured? Are the designated experts called upon to call consensus? --- Section 4.3 defines rules for IANA Allocation of code points. Including notes on the ranges. Is it your intention that the registry is updated to point to this document? If so, you should make that statement in the IANA considerations section. On the other hand, this seems to be a restatement of what is already in the registry, so I wonder whether the section can be left out. --- Doesn't Section 11 give rise to some additional rules that are not captured in the body of the document and (importantly) not in the checklists of Section 7? --- Section 12 Do you need to tell IANA how to populate the Revision and Date fields in the IE registry for IEs that have already been defined? |
2012-09-27
|
06 | Adrian Farrel | [Ballot comment] Comment updated to remove my rant! --- The use of 2119 language seems entirely inappropriate to me. There is nothing to be implemented … [Ballot comment] Comment updated to remove my rant! --- The use of 2119 language seems entirely inappropriate to me. There is nothing to be implemented and no bits on the wire. The designated experts are humans not machines - speak to them in English! --- Section 4.1 o Names of Information Elements SHOULD be descriptive. Why on earth do you want to allow non-descriptive names? --- Section 4.2 Information Elements of type string or octetArray which have length constraints (fixed length, minimum and/or maximum length) MUST note these constraints in their description. The type of an Information Element MUST match the type of the data it represents. More specifically, information that could be represented as a string, but which better matches one of the other data types (e.g. an integral type for a number or enumerated type, an address type for an address) MUST be represented by the best-matching type, even if the data was represented using a different type in the source. In other words, an IPFIX application that exports Options Template Records mapping IP addresses to additional information about each host from an external database MUST use Information Elements of an address type to represent the addresses, even if the source database represented these as strings. Do you need to say that strings and octetArrays must not be used to encode data that would be more properly encoded in other data types perhaps using multiple information elements with a forward pointer to Section 4.5? --- Section 4.3 In general, when adding newly registered Information Elements to the IANA IE registry, IANA SHOULD assign the lowest available Information Element identifier (the value column in [iana-ipfix-assignments]) in the range 128-32767. What does "in general" mean and how is IANA to interpret it? --- Section 4.9 However, for reasons of history, there are several Information Elements within the IANA IE registry which do not follow best practices in Information Element design. These Information Elements are not necessarily so flawed so as to require deprecation, but they should be explicitly ignored when looking for guidance as to whether a new Information Element should be added. Now, I know the experts are experts, and it is completely obvious to them which IEs don't follow best practices, but the poor fool building a new spec is being asked for a rock. Can you not list the IEs that should be ignored? --- Section 6 Due to the limited number space of Information Elements in the IANA IE registry, avoiding redundancy and clutter in the registry is important in defining new applications. Nah! I agree that avoiding redundancy and clutter are a good idea, but you cannot say that the IE has such limited space that this is the reason. Look, you have assigned fewer than 375 out of 32767 identifiers. If it fills up in the next 20 years I will buy you a bottle. |
2012-09-27
|
06 | Adrian Farrel | Ballot comment and discuss text updated for Adrian Farrel |
2012-09-27
|
06 | Gonzalo Camarillo | [Ballot Position Update] New position, No Objection, has been recorded for Gonzalo Camarillo |
2012-09-27
|
06 | Adrian Farrel | [Ballot discuss] Updated first point of the Discuss after conversation with Ron Bonica. I found rather a number of issues. I have tried to split … [Ballot discuss] Updated first point of the Discuss after conversation with Ron Bonica. I found rather a number of issues. I have tried to split them between my Discuss and Comment according to their magnitude. Inevitably I will have got this wrong, so please debate them with me. --- This document appears to update RFC 5102. That RFC defined the registry and sets up the guidelines for expert review of allocation requests.This document is changing those guidelines. Not quite sure how that will fit in when you come to publish I-D.ietf-ipfix-information-model-rfc5102bis, and I know that this I-D has a normative reference to that I-D so they will pop out together. A way to fix this would be to yank all of the IANA stuff and put it in 5102bis. Then this document simply instruct the IE-doctors to ensure the IANA allocation requests match the rules. --- Section 4 o The Information Element MUST be unique within the registry. Its description MUST represent a substantially different meaning from that of any existing Information Element. A proposed Information Element which is a substantial duplicate of an existing Information Element is to be represented using the existing Information Element. Surely this is too subjective. What does "substantially different" actually mean? I tried to rewrite this for you in terms of data type, units, and range, but I think that is probably only a part of what you are talking about. For re-use of an existing Information Element you presumably need those three parameters to be the same, *and* some other quality has to be the same. Depending on the description being similar seems really doubtful. Can you clarify this? --- Section 4 o The Information Element SHOULD contain minimal internal structure; Do you mean "minimal". I suppose you use this in the meaning "the least possible". Given the existence of parallel export and Structured Data, is there any reason not to interpret this statement as: you must only use a single Abstract Data Type. Of course, you may be attempting to also control the definition of new Abstract Data Types, but if so, you probably ought to call that out. --- Section 4 o The Information Element SHOULD be generally applicable to the application at hand, which SHOULD be of general interest to the community. I find this a bit worrying. What are you saying about proposals from outside the IETF? How is the "general interest to the community" to be measured? Are the designated experts called upon to call consensus? --- Section 4.3 defines rules for IANA Allocation of code points. Including notes on the ranges. Is it your intention that the registry is updated to point to this document? If so, you should make that statement in the IANA considerations section. On the other hand, this seems to be a restatement of what is already in the registry, so I wonder whether the section can be left out. --- Doesn't Section 11 give rise to some additional rules that are not captured in the body of the document and (importantly) not in the checklists of Section 7? --- Section 12 Do you need to tell IANA how to populate the Revision and Date fields in the IE registry for IEs that have already been defined? |
2012-09-27
|
06 | Adrian Farrel | Ballot discuss text updated for Adrian Farrel |
2012-09-27
|
06 | Ralph Droms | [Ballot Position Update] New position, No Objection, has been recorded for Ralph Droms |
2012-09-26
|
06 | Wesley Eddy | [Ballot Position Update] New position, No Objection, has been recorded for Wesley Eddy |
2012-09-26
|
06 | Pete Resnick | [Ballot comment] The abstract tries to jam everything into a single convoluted sentence, and I think it ends up being completely unclear. I make a … [Ballot comment] The abstract tries to jam everything into a single convoluted sentence, and I think it ends up being completely unclear. I make a suggestion here, but I'm not sure I've captured what needs to be captured. The WG needs to check this: This document provides guidelines for how to write definitions of new Information Elements for the IP Flow Information Export (IPFIX) protocol. It provides instructions on using the proper conventions for Information Elements to be registered in the IANA IPFIX Information Element registry, and provides guidelines for expert reviewers to evaluate new registrations. I'll leave it to the authors to rewrite section 1 along the same lines. In section 1.1, I think you specifically need to mention people who write new IEs and *not* talk about "extending the applicability of IPFIX", as that confused the issue. I also find the use of the word "application" a bit odd here, and I've substituted "use case", but if "application" is understood in this community, that is fine. So, maybe something like: This document is meant for two separate audiences. For those wishing to write new Information Element specifications, it provides guidelines for how to decide which Information Elements are necessary for a given existing or new use case, instructions for writing the Information Element specification to be registered, and information on the kinds of documentation that will be required for the use case (up to and including publication of a new RFC). For the IPFIX experts... 2. Regarding 2119: I agree with Adrian that the use of 2119 language in this document is wrong, and verges on downright silly. This document is not talking about protocol requirements, or even documentation requirements that need to be followed for interoperability purposes. So for instance, section 4.1 says, "Information Element Names should be defined in accordance with section 2.3 of [I-D.ietf-ipfix-information-model-rfc5102bis]" and then goes on to give some conventions as MUSTs and SHOULDs. But if we look at ietf-ipfix-information-model-rfc5102bis, we find: The following naming conventions were used for naming Information Elements in this document. It is recommended that extensions of the model use the same conventions. So even the MUSTs are not requirements, but recommended naming conventions for extensions. I really think you should get rid of all of the 2119 language. That said, you'll note that this is in a COMMENT. I think for the most part, while useless and silly (it sounds like you are trying to be protocol police), using 2119 in this document is generally not harmful. I am most worried about the use of 2119 to control IANA actions (e.g., 4.3), but even there, disaster is unlikely. So I do beg with you to revisit your decision to use 2119 in this document; I think it adds nothing and detracts from the understanding of 2119 in other documents. But I will not insist on DISCUSSing this with the IESG. |
2012-09-26
|
06 | Pete Resnick | [Ballot Position Update] New position, No Objection, has been recorded for Pete Resnick |
2012-09-26
|
06 | Adrian Farrel | [Ballot discuss] I found rather a number of issues. I have tried to split them between my Discuss and Comment according to their magnitude. Inevitably … [Ballot discuss] I found rather a number of issues. I have tried to split them between my Discuss and Comment according to their magnitude. Inevitably I will have got this wrong, so please debate them with me. --- This document clearly updates RFC 5102. That RFC defined the registry and set up the guidelines for expert review of allocation requests. This document is changing those guidelines. Not quite sure how that will fit in when you come to publish I-D.ietf-ipfix-information-model-rfc5102bis, and I know that this I-D has a normative reference to that I-D so they will pop out together. --- Section 4 o The Information Element MUST be unique within the registry. Its description MUST represent a substantially different meaning from that of any existing Information Element. A proposed Information Element which is a substantial duplicate of an existing Information Element is to be represented using the existing Information Element. Surely this is too subjective. What does "substantially different" actually mean? I tried to rewrite this for you in terms of data type, units, and range, but I think that is probably only a part of what you are talking about. For re-use of an existing Information Element you presumably need those three parameters to be the same, *and* some other quality has to be the same. Depending on the description being similar seems really doubtful. Can you clarify this? --- Section 4 o The Information Element SHOULD contain minimal internal structure; Do you mean "minimal". I suppose you use this in the meaning "the least possible". Given the existence of parallel export and Structured Data, is there any reason not to interpret this statement as: you must only use a single Abstract Data Type. Of course, you may be attempting to also control the definition of new Abstract Data Types, but if so, you probably ought to call that out. --- Section 4 o The Information Element SHOULD be generally applicable to the application at hand, which SHOULD be of general interest to the community. I find this a bit worrying. What are you saying about proposals from outside the IETF? How is the "general interest to the community" to be measured? Are the designated experts called upon to call consensus? --- Section 4.3 defines rules for IANA Allocation of code points. Including notes on the ranges. Is it your intention that the registry is updated to point to this document? If so, you should make that statement in the IANA considerations section. On the other hand, this seems to be a restatement of what is already in the registry, so I wonder whether the section can be left out. --- Doesn't Section 11 give rise to some additional rules that are not captured in the body of the document and (importantly) not in the checklists of Section 7? --- Section 12 Do you need to tell IANA how to populate the Revision and Date fields in the IE registry for IEs that have already been defined? |
2012-09-26
|
06 | Adrian Farrel | [Ballot comment] Just to let the shepherding AD know that it isn't very nice to find: Capitalized terms used in this document that are … [Ballot comment] Just to let the shepherding AD know that it isn't very nice to find: Capitalized terms used in this document that are defined in the Terminology section of [I-D.ietf-ipfix-protocol-rfc5101bis] are to be interpreted as defined there. when the referenced I-D is not yet stable enough to receive a publication request. Nothing the authors can do except realise that any change to the referenced document may break this document. --- The use of 2119 language seems entirely inappropriate to me. There is nothing to be implemented and no bits on the wire. The designated experts are humans not machines - speak to them in English! --- Section 3, while providing a useful refresher on IPFIX seems to be out of scope for the document. It could be entirely removed without harming the document. --- Section 4.1 o Names of Information Elements SHOULD be descriptive. Why on earth do you want to allow non-descriptive names? --- Section 4.2 Information Elements of type string or octetArray which have length constraints (fixed length, minimum and/or maximum length) MUST note these constraints in their description. The type of an Information Element MUST match the type of the data it represents. More specifically, information that could be represented as a string, but which better matches one of the other data types (e.g. an integral type for a number or enumerated type, an address type for an address) MUST be represented by the best-matching type, even if the data was represented using a different type in the source. In other words, an IPFIX application that exports Options Template Records mapping IP addresses to additional information about each host from an external database MUST use Information Elements of an address type to represent the addresses, even if the source database represented these as strings. Do you need to say that strings and octetArrays must not be used to encode data that would be more properly encoded in other data types perhaps using multiple information elements with a forward pointer to Section 4.5? --- Section 4.3 In general, when adding newly registered Information Elements to the IANA IE registry, IANA SHOULD assign the lowest available Information Element identifier (the value column in [iana-ipfix-assignments]) in the range 128-32767. What does "in general" mean and how is IANA to interpret it? --- Section 4.9 However, for reasons of history, there are several Information Elements within the IANA IE registry which do not follow best practices in Information Element design. These Information Elements are not necessarily so flawed so as to require deprecation, but they should be explicitly ignored when looking for guidance as to whether a new Information Element should be added. Now, I know the experts are experts, and it is completely obvious to them which IEs don't follow best practices, but the poor fool building a new spec is being asked for a rock. Can you not list the IEs that should be ignored? --- Section 6 Due to the limited number space of Information Elements in the IANA IE registry, avoiding redundancy and clutter in the registry is important in defining new applications. Nah! I agree that avoiding redundancy and clutter are a good idea, but you cannot say that the IE has such limited space that this is the reason. Look, you have assigned fewer than 375 out of 32767 identifiers. If it fills up in the next 20 years I will buy you a bottle. |
2012-09-26
|
06 | Adrian Farrel | [Ballot Position Update] New position, Discuss, has been recorded for Adrian Farrel |
2012-09-26
|
06 | Barry Leiba | [Ballot comment] The beginning of the document, through the beginning of Section 3 (end of page 5), very strongly smells like an Applicability Statement, which … [Ballot comment] The beginning of the document, through the beginning of Section 3 (end of page 5), very strongly smells like an Applicability Statement, which should be on Standards Track. Completion of review and further discussion supports BCP, but it will help to clarify the text up to page 5. Pete has promised specific comments for that, so I'll leave them to him, but I'm happy to help with it as well. |
2012-09-26
|
06 | Barry Leiba | [Ballot Position Update] Position for Barry Leiba has been changed to No Objection from Discuss |
2012-09-26
|
06 | Sean Turner | [Ballot Position Update] New position, No Objection, has been recorded for Sean Turner |
2012-09-26
|
06 | Stewart Bryant | [Ballot comment] Thank you for addressing my concerns. |
2012-09-26
|
06 | Stewart Bryant | [Ballot Position Update] Position for Stewart Bryant has been changed to Yes from Discuss |
2012-09-26
|
06 | Stephen Farrell | [Ballot Position Update] Position for Stephen Farrell has been changed to No Objection from Discuss |
2012-09-26
|
06 | Brian Trammell | New version available: draft-ietf-ipfix-ie-doctors-06.txt |
2012-09-26
|
05 | Brian Haberman | [Ballot Position Update] New position, No Objection, has been recorded for Brian Haberman |
2012-09-26
|
05 | Stephen Farrell | [Ballot discuss] (1) 4.3: Why does a CISCO-specific informational RFC end up generating a MUST NOT in a BCP with a set of experts for … [Ballot discuss] (1) 4.3: Why does a CISCO-specific informational RFC end up generating a MUST NOT in a BCP with a set of experts for the vendor-specific protocol whose views are "exempt" from review by the reviewers for the IETF standards track protocol? I don't understand why that's appropriate. I would suggest just deleting the last paragraph of 4.3 entirely. Same for the last para of 5.2 and the 3rd last in 5.3 and in section 7, checklist 1, point 8, and section 7, checklist 2, item 10. In an offlist conversation with Ron we figured the changes below might suffice - they look good to me but I need to just check they hits all the bits and make sure they're clear enough for an editor. OLD< Information Element identifiers in the range 1-127 MUST NOT be assigned unless the Information Element is compatible with the NetFlow V9 protocol as described in [RFC3954]. Such Information Elements may ONLY be requested by a NetFlow v9 expert, to be designated by the IESG to consult with IANA on NetFlow v9 compatibility with IPFIX. These information elements are exempt from IE-DOCTORS review; it is the responsibility of the NetFlow v9 expert to ensure that the requested IEs substantially conform to the guidelines in this document, with consideration given for already- implemented and already-deployed features. Information Element identifiers in the range 1-127 MUST NOT be assigned. These are used by Netflow V9 [RFC3954], a pre-standard version of IPFIX Information Elements with identifiers in the range 1-127 are compatible with the NetFlow V9 protocol as described in [RFC3954]; to maintain this compatibility, all deprecations of such Information Elements are subject to additional review by the appointed NetFlow V9 expert. OLD> NEW> Information Elements with identifiers in the range 1-127 are compatible with the NetFlow V9 protocol as described in [RFC3954]; to maintain this compatibility, all deprecations of such Information Elements are subject to additional review by the appointed NetFlow V9 expert. <NEW (2) 5.2 & 5.3: I hope you've convinced yourself that this set of rules don't allow the IE-doctors to overrule IETF consensus, even in an interoperable manner. That's not clear to me. I think you ought say that explicitly, i.e. "These rules do not allow IE-doctors to override or change IETF consensus" or however you'd rather say that. |
2012-09-26
|
05 | Stephen Farrell | [Ballot comment] - general: are you missing a meta-guideline for experts? E.g.: "don't add things gratuituously but try get folks to re-use what's there" - … [Ballot comment] - general: are you missing a meta-guideline for experts? E.g.: "don't add things gratuituously but try get folks to re-use what's there" - 1.2: the "EDITOR's NOTE" should be gone by now I would have thought. Did that review happen? - section 4: "MUST be sufficiently unique" is odd 2119 language but since I can understand it fine, that's ok IMO. Others might not agree. Same goes for a bunch of other uses of 2119 language in this draft. - 4.1: Why do you care about camelCase? Seems like a bad MUST to me, a SHOULD at most, esp. since you do say there can be exceptions. And is "6" a "letter" or not in this context? How about Eszett:-) - 4.9: I love the section title! - 4.9: The "EDITOR'S NOTE" should be gone already. - 7: depending on your reaction to the comments above, you might need to make some change in this section. - section 10 seems like a protocol spec. Why is it here and not in a separate document? I think it really ought be. |
2012-09-26
|
05 | Stephen Farrell | Ballot comment and discuss text updated for Stephen Farrell |
2012-09-25
|
05 | Stephen Farrell | [Ballot discuss] - 4.3: Why does a CISCO-specific informational RFC end up generating a MUST NOT in a BCP with a set of experts for … [Ballot discuss] - 4.3: Why does a CISCO-specific informational RFC end up generating a MUST NOT in a BCP with a set of experts for the vendor-specific protocol whose views are "exempt" from review by the reviewers for the IETF standards track protocol? I don't understand why that's appropriate. I would suggest just deleting the last paragraph of 4.3 entirely. Same for the last para of 5.2 and the 3rd last in 5.3 and in section 7, checklist 1, point 8, and section 7, checklist 2, item 10. - 5.2 & 5.3: I hope you've convinced yourself that this set of rules don't allow the IE-doctors to overrule IETF consensus, even in an interoperable manner. That's not clear to me. I think you ought say that explicitly, i.e. "These rules do not allow IE-doctors to override or change IETF consensus" or however you'd rather say that. |
2012-09-25
|
05 | Stephen Farrell | [Ballot comment] - general: are you missing a meta-guideline for experts? E.g.: "don't add things gratuituously but try get folks to re-use what's there" - … [Ballot comment] - general: are you missing a meta-guideline for experts? E.g.: "don't add things gratuituously but try get folks to re-use what's there" - 1.2: the "EDITOR's NOTE" should be gone by now I would have thought. Did that review happen? - section 4: "MUST be sufficiently unique" is odd 2119 language but since I can understand it fine, that's ok IMO. Others might not agree. Same goes for a bunch of other uses of 2119 language in this draft. - 4.1: Why do you care about camelCase? Seems like a bad MUST to me, a SHOULD at most, esp. since you do say there can be exceptions. And is "6" a "letter" or not in this context? How about Eszett:-) - 4.9: I love the section title! - 4.9: The "EDITOR'S NOTE" should be gone already. - 7: depending on your reaction to the comments above, you might need to make some change in this section. - section 10 seems like a protocol spec. Why is it here and not in a separate document? I think it really ought be. |
2012-09-25
|
05 | Stephen Farrell | [Ballot Position Update] New position, Discuss, has been recorded for Stephen Farrell |
2012-09-25
|
05 | Robert Sparks | [Ballot Position Update] New position, No Objection, has been recorded for Robert Sparks |
2012-09-25
|
05 | Stewart Bryant | [Ballot discuss] I am a little concerned about the advice in Section 4 bullet 2 as being interpreted closer to a MUST than a MAY. … [Ballot discuss] I am a little concerned about the advice in Section 4 bullet 2 as being interpreted closer to a MUST than a MAY. Surely the important think is that the Reviewer consider this in the context of the application and then does the right thing for the application and its context. I think that it would be useful if advice to that effect was more prominent in the document that is currently the case. As I read the advice it is very much written from the traditional use/flow reporting perspective, rather than from the point of view of a general use push protocol, and this conservative approach I think limits the potential of the IPFIX protocol. |
2012-09-25
|
05 | Stewart Bryant | [Ballot Position Update] New position, Discuss, has been recorded for Stewart Bryant |
2012-09-25
|
05 | Martin Stiemerling | [Ballot Position Update] New position, No Objection, has been recorded for Martin Stiemerling |
2012-09-24
|
05 | Russ Housley | [Ballot Position Update] New position, No Objection, has been recorded for Russ Housley |
2012-09-23
|
05 | Barry Leiba | [Ballot discuss] I have to finish reviewing this document, but I wanted to get this in as early as possible, so it can be responded … [Ballot discuss] I have to finish reviewing this document, but I wanted to get this in as early as possible, so it can be responded to. This document, at least through the beginning of Section 3, very strongly smells like an Applicability Statement, which should be on Standards Track. RFC 5472 (which is actually *titled* "Applicability Statement") was published as Informational, and should also have been Standards Track as the Applicability Statement that it is, but that's history now. We can, though, do this one right. I believe that the information given here (and in 5472) is information that should be considered to define standards for network operation & management, and that should be progressed along the Standards Track as it gets deployment and use, and matures. The shepherd writeup doesn't help: it just says that this is a BCP, which I can see from the header, and says nothing about *why* BCP is appropriate, and nothing about the working group's discussion on the matter. |
2012-09-23
|
05 | Barry Leiba | [Ballot Position Update] New position, Discuss, has been recorded for Barry Leiba |
2012-09-20
|
05 | Jean Mahoney | Request for Telechat review by GENART is assigned to Roni Even |
2012-09-20
|
05 | Jean Mahoney | Request for Telechat review by GENART is assigned to Roni Even |
2012-09-20
|
05 | Ron Bonica | Placed on agenda for telechat - 2012-09-27 |
2012-09-20
|
05 | Ron Bonica | State changed to IESG Evaluation from Waiting for AD Go-Ahead |
2012-09-19
|
05 | Benoît Claise | New version available: draft-ietf-ipfix-ie-doctors-05.txt |
2012-08-31
|
04 | Brian Trammell | New version available: draft-ietf-ipfix-ie-doctors-04.txt |
2012-07-23
|
03 | Benoît Claise | [Ballot Position Update] Position for Benoit Claise has been changed to Recuse from Abstain |
2012-07-17
|
03 | (System) | State changed to Waiting for AD Go-Ahead from In Last Call |
2012-07-16
|
03 | Pearl Liang | IANA has reviewed draft-ietf-ipfix-ie-doctors-03 and has the following comments: IANA understands that, upon approval of this document, there are three IANA actions which must be … IANA has reviewed draft-ietf-ipfix-ie-doctors-03 and has the following comments: IANA understands that, upon approval of this document, there are three IANA actions which must be completed. First, IANA has worked with the authors to understand and implement the updated expert review process for the IPFIX Information Element registry and its related subregistries. Upon approval of this document, IANA will work with the IESG and the authors to implement the process outlined in section 5.1, 5.2 and 5.3 of the current draft. Second, the IPFIX Information Elements registry located at: http://www.iana.org/assignments/ipfix/ipfix.xml will be modified to add three columns. Those new columns are specified in section 12 of the current draft and are: Revision: a serial revision number for each Information Element, beginning at 0 for all presently existing and newly created Information Elements. Date: the date at which the Information Element was created or last modified. Enterprise-specific reference: for Information Elements which where deployed as enterprise-specific Information Elements for experimentation and testing, and subsequently registered in the IANA registry, specifies the private enterprise number (PEN)/IE number pair(s) of the equivalent experimental Information Element(s). Third, IANA understands that this document updates the procedure for IPFIX Information Element assignment and thus in the IANA Matrix at: http://www.iana.org/protocols/ and in the IPFIX Information Element registry located at: http://www.iana.org/assignments/ipfix/ipfix.xml the references to RFC 5102 will be updated to [RFC-to-be]. IANA understands these three actions are the only ones that need to be completed upon approval of this 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. |
2012-07-15
|
03 | Roni Even | Request for Last Call review by GENART Completed. Reviewer: Roni Even. |
2012-07-13
|
03 | Samuel Weiler | Request for Last Call review by SECDIR Completed. Reviewer: Yoav Nir. |
2012-07-11
|
03 | Benoît Claise | [Ballot Position Update] New position, Abstain, has been recorded for Benoit Claise |
2012-07-11
|
03 | Ron Bonica | Ballot has been issued |
2012-07-11
|
03 | Ron Bonica | [Ballot Position Update] New position, Yes, has been recorded for Ronald Bonica |
2012-07-11
|
03 | Ron Bonica | Created "Approve" ballot |
2012-07-05
|
03 | Samuel Weiler | Request for Last Call review by SECDIR is assigned to Yoav Nir |
2012-07-05
|
03 | Samuel Weiler | Request for Last Call review by SECDIR is assigned to Yoav Nir |
2012-07-05
|
03 | Jean Mahoney | Request for Last Call review by GENART is assigned to Roni Even |
2012-07-05
|
03 | Jean Mahoney | Request for Last Call review by GENART is assigned to Roni Even |
2012-07-03
|
03 | Amy Vezza | The following Last Call announcement was sent out: From: The IESG To: IETF-Announce CC: Reply-To: ietf@ietf.org Subject: Last Call: (Guidelines for Authors and Reviewers of … The following Last Call announcement was sent out: From: The IESG To: IETF-Announce CC: Reply-To: ietf@ietf.org Subject: Last Call: (Guidelines for Authors and Reviewers of IPFIX Information Elements) to Best Current Practice The IESG has received a request from the IP Flow Information Export WG (ipfix) to consider the following document: - 'Guidelines for Authors and Reviewers of IPFIX Information Elements' as Best Current Practice 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-07-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 provides guidelines for the definition of IPFIX Information Elements for addition to the IANA IPFIX Information Element registry, in order to extend the applicability of the IPFIX protocol to new operations and management areas. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-ipfix-ie-doctors/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-ipfix-ie-doctors/ballot/ No IPR declarations have been submitted directly on this I-D. |
2012-07-03
|
03 | Amy Vezza | State changed to In Last Call from Last Call Requested |
2012-07-03
|
03 | Ron Bonica | Last call was requested |
2012-07-03
|
03 | Ron Bonica | Last call announcement was generated |
2012-07-03
|
03 | Ron Bonica | Ballot approval text was generated |
2012-07-03
|
03 | Ron Bonica | State changed to Last Call Requested from AD Evaluation |
2012-07-03
|
03 | Ron Bonica | State changed to AD Evaluation from Publication Requested |
2012-07-03
|
03 | Ron Bonica | Ballot writeup was changed |
2012-07-03
|
03 | Ron Bonica | Ballot writeup was generated |
2012-06-25
|
03 | Cindy Morgan | (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? … (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? The requested type is BCP as stated in the title page header. (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 provides guidelines for the definition of IPFIX Information Elements for addition to the IANA IPFIX Information Element registry, in order to extend the applicability of the IPFIX protocol to new operations and management areas. Working Group Summary This draft has been discussed already at WG sessions and on the mailing list for along time before adopting it as WG work item. There was strong consensus on the need for such a document and on the general content. Details has been discussed extensively. WGLC was conducted in February 2012. Raise issues in the LC Phase were discussed and fixed. Document Quality This BCP for IPFIX IE doctors summarizes experiences gained in several years of dealing with new proposals for IEs. Personnel By default, Benoit Claise would be the responsible area director. But since Benoit Claise is co-author of the draft, the responsible area director is Ron Bonica. Document shepherd is Juergen Quittek. (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? No. (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. No. (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 understand and agree 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. The document uses 'NOT RECOMMENDED' as an RFC 2119 keyword, but does not include the phrase in its RFC 2119 key words list. This can be fixed 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. (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 are two: - draft-ietf-ipfix-protocol-rfc5101bis-01 - draft-ietf-ipfix-information-model-rfc5102bis-01 Both are on the IPFIX WG charter and currently progressing in the WG. (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. No. (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). The draft defines a process for IANA and extends an IANA registry. Both issues are well documented in the IANA considerations section. (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 registries that require expert review requested by this draft. (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. |
2012-06-25
|
03 | Cindy Morgan | Note added 'Juergen Quittek (Quittek@neclab.eu) is the document shepherd.' |
2012-06-25
|
03 | Cindy Morgan | Intended Status changed to Best Current Practice |
2012-06-25
|
03 | Cindy Morgan | IESG process started in state Publication Requested |
2012-06-25
|
03 | (System) | Earlier history may be found in the Comment Log for draft-trammell-ipfix-ie-doctors |
2012-06-11
|
03 | Brian Trammell | New version available: draft-ietf-ipfix-ie-doctors-03.txt |
2012-03-07
|
02 | Brian Trammell | New version available: draft-ietf-ipfix-ie-doctors-02.txt |
2012-02-10
|
01 | (System) | New version available: draft-ietf-ipfix-ie-doctors-01.txt |
2011-11-21
|
00 | (System) | New version available: draft-ietf-ipfix-ie-doctors-00.txt |