Brian: 1. The GRASP specification of 4.1.1 should only describe what is required and valid for the standard of GRASP objective, which is the TCP proxy. Appendix C proxy option is not full/formally worked out, thats why its in an appendix. If the authors want to propose a formal GRASP option for appendix C proxy, then that should better go into appendix C as well. Rather a bit more duplicated text then confusing what objective details are used for what type of proxy.
Therefore only "IPPROTO_TCP" IMHO. Also nitpick: locator = [ O_IPv6_LOCATOR, ipv6-address, .. should be: locator-option = [ O_IPv6_LOCATOR, ipv6-address, .. (because prior definition of "flood-message" does say "locator-option"] 2. A value of IPPROTO_IPV6 which i guess would be desired for an appendix C proxy would IMHO be an extension to whats defined in GRASP. An RFC specifying that would therefore have to declare itself to be an update of GRASP. I don't think this is a big deal. It would become somewhat frustrating when we have to figure out multiple extensions to GRASP header options across multiple future RFCs. But the GRASP headers are not that complex, so there is not that much to do. A simple option could be to make a simple rev of GRASP RFC that accumulates all extensions - after a while, e.g.: after three RFCs that extend GRASP. Btw: The specific issue of extening transport options could have been avoided by permitting 0..255 in GRASP. Cheers Toerless On Thu, May 31, 2018 at 02:45:29PM +1200, Brian E Carpenter 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.) > > 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. > > Brian > > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima -- --- t...@cs.fau.de _______________________________________________ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima