Subject: RE: [Int-area] concerns about draft-ietf-ipv6-ndproxy-03.txt

From: "Bound, Jim" <[email-masked]>
Date: Tue, 20 Sep 2005 09:03:12 -0400

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-masked]; [email-masked]
> 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-masked] 
> > [mailto:[email-masked]] On Behalf Of Brian E 
> > Carpenter
> > Sent: Monday, September 19, 2005 8:47 AM
> > To: Pekka Savola
> > Cc: [email-masked]; [email-masked]
> > 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-masked]
> > https://www1.ietf.org/mailman/listinfo/int-area
> > 

_______________________________________________
Int-area mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/int-area

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 21 Sep 2005 15:39:53 +0200

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:
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>