[P2PSIP] Review of draft-ietf-p2psip-self-tuning-08

Carlos Jesús Bernardos Cano <cjbc@it.uc3m.es> Mon, 29 July 2013 14:12 UTC

Return-Path: <cjbc@it.uc3m.es>
X-Original-To: p2psip@ietfa.amsl.com
Delivered-To: p2psip@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBE2121F9DCE for <p2psip@ietfa.amsl.com>; Mon, 29 Jul 2013 07:12:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.299
X-Spam-Level:
X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n53XrhNljTHw for <p2psip@ietfa.amsl.com>; Mon, 29 Jul 2013 07:11:58 -0700 (PDT)
Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by ietfa.amsl.com (Postfix) with ESMTP id B026B11E80A2 for <p2psip@ietf.org>; Mon, 29 Jul 2013 07:11:47 -0700 (PDT)
Received: from smtp02.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 55A36778A6A; Mon, 29 Jul 2013 16:11:46 +0200 (CEST)
X-uc3m-safe: yes
X-uc3m-safe: yes
Received: from [130.129.85.5] (dhcp-5505.meeting.ietf.org [130.129.85.5]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: cjbc@smtp02.uc3m.es) by smtp02.uc3m.es (Postfix) with ESMTPSA id CA04776B59C; Mon, 29 Jul 2013 16:11:45 +0200 (CEST)
Message-ID: <1375107104.4631.35.camel@acorde.it.uc3m.es>
From: Carlos Jesús Bernardos Cano <cjbc@it.uc3m.es>
To: p2psip@ietf.org
Date: Mon, 29 Jul 2013 16:11:44 +0200
Organization: Universidad Carlos III de Madrid
Content-Type: text/plain; charset="UTF-8"
X-Mailer: Evolution 3.4.4-3
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
X-TM-AS-Product-Ver: IMSS-7.1.0.1224-7.0.0.1014-20044.007
X-TM-AS-Result: No--13.884-7.0-31-1
X-imss-scan-details: No--13.884-7.0-31-1
Cc: draft-ietf-p2psip-self-tuning@tools.ietf.org
Subject: [P2PSIP] Review of draft-ietf-p2psip-self-tuning-08
X-BeenThere: p2psip@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: cjbc@it.uc3m.es
List-Id: Peer-to-Peer SIP working group discussion list <p2psip.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/p2psip>, <mailto:p2psip-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/p2psip>
List-Post: <mailto:p2psip@ietf.org>
List-Help: <mailto:p2psip-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/p2psip>, <mailto:p2psip-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 29 Jul 2013 14:12:05 -0000

Hi,

I've performed a Document Shepherd review of
draft-ietf-p2psip-self-tuning-08.

I think the document is in very good shape and I'll be requesting the
publication of the document later this week. I have some very minor
comments that maybe can be addressed by the authors in the next revision
of the document, together with any other comments you might get during
the next steps in the publication process:

- Page 3. Section 1 (Introduction). Expand DHT (first time it appears on
the document).

- Page 4. Section 2 (Terminology). There is a reference to
draft-ietf-p2psip-concepts. We'll discuss in this meeting (and follow up
on the ML later) what to do with this document. Depending on the
decision, you might need to modify/remove this part and add some other
changes.

- Page 4. Section 2 (Terminology). I think adding some text introducing
the listed terms would not harm.

- Page 4. Section 2 (Terminology). Some reordering of the terms might be
useful. For example, numBitsInNodeId can be introduced before Chord
Ring. Some comment about Routing Table and Successor List.

- Page 4. Section 2 (Terminology). Not sure it is needed to explain what
log2(N) represents.

- Page 16. Not sure if it is worth to explicitly mention if the result
of the join_rate field is a "floor" or a "ceil".

- Page 16. I'd maybe use "(log2(N))^2" instead of "log2^2(N)".

- Security Considerations. What would happen if a node sends fake
estimates? Maybe we need to add some text on that.

- Section 9.1. I guess RFC-AAAA refers to the number assigned to RELOAD
RFC, right? If so, adding a note to the RFC-Editor would not harm. 

- Section 11 (References). Ref [I-D.ietf-mmusic-ice] needs to be updated
with RFC 5245.

- Section 11 (References). Check consistency in the format used for the
references. For example, use expanded or shortened month names in all of
them.

- The nits checking tool also reports the following:

"The document seems to use 'NOT RECOMMENDED' as an RFC 2119 keyword, but
does not include the phrase in its RFC 2119 key words list."

Thanks,

Carlos