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 ---------------------------------------------------
- Unsupported DOI attributes and values Black_David
- Re: Unsupported DOI attributes and values Derrell D. Piper
- Unsupported DOI attributes and values Tero Kivinen
- RE: Unsupported DOI attributes and values Black_David