I also do not support the idea or process of an area ad hoc mail list overruling a working group or chairs support of a document at all. We already have far to much process and missing time to market from within the IETF with industry. This is highly questionable behavior as even a thought.
/jim > -----Original Message----- > From: Bound, Jim > Sent: Tuesday, September 20, 2005 8:48 AM > To: 'Brian E Carpenter'; Pekka Savola > Cc: [EMAIL PROTECTED]; ipv6@ietf.org > Subject: RE: [Int-area] concerns about draft-ietf-ipv6-ndproxy-03.txt > > I support nd proxy it should be PS. It should not go to DS > without wide implementation from multiple members I do not > believe it is under specified either. Would I recommend it > on a production network, not at all. What some may be > uncomfortable with if they are not implementers is the > complexity for net centric implementation capabability. The > idea has been implemented in many forms and has nothing to do > with ARP or ND, they are simply the vehicle to permit the > deployment model of partitioned links. This team did its job > and checked with multiple domain experts across the IETF my > input is to move on. > > /jim > > > -----Original Message----- > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED] On Behalf Of Brian E > > Carpenter > > Sent: Monday, September 19, 2005 8:47 AM > > To: Pekka Savola > > Cc: [EMAIL PROTECTED]; ipv6@ietf.org > > Subject: Re: [Int-area] concerns about > draft-ietf-ipv6-ndproxy-03.txt > > > > People might want to look in the tracker at the other comments > > that have come up. > > > > https://datatracker.ietf.org/public/pidtracker.cgi?command=vie > > w_id&dTag=12623&rfc_flag=0 > > > > Brian > > > > Pekka Savola wrote: > > > (FWIW, I think ND proxies are useful and needed.) Some comments > > > inline. Adding ipv6 WG. > > > > > > On Thu, 15 Sep 2005, Thomas Narten wrote: > > > > > >> 1) I do not believe the material on IPv4 ARP proxy should be > > >> included. It is not in-scope for the IPv6 WG to be > > developing it, and > > >> any document on proxy ARP in IPv4 really requires review from the > > >> broader community. AFAIK, that review has not taken place. > > >> > > >> Recommendation: remove the IPv4 material and place in a separate > > >> document > > > > > > > > > v4 part is said to reflect what one implementation does, > > but I guess > > > even for Informational, that info might be too much. I > > guess it could > > > be taken out of fleshed out in a separate spec (if anyone > > is interested > > > in documenting proxy-arp behaviour..) > > > > > >> 2) This document breaks SEND (but does not say this > > clearly). I have > > >> doubts that we should be publishing documents that break > > our standards > > >> track protocols (especially ones that we believe are > > important). Or at > > >> the very least, if it is published, very strong wording is > > needed to > > >> point out that it is incompatable with SEND, e.g., an IESG note. > > > > > > > > > Wording could be enhanced, but I do not think this document > > should be > > > blocked by the missing SEND details. > > > > > >> 3) this document may have implications for DHC. In particular, > > >> document says: > > > > > > > > > This is moot if v4 parts are removed. > > > > > >> 4) The history of this document is troubling, and I > believe it does > > >> not have strong support from the WG. Rather, I'd > > characterize this as > > >> an effort that has gotten this far mostly because the vast > > majority of > > >> the WG has tuned out and no longer is following the work. > > >> > > >> The history of this effort (though I may be biased) is > > that the IPv6 > > >> WG desired a simple proxy mechanism for the following > case. Suppose > > >> one has an access router connecting to an upstream ISP, > > and that link > > >> is assigned a prefix (say X). It would be nice if the > access router > > >> could readvertise that prefix (say for a home network), > acting as a > > >> simple bridge. > > > > > > ... > > > > > >> But it's scope is quite a lot broader than what > > >> the charter called for. > > > > > > > > > I'm not sure if I understand your comment. Are you saying > > the ND proxy > > > spec is too complicated? > > > > > > Well, I myself suggested removing the spanning tree loop > > prevention from > > > the draft completely (now it has a bit in the RAs) because > > it wasn't > > > needed in the applicability we had in mind. But folks that > > didn't like > > > ND proxy argued that infinite loops are not nice, even in illegal > > > configurations, so we're stuck with some additional specification. > > > > > > How would you like to see it simplified? Do you have an > > alternative in > > > mind? > > > > > > (To me, ND proxies seems "as simple as it can get" excluding loop > > > prevention which I argued for removal but folks thought > the failure > > > modes were too dangerous..) > > > > > > > > > _______________________________________________ > > Int-area mailing list > > Int-area@lists.ietf.org > > https://www1.ietf.org/mailman/listinfo/int-area > > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
