Reviewing changes per issue #24

[gklyne]

Catching up, re issue #24 ...

Specifics first. More general comments at the end.

section 5.2. Entry Levels, nit

The classification of registry entries into "permanent" and "provisional" is a pattern being followed by other IETF specifications and registries as well, for example by the registration procedures for message header fields [3].

The provisional/permanent pattern was introduced by the message header registration spec (BCP 90), and subsequently adopted and adapted by the URI scheme spec. I'm not aware of any other registries that have also adopted the pattern.

This is just a historical nit, and doesn't affect the substantive content of your text.

5.3. Separation by Value Syntax

I believe there was a proposal to map registered registered link relations into URI space in a consistent fashion, but don't offhand recall where I saw it.

In the case of link relations, I think it is possible to gracefully migrate between categories by retaining the previous use; e.g. a registered link relation could be documented as being equivalent to some URI used as link relation. It's not perfect, but not (IMO) as disruptive as your text seems to suggest, and not in the same league as the "X-" prefix problem.

6.1. Registry Operations

It is possible that a different model may be implemented at a later time, but the current model is biased towards email-based workflows and human-readable registry access.

FWIW, I think IANA are moving towards an underlying XML model for at least some registries that also supports machine readable data. E.g. http://www.iana.org/assignments/uri-schemes/uri-schemes.xml (look at page source). Other formats are also available.

I think there's an important registry operation matter that you haven't touched on here: IANA have great administrative skills, but they cannot be expected to have technical knowledge of any particular protocol or system. So, if registration approval requires any kind of technical judgement, you end up being pretty much compelled to involve an expert review in the registration process.

6.7. Registry Access

This section feels out of place to me, as a subsection of "using registries". It feels more like an operations concern, not something that is really relevant to registry designers, and maybe should be a subsection of 6.1?

6.8. Runtime vs. Design-Time

I'm not aware of any IANA registries that are intended to allow dynamic access. It feels to me like a "bad idea", because it potentially makes IANA a bottleneck in Internet operations, and I'm not sure they have the infrastructure resilience to support this.

I tentatively suggest that if there is an element of dynamic access, then this needs to be part of the related protocol spec rather than pushed onto a registry.

---

General comments

