Subject: [Ecrit] Draft new version: draft-holmberg-ecrit-country-emg-urn-01

From: Christer Holmberg <[email-masked]>
Date: Mon, 25 Feb 2013 10:54:26 +0000

Hi,

I've submitted a new version (-01) of draft-holmberg-ecrit-country-emg-urn-01.

The only change is a tiny editorial fix.

Note, that due to a timing issue, I wasn't able to add the alternative of relaxing the registration rules for the existing registry, but that alternative WILL be on the slides for Orlando.

Regards,

Christer

---

From: "Winterbottom, James" <[email-masked]>
Date: Tue, 26 Feb 2013 07:45:53 +0800

Hi Christer,

I have read the new version of the draft and I am unconvinced that these there is a need for these to be country specific.
I can certainly see a need to register additional sub-service types under the sos service urn, but what makes the kidnapping service in Columbia different from a kidnapping service in say Somalia?

I am concerned with the proposed solution described in section 6.1 as this presupposes that the service URN included in the query to the LoST server includes a country indicator, and this requires the client to understand where it is and what service types are available in that area. While a query to LoST does require the client to have a location, it does not necessarily require the client to "understand" that location, changing the service URNs in the manner you are proposing undermines this. Further, in the case of the device only having a geodetic location it now needs to be able to reverse-geocode this somehow to arrive at a country code.

I think that for this draft to progress on the pretext being proposed then some degree of specific country-level service differentiation needs to be demonstrated and I am not seeing this.

I think that it is perfectly valid to say that some service, the reporting-spies for example, are required services but do they all necessarily fall under the sos service tree? Some of this leads back to the service categorization discussion that we had a number of IETFs ago. I can see that a gov service URN might be valid, but not a country one.

Cheers
James

From: [email-masked] [mailto:[email-masked]] On Behalf Of Christer Holmberg
Sent: Monday, 25 February 2013 9:54 PM
To: [email-masked]
Subject: [Ecrit] Draft new version: draft-holmberg-ecrit-country-emg-urn-01

Hi,

Regards,

Christer

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Tue, 26 Feb 2013 01:25:38 +0100

Any subtype has to fulfil the requirement of the top level type, and there is a fairly rigorous definition of what constitutes "sos". If the subtype does not fulfil this, then it should not be used.

But to me the main criteria for existence of these subtypes is that we have an emergency service in a country that is fairly unique. If we have multiple countries using an emergency service that can be combined in a single definition, then we should invent a new subtype. So I believe we need this draft, but the usage should not be so endemic as you imply.

Keith

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of Winterbottom, James
Sent: 25 February 2013 23:46
To: Christer Holmberg; [email-masked]
Subject: Re: [Ecrit] Draft new version: draft-holmberg-ecrit-country-emg-urn-01

Hi Christer,

Cheers
James

Hi,

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 26 Feb 2013 08:44:31 +0800

On 2/26/13 8:25 AM, DRAGE, Keith (Keith) wrote:
> Any subtype has to fulfil the requirement of the top level type, and
> there is a fairly rigorous definition of what constitutes “sos”. If the
> subtype does not fulfil this, then it should not be used.
>
> But to me the main criteria for existence of these subtypes is that we
> have an emergency service in a country that is fairly unique. If we have
> multiple countries using an emergency service that can be combined in a
> single definition, then we should invent a new subtype. So I believe we
> need this draft, but the usage should not be so endemic as you imply.

ISTM that having a country-coded service would only make sense if the 
service is unique to country and it would never make sense for another 
country to have an analogous service. It is hard for me to imagine such 
a case.

If another country *did* want to introduce an analogous service, then 
what would it do? The choices seem to be to either define another 
country-specific service with the same semantics, or else use the 
existing name defined for a different country. Neither seems like a good 
choice.

So, ISTM that it would be better to change the rules to allow defining a 
new service even in cases where it initially will only be used in one 
country. This sounds like a good place for expert review to help ensure 
that the new service isn't redundant, and that it is defined as broadly 
as possible to encourage reuse.

	Thanks,
	Paul

