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

["Wijnen, Bert (Bert)" <[e-mail]>]

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]

- 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?

- 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?

- 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?

- 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.

- 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.

- 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.

- 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.

- 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.

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.

Thanks,
Bert 

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