RE: [Policy] AD review: draft-reyes-policy-core-ext-schema-03.txt (targeted fo r PS)

[John Strassner <[e-mail]>]

Hi Bert,

My opinions in answer to your questions are inline. Look for <js>..</js>

regards,
John

John C. Strassner
Chief Strategy Officer
Intelliden Inc.
90 South Cascade Avenue
Colorado Springs, CO  80906  USA
phone:  [phone]
  fax:     [phone]
email:    [e-mail]


> -----Original Message-----
> From: Wijnen, Bert (Bert) [mailto:[e-mail]]
> Sent: Friday, August 29, 2003 2:50 PM
> To: 'Pana, Mircea'; 'Marcus Brunner'; '[e-mail]';
> '[e-mail]'; 'David Moron'
> Cc: Policy (E-mail)
> Subject: [Policy] AD review: draft-reyes-policy-core-ext-schema-
> 03.txt (targeted fo r PS)
> 
> Here are my comments. Would be good to not only hear
> authors/editors
> responses, but also input from the WG.
> 
> - RFC3460 Updates RFC3060. So would it not be logical to say/claim
>   that this PCELS Updates PCLS ?? If so, we need to say so in the
>   abstract with a simple, but explicit sentence:
>       This document updates RFC zzzz
>       -- RFC-Editor replaces zzzz with RFC number assigned to
> [PCLS]

<js> One would have thought so. But this document changes PCLS in several
fundamental ways. I do NOT think that the word "update" should be used
anywhere in this document. </js>

> - Maybe I just do not understand... But is it valid to just move a
>   class, like you moved the pcimGroup (and all that was under it)
>   underneath a new pcimPolicySet. Would it not be more cuatious to
>   deprecate the pcimGroup and define s pcimeGroup or such under
>   pcimPolicySet and do something similar for the other moved groups
>   classes? I understand that PCIM-EXT did this moving too, but that
>   is an information model (so abstract) while this is a mapping
> onto
>   a repository, so here things may get incompatible if we already
>   have implementation of PCLS, no?

<js> I don't think that moving classes around are justified or a good idea.
This would be equivalent to me building a MIB where I "update" an existing
table by building a completely new table. This and other things render the
resulting schema of PCELS incompatible with older PCLS implementations.
</js>

> - Is it wise to have (as part of this document) two Vendor specific
>   classes that are not part of or based on PCIM-EXT ?? This doc is
>   supposed to do the LDAP Schema defintiions for PCIM-EXT, right?
>   So why these additions?

<js> The vendor classes were originally intended to provide extensibility.
But having new classes that are not built from PCIM or PCIMe is NOT a good
idea, and they certainly do not qualify as an "update". </js>

> - Is it wise to just rename classes (sect 4.2, bullet 1). Would it
>   not be wiser to deprecate the old ones and add new ones?

<js> Renaming is a bad idea, because everything else now changes - their
OIDs, classes referencing them, etc. But I don't believe that deprecation is
appropriate for a schema. I know of no LDAP documents that have deprecated
schema - this is rather done in an implementation.

Again, it seems that this is more of a NEW implementation as opposed to an
UPDATE of any type. </js>

> - There seems to be more of these things that I wonder if
> deprecation
>   and adding new ones would be better. I guess I do not very well
>   understand the impact (or non-impact) on existing implementations
>   of the PCLS by the changes being made. Can someone explain to me.
>   Or possibly add text to the document that describes such
>   (non-)impact.

<js> There's a very large impact - lack of compatibility. Fundamentally,
this document proposes a set of incompatible changes to PCLS. I don't
understand why these changes are being asked for. It would seem that instead
of rewriting parts of the schema, as this document proposes, changes should
have been made to PCLS. </js>

> - In section 5, I think you need to explain/define which matching
>   rules are used and make citations to where they are defined.
>   PCLS does that too (zeilenga-user_schema), but you probably
>   better use: draft-zeilenga-ldap-user-schema-mr-00.txt
>   Pls make sure that that indeed covers all matching rules.

<js> The matching rules are not defined as normative references, which is
imho a mistake. They should at least reference RFC2252 for LDAP definitions
and X.520 for the X.5 definitions. Note that PCLS uses the 2001 version of
X.520. </js>

> - Security Considerations
>   Would it not be better to change the first 3 paragraphs:
>     This topic is based on requirements from previous [PCLS]
> documents
>     and also takes into account other RFCs about the same security
>     aspects entitled as following:
> 
>     RFC 2829 (Authentication Methods for LDAP)
>     RFC 2830 (Lightweight Directory Access Protocol (v3): Extension
> for
>               Transport Layer Security)
> 
>     These RFC documents provide a general framework for security
>     architecture of the system. However some comments have to be
> provided
>     as a consequence of the inclusion of extensions in this own
> document
>     and its relation with PCLS doc.
>   Into something like:
>     Since this PCELS document is an update to the [PCLS] it has the
> same
>     basic security considerations as the [PCLS] document. So see
> the
>     Security considerations in [PCLS] first.

<js> I would agree </js>

> - You may want to check the English on Page 55 (up to IANA
> considerations)
>   For example: what is "obtention" ??
>                what is "p.e." ? I guess par example or per exemple?
>                in English text we tend to use e.g.
> 
>   And for me (but I am not a security expert), I do not understand
> what
>   that text on page 55 is trying to tell me. You may want to check
> with
>   one of the security ADs, Russ Housley is probably the most
> appropriate,
>   if this is clear and acceptable for them.

<js> Russ Mundy was the security advisor for PCIM. Luis Sanchez also looked
at early copies of the document. </js>

> - IANA Considerations.
>   Isn't the IANA-ASSIGNED-OID the same as the one in PCLS ??
>   If so, we should make that clear in the document, so it is
>   easy for IANA to see and understand.

<js> Depends on what they would want to do. But I would expect that new
classes (regardless of whether they update an existing class or not) to have
new OIDs. </js>

> NITS:
> - in abstract, do not use citations as per RFC-Editor policy. It is
> OK to
>   use RFC numbers.
> - RFC2119 (your [KEYWORDS] citation) must be a normative reference
>   Your text on keywors on page 1 does not make a citation to this
> by the
>   way.
> 
> I want to get this doc reviewed by an LDAP expert (from the LDAP
> directorate) as well, but maybe you can try to address and/or
> answer
> the above first.

<js> I'm on the LDAP directorate ;-) and will take a good look at actual
recommended schema next week. </js>

> Thanks,
> Bert
> 
> _______________________________________________
> Policy mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/policy