Re: [sipcore] Opsdir last call review of draft-ietf-sipcore-locparam-06
Tim Chown <Tim.Chown@jisc.ac.uk> Mon, 17 February 2020 18:42 UTC
Return-Path: <tim.chown@jisc.ac.uk>
X-Original-To: sipcore@ietfa.amsl.com
Delivered-To: sipcore@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00CE6120863 for <sipcore@ietfa.amsl.com>; Mon, 17 Feb 2020 10:42:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=jisc.ac.uk
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 Fx-4CsXVrh7g for <sipcore@ietfa.amsl.com>; Mon, 17 Feb 2020 10:42:19 -0800 (PST)
Received: from eu-smtp-delivery-189.mimecast.com (eu-smtp-delivery-189.mimecast.com [146.101.78.189]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4D29D12085E for <sipcore@ietf.org>; Mon, 17 Feb 2020 10:42:19 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jisc.ac.uk; s=mimecast20170213; t=1581964936; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=qsGjAlmbyUb0gFUAlPxtYkX9ShZDGURBtoXuwPjrn4I=; b=efBvwT3ppDAs7+q/cqZMl9D42cgo4awkJeMFSRdWcbQ4I5PqEmn9EOH6/U45ESsU3VN8Om /DW7zn1Ax5Nps/N71s/Pte9uW+JUx+ukvdzl/fxO6zN8Jswk66xzZghh2d/0ROHTs0jXxb +FF7P3S6WNpcpNM6NloDlKRqo1qU5Tc=
Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-db5eur01lp2052.outbound.protection.outlook.com [104.47.2.52]) (Using TLS) by relay.mimecast.com with ESMTP id uk-mta-95-Tjjp4eNwO7eTLlawA6cyUw-1; Mon, 17 Feb 2020 18:42:14 +0000
Received: from AM5PR0701MB2849.eurprd07.prod.outlook.com (10.168.153.149) by AM5PR0701MB2691.eurprd07.prod.outlook.com (10.173.93.17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2750.12; Mon, 17 Feb 2020 18:42:12 +0000
Received: from AM5PR0701MB2849.eurprd07.prod.outlook.com ([fe80::1446:7407:4077:14a4]) by AM5PR0701MB2849.eurprd07.prod.outlook.com ([fe80::1446:7407:4077:14a4%9]) with mapi id 15.20.2750.016; Mon, 17 Feb 2020 18:42:12 +0000
From: Tim Chown <Tim.Chown@jisc.ac.uk>
To: Brian Rosen <br@brianrosen.net>
CC: "ops-dir@ietf.org" <ops-dir@ietf.org>, "last-call@ietf.org" <last-call@ietf.org>, "sipcore@ietf.org" <sipcore@ietf.org>, "draft-ietf-sipcore-locparam.all@ietf.org" <draft-ietf-sipcore-locparam.all@ietf.org>
Thread-Topic: Opsdir last call review of draft-ietf-sipcore-locparam-06
Thread-Index: AQHV5bLViftUNAo4rUGHpyUE6HuYZKgfuIiA
Date: Mon, 17 Feb 2020 18:42:12 +0000
Message-ID: <FE222FE5-B386-47C4-8573-0B7D231A1D02@jisc.ac.uk>
References: <158195057743.18035.4886589758870412146@ietfa.amsl.com> <B7B6E160-6346-4183-BAE8-8FEFFD62371D@brianrosen.net>
In-Reply-To: <B7B6E160-6346-4183-BAE8-8FEFFD62371D@brianrosen.net>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-mailer: Apple Mail (2.3608.60.0.2.5)
x-originating-ip: [2001:a88:d510:1101:dde7:fff5:1f55:264e]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 464ab358-03d1-4c04-3d8f-08d7b3d919f4
x-ms-traffictypediagnostic: AM5PR0701MB2691:
x-microsoft-antispam-prvs: <AM5PR0701MB26919DC340148C4C089CE61AD6160@AM5PR0701MB2691.eurprd07.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:9508;
x-forefront-prvs: 0316567485
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(366004)(396003)(136003)(376002)(346002)(39850400004)(199004)(189003)(8676002)(6486002)(71200400001)(81166006)(66476007)(76116006)(66946007)(81156014)(54906003)(2616005)(91956017)(186003)(66446008)(66556008)(64756008)(2906002)(786003)(6506007)(53546011)(6512007)(33656002)(36756003)(316002)(86362001)(8936002)(478600001)(5660300002)(4326008)(6916009); DIR:OUT; SFP:1101; SCL:1; SRVR:AM5PR0701MB2691; H:AM5PR0701MB2849.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: 6tHGV4jMgwcMRpJfr+OZ2zwSQ4Fu9t1ZOcdvit7WXdaVLL5+q7s89/l4zC6fgRJUAjSV0EO+Ub5GnLgwhltG/rcOqe1EERwAKellLlXIweo4f/rZAMGrVCOjuUHxYEDXZVMhWM98psrHIPJXHPQKJaO5syqrXz2Da88lXRtKKVsoOiFOB9C71P5F5IQZPnAyuwoPaL8AGIl0mgpurNZkIrZxTDPChH7oEJsEX3y0KsdPl0S3U+gLRwpfZEwcs2Qkq+d6AZ18SVf0fgsKKexkZJqUHDIgty5xO6PPz0XJ4Bq++ZsdVjRvC1i/8LfMF9fPy1wJZefOa8YuefUq8ipwDIgyO993gN0jYOtUWByI7AFpAlk9UIbUqjh6AGulwKITHg7w84MO4DXLjKqHq+wQnnV9RHTLGaHiNLasjWXOVEFsThfNcKD1aCp54IuOoOgW
x-ms-exchange-antispam-messagedata: okdw95rdQUOoXGP9F2wJKrORn5Gx4FmRE6p+GlqSG0LEt4wwtzaSPEHmyh7ytI1/QRsHVAu2YYycEyZkiVlussI9UsahzP0acI95XpOoJScQzIy2tWymRvrnwUQSOQj0xIoRVkGtAkGZ9bKKxKdIZlaMKz2xlFga/GV3NV3zfpPRs5VfiCQgv18VW2LBw50SieALYDZBiNuiUFvMxljd9w==
x-ms-exchange-transport-forked: True
MIME-Version: 1.0
X-OriginatorOrg: jisc.ac.uk
X-MS-Exchange-CrossTenant-Network-Message-Id: 464ab358-03d1-4c04-3d8f-08d7b3d919f4
X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Feb 2020 18:42:12.0536 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 48f9394d-8a14-4d27-82a6-f35f12361205
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: zCGGJ0eAK+2CdCuvJQsoYR7pC4WOLdCFeTCcapTuNsCLrg2pDFnI7+LElML2g9EiVldVJ2nFk9J+S/T9MKagGA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM5PR0701MB2691
X-MC-Unique: Tjjp4eNwO7eTLlawA6cyUw-1
X-Mimecast-Spam-Score: 0
X-Mimecast-Originator: jisc.ac.uk
Content-Type: multipart/alternative; boundary="_000_FE222FE5B38647C485730B7D231A1D02jiscacuk_"
Archived-At: <https://mailarchive.ietf.org/arch/msg/sipcore/tFUUfi-ln_iYkrblFy25InOef0Q>
Subject: Re: [sipcore] Opsdir last call review of draft-ietf-sipcore-locparam-06
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: SIP Core Working Group <sipcore.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sipcore>, <mailto:sipcore-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sipcore/>
List-Post: <mailto:sipcore@ietf.org>
List-Help: <mailto:sipcore-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sipcore>, <mailto:sipcore-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 17 Feb 2020 18:42:24 -0000
Hi, Apologies, it was still in my review queue from the end of January. Having a quieter week this week I reviewed it today, but didn’t realise it had been approved for publication. I stand by the review, so I guess it can be published as is or it can be recalled by the AD and the comments addressed. I do find it a clumsy document to read, and there are some gaps / inconsistencies. Tim On 17 Feb 2020, at 16:53, Brian Rosen <br@brianrosen.net<mailto:br@brianrosen.net>> wrote: What happened here? This document has just been approved for publication. Brian On Feb 17, 2020, at 9:42 AM, Tim Chown via Datatracker <noreply@ietf.org<mailto:noreply@ietf.org>> wrote: Reviewer: Tim Chown Review result: Has Issues Hi, I have reviewed this document as part of the Operational directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written with the intent of improving the operational aspects of the IETF drafts. Comments that are not addressed in last call may be included in AD reviews during the IESG review. Document editors and WG chairs should treat these comments just like any other last call comments. The draft describes an extension to RFC6442 to support the inclusion of a “loc-src” parameter to the SIP Geolocation field such that when multiple locationValues are present the recipient can make a better informed decision about which locationValue it wishes to use. For the context of my comments, I am not that familiar with SIP-related protocols. The rationale for the addition of this parameter appears sound, and its definition seems appropriate. However, the document is written in such a way that the rationale is split over two sections, and the mechanism for including the parameter is split across three sections, leaving the document a little clumsy for readers to follow. Overall, the document is one that should ultimately be published, but as is it has issues, and in my view needs some restructuring to make it more concise and simpler to follow, so is not (yet) ready for publication. Main comments: The definition of the parameter itself is fine. The first issue is around the rationale. This seems perfectly sound, but the document splits the reasoning between most of the Introduction and the first two paragraphs of Section 3. It would be better to have the rationale in a Rationale section, without repetition. The more confusing issue is the way the mechanism is described over Sections 3 (paragraphs 3,4,5), 4 (paragraph 3) and 7 (all paragraphs). There is repetition, some clashes, and some ambiguity. Rewriting the text to have a single mechanism section would make the text far clearer, in my view. Here is how I would suggest the text is restructured: Introduction Largely paras 1 and 2 of the current intro. Rationale Largely para 3 of the intro, and paras 1 and 2 of the existing Rationale section. Loc-src parameter specification Paras 1-2 of the Mechanism section, with the Figure, and para 6 of the Rationale section. Mechanism A rewrite of paras 3-5 of the current Rationale section, para 3 of the current Mechanism section, and pretty much all of the Security section. Example Can stay as is Privacy Considerations Fine Security Considerations Just one para mentioning the trust issue and the protections defined in the Mechanism section would be fine. Don’t split the guidance as it currently is across three sections - put it all in one pace where - a new Mechanisms section as above - it can be much more easily followed and implemented. Other comments: Section 3 Para 2 says the document makes no comment on the rationale, but the document explains the rationale. Perhaps just delete this. Para 5 talks about another networks with no trust; is the issue messages sent to (as stated) or also received from? I think when you pull all the mechanism text into one place you can make this clearer. Section 4 Para 3 - what is the difference between a UA and UE from the point of view of an end node adding (or not adding) a loc-src parameter? It says a UA MUST NOT add one, but in Section 5 states that a UE might provide it? The last sentence talks of removing loc-src for certain case(s) but this is also included in Sections 3 and 7. It really needs to be stated clearly in one place. Section 5 Para 1 - RFC 4483 or RFC 2392? RFC6442 cites 2392 for cid. Section 7 Para 1 - What is a “location recipient”? A receiver which is inspecting a header with multiple locationValues? Perhaps define this, or rewrite. Paras 2 and 3 - “strongly recommended” should be “RECOMMENDED” ? I think much of this section is repeating what has been said before, e.g. in Section 4 it says “MUST remove” and here it says removing it is (only) strongly recommended. Bets wishes, Tim
- [sipcore] Opsdir last call review of draft-ietf-s… Tim Chown via Datatracker
- Re: [sipcore] Opsdir last call review of draft-ie… Brian Rosen
- Re: [sipcore] Opsdir last call review of draft-ie… Tim Chown