RE: Unsupported DOI attributes and values

Black_David@emc.com Wed, 29 September 1999 23:44 UTC

Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id QAA04647; Wed, 29 Sep 1999 16:44:22 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA00802 Wed, 29 Sep 1999 18:22:11 -0400 (EDT)
Message-ID: <729D927EF825D311961000E029101CCC258CD5@mxclsa>
From: Black_David@emc.com
To: kivinen@ssh.fi, Black_David@emc.com
Cc: ipsec@lists.tislabs.com
Subject: RE: Unsupported DOI attributes and values
Date: Wed, 29 Sep 1999 18:24:34 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk

> There is some text about that in my
> draft-ietf-ipsec-ike-ext-meth-02.txt saying (see the 12.1 first
> paragraph):

> [snip]

> 12.1.  Data Attributes, Protocol and Transform IDs
> 
> The proposal or transform payload MUST NOT be selected by the responder
> if it contains unknown protocol IDs, transform IDs, data attribute
> types, or data attribute values.
> 
> This means that an initiator SHOULD always include a proposal without
> any private-use types or values so that if the other end does not
> understand them then it may select the transform or proposal without
> private-use types or values.

I like that text - I'll put something approximating it into the ipsec-ecn
document
(we're dealing with a new IANA allocated attribute and its values)
and trust that Derrell will get RFC 2407 updated accordingly.

--David

---------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 42 South St., Hopkinton, MA  01748
+1 (508) 435-1000 x75140, FAX: +1 (508) 497-6909
black_david@emc.com
---------------------------------------------------