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!
- [P2PSIP] Alexey Melnikov's Discuss on draft-ietf-… Alexey Melnikov
- Re: [P2PSIP] Alexey Melnikov's Discuss on draft-i… Thomas C. Schmidt
- Re: [P2PSIP] Alexey Melnikov's Discuss on draft-i… Alexey Melnikov
- Re: [P2PSIP] Alexey Melnikov's Discuss on draft-i… Thomas C. Schmidt
- Re: [P2PSIP] Alexey Melnikov's Discuss on draft-i… Alexey Melnikov