Re: draft-ietf-pkix-rfc3770bis-01: OID Import

[Peter Sylvester <[e-mail]>]

> >
> >Now you say that it is not a matter of taste.
> 
> No.  I shared the reason that I prefer to include the OIDs rather than 
> IMPORTing them.  They both work.

I say that what you give as a reason is not a matter of taste.

And your reasoning tries to just justify technical hack.

What you are technically doing is to define a new element in the
pkix kp arc in this module. I have not see that you have obtained
authorisation to do this from the owner of the pkix kp arc. 

> >By the way, further down the example is an import of something that is NOT 
> >SIMPLE.
> >
> >Using this technique requires to keep track of all copies, and IF a
> >copied definitions changes slightly in the main definition module
> >THEN you get inconsistencies.
> 
> True.  Neither of the alternatives is perfect.  They have different kinds 
> of pain.

There is nothing wrong in IMPORT in this particular case.
IMO it is PERFECTLY in line with all (what I know) of ASN1 etc. 

We are not etalking about pains created by difficulties of correct
organisation of ASN.1 modules or using current and non-obsolete syntax
versions. 
 
> > > I have had to make edits to old ASN.1 modules to avoid errors that are
> > > introduced when one modules imports stuff from another that imports stuff
> > > from another that imports stuff from another.  The changes are almost
> > > always in parts that are not needed for the part that is needed.  I'll 
> > give
> > > a recent example.
> > >
> > > RFC 2634 imports from CMS.  The ASN.1 module says:
> > >
> > > -- RFC 2630: Cryptographic Message Syntax (CMS)
> > >      ContentType, IssuerAndSerialNumber, SubjectKeyIdentifier
> > >      FROM CryptographicMessageSyntax
> > >         { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
> > >           pkcs-9(9) smime(16) modules(0) cms(1) }
> > >
> > > I needed to change this to:
> > >
> > > -- RFC 3852: Cryptographic Message Syntax (CMS)
> > >      ContentType, IssuerAndSerialNumber, SubjectKeyIdentifier
> > >      FROM CryptographicMessageSyntax2004
> > >         { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
> > >           pkcs-9(9) smime(16) modules(0) cms-2004(24) }
> > >
> > > Why?  It did not have anything to do with ContentType,
> > > IssuerAndSerialNumber, or SubjectKeyIdentifier.  It had to do with
> > > something else in the RFC 2630 module.
> >
> >Do you mean the usage of 'Name' which is used in IssuerAndSerialNumber?
> >You don't change the definition of a module. You make a new one.
> >I don't see the point.
> 
> This module also had in import from RFC 3280, and the RFC 2634 imported 
> from RFC 2630, which had an import from RFC 2459, there was some 
> conflict.  I do not recall more detail than that.  By shifting the import 
> to RFC 3852, the subordinate import shifted to RFC 3280, resolving the 
> conflict.

Sorry, arguments that are not explained have no meaning to me. 
Anyway, if there was a problem and a REAL conflict, i.e. a different
definition, then duplication of the elements using same name
would have created more problems because you don't keep track.
if in your case the definitions do not change, I don't see why
you need to import then from a different place.