Subject: [sipcore] WG: New Version Notification for draft-winterbottom-sipcore-locparam-02.txt

From: "Jesske, Roland" <[email-masked]>
Date: Tue, 24 Oct 2017 09:25:16 +0000

Dear all,
last week I have updated draft-winterbottom-sipcore-locparam due to the discussions made.
So all comments made are now reflected.
I did some improvement of the text with regard to the use of the locparam within the trusted domain.
This reflects the use to be intended within a trust domain.

Thank you and Best Regards

Roland 

-----Ursprüngliche Nachricht-----
Von: [email-masked] [mailto:[email-masked]] 
Gesendet: Donnerstag, 19. Oktober 2017 05:44
An: Andrew Hutton <[email-masked]>; Jesske, Roland <[email-masked]>; James Winterbottom <[email-masked]>; Bruno Chatras <[email-masked]>
Betreff: New Version Notification for draft-winterbottom-sipcore-locparam-02.txt

A new version of I-D, draft-winterbottom-sipcore-locparam-02.txt
has been successfully submitted by Roland Jesske and posted to the IETF repository.

Name:		draft-winterbottom-sipcore-locparam
Revision:	02
Title:		Location Source Parameter for the SIP Geolocation Header Field
Document date:	2017-10-18
Group:		Individual Submission
Pages:		8
URL:            https://www.ietf.org/internet-drafts/draft-winterbottom-sipcore-locparam-02.txt
Status:         https://datatracker.ietf.org/doc/draft-winterbottom-sipcore-locparam/
Htmlized:       https://tools.ietf.org/html/draft-winterbottom-sipcore-locparam-02
Htmlized:       https://datatracker.ietf.org/doc/html/draft-winterbottom-sipcore-locparam-02
Diff:           https://www.ietf.org/rfcdiff?url2=draft-winterbottom-sipcore-locparam-02

Abstract:
   There are some circumstances where a geolocation header field may
   contain more than one location value.  Knowing the identity of the
   node adding the location value allows the recipient more freedom in
   selecting the value to look at first rather than relying solely on
   the order of the location values.

Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

---

From: <[email-masked]>
Date: Thu, 26 Oct 2017 10:25:10 +0000

What are the next steps to get this document approved as an RFC? Is there anything missing? On the ETSI side we do need to reference this document from an ETSI standard that will be published very soon.
Bruno
-----Message d'origine-----
De : sipcore [mailto:[email-masked]] De la part de Jesske, Roland
Envoyé : mardi 24 octobre 2017 11:25
À : [email-masked]
Objet : [sipcore] WG: New Version Notification for draft-winterbottom-sipcore-locparam-02.txt

Dear all,

Roland 

-----Ursprüngliche Nachricht-----
Von: [email-masked] [mailto:[email-masked]] 
Gesendet: Donnerstag, 19. Oktober 2017 05:44
An: Andrew Hutton <[email-masked]>; Jesske, Roland <[email-masked]>; James Winterbottom <[email-masked]>; Bruno Chatras <[email-masked]>
Betreff: New Version Notification for draft-winterbottom-sipcore-locparam-02.txt

Abstract:

The IETF Secretariat

_______________________________________________
sipcore mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/sipcore

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: Brian Rosen <[email-masked]>
Date: Thu, 26 Oct 2017 09:01:05 -0400

We need reviews: we need people to carefully look at the document and send comments (if they have any).

If the previous commenters signal their concerns are addressed, chairs will issue a working group last call soon, but getting reviews is critical to getting the document approved.

Brian

> On Oct 26, 2017, at 6:25 AM, [email-masked] wrote:
>

---

From: "Olle E. Johansson" <[email-masked]>
Date: Thu, 26 Oct 2017 15:09:07 +0200

Some quick comments to version -02:

in section 4, you refer to “other-loc-src” as a token. That’s not clearly specified. WIll there be a registry for “tokens”?
I am afraid that this is an opening for private tokens that hinders interoperability.

In “Privacy considerations” - should you not discuss what happens with my privacy if an entity in the network,
but not my phone, adds a location?

In “security considerations” there’s a discussion about a “trusted network” - but that is not defined. What is
a trusted network? There’s no mention on how to apply trust, privacy, confidentiality.

