Hi, This was my question, if you registered the OIDs then it is OK. Roni Even > -----Original Message----- > From: Sean Turner [mailto:turners@xxxxxxxx] > Sent: Sunday, April 18, 2010 11:19 PM > To: Roni Even > Cc: 'General Area Review Team'; ietf@xxxxxxxx; draft-turner- > asymmetrickeyformat.all@xxxxxxxxxxxxxx > Subject: Re: Gen-ART Telechat review of draft-turner- > asymmetrickeyformat-05 > > Roni Even wrote: > > Hi, > > I will provide an example > > This draft defines > > > > AsymmetricKeyPackageModuleV1 > > { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) > > smime(16) modules(0) id-mod-asymmetricKeyPkgV1(50) } > > > > RFC 5652 defines > > > > CryptographicMessageSyntax2004 > > { iso(1) member-body(2) us(840) rsadsi(113549) > > pkcs(1) pkcs-9(9) smime(16) modules(0) cms-2004(24) } > > > > In this case the id-mod-asymmetricKeyPkgV1(50) is not the same as > > cms-2004(24) so they are different but how do you know that 50 is not > used > > by other draft. > > > > Look at Alfred H־nes email. I think that updating the specific > registries is > > important. I know that they are not maintained by IANA but hopefully > someone > > is maintain them and need to be notified of these two OIDs > allocations. > > Ah, I got both OIDs by asking for them. I only put them in the > document > after I had them registered to ensure we wouldn't have collisions. The > earlier versions of the ID had "tbd" as place holders until I > officially > got them registered. > > spt > > > Thanks > > Roni Even > > > >> -----Original Message----- > >> From: Sean Turner [mailto:turners@xxxxxxxx] > >> Sent: Sunday, April 18, 2010 8:37 PM > >> To: Roni Even > >> Cc: 'General Area Review Team'; ietf@xxxxxxxx; draft-turner- > >> asymmetrickeyformat.all@xxxxxxxxxxxxxx > >> Subject: Re: Gen-ART Telechat review of draft-turner- > >> asymmetrickeyformat-05 > >> > >> Roni, > >> > >> Thanks for your review. Comments inline. > >> > >> spt > >> > >> Roni Even wrote: > >>> I have been selected as the General Area Review Team (Gen-ART) > >> reviewer for > >>> this draft (for background on Gen-ART, please see > >>> http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html). > >>> > >>> Please wait for direction from your document shepherd or AD before > >> posting a > >>> new version of the draft. > >>> > >>> Document: draft-turner-asymmetrickeyformat-05 > >>> > >>> Reviewer: Roni Even > >>> > >>> Review Date: 2010-4-18 > >>> > >>> IESG Telechat date: 2010-4-22 > >>> > >>> Summary: This draft is ready for publication as a Proposed > Standard. > >> I have > >>> some nits > >>> > >>> Nits/editorial comments: > >>> > >>> 1. In section 7 what you are registering is a media subtype > and not > >> a > >>> media type. The media type is application. So "defines a new media > >> type" > >>> should be "defines a new media subtype" and "Registration of media > >> type" > >>> should be "Registration of media subtype". > >> I'll add this in. > >> > >>> 2. The document defines new object identifiers like > >>> id-ct-KP-aKeyPackage and AsymmetricKeyPackageModuleV1. Where is > the > >> list of > >>> these identifiers kept and how do you update this list in order to > >> guarantee > >>> the uniqueness of these identifiers. > >> I got the OIDs for the content types and asn.1 module out of two > arcs. > >> Both OIDs are unique. Technically, we'd never update an OID. Once > >> it's > >> registered it's registered. If we need a new OID, then we don't > >> necessarily have to go back to the same arc - but I'm sure we could. > >> The module OID I got from the SMIME Arc, which is administered by > Russ > >> Housley and it's been delegated from IANA to SMIME. The other I got > >> out > >> of a DoD arc. I should add the following the IANA considerations > >> sections to make this clear: > >> > >> This document makes use of object identifiers to identify a CMS > content > >> and the ASN.1 module found in Appendix A. The CMS content type OID > is > >> registered in a DoD arc. The ASN.1 module OID is registered in an > arc > >> delegated by IANA to the SMIME Working Group. No further action by > >> IANA > >> is necessary for this document or any anticipated updates. > > > > _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf