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

Re: Last Call: IPSec DOI Proposed Standard

To: "Theodore Y. Ts'o" <tytso@MIT.EDU>
Subject: Re: Last Call: IPSec DOI Proposed Standard
From: "Derrell D. Piper" <ddp@network-alchemy.com>
Date: Thu, 23 Apr 1998 10:31:29 -0700
cc: Avram Shacham <shacham@cisco.com>, "'iesg@ns.ietf.org'" <iesg@ietf.org>, ipsec@tis.com, ippcp@external.cisco.com
In-reply-to: Your message of "Wed, 22 Apr 1998 22:37:16 EDT." <199804230237.WAA16620@dcl.MIT.EDU>
Sender: owner-ipsec@ex.tis.com

All,

The ISAKMP protocol defines the size of its Transform ID field as one octet.
The IPSEC DOI defines the legal values for this field when using IPSEC with
ISAKMP (as IPPCP does).  If IPPCP wants to use only six bits of the octet for
the compression transform identifier, that's fine, but it's still eight bits
on the wire in ISAKMP.  It can also be just six bits in the IPPCP protocol.

The current IPSEC DOI says that the values not defined in the IPSEC DOI are
reserved to IANA and that requests to IANA must be accompanied by a standards
track RFC, like IPPCP, that details the use of the requested allocation.

The only potential problem I see is that the IPSEC DOI does state that "the
values 249-255 are reserved for use private use amongst cooperating systems."
I will correct this in the next draft.

Derrell

References:

Re: Last Call: IPSec DOI Proposed Standard

From: "Theodore Y. Ts'o" <tytso@MIT.EDU>

Prev by Date: Re: Last Call: IPSec DOI Proposed Standard
Next by Date: Re: Last Call: IPSec DOI Proposed Standard
Prev by thread: Re: Last Call: IPSec DOI Proposed Standard
Next by thread: Re: Last Call: IPSec DOI Proposed Standard
Index(es):
- Main
- Thread