Skip to main content

Problem Statement and Architecture for Information Exchange between Interconnected Traffic-Engineered Networks
draft-ietf-teas-interconnected-te-info-exchange-07

Revision differences

Document history

Date Rev. By Action
2016-07-18
07 (System) RFC Editor state changed to AUTH48-DONE from AUTH48
2016-06-29
07 (System) RFC Editor state changed to AUTH48 from RFC-EDITOR
2016-06-28
07 (System) RFC Editor state changed to RFC-EDITOR from AUTH
2016-06-23
07 (System) RFC Editor state changed to AUTH from EDIT
2016-05-23
07 Gunter Van de Velde Closed request for Last Call review by OPSDIR with state 'No Response'
2016-05-23
07 (System) RFC Editor state changed to EDIT
2016-05-23
07 (System) IESG state changed to RFC Ed Queue from Approved-announcement sent
2016-05-23
07 (System) Announcement was received by RFC Editor
2016-05-23
07 (System) IANA Action state changed to No IC
2016-05-23
07 Amy Vezza IESG state changed to Approved-announcement sent from Approved-announcement to be sent
2016-05-23
07 Amy Vezza IESG has approved the document
2016-05-23
07 Amy Vezza Closed "Approve" ballot
2016-05-23
07 Amy Vezza IESG state changed to Approved-announcement to be sent from IESG Evaluation::AD Followup
2016-05-23
07 Amy Vezza Ballot writeup was changed
2016-05-21
07 Deborah Brungard Ballot approval text was changed
2016-05-21
07 Adrian Farrel IANA Review state changed to Version Changed - Review Needed from IANA OK - No Actions Needed
2016-05-21
07 Adrian Farrel New version available: draft-ietf-teas-interconnected-te-info-exchange-07.txt
2016-05-19
06 Amy Vezza IESG state changed to IESG Evaluation::AD Followup from IESG Evaluation
2016-05-19
06 Alvaro Retana
[Ballot comment]
I'm clearing my DISCUSS because it achieved the objective: to get the IESG talking about the Intended State of this document.  I don't …
[Ballot comment]
I'm clearing my DISCUSS because it achieved the objective: to get the IESG talking about the Intended State of this document.  I don't think we clearly reached consensus, but I'm sure the responsible AD will make the appropriate decision based on the input.
2016-05-19
06 Alvaro Retana [Ballot Position Update] Position for Alvaro Retana has been changed to No Objection from Discuss
2016-05-19
06 Stephen Farrell
[Ballot comment]

- The security considerations says to use IPsec or TCP-AO.  To
what extent do we think that this could help with implementation
and …
[Ballot comment]

- The security considerations says to use IPsec or TCP-AO.  To
what extent do we think that this could help with implementation
and deployment of TCP-AO? If it can, great. If it wouldn't, then I'm
not sure there's much point in mentioning TCP-AO given what I
understand it the current state of play there.

- IPsec can clearly be used, but I wondered if there's really no
place for using TLS between the domains here? That might need a
bit of work, (e.g. to allocate ports or define a STARTTLS
equivalent), but perhaps there's the opportunity here to get that
kind of thing done? That's maybe less of a question for this
document, but more for the WG in general. (Though if (D)TLS
made sense as part of this, saying so here would be good
probably.)

- I note that the IPR declaration refers to a "standard." As of
now, this document is aiming for BCP, so I've no idea how to
interpret the text in the declaration unless this reverts to PS.
(That said: I don't care much about what kind of RFC results
here, but I agree with the authors that just picking wihtout
requiring text changes for process reasons is right.)
2016-05-19
06 Stephen Farrell [Ballot Position Update] New position, No Objection, has been recorded for Stephen Farrell
2016-05-18
06 Joel Jaeggli
[Ballot comment]
watching the outcome of the state discussion, but I won't belabor the point. I think a clear case can be made of state …
[Ballot comment]
watching the outcome of the state discussion, but I won't belabor the point. I think a clear case can be made of state other than informational on the basis that this is providing guidance to the rest of the teas effort.
2016-05-18
06 Joel Jaeggli [Ballot Position Update] New position, No Objection, has been recorded for Joel Jaeggli
2016-05-18
06 Ben Campbell [Ballot comment]
I too share the confusion over the intended status. (And I agree with Alissa that this seems like an informational)
2016-05-18
06 Ben Campbell [Ballot Position Update] New position, No Objection, has been recorded for Ben Campbell
2016-05-18
06 Alia Atlas [Ballot Position Update] New position, No Objection, has been recorded for Alia Atlas
2016-05-18
06 Jari Arkko
[Ballot comment]
I believe this document would greatly benefit from clarifying the role of describing the "abstracting" from existing solutions, as discussed in Brian Carpenter's …
[Ballot comment]
I believe this document would greatly benefit from clarifying the role of describing the "abstracting" from existing solutions, as discussed in Brian Carpenter's Gen-ART review thread. This will help explain why the document is a BCP rather than Inf.
2016-05-18
06 Jari Arkko [Ballot Position Update] New position, No Objection, has been recorded for Jari Arkko
2016-05-18
06 Alissa Cooper [Ballot comment]
I too was wondering why this is listed as BCP rather than Informational.
2016-05-18
06 Alissa Cooper [Ballot Position Update] New position, No Objection, has been recorded for Alissa Cooper
2016-05-18
06 Mirja Kühlewind
[Ballot comment]
I fully support Alvaro's Discuss and I was just in the process of deciding if I want to raise a Discuss or not …
[Ballot comment]
I fully support Alvaro's Discuss and I was just in the process of deciding if I want to raise a Discuss or not when his ballot position came in.

