Subject: [Taps] Standardising Transport Property Names

From: "Philipp S. Tiesel" <[email-masked]>
Date: Fri, 1 Feb 2019 16:49:49 +0100

Hi,

during the January interim, we had some discussions regarding whether we want
to standardise strings for representing Transport Property Names and whether
we may need an IANA registry to keep track of these when new ones get added.

TL;DR
=====
In the interim, we roughly agreed that we need to add names for the Transport
Properties to the API draft. Also, we agreed that these property names can
be prefixed with a namespace to separate standard generic properties from protocol,
implementation, or vendor specific properties.

Before writing text for that, I volunteered to bring the conclusion from the
interim to the mailing list and ask for feedback.

The bloody details
==================

Transport Property Names
------------------------

Standardised Transport Property Names solve two purposes:
 - Allow different components of a TAPS implementation to pass Transport
   Properties, e.g., between a language frontend and a policy manager
 - Make code of different TAPS implementations look similar / familiar

My straw-man proposal to use camelCased strings got a lot criticism as it
discriminates non-camelCased languages. It seems that we need a canonical
string format that can be used across components of a TAPS system and can
be easily translated into strings, symbolic constants or static objects that
match the individual style of the programming APIs.

As a first proposal, I favour lower-case strings with underscores as word separators.

Namespaces
----------

Besides the categorisation into Selection, Connection, and Message Properties,
we also have different kinds of Transport Properties:
 - Generic Properties (most properties in the API draft fall in this case)
 - Protocol Specific Properties (e.g., properties to control certain TCP timers)
 - Vendor or Implementation Specific Properties

To allow a TAPS system to be extendable, we want to separate these out by
adding a namespace prefix to the Transport Properties.

As a first proposal, I favour the following
 - Generic properties from the API draft or defined by an RFC carry no
   namespace prefix.
 - Protocol Specific Properties must carry the protocol acronym as
   prefix, e.g., “tcp" for TCP specific Transport Properties.
   For IETF protocols, property names unter these namespaces should
   be defined in an RFC.
 - Vendors or implementation specific properties must prefix with the
   vendor or implementation’s name.
 - Experimental or local-use properties must be Prefixed with an X or Y.

Open Questions:
---------------

- Do we need an IANA registry for Generic Properties?

- Do we need an IANA registry for Property Namespaces?

- Do we need to request an IANA registry with the API document
  or may we postpone the above decisions?

- Where do we want to define the rules for naming Transport Properties and Namespaces?

AVE!
  Philipp S. Tiesel / phils…
--
   {phils}--->---([email-masked])--->---(http://phils.in-panik.de)----,
      wenn w eine   aube ist dn      man au dran dre en                   |
           o     Schr        an muss     hc         h   (Kurt Schwitters) |
:wq!  <----(phone: +49-179-6737439)---<---(jabber: [email-masked])----'

---

From: "Brian Trammell (IETF)" <[email-masked]>
Date: Wed, 20 Feb 2019 17:20:38 +0100

hi Philipp,

Thanks for pulling this together. I've finally had time to look at it.

> On 1 Feb 2019, at 16:49, Philipp S. Tiesel <[email-masked]> wrote:
> 
> Hi,
> 

This seems reasonable to me. Alternately we could party like it's 1982 and we can't afford an 80-column card and do UNDERSCORE_SEPARATED_UPPERCASE like the TCP RFCs do. 

(That's not a serious suggestion, but I note that it does make it very easy to see where the property names are when scanning the document, as long as we don't name a property RECOMMENDED.)

> Namespaces

So the namespace question only really becomes interesting if we presume we want to have a registry with other than Standards Action policy. But if we presume that...

Bikeshed question number 1: do we want to separate namespace prefixes with underscores as with spaces, or with some other character? i.e. to use a tortured example would it be something like tcp.retransmission_timeout or tcp_retransmission_timeout? (I'm borrowing from sysctl namespaces a little here)

> - Generic properties from the API draft or defined by an RFC carry no

This makes sense.

>   For IETF protocols, property names unter these namespaces should

This also makes sense.

>   vendor or implementation’s name.

Bikeshed question number 2: you probably need a registry of vendor namespaces. what's the policy on creating those? Do we really want to create another PEN-like thing?

> - Experimental or local-use properties must be Prefixed with an X or Y.

I don't like this. MIME headers used to use the X- prefix, but this has been deprecated because the presumptive semantic benefit of this -- you can see which bits are experimental -- disappears because nobody ever replaces experimental identifiers when experiments transition to production.

> Open Questions:

That depends on what we think the extension mechanism for the TAPS API is. I tend to think no: new extensions to the API will require a standards action, and probably even need to update the core TAPS API docs.

> - Do we need an IANA registry for Property Namespaces?

Maybe?

>  or may we postpone the above decisions?

I'm inclined to assign names (with generic and protocol-specific namespaces) and leave the whole vendor/registry thing as future work, because defining a registry well is hard, and I'm not sure such a thing will ever be used. It's a lot to do up front. 

> - Where do we want to define the rules for naming Transport Properties and Namespaces?

Consistent with my opinion above: name the transport namespaces in this doc, leave all other rules as future work.

Cheers,

Brian

> _______________________________________________
> Taps mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/taps

---

From: tom petch <[email-masked]>
Date: Wed, 20 Feb 2019 16:58:57 +0000

----- Original Message -----
From: "Brian Trammell (IETF)" <[email-masked]>
To: "Philipp S. Tiesel" <[email-masked]>
Cc: "taps WG" <[email-masked]>
Sent: Wednesday, February 20, 2019 4:20 PM

> This seems reasonable to me. Alternately we could party like it's 1982
and we can't afford an 80-column card and do
UNDERSCORE_SEPARATED_UPPERCASE like the TCP RFCs do.
>
> (That's not a serious suggestion, but I note that it does make it very
easy to see where the property names are when scanning the document, as
long as we don't name a property RECOMMENDED.)

or we could look forward to the 21st century and imagine that sometime
someone might want to do some sort of management of these entities and
make them YANG-compatible (hoping that YANG lasts that long!).

And a registry could be a YANG module ready to be imported by anyone who
wants to use the names.

And that is a serious suggestion.

Tom Petch

> So the namespace question only really becomes interesting if we
presume we want to have a registry with other than Standards Action
policy. But if we presume that...
>
> Bikeshed question number 1: do we want to separate namespace prefixes
with underscores as with spaces, or with some other character? i.e. to
use a tortured example would it be something like
tcp.retransmission_timeout or tcp_retransmission_timeout? (I'm borrowing
from sysctl namespaces a little here)
> Bikeshed question number 2: you probably need a registry of vendor
namespaces. what's the policy on creating those? Do we really want to
create another PEN-like thing?
> I don't like this. MIME headers used to use the X- prefix, but this
has been deprecated because the presumptive semantic benefit of this --
you can see which bits are experimental -- disappears because nobody
ever replaces experimental identifiers when experiments transition to
production.
> That depends on what we think the extension mechanism for the TAPS API
is. I tend to think no: new extensions to the API will require a
standards action, and probably even need to update the core TAPS API
docs.
> I'm inclined to assign names (with generic and protocol-specific
namespaces) and leave the whole vendor/registry thing as future work,
because defining a registry well is hard, and I'm not sure such a thing
will ever be used. It's a lot to do up front.
> Consistent with my opinion above: name the transport namespaces in
this doc, leave all other rules as future work.