Reflecting on the revised spec and our ealier discussions (per issue #24), I feel that the role of registries as a means to make values discoverable is a bit obscured. It's there in the document (section 3.7), but the message of discoverability does't come over so clearly to me. I think it's partly the choice of section title, and partly because the content also discusses design time vs run time in a way that I think distracts from the key idea of design-time discovery. To my mind, allowing designers and implementers to find out about parameter values is the purpose of IANA registries, and anything else is secondary.

I'd suggest:

1. Including "discovery" in the section title
2. focusing the first paragraph on design-time discovery (e.g. s/anybody/designers and implementers/), and making the discussion of design-time vs run-time secondary (e.g. a subsection), or dropping it altogether.

My suggestion for the first paragraph

OLD:

With a registry containing all current values (and possibly listing changed/deprecated ones as well) along with some registration metadata, they provide valuable information for anybody looking for information about registered values in the registry namespace. All IANA protocol registries [13] are openly accessible on the Web, allowing everybody to lookup the current state of all these registries.

NEW:

A central registry containing all current values (including changed/deprecated ones) makes it easy for protocol designers and implementers to discover information about them. All IANA protocol registries [13] are openly accessible on the Web, allowing everybody to lookup the current state of all these registries, thereby reducing impediments to discovery.

Something else that I think has got lost in the detail here is the role of registries in recording community consensus, or providing recommendations for values to be used as opposed just descriptions of options. This is part of what is at the heart of the permanent/provisional pattern. I guess this is a distinction between use by protocol designers ("we recommend you use these values") vs implementers ("what should my implementation do when it sees this value").

In considering the above, I recall your earlier https://github.com/dret/I-D/issues/24#issuecomment-180514421:

that's exactly the main goal of this structured discussion in the draft, and that's the thing that's often not done well in the current debates. for example, for the RFC 5988 link relation type registry [...]

I think the key ideas that need too be surfaced are: what can protocol designers do, when thinking about registry designs, to ensure their goals are not subverted by others who find the registration requirements too onerous? Having at most one way to do something is a key feature for aiding interoperability, which one hopes everyone buys into, and is one of the main purposes of registries.

Maybe some overview of our discussion, e.g. at https://github.com/dret/I-D/issues/24#issuecomment-187119129, would usefully be surfaced earlier in the document?

[gklyne]

Reflecting on my reflections...

I think the draft is a bit schizo about the specific use of IANA registries. There are many references to IANA registries, but much of the language in the spec (-02) seems to avoid being specific about IANA registries, while not really mentioning any alternatives. An example here would be the use of a public wiki as an alternative to an IANA registry.

[dret]

hello graham.

On 2016-03-10 15:00, gklyne wrote:

I believe there was a proposal to map registered registered link relations into URI space in a consistent fashion, but don't offhand recall where I saw it.

this pops up every couple months, usually because people working with RDF don't like the idea of identifying things with non-URI identifiers.

In the case of link relations, I think it /is/ possible to gracefully migrate between categories by retaining the previous use; e.g. a registered link relation could be documented as being equivalent to some URI used as link relation. It's not perfect, but not (IMO) as disruptive as your text seems to suggest, and not in the same league as the "X-" prefix problem.

this would be a breaking change, and you would introduce aliases by saying "use the string or the URIfied string, they mean the same thing". i would argue that having non-unique identifiers may be worse than any single unfortunate identifier scheme could ever be; but that's not a discussion we need to have here.

[dret]

going through your comments one by one...

On 2016-03-10 15:00, gklyne wrote:

6.8. Runtime vs. Design-Time

I'm not aware of any IANA registries that are intended to allow dynamic access. It feels to me like a "bad idea", because it potentially makes IANA a bottleneck in Internet operations, and I'm not sure they have the infrastructure resilience to support this.

i absolutely agree. but the point is that there is this conflation of "let's have registered well-known values" and the linked data notion of "using dereferencable HTTP URIs for everything, including what otherwise might live in a registry".

i fully agree that registries should be for documenting the identifiers that have been agreed on by whatever process the registry defines, and not for runtime access. but that's a slippery slope: you maybe want to have a "registry API" to be able to access the registry contents, but if people use this for runtime access, you may easily overwhelm the API's capacity.

I tentatively suggest that if there is an element of dynamic access, then this needs to be part of the related protocol spec rather than pushed onto a registry.

yes, that's what i think as well. however, that distinction is explicitly avoided in linked data, and i think at least it would be good to raise awareness about these differences, so that designers can consider when to use a registry and when to use a protocol.

[asbjornu]

@gklyne:

I believe there was a proposal to map registered registered link relations into URI space in a consistent fashion, but don't offhand recall where I saw it.

Yes, this already exists as defined in RFC 4287. It has also been heavily discussed in mnot/I-D#140.

[dret]

On 2016-03-10 10:00, gklyne wrote:

Catching up...

same here... ;-) and maybe we can do so in person later this week.

I think there's an important registry operation matter that you haven't touched on here: IANA have great administrative skills, but they cannot be expected to have technical knowledge of any particular protocol or system. So, if registration approval requires any kind of technical judgement, you end up being pretty much compelled to involve an expert review in the registration process.

absolutely agreed, but that's not part of operations, is it? i think that if there's no review process at all, then it's not quite sure why there's a registry to begin with. but registry operations simply revolve around how to make the whole thing work, and not who is contributing to it. do you see that differently?

[dret]

I think the draft is a bit schizo about the specific use of IANA registries. There are many references to IANA registries, but much of the language in the spec (-02) seems to be avoiding being specific about IANA registries, while not really mentioning any alternatives. An example here would be the use of a public wiki as an alternative to an IANA registry.

