Subject: Re: [ANCP] Can we modify IANA registries set up for GSMPv3?

From: Wojciech Dec <[email-masked]>
Date: Thu, 01 Jul 2010 14:42:55 +0200

Ok. Unless you know off hand the answer to the alternative (as proposed by
Tom), I will also Whether it's viable to subdivide a code-point space, ie if
gsmp and ancp use the same protocol id, whether we could get iana registries
for ancp-only messages/result codes, etc.

-Woj.

On 01/07/2010 13:50, "Ralph Droms" <[email-masked]> wrote:

> I don't know the answer.  If you'll write up a short request, with a few
> sentences describing how we got the current situation, I'll take it to IANA
> and the IESG.
> 
> - Ralph
> 
> On Jul 1, 2010, at 6:54 AM 7/1/10, Wojciech Dec wrote:
> 
>> I am asking whether renaming the existing GSMP code point as ANCP,
>> effectively deprecating GSMP, is something that can be done?
>> 
>> -Woj.
>> 
>> 
>> On 01/07/2010 12:27, "Ralph Droms (rdroms)" <[email-masked]> wrote:
>> 
>>> Woj - I'm not clear on the course of action you are suggesting.  Do you mean
>>> to declare GSMP deprecated, assign all of the registries to ANCP and assign
>>> codepoints from those registries as if GSMP never existed?
>>> 
>>> - Ralph
>>> 
>>> On Jun 30, 2010, at 12:06 PM 6/30/10, Wojciech Dec wrote:
>>> 
>>>> Adding Ralph...
>>>> 
>>>> The core issue looks like being that ANCP still rides on the GSMP protocol
>>>> code point, even though it is incompatible.
>>>> I'm not sure if there is a precedent for a re-branding of a protocol type,
>>>> but if that is an option, along with declaring GSMP deprecated, then we
>>>> could have an alternative. (Note: Previous searches into finding
>>>> operational
>>>> implementations of GSMP have not found any, but we will never know for
>>>> sure.
>>>> That said, it's highly unlikely that the two will meet.)
>>>> 
>>>> -Woj.
>>>> 
>>>> 
>>>> On 30/06/2010 15:31, "Tom Taylor" <[email-masked]> wrote:
>>>> 
>>>>> This issue may affect other registries, but I realized it when I was
>>>>> looking
>>>>> at
>>>>> the reallocation of bits between Result and Code compared with GSMPv3. I'm
>>>>> sure
>>>>> it's legitimate to add code points to a registry for an older protocol,
>>>>> but
>>>>> this
>>>>> reallocation of bits means that the limits on the possible values change.
>>>>> Can
>>>>> we
>>>>> do that (implying that we obsolete GSMPv3 itself), or must we establish
>>>>> new
>>>>> parallel registries for ANCP?
>>>>> 
>>>>> There is an intermediate solution where we continue to use GSMPv3
>>>>> registries
>>>>> but
>>>>> segregate the codepoints falling outside the limits for one protocol or
>>>>> the
>>>>> other, noting that they apply only to one protocol. Thus in the Result
>>>>> value
>>>>> registry we would add a note that any values greater than 15 apply to
>>>>> GSMPv3
>>>>> only, while in the Code registry, values greater than 255 apply to ANCP
>>>>> only.
>>>>> This sounds like the best solution, though I had to talk myself around to
>>>>> it.
>>>>> 
>>>>> Tom Taylor
>>>>> _______________________________________________
>>>>> ANCP mailing list
>>>>> [email-masked]
>>>>> https://www.ietf.org/mailman/listinfo/ancp
>>>> 
>>> 
>>> 
>

---

From: Ralph Droms <[email-masked]>
Date: Thu, 1 Jul 2010 08:51:57 -0400

I don't know if the alternative can be done, either.  I can see arguments pro/con for both alternatives.  So, if you'll give me a brief write-up of both alternatives, I'll discuss it with the IESG and IANA.

- Ralph

---

From: Tom Taylor <[email-masked]>
Date: Thu, 01 Jul 2010 10:44:57 -0400

Here's a write-up, for all *three* alternatives.

Background: The Access Network Control Protocol (ANCP) was designed taking 
GSMPv3 (RFC 3292) as the starting point. ANCP has introduced modifications and 
extensions that are such as to render the two protocols non-interoperable. 
Nevertheless, the ANCP specification still refers normatively to RFC 3292 for 
both procedures and data formats. In particular, ANCP reuses some IANA 
registries set up by RFC 3292. ANCP needs additional registries of its own.

The complications come in because ANCP has not only added codepoints to these 
GSMPv3 registries, but in some cases has modified the sizes of the fields 
concerned so that the upper limits of the values contained in them have changed. 
To accommodate this, three alternatives have been proposed. The IESG and IANA 
are being asked for their preference amongst these alternatives.

Alternative 1: Parallel Registries
==================================

With this alternative, ANCP ceases to reuse the GSMPv3 registries and instead 
establishes its own. The GSMPv3 codepoints used by ANCP are copied over to the 
ANCP registries, and the GSMPv3 registries are left undisturbed. If GSMPv3 were 
  a living protocol, this would introduce the potential need for continued 
synchronization between the two sets of registries. Given that no known 
implementations of GSMPv3 exist, that maintenance issue isn't really there.

Alternative 2: Reuse With Notes
===============================

With this alternative, a note would be added to each registry that ANCP shares 
with GSMPv3, indicating that the registry is also used by ANCP. It is an open 
question whether codepoints added for ANCP use should be identified as such.

Where the field sizes have changed, further notes would have to be added, 
indicating the limits applicable to GSMPv3 and ANCP respectively. Possibly 
codepoints applicable to only one of the two protocols would be listed separately.

Alternative 3: Deprecation of GSMPv3
====================================

With this alternative, GSMPv3 would be deprecated and the registries not used by 
ANCP would be closed/marked "deprecated". The registries used by ANCP would be 
renamed, leaving behind their GSMPv3 heritage and the codepoints inapplicable to 
ANCP. The ANCP base specification would have to add the material currently 
incorporated by reference from RFC 3292 (and 3293), so that it becomes 
independent of those specifications.

If I may add a personal note, deprecation of GSMPv3 seems like an extreme 
measure. There's also so much heritage in ANCP in the way of GSMPv3 fields that 
are unused that the protocol would seem very odd to someone unaware of its 
history because that history had been obliterated. (Note to Ralph: design of the 
protocol has been constrained by the existence of early implementations, 
departures from which had to be minimized.)

>> for ancp-only messages/result codes, etc.
...

---

From: Wojciech Dec <[email-masked]>
Date: Thu, 01 Jul 2010 16:52:15 +0200

> departures from which had to be minimized.)

The GSMPv3 rfc¹s would still be there, marked accordingly. ANCP is a TCP
version of GSMPv3.2 (which on the wire it looks like, albeit without a lot
of other baggage)....

-Woj.