Subject: Re: [sipcore] draft-winterbottom-sipcore-locparam-01.txt and Liaison Statement to IETF on location source parameter

From: "Jesske, Roland" <[email-masked]>
Date: Wed, 20 Sep 2017 05:09:43 +0000

Dear all,
since I did not get any comments on our draft it look for me that people are happy with the content.

So I would like to ask the group for adoption of this draft.

Best Regards

Roland

Von: sipcore [mailto:[email-masked]] Im Auftrag von Jesske, Roland
Gesendet: Dienstag, 29. August 2017 10:59
An: [email-masked]
Betreff: [sipcore] draft-winterbottom-sipcore-locparam-01.txt and Liaison Statement to IETF on location source parameter

Dear all,
since I have uploaded the latest draft on draft-winterbottom-sipcore-locparam-01.txt and the last clarification on questions were given on 23. May I did not get any further comment.

With a reference to this draft a Liaison from ETSI ( https://datatracker.ietf.org/liaison/1527/ ) is waiting for action.

The liaison from ETSI is asking on the progress of the draft for their solution on Emergency Call due to the Project of  the European Union Mandate: M493.

My question is, since we have no open questions, if we can now progress the draft.

Thank you for consideration.

Best Regards

Roland

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 20 Sep 2017 15:11:45 -0400

I'm ok with adopting this.

A minor point on the content:

The syntax of the new parameter is defined as:

           location-source = "loc-src=" (host / other-loc-src)
           other-loc-src = token

But there is no definition of 'host'. I think the definition you are 
intending is actually 'hostname' as defined in 3261.

Also, if "Only a fully qualified host name is valid" then what is the 
point of 'other-loc-src'?

So I would suggest:

           location-source = "loc-src=" hostname
           hostname = <defined in RFC3261>

	Thanks,
	Paul

On 9/20/17 1:09 AM, Jesske, Roland wrote:
> *Von:*sipcore [mailto:[email-masked]] *Im Auftrag von *Jesske, 
> Roland
> *Gesendet:* Dienstag, 29. August 2017 10:59
> *An:* [email-masked]
> *Betreff:* [sipcore] draft-winterbottom-sipcore-locparam-01.txt and 
> Liaison Statement to IETF on location source parameter
> 
> Dear all,
> 
> since I have uploaded the latest draft on 
> draft-winterbottom-sipcore-locparam-01.txt and the last clarification on 
> questions were given on 23. May I did not get any further comment.
> 
> With a reference to this draft a Liaison from ETSI ( 
> https://datatracker.ietf.org/liaison/1527/ ) is waiting for action.
> 
> The liaison from ETSI is asking on the progress of the draft for their 
> solution on Emergency Call due to the Project of  the European Union 
> Mandate: M493.
> 
> _______________________________________________
> sipcore mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sipcore
>

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 20 Sep 2017 20:45:03 +0000

Hi,

I am ok with the draft as such, but I have a few comments, in addition to those given by Paul.

First, there are some MUSTs and MUST NOTs, without any clear justification.

For example:

"Only a fully qualified host name is valid, an IP address MUST NOT be added by an entity conforming with this specification."

"A UE MUST NOT provide a loc-src parameter value."

Second, "UE" is not an IETF term. You should use "UA". But still, I think you need to be a little more clear what exactly you mean. Because, a B2BUA also implements a "UA", but I assume you don't want to prevent it from using the mechanism?

Third, related to the first, why do you mandate the value to be a FQDN?

Fourth, I am pretty sure the security folks are going to request more text on the fact that you don't know whether the receiver of the parameter supports it or not, which means it might not be removed (and, thus, forwarded e.g., to a non-trusted network).

Regards,

Christer

From: sipcore [mailto:[email-masked]] On Behalf Of Jesske, Roland
Sent: 20 September 2017 07:10
To: [email-masked]
Subject: Re: [sipcore] draft-winterbottom-sipcore-locparam-01.txt and Liaison Statement to IETF on location source parameter

Dear all,

Best Regards

Roland

Von: sipcore [mailto:[email-masked]] Im Auftrag von Jesske, Roland
Gesendet: Dienstag, 29. August 2017 10:59
An: [email-masked]<mailto:[email-masked]>
Betreff: [sipcore] draft-winterbottom-sipcore-locparam-01.txt and Liaison Statement to IETF on location source parameter

Dear all,

Best Regards

Roland

---

From: "Jesske, Roland" <[email-masked]>
Date: Fri, 22 Sep 2017 05:30:16 +0000

Hi Paul,
Thank you for your comment.
The addition of other-loc-src was discussed in the past and was added due to some requests not to restrict this parameter to a hostname.
ETSI does only needs a hostname.

So I have nothing against to change it as you have proposed it. 
So If other people would like to keep this please speak up.

Thank you and Best Regards

Roland

> -----Ursprüngliche Nachricht-----
> Von: sipcore [mailto:[email-masked]] Im Auftrag von Paul Kyzivat
> Gesendet: Mittwoch, 20. September 2017 21:12
> An: [email-masked]
> Betreff: Re: [sipcore] draft-winterbottom-sipcore-locparam-01.txt and
> But there is no definition of 'host'. I think the definition you are intending is
> actually 'hostname' as defined in 3261.
> 
> Also, if "Only a fully qualified host name is valid" then what is the point of
> 'other-loc-src'?
> 
> So I would suggest:
> 
> > *Von:*sipcore [mailto:[email-masked]] *Im Auftrag von
> > *Jesske, Roland
> > draft-winterbottom-sipcore-locparam-01.txt and the last clarification
> > on questions were given on 23. May I did not get any further comment.
> >

---

From: "Asveren, Tolga" <[email-masked]>
Date: Fri, 22 Sep 2017 06:24:03 +0000

I would prefer to keep the existing syntax. Not that I have an immediate use case at hand but you never know what future would bring. And it would be a pity to have an extension draft just for something like this.

Thanks,
Tolga

-----Original Message-----
From: sipcore [mailto:[email-masked]] On Behalf Of Jesske, Roland
Sent: Friday, September 22, 2017 1:30 AM
To: Paul Kyzivat <[email-masked]>; [email-masked]
Cc: James Winterbottom <[email-masked]>
Subject: Re: [sipcore] draft-winterbottom-sipcore-locparam-01.txt and Liaison Statement to IETF on location source parameter

Hi Paul,

Roland

> > draft-winterbottom-sipcore-locparam-01.txt and the last 
> > clarification on questions were given on 23. May I did not get any further comment.
> >
> > The liaison from ETSI is asking on the progress of the draft for 
> > their solution on Emergency Call due to the Project of  the European 
> > Union
> > Mandate: M493.
> >

---

From: "Jesske, Roland" <[email-masked]>
Date: Fri, 22 Sep 2017 09:44:17 +0000

Hi,
so I can let it as it is or add an additional note to mention that the token is for future proof use.

Also to address Pauls comment complete. I would propose then the following:

          location-source = "loc-src=" (hostname / other-loc-src)
          hostname = <defined in RFC3261>
          other-loc-src = token

                         Figure 1: Location Source

Thank you and Best regards

Roland

> Von: Asveren, Tolga [mailto:[email-masked]]
> Gesendet: Freitag, 22. September 2017 08:24
> An: Jesske, Roland <[email-masked]>; Paul Kyzivat
> <[email-masked]>; [email-masked]
> Betreff: RE: [sipcore] draft-winterbottom-sipcore-locparam-01.txt and
> I would prefer to keep the existing syntax. Not that I have an immediate use
> case at hand but you never know what future would bring. And it would be a
> pity to have an extension draft just for something like this.
> 
> Thanks,
> Tolga
> 
> Subject: Re: [sipcore] draft-winterbottom-sipcore-locparam-01.txt and
> The addition of other-loc-src was discussed in the past and was added due to
> some requests not to restrict this parameter to a hostname.

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 22 Sep 2017 09:42:34 -0400

Roland,

>                           Figure 1: Location Source

I'll be ok with this if you also include some text about the intent of 
other-loc-src. Is it intended only as a hook for future extension - 
requiring another document to define that usage? What should a recipient 
do if they receive this with something matching other-loc-src and don't 
understand that usage?

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 22 Sep 2017 17:21:06 +0000

Hi,

>I'll be ok with this if you also include some text about the intent of other-loc-src. Is it >intended only as a hook for future extension - requiring another document to define that >usage? What should a recipient do if they receive this with something matching other-loc->src and don't understand that usage?

As I indicated in my comments, I'd like to see some justification on why we mandate a FQDN to begin with.

Regards,

Christer

>> I would prefer to keep the existing syntax. Not that I have an 
>> immediate use case at hand but you never know what future would 
>> bring. And it would be a pity to have an extension draft just for something like this.
>>
>> Thanks,
>> Tolga
>>
>> The addition of other-loc-src was discussed in the past and was added 
>> due to some requests not to restrict this parameter to a hostname.
>>> Betreff: Re: [sipcore] draft-winterbottom-sipcore-locparam-01.txt 
>>> and Liaison Statement to IETF on location source parameter
>>>
>>> Also, if "Only a fully qualified host name is valid" then what is 
>>> the point of 'other-loc-src'?
>>>
>>> So I would suggest:
>>>
>>>> clarification on questions were given on 23. May I did not get any 
>>>> further
>> comment.
>>>>
>>>> their solution on Emergency Call due to the Project of  the 
>>>> European Union
>>>> Mandate: M493.
>>>>

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 22 Sep 2017 15:16:38 -0400

> As I indicated in my comments, I'd like to see some justification on why we mandate a FQDN to begin with.

As opposed to *what*?

Surely there ought to be some semantics to this. I presume it is to be 
an identifier of something, and presumably there then need to be rules 
for resolution/comparison/etc.

Otherwise I could just enter XYZZY.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 22 Sep 2017 19:31:22 +0000

Hi,

>>> I'll be ok with this if you also include some text about the intent of other-loc-src. Is it intended only as a hook for future extension - requiring another document to 
>>> define that usage? What should a recipient do if they receive this with something matching other-loc->src and don't understand that usage?
>> 
> Surely there ought to be some semantics to this. I presume it is to be an identifier of something, and presumably there then need to be rules for 
> resolution/comparison/etc.

Based on my understanding of the draft (please correct me if I'm wrong), it's only an identifier within a trust domain. What matters is that entities within that trust domain understand the semantics.

But, assuming we want something "real", why is an IP address not allowed?

Regards,

Christer

>>> Betreff: RE: [sipcore] draft-winterbottom-sipcore-locparam-01.txt 
>>> Subject: Re: [sipcore] draft-winterbottom-sipcore-locparam-01.txt 
>>> The addition of other-loc-src was discussed in the past and was 
>>> added due to some requests not to restrict this parameter to a hostname.
>>>> But there is no definition of 'host'. I think the definition you 
>>>> are intending is actually 'hostname' as defined in 3261.
>>>>
>>>>> *Betreff:* [sipcore] draft-winterbottom-sipcore-locparam-01.txt

---

From: [email-masked] (Dale R. Worley)
Date: Sun, 24 Sep 2017 22:27:31 -0400

> Otherwise I could just enter XYZZY.

If usage is confined to a single administrative domain (which is what I
think Christer is saying), there don't need to be general semantic
rules.  There don't even need to be general syntactic rules.

Dale

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 25 Sep 2017 07:24:42 +0000

Hi,

>rules.  There don't even need to be general syntactic rules.

Correct.

And, again, if there something I¹ve missed, and there is a reason for
justifying a FQDN - fine. But, if so, I want that justification to be
described in the draft.

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 25 Sep 2017 09:01:47 -0400

> rules.  There don't even need to be general syntactic rules.

The usage isn't *restricted* to IMS. It is simply defined with the 
expectation that they are the ones who need it. If others are allowed to 
use it then there need to be some rules to ensure mutual understanding. 
Otherwise this is just using sip to tunnel another protocol.

The advantage of using FQDNs is that there are clear rules for 
assignment of those.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 25 Sep 2017 13:04:57 +0000

Hi,

>The advantage of using FQDNs is that there are clear rules for

I don¹t think I said ³IMS² :)

But, the draft DOES say that the identifier must only be used within a
trusted domain.

Regards,

Christer