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

Alissa Cooper <> Wed, 11 June 2014 23:26 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 2967E1B28DB for <>; Wed, 11 Jun 2014 16:26:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.399
X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_8BIT_HEADER=0.3, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id PkzmMpkiFbpn for <>; Wed, 11 Jun 2014 16:26:38 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 03E9C1B28CC for <>; Wed, 11 Jun 2014 16:26:37 -0700 (PDT)
Received: from compute1.internal (compute1.nyi.mail.srv.osa []) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id AC2942125C for <>; Wed, 11 Jun 2014 19:26:36 -0400 (EDT)
Received: from frontend1 ([]) by compute1.internal (MEProxy); Wed, 11 Jun 2014 19:26:36 -0400
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed;; h=date :subject:from:to:cc:message-id:references:in-reply-to :mime-version:content-type:content-transfer-encoding; s=mesmtp; bh=qMAGpillhT8pQQ1HN6EYSHRNt7w=; b=1z7Y6CVGJvrP7Rdx0iDAGe4secFh 8Xj2SWEqBZF7pw/35xSmeYuVpeLKKgYcqMtERUcH5hUxUM6kF8+YKx8o219vhSuV 0J1t2AThw+XSK7e3XJQCZw3kJOr1K/9XjnWEGzZ0a0z8PkK8cfrR+Udo639STO3F /IxYX1NDe6e4SFc=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=; h=date:subject:from:to:cc:message-id :references:in-reply-to:mime-version:content-type :content-transfer-encoding; s=smtpout; bh=qMAGpillhT8pQQ1HN6EYSH RNt7w=; b=AjdFIl7Ns4KUgeHEDUhIFedBnHqDkpRwp8C/iAEwyudHiwomp9G8tn +Frm1tJDHlc/NLCDlnBoImoW4zlyuebbE/rqdnFIBrfkjju7XvuuPWxI6EGUJAp+ njbMIKYEoeSez0C8aKnZKEphAEo3/NvqDEG/8myqLKL21s4fRTi1k=
X-Sasl-enc: jaGg82OOTk60W0JDI/Aa6ddARZOmoTGjQUO0ntJwXuRy 1402529196
Received: from [] (unknown []) by (Postfix) with ESMTPA id 28F51C0000C; Wed, 11 Jun 2014 19:26:34 -0400 (EDT)
User-Agent: Microsoft-MacOutlook/
Date: Wed, 11 Jun 2014 16:26:35 -0700
From: Alissa Cooper <>
To: Jouni =?UTF-8?B?TcOkZW5ww6TDpA==?= <>, "" <>
Message-ID: <>
Thread-Topic: AD evaluation: draft-ietf-p2psip-service-discovery-11
References: <> <>
In-Reply-To: <>
Mime-version: 1.0
Content-type: text/plain; charset="UTF-8"
Content-transfer-encoding: quoted-printable
Cc: "" <>
Subject: Re: [P2PSIP] AD evaluation: draft-ietf-p2psip-service-discovery-11
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Peer-to-Peer SIP working group discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 11 Jun 2014 23:26:40 -0000

Hi Jouni,

On 6/8/14, 2:14 AM, "Jouni Mäenpää" <>; wrote:

>Thanks for the comments! They have been addressed in the new -12 revision
>of the draft.
>> Given that the base RELOAD spec already defines a discovery mechanism
>> TURN, I was surprised to see TURN as the only service registered in the
>> namespaces registry. What was the rationale for that decision?
>The service discovery mechanism in the base RELOAD spec is specific to
>TURN. The reason why we started writing this draft was that there was
>interest from the working group in having also a more generic service
>discovery mechanism for RELOAD that could be used also for other use
>cases than TURN server discovery. Use cases that were discussed at that
>point included among others voice mail and gateway discovery. Should we
>add these services to the namespaces registry? ReDiR can also be used as
>alternative to the TURN server discovery mechanism specified in RELOAD

I don’t have a strong opinion on whether the other services should be
added. If people are interested in using them, then they should be added.
Are people interested? If not, there should be an explanation in the
document that TURN is the only current use case of interest and that ReDir
is an alternative to the already-specified TURN discovery mechanism.


>-----Original Message-----
>From: Alissa Cooper []
>Sent: 30. toukokuuta 2014 23:50
>Subject: AD evaluation: draft-ietf-p2psip-service-discovery-11
>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/