Wrapped Encapsulating Security Payload (ESP) for Traffic Visibility
RFC 5840

Note: This ballot was opened for revision 12 and is now closed.

(Pasi Eronen) Yes

(Jari Arkko) (was Discuss) No Objection

Comment (2009-12-17)
No email
send info
By the way, I agree with Russ' Discuss.

(Ralph Droms) No Objection

(Lisa Dusseault) No Objection

(Lars Eggert) No Objection

(Adrian Farrel) No Objection

(Russ Housley) (was Discuss) No Objection

Alexey Melnikov No Objection

Comment (2009-12-13 for -)
No email
send info
4. IANA Considerations 

   The USE_WESP_MODE notification number is assigned out of the 
   "IKEv2 Notify Message Types - Status Types" registry's 16384-
   40959 (Expert Review) range: TBD. 

I assume the Expert Reviewer Okeyed this registration already?

(Tim Polk) (was No Record, Discuss) No Objection

Comment (2009-12-16)
No email
send info
(1) The abstract states "there is no way to differentiate between encrypted and unencrypted
payloads", but section 1.2 notes that this differentiation can be achieved using heuristics.
This seems to be in conflict.

(2) In section 1.2, the text preceding the list states "there are two ways ... to distinguish
between encrypted and unencrypted ESP traffic".  Something tells me there are other
possibilities.

(3) section 2, paragraph beginning "Padding Present (P), 1 bit".  The following text is about 
the padding field rather than the flag.  I think both are needed, and suggest moving the 
padding text to follow the discussion of the reserved bits.

(4) a description of how the padding field will be used for extensibility, and any limitations
on the use of that field, should be documented here.

(5)  Section 2, next to last paragraph: is it really optional to extend the standard ESP header
by 8 octets for IPv6?   

(6) Security considerations, paragraph 1:
s/should be used to in determining/should be used in determining/

(Dan Romascanu) (was Discuss) No Objection

(Robert Sparks) No Objection

Magnus Westerlund Abstain

Comment (2009-12-17 for -)
No email
send info
I am entering an abstain position on this due to that it doesn't appear to be a well enough motivated usage of an protocol number. The protocol number space is quite limited and this is basically a duplication of the ESP one. Yes, it attempts to provide some additional functionality. 

Due to the expressed limited support and lack of implementation I would have no problem if this proposal skipped requesting an protocol ID of itself and instead always relied on the UDP encapsulation. That way it only consume one code point from a IPsec specific range, that also is almost not utilized at all today.