Be more specific on namespace

[zaheduzzaman]

api-drafts/draft-ietf-taps-interface.md

Lines 551 to 553 in 9266fbe

	- Protocol Specific Properties MUST use the protocol acronym as the Namespace, e.g.,
	`tcp` for TCP specific Transport Properties. For IETF protocols, property
	names under these namespaces SHOULD be defined in an RFC.

are all the current protocols defined their Namespace in the respective RFCs? can we put a example reference? can we be more detailed on "SHOULD be defined in an RFC" actually mean?

[mwelzl]

My understanding is that this is meant as guidance for implementations, and for future RFCs to be written. If I write a TAPS system and provide a property that exists in QUIC only (and cannot reasonably be mapped to other protocols), then I should call it "quic.propertyname" - much like the TCP-specific properties in section 8.2. Similarly, future RFCs should define such namespaces if they offer properties that are protocol-specific.

It seems that this second sentence poses quite a burden on the IETF in general, and may not be realistic - will people follow this?

Suggested solution: remove the second sentence, and add a reference to section 8.2 to the first sentence to show an example.

[gorryfair]

I'm not sure removing the sentence is the right thing to do.
To me this is like the rules to add to a registry, and we should simply describe what they ought to do:

• what I thought was intended was that the IETF ought to publish the binding in a RFC that defines the thing with a property, or (if necessary) a separate RFC.

[mwelzl]

It sounded like a too broad demand to make - e.g., RFC 9000 should then have such stuff in it. What if we would phrase this more like, e.g.: "Future RFCs that extend Transport Service systems SHOULD define property names under these namespaces."

[gorryfair]

I don’t read the problem the same here… your text suggests a property name needs to be in the spec itself - which might be good — but is more than my proposal that said the property name for transport systems SHOULD be defined in the RFC series. Although we might decide to say both.
The potential problem as a WG Chair here is that there is no mechanism to remind or check that this is done. To me, it seems like if we had a registry, then we would have an IETF process to encourage ID authors to do the things in 4.1 and 4.2 of interface.

[mwelzl]

Ok, the phrase "SHOULD be in the RFC series" makes this leave the domain of my IETF knowledge - are we talking about an IANA registry here? Can we use a capital SHOULD as a request to IANA? Or what other form would that take? What would it mean to make such a SHOULD request to the IETF ("RFC series") as a whole?

Suggestion: I update my PR to not remove the sentence, merge the PR without closing this issue, and you propose text?