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

No Subject



[192.94.214.100])
	by portal.ex.tis.com (8.9.1/8.9.1) with ESMTP id MAA24704
	for <ipsec@ex.tis.com>; Tue, 3 Nov 1998 12:56:44 -0500 (EST)
(4.1)
	id xma006520; Tue, 3 Nov 98 13:20:19 -0500
(dhcp200.local.windrose.omaha.ne.us [10.9.200.200])
	by privateer.windrose.omaha.ne.us (8.8.7/8.8.7) with SMTP id MAA26702;
	Tue, 3 Nov 1998 12:17:05 -0600 (CST)
From: "Ryan Moats" <jayhawk@att.com>
To: <ipsec@tis.com>
Cc: <partha@watson.ibm.com>, <radams@cisco.com>, <rpereira@timestep.com>,
        <wdixon@microsoft.com>, <raju@watson.ibm.com>
Subject: Comments on  draft-ietf-ipsec-vpn-policy-schema-00
Date: Tue, 3 Nov 1998 12:14:09 -0600
Message-ID: <001201be0755$c050fbe0$c8c8090a@sloop.local.windrose.omaha.ne.us>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4
Sender: owner-ipsec@portal.ex.tis.com
Precedence: bulk


In reading draft-ietf-ipsec-vpn-policy-schema-00, several questions for
clarification need to be asked.  While most of these are editorial in
nature, one is technical.

In RFC 2247, the "dc" component is introduced as a potential RDN.  In RFC
2377, this concept is extended by introducing the "uid" component as a
potential RDN.  By requiring [MUST] "CommonName" as the RDN for all objects
in this schema, you preclude anyone from building a naming plan based on
"dc" and "uid". Rather, CommonName, DomainComponent, and UniqueIdentifier
should all be optional [MAY].  This allows directory implementors more
flexibility in setting up their naming plans.

In addition to this, it would also be useful if PolicyContainmentAuxClass
also included the Domain class in the list of potential parents.

Now for the editorial comments:

While implicitly stated, an explicit statement that the PoliciesContainedRef
attribute of the PolicyContainmentAuxClass points to Policy class objects
would be more clear.

In class IPPolicyCondition, is the attribute name HostUserIDRef (page x) or
UserIDConditionRef (page xiii)?

On page xxvii, does the PrivateDiffieHellmanGroupRef point to a
DiffieHellmanGroup object or a PrivateDiffieHellmanGroup object?  It is not
clear.

On page xxix, "private DiffieHellmanGroup" should be
"PrivateDiffieHellmanGroup".

The classes ISAKMPProposal, IPSecProposal, IPSecTransform, and
PrivateDiffieHellmanGroup don't have explicit type definitions.  Therefore,
according to RFC 2252, they default to STRUCTURAL.  Is this the your intent?
(Clarification)

Finally, the draft's designation (draft-...) changes throughout the
document.