Subject: [Geopriv] local-civic registry management policy

From: Brian Rosen <[email-masked]>
Date: Mon, 7 Mar 2011 15:36:17 -0500

In -local-civic, the text on registration currently states:
   The "CAtypes" registry is altered to operate on a registration policy
   of "Expert Review", and optionally "Specification Required"
   [RFC5226].

   The registration rules for "Specification Required" are followed only
   if a registration includes a reference to a specification.
   Registrations can be made without a specification reference.

I think this came about because of my yammering about two different kinds of extensions:
1) Truly local extensions, where an app has to be created specifically around the use case and the extension.  These are more special purpose applications
2) Generally applicable extensions that are used relatively widely, and for which most implementations should be able to use them

We expect, for example, that any implementation of civic address would be able to handle ALL of the CAtypes in the current registry, and implementors of a location source can reasonably expect that a PIDF containing any or all of these elements would work.  

I posit that we haven't had enough countries writing their civic address encodings as recommended in 5774, and we will find some additional elements like Street Type Prefix, and Lamp Post, which are more commonly used.

What I would like to see is two ways to add a new element to the registry: one which is basically FCFS, expert review to avoid duplicates, and the other is specification required, expert review for general applicability.  We would the say that all implementations SHOULD be able to correctly handle any of the latter elements, just like they handle the elements now in 5139.

The definition of the registry in the current draft of local-civic is okay, the working of Management Policy is what I want to change.

I will propose exact wording for this section if this differentiation makes sense.

Brian

---

From: Ted Hardie <[email-masked]>
Date: Mon, 7 Mar 2011 14:43:17 -0800

Hi Brian,

Forgive the top posting, but I'd like to encourage you to go ahead and
post suggested language.  It's hard for me to parse how what you
discuss below would fit into the document, and exact language would
improve that a good bit.

thanks,

Ted

On Mon, Mar 7, 2011 at 12:36 PM, Brian Rosen <[email-masked]> wrote:
> _______________________________________________
> Geopriv mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/geopriv
>

---

From: Brian Rosen <[email-masked]>
Date: Tue, 8 Mar 2011 10:08:43 -0500

Somewhere before this section:

New CAtypes have a myriad of uses.  This document classifies usage into two classes:
Type A: CAtypes that are more widely used to encode civic addresses, and most clients should be able to use the extension

Type B: CAtypes that are special purpose, and both the client and server have to be constructed specifically for the use case the extension was designed for, and consequently relatively few clients will be able to use the extension CAtype

The CAtypes defined in [RFC4119] and [RFC5139] are examples of Type A CAtypes.

The CAtypes registry is modified by this document to contain an indication of which type of extension CAtype the entry is.  All clients implementing PIDF-LO SHOULD implement all Type A extension CAtypes, recognizing that a newly defined Type A extension CAtype marked may not be implemented by a client until that client is updated and some clients may be constructed for special purposes where it is known that a Type A CAtype will not be encountered.

In this section, replace the text noted with:

The CAtypes registry is altered to so that it's management policy [RFC5226] for Type A registrations (see Section [?]) is "Standards Action".  If a Type A registration is made, the specification column in the registry will contain a reference to an RFC.  

Type B registrations require "Expert Review".  A specification is optional.  If it is provided, it must meet the rules for "Specification Required".

Registrations requests to IANA for this registry must specify whether a Type A or Type B registration is desired.  All entries presently in the registry are Type A.

---

From: "Thomson, Martin" <[email-masked]>
Date: Wed, 9 Mar 2011 05:51:25 +0800

This proposal fundamentally changes the mechanism in the draft.

If you want to re-open the discussion, then I guess that's fair game.  I'm against it.

--Martin

On 2011-03-09 at 02:08:43, Brian Rosen wrote:
> Type A: CAtypes that are more widely used to encode civic addresses, 
> and most clients should be able to use the extension
> 
> Type B: CAtypes that are special purpose, and both the client and 
> server have to be constructed specifically for the use case the 
> extension was designed for, and consequently relatively few clients 
> will be able to use the extension CAtype
> 
> The CAtypes registry is modified by this document to contain an 
> indication of which type of extension CAtype the entry is.  All 
> clients implementing PIDF-LO SHOULD implement all Type A extension 
> CAtypes, recognizing that a newly defined Type A extension CAtype 
> marked may not be implemented by a client until that client is updated 
> and some clients may be constructed for special purposes where it is 
> known that a Type A CAtype will not be encountered.
> 
> 
> The CAtypes registry is altered to so that it's management policy 
> [RFC5226] for Type A registrations (see Section [?]) is "Standards 
> Action".  If a Type A registration is made, the specification column 
> in the registry will contain a reference to an RFC.
> 
> 
> Type B registrations require "Expert Review".  A specification is 
> optional.  If it is provided, it must meet the rules for 
> "Specification Required".
> 
> Registrations requests to IANA for this registry must specify whether 
> a Type A or Type B registration is desired.  All entries presently in 
> the registry are Type A.
> 
> 
> 
> 
> >> 1) Truly local extensions, where an app has to be created 
> >> specifically around the use case and the extension.  These are more 
> >> special purpose applications
> >> 2) Generally applicable extensions that are used relatively widely, 
> >> and for which most implementations should be able to use them
> >>
> >> We expect, for example, that any implementation of civic address
> would be able to handle ALL of the CAtypes in the current registry, 
> and implementors of a location source can reasonably expect that a 
> PIDF containing any or all of these elements would work.
> >>
> >> I posit that we haven't had enough countries writing their civic
> address encodings as recommended in 5774, and we will find some 
> additional elements like Street Type Prefix, and Lamp Post, which are 
> more commonly used.
> >>
> >> What I would like to see is two ways to add a new element to the
> registry: one which is basically FCFS, expert review to avoid 
> duplicates, and the other is specification required, expert review for 
> general applicability.  We would the say that all implementations 
> SHOULD be able to correctly handle any of the latter elements, just 
> like they handle the elements now in 5139.
> >>
> >> The definition of the registry in the current draft of local-civic
> is okay, the working of Management Policy is what I want to change.
> >>

