MIME-Version: 1.0
In-Reply-To: <F4B26B73-8B33-4C88-B8A3-B9A28EAC967D@salsgiver.com>
References: <F4B26B73-8B33-4C88-B8A3-B9A28EAC967D@salsgiver.com>
From: Ted Hardie <ted.ietf@gmail.com>
Date: Wed, 9 Nov 2016 11:08:50 -0800
Message-ID: <CA+9kkMApo-Yx5cG2z1Deu1Sxo=C8+ZF7zJwXZ9aqjfTKko1vDQ@mail.gmail.com>
To: Brian Rosen <br@salsgiver.com>
Content-Type: multipart/alternative; boundary=001a114e2cf6886b070540e2fe72
Archived-At: <https://mailarchive.ietf.org/arch/msg/ecrit/p3LH8Xr14hC1VFZlkAFkAYpcQng>
Cc: ECRIT <ecrit@ietf.org>
Subject: Re: [Ecrit] urn:service:sos.country-specific
Precedence: list

--001a114e2cf6886b070540e2fe72
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hi Brian,

On Wed, Nov 9, 2016 at 10:49 AM, Brian Rosen <br@salsgiver.com> wrote:

>
> On the other hand, we don=E2=80=99t have criteria in 7163 that would allo=
w me, as
> 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 tha=
t
> 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=E2=
=80=99m
> 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
> Ecrit@ietf.org
> https://www.ietf.org/mailman/listinfo/ecrit
>
>

--001a114e2cf6886b070540e2fe72
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Hi Brian, <br><div><div class=3D"gmail_extra"><br><div cla=
ss=3D"gmail_quote">On Wed, Nov 9, 2016 at 10:49 AM, Brian Rosen <span dir=
=3D"ltr">&lt;<a href=3D"mailto:br@salsgiver.com" target=3D"_blank">br@salsg=
iver.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=
=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div sty=
le=3D"word-wrap:break-word"><br><div>On the other hand, we don=E2=80=99t ha=
ve criteria in 7163 that would allow me, as expert reviewer, to just say no=
.</div><div><br></div></div></blockquote><div><br></div><div>I disagree wit=
h this, on two grounds.=C2=A0 The first is that 7163 is clear that the regi=
strations in this registry must be sub-services of the sos service.=C2=A0 T=
his registration is not in and of itself a sub-service.=C2=A0 <br><br></div=
><div>The second is that URN namespaces are intended to be managed, in orde=
r to maintain the persistence of the identifier and the persistence of the =
referent/identifier relationship. While it is possible to have delegated sp=
aces within a URN namespace, the persistence is guaranteed by an agreement =
between the NID holder and those accepting the delegation.=C2=A0 Because th=
is is an IETF namespace, that means that the agreement would have to be bet=
ween the IETF and the sub-namespace holders; no such agreement appears to b=
e part of this.=C2=A0 The risk is that a country-specific:country:identifie=
r might be re-used, and the IETF would have no way to inform the group mint=
ing the identifier that this was not permitted.<br>=C2=A0</div><blockquote =
class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid=
;padding-left:1ex"><div style=3D"word-wrap:break-word"><div></div><div>My s=
uggested 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 designe=
d to work.=C2=A0 If 3GPP insists that they must have this feature, I=E2=80=
=99m not sure I have sufficient grounds to reject it, but I seek the advice=
 of the work group on that.</div><span class=3D"HOEnZb"><font color=3D"#888=
888"><div><br></div></font></span></div></blockquote><div><br></div><div>I =
agree with your suggested course of action.=C2=A0 If they decline, however,=
 I believe you have sufficient grounds to reject it.<br><br></div><div>Ted<=
br></div><div><br>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"ma=
rgin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style=3D"=
word-wrap:break-word"><span class=3D"HOEnZb"><font color=3D"#888888"><div><=
/div><div>Brian</div></font></span></div><br>______________________________=
<wbr>_________________<br>
Ecrit mailing list<br>
<a href=3D"mailto:Ecrit@ietf.org">Ecrit@ietf.org</a><br>
<a href=3D"https://www.ietf.org/mailman/listinfo/ecrit" rel=3D"noreferrer" =
target=3D"_blank">https://www.ietf.org/mailman/<wbr>listinfo/ecrit</a><br>
<br></blockquote></div><br></div></div></div>

--001a114e2cf6886b070540e2fe72--