Subject: [Ecrit] urn:service:sos.country-specific

From: Brian Rosen <[email-masked]>
Date: Wed, 9 Nov 2016 13:49:06 -0500

I am the expert reviewer for a request from 3GPP to add urn:service:sos.country-specific to the IANA registry.

Please reference RFC7163 and reference: 24.229 12.14.0 available at http://www.3gpp.org/ftp/Specs/archive/24_series/24.229/24229-ce0.zip <http://www.3gpp.org/ftp/Specs/archive/24_series/24.229/24229-ce0.zip> (cf subclause 7.11.1)

The text in 23.229, says, in part:
This sub-service type is used before an appropriate sub-service type is registered with IANA for a specific emergency service. 
The key word for me is “before”, meaning the general intention is to ultimately do  regular registration for an emergency service.  This is similar to a general experimental service, or an “X-“ service.  No registration is needed, no guarantee of interoperability.

The IETF has long history with these kinds of “escape” mechanisms, most of it bad.

In this particular case, I am very confused why it is thought necessary to have this kind of escape mechanism.  While new kinds of emergency services do appear from time to call, such as eCall, it’s rare; very rare.  It’s also definitely not country specific.  The registry is currently managed with expert review, and thus the bar to new services is low.  Even an experimental service that ultimately fails to gain traction would not have any negative consequences if the listing persisted in the registry.

When 7163 was being discussed, we never imagined that a generic escape mechanism was needed, because of these factors.  This request is clearly outside what we expected would occur, and it creates a very wide hole for non-interoperable implementations, especially where the same service exists in more than one country.

On the other hand, we don’t have criteria in 7163 that would allow me, as expert reviewer, to just say no.

My suggested course of action is to send a liaison to CT1 and request that they withdraw this request in favor of just using the registry as it is designed to work.  If 3GPP insists that they must have this feature, I’m not sure I have sufficient grounds to reject it, but I seek the advice of the work group on that.

Brian

---

From: Ted Hardie <[email-masked]>
Date: Wed, 9 Nov 2016 11:08:50 -0800

Hi Brian,

> expert reviewer, to just say no.
I disagree with this, on two grounds.  The first is that 7163 is clear that
the registrations in this registry must be sub-services of the sos
service.  This registration is not in and of itself a sub-service.

The second is that URN namespaces are intended to be managed, in order to
maintain the persistence of the identifier and the persistence of the
referent/identifier relationship. While it is possible to have delegated
spaces within a URN namespace, the persistence is guaranteed by an
agreement between the NID holder and those accepting the delegation.
Because this is an IETF namespace, that means that the agreement would have
to be between the IETF and the sub-namespace holders; no such agreement
appears to be part of this.  The risk is that a
country-specific:country:identifier might be re-used, and the IETF would
have no way to inform the group minting the identifier that this was not
permitted.

> My suggested course of action is to send a liaison to CT1 and request that
> they withdraw this request in favor of just using the registry as it is
> designed to work.  If 3GPP insists that they must have this feature, I’m
> not sure I have sufficient grounds to reject it, but I seek the advice of
> the work group on that.
>
>
I agree with your suggested course of action.  If they decline, however, I
believe you have sufficient grounds to reject it.

Ted

> Brian
>
> _______________________________________________
> Ecrit mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ecrit
>
>

---

From: "Drage, Keith (Nokia - GB)" <[email-masked]>
Date: Thu, 10 Nov 2016 01:23:15 +0000

Brian,

CT1 meets next week and then not until next year.

All this generating liaison statements will miss them doing anything about it until next year.

So please provide them with your input as an expert reviewer as soon as possible, rather than waiting for ECRIT to attempt to reinterpret the words of the RFC. It is then up to them to argue either for or against the spirit of the RFC and URNs in general.

Keith

From: Ecrit [mailto:[email-masked]] On Behalf Of Ted Hardie
Sent: 09 November 2016 19:09
To: Brian Rosen
Cc: ECRIT
Subject: Re: [Ecrit] urn:service:sos.country-specific

Hi Brian,

On Wed, Nov 9, 2016 at 10:49 AM, Brian Rosen <[email-masked]<mailto:[email-masked]>> wrote:

I disagree with this, on two grounds.  The first is that 7163 is clear that the registrations in this registry must be sub-services of the sos service.  This registration is not in and of itself a sub-service.
The second is that URN namespaces are intended to be managed, in order to maintain the persistence of the identifier and the persistence of the referent/identifier relationship. While it is possible to have delegated spaces within a URN namespace, the persistence is guaranteed by an agreement between the NID holder and those accepting the delegation.  Because this is an IETF namespace, that means that the agreement would have to be between the IETF and the sub-namespace holders; no such agreement appears to be part of this.  The risk is that a country-specific:country:identifier might be re-used, and the IETF would have no way to inform the group minting the identifier that this was not permitted.

I agree with your suggested course of action.  If they decline, however, I believe you have sufficient grounds to reject it.
Ted

Brian

_______________________________________________
Ecrit mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/ecrit