Re: [P2PSIP] HIP: optional, mandatory?

"Roy, Radhika R Dr CTR USA USAMC" <radhika.r.roy@us.army.mil> Tue, 15 January 2008 19:32 UTC

Return-path: <p2psip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JErVw-0004WY-4V; Tue, 15 Jan 2008 14:32:00 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JErVu-0004V6-Pw for p2psip@ietf.org; Tue, 15 Jan 2008 14:31:58 -0500
Received: from mxoutps1.us.army.mil ([143.69.250.38]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JErVr-0003rs-GH for p2psip@ietf.org; Tue, 15 Jan 2008 14:31:57 -0500
DomainKey-Signature: s=ako; d=us.army.mil; c=nofws; q=dns; h=From:X-AKO:X-IronPort-AV:Received:Received:To:Cc: Message-ID:Date:X-Mailer:MIME-Version:Content-Language: Subject:X-Accept-Language:Priority:In-Reply-To:References: Content-Type:Content-Disposition: Content-Transfer-Encoding; b=UqzFwhBwFvlkDb563QK7EBGJ957oEsqNYQXJB0mRz+rM3qM7LLyQL1E2 ysEBl+CnzPho9IRIe/iE7ysYUlyf+Q==;
From: "Roy, Radhika R Dr CTR USA USAMC" <radhika.r.roy@us.army.mil>
X-AKO: 105122150:10.224.36.65:15 Jan 2008 19:31:52 +0000:$Webmail:None
X-IronPort-AV: E=Sophos;i="4.24,288,1196640000"; d="scan'208";a="105122150"
Received: from mail5.int.ps1.us.army.mil (HELO us.army.mil) ([10.224.36.65]) by mxoutps1.us.army.mil with ESMTP; 15 Jan 2008 19:31:52 +0000
Received: from [10.240.32.176] (Forwarded-For: 134.80.13.193, [10.240.32.176]) by mail5.int.ps1.us.army.mil (mshttpd); Tue, 15 Jan 2008 14:31:51 -0500
To: Gonzalo Camarillo <Gonzalo.Camarillo@ericsson.com>
Message-ID: <e1df81d5b8ce.478cc3d7@us.army.mil>
Date: Tue, 15 Jan 2008 14:31:51 -0500
X-Mailer: Sun Java(tm) System Messenger Express 6.2-9.04 (built Jun 11 2007)
MIME-Version: 1.0
Content-Language: en
Subject: Re: [P2PSIP] HIP: optional, mandatory?
X-Accept-Language: en
Priority: normal
In-Reply-To: <478BB75F.5080409@ericsson.com>
References: <476BA8D9.4010203@ericsson.com> <476E2B7C.9070601@ericsson.com> <20d2bdfb0801081416t41b9b84atb3a147659771036@mail.gmail.com> <77F357662F8BFA4CA7074B0410171B6D04049B22@XCH-NW-5V1.nw.nos.boeing.com> <7C5B8529-85C9-4977-8C57-34E9041ED1EC@nomadiclab.com> <77F357662F8BFA4CA7074B0410171B6D04049B33@XCH-NW-5V1.nw.nos.boeing.com> <10DA6CAF-DB5B-4B89-9417-4BEFD816B1E5@cs.columbia.edu> <4571B070-0B2F-4076-AAAB-4398295C9E88@cisco.com> <0c3a01c85402$28d821e0$6601a8c0@china.huawei.com> <CBAEA83C-A2BB-47E7-AE49-A3E901DDB50C@cs.columbia.edu> <4d4304a00801110710x1b7f04b4lcbcbb9eb8702ba1e@mail.gmail.com> <0d2101c85468$034c4080$6601a8c0@china.huawei.com> <1B79D7E7-A67B-42D9-9F00-66E69080C358@cs.columbia.edu> <478BB75F.5080409@ericsson.com>
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4
Cc: P2PSIP Mailing List <p2psip@ietf.org>
X-BeenThere: p2psip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Peer-to-Peer SIP working group discussion list <p2psip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/p2psip>, <mailto:p2psip-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/p2psip>
List-Post: <mailto:p2psip@ietf.org>
List-Help: <mailto:p2psip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/p2psip>, <mailto:p2psip-request@ietf.org?subject=subscribe>
Errors-To: p2psip-bounces@ietf.org

Gonzalo:

Good.

It is what is required for clarifications especially from the author of the draft as follows:

1. P2PSIP WG will develop the peer protocol.
2. The peer protocol will be simple one using KISS principles.

Let us focus on this and finish the development of the peer protocol first.

So, I, personally, want to help and expedite the above item of the WG. Once we have this one ready, the rest are the use cases of the peer protocol. In fact, this is the beauty of the entire process - to proceed step-by-step.

Best regards,
Radhika

PS: 

1. In fact, like you, we have also many more ideas how to solve many other problems using the standard peer protocol. You cannot believe that the emerging MANET networks are hungry for building applications once the peer protocol is standardized. It is a huge area as all applications need to migrate in peer-to-peer communications environments.

2. If the peer protocol development is completed on time by this WG, it will be an enormous help to the industry because a whole new areas for building the p2p-applications will be made open. We are yet to imagine what will be the impact of it in the future. So, let us finish our first task of the WG first as Cullen pointed out.

----- Original Message -----
From: Gonzalo Camarillo 
Date: Monday, January 14, 2008 14:26
Subject: Re: [P2PSIP] HIP: optional, mandatory?
To: Henning Schulzrinne 
Cc: P2PSIP Mailing List 

> Hi Henning,
> 
> > At least we're now clear that the HIP advocates want to 
> essentially 
> > force systems to implement it. This will hopefully focus the 
> discussion 
> > a bit.
> 
> not at all. I, for one, do not want to force anyone to implement 
> HIP if 
> he or she does not want to.
> 
> I agree with you that if you buy a product that supports "IETF 
> P2PSIP" 
> and I buy another product that also supports "IETF P2PSIP", they 
> should 
> be able to talk to each other... of course, we may find out that 
> our 
> boxes do not implement the right DHT, but that is a different story.
> 
> Of course, it would be OK for the P2PSIP WG to decide not to use 
> HIP for 
> "IETF P2PSIP" applications, if this is what most people want (this 
> is 
> what is being discussed). You are also right that, lately, we tend 
> to 
> build too complex systems and that we should be aplying the kiss 
> principle more often... but I come from a different perspective.
> 
> I want to build a HIP-based overlay. If the P2PSIP WG decides that 
> P2PSIP should be HIP-free, that's OK. If that was the case, I 
> would run 
> other types of applications on top of my HIP-based overlays.
> 
> The thing is that, in order to build my HIP-based overlay, I need 
> a peer 
> protocol whose functionality is a subset of the functionality 
> provided 
> by the peer protocols designed in the P2PSIP WG... therefore, in 
> order 
> to avoid reinventing the wheel once more, I would like to use 
> those peer 
> protocols for my HIP-based overlay.
> 
> Consequently, my requirement on the peer protocol is documented on 
> Section 5 of the HIP BONE draft:
> 
> ... the peer protocol
> standardized by the WG is kept functionally and specification
> wise reasonably modular so that the HIP community can use the
> peer protocol minus the connection management and NAT 
> traversal modules to experiment with HIP-based overlays. 
> Note that, at
> present, this is the case with several peer protocols.
> 
> I really hope nobody has a problem with this requirement.
> 
> With respect to whether or not option 3 (optional to implement and 
> run) 
> is actually an option, we can discuss whether or not making HIP 
> optional 
> to run for any given node in any given overlay adds too much 
> complexity 
> to a system (the capability negotiation mechanism needed for that 
> and 
> the stuff that would need to be implemented twice). I personally 
> tend to 
> think that the complexity would be relatively high, but some folks 
> do 
> not think so.
> 
> Cheers,
> 
> Gonzalo
> 
> 

_______________________________________________
P2PSIP mailing list
P2PSIP@ietf.org
https://www1.ietf.org/mailman/listinfo/p2psip