[P2PSIP] Alexey Melnikov's No Objection on draft-ietf-p2psip-sip-19: (with COMMENT)

"Alexey Melnikov" <aamelnikov@fastmail.fm> Tue, 19 April 2016 15:29 UTC

Return-Path: <aamelnikov@fastmail.fm>
X-Original-To: p2psip@ietf.org
Delivered-To: p2psip@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 270E112D669; Tue, 19 Apr 2016 08:29:09 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: "Alexey Melnikov" <aamelnikov@fastmail.fm>
To: "The IESG" <iesg@ietf.org>
X-Test-IDTracker: no
X-IETF-IDTracker: 6.19.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20160419152909.31573.30501.idtracker@ietfa.amsl.com>
Date: Tue, 19 Apr 2016 08:29:09 -0700
Archived-At: <http://mailarchive.ietf.org/arch/msg/p2psip/ZuqxkBj-hjMWSgwJw5MXs5HIJok>
Cc: p2psip-chairs@ietf.org, draft-ietf-p2psip-sip@ietf.org, p2psip@ietf.org
Subject: [P2PSIP] Alexey Melnikov's No Objection on draft-ietf-p2psip-sip-19: (with COMMENT)
X-BeenThere: p2psip@ietf.org
X-Mailman-Version: 2.1.17
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: Tue, 19 Apr 2016 15:29:09 -0000

Alexey Melnikov has entered the following ballot position for
draft-ietf-p2psip-sip-19: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:


Mentioning "opaque string" in the terminology section would be good.

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.

In Section 7:

     Access Control  USER-NODE-MATCH.  Note that this matches the SIP
      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. Thank you for adding text that %-encoding should be
decoded, but I also think this should point to RFC 3986.

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

What happens if "enable" is false/unspecified and patter subelements are
included? Are they ignored?