>> >> I'm puzzled by the choice of acronym. GRE refers to RFC2784 which has its >> own encapsulation header format. >> >> => I know, it's the same GRE. People wanted to put GRE encapsulation in this >> specification. > > Well in that case there needs to be a reference to RFC2784 and perhaps > RFC2890. I'm quite confused, because there is nothing in the text that > refers to GRE encapsulation - the only specific encapsulation mentioned > is RFC2473 and RFC4213, and neither of those use GRE as far as I know. > You can't use the same TLV to indicate both GRE and non-GRE encapsulations.
=> Ok, I'll add the reference and explain it's the same thing. You can use the TLV-format for tunnel either GRE or IP based on the values allocated (0 and 1). > >> >>> To accommodate traffic that uses Explicit Congestion Notification >>> (ECN), it is RECOMMENDED that the ECN information is copied between >>> the inner and outer header as defined in [RFC3168]. >> >> >> >> OK, but why not also suggest that the DSCP be copied, as defined in >> RFC2983 (which is Informational)? >> >> => Ok, but I'll use 4213, which obsoletes 2983. > > Wrong! It obsoletes 2893. Very confusing... => Yes of course you're right, sorry for the dyslexia >> How does the mobile know that it's in an IPv4-only network? (Also, there's >> a missing verb in that sentence.) >> >> => Ok about the verb. The mobile node knows because it didn't receive any >> IPv6 information from the router, i.e. Router advertisements. > > I think you should say a few words about that (i.e. that you assume that > the stack provides a status indicator of some kind for this, since this > is not a part of MIP6 itself). => Ok, will add this. Thanks for all your comments. Hesham > > Brian _______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
