----- Original Message ----- From: "Brian Trammell (IETF)" <[email protected]> To: "Philipp S. Tiesel" <[email protected]> Cc: "taps WG" <[email protected]> Sent: Wednesday, February 20, 2019 4:20 PM
> 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 protected]> wrote: > > > > 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. > > 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 > > 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. > > 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) > > > > As a first proposal, I favour the following > > - Generic properties from the API draft or defined by an RFC carry no > > namespace prefix. > > This makes sense. > > > - 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. > > This also makes sense. > > > - Vendors or implementation specific properties must prefix with the > > 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: > > --------------- > > > > - Do we need an IANA registry for Generic Properties? > > 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? > > > - Do we need to request an IANA registry with the API document > > 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 > > > > > AVE! > > Philipp S. Tiesel / phils… > > -- > > {phils}--->---([email protected])--->---(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 protected])----' > > > > _______________________________________________ > > Taps mailing list > > [email protected] > > https://www.ietf.org/mailman/listinfo/taps > > _______________________________________________ > Taps mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/taps > _______________________________________________ Taps mailing list [email protected] https://www.ietf.org/mailman/listinfo/taps
