Hi Thomas, Bob, Thanks for the discussion.
The specific application that needs (well, to be precise, would greatly benefit) RAO is NSIS. That is why NSIS ML is CC:d. Moreover, the RSVP spec talks about multiple RAO values, but lets it open as to whether IPv4 should also have those, not just IPv6. RFC2113 also says that "The semantics of other values in the Value field are for further study." The point is, is it time to study those "other values" further? At least GIST and the whole NSIS framework would greatly benefit from more values than just "0" for IPv4, and these values should be the same for IPv6 also, for simplified implementations. There is a lot of discussions about RAO in the GIST spec, e.g., Sections 4.3.1., 4.3.4., 5.3.2.1., 5.3.2.2., 6. IANA Considerations and Appendix C: http://tools.ietf.org/wg/nsis/draft-ietf-nsis-ntlp/ Regards, Jukka On Wed, 24 Oct 2007, Thomas Narten wrote: > Bob Hinden and I had some further offlist discussion about this. > > My understanding is that the IPv4 RA option is very basic. It says > "look at this packet". The option itself doesn't contain any > additional information or "hint" as to what to look for or what the > packet contains. > > The semantics of the IPv6 router alert option are different. The value > itself is used to convey additional "hints" about processing. > > My sense is that the semantics of the IPv4 and IPv6 Router Alert > option are sufficiently different that sharing the name space just > doesn't make any sense. > > That is, the ID says: > > This document proposes the creation of a new IANA registry for > managing IPv4 Router Alert Option Values. In conjunction with > this, it also proposes an update to the way in which IPv6 Router > Alert Option Values are assigned in the existing IANA registry. > > But there are no defined IPv4 Router Alert Option values (other than > zero), and it would be inappropriate to change the semantics of any > existing usages (too late for that) and it would also be inappropriate > to consider doing this in the absense of a specific new application > that would make use of a new value. This document does not propose > such a new usage. > > Hence, at this point, I'm opposed to the actions called for in the > document. > > Thomas > _______________________________________________ Int-area mailing list [email protected] https://www1.ietf.org/mailman/listinfo/int-area
