IETF Logo Mail Archive

[P2PSIP] Status of RELOAD

michaelc@idssoftware.com Wed, 23 January 2008 03:02 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 1JHVsM-0003DU-16; Tue, 22 Jan 2008 22:02:06 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHVsL-0003DL-F8 for p2psip@ietf.org; Tue, 22 Jan 2008 22:02:05 -0500
Received: from smtpoutwbe02.prod.mesa1.secureserver.net ([208.109.78.113]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1JHVsK-0003lg-Rj for p2psip@ietf.org; Tue, 22 Jan 2008 22:02:05 -0500
Received: (qmail 11684 invoked from network); 23 Jan 2008 03:02:03 -0000
Received: from unknown (HELO gem-wbe20.prod.mesa1.secureserver.net) (64.202.189.175) by smtpoutwbe02.prod.mesa1.secureserver.net with SMTP; 23 Jan 2008 03:02:03 -0000
Received: (qmail 28376 invoked by uid 99); 23 Jan 2008 03:02:03 -0000
Date: Tue, 22 Jan 2008 20:02:03 -0700
From: michaelc@idssoftware.com
To: p2psip@ietf.org
Message-ID: <20080122200203.59ca11a9ba9389561a029f06442e67fa.ff22e2cc50.wbe@email.secureserver.net>
MIME-Version: 1.0
User-Agent: Web-Based Email 4.12.20
X-Originating-IP: 72.87.190.177
X-Spam-Score: 1.7 (+)
X-Scan-Signature: bb8eae9af85e4fcfe76f325e38493bf4
Subject: [P2PSIP] Status of RELOAD
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>
Content-Type: multipart/mixed; boundary="===============1927128924=="
Errors-To: p2psip-bounces@ietf.org

Hi Cullen,

RELOAD-1 was a solid protocol with strengths like the flexibility of TLV, 32-bit alignment, full 160-bit IDs, well defined symbolic values, etc.  By comparison, the ASP draft was pretty rough.  When these two merged into RELOAD-2, most of the RELOAD-1 pros were lost.  Is RELOAD-3 on its way?

Many fields in RELOAD-2 are variable size values or arrays, so why not use Type-Length-Value to make the protocol more "binary readable" and extensible?  RELOAD-1 defines a single fixed header and everything else in TLV.  That is too good to abandon, not to mention being a perfect construct for supporting multiple DHTs.

By the way, I have seen several drafts use 128-bit ID in fixed structures, which means truncating the low 32-bit of a SHA-1 hash.  Is there a potential risk?  Any formal paper about this?

Thanks

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

v2.23.0 | Report a Bug | By Email