[P2PSIP] AD evaluation: draft-ietf-p2psip-service-discovery-11

Alissa Cooper <alissa@cooperw.in> Fri, 30 May 2014 20:50 UTC

Return-Path: <alissa@cooperw.in>
X-Original-To: p2psip@ietfa.amsl.com
Delivered-To: p2psip@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com []) by ietfa.amsl.com (Postfix) with ESMTP id D60D91A883A for <p2psip@ietfa.amsl.com>; Fri, 30 May 2014 13:50:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id tIC2fNGlDQFn for <p2psip@ietfa.amsl.com>; Fri, 30 May 2014 13:50:41 -0700 (PDT)
Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F23221A8838 for <p2psip@ietf.org>; Fri, 30 May 2014 13:50:40 -0700 (PDT)
Received: from compute6.internal (compute6.nyi.mail.srv.osa []) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id 9CF0D20DDE; Fri, 30 May 2014 16:50:35 -0400 (EDT)
Received: from frontend2 ([]) by compute6.internal (MEProxy); Fri, 30 May 2014 16:50:35 -0400
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=cooperw.in; h=date :subject:from:to:cc:message-id:mime-version:content-type :content-transfer-encoding; s=mesmtp; bh=UbhWFT71wmBlFv6D3rYKjyc /eQU=; b=4e01IkZ9Me5xza0fqaD1p8eFA1DL0yHUBZtDsmUHK2lzbFIj+Xnf8DV fkgcIDGrqab8ABdBp3E5Om2GgizOvoM3POQX3WGBgZq6bZxrBfCpEeHuH1OKtp04 yM3UYvbe4xAE4R286qN7Yu3xrRUTzVDaR4JWya4Elgh4J2jWUab4=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=date:subject:from:to:cc:message-id :mime-version:content-type:content-transfer-encoding; s=smtpout; bh=UbhWFT71wmBlFv6D3rYKjyc/eQU=; b=QoSQFHghPlRxVcFZpJb1xKB4NSok kjllEGLd8QLgf66yiVke3Dkkz4Vry77mCOue0IsIffYJ2vUlOTL6U1hKroROwqfb LeYBryqGDsmYSqIquOIKVxOZR26kNGliS9QcGhCZIKd66fjtz4O0Io+VZCwbQtxL lMFLn0MwfGPS09U=
X-Sasl-enc: +lPQcT4MEvvTsh6ulWmQe12HPiXvAcpD+wClGfd9gz8a 1401483033
Received: from [] (unknown []) by mail.messagingengine.com (Postfix) with ESMTPA id DB783680117; Fri, 30 May 2014 16:50:32 -0400 (EDT)
User-Agent: Microsoft-MacOutlook/
Date: Fri, 30 May 2014 13:50:28 -0700
From: Alissa Cooper <alissa@cooperw.in>
To: <draft-ietf-p2psip-service-discovery@tools.ietf.org>
Message-ID: <CFAE3D24.3D64D%alissa@cooperw.in>
Thread-Topic: AD evaluation: draft-ietf-p2psip-service-discovery-11
Mime-version: 1.0
Content-type: text/plain; charset="UTF-8"
Content-transfer-encoding: quoted-printable
Archived-At: http://mailarchive.ietf.org/arch/msg/p2psip/yTU4aA4iYzg6SlacvbEND6sCQo8
Cc: p2psip@ietf.org
Subject: [P2PSIP] AD evaluation: draft-ietf-p2psip-service-discovery-11
X-BeenThere: p2psip@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
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: Fri, 30 May 2014 20:50:43 -0000

I have reviewed this document in preparation for IETF last call. It’s in
good shape. I have one question before I issue the last call, though.
Given that the base RELOAD spec already defines a discovery mechanism for
TURN, I was surprised to see TURN as the only service registered in the
new namespaces registry. What was the rationale for that decision?

Some nits to be resolved with any last call comments:

Section 2:

Section 4.2:
"It is RECOMMENDED that Lstart is set to 2.”

It would be helpful to add some text here to motivate the decision to use
2 as the recommendation.

Section 4.5
s/note: within the entire tree/note: within the entire tree node/

Section 5:
s/every kind which is storable/every Kind which is storable/

Section 6:
s/REDIR kind/REDIR Kind/

Section 8:
s/"REDIR” kind/"REDIR” Kind/

Section 9:
Seems like this section deserves a mention of the fact that a new access
control policy had to be defined for Redir.

Section 10.4:
s/IANA SHALL create/IANA is requested to create/