I am fine with that it is the sense that this new group can over-rule the IETF process that is all. A PS has to have continued technical review and Thomas could have expressed his concerns in the IPv6 WG.
/jim > -----Original Message----- > From: Brian E Carpenter [mailto:[EMAIL PROTECTED] > Sent: Wednesday, September 21, 2005 9:40 AM > To: Bound, Jim > Cc: Pekka Savola; [email protected]; [EMAIL PROTECTED] > Subject: Re: [Int-area] concerns about draft-ietf-ipv6-ndproxy-03.txt > > Actually Jim, it is an open mailing list and they > hold open Area meetings, so I don't see your concern. > The point isn't overruling. It's that when an IPv6 document > covers IPv4 topics, then the wider perspective is relevant. > > But more to the point - a number of specific technical > issues have been raised and need to be answered. > > Brian > > Bound, Jim wrote: > > 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]; [email protected] > >>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]; [email protected] > >>>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 > >>>[email protected] > >>>https://www1.ietf.org/mailman/listinfo/int-area > >>> > > > > > > -------------------------------------------------------------------- > > IETF IPv6 working group mailing list > > [email protected] > > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > > -------------------------------------------------------------------- > > > > _______________________________________________ Int-area mailing list [email protected] https://www1.ietf.org/mailman/listinfo/int-area
