Brian E Carpenter <[email protected]> wrote: > On 31/05/2018 13:53, Toerless Eckert wrote: > ... >> 4.1.1: >> >>> transport-proto = IPPROTO_TCP / IPPROTO_UDP / IPPROTO_IPV6 >> >> The way i see it, the normative approach with TCP circuit proxy would >> always only have TCP, right, e.g.: the line should say >> >> transport-proto = IPPROTO_TCP ; Not considering non-normative >> ; options like Appendix C.
> There's kind of a general point about extensibility here.
> We're using CDDL as a normative notation (which may well become
> slightly awkward unless the CDDL draft advances soon), but are
> we intending to interpret it formally?
> In other words,
> if we later want to add " / IPPROTO_UDP / IPPROTO_IPV6"
> to implementations, do we have to circle back and update the BRSKI
> RFC? (And so on for any other documents that cite intrinsically
> extensible items like transport-proto.)
I don't mind saying that only IPPROTO_TCP is normative in the CDDL,
but I think that the point of listing a few options here is so that
implementations actually check the value.
> One option in this case is to include "/ IPPROTO_UDP / IPPROTO_IPV6"
> in the syntax with a specific note that they are not currently
> defined and MUST be treated as errors if received.
I prefer this to the not listing them.
--
] Never tell me the odds! | ipv6 mesh networks [
] Michael Richardson, Sandelman Software Works | network architect [
] [email protected] http://www.sandelman.ca/ | ruby on rails [
signature.asc
Description: PGP signature
_______________________________________________ Anima mailing list [email protected] https://www.ietf.org/mailman/listinfo/anima
