Representing O/R Address in Directory

[Vicki Cox <[e-mail]>]

MHS-DS ,

We (representing DoD) would like the IETF X.500 directory to be the repository for several types of information.  This particular request is for changes to the O/R address portion of the schema.   We were planning on sending the following template to the X.500 Schema Working Group at [e-mail].  Seeking some guidance, we asked Tim Howes of the X.500 Schema group for his opinion of our template.  He responded by saying he that we were attempting to redefine existing schema elements.   One recommendation he suggested was to work with the mhs-ds group to get the definintions changed.

Something we did not point out to Mr. Howes and perhaps should have was that we have found a few differences in the description of the O/R Address between the Network Working Group and the X.500 Schema Working Group.  For example, the attributes in the X.500 Schema Working Group schema under the mHSOrganisation and mHSOrganisationalUnit (with an s instead of a z)object classes are mHS-0 (vice mHSOrganizationName) and mHS-OU (vice mHSOrganizationalUnitName). The Object IDs are also different, i.e. mhs-ds-tables-oc 5 (vice oc-mhs-organization) and mhs-ds-tables-oc 6(vice oc-mhs-organizational-unit).  mHSPerson is also different, etc.  It appears that the two WGs seem to be solving the same requirement.  If this is the case, has there been any harmonization between the two groups?  Or is our assumption incorrect?  This also raises the question, are we sending this request to the correct place?

In any case, we are submitting the same template to save time and because we do not know what format our request should be in for the mhs-ds group.  Thanks for taking the time to look this over. 

------------------------------------------------

1.  Names of submitters and email addresses:

Robert Cooney, [e-mail]
  
Curtis Cox, [e-mail]

We represent the Department of Defense (DoD) registration process.  DoD currently has formal registration procedures for all the Services and Agencies within DoD to register MTA name, NSAP Routing Domains, O/R Addresses, Directory Distinguished Names and Technical Objects.  We (representing DoD) would like the X.500 directory to be the repository for all registered information. We would like to use a directory based on the IETF X.500 schema.  Our immediate requirement is to register O/R addresses and place the appropriate entries in the directory.  We have been using the concepts presented in draft-ietf-mhsds-infotree-06.txt,ps by S. Kille of the Network Working Group as a frame of reference and more recently the effort within the X.500 Schema Working Group.

2.  Mailing list: ??

3.  Date of Original Submission:

4.  Date of Last Update:

5.  Schema Element(s)(Modifications) and Need for It:

The request we make is based on a requirement placed on us by our Operations personnel.  When we register a piece of the O/R Address (Organization Name, etc.) we require the name of the organization the entry is being created for and a point of contact to answer questions about that registered object.  If the directory is to be the repository of this information, we need attributes in the appropriate entries to hold, we believe, the distinguished name of the associated organization and the point of contact.  An additional request has been made for a place for comments or description of the entry. We have not seen any Object Class definitions which would allow the additional attributes in the appropriate entries without modification.

We understand that when something is registered it is somewhat cast in concrete and not to be fiddled with.  On the otherhand, we have also seen a request for modifications, updates, additions and corrections to the schema.  We wish to influence the existing schema such that we do not end up with a DoD specific subtree that is unusable by commercial off the shelf X.400/X.500 products.

We solicit your advise and recommendations on a course of action that might satisfy our requirements.  We have noted the attribute "description" and "owner" that might provide appropriate places for comments and point of contact information. We have not found any attribute for associated organization. We are submitting an attribute defined specifically for DoD use that satisfies this requirement but may not be appropriate to use in the IETF Schema.  It is called mHSAssociatedOrganization. We have added these attributes as MAY CONTAIN statements to already existing object classes to fulfill these requirements.  

6.  Current Status:  Experimental (?)

7.  Status of Standardization:

8.  Object Class Definition Template:

           aDMD OBJECT-CLASS ::= {
             SUBCLASS OF {top}
             MUST CONTAIN {aDMDName}
Addition:    MAY CONTAIN {description|
Addition:        mHSAssociatedOrganization|
Addition:        owner|
Addition:        seeAlso}       
             ID oc-admd}

           pRMD OBJECT-CLASS ::= {
             SUBCLASS OF {top}
             MUST CONTAIN {pRMDName}
Addition:    MAY CONTAIN {description|
Addition:         mHSAssociatedOrganization|
Addition:         owner|
Addition:         seeAlso}       
             ID oc-prmd}


           mHSOrganisation OBJECT-CLASS ::= {
             SUBCLASS OF {top}
             MUST CONTAIN {mHSOrganizationName }
Addition:    MAY CONTAIN {description|
Addition:        mHSAssociatedOrganization|
Addition:        owner|
Addition:        seeAlso}       
             ID oc-mhs-organization }

           mHSOrganisationalUnit OBJECT-CLASS ::= {
             SUBCLASS OF {top}
             MUST CONTAIN {mHSOrganizationalUnitName }
Addition:    MAY CONTAIN {description|
Addition:        mHSAssociatedOrganization|
Addition:        owner|
Addition:        seeAlso}        
             ID oc-mhs-organizational-unit}

           mHSPerson OBJECT-CLASS ::= {
             SUBCLASS OF {top}
             MUST CONTAIN {mHSSurname}
             MAY CONTAIN  {mHSGivenName 
                 mHSInitials
                 mHSGenerationalQualifier
Addition:        description|
Addition:        mHSAssociatedOrganization|
Addition:        owner|
Addition:        seeAlso}         
                 ID oc-mhs-person}


9.  (Proposed) Attribute Type Definition Template:

Name:  mHSAssociatedOrganization ATTRIBUTE ::= {
          WITH SYNTAX distinguishedNameSyntax
          ID pilotAttributeType.61(???)}  

10. Definition.   When registering various entries, we need a means of registering a Point of Contact (owner), the Service or Agency they are registering for (mHSAssociatedOrganization (our name)), other pointers (seeAlso) and comments (description). We would therefore like to propose the above additions to existing Object Classes. Please add the MAY CONTAIN statements as shown above to the aDMD, pRMD, mHSOrganisation and mHSOrganisationalUnit Object Classes.

The proposed attribute, mHSAssociatedOrganization, is defined as the name of the organization the O/R address entry is being created for. 
  
We hope that you can give us some guidance and eventually help in getting this put into consideration as a schema change.



Sincerely,

Robert Cooney
telephone [phone]

Curtis Cox
telephone [phone]