Even though this document is well written and provides a lot of interesting information, to be honest, I could not find any recommendation on a best current pratice as this document mainly takes about requirements for future work. For me this document provides a problem statement, use cases, and requirements as well as some survery about the applicability of existing protocols and therefore should be an Informational document.
2016-05-18
06 Mirja Kühlewind [Ballot Position Update] New position, No Objection, has been recorded for Mirja Kühlewind
2016-05-18
06 Alvaro Retana
[Ballot discuss]
First off, let me say that this is a very well written and informative document. 

I went back and forth when considering my …
[Ballot discuss]
First off, let me say that this is a very well written and informative document. 

I went back and forth when considering my ballot for this document.  I decided to put in a DISCUSS for the IESG to talk about the Intended Status and whether anything needs to be done in the current document.  My intent is to attract the attention of the IESG towards the Gen-art review (where the topic of the Intended Status first came up [2]) and the longer than expected thread [3] in the teas WG, where a couple of the authors have said that they don't know why BCP is the right answer [4] and [5].

By the time we get to the Telechat (tomorrow!) my comments may have already been taken over by events; if so, I will clear.

If asked to decide I would have leaned towards Informational — there is lot of content describing the problem and an architecture (not a solution).  I think Adrian made more persuasive points towards Informational (probably not his intent) in one of his messages to the teas WG [1].

The document does present the best thinking of the WG at this point, but I think it falls short of explicitly documenting the "the best way to perform some operations" [rfc2026].  In fact, the current way to implement the architecture is left to an Appendix.

If the resulting Status remains as BCP (or even Standards Track), then I would like to support Brian Carpenter (Gen-art reviewer) in his request for the document to call out which sections are not normative (5 – Building on Existing Protocols and 9 – Scoping Future Work, are high on my list).  This action shouldn't require more than a couple of sentences.

Just to recap.  This DISCUSS is for the IESG to talk…  I don't expect any action from the authors at this point — maybe just help the IESG in the discussion…


[1] https://mailarchive.ietf.org/arch/msg/teas/ql2RDMcvMZZU9KPKTdKijIqMtBA
[2] https://mailarchive.ietf.org/arch/msg/gen-art/yDlSiKhKzkEhrXbuXSJtdYivhbc
[3] https://mailarchive.ietf.org/arch/msg/teas/qMbaZkMi4iJMAzZPq8SYrxMmtPg
[4] https://mailarchive.ietf.org/arch/msg/teas/aq8YSEDr6BP6V1MdN4ZNTJUQd4k
[5] https://mailarchive.ietf.org/arch/msg/gen-art/kMwMDZ8nU8t4dKKI1ImN3l6YdbY
2016-05-18
06 Alvaro Retana
[Ballot comment]
A couple of nits:

s/one or more network/one or more networks

"…the source domain does not know in which domain the destination node …
[Ballot comment]
A couple of nits:

s/one or more network/one or more networks

"…the source domain does not know in which domain the destination node is located…this issue is obviously mitigated in IP networks by inter-domain routing [RFC4271]."  For the definition of "domain" used in this document BGP is not the only inter-domain routing solution — and others may not mitigate the issue in the same way (but may of course use aggregation/abstraction to compensate).

