Re: [sipcore] WGLC: draft-ietf-sipcore-locparam - Christer's review

<R.Jesske@telekom.de> Tue, 20 August 2019 14:02 UTC

Return-Path: <R.Jesske@telekom.de>
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 112DF120058 for <sipcore@ietfa.amsl.com>; Tue, 20 Aug 2019 07:02:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.298
X-Spam-Level:
X-Spam-Status: No, score=-4.298 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telekom.de
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 Q_ijGNQAlIty for <sipcore@ietfa.amsl.com>; Tue, 20 Aug 2019 07:02:25 -0700 (PDT)
Received: from mailout21.telekom.de (mailout21.telekom.de [194.25.225.215]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D60E3120044 for <sipcore@ietf.org>; Tue, 20 Aug 2019 07:02:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telekom.de; i=@telekom.de; q=dns/txt; s=dtag1; t=1566309742; x=1597845742; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=Y8pkSiE6Mrt2t5b7ceaZIbC5D4hPOdT+YsS0/ezbUAc=; b=TSHNrQSi1NlROo8qd/gFM5YgtAt+PSmCmtFlc9iwrn+Dlcp9ToBspEnT zak76d1zfpZoIW1j6++yGoszHRn/+JrNWo1u5KESQnqMFTuCDuJdWRxG2 ackIaRyZNCnjxRP3DlCVy7/5D578b0+tdmiyI55wJpAgba/nVZBag4vvD s1XqFXTJ+c0T+0Vi4F0Z9okngRXN/YN+jE1KiO2JumGWiICrfZb4SBJmb qK2K3uvkUwuDkj320GX+kkrspFJNX/q4CGHPxRnYalCzfPxd2H6MOMbPo gTMwAKQTvm5Qo8rGqyRuORGY7PG6hwXLKHU1F0X7UJJZz3Sl+2aQbEgEd Q==;
Received: from qde8e4.de.t-internal.com ([10.171.255.33]) by MAILOUT21.dmznet.de.t-internal.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 20 Aug 2019 16:02:20 +0200
X-IronPort-AV: E=Sophos;i="5.64,408,1559512800"; d="scan'208";a="605003772"
X-MGA-submission: MDEemxI0Qe450gk2Toe9boAPz0Za7egHpoJOH/H7xPYh5jMFFyfJVmqWgDLdBpOTFe0q7sxOlunwJX0W7kRI4hOIJEWCDIga23QGQdydNQ7C3lXk9bUqssTaR5D3LyHnkwWDIBmcS5QiQw9C4+J6YZZ5LbX8cfd8fs1+g2aeTxukjA==
Received: from he199745.emea1.cds.t-internal.com ([10.169.119.53]) by QDE8PP.de.t-internal.com with ESMTP/TLS/AES256-SHA; 20 Aug 2019 16:02:22 +0200
Received: from HE199743.EMEA1.cds.t-internal.com (10.169.119.51) by HE199745.emea1.cds.t-internal.com (10.169.119.53) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Tue, 20 Aug 2019 16:02:22 +0200
Received: from HE100181.emea1.cds.t-internal.com (10.171.40.15) by HE199743.EMEA1.cds.t-internal.com (10.169.119.51) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Tue, 20 Aug 2019 16:02:22 +0200
Received: from GER01-LEJ-obe.outbound.protection.outlook.de (51.5.80.23) by O365mail02.telekom.de (172.30.0.235) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Tue, 20 Aug 2019 16:02:21 +0200
Received: from FRXPR01MB0743.DEUPRD01.PROD.OUTLOOK.DE (10.158.154.143) by FRXPR01MB0886.DEUPRD01.PROD.OUTLOOK.DE (10.158.155.139) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2178.18; Tue, 20 Aug 2019 14:02:21 +0000
Received: from FRXPR01MB0743.DEUPRD01.PROD.OUTLOOK.DE ([fe80::9903:90fe:f1a5:5f07]) by FRXPR01MB0743.DEUPRD01.PROD.OUTLOOK.DE ([fe80::9903:90fe:f1a5:5f07%5]) with mapi id 15.20.2178.018; Tue, 20 Aug 2019 14:02:21 +0000
From: R.Jesske@telekom.de
To: a.james.winterbottom@gmail.com, christer.holmberg@ericsson.com
CC: sipcore@ietf.org
Thread-Topic: [sipcore] WGLC: draft-ietf-sipcore-locparam - Christer's review
Thread-Index: AdVV7vzpPvKQeIXFRQyDyCoSHVjZDQAFGEgAAFR4jpA=
Date: Tue, 20 Aug 2019 14:02:21 +0000
Message-ID: <FRXPR01MB0743760C0F51E7DED1AE56EAF9AB0@FRXPR01MB0743.DEUPRD01.PROD.OUTLOOK.DE>
References: <HE1PR07MB316113983B0E51E6CB0E488193A90@HE1PR07MB3161.eurprd07.prod.outlook.com> <B319C022-97FF-438D-9C66-A21160B63675@gmail.com>
In-Reply-To: <B319C022-97FF-438D-9C66-A21160B63675@gmail.com>
Accept-Language: de-DE, en-US
Content-Language: de-DE
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=R.Jesske@telekom.de;
x-originating-ip: [164.19.3.135]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 7c21348b-f88b-4492-6589-08d7257704f6
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:FRXPR01MB0886;
x-ms-traffictypediagnostic: FRXPR01MB0886:
x-ms-exchange-purlcount: 2
x-microsoft-antispam-prvs: <FRXPR01MB0886126A0A620DCA1F734389F9AB0@FRXPR01MB0886.DEUPRD01.PROD.OUTLOOK.DE>
x-ms-oob-tlc-oobclassifiers: OLM:6790;
x-forefront-prvs: 013568035E
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(136003)(366004)(346002)(396003)(376002)(39860400002)(51914003)(53754006)(199004)(189003)(486006)(66066001)(4326008)(8936002)(446003)(966005)(14454004)(508600001)(6306002)(256004)(305945005)(9686003)(55016002)(2906002)(110136005)(81166006)(81156014)(476003)(11346002)(7696005)(14444005)(8676002)(7736002)(52396003)(53936002)(76176011)(6116002)(3846002)(76116006)(5660300002)(53546011)(71190400001)(33656002)(71200400001)(86362001)(66574012)(66476007)(66556008)(186003)(64756008)(66446008)(26005)(66946007)(102836004); DIR:OUT; SFP:1101; SCL:1; SRVR:FRXPR01MB0886; H:FRXPR01MB0743.DEUPRD01.PROD.OUTLOOK.DE; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
received-spf: None (protection.outlook.com: telekom.de does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: Py8C0wkqk5S0Hh0nXR0Ck/oW2YzCCqAnkoYjQUkFE3RN11KGhiljoirWszKWqfDvlMRFq4NhauSg7Lm+I6MIApo/tsuezVUCChZpp0Vel7RmMqvU+FHfDpW5E4FzDswTnh94r7Hgp7o6ZlbzeANd608eYUoUlC/RJ69RqL+ptEZugk9Kv0prqn1RcwhwWOk/pqhgJ7GPuOvetZ5Ut1skP6guBxeR7nj49A6H7nENUWCy0pZdR+fw23An32rjHqKM7FxCG7Q40w7rQg2MnPfhH33cE1ChkXTBt6T/C4b0BhVXDTVFNz8yZOT3cnuHFvZL+47HQnYKmXVfhbsuV0NP30cDNoDISV5v8WnMEEmbpp5QG/RUwuT7jZA2+duWxyP8CD0QauuwkVHvGRknqlgzS0YLFLlvrplQyL8IEJKWf2M=
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 7c21348b-f88b-4492-6589-08d7257704f6
X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Aug 2019 14:02:21.0457 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bde4dffc-4b60-4cf6-8b04-a5eeb25f5c4f
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: Z5Wn/8TOrYcbaiNGMwRRL/0DyW4PhaxGwEAbREzVWoroLXkfPz9jZWS6OqRE2ejWUvxcjI9FiPtk7LuGri1BgQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: FRXPR01MB0886
X-OriginatorOrg: telekom.de
Archived-At: <https://mailarchive.ietf.org/arch/msg/sipcore/pKB58y0g7E5h3RQ53eH0kJJX9QE>
Subject: Re: [sipcore] WGLC: draft-ietf-sipcore-locparam - Christer's review
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: Tue, 20 Aug 2019 14:02:29 -0000

Hi Christer,
thank you for your review.
I see this also as good changes and have included the proposed changes within the draft.

> Q_GEN_4:
> 
> - While RFC 6442 talks generally about "SIP intermediaries", this draft talks about "proxies". Is there a reason for that?

I have changed proxies/proxy it to SIP intermediaries/ SIP intermediarity depending in the text where the location-source is added. To be more aligned with RFC6442.

For Q_ABS_1 I have added the following text:
This document defines the location-source parameter so that the entity adding the location value to 
    	Geolocation header field can identify itself using its hostname.

After WGLC will provide the next draft with all changes. 

Best Regards

Roland 

-----Ursprüngliche Nachricht-----
Von: sipcore <sipcore-bounces@ietf.org> Im Auftrag von James Winterbottom
Gesendet: Sonntag, 18. August 2019 22:28
An: Christer Holmberg <christer.holmberg@ericsson.com>
Cc: sipcore@ietf.org
Betreff: Re: [sipcore] WGLC: draft-ietf-sipcore-locparam - Christer's review

Thanks Christer, these all look pretty reasonable to me.

Thanks for the review.

James


> On 19 Aug 2019, at 5:23 am, Christer Holmberg <christer.holmberg@ericsson.com> wrote:
> 
> Hi,
> 
> Below is my WGLC review. 
> 
> NUTSHELL:
> 
>> From a technical point of view, the document is ready to move forward. However, there are some editorial issues that I'd like the authors to address.
> 
> ---
> 
> GENERAL:
> 
> Q_GEN_1:
> 
> - Please always use capital 'G' for Geolocation header field.
> 
> Q_GEN_2:
> 
> - Instead of talking about "The parameter defined in this specification", use the name of the parameter.
> 
> Q_GEN_3:
> 
> - In some places the text talks about the loc-src parameter. I think it shall talk about the location-source parameter instead, as that is the name in the ABNF. loc-src is just the encoding.
> 
> Q_GEN_4:
> 
> - While RFC 6442 talks generally about "SIP intermediaries", this draft talks about "proxies". Is there a reason for that?
> 
> ---
> 
> ABSTRACT:
> 
> Q_ABS_1:
> 
> The text gives some background about a problem, but there is no words about what the draft does to address that problem. I think there should be a sentence saying: "This document blah blah blah...".
> 
> ---
> 
> SECTION 1:
> 
> Q_1_1:
> 
> The first sentence says:
> 
>   "The SIP geolocation specification [RFC6442] describes the
>   "Geolocation" SIP header field which is used to indicate that the SIP
>   message is conveying location information.  The specification
>   suggests that only one location value should be conveyed."
> 
> - The Geolocation SIP header field does not only indicate that the SIP message is used to convey location information, it also contains a reference to the location information.
> 
> - Does RFC 6442 really suggest that only one location value should be conveyed? The way I read it is that an intermediary should not add location information to a request that already contains it. Would it be more appropriate to say:
> 
> "The specification specifies that SIP intermediaries should not add location values to a SIP request that already contains location value."
> 
> Q_1_2:
> 
> The text says:
> 
>   "This document adds a location-source (loc-src) parameter to the
>   location values in [RFC6442] so that the entity adding the location
>   value to geolocation header field can identify itself using its
>   hostname."
> 
> - I think you shall be more specific, and say something like:
> 
> "This document extends the Geolocation header field, by allowing an entity adding the location value to identity itself using a hostname. This is done by defining a new geoloc-param header field parameter, location-source."
> 
> ---
> 
> SECTION 3:
> 
> Q_3_1:
> 
> - s/specific/specification
> 
> ---
> 
> SECTION 4:
> 
> Q_4_1:
> 
> The syntax says:
> 
> location-source = "loc-src=" (hostname ) hostname = <defined in 
> RFC3261>
> 
> - I suggest "loc-src" EQUAL (hostname).
> 
> - s/(hostname)/hostname
> 
> 
> A_4_2:
> 
> The text says:
> 
>   "Only a fully qualified host name is valid, an IP address MUST NOT be
>   added by an entity conforming with this specification.  If a node
>   conforming to this specification receives a geolocation header field
>   with a loc-src parameter containing an IP address then the parameter
>   MUST be removed."
> 
> - It is not only about not supporting IP addresses - the syntax does not even allow an IP address. Perhaps something like:
> 
> "Only a fully qualified host name is valid. The syntax does not support IP addresses, and if an entity conforming to this..."
> 
> 
> Q_4_3:
> 
> The text says:
> 
>   "Any proxy adding a location value to a geolocation header field
>   SHOULD also add its host name using the loc-src parameter so that it
>   is clearly identified as the node adding the location."
> 
> - I suggest to say "A proxy conformant to this specification adding a location value..."
> 
> - s/SHOULD also add its host name using the loc-src parameter/SHOULD also add a location-source header field parameter".
> 
> 
> Q_4_4:
> 
> The text says:
> 
> "A UE MUST NOT provide a loc-src parameter value."
> 
> I suggest "A UA MUST NOT insert a location-source header field parameter"
> 
> ---
> 
> SECTION 7:
> 
> Q_7_1:
> 
> The text says: "the that they". I assume that is a mistake.
> 
> Q_7_2:
> 
> The text says:
> 
> "To avoid problems of wrong interpretation of loc-src the value may be discarded when passed to an other domain."
> 
> Is "removed" more appropriate than "discarded"?
> 
> 
> Regards,
> 
> Christer
> 
> 
> 
> 
> 
> -----Alkuperäinen viesti-----
> Lähettäjä: sipcore <sipcore-bounces@ietf.org> Puolesta A. Jean Mahoney
> Lähetetty: sunnuntai 18. elokuuta 2019 20.57
> Vastaanottaja: sipcore@ietf.org
> Aihe: Re: [sipcore] WGLC: draft-ietf-sipcore-locparam
> 
> Hi all,
> 
> The WGLC is being extended to Friday, Sept 13, since many people go on vacation in August and early September.
> 
> Thanks!
> 
> Jean
> 
> 
> 
> On 8/15/19 2:43 PM, A. Jean Mahoney wrote:
>> Hi all,
>> 
>> This begins the Working Group Last Call of 
>> draft-ietf-sipcore-locparam (Location Source Parameter for the SIP Geolocation Header Field).
>> 
>> Please post any feedback to the sipcore mailing list by Friday, August 30.
>> 
>> https://datatracker.ietf.org/doc/draft-ietf-sipcore-locparam/
>> 
>> Thanks!
>> 
>> Jean
>> 
>> _______________________________________________
>> sipcore mailing list
>> sipcore@ietf.org
>> https://www.ietf.org/mailman/listinfo/sipcore
> 
> _______________________________________________
> sipcore mailing list
> sipcore@ietf.org
> https://www.ietf.org/mailman/listinfo/sipcore
> 
> _______________________________________________
> sipcore mailing list
> sipcore@ietf.org
> https://www.ietf.org/mailman/listinfo/sipcore

_______________________________________________
sipcore mailing list
sipcore@ietf.org
https://www.ietf.org/mailman/listinfo/sipcore