Thanks Roy! This is actually orthogonal to the HIP discussion - it was my omission to specify.
Henry -----Original Message----- From: Roy, Radhika R Dr CTR USA USAMC [mailto:[EMAIL PROTECTED] Sent: Monday, January 14, 2008 10:13 AM To: Henry Sinnreich Cc: Cullen Jennings; P2PSIP Mailing List Subject: Re: RE: [P2PSIP] HIP: optional, mandatory? Henry: Right, per P2PSIP Charter objectives. Best regards, Radhika ----- Original Message ----- From: Henry Sinnreich Date: Monday, January 14, 2008 10:13 Subject: RE: [P2PSIP] HIP: optional, mandatory? To: "Roy, Radhika R Dr CTR USA USAMC" , Cullen Jennings Cc: P2PSIP Mailing List > Radhika, > > > what is the problem to proceed per P2PSIP charter for accomplishing > the mandated > work items (may be in a limited way) soon which may be > ready for deployment? > > I presume you share the view that "ready for deployment" means open > available running code and performance reports from actual test > deployments and you don't mean just eloquently written papers? > > Henry > > -----Original Message----- > From: Roy, Radhika R Dr CTR USA USAMC > [mailto:[EMAIL PROTECTED] > Sent: Friday, January 11, 2008 11:04 AM > To: Cullen Jennings > Cc: P2PSIP Mailing List > Subject: Re: [P2PSIP] HIP: optional, mandatory? > > If it is so as Cullen has explained, what is the problem to > proceed per > P2PSIP charter for accomplishing the mandated work items (may be > in a > limited way) soon which may be ready for deployment? > > Cheers! > Radhika > > ----- Original Message ----- > From: Cullen Jennings > Date: Friday, January 11, 2008 11:40 > Subject: Re: [P2PSIP] HIP: optional, mandatory? > To: David Barrett > Cc: P2PSIP Mailing List > > > > > On Jan 10, 2008, at 8:23 PM, David Barrett wrote: > > > > > We don't need more options for what we CAN do, we need > decisions > > on > > > what we WILL do. > > > > Yep - agree. And what I want to do is standardize something that > > lets me build deployable interoperable solutions soon. Success > for > > me > > involves deployments. > > > > > If we're not considering making HIP mandatory, then let's stop > > > > > talking about it and start focusing on those things that > *will* > > be > > > mandatory. > > > > The P2PSIP WG has made very few decisions since it was formed. > > IMHO, > > what we need to do real soon now is pick something as a starting > > point for a WG document then go and make the decision to change > it > > to > > be what we want. Until we do that, my belief is that the WG will > > make fairly marginal progress. > > > > > > > > That said, I think this HIP discussion is the best thing to > > happen > > > in P2PSIP for years. It seems like the most practical and > > powerful > > > solution, the best layering of functionality, and the most > > feasible > > > design that I've yet to hear. Moving the hard P2P code into a > > > reusable HIP layer makes a lot of sense, > > > > this is way outside anything HIP was charted to do or is working on > > > > > not only for P2PSIP, but for the internet as a whole. It seems > > > like a wagon that we should voluntarily and enthusiastically > > hitch > > > ourselves to, rather than try to reproduce or compete with it, > > or > > > toss it in the overflowing bucket of optional extensions. > > > > > > It seems sensible to have a base HIP layer that either comes > pre- > > > > > installed with the OS or redistributed by the application > > (similar > > > to WinPCap). (I could even see making a sort of "HIP-lite" > self- > > > > > contained library that can be linked straight into the > > application > > > for when installing a Then P2PSIP can be one of many HIP-using > > > > > applications that are vastly simplified by being insulated > from > > the > > > gnarly realities of NAT and firewall penetration, mobility, etc. > > > > > > This makes a lot more sense than continually reproducing this > > > really hard functionality in every application. > > > > Most of the concrete proposals layer the p2p code such that the > > library that provided the p2p part could be used by other > > applications. This is a good design but not something you need > HIP > > to > > accomplish. > > > > > > > > -david > > > > Cullen > > > > > > > > On Jan 11, 2008, at 7:33 AM, Cullen Jennings wrote: > > > > > >> > > >> I was assuming most folks were talking about (3) given that > > much > > >> of HIP is still being designed and it will be awhile to get > > things > > >> build and deployed. I know lots of parts of HIP have been > done > > but > > >> when we are talking about mobility, nat traversal, no DNS, > and > > >> easy end user installations, there is still work. Anyway, I > am > > in > > >> the 3 category. > > >> > > >> Cullen > > >> On Jan 10, 2008, at 2:14 PM, Henning Schulzrinne wrote: > > >> > > >>> One of the issues I don't understand about this discussion > is > > >>> whether all instances of P2PSIP would be expected to be > > running > > >>> HIP or just some. There seem to be at least three options: > > >>> > > >>> (1) Mandatory to implement and run > > >>> > > >>> The only non-recursive-dependency model seems to be that > peer > > >>> nodes would store the HIT-IP bindings in their routing > tables. > > > > >>> (This largely negates any mobility advantages, but that's a > > >>> separate discussion.) > > >>> > > >>> (2) Mandatory to implement, but there can be instances of an > > >>> overlay (or maybe even part of an overlay) that don't use HIP > > >>> > > >>> This would require providing ICE functionality at both the > HIP > > > > >>> level and directly to the P2P protocol. > > >>> > > >>> (3) Optional to implement and run > > >>> > > >>> This only works if you can have mixed HIP-non-HIP nodes. > Also > > >>> requires implementations of ICE in both layers and the > ability > > to > > >>> mix-and-match HIP and non-HIP nodes within an overlay, > unless > > >>> each overlay has a "HIP flag". > > >>> > > >>> I admit that I'm rather worried about the complexity of this > > >>> whole edifice. I think it would be helpful if the proponents > > of a > > >>> HIP-based approach stated clearly which of these they have > in > > mind.>>> > > >>> Henning > > _______________________________________________ > P2PSIP mailing list > [email protected] > https://www1.ietf.org/mailman/listinfo/p2psip > _______________________________________________ P2PSIP mailing list [email protected] https://www1.ietf.org/mailman/listinfo/p2psip