s/requested to to follow same path/requested to follow the same path
2016-05-18
06 Alvaro Retana [Ballot Position Update] New position, Discuss, has been recorded for Alvaro Retana
2016-05-17
06 Suresh Krishnan [Ballot Position Update] New position, No Objection, has been recorded for Suresh Krishnan
2016-05-17
06 Spencer Dawkins [Ballot comment]
This document is terrifically helpful. Thanks for producing it.
2016-05-17
06 Spencer Dawkins [Ballot Position Update] New position, Yes, has been recorded for Spencer Dawkins
2016-05-17
06 Terry Manderson [Ballot Position Update] New position, No Objection, has been recorded for Terry Manderson
2016-05-17
06 (System) IANA Review state changed to IANA OK - No Actions Needed from Version Changed - Review Needed
2016-05-17
06 Alexey Melnikov [Ballot Position Update] New position, No Objection, has been recorded for Alexey Melnikov
2016-05-16
06 Kathleen Moriarty [Ballot comment]
Thanks for addressing the SecDir review:
https://www.ietf.org/mail-archive/web/secdir/current/msg06560.html
2016-05-16
06 Kathleen Moriarty [Ballot Position Update] New position, No Objection, has been recorded for Kathleen Moriarty
2016-05-14
06 Brian Carpenter Request for Telechat review by GENART Completed: Ready. Reviewer: Brian Carpenter.
2016-05-13
06 Peter Yee Request for Telechat review by GENART is assigned to Brian Carpenter
2016-05-13
06 Peter Yee Request for Telechat review by GENART is assigned to Brian Carpenter
2016-05-12
06 Tero Kivinen Request for Last Call review by SECDIR Completed: Has Issues. Reviewer: Hilarie Orman.
2016-05-12
06 Deborah Brungard IESG state changed to IESG Evaluation from Waiting for Writeup
2016-05-12
06 Deborah Brungard Changed consensus to Yes from Yes
2016-05-11
06 Deborah Brungard Placed on agenda for telechat - 2016-05-19
2016-05-11
06 Deborah Brungard Ballot has been issued
2016-05-11
06 Deborah Brungard [Ballot Position Update] New position, Yes, has been recorded for Deborah Brungard
2016-05-11
06 Deborah Brungard Created "Approve" ballot
2016-05-11
06 Deborah Brungard Ballot writeup was changed
2016-05-11
06 Deborah Brungard Ballot writeup was changed
2016-05-10
06 Adrian Farrel IANA Review state changed to Version Changed - Review Needed from IANA OK - No Actions Needed
2016-05-10
06 Adrian Farrel New version available: draft-ietf-teas-interconnected-te-info-exchange-06.txt
2016-05-10
05 (System) IESG state changed to Waiting for Writeup from In Last Call
2016-05-05
05 Jonathan Hardwick Request for Early review by RTGDIR Completed: Ready. Reviewer: Stewart Bryant.
2016-05-04
05 Brian Carpenter Request for Early review by GENART Completed: Almost Ready. Reviewer: Brian Carpenter.
2016-04-28
05 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Niclas Comstedt
2016-04-28
05 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Niclas Comstedt
2016-04-28
05 Tero Kivinen Request for Last Call review by SECDIR is assigned to Hilarie Orman
2016-04-28
05 Tero Kivinen Request for Last Call review by SECDIR is assigned to Hilarie Orman
2016-04-28
05 (System) IANA Review state changed to IANA OK - No Actions Needed from IANA - Review Needed
2016-04-28
05 Sabrina Tanamal
(Via drafts-lastcall-comment@iana.org): IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-teas-interconnected-te-info-exchange-05.txt, which is currently in Last Call, and has the following comments:

We understand that this …
(Via drafts-lastcall-comment@iana.org): IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-teas-interconnected-te-info-exchange-05.txt, which is currently in Last Call, and has the following comments:

We understand that this document doesn't require any IANA actions.

While it's often helpful for a document's IANA Considerations section to remain in place upon publication even if there are no actions, if the authors strongly prefer to remove it, IANA does not object.

If this assessment is not accurate, please respond as soon as possible.

Thank you,

Sabrina Tanamal
IANA Specialist
ICANN
2016-04-27
05 Jean Mahoney Request for Early review by GENART is assigned to Brian Carpenter
2016-04-27
05 Jean Mahoney Request for Early review by GENART is assigned to Brian Carpenter
2016-04-26
05 Cindy Morgan IANA Review state changed to IANA - Review Needed
2016-04-26
05 Cindy Morgan
The following Last Call announcement was sent out:

From: The IESG
To: "IETF-Announce"
CC: draft-ietf-teas-interconnected-te-info-exchange@ietf.org, db3546@att.com, "Lou Berger" , teas-chairs@ietf.org, teas@ietf.org, …
The following Last Call announcement was sent out:

