Subentries in the Lightweight Directory Access Protocol (LDAP)
RFC 3672

Summary: Needs a YES. Needs 10 more YES or NO OBJECTION positions to pass.

Alvaro Retana No Record

Benjamin Kaduk No Record

Erik Kline No Record

Francesca Palombini No Record

John Scudder No Record

Lars Eggert No Record

Martin Duke No Record

Martin Vigoureux No Record

Murray Kucherawy No Record

Robert Wilton No Record

Roman Danyliw No Record

Warren Kumari No Record

Zaheduzzaman Sarker No Record

Éric Vyncke No Record

(Steven Bellovin; former steering group member) Discuss

Discuss [Treat as non-blocking comment] (2003-08-04)
No email
send info
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.

(Ned Freed; former steering group member) Yes

Yes ()
No email
send info

(Alex Zinin; former steering group member) No Objection

No Objection ()
No email
send info

(Allison Mankin; former steering group member) No Objection

No Objection ()
No email
send info

(Bert Wijnen; former steering group member) No Objection

No Objection ()
No email
send info

(Bill Fenner; former steering group member) No Objection

No Objection ()
No email
send info

(Harald Alvestrand; former steering group member) No Objection

No Objection ()
No email
send info

(Randy Bush; former steering group member) No Objection

No Objection ()
No email
send info

(Thomas Narten; former steering group member) No Objection

No Objection ()
No email
send info