[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: [ldapext] Request for LDAP expert review of PEC object identifier descriptors



Alba,

First, I like to note that this 'LDAP expert review' is limited, per BCP 64, to the registration requests, as well as the use of non-registered protocol values (see below).  It's not a review of your technical specification.  However, it's hard for me not to comment on a few obvious technical issues I found by quick scan of this document.  Hence, I will separately send a few technical comments separately (with my IANA "LDAP expert review" hat off).

While the I-D's 8.2 is properly titled 'Registration of LDAP object identifier descriptors', the subsections 8.2.1 and 8.2.2 incorrectly request LDAP OID registration.  This caused some confusion at IANA.  While it fine to use a table to avoid having 9 separate templates, there is no need to have two tables of descriptors.  Using one table, of the form of the "Object Identifier Descriptors" registry in the IANA ldap-parameter file <http://www.iana.org/assignments/ldap-parameters> would be better (both less confusing and easier on IANA (they could just cut-n-paste)).  Please update the I-D to have a single table-based registration request for all 9 requested descriptors.

Like Steve, I generally prefer that descriptor values be more specific and relate more clearly to the application they are designed for.  As Steven suggests, prefixing everything with 'pec' would generally be appropriate.

I do understand the desire of not wanting to require existing implementations to change.  I think here one has to balance the possibility of future real world conflicts, which will require some implementations (PECs or the conflicting ones) to change to co-exist.   Registration with IANA may well aide PECs to "win" such conflicts.   However, so long as the community understands the possibility of such conflicts, and knowing PECs might not win in the real world despite being registered, I don't object to registration of these descriptors as requested.  (The two I am most concerned about are 'provider' and 'mailReceipt'.)

Hence, I, as the assigned LDAP registration "expert", tentatively approve the registration of these 9 descriptors pending update of the IANA consideration section as discussed above, such registration to be made by IANA just prior to publication as an RFC.  Upon update, please notify me so that I can take appropriate action (e.g., notify IANA that all is well).

However, if for any reason the schema were to change (such as due to late comments :-), I strongly advise injecting a 'pec' prefix into every descriptor.

Lastly, I note the I-D suggests the use of naming context named "o=postacert" but no where details how this name was properly delegated for the purposes discussed in the I-D.   Presumedly this is because it's not properly delegated.  Traditionally, LDAP relies on X.500 delegation or DNS-based name delegation.  That is, names properly delegated in X.500 or DNS, each by an appropriate naming authority, are usable in LDAP (via mechanical translation) without the need for any further registration requirement.   Traditionally, top level naming contexts of type o (organization) have been unregulated.  However, this may change in the future due to the popularity of top-level organization naming.

While "o=portacert" is not registrable (at this time), one could registered a domain namefor this purpose of use in constructing an LDAP DN.  (If the authors want to pursue this approach, I would suggest bringing in a DNS expert.*)  If the authors wish to continue to use "o=postacert", I recommend an IESG note be added that this specification utilized unregistered LDAP DN name space which may lead to conflict with other registered or unregistered names.

Regards, Kurt

(* At first, I was thinking of a domain under .arpa could be used, but it seems that this purpose likely met the requirements for .arpa delegation).


On Oct 22, 2010, at 4:01 AM, Alba Shahin wrote:

> Hello Steven.
> 
> Thank you for the comment. We agree that adding a "pec" prefix would make
> certain values less prone to misunderstandings, but we'd like to point out
> that there are currently several functioning implementations that use the
> values as defined in the draft. If possible we would like said draft to be
> representative of how things are right now, therefore maintain the values
> that are being used by those existing implementations.
> We think they should be unambiguous in any case, since those values are
> defined within the PEC context under the PEC tree.
> 
> Do you think keeping the values as they are now is possible?
> 
> Regards,
> --Alba
> 
> 
> 
> -----Original Message-----
> From: Steven Legg [mailto:steven.legg@eNitiatives.com.au] 
> Sent: giovedì 21 ottobre 2010 01:22
> To: directory@apps.ietf.org; alba.shahin@isti.cnr.it
> Cc: Kurt Zeilenga; ldapext@ietf.org
> Subject: Re: [ldapext] Fwd: Request for LDAP expert review of PEC object
> identifier descriptors
> 
> 
> I don't have a problem with any of the names requested in that they don't
> clash with anything I'm aware of. However, a name like "provider"
> is fairly generic and might clash with someone's local definition.
> I would suggest prefixing all the names with "pec" to reduce the chance of
> conflict (so pecProvider, pecProviderCertificateHash, etc.).
> 
> Regards,
> Steven
> 
> On 21/10/2010 12:20 AM, Kurt Zeilenga wrote:
>> Any comments? If so, please direct them to directory@apps.ietf.org 
>> <mailto:directory@apps.ietf.org>.
>> 
>> -- Kurt
>> 
>> Begin forwarded message:
>> 
>>> *From: *Alba Shahin <alba.shahin@isti.cnr.it 
>>> <mailto:alba.shahin@isti.cnr.it>>
>>> *Date: *October 4, 2010 8:37:48 AM PDT
>>> *To: *directory@apps.ietf.org <mailto:directory@apps.ietf.org>
>>> *Cc: *Sean Turner <turners@ieca.com <mailto:turners@ieca.com>>, 
>>> "Polk, William T." <william.polk@nist.gov 
>>> <mailto:william.polk@nist.gov>>, 
>>> draft-gennai-smime-cnipa-pec@tools.ietf.org
>>> <mailto:draft-gennai-smime-cnipa-pec@tools.ietf.org>
>>> *Subject: **Request for LDAP expert review of PEC object identifier
>>> descriptors*
>>> *x-spam-score: *1.882
>>> *x-spam-status: *No, score=1.882 tagged_above=-999 required=5 
>>> tests=[BAYES_50=0.001, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, 
>>> HTML_MESSAGE=0.001]
>>> *list-id: *Discussion of issues related to directories 
>>> <directory.ietf.org <http://directory.ietf.org>>
>>> 
>>> Hello,
>>> We would like to request an expert review of the LDAP object 
>>> identifier descriptors defined in PEC (Italian Certified Electronic 
>>> Mail) [http://www.ietf.org/id/draft-gennai-smime-cnipa-pec-08.txt] 
>>> and pasted below.
>>> (Some minor changes were made below wrt what’s in the draft).
>>> We look forward to your feedback on this.
>>> Thank you.
>>> --Alba
>>> ----
>>> 8.2.1. Registration of Object Classes
>>> Subject: Request for LDAP Descriptor Registration Descriptor (short 
>>> name): See comments Object Identifier: See comments Person & email 
>>> address to contact for further information:
>>> See "Author/Change Controller"
>>> Usage: object class
>>> Specification: (I-D)
>>> Author/Change Controller:
>>> Claudio Petrucci
>>> DigitPA
>>> Viale Carlo Marx 31/49
>>> 00137 Roma
>>> Italy
>>> EMail:PETRUCCI@digitpa.gov.it <mailto:PETRUCCI@digitpa.gov.it>
>>> Comments:
>>> The following object identifiers and associated object classes are 
>>> requested to be registered.
>>> OID Object Class
>>> ------------------------- -----------------------
>>> 1.3.6.1.4.1.16572.2.1.1 LDIFLocationURLObject
>>> 1.3.6.1.4.1.16572.2.1.2 provider
>>> Please also see the associated registration request for the 
>>> providerCertificateHash, providerCertificate, providerName, 
>>> mailReceipt, managedDomains, LDIFLocationURL, and providerUnit 
>>> attribute types.
>>> 8.2.2. Registration of Attribute Types
>>> Subject: Request for LDAP Descriptor Registration Descriptor (short 
>>> name): See comments Object Identifier: See comments Person & email 
>>> address to contact for further information:
>>> See "Author/Change Controller"
>>> Usage: attribute type
>>> Specification: (I-D)
>>> Author/Change Controller:
>>> Claudio Petrucci
>>> DigitPA
>>> Viale Carlo Marx 31/49
>>> 00137 Roma
>>> Italy
>>> EMail:PETRUCCI@digitpa.gov.it <mailto:PETRUCCI@digitpa.gov.it>
>>> Comments:
>>> The following object identifiers and associated attribute types are 
>>> requested to be registered.
>>> OID Attribute Type
>>> ------------------------- -------------------------
>>> 1.3.6.1.4.1.16572.2.2.1 providerCertificateHash
>>> 1.3.6.1.4.1.16572.2.2.2 providerCertificate
>>> 1.3.6.1.4.1.16572.2.2.3 providerName
>>> 1.3.6.1.4.1.16572.2.2.4 mailReceipt
>>> 1.3.6.1.4.1.16572.2.2.5 managedDomains
>>> 1.3.6.1.4.1.16572.2.2.6 LDIFLocationURL
>>> 1.3.6.1.4.1.16572.2.2.7 providerUnit
>>> Please also see the associated registration request for the 
>>> LDIFLocationURLObject and provider object classes.
>> 
>> 
>> 
>> _______________________________________________
>> Ldapext mailing list
>> Ldapext@ietf.org
>> https://www.ietf.org/mailman/listinfo/ldapext
> 

_______________________________________________
Ldapext mailing list
Ldapext@ietf.org
https://www.ietf.org/mailman/listinfo/ldapext