Date: Tue, 8 Feb 2000 04:53:22 -0800 (PST) From: Abraham Shacham To: ippcp@external.cisco.com cc: ipsec@lists.tislabs.com Subject: Re: I-D ACTION:draft-shacham-ippcp-rfc2393bis-04.txt The draft reflects the discussions in the VPN bakeoff in San Diego last month. The content changes are in section 4.1. Use of IKE, as the attached diff provides. avram 347,370c347,356 < Identifiers. < < The following attributes are applicable to IPComp proposals: < < Encapsulation Mode < < To suggest a non-default Encapsulation Mode (such as Tunnel < Mode), an IPComp proposal MUST include an Encapsulation Mode < attribute. If the Encapsulation Mode is unspecified, the < default value of Transport Mode is assumed. < < Lifetime < < An IPComp proposal uses the Life Duration and Life Type < attributes to suggest life duration to the IPCA. < < When IPComp is negotiated as part of a Protection Suite, all the < logically related offers must be consistent. However, an IPComp < proposal SHOULD NOT include attributes that are not applicable to < IPComp. An IPComp proposal MUST NOT be rejected because it does not < include attributes of other protocols in the Protection Suite that < are not relevant to IPComp. When an IPComp proposal includes such < attributes, those attributes MUST be ignored when setting the IPCA, < and therefore ignored in the operation of IPComp. --- > Identifiers. To suggest a non-default Encapsulation Mode (such as > Tunnel Mode), an IPComp proposal MUST include an Encapsulation Mode > attribute. If the Encapsulation Mode is unspecified, the default > value of Transport Mode is assumed. When IPComp is negotiated as > part of a Protection Suite, and when the negotiation protocol > requires that all the logically related offers must be consistent, > the IPComp proposals MUST include all the attributes of every > transform being negotiated, but those attributes not relevant to > IPComp MUST be ignored when setting the IPCA and therefore ignored in > the operation of IPComp.