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
pseudo-code
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 resumed,
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.,
Looks good! Thank you.
BR,
Emre
On Mon, Aug 17, 2009 at 3:55 AM, pasi.ero...@nokia.com 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
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
