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

Alexey Melnikov <aamelnikov@fastmail.fm> Wed, 20 April 2016 07:08 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 55B3B12E73B for <p2psip@ietfa.amsl.com>; Wed, 20 Apr 2016 00:08:00 -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=qEkwxism; dkim=pass (1024-bit key) header.d=messagingengine.com header.b=hEOSFUqA
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 If7D9v_UztKM for <p2psip@ietfa.amsl.com>; Wed, 20 Apr 2016 00:07:58 -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 DEBE712DF30 for <p2psip@ietf.org>; Wed, 20 Apr 2016 00:07:57 -0700 (PDT)
Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 3725F20C8B for <p2psip@ietf.org>; Wed, 20 Apr 2016 03:07:57 -0400 (EDT)
Received: from frontend1 ([10.202.2.160]) by compute3.internal (MEProxy); Wed, 20 Apr 2016 03:07:57 -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=vP2om2zbcFWhzGpOUkKB001aFfU=; b=qEkwxi smZ3NpUUsZz2OQ6pIH/shUuwuCWeXxyfJklHwhAOstS3tG71rl8cpjw5FzzBD3T1 uHu2sjhwb7tAFKa6T1qczD8b30v5q26T71a/3iW9C7w41fXfHN6ZlZosnuDcwKMq jQJtReRcu1XahKI+Q+aCKnUqFqlhJO1vQi4QE=
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=vP2om2zbcFWhzGp OUkKB001aFfU=; b=hEOSFUqAydXYwW6QHsv5UDYRw3ck3K+FYcYkvjaZ2q97F64 DawNnVXEzzllh2Y2XdFn+jD2NPUKzlJfv1dxP3jwNrK+Df76M+Kl8MOHllujePov OrWlcqY6scEqWb6he52z1mA/dOfWPOFMDlsO2zjmY1QTxVcQE0ysyb/Gu+eU=
X-Sasl-enc: YC+nQulDY4Bh2xlXcHjP5tjUzBEsxPVdo7/1v3Hl6aZw 1461136076
Received: from [10.0.151.254] (unknown [85.255.232.7]) by mail.messagingengine.com (Postfix) with ESMTPA id 94FB1C0001A; Wed, 20 Apr 2016 03:07:56 -0400 (EDT)
Content-Type: text/plain; charset=windows-1251
Mime-Version: 1.0 (1.0)
From: Alexey Melnikov <aamelnikov@fastmail.fm>
X-Mailer: iPhone Mail (13E238)
In-Reply-To: <571668CD.2090704@haw-hamburg.de>
Date: Wed, 20 Apr 2016 08:12:18 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <C1808D36-A1D9-4909-904E-82CCBB41C1E9@fastmail.fm>
References: <2995d676192d4d1ca3a22232ec6995cd@HUB02.mailcluster.haw-hamburg.de> <5713FB2D.2020405@haw-hamburg.de> <03ce1ff85a2d46fa8c19c1bc6abbae85@HUB02.mailcluster.haw-hamburg.de> <571668CD.2090704@haw-hamburg.de>
To: "Thomas C. Schmidt" <t.schmidt@haw-hamburg.de>
Archived-At: <http://mailarchive.ietf.org/arch/msg/p2psip/Rf7FIlA1Q0XStqrGX5UaMgO9VGQ>
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: Wed, 20 Apr 2016 07:08:00 -0000

Hi Thomas,

> On 19 Apr 2016, at 18:20, Thomas C. Schmidt <t.schmidt@haw-hamburg.de>; wrote:
> 
> Hi Alexey,
> 
> please see the two open answers inline.
> 
>> On 18.04.2016 09:37, Alexey Melnikov wrote:
>> 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.
> 
> O.K. - we added.

Thank you.

>>> 
>>>> 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?
> 
> Actually, in the terminology section is an explicit mentioning of the AOR from RFC 3261 and how to use it here. From my understanding, any additional marking might rather generate confusion than clarity - in particular since an understanding of SIP terminology is rather natural in the context of this document ("SIP Usage").
> 
> Do you agree?

Works for me.

> Best,
> Thomas
> 
>>> 
>>>> 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!
> 
> -- 
> 
> Prof. Dr. Thomas C. Schmidt
> ° Hamburg University of Applied Sciences                   Berliner Tor 7 °
> ° Dept. Informatik, Internet Technologies Group    20099 Hamburg, Germany °
> ° http://www.haw-hamburg.de/inet                   Fon: +49-40-42875-8452 °
> ° http://www.informatik.haw-hamburg.de/~schmidt    Fax: +49-40-42875-8409 °