Subject: Re: LTANS: clean-up of ltans oid structure - next revision of OID Registry
From: Peter Sylvester <[email-masked]>
To: Tobias Gondrom <[email-masked]>
Cc: Carl Wallace <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Mon, 30 Apr 2007 16:13:06 +0200
List-Id: <ietf-ltans.imc.org>

Hi,

I think we are getting closer. But some comments anyway.

First, only the id-* need to be defined with global names. They are  in 
fact defined in each
of the asn.1 modules for ers or ltap, etc. The other ids are not global 
definitions. They
are not intended to be importable from anywhere.

ltans, ers and ltap are special: They are used locally in the ers or 
ltap module to
define the parents of some id-*
unless we follow the logic of the ITU to have a useful definitions module
where we can even import oid of moduls, there is no reason to them
a name, they are just object identifier values.

Second, mste values should have names at the last component, i.e. all 
except the module
identifiers whether the last is just the version number.

I still don't think that pushing down the module arc below ers or ltap 
is a good idea, since
other working groups don't do that. IMO it does too much of delegation 
to a topic
writer like ers or ltap. Well, the actual logic means:  "Dear  ltans 
contributor, if
you want to contribute some work, tell us  how many asn1 modules you want,
and we give you an arc root where you are supposed to add one
   mod(2)
   mod88(1)
and you can use the rest of the arc as you wish.

I prefer at least for tyhe modules:

'Write one or two modules', chose a  NAME for the module, we  (ltans)  give
you an identifier for that. " ...

BtW, in any case I'd prefer module(0) instead of mod(2)

Tobias Gondrom wrote:
> Hello Peter, hello all,
>
> sorry, that this answer took me so long, but I have been occupied the last week with some other things. :-(
>
>
> I agree, we are on the same page. 
> As mentioned before, the intention is to list the OIDs we will register at the LTANS OID registry at http://www.imc.org/ietf-ltans/ltans-oid.asn 
>   
I don't see what is supposed to be registered and how. The only OID, in 
fact, it value
is the

    { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) ltans(11) }

I don't think that we need an actual global definition id-ltans or ltans 
for it.
If the name is a hint that instruct module writers to include a local 
definition of
that kind, then, why not, so in the ers modules one would have the 
definitions

ltans OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) 
            dod(6) internet(1) security(5) mechanisms(5) ltans(11) }

-- LTANS Arcs
ers OBJECT IDENTIFIER ::= { ltans ers(1) }   - Evidence Record Syntax

in order to be able to says

id-ers-em OBJECT IDENTIFIER ::= { ers em(3) }

instead of

id-ers-em OBJECT IDENTIFIER ::= { ltans ers(1) em(3) }

or 

id-ers-em OBJECT IDENTIFIER ::= { so(1) identified-organization(3) 
            dod(6) internet(1) security(5) mechanisms(5) ltans(11)
            ers(1) em(3) }

Note the NAMES ers and em on the right side!

> 1. As no one else had any additional comments concerning the naming convention (module vs. module97) I will follow your proposal.
>
> 2. As I learned also from our discussion my naming convention was in some cases a bit confusing (and ambiguous), so I looked again at the other OID lists and revised the draft for LTANS-OIDs slightly to be unambiguous by using the name of the father node as the prefix for the name of the child-node (as done by PKIX and SMIME). Other OID lists follow the guidance to always use the short code of the level above as the prefix for the identifiers one level below, without the WG father node, e.g. at PKIX id-swb-pkc-cert-path being a child of id-swb.
>
> Please note: I only revised the names, the structures stayed exactly the same. And I hope that the new names and convention are acceptable. 
>
> If not, please reply until May-07 to the list. 
>
> One small additional comment concerning the prefix "id":
> I only used it for some of the identifiers, if there is a WG consensus to use the id-prefix for all identifiers, I will of course follow this guidance, but I would vote for the names as listed below:
>   
The NAMES on the left side are global since the registry is not part of 
an asn.1 modul,
so you cannot just import the values. This "asn" file just uses some 
asn.1 syntax but this
seems inappropriate to me.

>
> -- LTANS Object Identifier Registry
> ltans OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) 
>             dod(6) internet(1) security(5) mechanisms(5) ltans(11) }
>
>
> -- LTANS Arcs
> ers OBJECT IDENTIFIER ::= { ltans 1 }   - Evidence Record Syntax
>   

                              { ltans ers(1) }

> ltap OBJECT IDENTIFIER ::= { ltans 2 }  - Long Term Archive Protocol
>   

                               { ltans ltap(2) }

Thus one I already meantioned above.
> -- ERS Modules
> ers-mod88 OBJECT IDENTIFIER ::= { ers 1 }   - Module ASN.1 1988-Syntax
>   

                              { ers mod88(1) } 

> ers-mod OBJECT IDENTIFIER ::= { ers 2 }     - Module ASN.1 1997-Syntax
>   

                              { ers mod(2) } 

I'd prefer 0 as in other specs. and cann it  module(0)

> id-ers-em OBJECT IDENTIFIER ::= { ers 3 }   - Encryption Method in ERS
                                 { ers em(3) }

> }
>   
> -- Version for ERS Module 88
> ers-mod88-ver OBJECT IDENTIFIER ::= { ers-mod88 1 } - Version number for RFC
>
> -- Version for ERS Module
> ers-mod-ver OBJECT IDENTIFIER ::= { ers-mod 1 }   - Version number for RFC
>   

> -- ERS Encryption Methods
> id-ers-em-er-internal OBJECT IDENTIFIER ::= {id-ers-em 1}
> id-ers-em-er-external OBJECT IDENTIFIER ::= {id-ers-em 2}
>
>   

id-ers-em-er-internal OBJECT IDENTIFIER ::= {id-ers-em er-internal(1)}

etc

> -- LTAP Modules
> ltap-mod88 OBJECT IDENTIFIER ::= { ltap 1 }   - Module ASN.1 1988-Syntax
> ltap-mod OBJECT IDENTIFIER ::= { ltap 2 }     - Module ASN.1 1997-Syntax
>   

                                   { ltap mod88(1) }
                                   { ltap mod(2) }

> -- for LTAP Module 88
> ltap-mod88-ver OBJECT IDENTIFIER ::= { ltap-mod88 1 } - Version number for RFC
>
> -- for LTAP Module
> ltap-mod-ver OBJECT IDENTIFIER ::= { ltap-mod 1 }   - Version number for RFC
>
>   

The names on the right side are necssary since we want to write

ERS MODULE { iso(1) identified-organization(3) dod(6) internet(1) 
security(5) mechanisms(5) ltans(11)  ers(1) mod(2) 1 }
or as I prefer

ERS MODULE { iso(1) identified-organization(3) dod(6) internet(1) 
security(5) mechanisms(5) ltans(11)  module(0) ers(1)  1 }

>
> Best regards, Tobias
>
>
>   
Have fun.