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: … 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: https://mailarchive.ietf.org/arch/msg/teas/soNWChKyjUrMm3wHgAfzzdNPNPw IPR response 14 of 18: Victor Lopez: https://mailarchive.ietf.org/arch/msg/teas/MTaadWGj1PolHvAch4bq1Uh1X20 |
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 | IPR response 1 of 18: John Drake: https://mailarchive.ietf.org/arch/msg/teas/HZbP1bUb4nKefBoMwenp6GS0o5Y IPR response 2 of 18: Adrian Farrel: https://mailarchive.ietf.org/arch/msg/teas/VgC5afijCEj5viC6jeXxsj6mz5s IPR response 3 of 18: Sergio Belotti: https://mailarchive.ietf.org/arch/msg/teas/c3ezxtVt2gWPZPsRG-LZct3T7rk IPR … IPR response 1 of 18: John Drake: https://mailarchive.ietf.org/arch/msg/teas/HZbP1bUb4nKefBoMwenp6GS0o5Y IPR response 2 of 18: Adrian Farrel: https://mailarchive.ietf.org/arch/msg/teas/VgC5afijCEj5viC6jeXxsj6mz5s IPR response 3 of 18: Sergio Belotti: https://mailarchive.ietf.org/arch/msg/teas/c3ezxtVt2gWPZPsRG-LZct3T7rk IPR response 4 of 18: Daniele Ceccarelli: https://mailarchive.ietf.org/arch/msg/teas/cN2pd3iWairgWx-tTT1xcEyyEUM IPR response 5 of 18: Jeff Tantsura: https://mailarchive.ietf.org/arch/msg/teas/6vXV-DFoK1J6xLFRJiq-h9lx57Q IPR response 6 of 18: Cyril Margaria: https://mailarchive.ietf.org/arch/msg/teas/SvFGkHJIVzw2EmA55U0lWHXQSVU IPR response 7 of 18: Vishnu Pavan Beeram: https://mailarchive.ietf.org/arch/msg/teas/kbYcIDfYYzWsQHpzLuizLEA5vxw |
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 |