Re: [P2PSIP] Alexey Melnikov's Discuss on draft-ietf-p2psip-sip-18: (with DISCUSS and COMMENT)

Alexey Melnikov <aamelnikov@fastmail.fm> Mon, 18 April 2016 07:33 UTC

Return-Path: <aamelnikov@fastmail.fm>
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 3E48912DE55 for <p2psip@ietfa.amsl.com>; Mon, 18 Apr 2016 00:33:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.72
X-Spam-Level:
X-Spam-Status: No, score=-2.72 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fastmail.fm header.b=FxowTKBy; dkim=pass (1024-bit key) header.d=messagingengine.com header.b=UTZDDsrz
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6kKyVlo9L0uS for <p2psip@ietfa.amsl.com>; Mon, 18 Apr 2016 00:33:41 -0700 (PDT)
Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 62FDD12DE5F for <p2psip@ietf.org>; Mon, 18 Apr 2016 00:33:41 -0700 (PDT)
Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id CC69420724 for <p2psip@ietf.org>; Mon, 18 Apr 2016 03:33:40 -0400 (EDT)
Received: from frontend1 ([10.202.2.160]) by compute6.internal (MEProxy); Mon, 18 Apr 2016 03:33:40 -0400
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=fastmail.fm; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-sasl-enc :x-sasl-enc; s=mesmtp; bh=OZsaCGmpTwcBQ4hQ6gFqz7fsQSY=; b=FxowTK BybqZgZf62bwALyOT1KQ2Ac1C6aXgVfgxiJa+rMbXJdu/+3mmLiJkOtNuAIs9yX7 urvBcCNHRQoFknZKSjQrYhsO6WnO1vP4wEVSzFQgW7SbixDC/7Dqoi0b/alGax9h P5rMautNN55XTITPcnvsAlVeepabDc1sSGtsA=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-sasl-enc:x-sasl-enc; s=smtpout; bh=OZsaCGmpTwcBQ4h Q6gFqz7fsQSY=; b=UTZDDsrzm68o/JlYcYLSt/uzcWKrLdGEeiUPbdDqKgPC/YK UEg7aPPjmRqrG2Yiw1EicxLexZbYRWJpEVtK0Uhy2T/0L3Mi3mdQIKTh7dNcGyjW m4Jj5d+eIp/QWVK5QCUIK1JY+4NlwOoeNCccpc2RBZgnGK9w+jRwAf1sjb14=
X-Sasl-enc: 5Fsr6TTYKOQV46YcT0UetZym6N3voUY1nsKjKk1mT0Fs 1460964820
Received: from [10.0.151.254] (unknown [212.183.128.129]) by mail.messagingengine.com (Postfix) with ESMTPA id 518A5C00018; Mon, 18 Apr 2016 03:33:40 -0400 (EDT)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (1.0)
From: Alexey Melnikov <aamelnikov@fastmail.fm>
X-Mailer: iPhone Mail (13E238)
In-Reply-To: <5713FB2D.2020405@haw-hamburg.de>
Date: Mon, 18 Apr 2016 08:37:54 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <6078AE17-8D6E-4F51-B6FC-BDFA4F0A512A@fastmail.fm>
References: <2995d676192d4d1ca3a22232ec6995cd@HUB02.mailcluster.haw-hamburg.de> <5713FB2D.2020405@haw-hamburg.de>
To: "Thomas C. Schmidt" <t.schmidt@haw-hamburg.de>
Archived-At: <http://mailarchive.ietf.org/arch/msg/p2psip/t7VG6Eyj_lkx9dofzzPCFVtD9z8>
Cc: "p2psip-chairs@ietf.org" <p2psip-chairs@ietf.org>, "draft-ietf-p2psip-sip@ietf.org" <draft-ietf-p2psip-sip@ietf.org>, The IESG <iesg@ietf.org>, "p2psip@ietf.org" <p2psip@ietf.org>
Subject: Re: [P2PSIP] Alexey Melnikov's Discuss on draft-ietf-p2psip-sip-18: (with DISCUSS and COMMENT)
X-BeenThere: p2psip@ietf.org
X-Mailman-Version: 2.1.17
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: <https://mailarchive.ietf.org/arch/browse/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, 18 Apr 2016 07:33:43 -0000

Hi Thomas,

