At 11:04 AM +0200 12/10/09, Yaron Sheffer wrote:
>This is to begin a 4 week working group last call for
>draft-ietf-ipsecme-ikev2bis-06. The target status for this document is
>Proposed Standard, obsoleting RFC 4306 and RFC 4718.
>
>Please send your comments to the ipsec list by Jan. 5, 2010, as
David Wierbowski writes:
> Comment # 2:
>
> Section 1.7 (Differences Between RFC 4306 and This Document) states:
>
>The protocol described in this document retains the same major
>version number (2) and minor version number (0) as was used in RFC
>4306. That is, the version number is
At 3:31 PM -0500 12/16/09, David Wierbowski wrote:
>I haven't matched Scott's efforts, but I do have some comments:
Many thanks!
>Comment #1:
>
>Section 1.2 (The Initial Exchanges) has the following sentence, which was
>also in RFC 4306.
>
> Payloads that may optionally appear will be shown in
Date: 12/15/2009 12:28 PM
Subject:Re: [IPsec] Working Group LC: draft-ietf-ipsecme-ikev2bis-06
(yes, IKEv2-bis!)
not encrypted.
Scott Moonen (smoo...@us.ibm.com)
z/OS Communications Server TCP/IP Development
http://www.linkedin.com/in/smoonen
From:
Tero Kivinen
To:
Scott C Moonen/Raleigh/i...@ibmus
Cc:
Yaron Sheffer , "ipsec@ietf.org"
Date:
12/16/2009 05:09 AM
Subject:
Re: [IPsec] Working Group L
Scott C Moonen writes:
> 7) Section 3.14, "The Encrypted Payload, if present in a message, MUST be
> the last payload in the message. Often, it is the only payload in the
> message." Out of curiosity, do we know of any cases where this payload is
> not the only payload in the message? It stri
At 11:53 AM -0500 12/15/09, Scott C Moonen wrote:
>1) There are excessive spaces on the second lines of these list items in
>section 2.23:
Fixed.
>2) In section 3.3, this sentence: "If an algorithm that combines encryption
>and integrity protection is proposed, it MUST be proposed as an encrypt
At 11:53 AM -0500 12/15/09, Scott C Moonen wrote:
>I've finished my read through the draft.
Many thanks for the careful review. So, who wants to match or exceed Scott's
efforts? We need more eyes on this version of the document before it is ready
for IETF Last Call.
--Paul Hoffman, Director
-
INFORMATIONAL request contained a Delete payload for a Child
SA?
9) Appendix D -- we need to fill this in.
Scott Moonen (smoo...@us.ibm.com)
z/OS Communications Server TCP/IP Development
http://www.linkedin.com/in/smoonen
From:
Yaron Sheffer
To:
"ipsec@ietf.org"
Date:
12/10/2009 0
At 2:49 PM +0200 12/14/09, Tero Kivinen wrote:
>BTW, I think that change is one of the significant changes we should
>list in the RFC4306, i.e. following the payload order of the figures
>in section 2 is no longer MUST, it is now SHOULD (and applies to
>figures in section 1 too).
Quite right. I re
Hello all,
A minor technical note about Issue #22. Section 2.25, last paragraph reads:
A CHILD_SA_NOT_FOUND notification SHOULD be sent when a peer receives a
request to rekey a Child SA that does not exist. A peer that receives a
CHILD_SA_NOT_FOUND notification SHOULD silently delete the Child
Paul Hoffman writes:
> At 10:55 AM +0900 12/14/09, Toshihiko Tamura wrote:
> >Hi, I want to check one point.
> >At the last paragraph in Section 2.5, there is a mention of refering
> >the figures in Section 2.
> >Does it mean we should refer all fighres in Section 2?
> >Or does it mistake section 2
At 10:55 AM +0900 12/14/09, Toshihiko Tamura wrote:
>Hi, I want to check one point.
>At the last paragraph in Section 2.5, there is a mention of refering
>the figures in Section 2.
>Does it mean we should refer all fighres in Section 2?
>Or does it mistake section 2 for section 1?
Good catch. It s
Hi, I want to check one point.
At the last paragraph in Section 2.5, there is a mention of refering
the figures in Section 2.
Does it mean we should refer all fighres in Section 2?
Or does it mistake section 2 for section 1?
-
2.5. Version Numbers and Forward Compatibility
/snip/
Alth
>Section 1.2, paragraph 2 -- "the identities are hidden from eavesdroppers".
>Is it worth noting that a man-in-the-middle could intrusively discover the
>initiator's identity?
Added: (A man-in-the-middle who cannot complete the IKE_AUTH exchange can
nonetheless see the identity of the initiato
d to remember to remove the "NOTE FOR WG
DISCUSSION".
Scott Moonen (smoo...@us.ibm.com)
z/OS Communications Server TCP/IP Development
http://www.linkedin.com/in/smoonen
From:
Yaron Sheffer
To:
"ipsec@ietf.org"
Date:
12/10/2009 04:05 AM
Subject:
[IPsec] Working Group LC: d
This is to begin a 4 week working group last call for
draft-ietf-ipsecme-ikev2bis-06. The target status for this document is Proposed
Standard, obsoleting RFC 4306 and RFC 4718.
Please send your comments to the ipsec list by Jan. 5, 2010, as follow-ups to
this message.
This is a large document
17 matches
Mail list logo
