Subentries in the Lightweight Directory Access Protocol (LDAP)
draft-zeilenga-ldap-subentry-07

If I understand this correctly -- and I'm not at all sure that 
I do -- the security considerations should specify that the same security 
checks must be made on retrieval or update of the collective attribute 
as for the actual entry. This is a minor point and can, I think, be 
handled with an RFC editor note.

Alternatively, I have no idea what I'm talking about and this DISCUSS
should be ignored...

Bert: Has anybody (or is anyone) checked(ing) the ABNF syntax
in those documents?

In here I see a request to IANA to assign a set of OIDs, for example:


                c-FacsimileTelephoneNumber A 2.5.4.23.1
                c-InternationalISDNNumber A 2.5.4.25.1
                c-PhysicalDeliveryOffice A 2.5.4.19.1
               
When I go to
    http://www.alvestrand.no/objectid/2.5.4.23.1.html

then it seems they are already assigned.
but certainly, the OID starts with a 2 and that is ISO/ITU-T
jointly assigned OIDs. So I wonder (did I so earlier on too
and did I forget the answer) why IANA has anything to do
with it. Does not IANA (in principle) only make
assignments in Internet owned Name spaces. So for OIDs that
is underneath 1.3.6.1 (which is the Internet OID) ??

I assume that PAF or someone makes sure that assignments are
not overlapping with anything else?

I guess that it is historical, but these attribute names


                c-l A 2.5.4.7.1
                c-o A 2.5.4.10.1
                c-ou A 2.5.4.11.1
                c-st A 2.5.4.8.1
               
are kind of short and cryptic, are they not?

To follow up on my own questions below, at the bottom of
IANA Considerations section it says:


    This document uses in this document were assigned by the ISO/IEC 
    Joint Technical Committee 1 - Subcommitte 6 to identify elements of 
    X.500 schema. This document make no OID assignments, it only 
    associates LDAP schema descriptions with existing elements of X.500 
    schema.

Which I cannot parse. But potentially it means to say:

    The OIDs used in this document were assigned by the ISO/IEC Joint
    Technical Committee 1 - Subcommitte 6 to identify elements of X.500
    schema. This document make no OID assignments, it only associates
    LDAP schema descriptions with existing elements of X.500 schema.

So if this document makes no OID assignments, is it then the idea
that IANA still registers them? I guess it needs to be added then
that authoritative "registration" or "OID assignment" is done
in that other place, possibly witha ptr to it (if any).


Bill: draft-zeilenga-ldap-subentry-06.txt has an ABNF error in Appendix 
A. ABNF rule names are case-insensitive, however it has one rule
specificExclusions and one SpecificExclusions. One of them should
be renamed. This would be easily done with an RFC-Editor note.

draft-legg-ldap-gser-abnf-03.txt and draft-legg-ldap-gser-00.txt
have syntactically correct ABNF.

Jeff: ]7. Security Considerations
]
] The Generic String Encoding Rules do not necessarily enable the exact
] octet encoding of values of the TeletexString, VideotexString,
] GraphicString or GeneralString types to be reconstructed, so a
] transformation from DER to GSER and back to DER may not reproduce the
] original DER encoding. This has consequences for the verification of
] digital signatures.

I am not sure this is an acceptable restriction. I would recommend
that the author come up with a way that permits transformation from
DER to GSER to DER in a way that doesn't break signatures.