> On 17 Apr 2016, at 22:07, Thomas C. Schmidt <t.schmidt@haw-hamburg.de> wrote:
> 
> Hi Alexey,
> 
> many thanks for your careful review. Please see inline:
> 
>> 
>> ----------------------------------------------------------------------
>> DISCUSS:
>> ----------------------------------------------------------------------
>> 
>> I will move to No Objection once my comments are discussed. They should
>> be easy to address.
>> 
>> In Section 7:
>> 
>>      Access Control  USER-NODE-MATCH.  Note that this matches the SIP
>> AOR
>>       against the rfc822Name in the X509v3 certificate.  The rfc822Name
>>       does not include the scheme so that the "sip:" prefix needs to be
>>       removed from the SIP AOR before matching.
>> 
>> In general the advice of stripping "sip:" is misleading, because URIs
>> might have %-encoding, which is not present in rfc822Name, which is an
>> email address. I think adding text that %-encoding should be decoded
>> would be a good idea.
> 
> Thanks for pointing at this: We added
> 
>  "Escaped characters ('%' encoding) in the SIP AOR also need to be decoded prior to matching."

Adding a reference to RFC 3986 would be good here.
> 
>> Also, the first reference to rfc822Name (earlier in the document) needs a
>> normative reference to RFC 5280.
> 
> We added the ref. in Section 2.
> 
>> 
>> ----------------------------------------------------------------------
>> COMMENT:
>> ----------------------------------------------------------------------
>> 
>> In 3.2:
>> 
>>       If the registration is of type "sip_registration_uri", then the
>>       contents are an opaque string containing the AOR as specified in
>>       Section 2.
>> 
>> Is the reference correct? Section 2 is "Terminology".
> 
> Nope, this is a historic editing mistake -> removed.
> 
>> What does "opaque string" means here? You still need to define syntax of
>> the field.
> 
> "opaque string" is the appropriate (single valued) data type of RELOAD (see https://tools.ietf.org/html/rfc6940#section-7.2). Further specifications are given as "the AOR".

Ok. Maybe put in quotes or point this out in the terminology section?
> 
>> In 3.3:
>> 
>>    Before a Store is permitted, the storing peer MUST check that:
>> 
>>    o  The AOR of the request is a valid Resource Name with respect to
>>       the namespaces defined in the overlay configuration document.
>> 
>>    o  The certificate contains a username that is a SIP AOR which hashes
>>       to the Resource-ID it is being stored at.
>> 
>>    o  The certificate contains a Node-ID that is the same as the
>>       dictionary key it is being stored at.
>> 
>> Is there a document that defines how exactly a username and a Node-ID can
>> be represented in an X.509 certificate? If yes, adding a normative
>> reference here would be useful. If not, adding specific details here
>> would be useful.
> 
> Username is a SIP AOR as specified in RFC 3261 (this is normatively referenced in Section 2). A Node-ID is an Overlay Hash, which is defined in RFC 6940 (also normatively referenced in Section 2).

Ok.
> 
>> On page 10:
>> 
>>    Inclusion of a <domain-restrictions> element in an overlay
>>    configuration document is OPTIONAL.  If the element is not included,
>>    the default behavior is to accept any AOR.  If the element is
>>    included and the "enable" attribute is not set or set to false, the
>>    overlay MUST only accept AORs that match the domain name of the
>>    overlay.
>> 
>> What happens if "enable" is false/unspecified and patter subelements are
>> included? Are they ignored?
> 
> According to the writing, this means that
> 
> " the
>   overlay MUST only accept AORs that match the domain name of the
>   overlay."
> 
> The case you are describing is an inconsistently extended overlay configuration document. Hence, this spec tells to ignore inconsistent extensions (isolated pattern subelements), which I believe makes sense. Any counter-arguments?

No, this sounds entirely sensible.
> 
>>    The <domain-restrictions> element serves as a container for zero to
>>    multiple <pattern> sub-elements.  A <pattern> element MAY be present
>>    if the "enable" attribute of its parent element is set to true.  Each
>>    <pattern> element defines a pattern for constructing admissible
>>    resource names.  It is of type xsd:string and interpreted as a
>>    regular expression according to "POSIX Extended Regular Expression"
>>    (see the specifications in [IEEE-Posix]).
>> 
>> This repeats part of the second paragraph of the same section. Is this
>> repetition needed?
> 
> Oopsi - no. This is an editing mistake, most likely from copying a block while revising text. It is removed now.
> 
> Thanks again for finding these lapses!
> 
> We revise and submit.

Thank you!