Routing IPv6 with IS-IS
RFC 5308
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2017-05-16 |
07 | (System) | Changed document authors from "" to "Christian Hopps" |
2015-10-14 |
07 | (System) | Notify list changed from isis-chairs@ietf.org to (None) |
2012-08-22 |
07 | (System) | post-migration administrative database adjustment to the No Objection position for Jari Arkko |
2012-08-22 |
07 | (System) | post-migration administrative database adjustment to the No Objection position for Dan Romascanu |
2012-08-22 |
07 | (System) | post-migration administrative database adjustment to the No Objection position for Magnus Westerlund |
2012-08-22 |
07 | (System) | post-migration administrative database adjustment to the Abstain position for Brian Carpenter |
2012-08-22 |
07 | (System) | post-migration administrative database adjustment to the No Objection position for Russ Housley |
2008-10-06 |
07 | Amy Vezza | State Changes to RFC Published from RFC Ed Queue by Amy Vezza |
2008-10-06 |
07 | Amy Vezza | [Note]: 'RFC 5308' added by Amy Vezza |
2008-10-03 |
07 | (System) | RFC published |
2008-02-29 |
07 | (System) | IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor |
2008-02-29 |
07 | (System) | IANA Action state changed to Waiting on RFC Editor from In Progress |
2008-02-29 |
07 | (System) | IANA Action state changed to In Progress from Waiting on Authors |
2008-02-27 |
07 | (System) | IANA Action state changed to Waiting on Authors from In Progress |
2008-02-27 |
07 | (System) | IANA Action state changed to In Progress from Waiting on Authors |
2008-02-19 |
07 | (System) | IANA Action state changed to Waiting on Authors from Waiting on ADs |
2008-02-14 |
07 | (System) | IANA Action state changed to Waiting on ADs from In Progress |
2008-02-14 |
07 | Amy Vezza | State Changes to RFC Ed Queue from Approved-announcement sent by Amy Vezza |
2008-02-14 |
07 | (System) | IANA Action state changed to In Progress |
2008-02-14 |
07 | Amy Vezza | IESG state changed to Approved-announcement sent |
2008-02-14 |
07 | Amy Vezza | IESG has approved the document |
2008-02-14 |
07 | Amy Vezza | Closed "Approve" ballot |
2008-02-14 |
07 | Ross Callon | State Changes to Approved-announcement to be sent from IESG Evaluation::AD Followup by Ross Callon |
2008-02-14 |
07 | Dan Romascanu | [Ballot Position Update] Position for Dan Romascanu has been changed to No Objection from Undefined by Dan Romascanu |
2008-02-14 |
07 | Dan Romascanu | [Ballot Position Update] Position for Dan Romascanu has been changed to Undefined from Discuss by Dan Romascanu |
2008-01-10 |
07 | Magnus Westerlund | [Ballot Position Update] Position for Magnus Westerlund has been changed to No Objection from Discuss by Magnus Westerlund |
2008-01-09 |
07 | Michelle Cotton | IANA section needs revising. Working with Magnus and Authors to fix. |
2007-12-13 |
07 | Chris Newman | [Ballot comment] I'd prefer if the IANA considerations section was kept after the document was published. The fact two codepoints were registered and a new … [Ballot comment] I'd prefer if the IANA considerations section was kept after the document was published. The fact two codepoints were registered and a new registry was created is interesting and relevant. |
2007-12-13 |
07 | Chris Newman | [Ballot comment] I'd prefer if the IANA considerations section was kept after the document was published. The fact two codepoints were registered and a new … [Ballot comment] I'd prefer if the IANA considerations section was kept after the document was published. The fact two codepoints were registered and a new registry was created is interesting and relevant. |
2007-12-13 |
07 | Chris Newman | [Ballot Position Update] New position, No Objection, has been recorded by Chris Newman |
2007-12-13 |
07 | Jari Arkko | [Ballot Position Update] Position for Jari Arkko has been changed to No Objection from Discuss by Jari Arkko |
2007-10-05 |
07 | Russ Housley | [Ballot Position Update] Position for Russ Housley has been changed to No Objection from Discuss by Russ Housley |
2007-10-05 |
07 | (System) | Sub state has been changed to AD Follow up from New Id Needed |
2007-10-05 |
07 | (System) | New version available: draft-ietf-isis-ipv6-07.txt |
2007-03-22 |
07 | Bill Fenner | This needs a few updates to handle the DISCUSSes. My understanding was that there was an agreement on a few citations to add to handle … This needs a few updates to handle the DISCUSSes. My understanding was that there was an agreement on a few citations to add to handle the concern of it being under-specified; the other DISCUSSes seem reasonably straightforward. |
2007-03-22 |
07 | Bill Fenner | Responsible AD has been changed to Ross Callon from Bill Fenner |
2007-01-18 |
07 | Brian Carpenter | [Ballot Position Update] Position for Brian Carpenter has been changed to Abstain from Discuss by Brian Carpenter |
2006-11-08 |
07 | (System) | Request for Early review by SECDIR Completed. Reviewer: Blake Ramsdell. |
2006-05-12 |
07 | (System) | Removed from agenda for telechat - 2006-05-11 |
2006-05-11 |
07 | Amy Vezza | State Changes to IESG Evaluation::Revised ID Needed from IESG Evaluation by Amy Vezza |
2006-05-11 |
07 | (System) | [Ballot Position Update] New position, No Objection, has been recorded for Lisa Dusseault by IESG Secretary |
2006-05-11 |
07 | (System) | [Ballot Position Update] New position, No Objection, has been recorded for David Kessens by IESG Secretary |
2006-05-11 |
07 | Sam Hartman | [Ballot Position Update] Position for Sam Hartman has been changed to Abstain from Yes by Sam Hartman |
2006-05-11 |
07 | Sam Hartman | [Ballot comment] I don't think this document has enough information in order to create an interoperable implementation of the spec. I'm concerned that there may … [Ballot comment] I don't think this document has enough information in order to create an interoperable implementation of the spec. I'm concerned that there may be unwritten knowledge necessary to make this work. Alternatively, it may all become clear if you have a better understanding of the normative references than I do. However I definitely do not have enough confidence in this document to support publication. |
2006-05-11 |
07 | Sam Hartman | [Ballot Position Update] New position, Yes, has been recorded for Sam Hartman by Sam Hartman |
2006-05-11 |
07 | Lars Eggert | [Ballot Position Update] New position, No Objection, has been recorded for Lars Eggert by Lars Eggert |
2006-05-11 |
07 | Jari Arkko | [Ballot discuss] > 0 1 2 … [Ballot discuss] > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Type = 236 | Length | Metric .. | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | .. Metric |U|X|S| Reserve | Prefix Len | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Prefix ... > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |Sub-TLV Len(*) | Sub-TLVs(*) ... > * - if present > > U - up/down bit > X - external original bit > S - subtlv present bit > > This structure MAY appear any number of times (including none) within > the TLV. What does "this structure" refer to? The entire thing? Can the protocol where these TLVs are carried deal with zero-length TLVs? This seems strange. Perhaps you meant the part after the Length field? But this should then be explicitly specified. Or the subtlv part? That too should then be specified. Please clarify. |
2006-05-11 |
07 | Jari Arkko | [Ballot Position Update] New position, Discuss, has been recorded for Jari Arkko by Jari Arkko |
2006-05-10 |
07 | Ross Callon | [Ballot Position Update] Position for Ross Callon has been changed to Yes from Undefined by Ross Callon |
2006-05-10 |
07 | Ross Callon | [Ballot comment] This is in fact the fourth or fifth protocol that is supported using IS-IS (the first two were DECnet Phase 4 and CLNP … [Ballot comment] This is in fact the fourth or fifth protocol that is supported using IS-IS (the first two were DECnet Phase 4 and CLNP which were pretty much supported simultaneously, then came IPv4, then came NLSP for routing IPX, which is so similar to IS-IS that some implementations use a single implementation to support both NLSP and IS-IS). Thus many of the questions that implementors might otherwise have, have already been answered in previous work. I think that it would make sense for the security considerations section to include informational references to RFC3567 and to draft-ietf-opsec-current-practices-02.txt. Possible replacement text for section 8 would be: 8 Security Considerations This document raises no new security considerations. Authentication of IS-IS packets may optionally be provided using the extension specified in [RFC3567]. A threat model as well as operational security features which are commonly deployed in networks is provided in [OPSECPRACTICES]. then add to references: [RFC3567] "Intermediate System to Intermediate System (IS-IS) Cryptographic Authentication", T.Li and R.Atkinson, July 2003. [OPSECPRACTICES] "Operational Security Current Practices", draft-ietf-opsec-current-practices-02.txt, work in progress, July 2005. (note that this last one has timed out but will be updated very soon as -03). Reference 2 is clearly obsolete, and needs to be replaced by something. I am pretty sure that this would be: [RFC3784] "Intermediate System to Intermediate System (IS-IS) Extensions for Traffic Engineering (TE)", H. Smit and T.Li, June 2004. Most likely we should also add a reference to: [RFC2966] "Domain-wide Prefix Distribution with Two-Level IS-IS", T. Li, T. Przygienda, H. Smit, October 2000. I am told that all deployments (except pure CLNS deployments) use wide-metrics-only. Thus the use of wide metrics seems fine. It might be worthwhile to write a different very short RFC deprecating the use of narrow (ie original) metrics. |
2006-05-10 |
07 | Ross Callon | [Ballot Position Update] New position, Undefined, has been recorded for Ross Callon by Ross Callon |
2006-05-10 |
07 | Jon Peterson | [Ballot Position Update] Position for Jon Peterson has been changed to No Objection from Undefined by Jon Peterson |
2006-05-10 |
07 | Jon Peterson | [Ballot comment] Please expand the first usage of the acronym "LSP" in the document. |
2006-05-10 |
07 | Jon Peterson | [Ballot Position Update] New position, Undefined, has been recorded for Jon Peterson by Jon Peterson |
2006-05-09 |
07 | Cullen Jennings | [Ballot Position Update] New position, No Objection, has been recorded for Cullen Jennings by Cullen Jennings |
2006-05-09 |
07 | Ted Hardie | [Ballot Position Update] New position, No Objection, has been recorded for Ted Hardie by Ted Hardie |
2006-05-09 |
07 | Mark Townsley | [Ballot comment] Might be a good idea to reference RFC2460 at the start of the document. Need a 2119 ref at the end of the … [Ballot comment] Might be a good idea to reference RFC2460 at the start of the document. Need a 2119 ref at the end of the doc. |
2006-05-09 |
07 | Mark Townsley | [Ballot Position Update] New position, No Objection, has been recorded for Mark Townsley by Mark Townsley |
2006-05-09 |
07 | Bill Fenner | Last Call Comment from Pekka Savloa: From: Pekka Savola <pekkas@netcore.fi> Subject: Re: Last Call: 'Routing IPv6 with IS-IS' to Proposed Standard Date: Wed, Feb 8 … Last Call Comment from Pekka Savloa: From: Pekka Savola <pekkas@netcore.fi> Subject: Re: Last Call: 'Routing IPv6 with IS-IS' to Proposed Standard Date: Wed, Feb 8 10:51:24 To: iesg@ietf.org Cc: isis-wg@ietf.org There is a procedural problem here: a normative reference to [[RFC3784]] (references list not updated), which is informational, while this spec is going for Standards Track. This is a down-ref issue. On our network, we also observed a Cisco bug where the router redistributed FE80::/10 an FF00::/8 into IS-IS, which caused a bit of mess. Maybe the document should say something about this. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings |
2006-05-09 |
07 | Brian Carpenter | [Ballot comment] Extra comments from Gemn-ART review by Elwyn Davies: s2/s5: The IPv6 protocol identifier is not new with this specification. If I understand correctly … [Ballot comment] Extra comments from Gemn-ART review by Elwyn Davies: s2/s5: The IPv6 protocol identifier is not new with this specification. If I understand correctly it is defined in ISO/IEC TR 9577 (in the 1999 update at least). There should be a reference to this document. s2: I think it would be appropriate to discuss whether the updates of ref [2] (now RFC3784) for IPv4 are a prerequisite for implementing the changes in this document. At first I didn't *think* they were but the statement that the IPv6 stuff 'uses' the semantics etc of [2] doesn't make this totally clear, and omitting RFC3784 support would result (but I may be confused) in a combination of 'narrow' (6 bit) link metrics and 'wide' (24-32 bit) path metrics for IPv6. Is this reasonable? s3: This section lacks precise definitions of several of the fields: In particular the length field is unspecified. By analogy with s5.3 of RFC1195 one could ASSUME that it is the total length of the value part of the TLV excluding the first two octets but that assumes that everything said for IP(v4) applies for IPv6 - which is not made explicit. To avoid uncertainty it would be worth being explicit. Similarly the encoding of the metric (presumably unsigned 32 bit integer), the possible values of prefix length and the number of octets of prefix are not made explicit. s3: s/external original/external origin/ s3: '...the octet following the prefix will contain the length of the sub-TLV portion of the structure': Aside from the redundancy of this octet (the sub-TLV length can (probably) be derived from the overall length and the prefix length fields unless the TLV length does not cover the sub-TLVs as well), it needs to be made clear if this length includes or excludes the length octet itself. I would suggest repeating section 4.2 of RFC3784 which would also make it clear that the draft doesn't define any sub-TLVs and notes the limitations of the size of sub-TLVs that are possible (slightly different in this case). s4: Again the length is not precisely defined. s6: I don't think it is very clear how the various preference rules in RFC1195, RFC2966 and this document are supposed to be integrated. s6: Copying over some of the reasoning for the choice of the maximum metric from RFC3784 would not go amiss. s9: Ref [2] is RFC2784. Need a reference to ISO/IEC TR 9577:1999. |
2006-05-09 |
07 | Brian Carpenter | [Ballot discuss] It doesn't seem that this spec contains sufficient information (or normative references) for an independent implementor. The fact that established ISIS implementors have … [Ballot discuss] It doesn't seem that this spec contains sufficient information (or normative references) for an independent implementor. The fact that established ISIS implementors have added IPv6 doesn't mean the independent implementors could do so based on this spec. This was pointed out during IETF Last Call but the gaps have not been filled, and I haven't seen any feedback to indicate that the WG discussed this point. Specifically, quoting the Gen-ART review by Elwyn Davies: This new draft adds a third address family but does not discuss the interaction of IPv6 with IPv4 (or OSI). This wouldn't matter if the multi-topology extensions (draft-ietf-isis-wg-multi-topology-11.txt) were being used but for the basic protocol I think something needs to be said about some new classes of routers (in principle there are now six possibilities { {OSI}, {IPv4}, {IPv6}, {OSI, IPv4}, {OSI, IPv6}, {IPv4, IPv6}, (OSI, IPv4, IPv6}}). RFC1195 indicates that routers need to be configured with their domain type (essentially the common set of address families supported by all nodes in the domain) which would need to be extended to cover the extra family. (This issue is mentioned in many presentations on the use of a single instance of IS-IS for routeing IPv4 and IPv6). Aside from this fairly fundamental issue, it was not clear to me where the additional preference rules specified in s6 had to be integrated into the fairly complex preference rules already specified in s3.10 of RFC1195 or what their relationship was to the preference rules given in s3.2 of RFC2966 (the semantics of the up/down bit used in the IPv6 Reachability TLVs appear to be derived through ref [2] which is now RFC3784 which in turn defers to RFC2966). Talking of RFC3784, there is no clear statement as to whether implementation of the RFC3784 extensions is a necessary prerequisite for these extensions: if I understand correctly, NOT implementing RFC3784 means that only 'narrow' metrics would be available for IS link specifications but the IPv6 extensions only provide for 'wide' path metrics, whereas RFC1195+RFC3784 gives a choice of wide and narrow for both IS links and IPv4 paths. I am not clear if the situation would be reasonable without RFC3784 support. Another related area which is really rather buried in these specifications is the issue of separate metrics for the various address families. This may be obvious to afficionados of IS-IS but the fact that the SPF is run separately for each metric gets rather lost. Referring back to the original specification it is possible that the SPF is run multiple times for the same address family if multiple metrics are defined - originally to handle multiple TOS metrics. A reminder of this would not go amiss. Presumably we have to wait for TE extensions to get multiple metrics for IPv6. Overall I felt that the draft lacked attention to detail and there were areas (especially s6) which amounted to 'hand-waving' rather than rigorous specification. This seems slightly surprising as there are (I believe) several implementations already in service. |
2006-05-09 |
07 | Brian Carpenter | [Ballot Position Update] Position for Brian Carpenter has been changed to Discuss from Abstain by Brian Carpenter |
2006-05-09 |
07 | Brian Carpenter | [Ballot Position Update] New position, Abstain, has been recorded for Brian Carpenter by Brian Carpenter |
2006-05-09 |
07 | Magnus Westerlund | [Ballot comment] Abrevation should be expanded on the first usage of each of them. |
2006-05-09 |
07 | Magnus Westerlund | [Ballot discuss] No IANA registry for the SUB-TLVs are created. |
2006-05-09 |
07 | Magnus Westerlund | [Ballot Position Update] New position, Discuss, has been recorded for Magnus Westerlund by Magnus Westerlund |
2006-05-08 |
07 | Russ Housley | [Ballot comment] Section 4 says: > > This TLV maps directly to [1]'s "IP Interface Address" TLV. > Suggested rewording: … [Ballot comment] Section 4 says: > > This TLV maps directly to [1]'s "IP Interface Address" TLV. > Suggested rewording: > > This TLV maps directly to the "IP Interface Address" TLV defined > in [1]. |
2006-05-08 |
07 | Russ Housley | [Ballot discuss] The Security Considerations are not sufficient. At a minimum, there should be a reference to RFC 3567. |
2006-05-08 |
07 | Russ Housley | [Ballot Position Update] New position, Discuss, has been recorded for Russ Housley by Russ Housley |
2006-05-07 |
07 | Dan Romascanu | [Ballot discuss] The following issue was raised by Pekka Savola on the OPS Directorate list. I sent an IETF Last Call on 8 Feb: http://www1.ietf.org/mail-archive/web/isis-wg/current/msg01549.html … [Ballot discuss] The following issue was raised by Pekka Savola on the OPS Directorate list. I sent an IETF Last Call on 8 Feb: http://www1.ietf.org/mail-archive/web/isis-wg/current/msg01549.html There was no response. First off, there is procedural down-ref problem, but that's not my main concern. My main concern is that the doc doesn't say anything about special prefixes which should not be routed using IS-IS. The document should say either: 1) that sender implementations should consider what prefixes or interface addresses to advertise, and receivers likewise for receiving (without specifying or giving examples what these might be), or 2) above, and mention those prefixes, either as examples or as normative. This affects at least multicast, link-local, loopback, etc. prefixes for both v4 and v6. We noticed this problem with two major vendors about a year ago (one leaked link-local stuff, the other accepted it), and it caused some mess. 1) seems suboptimal from interop perspective. Hence, I think the document must say something on this. |
2006-05-07 |
07 | Dan Romascanu | [Ballot Position Update] Position for Dan Romascanu has been changed to Discuss from Undefined by Dan Romascanu |
2006-05-07 |
07 | Dan Romascanu | [Ballot Position Update] New position, Undefined, has been recorded for Dan Romascanu by Dan Romascanu |
2006-04-28 |
07 | Bill Fenner | [Ballot Position Update] New position, Yes, has been recorded for Bill Fenner |
2006-04-28 |
07 | Bill Fenner | Ballot has been issued by Bill Fenner |
2006-04-28 |
07 | Bill Fenner | Created "Approve" ballot |
2006-04-28 |
07 | Bill Fenner | Placed on agenda for telechat - 2006-05-11 by Bill Fenner |
2006-04-28 |
07 | Bill Fenner | State Changes to IESG Evaluation from Waiting for AD Go-Ahead by Bill Fenner |
2006-04-28 |
07 | Bill Fenner | State Change Notice email list have been change to isis-chairs@tools.ietf.org from chopps@procket.com; dward@cisco.com |
2006-03-29 |
07 | Bill Fenner | Shepherding AD has been changed to Bill Fenner from Alex Zinin |
2006-02-23 |
07 | Michelle Cotton | IANA Comments: Upon approval of this document the IANA will update the IS-IS codepoint registry (http://www.iana.org/assignments/isis-tlv-codepoints) so that TLV codes 232 and 236 … IANA Comments: Upon approval of this document the IANA will update the IS-IS codepoint registry (http://www.iana.org/assignments/isis-tlv-codepoints) so that TLV codes 232 and 236 refer to this document's RFC number. We understand these to be the only IANA Actions. |
2006-02-15 |
07 | (System) | State has been changed to Waiting for AD Go-Ahead from In Last Call by system |
2006-02-01 |
07 | Amy Vezza | Last call sent |
2006-02-01 |
07 | Amy Vezza | State Changes to In Last Call from Last Call Requested by Amy Vezza |
2006-02-01 |
07 | Alex Zinin | Last Call was requested by Alex Zinin |
2006-02-01 |
07 | Alex Zinin | State Changes to Last Call Requested from AD Evaluation by Alex Zinin |
2006-02-01 |
07 | (System) | Ballot writeup text was added |
2006-02-01 |
07 | (System) | Last call text was added |
2006-02-01 |
07 | (System) | Ballot approval text was added |
2005-11-02 |
07 | Alex Zinin | Asked Chopps if he submitted the implementation report. |
2005-11-02 |
07 | Alex Zinin | State Changes to AD Evaluation from Publication Requested by Alex Zinin |
2005-10-27 |
07 | Alex Zinin | State Changes to Publication Requested from Dead by Alex Zinin |
2005-10-27 |
07 | Alex Zinin | Intended Status has been changed to Proposed Standard from Informational |
2005-10-24 |
06 | (System) | New version available: draft-ietf-isis-ipv6-06.txt |
2005-06-02 |
07 | (System) | This document has been resurrected |
2005-06-01 |
07 | Alex Zinin | I-D Resurrection was requested by Alex Zinin |
2005-05-26 |
07 | (System) | State Changes to Dead from AD is watching by IESG Secretary |
2004-09-29 |
05 | (System) | New version available: draft-ietf-isis-ipv6-05.txt |
2004-05-19 |
07 | Alex Zinin | State Changes to AD is watching from Waiting for AD Go-Ahead by Alex Zinin |
2004-05-19 |
07 | Alex Zinin | The WG needs to make a decision on whether this should go STD track. Changing the state accordingly. |
2004-05-19 |
07 | Alex Zinin | State Change Notice email list have been change to chopps@procket.com; dward@cisco.com from <tli@procket.com>, <prz@xebeo.com> |
2003-10-07 |
07 | Bill Fenner | [Note]: 'Waiting for draft-ietf-isis-traffic' has been cleared by Bill Fenner |
2003-10-07 |
07 | Bill Fenner | Shepherding AD has been changed to Alex Zinin from Bill Fenner |
2003-07-02 |
07 | Bill Fenner | Turns out draft-ietf-isis-traffic is still semi-stalled, so this document is still waiting for it. |
2003-06-22 |
07 | Bill Fenner | Last Call ended on June 10th. |
2003-06-22 |
07 | Bill Fenner | State Changes to Waiting for AD Go-Ahead from In Last Call by Fenner, Bill |
2003-05-30 |
07 | Amy Vezza | Status date has been changed to 2003-06-10 from |
2003-05-30 |
07 | Amy Vezza | State Changes to In Last Call from Last Call Requested by Vezza, Amy |
2003-05-23 |
07 | Bill Fenner | Now that draft-ietf-isis-traffic is almost approved, let's get this one moving. |
2003-05-23 |
07 | Bill Fenner | State Changes to Last Call Requested from AD Evaluation :: AD Followup by Fenner, Bill |
2003-02-04 |
07 | Bill Fenner | Bill to double-check that revision addresses concerns, then this needs to wait for draft-ietf-isis-traffic . |
2003-02-04 |
07 | Bill Fenner | State Changes to AD Evaluation :: AD Followup from AD Evaluation :: Revised ID Needed by Fenner, Bill |
2002-12-02 |
04 | (System) | New version available: draft-ietf-isis-ipv6-04.txt |
2002-11-04 |
07 | Bill Fenner | State Changes to AD Evaluation :: Revised ID Needed from AD Evaluation :: External Party by Fenner, Bill |
2002-11-04 |
03 | (System) | New version available: draft-ietf-isis-ipv6-03.txt |
2002-03-03 |
07 | (System) | State Changes to New Version Needed (WG/Author) from Token@wg or Author … State Changes to New Version Needed (WG/Author) from Token@wg or Author by IESG Member |
2002-02-28 |
07 | (System) | Waiting for updated version. |
2002-02-28 |
07 | (System) | State Changes to Token@wg or Author from Reading List … State Changes to Token@wg or Author from Reading List by IESG Member |
2001-04-02 |
02 | (System) | New version available: draft-ietf-isis-ipv6-02.txt |
2000-07-12 |
01 | (System) | New version available: draft-ietf-isis-ipv6-01.txt |
2000-01-03 |
00 | (System) | New version available: draft-ietf-isis-ipv6-00.txt |