There is a typo as well: "when passed to an other domain.”  
s/an other/another/

Cheers,
/O

---

From: "Olle E. Johansson" <[email-masked]>
Date: Thu, 26 Oct 2017 15:14:02 +0200

Went back to the RFC you are updating. The security considerations there are very much out of date with
current IETF practise in my opinion. If you update 6442, the security section would benefit from an update.

Referring to S/MIME (not really implemented much) and SIPS: (which is totally out-of-date) is not acceptable
any more. 

/O

> On 26 Oct 2017, at 15:09, Olle E. Johansson <[email-masked]> wrote:
>

---

From: Brian Rosen <[email-masked]>
Date: Thu, 26 Oct 2017 09:47:38 -0400

Thanks for noticing this.  Any way we could convince you to draft a paragraph that could be included with this document that will do that update to security for 6442?

Brian

> On Oct 26, 2017, at 9:14 AM, Olle E. Johansson <[email-masked]> wrote:
> 
>> On 26 Oct 2017, at 15:09, Olle E. Johansson <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> [email-masked] <mailto:[email-masked]>

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 26 Oct 2017 15:34:00 -0400

On 10/26/17 9:09 AM, Olle E. Johansson wrote:
> in section 4, you refer to “other-loc-src” as a token. That’s not 
> clearly specified. WIll there be a registry for “tokens”?

Agree. A simply way out of this is to leave use of this for future 
definition, so that, for now, it can't be used, but with default 
processing on reception being defined to ignore.

There are other problems with this as well.

Syntactically, 'token' isn't defined. I trust what is intended is 
'token' as defined in 3261. If so that needs to be specified.

But that presents a further problem - ambiguity. A token is a superset 
of hostname. There needs to be a way to distinguish an 'other-loc-src' 
from a hostname.

	Thanks,
	Paul

---

From: "Jesske, Roland" <[email-masked]>
Date: Fri, 27 Oct 2017 08:22:11 +0000

Thank you for your comments.
We had the discussion a couple of weeks ago.
I had let in the token due to some comment. It was stated the ti would be good to have the possibility of extending the mechanism.
ETSI does only need only the loc-src.
So before opening Pandora's box I will delete the other-loc-src.

Is this OK for everybody?

Best regards

Roland

> Von: sipcore [mailto:[email-masked]] Im Auftrag von Paul Kyzivat
> Gesendet: Donnerstag, 26. Oktober 2017 21:34
> An: [email-masked]
> Betreff: Re: [sipcore] New Version Notification for draft-winterbottom-sipcore-
> locparam-02.txt
> 
> Agree. A simply way out of this is to leave use of this for future definition, so
> that, for now, it can't be used, but with default processing on reception being
> defined to ignore.
> 
> Syntactically, 'token' isn't defined. I trust what is intended is 'token' as defined
> in 3261. If so that needs to be specified.
> 
> But that presents a further problem - ambiguity. A token is a superset of
> hostname. There needs to be a way to distinguish an 'other-loc-src'
> from a hostname.
> 
> 	Thanks,
> 	Paul
>

---

From: "Jesske, Roland" <[email-masked]>
Date: Fri, 27 Oct 2017 08:25:10 +0000

Hi Brian,
Thank you for the hint, I will update the security section.

Best Regards

Roland

Von: sipcore [mailto:[email-masked]] Im Auftrag von Brian Rosen
Gesendet: Donnerstag, 26. Oktober 2017 15:48
An: Olle E Johansson <[email-masked]>
Cc: [email-masked]; [email-masked]; Jesske, Roland <[email-masked]>
Betreff: Re: [sipcore] New Version Notification for draft-winterbottom-sipcore-locparam-02.txt

Brian

On Oct 26, 2017, at 9:14 AM, Olle E. Johansson <[email-masked]<mailto:[email-masked]>> wrote:

/O

On 26 Oct 2017, at 15:09, Olle E. Johansson <[email-masked]<mailto:[email-masked]>> wrote:

Cheers,
/O
_______________________________________________
sipcore mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/sipcore

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 27 Oct 2017 10:47:37 -0400

> So before opening Pandora's box I will delete the other-loc-src.

OK, that solves the problems. If there is future need to convey location 
in some other form all you need to do is define another parameter for that.

	Thanks,
	Paul