Subject: [Taps] To registry, or not to registry?

From: Tommy Pauly <[email-masked]>
Date: Mon, 23 Jul 2018 13:15:53 -0700

Hello TAPS,

Migrating a thread from GitHub to the email list, since it needs broad WG input. I've pasted the discussion so far below.

Essentially, the question is if we have a set of standard properties for Transport Services APIs, should they have a formal registry or not?

Thanks,
Tommy

======================================

https://github.com/taps-api/drafts/issues/210

Philipp:

We will end up with a set Turns out we might need a lot of (protocol) specific properties, we should discuss whether we need an IANA registry of properties and how this will look like.
	• Include Types ?
	• Include Names ?
	• Some numeric representation ?
What do we do with ENUM values?

Mirja:
I don't really understand why we would need a registry. Who would be using the registry?

Tommy:
I agree that a registry seems unnecessary; this is not a matter of protocol or on-the-wire standard.

Philipp:
If we don't want to clutter the basic API document, we will end up having at least a half a dozen documents defining specific properties for different protocols.
Does anyone have a good alternative to collect all these except in an IANA registry?

Tommy:
We do not need to have documents specify every property. Implementation should be allowed to extend as they need.

Brian:
this discussion does suggest that we might want to be more explicit up front in the interface document about the scope and purpose of the document (i.e. this is meant primarily to define a standard API "shape", not the particular strings and codepoints, etc.). I'll file an issue.

Colin:
I agree with @tfpauly that we don't need to document every property, and with @britram that we're documenting the shape of an abstract API, but I also see value in consistent property naming across concrete implementations of that API. Some form of registry might make sense here.

---

From: David Schinazi <[email-masked]>
Date: Mon, 23 Jul 2018 13:32:52 -0700

We had a similar discussion in the Babel WG regarding link types in our data model - which isn't sent over the wire.
We landed on having an IANA registry of strings so there is one place to find the mapping from string to specification.
We're planning on reserving all strings starting with an underscore "_" for experimental use so the registry does not get in anyone's way.
Apparently IANA registries have very low overhead.
Hope this helps.

David

> On Jul 23, 2018, at 13:15, Tommy Pauly <[email-masked]> wrote:
> 
> Hello TAPS,
> 
> https://github.com/taps-api/drafts/issues/210 <https://github.com/taps-api/drafts/issues/210>
> 
> Philipp:
> 
> _______________________________________________
> Taps mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/taps

---

From: John Grant <[email-masked]>
Date: Tue, 24 Jul 2018 10:23:39 +0100

On 23/07/2018 21:15, Tommy Pauly wrote:
> Hello TAPS,
>
> Migrating a thread from GitHub to the email list, since it needs broad 
> WG input. I've pasted the discussion so far below.
>
> Essentially, the question is if we have a set of standard properties 
> for Transport Services APIs, should they have a formal registry or not?
Maybe call it an ontology, as in metadata libraries, rather than a registry.

The API is an interface between the application and the network, so it 
needs to provide an abstraction of the service the network provides that 
can be understood by each side without having to know too much about how 
the other side is implemented. There's been some debate about that in 
the DetNet group recently, too. Anyway, the API should allow the 
application to specify byte stream or packet, constant bit rate or 
bursty, latency requirements, tolerance of packet loss or corruption, 
etc, but not ask it to select a particular protocol such as TCP. 
Similarly, it should provide more abstract ways for the application to 
say what it wants to talk to, e.g. specify a URL directly rather than 
having to make a separate call of gethostbyname().

Of course, it should also provide a way for an application to request 
features that are specific to a particular network technology, but 
recognise that doing so compromises portability of the application.

-- 
John Grant
Nine Tiles, Cambridge, England
+44 1223 862599 and +44 1223 511455
http://www.ninetiles.com

---

From: G Fairhurst <[email-masked]>
Date: Tue, 24 Jul 2018 14:52:33 +0100

On 24/07/2018, 10:23, John Grant wrote:
>> Migrating a thread from GitHub to the email list, since it needs 
>> broad WG input. I've pasted the discussion so far below.
>>
> needs to provide an abstraction of the service the network provides 
> that can be understood by each side without having to know too much 
> about how the other side is implemented. There's been some debate 
> about that in the DetNet group recently, too. Anyway, the API should 
> allow the application to specify byte stream or packet, constant bit 
> rate or bursty, latency requirements, tolerance of packet loss or 
> corruption, etc, but not ask it to select a particular protocol such 
> as TCP. Similarly, it should provide more abstract ways for the 
> application to say what it wants to talk to, e.g. specify a URL 
> directly rather than having to make a separate call of gethostbyname().
>
John, I think if you take a look at the TAPS WG drafts, you'll now find 
that much of what you hope exists in the current work.