> Keith
>
> ------------------------------------------------------------------------
>
> *From:[email-masked] [mailto:[email-masked]] *On Behalf
> Of *Winterbottom, James
> *Sent:* 25 February 2013 23:46
> *To:* Christer Holmberg; [email-masked]
> *Subject:* Re: [Ecrit] Draft new version:
> draft-holmberg-ecrit-country-emg-urn-01
>
> Hi Christer,
>
> I have read the new version of the draft and I am unconvinced that these
> there is a need for these to be country specific.
>
> I can certainly see a need to register additional sub-service types
> under the sos service urn, but what makes the kidnapping service in
> Columbia different from a kidnapping service in say Somalia?
>
> I am concerned with the proposed solution described in section 6.1 as
> this presupposes that the service URN included in the query to the LoST
> server includes a country indicator, and this requires the client to
> understand where it is and what service types are available in that
> area. While a query to LoST does require the client to have a location,
> it does not necessarily require the client to “understand” that
> location, changing the service URNs in the manner you are proposing
> undermines this. Further, in the case of the device only having a
> geodetic location it now needs to be able to reverse-geocode this
> somehow to arrive at a country code.
>
> I think that for this draft to progress on the pretext being proposed
> then some degree of specific country-level service differentiation needs
> to be demonstrated and I am not seeing this.
>
> I think that it is perfectly valid to say that some service, the
> reporting-spies for example, are required services but do they all
> necessarily fall under the sos service tree? Some of this leads back to
> the service categorization discussion that we had a number of IETFs ago.
> I can see that a gov service URN might be valid, but not a country one.
>
> Cheers
>
> James
>
> *From:[email-masked] [mailto:[email-masked]] *On Behalf
> Of *Christer Holmberg
> *Sent:* Monday, 25 February 2013 9:54 PM
> *To:* [email-masked]
> *Subject:* [Ecrit] Draft new version:
> draft-holmberg-ecrit-country-emg-urn-01
>
> Hi,
>
> I’ve submitted a new version (-01) of
> draft-holmberg-ecrit-country-emg-urn-01.
>
> Note, that due to a timing issue, I wasn’t able to add the alternative
> of relaxing the registration rules for the existing registry, but that
> alternative WILL be on the slides for Orlando.
>
> Regards,
>
> Christer
>
>
>
> _______________________________________________
> Ecrit mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ecrit
>

---

From: "Winterbottom, James" <[email-masked]>
Date: Tue, 26 Feb 2013 09:53:42 +0800

Thanks Paul, I think that this is more or less what I was thinking.
I think that there are very few service that could only possibly exist in one country.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Paul Kyzivat
Sent: Tuesday, 26 February 2013 11:45 AM
To: [email-masked]
Subject: Re: [Ecrit] Draft new version: draft-holmberg-ecrit-country-emg-urn-01

On 2/26/13 8:25 AM, DRAGE, Keith (Keith) wrote:
> there is a fairly rigorous definition of what constitutes "sos". If 
> the subtype does not fulfil this, then it should not be used.
>
> have an emergency service in a country that is fairly unique. If we 
> have multiple countries using an emergency service that can be 
> combined in a single definition, then we should invent a new subtype. 
> So I believe we need this draft, but the usage should not be so endemic as you imply.

ISTM that having a country-coded service would only make sense if the service is unique to country and it would never make sense for another country to have an analogous service. It is hard for me to imagine such a case.

If another country *did* want to introduce an analogous service, then what would it do? The choices seem to be to either define another country-specific service with the same semantics, or else use the existing name defined for a different country. Neither seems like a good choice.

So, ISTM that it would be better to change the rules to allow defining a new service even in cases where it initially will only be used in one country. This sounds like a good place for expert review to help ensure that the new service isn't redundant, and that it is defined as broadly as possible to encourage reuse.

	Thanks,
	Paul

> *From:[email-masked] [mailto:[email-masked]] *On 
> Behalf Of *Winterbottom, James
> I have read the new version of the draft and I am unconvinced that 
> these there is a need for these to be country specific.
>
> this presupposes that the service URN included in the query to the 
> LoST server includes a country indicator, and this requires the client 
> to understand where it is and what service types are available in that 
> area. While a query to LoST does require the client to have a 
> location, it does not necessarily require the client to "understand" 
> that location, changing the service URNs in the manner you are 
> proposing undermines this. Further, in the case of the device only 
> having a geodetic location it now needs to be able to reverse-geocode 
> this somehow to arrive at a country code.
>
> then some degree of specific country-level service differentiation 
> needs to be demonstrated and I am not seeing this.
>
> necessarily fall under the sos service tree? Some of this leads back 
> to the service categorization discussion that we had a number of IETFs ago.
> *From:[email-masked] [mailto:[email-masked]] *On 
> Behalf Of *Christer Holmberg
> Note, that due to a timing issue, I wasn't able to add the alternative

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 26 Feb 2013 08:24:18 +0000

Hi,

Please note that it has been suggested that, instead of creating a subtree for the emergency URNs for the country specific emergency services, we simply relax the policy for registration of any emergency URNs - as Paul also suggests.

That would allow the registration of a URN that, AT THE TIME OF REGISTRATION, is unique to a single country. Then, later, other countries can also use the URN.

And, in this case the URN would not need to include "country-specific", or the name of the country.

Regards,

Christer

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Paul Kyzivat
Sent: Tuesday, 26 February 2013 11:45 AM
To: [email-masked]
Subject: Re: [Ecrit] Draft new version: draft-holmberg-ecrit-country-emg-urn-01

	Thanks,
	Paul

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 26 Feb 2013 07:42:19 -0500

Since the reason for the registration rule was to prevent numerous registrations for emergency services that were, in role and mission, very similar, I favor Christer's approach. We've had not-so-great experiences with separate namespaces, such as experimental, with the SIP P- headers being one recent example. As problems, such as child abuse, terrorism or environmental issues, emerge, such services may well proliferate beyond national borders. 

Henning