Re: I-D ACTION:draft-ietf-ldup-infomod-03.txt

Jim,

I tend to agree with you in this respect - without OIDs things seem to be 
more "maleable" and so we can change object classes and attribute types 
without obsoleting.  It drives home the point that the Internet Draft is 
not for implementation yet.

Given that OIDs were assigned to the (now obsolete form) object classes 
and attribute types, I felt it "safer" to OBSOLETE the names/definitions 
rather than just change them.

A question for the list: ARE THERE IMPLEMENTATIONS THAT USED THE OLD OIDS? 
 If not, we could entertain using the old OIDs and names - just with 
modified definitions.

Regards,
Tim Hahn

Internet: [email protected]
Internal: Timothy Hahn/Endicott/IBM@IBMUS or IBMUSM00(HAHNT)
phone: 607.752.6388     tie-line: 8/852.6388
fax: 607.752.3681





"Jim Sermersheim" <[email protected]>
Sent by: [email protected]
08/07/2001 09:53 AM

 
        To:     <[email protected]>
        cc:     <[email protected]>
        Subject:        Re: I-D ACTION:draft-ietf-ldup-infomod-03.txt

 


Regarding:

     ¡ Made obsolete replicaSubEntry and replicaAgreementSubentry 
        object classes 
     ¡ Defined replacement object classes replicaSubEntry2 and 
        replicaAgreementSubentry2 

Assuming there are no existing implementations of this draft, do we need 
to rename these attributes?

In general, I think it would be a good idea to hold off the assignment of 
OIDs in I-Ds until the draft is ready to be progressed to RFC. This will 
prevent this scenario from being repeated in the future.

Jim