[P2PSIP] Alexey Melnikov's Discuss on draft-ietf-p2psip-sip-18: (with DISCUSS and COMMENT)
"Alexey Melnikov" <aamelnikov@fastmail.fm> Fri, 08 April 2016 18: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 8863F12D586; Fri, 8 Apr 2016 11:29:52 -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: <20160408182952.23007.88985.idtracker@ietfa.amsl.com>
Date: Fri, 08 Apr 2016 11:29:52 -0700
Archived-At: <http://mailarchive.ietf.org/arch/msg/p2psip/QXUN25GxCzBr-HkuUtdi9B_5IkA>
X-Mailman-Approved-At: Sat, 16 Apr 2016 10:15:22 -0700
Cc: p2psip-chairs@ietf.org, draft-ietf-p2psip-sip@ietf.org, p2psip@ietf.org
Subject: [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
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: Fri, 08 Apr 2016 18:29:52 -0000
Alexey Melnikov has entered the following ballot position for draft-ietf-p2psip-sip-18: Discuss 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: https://datatracker.ietf.org/doc/draft-ietf-p2psip-sip/ ---------------------------------------------------------------------- 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. Also, the first reference to rfc822Name (earlier in the document) needs a normative reference to RFC 5280. ---------------------------------------------------------------------- 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". What does "opaque string" means here? You still need to define syntax of the field. 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. 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? 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?
- [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