agreed that this (the ability to use non-IANA registries) needs to be in there. it just makes things a bit more complex (just looking at the IANA path):

• registry as a general namespace-management pattern
• IANA registry service as one way to implement that pattern
• one specific IANA registry for a specific registry requirement

[gklyne]

On 12/04/2016 14:04, Erik Wilde wrote:

On 2016-03-10 10:00, gklyne wrote:

Catching up...

same here... ;-) and maybe we can do so in person later this week.

I think there's an important registry operation matter that you haven't touched on here: IANA have great administrative skills, but they cannot be expected to have technical knowledge of any particular protocol or system. So, if registration approval requires any kind of technical judgement, you end up being pretty much compelled to involve an expert review in the registration process.

absolutely agreed, but that's not part of operations, is it? i think that if there's no review process at all, then it's not quite sure why there's a registry to begin with. but registry operations simply revolve around how to make the whole thing work, and not who is contributing to it. do you see that differently?

I'm a bit fuzzy on the context of this discussion (which isn't managed well by GitHub, IMO). But I think we covered some salient points when we mat F2F, i.e.

1. The initial mailing list review is not part of the formal IANA/IETF process, just a recommended good practice for any protocol design (i.e. many eyeballs...)

When a registration request is submited to IANA, then if the registry calls for expert review, IANA pass the request to the designated expert for comment.

1. So even if the formal process does not require review, it's generally a good thing (but not a requirement) to seek review. Even in the absence of review (formal or otherwise), the registry serves to manage namespace collisions (which might be managed by a wiki).

But if the namespace may contain reviewed and non-reviewed values (as is the case with the most recent URI registry specification), then the registry purpose of avoiding namespace collisions is not so easily handed off to a separate wiki-like mechanism.

g

[dret]

just wondering here, @gklyne: would that issue be addressed by talking about various "categories" of values that a registry might have? this could be associated with different levels of review/process and thus make it possible to have different "spaces" in one registry: they would share the same value space (the registered value), but have different policies associated with them in terms of what it takes to be accepted into the registry.

[gklyne]

That (.. various "categories" of values ..) is effectively what happens now for URI scheme registration: the requirement for provisional registration is first-come first-served, where the requirements for permanent are more stringent.

As the currently designated reviewer, I've requested that I'm notified by IANA about provisional registrations, but I have no formal role in determining their acceptance.

I think "that issue" you refer to is my comment about handing off to a wiki-like mechanism. That comment was made over a year ago now, and I'm not certain what was in my mind at the time. But it does seem to me that if the provisional entries are separated from the registry of reviewed permanent entries, then it's more work to ensure that collisions are avoided. I'm also not sure if wiki edit wars might ensue (e.g. if someone didn't recognize the priority of permanently registered schemes).

[dret]

On 2017-08-01 13:49, gklyne wrote:

That (.. various "categories" of values ..) is effectively what happens now for URI scheme registration: the requirement for provisional registration is first-come first-served, where the requirements for permanent are more stringent.

good, i think that's a useful aspect to add to the draft. i have created https://github.com/dret/I-D/issues/65 for this.

As the currently designated reviewer, I've requested that I'm notified by IANA about provisional registrations, but I have no formal role in determining their acceptance.

that's probably a useful and common pattern.

I think "that issue" you refer to is my comment about handing off to a wiki-like mechanism. That comment was made over a year ago now, and I'm not certain what was in my mind at the time. But it does seem to me that if the provisional entries are separated from the registry of reviewed permanent entries, then it's more work to ensure that collisions are avoided. I'm also not sure if wiki edit wars might ensue (e.g. if someone didn't recognize the priority of permanently registered schemes).

thanks for bearing with me. i am only getting back to the registry topic now, after i did let it sit quiet for a long time. i hope i'll be able to produce an updated version of the draft pretty soon. thanks for your feedback, it is very much appreciated!