Hi Carsten,
----- Original Message ----- > From: Carsten Bormann <c...@tzi.org> > To: Mark Smith <markzzzsm...@yahoo.com.au> > Cc: "6low...@ietf.org" <6low...@ietf.org>; "r...@ietf.org" <r...@ietf.org>; > "ipv6@ietf.org List" <ipv6@ietf.org>; "core (c...@ietf.org)" <c...@ietf.org> > Sent: Saturday, 30 March 2013 8:25 AM > Subject: Re: GHC now crunches DTLS (Re: [Roll] [6lowpan] draft-bormann-ghc) > > On Mar 29, 2013, at 22:11, Mark Smith <markzzzsm...@yahoo.com.au> wrote: > >> RFC5175, "IPv6 Router Advertisement Flags Option" > > EFO was inspiration for 6CIO, but is different from 6CIO in that it is about > flags promulgated by a router (and therefore can only be used in an RA). > 6CIO is about the capabilities of the node sending that option. > That's why they are not the same thing. > > 6CIO is indeed meant to be general enough to carry other node capabilities > that > are relevant to a node-node situation. ROHC-over-802 could have used it. > That's why I'm proposing creating an IANA registry. to make the other 47 > bits available for other uses. > > I'm completely neutral to whether GHC's compression scheme and 6CIO > should be done in a combined draft or separate drafts. In the latter case, > stealing more text from 5175 is an obvious thing to do. > > Is there anything that could/should be generalized about 6CIO? > (Without making it more complex, please.) > The name is pretty much it - "IPv6 Neighbor Capability Flags Option" or similar would be better and more general. I mentioned RFC5175 because the processing rules in that probably would be the same for this option and therefore could be stolen. I think they would need to be specified somewhere that isn't 6LowPAN specific, which is why I suggested a different ID. Best regards, Mark. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