I think the discussion of byte stream v. packet may be at a lower level 
that we now envisage in TAPS, but as the TAPS work moves forward I 
expect you'll find anything that was possible in a byte or packet stream 
will also be possible via the higher-level API. In most cases, we have 
also found the new abstraction to be also much simpler for developers to 
code against. Do let us know if you have further comments on the WG drafts.

Gorry

---

From: G Fairhurst <[email-masked]>
Date: Tue, 24 Jul 2018 15:06:58 +0100

I don't yet know for sure myself....

On the one hand: I think a registry is a great way to capture the 
"bundle" of things that we know about needing to send across the API. 
Having common keywords (names) is a way to help people (who wish to take 
this approach) from unwantingly choosing the same function/param with a 
different name. And avoids accidentally choosing the same key. I like 
these advantages. especially if I thought people would use the registry.

On the other hand, as an author I am still bemused about exactly which 
list of items I think /need/ could appear in this registry. I know some 
I'd expect, there are some I would not be surprised to see, and some I'd 
expect not to see. Also this doesn't stop people dreaming of slight 
variants of functions/params because they want to be different or don't 
understand/agree with another definition, especially since the concrete 
API isn't specified by the IETF.

There are ways we could help support different uses, which I think we 
should consider:
* We can define "well-known" IETF keywords that start with a special 
prefix that require some IETF practice to assign;
* we can also define "public" keywords that have no prefix and are 
first-come-first served, the easy way to get a unique entery.
* We can allow private defintions with some different prefix that are 
not specified by IANA. (We simply preclude this format from the registry).

This approach has been used in many places, a simple, but similar 
transport example is the Service Codes registry:
https://www.iana.org/assignments/service-codes/service-codes.xhtml

- Let's all think about whether this is a useful approach for our API?

Gorry

On 23/07/2018, 21:32, David Schinazi wrote:
> We had a similar discussion in the Babel WG regarding link types in 
> our data model - which isn't sent over the wire.
> We landed on having an IANA registry of strings so there is one place 
> to find the mapping from string to specification.
> We're planning on reserving all strings starting with an underscore 
> "_" for experimental use so the registry does not get in anyone's way.
>> On Jul 23, 2018, at 13:15, Tommy Pauly <[email-masked] 
>> <mailto:[email-masked]>> wrote:
>>
>> Hello TAPS,
>>
>>     We will end up with a set Turns out we might need a lot of
>>     (protocol) specific properties, we should discuss whether we need
>>     an IANA registry of properties and how this will look like.
>>     • Include Types ?
>>     • Include Names ?
>>     If we don't want to clutter the basic API document, we will end
>>     up having at least a half a dozen documents defining specific
>>     properties for different protocols.
>>     We do not need to have documents specify every property.
>>     Implementation should be allowed to extend as they need.
>>
>> Brian:
>>
>>     this discussion does suggest that we might want to be more
>>     explicit up front in the interface document about the scope and
>>     purpose of the document (i.e. this is meant primarily to define a
>>     standard API "shape", not the particular strings and codepoints,
>>     etc.). I'll file an issue.
>>
>> Colin:
>>
>>     I agree with @tfpauly that we don't need to document every
>>     property, and with @britram that we're documenting the shape of
>>     an abstract API, but I also see value in consistent property
>>     naming across concrete implementations of that API. Some form of
>>     registry might make sense here.
>>
>> [email-masked] <mailto:[email-masked]>

---

From: "Aaron Falk" <[email-masked]>
Date: Tue, 24 Jul 2018 14:13:59 -0400

Caveat: I am not an expert on registries but my sense is that they are 
most useful for interoperability.  I think Gorry's concern about 
redundancy much less important.  And, in fact, it may take a while to 
figure out how to describe the parameters.  It might be more useful to 
allow for variety in how these are defined to permit creative 
approaches.  YMMV of course.

--aaron

On 24 Jul 2018, at 10:06, G Fairhurst wrote:

> Having common keywords (names) is a way to help people (who wish to 
> take this approach) from unwantingly choosing the same function/param 
> with a different name. And avoids accidentally choosing the same key. 
> I like these advantages. especially if I thought people would use the 
> registry.
>
> list of items I think /need/ could appear in this registry. I know 
> some I'd expect, there are some I would not be surprised to see, and 
> some I'd expect not to see. Also this doesn't stop people dreaming of 
> slight variants of functions/params because they want to be different 
> or don't understand/agree with another definition, especially since 
> the concrete API isn't specified by the IETF.
>
>>>     I don't really understand why we would need a registry. Who 
>>> would
>>>     be using the registry?
>>>
>>> Tommy:
>>>