Hi Sam,
please find some feedback below:
"Henning" == Henning Schulzrinne <hgs(_at_)cs(_dot_)columbia(_dot_)edu>
writes:
>> 2) Inadequate context for use:
>>
>> The document does not make reference to RPID, except in
>> "acknowledgement". Thus, it has to be interpreted as
>> stand-alone, and must contain its own guidance. RPID states:
>>
>>
>>
>> These things guide the usage of place-types in RPID, but cannot
>> be found from the registry document.
>>
Henning> Since usage will strongly depend on the context and since
Henning> this registry is not limited to RPID, I think this would
Henning> belong into RPID (or other documents), not the registry.
>> This document SHOULD give guidance for usage, saying at least:
>>
>> - whether it's intended that several of these values can be
>> used together
Henning> I'd assume yes, in general, but defining that seems to be
Henning> the role of the protocol using these elements, not a
Henning> registry.
Henning> I think of the registry like a dictionary. A dictionary
Henning> does not define which words you can use together.
Here I think is the crux of the problem. The IETF and IANA should not
be in the business of creating dictionaries.
There are documents that use a location type. We can give an initial
list of values but we cannot be exhaustive.
Do you have a better suggestion for extending these values?
The document under discussion creates a named set of place
descriptions.
There is no guidance given on how this information should be used,
This information is provided in other documents (RADIUS-Geopriv and
DHCP-CIVIC). We can add references to these documents.
why
you would want this registry
To provide a mechanism for extending the currently defined list of
values.
or what constraints should be placed on
it.
We have received some feedback about these constraints and we will put
them into the IANA consideration section (as suggested). Documents that
use the values in the registry provide additional constraints.
That's a big problem. First, there are likely to be concerns that
matter to almost all uses of the registry. It's desirable to require
using applications to consider these concerns and probably even to
describe how they handle the concerns.
Another reason not giving guidance is problematic has to do with
different assumptions about how the registry is used. Some
applications may assume that there will be a small number of entries
in the registry. That's fine until someone comes along and say
registers all the different major food chains with presence in more
than one country.
With the suggested change to expert review for enhancing or updating the
values in the registry this aspect seems to be covered.
One application may assume that location is single valued; another may
have multi-valued location. These applications will expect different
things from the registry.
There is no problem about this aspect.
Even when we've tried to have guidance for registries we've run into
problems. Witness the recent debate about whether RTP and MIME should
use the same media type registry.
As such, with my AD hat off, I do not support publication of an RFC
that establishes a dictionary for place names I would probably support
publication of an RFC that established a well-coped place name
registry for some purpose. I'd want to limit the size of the registry
for localization reasons.
I would like to make sure that I properly understand you.
It would be OK for you if we copy-and-paste the document into RPID,
RADIUS-Geopriv, DHCP-CIVIC (instead of referencing it) and create a
separate registry for each of these documents.
Ciao
Hannes
--Sam
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf