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