---

From: "Winterbottom, James" <[email-masked]>
Date: Wed, 9 Mar 2011 06:10:56 +0800

+1 to this.

I thought that we had got agreement on a single registry and what was required for this. I see no benefit in a secondary registry.

Cheers
James

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Thomson, Martin
> Sent: Wednesday, 9 March 2011 8:51 AM
> To: Brian Rosen; Ted Hardie
> Cc: [email-masked] WG
> Subject: Re: [Geopriv] local-civic registry management policy
>

---

From: Brian Rosen <[email-masked]>
Date: Tue, 8 Mar 2011 17:37:46 -0500

There is only one registry.  There are two types of registrations.  The only difference is the level of scrutiny.   The functional difference is SHOULD IMPLEMENT Type A.

If you don't do this, then a large class of civic locations won't be able to be handled by most clients.  A good example is the prefix fields.  There are many countries where there is some alpha numeric prefix before the numeric house number.  If most clients can't handle that, all of those addresses won't be correctly located.

On the other hand, the bridge ID is an example of the Type B registrations.  We only care about uniqueness.  Implementation will be specific for the use case.

Brian

---

From: "Thomson, Martin" <[email-masked]>
Date: Wed, 9 Mar 2011 07:02:01 +0800

OK, so you DO want to re-run the arguments.

Having two types of registry is more harmful to interoperability.

On 2011-03-09 at 09:37:46, Brian Rosen wrote:
> There is only one registry.  There are two types of registrations.  The
> only difference is the level of scrutiny.   The functional difference
> is SHOULD IMPLEMENT Type A.

Whether or not something should be implemented is not a judgment that we (or IANA) either need or want to make.  The current text doesn't make that decision necessary.

Worse, if you have two classes of registration, once the decision is made it's permanent.

So you have to discuss how to choose which applies for a particular registration.  For instance, your "Type A" doesn't convert properly unless it is understood by the converter.

--Martin

---

From: Brian Rosen <[email-masked]>
Date: Tue, 8 Mar 2011 20:42:34 -0500

You can always re-register with an RFC to upgrade to Type A.  You don't need to change the namespace to do that.  IANA would simply change the reference and the type value, fully backwards compatible.

We could say that explicitly if you like.

There is no interoperability issue with two types.  The ONLY functional difference is the SHOULD IMPLEMENT.  That doesn't create interop problems.

The judgement is the IETFs (PS RFC), not IANAs.  

I'm not following the "convert" issue.  Who is converting what?

Brian

---

From: "Thomson, Martin" <[email-masked]>
Date: Wed, 9 Mar 2011 11:28:13 +0800

> I'm not following the "convert" issue.  Who is converting what?

You are pulling my leg, right?

Conversion between DHCP and XML formats was crucial in reaching the current solution.  Without that particular wrinkle, we wouldn't even have this draft.

---

From: "Winterbottom, James" <[email-masked]>
Date: Wed, 9 Mar 2011 14:00:45 +0800

I think you may be talking past each other a bit here.

I think Brian is saying that the XML and DHCP encodings we have in the document are fine as is, and that his Type-As and Type-Bs are encoded exactly the same way. The only difference is that every implementation SHOULD be expected to understand everything in 5139 + any Type-As that find their way into the new registry.

Is this right Brian?

Cheers
James

> Sent: Wednesday, 9 March 2011 2:28 PM
> To: Brian Rosen
> Cc: [email-masked] WG
> Conversion between DHCP and XML formats was crucial in reaching the
> current solution.  Without that particular wrinkle, we wouldn't even have
> this draft.

---

From: Brian Rosen <[email-masked]>
Date: Wed, 9 Mar 2011 09:22:37 -0500

Yes, that is correct.  The type is only a column in the registry and the SHOULD IMPLEMENT statement for Type A.  There is no other significance to Type.

Note that the Type column in the registry would start with all 5139 tags defined as Type A.

I am not suggesting two registries.  This document would rework the existing CAtypes registry.  My proposed change would add one more column to that registry containing "A" or "B".

I am not suggesting any changes to encoding.

Brian