[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: FW: private use ISAKMP attributes




--- On Mon, 21 Jul 1997 17:10:41 -0400  "Edward A. Russell" <erussell@ftp.com> wrote:

>  Of course with private attribute types, there can be conflict between two vendors
>  who pick the same number for different things (hint: don't pick the first number in
>  the private range).  We need to be able to register  a standard Private Scheme 
>  Attribute Class or something.

In historic IETF practice, there are usually two magic number spaces:
	- one that is standardised (or registered with IANA following some
		IETF process) and intended to be interoperable across
		multiple independent implementations
	- one that is for "private use among consenting parties" that is
		understood NOT to be interoperable but provides the ability
		to have proprietary or private-community extensions that
		are not appropriate for either standardisation OR for
		registration with IANA via some IETF process.

SNMP has a third kind of number space, which is proprietary but allocated
uniquely to a particular vendor.  ISAKMP does not currently have that kind
of number space (some of us don't view this as a problem).

In the above context, I don't follow what "register a standard Private Scheme..."
means for ISAKMP.

In particular, its probably helpful for folks to identify now any KM attributes 
that they know they need but aren't currently documented.  That way the 
group as a whole can have a chance to consider whether those ought to be
standardised (even if they might be optional to implement).  All IMHO.

>  Ultimately, it is left up to the user or administrator to configure proposals 
>  for specific systems knowing ahead of time which use the private schemes and 
>  which are strictly standard.

It seems like a matter of local security policy to me.  I imagine that each
vendor will have their own method of specifying policy.  If a vendor doesn't
have some method for a local sysadmin to specify local policy, that vendor
might be at a competitive disadvantage relative to other vendors.  So goes
capitalism.

Later,

Ran
rja@inet.org



References: