Brian E Carpenter <brian.e.carpen...@gmail.com> 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 [ ] m...@sandelman.ca http://www.sandelman.ca/ | ruby on rails [
signature.asc
Description: PGP signature
_______________________________________________ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima