Hello and thanks for review!
I believe the comments look reasonable, and most of them should be
addressed easily. Two comments below, the first for my fellow co-authors
and the second as a general comment to you and to Mohan.
On Sun, 10 Dec 2006, Fred Baker wrote:
On Dec 9, 2006, at 5:55 PM, [EMAIL PROTECTED] wrote:
Section 4 has some wording problems:
1. [RFC2401] does not allow IP as the next layer protocol in traffic
selectors when an IPsec SA is negotiated. [RFC4301] also allows
IP as the next layer protocol (like TCP or UDP) in traffic
selectors.
The "also" is susceptible to misreading. The second sentence should
be rephrased to: "In contrast, [RFC4301] does allow ..."
Mohan or Richard, could you clarify this? I thought the idea was that
RFC2401 does not explicitly mention IP as the possible next layer
protocol, while many implementations do support it (and we aren't quite
sure whether such support is mandatory-to-implement)? On the other hand
RFC4301 explicitly requires support for all next layer protocol values.
Maybe we forgot to to reword the text above since this become clearer
after earlier iterations. If so, suggestions to reword?
The three requirements in Section 5.2 are generally applicable,
and should not be buried in Section 5.2's discussion of IPsec
tunnel mode. The requirements also lack explanations of why
they are requirements. At a minimum, the statement of the
requirements should be moved into Section 5 (before 5.1), but
I would suggest moving them to the end of Section 3 and adding
a discussion of why these requirements are important (e.g., what
goes wrong if they're not met) with reference to the scenarios
described in Section 3.
We could easily shuffle the text around a bit. Now that I read this, only
the first one seems to be clearly worded as a "requirement" rather than a
general observation. While the third one needs clarification (Mohan?),
only the first one (IMHO) can easily be expanded why that is so:
1. All of IPv6 traffic should be protected, including link-local
(e.g., Neighbor Discovery) and multicast traffic.
2. In router-to-router tunnels, the source and destination addresses
of the traffic could come from a wide range of prefixes that are
normally learned through routing. As routing can always learn a
new prefix, there is no way to know all the prefixes a priori
[RFC3884].
3. Source address selection depends on the notions of routes and
interfaces. This affects scenarios (2) and (3).
1) is required so that every form of traffic that is supported by RFC4213
IPv6-in-IPv4 tunnels is supported. A more general explanation is
mentioned in 2nd paragraph of Section 6 (in effect, "we want link local,
e.g., routing protocols, multicast, etc.") but it doesn't mention why we
want them (explanation above). On the other hand Appendix A describes the
tunnel mode setup if this is not felt to be a requirement and Tunnel mode
is felt better in the particular scenario.
As for 3), I'm not 100% sure what point it wants to convey and how it's
relevant here (does that refer to a multihomed endpoint with multiple
addresses?) Mohan?
Pekka
_______________________________________________
Gen-art mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/gen-art
