IPv6 Destination Option for Congestion Exposure (ConEx)
draft-ietf-conex-destopt-12
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2016-05-11
|
12 | (System) | RFC Editor state changed to AUTH48-DONE from AUTH48 |
2016-03-28
|
12 | (System) | RFC Editor state changed to AUTH48 from RFC-EDITOR |
2016-03-15
|
12 | (System) | RFC Editor state changed to RFC-EDITOR from IANA |
2016-03-03
|
12 | (System) | RFC Editor state changed to IANA from EDIT |
2016-02-03
|
12 | (System) | IANA Action state changed to No IC from Waiting on Authors |
2016-01-25
|
12 | (System) | IANA Action state changed to Waiting on Authors from In Progress |
2016-01-21
|
12 | (System) | RFC Editor state changed to EDIT |
2016-01-21
|
12 | (System) | IESG state changed to RFC Ed Queue from Approved-announcement sent |
2016-01-21
|
12 | (System) | Announcement was received by RFC Editor |
2016-01-20
|
12 | (System) | IANA Action state changed to In Progress |
2016-01-20
|
12 | Amy Vezza | IESG state changed to Approved-announcement sent from Approved-announcement to be sent |
2016-01-20
|
12 | Amy Vezza | IESG has approved the document |
2016-01-20
|
12 | Amy Vezza | Closed "Approve" ballot |
2016-01-20
|
12 | Amy Vezza | Ballot approval text was generated |
2016-01-20
|
12 | Martin Stiemerling | Ballot writeup was changed |
2016-01-20
|
12 | Martin Stiemerling | IESG state changed to Approved-announcement to be sent from IESG Evaluation::AD Followup |
2016-01-19
|
12 | Brian Haberman | [Ballot Position Update] Position for Brian Haberman has been changed to No Objection from Discuss |
2016-01-17
|
12 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2016-01-17
|
12 | Suresh Krishnan | New version available: draft-ietf-conex-destopt-12.txt |
2016-01-10
|
11 | Kathleen Moriarty | [Ballot comment] Prior discuss, thank you for addressing it in the pending version: I think this should be easy to address, but wanted to discuss … [Ballot comment] Prior discuss, thank you for addressing it in the pending version: I think this should be easy to address, but wanted to discuss options for the text in section 7. Since there is text that says IPsec Authentication should be used when integrity protection and the section goes on to also discuss encryption, shouldn't there be a similar statement that says IPsec encryption should be used when there is a need to protect confidentiality? Also, in reading this, I think because of the selected wording, I was thinking that it wasn't clear enough on the need/recommendation for authentication or encryption with IPsec since there are options for both to be set to NULL/none. You can have a NULL cipher-suite and you can also have authentication set to none to allow for opportunistic security negotiations (fairly new RFC for the latter). There's no need to mention these options explicitly, but rather to make it clear that IPsec can be used to provide authentication and encryption. So I think one additional sentence and some possible rewording in this section would be helpful. Prior comments: For the Security Considerations section, I'd just ask that you add in "IPsec" when AH and ESP are first mentioned so this is clear. |
2016-01-10
|
11 | Kathleen Moriarty | [Ballot Position Update] Position for Kathleen Moriarty has been changed to No Objection from Discuss |
2015-12-14
|
11 | Robert Sparks | Request for Last Call review by GENART Completed: Ready. Reviewer: Robert Sparks. |
2015-12-09
|
11 | Martin Stiemerling | IESG state changed to IESG Evaluation::Revised I-D Needed from IESG Evaluation::AD Followup |
2015-10-19
|
11 | Suresh Krishnan | New version available: draft-ietf-conex-destopt-11.txt |
2015-10-19
|
10 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2015-10-19
|
10 | Suresh Krishnan | IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed |
2015-10-19
|
10 | Suresh Krishnan | New version available: draft-ietf-conex-destopt-10.txt |
2015-10-14
|
09 | (System) | Notify list changed from draft-ietf-conex-destopt@ietf.org, draft-ietf-conex-destopt.ad@ietf.org, conex-chairs@ietf.org, "Dirk Kutscher" to (None) |
2015-10-09
|
09 | Gunter Van de Velde | Request for Last Call review by OPSDIR Completed: Has Nits. Reviewer: Scott Bradner. |
2015-10-01
|
09 | Amy Vezza | IESG state changed to IESG Evaluation::Revised I-D Needed from IESG Evaluation |
2015-10-01
|
09 | Jari Arkko | [Ballot comment] The resolution from the Robert Spark's Gen-ART review needs to be folded in to the document before it is approved. Also, as noted … [Ballot comment] The resolution from the Robert Spark's Gen-ART review needs to be folded in to the document before it is approved. Also, as noted in Ron Bonica's Gen-ART review and by Brian Haberman on the IESG review, there is a concern for using Destination Options this way. I wanted to be on record that I too am concerned about that. I'm not blocking on that comment because this is for Experiment RFC. But it is a cause for concern, even with the other option (HBH options) also has downsides. |
2015-10-01
|
09 | Jari Arkko | Ballot comment text updated for Jari Arkko |
2015-10-01
|
09 | Jari Arkko | [Ballot comment] The resolution from the Gen-ART review needs to be folded in to the document before it is approved. |
2015-10-01
|
09 | Jari Arkko | [Ballot Position Update] New position, No Objection, has been recorded for Jari Arkko |
2015-10-01
|
09 | Benoît Claise | [Ballot comment] As mentiond by Scott in his OPS-DIR review: As an experiment this should have few operational concerns for any network not involved in … [Ballot comment] As mentiond by Scott in his OPS-DIR review: As an experiment this should have few operational concerns for any network not involved in the experiment but if the technology becomes standardized at some later time it will add somewhat to the complexity of configuring network devices (i.e. routers). Bottom line, technology-wise this ID seems ready to publish. But I do have some comments on the use of rfc 2119 terminology in the ID. I do not think I’ve seen a case where a document says SHOULD NOT and MAY in the same paragraph referring to the same thing: As with any destination option, an ingress tunnel endpoint will not natively copy the CDO when adding an encapsulating outer IP header. In general an ingress tunnel SHOULD NOT copy the CDO to the outer header as this would changed the number of bytes that would be counted. However, it MAY copy the CDO to the outer header in order to facilitate visibility by subsequent on-path ConEx functions if the configuration of the tunnel ingress and the ConEx nodes is co- ordinated. This trades off the performance of ConEx functions against that of tunnel processing. I suggest that this be reworded to say something like “SHOULD NOT unless xxx, in which case it MAY xxx” The next paragraph says An egress tunnel endpoint SHOULD ignore any CDO on decapsulation of an outer IP header. The information in any inner CDO will always be considered correct, even if it differs from any outer CDO. Therefore, the decapsulator can strip the outer CDO without comparison to the inner. Why is this a SHOULD rather than a MUST? imo, SHOULDs should only be used when there is a known reason that an otherwise MUST behavior might not be followed – in that case the reason should be explained |
2015-10-01
|
09 | Benoît Claise | [Ballot Position Update] New position, No Objection, has been recorded for Benoit Claise |
2015-10-01
|
09 | Joel Jaeggli | [Ballot Position Update] New position, No Objection, has been recorded for Joel Jaeggli |
2015-09-30
|
09 | Barry Leiba | [Ballot Position Update] New position, No Objection, has been recorded for Barry Leiba |
2015-09-30
|
09 | Alvaro Retana | [Ballot comment] Section 4. (ConEx Destination Option (CDO)) defines the Option Length field by saying: "The sender MUST set this field to 1 but ConEx-aware … [Ballot comment] Section 4. (ConEx Destination Option (CDO)) defines the Option Length field by saying: "The sender MUST set this field to 1 but ConEx-aware nodes MUST accept an option length of 1 or more.” Maybe I just don’t understand the subtlety in that statement, but if all the senders use 1, why would the receiver want to accept any other value? To me it just seems like that would be an error/malformed option. |
2015-09-30
|
09 | Alvaro Retana | [Ballot Position Update] New position, No Objection, has been recorded for Alvaro Retana |
2015-09-30
|
09 | Terry Manderson | [Ballot Position Update] New position, No Objection, has been recorded for Terry Manderson |
2015-09-30
|
09 | Stephen Farrell | [Ballot comment] - section 7: "If the transport network cannot be trusted, IPsec Authentication should be used to ensure integrity of the ConEx information." Hmm. … [Ballot comment] - section 7: "If the transport network cannot be trusted, IPsec Authentication should be used to ensure integrity of the ConEx information." Hmm. Transport networks cannot be trusted so the first condition is always met. That means you are saying IPsec should be used. I don't see how the key management required is going to happen and even if it did, would that affect conex calculations? I'm ok with an experiment on that basis though, but it'd be better if the real relationship between this and IPsec were more fully fleshed out somewhere as part of the experiment. - The secdir review [1] touches on similar issues. I'm not sure if that got a response, but it raises a good point that seems to me to deserve a response. [1] https://www.ietf.org/mail-archive/web/secdir/current/msg05957.html |
2015-09-30
|
09 | Stephen Farrell | [Ballot Position Update] New position, No Objection, has been recorded for Stephen Farrell |
2015-09-30
|
09 | Ben Campbell | [Ballot comment] Thanks for including the paragraphs on the purpose of the experiment! There is an IPR declaration that lists this as an "associated draft". … [Ballot comment] Thanks for including the paragraphs on the purpose of the experiment! There is an IPR declaration that lists this as an "associated draft". I'm not sure what to make of that, but it was not mentioned in the shepherd review. IDNits mentions some unused references. |
2015-09-30
|
09 | Ben Campbell | Ballot comment text updated for Ben Campbell |
2015-09-30
|
09 | Alia Atlas | [Ballot comment] I support Brian's Discuss. |
2015-09-30
|
09 | Alia Atlas | [Ballot Position Update] New position, No Objection, has been recorded for Alia Atlas |
2015-09-30
|
09 | Kathleen Moriarty | [Ballot discuss] I think this should be easy to address, but wanted to discuss options for the text in section 7. Since there is text … [Ballot discuss] I think this should be easy to address, but wanted to discuss options for the text in section 7. Since there is text that says IPsec Authentication should be used when integrity protection and the section goes on to also discuss encryption, shouldn't there be a similar statement that says IPsec encryption should be used when there is a need to protect confidentiality? Also, in reading this, I think because of the selected wording, I was thinking that it wasn't clear enough on the need/recommendation for authentication or encryption with IPsec since there are options for both to be set to NULL/none. You can have a NULL cipher-suite and you can also have authentication set to none to allow for opportunistic security negotiations (fairly new RFC for the latter). There's no need to mention these options explicitly, but rather to make it clear that IPsec can be used to provide authentication and encryption. So I think one additional sentence and some possible rewording in this section would be helpful. |
2015-09-30
|
09 | Kathleen Moriarty | [Ballot comment] For the Security Considerations section, I'd just ask that you add in "IPsec" when AH and ESP are first mentioned so this is … [Ballot comment] For the Security Considerations section, I'd just ask that you add in "IPsec" when AH and ESP are first mentioned so this is clear. |
2015-09-30
|
09 | Kathleen Moriarty | [Ballot Position Update] New position, Discuss, has been recorded for Kathleen Moriarty |
2015-09-30
|
09 | Deborah Brungard | [Ballot Position Update] New position, No Objection, has been recorded for Deborah Brungard |
2015-09-30
|
09 | Ben Campbell | [Ballot comment] Thanks for including the paragraphs on the purpose of the experiment! IDNits mentions some unused references. |
2015-09-30
|
09 | Ben Campbell | [Ballot Position Update] New position, No Objection, has been recorded for Ben Campbell |
2015-09-30
|
09 | Brian Haberman | [Ballot discuss] I support the publication of this document given the need for experimentation in this area. However, there is one point that I would … [Ballot discuss] I support the publication of this document given the need for experimentation in this area. However, there is one point that I would like to discuss... Section 3 contains R-1 which says that this marking "needs to be visible to all ConEx-capable nodes on the path." Additionally, Section 5 says that the choice of using an IPv6 Destination Option precludes non-ConEx-capable devices from having to deal with the extension header. However, RFC 2460 clearly says that Destination Options are not inspected by intermediate devices. We all know that a variety of intermediate devices ignore the rule in 2460. Given that, I would like this document to explicitly state that it does not abide by the rule in 2460 so that implementations that do follow 2460 but want to support this approach know to update all their extension header processing code. |
2015-09-30
|
09 | Brian Haberman | [Ballot comment] * Why does the word "foo" appear in the middle of Section 4? * Do you want the Option Type description in Section … [Ballot comment] * Why does the word "foo" appear in the middle of Section 4? * Do you want the Option Type description in Section 4 to have a value = TBD construct so that the IANA-assigned value can be inserted? |
2015-09-30
|
09 | Brian Haberman | [Ballot Position Update] New position, Discuss, has been recorded for Brian Haberman |
2015-09-28
|
09 | Martin Stiemerling | Ballot has been issued |
2015-09-28
|
09 | Martin Stiemerling | [Ballot Position Update] New position, Yes, has been recorded for Martin Stiemerling |
2015-09-28
|
09 | Martin Stiemerling | Created "Approve" ballot |
2015-09-28
|
09 | Martin Stiemerling | Ballot writeup was changed |
2015-09-28
|
09 | Martin Stiemerling | IESG state changed to IESG Evaluation from Waiting for AD Go-Ahead |
2015-09-24
|
09 | Jean Mahoney | Request for Last Call review by GENART is assigned to Robert Sparks |
2015-09-24
|
09 | Jean Mahoney | Request for Last Call review by GENART is assigned to Robert Sparks |
2015-09-23
|
09 | Martin Stiemerling | Changed consensus to Yes from Unknown |
2015-09-23
|
09 | Martin Stiemerling | IESG state changed to Waiting for AD Go-Ahead from Waiting for Writeup |
2015-08-31
|
09 | (System) | IESG state changed to Waiting for Writeup from In Last Call |
2015-08-27
|
09 | Tero Kivinen | Request for Last Call review by SECDIR Completed: Has Issues. Reviewer: Robert Sparks. |
2015-08-26
|
09 | (System) | IANA Review state changed to IANA OK - Actions Needed from IANA - Review Needed |
2015-08-26
|
09 | Amanda Baber | (Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs: IANA has completed its review of draft-ietf-conex-destopt-09. If any part of this review is inaccurate, please let us know. IANA … (Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs: IANA has completed its review of draft-ietf-conex-destopt-09. If any part of this review is inaccurate, please let us know. IANA understands that, upon approval of this document, there is a single action which IANA must complete. In the Destination Options subregistry of the Internet Protocol Version 6 (IPv6) Parameters registry located at: http://www.iana.org/assignments/ipv6-parameters/ a new Destination Option will be registered as follows: Hex Value: [ TBD-at-registration ] Binary Value: act: 00 chg: 0 rest: [ TBD-at-registration ] Description: ConEx Destination Option (CDO) Reference: [ RFC-to-be ] IANA understands that this is the only action required 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. Please note that IANA cannot reserve specific values. However, early allocation is available for some types of registrations. For more information, please see RFC 7120. |
2015-08-26
|
09 | Martin Stiemerling | Placed on agenda for telechat - 2015-10-01 |
2015-08-23
|
09 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Scott Bradner |
2015-08-23
|
09 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Scott Bradner |
2015-08-20
|
09 | Jean Mahoney | Request for Last Call review by GENART is assigned to Robert Sparks |
2015-08-20
|
09 | Jean Mahoney | Request for Last Call review by GENART is assigned to Robert Sparks |
2015-08-20
|
09 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Robert Sparks |
2015-08-20
|
09 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Robert Sparks |
2015-08-17
|
09 | Cindy Morgan | IANA Review state changed to IANA - Review Needed |
2015-08-17
|
09 | Cindy Morgan | The following Last Call announcement was sent out: From: The IESG To: IETF-Announce CC: Reply-To: ietf@ietf.org Sender: Subject: Last Call: (IPv6 Destination Option for Congestion … The following Last Call announcement was sent out: From: The IESG To: IETF-Announce CC: Reply-To: ietf@ietf.org Sender: Subject: Last Call: (IPv6 Destination Option for Congestion Exposure (ConEx)) to Experimental RFC The IESG has received a request from the Congestion Exposure WG (conex) to consider the following document: - 'IPv6 Destination Option for Congestion Exposure (ConEx)' as Experimental 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 2015-08-31. 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 Congestion Exposure (ConEx) is a mechanism by which senders inform the network about the congestion encountered by packets earlier in the same flow. This document specifies an IPv6 destination option that is capable of carrying ConEx markings in IPv6 datagrams. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-conex-destopt/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-conex-destopt/ballot/ The following IPR Declarations may be related to this I-D: https://datatracker.ietf.org/ipr/1922/ |
2015-08-17
|
09 | Cindy Morgan | IESG state changed to In Last Call from Last Call Requested |
2015-08-17
|
09 | Cindy Morgan | Last call announcement was generated |
2015-08-16
|
09 | Martin Stiemerling | Last call was requested |
2015-08-16
|
09 | Martin Stiemerling | Ballot approval text was generated |
2015-08-16
|
09 | Martin Stiemerling | Ballot writeup was generated |
2015-08-16
|
09 | Martin Stiemerling | IESG state changed to Last Call Requested from AD Evaluation::AD Followup |
2015-08-16
|
09 | Martin Stiemerling | Last call announcement was generated |
2015-08-16
|
09 | Martin Stiemerling | Intended Status changed to Experimental from None |
2015-08-05
|
09 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2015-08-05
|
09 | Mirja Kühlewind | New version available: draft-ietf-conex-destopt-09.txt |
2015-05-22
|
08 | Martin Stiemerling | Please find below my AD review of draft-ietf-conex-destopt-08. Editorials: - Please expand ConEx in the title of the draft - Please expand ConEx in the … Please find below my AD review of draft-ietf-conex-destopt-08. Editorials: - Please expand ConEx in the title of the draft - Please expand ConEx in the abstract - Please expand the first occurence of ConEx in Section 1 - Please expand the first occurence of ECN in Section 4, E Bit, and add a reference to ECN here. - Section 4, Figure 1: There is no field called 'reserve' in the figure. Please add such text. - Section 4, paragraph starting with "If the X bit is set..." The text at the end of this paragraph about how long IPv6 headers and what to add, is a bit redundant, as this information is either known, or folks have anyway to read about IPv6. - Section 10, s/encrypting/encapsulating - Section 1, paragraph 2: OLD This document specifies the ConEx wire protocol. NEW This document specifies the ConEx wire protocol for IPv6. - A question: I wonder if it would be good to add a short sentence saying why there is only Conex for IPv6? Just to inform any new reader that is not aware of the WG's history. Questions/Issues: - Section 1, very last sentence of: "Given ConEx is only chartered for IPv6, it might take longer to find a suitable test scenario where only IPv6 traffic is managed using ConEx." I am not sure what this sentence should tell me? - Section 3, paragraph starting with "Choosing to use..." it says "...including policy or audit devices, might have to bury into inner IP headers to find ConEx information." I am not sure if 'bury into' is the right thing to say. In general, I would say "follow the chaing of the (extension-) headers". - Section 4, paragraph starting with "All packets sent over..." it says ConEx-capable connection and we might talk about non-TCP transports that do not have the concept of a connection, isn't it? Do you have any better term than ConEx-capable connection? - Section 4, paragraph starting with "If the X bit is zero..." OLD "should be ignored and forwarded unchanged by network nodes." NEW "MUST be ignored and forwarded unchanged by network nodes." The lower case should does not make any sense here. - Section 4, paragraph starting with "If the X bit is set..." OLD "...three bits (L, E, C) MAY be..." NEW "...three bits (L, E, C) can be..." - Section 4, paragraph starting with "A transport sends credit..." It is not clear to me how a transport sends credit. Any reference or explanation? - Section 4, page 6: OLD "In principle all of these three bits (L, E, C) MAY be set in the..." NEW "In principle all of these three bits (L, E, C) can be set in the" - Section 4, page 6, 2nd paragraph: I am not sure what this sentence means: "For ConEx-aware node processing, the CDO MUST use the Payload length field of the preceding IPv6 header for byte-based accounting. " - Section 4, page 6, 4th paragraph: "However, it can add a CDO header to any packets without one, taking care not to disrupt any integrity or authentication mechanisms." This is easily said, but in general you will run in issues with the MTU, isn't it? - Section 4, page 6, 5th paragraph: "The CDO is only applicable on unicast or anycast packets (see [I-D.ietf-ConEx-abstract-mech] for reasoning)" I cannot find the reasoning for unicast and anycast in draft-ietf-ConEx-abstract-mech. - Section 4, page 6, 6th paragraph: "There are no warning or error messages associated with the CDO." What is the context of this paragraph/sentence? - Section 8: This section does not belong in the core of the draft, as it describes a potential, unproven feature. Either remove Section 8 or mention it in an appendix. Remove any normative language, but give guidance on what experimental implementations and deployments should be doing. - Section 10, last paragraph. What is the rambling about the cover channel use of the reserved field? This is never mentioned before, just here. This is hack. |
2015-05-22
|
08 | Martin Stiemerling | IESG state changed to AD Evaluation::Revised I-D Needed from AD Evaluation |
2015-05-22
|
08 | Martin Stiemerling | IESG state changed to AD Evaluation from AD Evaluation::External Party |
2015-05-08
|
08 | Dirk KUTSCHER | 1. Summary Dirk Kutscher is the document shepherd and Martin Stiemerling the responsible Area Director. This document specifies an IPv6 destination option that is capable … 1. Summary Dirk Kutscher is the document shepherd and Martin Stiemerling the responsible Area Director. This document specifies an IPv6 destination option that is capable of carrying ConEx markings in IPv6 datagrams. The information that is represented by such markings can be used by any element on the path from a sender to a receiver, e.g., for traffic management or egress policing. This mechanism is a key element to ConEX operations, and therefore this document has been selected by the WG as one the essential specifications for ConEX. The intended status in EXPERIMENTAL (as for all ConEX specifications). 2. Review and Consensus There was large consents in the working group to adopt and follow-on with this document as this is a required mechanism to deploy ConEX in IPv6 networks. This document has seen 8 revision and was serval times presented in the working group session. There has been no controversial discussion about the document in the meetings or on the list. The document has received a detailed review by at least on of the experts in the working group. To my knowledge no issues with this document exist. 3. Intellectual Property All authors have confirmed conformance with BCP 78/79 and that there are no IPR disclosures on the document. 4. Other Points The new IPv6 destination option for ConEX needs to be allocated by IANA. The document has an IANA considerations section that explains this precisely. There are few improvements that should be done in the final editing round before publication: --------------- Section 3, paragraph 7 "devices [...] might have to bury into inner IP headers to find ConEx information" -- not whether that "bury" is the right word. "look into"? --------------- Section 4 Option Type: this should be updated after IANA has allocated the option number. --------------- Section 6, paragraph 1 "However, it MAY copy the CDO to the outer in order to facilitate..." -- do you want to say "outer header"? --------------- Section 8 on preferential dropping The second paragraph can still be improved wrt readibility. I think, you should say in the beginning of the paragraph that there can be value in treating ConEX packets preferentially. (Starting with Diffserv PHB is confusing IMO). --------------- These authors agreed to address these suggestions before final publication. Other than that, there are no issues with this document, and it should be published. |
2015-03-27
|
08 | Marcelo Bagnulo | Notification list changed to draft-ietf-conex-destopt@ietf.org, draft-ietf-conex-destopt.ad@ietf.org, conex-chairs@ietf.org, conex@ietf.org, "Dirk Kutscher" <dirk.kutscher@neclab.eu> from draft-ietf-conex-destopt@ietf.org, draft-ietf-conex-destopt.ad@ietf.org, conex-chairs@ietf.org, conex@ietf.org |
2015-03-27
|
08 | Marcelo Bagnulo | Document shepherd changed to Dirk Kutscher |
2015-02-17
|
08 | Cindy Morgan | Notification list changed to draft-ietf-conex-destopt@ietf.org, draft-ietf-conex-destopt.ad@ietf.org, conex-chairs@ietf.org, conex@ietf.org from draft-ietf-conex-destopt@ietf.org, draft-ietf-conex-destopt.ad@ietf.org, conex-chairs@ietf.org, draft-ietf-conex-destopt.shepherd@ietf.org, conex@ietf.org |
2015-02-17
|
08 | Martin Stiemerling | still waiting for the shepherd to be assigned. |
2015-02-17
|
08 | Martin Stiemerling | IESG state changed to AD Evaluation::External Party from AD Evaluation |
2015-02-10
|
08 | Martin Stiemerling | Shepherd write-up and shepherd are missing. Chairs notified. |
2015-02-10
|
08 | Martin Stiemerling | IESG state changed to AD Evaluation from Publication Requested |
2015-02-09
|
08 | Nandita Dukkipati | State Change Notice email list changed to draft-ietf-conex-destopt@ietf.org, draft-ietf-conex-destopt.ad@ietf.org, conex-chairs@ietf.org, draft-ietf-conex-destopt.shepherd@ietf.org, conex@ietf.org |
2015-02-09
|
08 | Nandita Dukkipati | Responsible AD changed to Martin Stiemerling |
2015-02-09
|
08 | Nandita Dukkipati | IETF WG state changed to Submitted to IESG for Publication from WG Document |
2015-02-09
|
08 | Nandita Dukkipati | IESG state changed to Publication Requested |
2015-02-09
|
08 | Nandita Dukkipati | IESG process started in state Publication Requested |
2014-11-10
|
08 | Suresh Krishnan | New version available: draft-ietf-conex-destopt-08.txt |
2014-10-14
|
07 | Suresh Krishnan | New version available: draft-ietf-conex-destopt-07.txt |
2014-02-14
|
06 | Mirja Kühlewind | New version available: draft-ietf-conex-destopt-06.txt |
2013-10-21
|
05 | Suresh Krishnan | New version available: draft-ietf-conex-destopt-05.txt |
2013-03-28
|
04 | Suresh Krishnan | New version available: draft-ietf-conex-destopt-04.txt |
2012-11-22
|
(System) | Posted related IPR disclosure: British Telecommunications plc's statement about IPR claimed in draft-ietf-conex-abstract-mech-06 | |
2012-09-24
|
03 | Suresh Krishnan | New version available: draft-ietf-conex-destopt-03.txt |
2012-03-12
|
02 | Suresh Krishnan | New version available: draft-ietf-conex-destopt-02.txt |
2011-10-30
|
01 | (System) | New version available: draft-ietf-conex-destopt-01.txt |
2011-10-24
|
00 | (System) | New version available: draft-ietf-conex-destopt-00.txt |