[VIPR] Review of draft-jennings-vipr-overview-00

Marc Petit-Huguenin <petithug@acm.org> Mon, 02 May 2011 17:22 UTC

Return-Path: <petithug@acm.org>
X-Original-To: vipr@ietfa.amsl.com
Delivered-To: vipr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD2B0E06B1 for <vipr@ietfa.amsl.com>; Mon, 2 May 2011 10:22:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.365
X-Spam-Level:
X-Spam-Status: No, score=-101.365 tagged_above=-999 required=5 tests=[AWL=0.900, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j-GezFHUC8Fy for <vipr@ietfa.amsl.com>; Mon, 2 May 2011 10:22:51 -0700 (PDT)
Received: from server.implementers.org (server.implementers.org [69.55.225.91]) by ietfa.amsl.com (Postfix) with ESMTP id 756DFE073E for <vipr@ietf.org>; Mon, 2 May 2011 10:22:47 -0700 (PDT)
Received: by server.implementers.org (Postfix, from userid 1001) id C8442DBE400C; Mon, 2 May 2011 17:22:46 +0000 (UTC)
Received: from [192.168.2.3] (server.implementers.org [127.0.0.1]) by server.implementers.org (Postfix) with ESMTPA id 78A2FDBE400A for <vipr@ietf.org>; Mon, 2 May 2011 17:22:45 +0000 (UTC)
Message-ID: <4DBEE864.1040002@acm.org>
Date: Mon, 02 May 2011 10:22:44 -0700
From: Marc Petit-Huguenin <petithug@acm.org>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.15) Gecko/20110402 Iceowl/1.0b2 Icedove/3.1.9
MIME-Version: 1.0
To: "vipr@ietf.org" <vipr@ietf.org>
X-Enigmail-Version: 1.1.2
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Subject: [VIPR] Review of draft-jennings-vipr-overview-00
X-BeenThere: vipr@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Verification Involving PSTN Reachability working group <vipr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/vipr>, <mailto:vipr-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/vipr>
List-Post: <mailto:vipr@ietf.org>
List-Help: <mailto:vipr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/vipr>, <mailto:vipr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 02 May 2011 17:22:51 -0000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

(I am co-editor of this draft, but as I am proposing some radical changes, I
thought it was better done in a formal review)

I think that this draft tries to be more than just than just a "Requirements,
Problem statement, and architecture overview" informational document.  More
precisely I think that section 7, 8 and 9 should be moved to a separate document
(with Standard Track status) that would be named something like "Verification
Involving PSTN Reachability (ViPR): Base protocol".

I am also worried that the VAP document (draft-jennings-vipr-vap-00) is
conflating two differents things: 1) the detail of the ViPR server behavior and
2) the VAP protocol itself.  Because it is possible to design an interopeable
ViPR system without VAP (from the outside point of view), I think that the ViPR
behavior part of the VAP draft should be merged with the document I described
above, and keep only the VAP protocol in the VAP document.

If this proposal is accepted, I am willing to prepare such draft (with the same
set of authors).

Now for the review of draft-jennings-vipr-overview-00:

- - The Intended Status in page 1 should be changed to "Informational".

- - Section 6.1, second paragraph "The Internet firewall will require two
pinholes, one for the P2P protocol, and one for the validation protocol"

Unless the idea was to use a dialect of RELOAD non-compliant with
draft-ietf-p2psip-base, a pinhole for the P2P protocol (RELOAD) is needed only
if the node in the ViPR server is a bootstrap peer.  If a ViPR server decides to
not be a bootstrap node, then it will establish the initial connection with a
bootstrap peer then can use ICE transports to connect to attach to other nodes.

Same thing for the validation protocol.  An AppAttach will be used to connect to
the peer declared in the ring, and ICE will take care of opening a pinhole in
the firewall.

Which brings a new question  Who will manage the bootstrap, configuration and
enrollment servers for ViPR?


Nits
- ----

- - first page, first line:

s/vipr/VIPR/

- - Section 4, Req-10:

s/This mechanism/These mechanisms/

- - Section 6, first paragraph

s/call agent can/call agent to/

- - Section 6.1, 4th bullet

s/restore/re-store/

- - Section 6.4

s/enrollment are/enrollment is/

- -- 
Marc Petit-Huguenin
Personal email: marc@petit-huguenin.org
Professional email: petithug@acm.org
Blog: http://blog.marc.petit-huguenin.org
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iEYEARECAAYFAk2+6GIACgkQ9RoMZyVa61eGiwCeOxMjMZZDGLB0u+gZMDOE7zuO
e8wAn2Dqx9F5RAexFC6sLJKY2pma8Eed
=Ntsp
-----END PGP SIGNATURE-----