Skip to main content

IPv6 Destination Option for Congestion Exposure (ConEx)
draft-ietf-conex-destopt-12

Revision differences

Document history

Date Rev. By Action
2016-05-13
12 (System) RFC published
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