From: The IESG
To: "IETF-Announce"
CC: draft-ietf-teas-interconnected-te-info-exchange@ietf.org, db3546@att.com, "Lou Berger" , teas-chairs@ietf.org, teas@ietf.org, lberger@labn.net
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Problem Statement and Architecture for Information Exchange Between Interconnected Traffic Engineered Networks) to Best Current Practice


The IESG has received a request from the Traffic Engineering Architecture
and Signaling WG (teas) to consider the following document:
- 'Problem Statement and Architecture for Information Exchange Between
  Interconnected Traffic Engineered Networks'
  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 2016-05-10. 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


  In Traffic Engineered (TE) systems, it is sometimes desirable to
  establish an end-to-end TE path with a set of constraints (such as
  bandwidth) across one or more network from a source to a destination.
  TE information is the data relating to nodes and TE links that is
  used in the process of selecting a TE path.  TE information is
  usually only available within a network.  We call such a zone of
  visibility of TE information a domain. An example of a domain may be
  an IGP area or an Autonomous System.

  In order to determine the potential to establish a TE path through a
  series of connected networks, it is necessary to have available a
  certain amount of TE information about each network.  This need not
  be the full set of TE information available within each network, but
  does need to express the potential of providing TE connectivity. This
  subset of TE information is called TE reachability information.

  This document sets out the problem statement for the exchange of TE
  information between interconnected TE networks in support of end-to-
  end TE path establishment and describes the best current practice
  architecture to meet this problem statement.  For reasons that are
  explained in the document, this work is limited to simple TE
  constraints and information that determine TE reachability.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-teas-interconnected-te-info-exchange/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-teas-interconnected-te-info-exchange/ballot/


The following IPR Declarations may be related to this I-D:

  https://datatracker.ietf.org/ipr/2745/



