Point-to-Point Operation over LAN in Link State Routing Protocols
draft-ietf-isis-igp-p2p-over-lan-06
Revision differences
Document history
| Date | Rev. | By | Action |
|---|---|---|---|
|
2020-07-29
|
06 | (System) | Received changes through RFC Editor sync (removed Errata tag (all errata rejected)) |
|
2019-06-05
|
06 | Alvaro Retana | Downref to RFC 5309 approved by Last Call for draft-ietf-ospf-transition-to-ospfv3-12 |
|
2017-05-16
|
06 | (System) | Changed document authors from "Naiming Shen" to "Naiming Shen, Alex Zinin" |
|
2017-05-02
|
06 | (System) | Received changes through RFC Editor sync (added Errata tag) |
|
2015-10-14
|
06 | (System) | Notify list changed from isis-chairs@ietf.org to (None) |
|
2008-10-06
|
06 | Amy Vezza | State Changes to RFC Published from RFC Ed Queue by Amy Vezza |
|
2008-10-06
|
06 | Amy Vezza | [Note]: 'RFC 5309' added by Amy Vezza |
|
2008-10-03
|
06 | (System) | RFC published |
|
2006-07-24
|
06 | Bill Fenner | State Change Notice email list have been change to isis-chairs@tools.ietf.org from <chopps@procket.com>, <dward@cisco.com> |
|
2006-04-20
|
06 | (System) | New version available: draft-ietf-isis-igp-p2p-over-lan-06.txt |
|
2004-10-01
|
06 | Amy Vezza | State Changes to RFC Ed Queue from Approved-announcement sent by Amy Vezza |
|
2004-09-30
|
06 | Amy Vezza | IESG state changed to Approved-announcement sent |
|
2004-09-30
|
06 | Amy Vezza | IESG has approved the document |
|
2004-09-30
|
06 | Amy Vezza | Closed "Approve" ballot |
|
2004-09-28
|
06 | (System) | Removed from agenda for telechat - 2004-09-27 |
|
2004-09-27
|
06 | Bill Fenner | Note field has been cleared by Bill Fenner |
|
2004-09-27
|
06 | Amy Vezza | State Changes to Approved-announcement to be sent from IESG Evaluation by Amy Vezza |
|
2004-09-27
|
06 | Steven Bellovin | [Ballot Position Update] New position, No Objection, has been recorded for Steve Bellovin by Steve Bellovin |
|
2004-09-27
|
06 | Alex Zinin | [Ballot Position Update] New position, Abstain, has been recorded for Alex Zinin by Alex Zinin |
|
2004-09-27
|
06 | Harald Alvestrand | [Ballot comment] It was not 100% clear to me what it is that prevents this techique from being used to put four routers on a … [Ballot comment] It was not 100% clear to me what it is that prevents this techique from being used to put four routers on a LAN with pairwise point-to-point links between them. But the document says "two routers on a LAN" so many times that I'm inclined to believe that it means exactly what it says. |
|
2004-09-27
|
06 | Harald Alvestrand | [Ballot Position Update] New position, No Objection, has been recorded for Harald Alvestrand by Harald Alvestrand |
|
2004-09-27
|
06 | David Kessens | [Ballot Position Update] New position, No Objection, has been recorded for David Kessens by David Kessens |
|
2004-09-26
|
06 | Margaret Cullen | [Ballot Position Update] New position, No Objection, has been recorded for Margaret Wasserman by Margaret Wasserman |
|
2004-09-24
|
06 | Russ Housley | [Ballot Position Update] New position, No Objection, has been recorded for Russ Housley by Russ Housley |
|
2004-09-23
|
06 | Bill Fenner | Placed on agenda for telechat - 2004-09-27 by Bill Fenner |
|
2004-09-23
|
06 | Bill Fenner | State Changes to IESG Evaluation from IESG Evaluation::AD Followup by Bill Fenner |
|
2004-09-23
|
06 | Bill Fenner | [Note]: 'Returning to agenda to see if Pekka''s and Russ''s concerns have been addressed. I think they have. Diffs at http://rtg.ietf.org/~fenner/draft-ietf-isis-igp-p2p-over-lan.html' added by Bill Fenner |
|
2004-07-19
|
06 | Scott Hollenbeck | [Ballot Position Update] New position, No Objection, has been recorded for Scott Hollenbeck by Scott Hollenbeck |
|
2004-07-14
|
05 | (System) | New version available: draft-ietf-isis-igp-p2p-over-lan-05.txt |
|
2004-07-13
|
06 | Bill Fenner | [Ballot Position Update] New position, Yes, has been recorded for Bill Fenner |
|
2004-07-13
|
06 | Bill Fenner | Ballot has been issued by Bill Fenner |
|
2004-07-13
|
06 | Bill Fenner | Created "Approve" ballot |
|
2004-07-13
|
06 | (System) | Last call text was added |
|
2004-07-13
|
06 | (System) | Ballot approval text was added |
|
2004-07-09
|
06 | (System) | Sub state has been changed to AD Follow up from New Id Needed |
|
2004-07-09
|
04 | (System) | New version available: draft-ietf-isis-igp-p2p-over-lan-04.txt |
|
2004-06-23
|
06 | Bill Fenner | State Changes to IESG Evaluation::Revised ID Needed from IESG Evaluation::AD Followup by Bill Fenner |
|
2004-06-23
|
06 | Bill Fenner | [Note]: 'Waiting for document authors to discuss and/or address IESG comments/' added by Bill Fenner |
|
2004-06-23
|
06 | Bill Fenner | From: "Acee Lindem" <acee@redback.com> Subject: Re: draft-ietf-isis-igp-p2p-over-lan followup Date: Fri, 11 Jun 2004 10:37:15 -0400 To: <dward@cisco.com>, <chopps@procket.com>, < … From: "Acee Lindem" <acee@redback.com> Subject: Re: draft-ietf-isis-igp-p2p-over-lan followup Date: Fri, 11 Jun 2004 10:37:15 -0400 To: <dward@cisco.com>, <chopps@procket.com>, <naiming@redback.com>, <jenny@redback.com>, <zinin@psg.com>, <riw@cisco.com>, <sprevidi@cisco.com>, "Bill Fenner" <fenner@research.att.com> Cc: <pekkas@netcore.fi> > > Both routers on the LAN will simply join the AllSPFRouters > > ==> s/SPF/OSPF/ (or intentional?) This is consistent with the term for the IP multicast address 224.0.0.5 in RFC 2328 (Section A.1). Thanks, Acee |
|
2004-04-05
|
06 | Bill Fenner | [Note]: 'On agenda for 2003-10-02 telechat' has been cleared by Bill Fenner |
|
2004-04-05
|
06 | Bill Fenner | State Change Notice email list have been change to <chopps@procket.com>, <dward@cisco.com> from <tli@procket.com>, <prz@xebeo.com> |
|
2003-10-02
|
06 | Amy Vezza | Removed from agenda for telechat - 2003-10-02 by Amy Vezza |
|
2003-10-02
|
06 | Amy Vezza | State Changes to IESG Evaluation::AD Followup from IESG Evaluation by Amy Vezza |
|
2003-10-02
|
06 | Bill Fenner | <pre><br> From: Pekka Savola <pekkas@netcore.fi><br> To: Randy Bush <randy@psg.com><br> cc: ops directorate <ops-dir@ops.ietf.org><br> Subject: draft-ietf-isis-igp-p2p-over-lan-03.txt [Re: Agenda and Package … <pre><br> From: Pekka Savola <pekkas@netcore.fi><br> To: Randy Bush <randy@psg.com><br> cc: ops directorate <ops-dir@ops.ietf.org><br> Subject: draft-ietf-isis-igp-p2p-over-lan-03.txt [Re: Agenda and Package for<br> October 2, 2003 Telechat]<br> Date: Tue, 30 Sep 2003 00:02:27 +0300 (EEST)<br> <br> On Fri, 26 Sep 2003, Randy Bush wrote:<br> > 3.1 WG Submissions<br> > 3.1.1 New Item<br> > **** o draft-ietf-isis-igp-p2p-over-lan-03.txt<br> > Point-to-point operation over LAN in link-state routing protocols <br> > (Informational) - 1 of 2 <br> > Note: On agenda for 2003-10-02 telechat <br> > Token: Bill Fenner<br> <br> IMHO, not ready yet. Comments below. Feel free to unmask (as always).<br> <br> I had time for a quick read only, but should be enough for now..<br> <br> In general, I think this is a very useful approach, with the advent of <br> Ethernet-type media for WAN links. However, the specification appears <br> incomplete to me.<br> <br> ==> why is this meant for Informational? This kind of stuff could be <br> useful in Experimental/PS as well.<br> <br> ==> The document has a large number of IPv4 dependencies, some of them <br> subtler than the others (ARP vs Neighbor Discovery, discussion of only <br> OSPFv2/IS-IS). This is unacceptable.<br> <br> ==> the draft has one author too many (6 at the moment)<br> <br> ==> add the IPR, copyrights, etc. sections at the end, please.<br> <br> 4.1 Operation of ISIS<br> [...]<br> <br> The circuit needs to have IP address(es) and the p2p IIH over this<br> circuit MUST include the IP interface address(es) as defined in<br> [ref2]. The IP address(es) can be numbered or unnumbered.<br> <br> ==> Uhh, I don't understand what is an "unnumbered IP address". <br> In my book, you either have an IP address or you don't? <br> What am I missing? Note, ref2 [RFC1195] doesn't mention "unnumbered" <br> at all.<br> <br> 4.3 IP forwarding and ARP<br> [...]<br> Proxy ARP has to be enabled if the address is not the adjacent<br> interface IP address.<br> <br> ==> this seems a bit awkward, couldn't you say it easier with like:<br> <br> Proxy ARP has to be enabled if the addresses do not share the<br> same IP subnet.<br> <br> ==> further than that, I'm not sure if it has been described in enough <br> detail why exactly you need proxy ARP. It's used in a bit unconventional <br> way, it seems to me ("router X proxy-arping for it's loopback addresses"), <br> right? I'm not sure if you need proxy-arp for that (or at least, describe <br> that this is what you mean with proxy-arp), defining that a router just <br> responds to loopback addresses with ARP on the particular interfaces would <br> be OK as well.<br> <br> ....<br> <br> In the case where unnumbered IP addresses are used for p2p-over-lan<br> circuit, the source IP address of ARP request and the target<br> interface IP address are usually on different subnets. The ARP<br> should reply if this is a p2p-over-lan circuit, or an<br> implementation MAY choose to limit the reply to the case where the<br> IGP peer is requesting over this unnumbered p2p-over-lan circuit.<br> <br> ==> IGP peer is requesting *what* ? <br> ==> I think the whole paragraph should be rewritten, starting from "The<br> ARP". I've _very_ little idea what you're actually specifying here.<br> <br> 7. Security Issues <br> <br> ==> s/Issues/Considerations/<br> <br> ==> I'd also add here something on the potential for misconfiguration, <br> affecting availability, like:<br> <br> If one router on a link thinks that a LAN should be either broadcast or<br> p2p-over-lan, and the other router has a different opinion, the<br> adjacencies will never form, as specified in Section 5. There are no<br> fallbacks at either end to resolve the situation, except by a manual<br> configuration change.<br> <br> purely editorial<br> ----------------<br> <br> Since the physically circuit is a broadcast one, the ISIS protocol<br> <br> ==> s/the physically/physically the/<br> <br> Both routers on the LAN will simply join the AllSPFRouters<br> <br> ==> s/SPF/OSPF/ (or intentional?)<br> <br> -- <br> Pekka Savola "You each name yourselves king, yet the<br> Netcore Oy kingdom bleeds."<br> Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings<br></pre> |
|
2003-10-02
|
06 | Bill Fenner | Russ, I agree the sentence doesn't make much sense as written. It is talking about the issue that's described a little better in this … Russ, I agree the sentence doesn't make much sense as written. It is talking about the issue that's described a little better in this paragraph from RFC 1027: If the IP networks of the source and target hosts of an ARP request are different, an ARP subnet gateway implementation should not reply. This is to prevent the ARP subnet gateway from being used to reach foreign IP networks and thus possibly bypass security checks provided by IP gateways. i.e. the "normal check" that he's talking about is "is this ARP for an IP address that's on the subnet to which this interface is attached", so that you don't cache an ARP entry for an arbitrary address that's not normally on this subnet, with mac address pointing to an attacker. You have to relax this check in the "unnumbered" case, since there is no subnet (second paragraph of section 4.3). How about this for a revised final sentence? "This is due to the fact that the normal ARP sanity check that the address is on the same subnet as the interface on which it was received can not be applied in this case." Thanks, Bill |
|
2003-10-01
|
06 | Russ Housley | Please change the title of section 7 to "Security Considerations." Also, I do not understand the last sentence of section 7. It says: "This is … Please change the title of section 7 to "Security Considerations." Also, I do not understand the last sentence of section 7. It says: "This is due to normal ARP sanity check for common subnet can not be applied in this case." |
|
2003-09-17
|
06 | Bill Fenner | Placed on agenda for telechat - 2003-10-02 by Bill Fenner |
|
2003-09-17
|
06 | Bill Fenner | State Changes to IESG Evaluation from AD Evaluation::External Party by Bill Fenner |
|
2003-09-17
|
06 | Bill Fenner | Version -03 satisfies my concerns. |
|
2003-09-16
|
03 | (System) | New version available: draft-ietf-isis-igp-p2p-over-lan-03.txt |
|
2003-08-07
|
06 | Bill Fenner | <pre><br> ----- Begin forwarded message:<br> <br> From: Naiming Shen <naiming@redback.com><br> Subject: Re: Comments on draft-ietf-isis-igp-p2p-over-lan-02.txt<br> Date: Sat, 14 Jun 2003 00:47:25 -0700<br> … <pre><br> ----- Begin forwarded message:<br> <br> From: Naiming Shen <naiming@redback.com><br> Subject: Re: Comments on draft-ietf-isis-igp-p2p-over-lan-02.txt<br> Date: Sat, 14 Jun 2003 00:47:25 -0700<br> To: Bill Fenner <fenner@research.att.com><br> Cc: naiming@redback.com, acee@redback.com, jenny@redback.com,<br> zinin@psg.com, riw@cisco.com, sprevidi@cisco.com<br> <br> <br> Hi Bill,<br> <br> ] <br> ] Hi,<br> ] <br> ] Sorry this has taken so long. I only have two technical comments<br> ] on this spec. I'm willing to be told I'm confused as long as you help<br> ] me understand exactly how confused I am =)<br> <br> You are not confused;-) just a different way looking at the problems.<br> Those are good comments.<br> <br> I think you basically have 3 points/questions:<br> <br> (1) in section 4.3, why should IGP be coupled with ARP<br> (2) this mechanism should be normal ARP instead of Proxy ARP<br> (3) remove this "broadcast/multicast" sentence<br> <br> For the (1):<br> I think there are a couple of things. Some people are concerned<br> about the "security" aspect of it, and since in the unnumbered<br> p2p-over-lan case, the basic ARP sanity check fails, there need<br> to have some way of checking. In RFC1027, Using ARP<br> to Implement Transparent Subnet Gateways, in section 2.4,<br> <br> Sanity checks:<br> <br> If the IP networks of the source and target hosts of an ARP request<br> are different, an ARP subnet gateway implementation should not<br> reply. This is to prevent the ARP subnet gateway from being used to<br> reach foreign IP networks and thus possibly bypass security checks<br> provided by IP gateways.<br> <br> One way to check in this case is: IGP knows the peer address, and the<br> ARP request has to come from that peer address for ARP to honor the<br> request. This is just a "security" thing, and is a "should", not a<br> "must" in the draft.<br> <br> Another angle to look at this is that, p2p-over-lan only works if<br> there is two routers communicate to each other over the logical<br> LAN. If there are third parties trying to use this router as<br> gateways on the LAN, there could be misconfiguration or intruders.<br> then, making such a check is a good thing.<br> <br> But I don't have strong feelings either way. If we think it's ok<br> to say as long as this is a p2p-over-lan link and someone asking<br> for ARP resolution over that, we don't need to check, just reply.<br> I'm fine with that too.<br> <br> For the (2):<br> This "Proxy" ARP term is used because for "normal" ARP, the requester <br> and the target are not on the same subnet. If a host/router wants to <br> ARP some address which is not on the same subnet, the "proxy" ARP<br> is used.<br> <br> In this p2p-over-lan case, we can argue both ways: one view is that,<br> even though the interface is borrowing an IP address from another <br> internal interface, it should consider this address is its own. So<br> no Proxy Arp is needed; anther view is that, in p2p-over-lan and<br> unnumbered interface case, someone is asking to resolve the address<br> belong to anther internal interface, and the IA and target address<br> are on different subnet. So this fits the proxy ARP concept.<br> <br> I can imagine this is also implementation specific, someone can<br> implement it like the "normal" ARP, others can implement it like<br> a "proxy" ARP procedure. I noticed some vendors implemented this<br> p2p-over-lan completely as an IGP issue. Thus the ARP or interface<br> don't even know this is a "p2p" interface, or an "unnumbered"<br> interface. then they should treat such a ARP request as a proxy<br> arp case.<br> <br> Maybe we should change the wording from MUST to SHOULD, on enabling <br> proxy arp in unnumbered interface case.<br> <br> For the (3):<br> I don't have problem removing the bullet 4 of section 4.4.<br> <br> <br> comments?<br> <br> thanks.<br> <br> ] <br> ] - Section 4.3 seems to be overly restrictive, and couples the IGP pretty<br> ] tightly with ARP. The algorithm in RFC 826 seems to actually capture<br> ] this case just fine:<br> ] <br> ] >As a packet is sent down through the network layers, routing <br> ] >determines the protocol address of the next hop for the packet <br> ] >and on which piece of hardware it expects to find the station<br> ] >with the immediate target protocol address.<br> ] <br> ] i.e. look in the routing table to find an interface and nexthop, exactly<br> ] as the draft says. The decision process for whether to respond to an<br> ] ARP request includes the question<br> ] <br> ] > ?Am I the target protocol address?<br> ] <br> ] This is presumably the part that might require modification, since<br> ] an arp implementation might not check all of its IP addresses. However,<br> ] if 4.3 just said that ARP uses the unnumbered address to decide whether<br> ] it is the target of the ARP request, that would be sufficient (i.e.<br> ] if this interface is configured as being unnumbered, arp should behave<br> ] in the following manner).<br> ] <br> ] I also don't think it's correct to describe this as "proxy arp".<br> ] It's within epsilon of the exact behavior described in RFC 826.<br> ] <br> ] <br> ] - In section 4.4, I think bullet 4 should be either fleshed out or<br> ] removed. i.e., if you have some ideas about how multicast or<br> ] broadcast can be used, then say what they are. Otherwise, just leave<br> ] the door open for other mechanisms. (Also, if you remove the link<br> ] between IGP and ARP as I suggested, the sentence "For example, if<br> ] link-state IGP is not configured over this p2p-over-lan link, or Proxy<br> ] ARP is not enabled on the circuit." could go)<br> ] <br> ] <br> ] I'd like to discuss these if you have issues - they are NOT mandates,<br> ] they are just points that I came across as a fresh set of eyes on the<br> ] spec that I want to be sure of before we go forward.<br> ] <br> ] Thanks,<br> ] Bill<br> <br> - Naiming<br> <br> <br> ----- End forwarded message<br> ----- Begin forwarded message:<br> <br> Subject: Re: Comments on draft-ietf-isis-igp-p2p-over-lan-02.txt<br> Date: Thu, 7 Aug 2003 17:50:32 -0700<br> To: naiming@redback.com<br> Cc: acee@redback.com jenny@redback.com zinin@psg.com riw@cisco.com<br> sprevidi@cisco.com<br> <br> Naiming,<br> <br> >I think you basically have 3 points/questions:<br> > <br> > (1) in section 4.3, why should IGP be coupled with ARP<br> > (2) this mechanism should be normal ARP instead of Proxy ARP<br> > (3) remove this "broadcast/multicast" sentence<br> <br> >For the (1):<br> > I don't have strong feelings either way. If we think it's ok<br> > to say as long as this is a p2p-over-lan link and someone asking<br> > for ARP resolution over that, we don't need to check, just reply.<br> > I'm fine with that too.<br> <br> I think that something needs to be spelled out, since implementations<br> presumably need some change. If you can say that on p2p-over-lan<br> links, it's OK to reply to ARP requests for the "unnumbered" address,<br> plus if you want more security you MAY limit this to the case where<br> the IGP peer is requesting, I think that'd be the best of both worlds.<br> <br> >For the (2):<br> > In this p2p-over-lan case, we can argue both ways: one view is that,<br> > even though the interface is borrowing an IP address from another <br> > internal interface, it should consider this address is its own. So<br> > no Proxy Arp is needed; anther view is that, in p2p-over-lan and<br> > unnumbered interface case, someone is asking to resolve the address<br> > belong to anther internal interface, and the IA and target address<br> > are on different subnet. So this fits the proxy ARP concept.<br> <br> Right, my thinking was that whether or not it's really "proxy arp" is more<br> of an implementation detail, so saying it's required is not really true<br> if the ARP implementation knows about the p2p nature of the interface.<br> Maybe mentioning that existing proxy arp implementations should be<br> capable of performing the needed operations, or an ARP implementation<br> may explicitly know the IP address assigned to the p2p-over-lan interface?<br> <br> In section 4.4, the mention of proxy arp is just when talking about what<br> you do if you don't do what's in 4.3 -- so maybe the best thing to do<br> is just to say "For example, if the mechanism described in section 4.3<br> is not possible." What do you think?<br> <br> >For the (3):<br> > I don't have problem removing the bullet 4 of section 4.4.<br> <br> Great.<br> <br> Thanks,<br> Bill<br> <br> ----- End forwarded message<br></pre> |
|
2003-06-17
|
06 | Bill Fenner | Intended Status has been changed to Informational from None |
|
2003-06-10
|
06 | Bill Fenner | authors interacted with rtg-dir March 12-21, presumably the results of these discussions will be reflected in a spec update |
|
2003-06-10
|
06 | Bill Fenner | State Changes to AD Evaluation :: External Party from AD Evaluation by Fenner, Bill |
|
2003-06-10
|
06 | Bill Fenner | <pre><br> Subject: Comments on draft-ietf-isis-igp-p2p-over-lan-02.txt<br> Date: Tue, 10 Jun 2003 18:02:03 -0700<br> To: naiming@redback.com,acee@redback.com,jenny@redback.com,zinin@psg.<br> com,riw@cisco.com,sprevidi@cisco.com … <pre><br> Subject: Comments on draft-ietf-isis-igp-p2p-over-lan-02.txt<br> Date: Tue, 10 Jun 2003 18:02:03 -0700<br> To: naiming@redback.com,acee@redback.com,jenny@redback.com,zinin@psg.<br> com,riw@cisco.com,sprevidi@cisco.com<br> <br> Hi,<br> <br> Sorry this has taken so long. I only have two technical comments<br> on this spec. I'm willing to be told I'm confused as long as you help<br> me understand exactly how confused I am =)<br> <br> - Section 4.3 seems to be overly restrictive, and couples the IGP pretty<br> tightly with ARP. The algorithm in RFC 826 seems to actually capture<br> this case just fine:<br> <br> >As a packet is sent down through the network layers, routing <br> >determines the protocol address of the next hop for the packet <br> >and on which piece of hardware it expects to find the station<br> >with the immediate target protocol address.<br> <br> i.e. look in the routing table to find an interface and nexthop, exactly<br> as the draft says. The decision process for whether to respond to an<br> ARP request includes the question<br> <br> > ?Am I the target protocol address?<br> <br> This is presumably the part that might require modification, since<br> an arp implementation might not check all of its IP addresses. However,<br> if 4.3 just said that ARP uses the unnumbered address to decide whether<br> it is the target of the ARP request, that would be sufficient (i.e.<br> if this interface is configured as being unnumbered, arp should behave<br> in the following manner).<br> <br> I also don't think it's correct to describe this as "proxy arp".<br> It's within epsilon of the exact behavior described in RFC 826.<br> <br> <br> - In section 4.4, I think bullet 4 should be either fleshed out or<br> removed. i.e., if you have some ideas about how multicast or<br> broadcast can be used, then say what they are. Otherwise, just leave<br> the door open for other mechanisms. (Also, if you remove the link<br> between IGP and ARP as I suggested, the sentence "For example, if<br> link-state IGP is not configured over this p2p-over-lan link, or Proxy<br> ARP is not enabled on the circuit." could go)<br> <br> <br> I'd like to discuss these if you have issues - they are NOT mandates,<br> they are just points that I came across as a fresh set of eyes on the<br> spec that I want to be sure of before we go forward.<br> <br> Thanks,<br> Bill<br></pre> |
|
2003-03-26
|
02 | (System) | New version available: draft-ietf-isis-igp-p2p-over-lan-02.txt |
|
2003-03-25
|
06 | Bill Fenner | Alex is a co-author so shouldn't be the responsible AD. |
|
2003-03-25
|
06 | Bill Fenner | Shepherding AD has been changed to Fenner, Bill from Zinin, Alex |
|
2003-03-12
|
06 | Alex Zinin | in review by rtg-dir |
|
2003-03-12
|
06 | Alex Zinin | Status date has been changed to 2003-03-29 from |
|
2003-03-11
|
06 | Alex Zinin | Passed the WG LC. Will review after the SF IETF. |
|
2003-03-11
|
06 | Alex Zinin | State Changes to AD Evaluation from Publication Requested by Zinin, Alex |
|
2003-03-11
|
06 | Alex Zinin | Draft Added by Zinin, Alex |
|
2002-09-17
|
01 | (System) | New version available: draft-ietf-isis-igp-p2p-over-lan-01.txt |
|
2001-09-21
|
00 | (System) | New version available: draft-ietf-isis-igp-p2p-over-lan-00.txt |