Yaron Sheffer wrote:
> > - Section A.1 should say that the notation used for the example
> > ticket formats is intended to be pseudo-code, and does not specify
> > exact octet-by-octet format. (And probably things like
> > "reserved[3]" should be removed, since they don't really belong in
> > pseu
The original text in RFC 4306 was slightly confusing, but I think we
should leave room for ROHCoIPsec here. Perhaps adding something like
this after the bulleted list?
If the Child SA negotiation includes some future IPsec protocol(s)
in addition to (or instead of) ESP or AH (e.g., ROHC_INTE
pasi.ero...@nokia.com writes:
> - Section 5: Peer vendor IDs cannot be "implementation specific" -- if
> the old gateway sent Vendor ID "FOO", the client has to unambiguously
> know whether it's allowed to FOO vendor-specific payloads to the new
> gateway or not. Probably this should be "Not resume
I read through this document, and it seems to be mostly ok.
Only think that might require clarification is the section "11. IANA
Considerations".
It currently says that "A specification that extends this registry
MUST also mention which of the new values are valid in which
Notification payload.",
pasi.ero...@nokia.com writes:
> The original text in RFC 4306 was slightly confusing, but I think we
> should leave room for ROHCoIPsec here. Perhaps adding something like
> this after the bulleted list?
>
>If the Child SA negotiation includes some future IPsec protocol(s)
>in addition to
For most other features (e.g. whether peer supports MOBIKE or not),
the draft already says that the relevant payloads (e.g. MOBIKE_SUPPORTED)
are sent in the new exchange (instead of assuming everything has
remained the same).
IMHO the simplest alternative would be to use the same approach
for Ven
Looks good! Thank you.
BR,
Emre
On Mon, Aug 17, 2009 at 3:55 AM, wrote:
> The original text in RFC 4306 was slightly confusing, but I think we
> should leave room for ROHCoIPsec here. Perhaps adding something like
> this after the bulleted list?
>
> If the Child SA negotiation includes some
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the IP Security Maintenance and Extensions Working
Group of the IETF.
Title : Using Advanced Encryption Standard (AES) Counter Mode
with IKEv2
Author(s) :
Hi, IPSECME WG,
The 01 version of draft-ietf-ipsecme-aes-ctr-ike was uploaded. The
modification addressed comments we received so far and also include some
other editing.
Your comments will be appreciated.
Regard,
Sean
> A New Internet-Draft is available from the on-line
> Internet-Drafts dire
