Thanks -- I've asked the secretariat to start the IETF Last Call!
Here are the first IETF Last Call comments (none of them major):
- The text about 8-octet alignment probably needs some small
clarifications. For IPv6, 8-octet alignment is not optional, so
SHOULD is not really correct. And
Nicolas Williams writes:
- Section 7, 1st paragraph: MOBIKE is mentioned without a reference.
- Section 7, 2nd paragraph: s/avare/aware/
- Section 8.1, next to last sentence: this sentence is grammatically
incorrect, I think. How about:
If the protocol (also known as the, next
On Sun, Oct 11, 2009 at 6:15 PM, Yoav Nir y...@checkpoint.com wrote:
Hi Hui
I think there is very little difference between IPv4 and IPv6 as regards to
IPsec. See below
On Oct 11, 2009, at 9:50 AM, Hui Deng wrote:
Dear IPsec forks,
May I get advice about the differnce between them:
1)
At 11:29 PM +0800 10/14/09, Zhen Cao wrote:
O...
IPv6 hosts, like IPv4 hosts, run Linux, BSD, Windows or some other OS. With
most of them, the latest versions support IPv6 for IKE and IPsec.
I guess we do not need tunnel model for IPv6 ipsec?
what makes you say that? unnelT mode is still
I would also add a few cents.
At 11:29 PM +0800 10/14/09, Zhen Cao wrote:
O...
IPv6 hosts, like IPv4 hosts, run Linux, BSD, Windows or some other
OS. With
most of them, the latest versions support IPv6 for IKE and IPsec.
I guess we do not need tunnel model for IPv6 ipsec?
what makes
On Wed, Oct 14, 2009 at 02:36:20PM +0300, Tero Kivinen wrote:
Nicolas Williams writes:
- Section 8.3, 1st paragraph, 2nd sentence: this sentence is
grammatically incorrect, and I'm unsure as to what is meant.
This was commented already by others and was changed to:
For example,
I would also add a few cents.
At 11:29 PM +0800 10/14/09, Zhen Cao wrote:
O...
IPv6 hosts, like IPv4 hosts, run Linux, BSD, Windows or some other
OS. With
most of them, the latest versions support IPv6 for IKE and IPsec.
I guess we do not need tunnel model for IPv6 ipsec?
what makes you
Tero Wrote:
RFC4718 is informational and tried to clarify things which are not
clear in RFC4306. Now we are writing standard track document when
revising RFC4306 and in that case we can even change things specified
in RFC4306, if needed. In this case I do not think we need to change
things