2016-04-26
05 Cindy Morgan IESG state changed to In Last Call from Last Call Requested
2016-04-26
05 Deborah Brungard Last call was requested
2016-04-26
05 Deborah Brungard Ballot approval text was generated
2016-04-26
05 Deborah Brungard Ballot writeup was generated
2016-04-26
05 Deborah Brungard IESG state changed to Last Call Requested from Publication Requested
2016-04-26
05 Deborah Brungard Last call announcement was generated
2016-04-26
05 Adrian Farrel New version available: draft-ietf-teas-interconnected-te-info-exchange-05.txt
2016-04-07
04 Jonathan Hardwick Request for Early review by RTGDIR is assigned to Stewart Bryant
2016-04-07
04 Jonathan Hardwick Request for Early review by RTGDIR is assigned to Stewart Bryant
2016-03-22
04 Lou Berger
>As required by RFC 4858, this is the current template for the Document
> Shepherd Write-Up.
>
> Changes are expected over time. This …
>As required by RFC 4858, this is the current template for the Document
> Shepherd Write-Up.
>
> Changes are expected over time. This version is dated 24 February 2012.
>
> (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?
>

BCP - This document describes how existing tools/RFC can be used to
interconnect Traffic Engineered networks (domains).

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


  This document sets out the problem statement and architecture for the
  exchange of TE information between interconnected TE networks in
  support of end-to-end TE path establishment. It describes how
  existing RFCs can be used to establish an end-to-end TE path with a
  set of constraints (such as bandwidth) across one or more network
  from a source to a destination.


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

This document has been in process for a long time.  There were many
heated discussions that eventyually led to the this document which has a
high degree of support.  Recent delays were largely editorial rather
than in content. 

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

This document has been discussed and reviewed by the WG many times.  It
has a wide scope and covers it comprehensively.  Having this information
consolidated in a single place has real value to the WG, users and
vendors. 

> Personnel
>
>  Who is the Document Shepherd?

Lou Berger

> Who is the Responsible Area Director?

Deborah Brungard


> (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 has been reviewed by the Shepherd while being developed as
well as in it's current form.  It is ready for publications


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

No concerns.  The document is in good shape for publication.

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

Yes.

> If so, summarize any WG discussion and conclusion regarding the IPR
> disclosures.

The IPR was discussed and the last messages on the topic stated:
1. https://www.ietf.org/mail-archive/web/teas/current/msg01038.html
  IPR was disclosed as required
2. https://www.ietf.org/mail-archive/web/teas/current/msg01037.html
  IPR on "BRPC" was also disclosed on RFC5441, back in 2007.

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

IMO strong concurrence.

> (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 https://www.ietf.org/tools/idnits/ and the Internet-Drafts
> Checklist). Boilerplate checks are not enough; this check needs to be
> thorough.
>

The document has one idnits warning (a long line).

> (12) Describe how the document meets any required formal review
> criteria, such as the MIB Doctor, media type, and URI type reviews.
>

No formal review required/appropriate.

> (13) Have all references within this document been identified as
> either normative or informative?
>

yes (although all marked as informative)

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

No.


> (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, N/A.


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

This document describes how exsiting RFCs can be used so there are no
new IANA considerations.


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

None.

> (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 needed.
2016-03-22
04 Lou Berger Responsible AD changed to Deborah Brungard
2016-03-22
04 Lou Berger IETF WG state changed to Submitted to IESG for Publication from WG Consensus: Waiting for Write-Up
2016-03-22
04 Lou Berger IESG state changed to Publication Requested
2016-03-22
04 Lou Berger IESG process started in state Publication Requested
2016-03-22
04 Lou Berger Changed consensus to Yes from Unknown
2016-03-22
04 Lou Berger Intended Status changed to Best Current Practice from None
2016-03-22
04 Lou Berger Changed document writeup
2016-03-22
04 Lou Berger LC complete https://www.ietf.org/mail-archive/web/teas/current/msg01159.html
2016-03-22
04 Lou Berger IETF WG state changed to WG Consensus: Waiting for Write-Up from In WG Last Call
2016-03-20
04 Adrian Farrel New version available: draft-ietf-teas-interconnected-te-info-exchange-04.txt
2016-03-07
03 Lou Berger IETF WG state changed to In WG Last Call from WG Document
2016-03-07
03 Lou Berger Notification list changed to "Lou Berger" <lberger@labn.net>
2016-03-07
03 Lou Berger Document shepherd changed to Lou Berger
2016-03-07
03 Matt Hartley IPR poll complete
2016-03-07
03 Matt Hartley IPR response 18 of 18: Nabil Bitar: https://mailarchive.ietf.org/arch/msg/teas/-GyvzQh4zXYMgXcQnsrkdvDXC9E
2016-03-01
03 Matt Hartley IPR response 16 of 18: Gert Grammel: https://mailarchive.ietf.org/arch/msg/teas/5svFZnYvvVeTtPih7PT_y5-P0FM
IPR response 17 of 18: Diego Caviglia: https://mailarchive.ietf.org/arch/msg/teas/y4k9re_AMbctzAG77Cfng1blYS0
2016-02-29
03 Matt Hartley IPR response 15 of 18: Zafar Ali: https://mailarchive.ietf.org/arch/msg/teas/qTwYQAJ4B3cfN_YUgiPi5RK5U3w
2016-02-23
03 Matt Hartley
IPR response 11 of 18: Rajan Rao: https://mailarchive.ietf.org/arch/msg/teas/byFak0SV6QakTcw28JYgUR5VByM
IPR response 12 of 18: Fatai Zhang: https://mailarchive.ietf.org/arch/msg/teas/0UxpoL5dmKobNtaprpHoNMg3fMA
IPR response 13 of 18: Oscar Gonzalez de Dios: …
2016-02-08
03 Matt Hartley IPR response 10 of 18: Khuzema Pithewan: https://mailarchive.ietf.org/arch/msg/teas/QRLEKmx3-eImNO3xKKtaIGAQMH0
2016-02-01
Naveen Khan Posted related IPR disclosure: Infinera Corporation's Statement about IPR related to draft-ietf-teas-interconnected-te-info-exchange
2016-01-27
03 Matt Hartley IPR response 9 of 18: George Swallow: https://mailarchive.ietf.org/arch/msg/teas/avBQHLB8Zfro-TPOzHCtBNEeAaA
2016-01-27
03 Matt Hartley IPR response 8 of 18: Xian Zhang: https://mailarchive.ietf.org/arch/msg/teas/sTuh2SEI0HeX2mNfn-NwshU52i4
2016-01-26
03 Matt Hartley
2016-01-26
03 Matt Hartley IPR poll started: https://mailarchive.ietf.org/arch/msg/teas/vTvJMUeU2j2qFEAU5ifHAkgNoZ0
2015-10-15
03 Adrian Farrel New version available: draft-ietf-teas-interconnected-te-info-exchange-03.txt
2015-03-08
02 Adrian Farrel New version available: draft-ietf-teas-interconnected-te-info-exchange-02.txt
2015-02-06
01 Adrian Farrel New version available: draft-ietf-teas-interconnected-te-info-exchange-01.txt
2014-12-08
00 Adrian Farrel This document now replaces draft-ietf-ccamp-interconnected-te-info-exchange instead of None
2014-12-08
00 Adrian Farrel New version available: draft-ietf-teas-interconnected-te-info-exchange-00.txt