[Gen-art] Gen-ART review of draft-drage-sipping-rfc3455bis-13
Martin Thomson <martin.thomson@gmail.com> Fri, 28 February 2014 00:43 UTC
Return-Path: <martin.thomson@gmail.com>
X-Original-To: gen-art@ietfa.amsl.com
Delivered-To: gen-art@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC3B31A0186 for <gen-art@ietfa.amsl.com>; Thu, 27 Feb 2014 16:43:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.6
X-Spam-Level:
X-Spam-Status: No, score=-0.6 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
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 GBEmEj2wi5OM for <gen-art@ietfa.amsl.com>; Thu, 27 Feb 2014 16:43:26 -0800 (PST)
Received: from mail-we0-x22e.google.com (mail-we0-x22e.google.com [IPv6:2a00:1450:400c:c03::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 920031A022C for <gen-art@ietf.org>; Thu, 27 Feb 2014 16:43:26 -0800 (PST)
Received: by mail-we0-f174.google.com with SMTP id t60so7361wes.5 for <gen-art@ietf.org>; Thu, 27 Feb 2014 16:43:24 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=qliqqURKydUFEPqkZLa/pp9lOdPfeqQYRze8NQX1xUE=; b=edMT4XP8DaPTNGkTwjcWaz2wiFUFOmMTYTabwF29c26B1IcLz8SFXTm8i+ivc9BVO9 YlTFSkiVa+9tpwvCzlmXlGCbTuwUrlF03fIui7vKjHgxAuq4XXuPCy7vStMD15dxJlBE lwLNsTJyqgMAdGuTy9AM9JrlDhGdmFuRrwpSZh1zpEpPo+HJhJQKc2szTtY1Q2vobsqv hnhI3xxn7MwhH32de5/8pCVkSNK1JFGuByiodEnF5d6zeKVnLIaXEf2F++kY6aGOv9Vs D1zOqXwpokNEMEfbTz/07LI5xPklMbPbLkESoLFOLM23eUPtUOm0+vdnkziv6wJ4Zl2i PINw==
MIME-Version: 1.0
X-Received: by 10.194.110.41 with SMTP id hx9mr16480wjb.28.1393548204478; Thu, 27 Feb 2014 16:43:24 -0800 (PST)
Received: by 10.227.10.196 with HTTP; Thu, 27 Feb 2014 16:43:24 -0800 (PST)
Date: Thu, 27 Feb 2014 16:43:24 -0800
Message-ID: <CABkgnnVVQCAz=ixeR04rc75Vc-rL2JFQcjT0-hX_UCL-c=FGjQ@mail.gmail.com>
From: Martin Thomson <martin.thomson@gmail.com>
To: "gen-art@ietf.org" <gen-art@ietf.org>, draft-drage-sipping-rfc3455bis.all@tools.ietf.org
Content-Type: text/plain; charset="UTF-8"
Archived-At: http://mailarchive.ietf.org/arch/msg/gen-art/OUbbpVn13uQ8a5JhfqbJnmkg1JM
Subject: [Gen-art] Gen-ART review of draft-drage-sipping-rfc3455bis-13
X-BeenThere: gen-art@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <gen-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/gen-art>, <mailto:gen-art-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/gen-art/>
List-Post: <mailto:gen-art@ietf.org>
List-Help: <mailto:gen-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 28 Feb 2014 00:43:29 -0000
I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>. Please resolve these comments along with any other Last Call comments you may receive. Document: draft-drage-sipping-rfc3455bis-13 Reviewer: Martin Thomson Review Date: 2014-02-27 IETF LC End Date: 2014-03-14 IESG Telechat date: (if known) Summary: I find it strange that this 3GPP document is being published on the standards track. But since it's a -bis there is clearly precedent, and it is otherwise sound. Major issues: This document doesn't include enough information for me to some of the headers. For example, there isn't enough information in the document to allow me to interpret the contents of cgi-3gpp: cgi-3gpp = "cgi-3gpp" EQUAL (token / quoted-string) (I pick on P-Access-Network-Info, because I'm somewhat familiar with it.) This can probably be addressed by the inclusion of appropriate normative references. I seem to recall there being a 3GPP TS that covered at least some of these. Minor issues: RFC 4244 is now obsolete, see 7044. (related nit: Change log entry #2 seems quite defensive, unnecessarily so. This document only needs to define P-Called-Party-ID, and reference History-Info as an alternative mechanism.) Change log entry #5, mentions a shortcoming of 3455 (no registry for access network types), but the draft does nothing about it. It seems to be propagating the mistake it notes. A lot has happened since RFC 3455 was published. The privacy considerations around the use of P-Access-Network-Info are unchanged from their pre-Geopriv form. In particular, I find the UA knowledge part to be problematic; Geopriv definitions can probably help here. S6.1 P-Associated-URI is a powerful linkability vector, which could be a far more serious privacy leak than the text implies. The following seems like good advice, but is not sufficient: An eavesdropper could possibly collect the list of identities a user is registered. This can have privacy implications. To mitigate this problem, this extension SHOULD only be used in a secured environment, where encryption of SIP messages is provided either end-to-end or hop-by-hop. You also have to trust the other end of the hop with the information. I think that's implicit, but probably needs to be stated. S6.4 This claim sounds false to me: However, there are no security problems resulting from a UA inserting incorrect information. Networks providing services based on the information carried in the P-Access-Network-Info header field will therefore need to trust the UA sending the information. A rogue UA sending false access network information will do no more harm than to restrict the user from using certain services. Any parameter whereby changing it can cause loss of service is likely to be true in the inverse. The draft makes no claims that would make me believe otherwise. Nits/editorial comments: S1 Having the disclaimer as the first section is a little strange. I don't know what it is disclaiming yet. S1, S3 It looks like a few characters are missing from these sections: "trust.These", "environment The", "[RFC3455] This" The change log contains a lot of normative language. I expected to see pointers to changes, and maybe some justification, but items include normative-sounding text and no pointers(7), other contain pointers and duplicate text (3&4) Change log #6 notes the removal of a field; given that this is extensible, why not just mark the CDMA 2000 item deprecated instead of removing it?
- [Gen-art] Gen-ART review of draft-drage-sipping-r… Martin Thomson
- Re: [Gen-art] Gen-ART review of draft-drage-sippi… Jari Arkko
- Re: [Gen-art] Gen-ART review of draft-drage-sippi… Martin Thomson
- Re: [Gen-art] Gen-ART review of draft-drage-sippi… R.Jesske
- Re: [Gen-art] Gen-ART review of draft-drage-sippi… Atle Monrad
- Re: [Gen-art] Gen-ART review of draft-drage-sippi… Gonzalo Camarillo
- Re: [Gen-art] Gen-ART review of draft-drage-sippi… Jari Arkko
- Re: [Gen-art] Gen-ART review of draft-drage-sippi… Martin Thomson
- Re: [Gen-art] Gen-ART review of draft-drage-sippi… R.Jesske
- Re: [Gen-art] Gen-ART review of draft-drage-sippi… Jari Arkko