Hi, Tero, Thank you for the reply. Please see comments marked with [pl].
On Fri Feb 10 14:00:28 2012, [email protected] wrote: > Pearl Liang via RT writes: > > - For Registry Name: IPSEC Authentication Methods (Value 3) > > > Registry Name: IPSEC Authentication Methods (Value 3) > > > Current: Standards-track RFC > > > > > > There is nothing about this in the RFC2409, so I would say either "RFC > > > required" or "Specification required" would be ok. There is draft > > > http://tools.ietf.org/html/draft-harkins-ike-iana-update-00 already > > > proposing this change. > > > > Question1: since a new document is in work to update this, > > the registration procedures will be updated when the document is made > > to IETF Last call. Would it be okay to not change the listed > > registration procedures at this time? > > As there seems to be different opinions about this in the IPsecME WG, > I think it might be better to leave this for now, and then we can work > on that issue by using the draft-harkins-ike-iana-update document as > our placeholder. > > I myself do think that as the current Standards-track RFC requirement > is not mentioned in any RFCs, we do not necessarely need RFC to change > it (and I think publishing RFC just to change one unspecified > registration policy is not really needed). > > On the other hand we do need to have concencus on the issue among the > working group, so after we reach that, we can come back to you, > regardless whether we publish separate document about that issue or > not (which is separate issue we need to decide). > > So leave it as it is for now, and we work on this issue in the IPsecME > WG. > [pl] No action. > > - For Registry Name: PRF (Value 13) > > > Registry Name: PRF (Value 13) > > > Current: Standards-track or Informational RFC > > > > > > There is nothing about this in the RFC2409, so I would say either "RFC > > > required" or "Specification required" would be ok. > > > > > > > Question2: Would it be sufficient to list "RFC required" only? > > Yes that would also be acceptable, but "Specification required" would > be more inline with other cryptographic algorithms specified in the > RFC2409 (encryption algorithm, hash algorithm etc), so I would prefer > "Specification required". > > The exact text in RFC2409 for similar registries is: > > Requests for assignment of new encryption algorithm values must be > accompanied by a reference to a standards-track or Informational > RFC or a reference to published cryptographic literature which > describes this algorithm. > [pl] I changed the reg procedures to "Specification required" for the sub-registry 'PRF' at http://www.iana.org/assignments/ipsec-registry. > > - For these 'early assignment' registrations as per > > ietf-ipsec-ike-ecc-groups, you commented the following: > > > > > > 6 EC2NGF163Random2 > > > > 7 EC2NGF163Koblitz > > > > 8 EC2NGF283Random > > > > 9 EC2NGF283Koblitz > > > > 10 EC2NGF409Random > > > > 11 EC2NGF409Koblitz > > > > 12 EC2NGF571Random > > > > 13 EC2NGF571Koblitz > > > > > > These are from the > > > http://tools.ietf.org/html/draft-ietf-ipsec-ike-ecc-groups-04 version, > > > i.e. the registry was updated at some point in 2002 even when the > > > registry had registration policy of "RFC Required" and the document > > > was still draft (and was never published as RFC). > > > > > > I think you should remove "Panjwani" and "Blake-Wilson" and put > > > "ipsec-ike-ecc-groups" for all of them, and put some down a footnote > > > saying that the registry was updated too early and the draft never > > > made it to the RFC, but as these values might be used by some > > > implementations they are left there in the registry, but new > > > implementations should not use them. Also the reference could point > > > out that the values in the registry match the -04 version of the > > > document. > > > > [pl] I have removed the version number from the draft string. (I was > > unable to locate those assignments (e.g. EC2NGF163Random2) in version 4.) > > I have also remove both "Panjwani" and "Blake-Wilson" from the registry. > > I have also marked the draft-ipsec-ike-ecc-group as expired in > > the registry since it has never made it to an RFC. > > Regarding the footnote, I've drafted something as follows: > > > > [[ > > Note: these values were reserved as per draft-ipsec-ike-ecc-groups which > > never made it to the RFC. These values might be used by some > > implementations as currently registered in the registry, but new > > implementations should not use them. > > ]] > > > > Question: does the above look okay? Please comment. When I receive > > your edits, I will add the "Note" to the registry. > > That note seems to be ok. > > > Please see: http://www.iana.org/assignments/ipsec-registry > [pl] Done. I'll submit this for conversion to XML as the source. If you see any errors, please let us know. > Your changes seem to be ok. > > BTW, is there any way to get diffs to the registries, in the same way > you can get diffs to the drafts. It would be useful when checking out > what has changed in the registry and when. > > Do you keep old versions of the registries and if so, is there a way > to fetch those using http so I could use rfcdiff (or wdiff, or make > separate tool for that) to make side by side diffs of the registries. > [pl] we do not offer this at this time, however we can consider what you have proposed when developing improvements to the website, which is in process right now. > > When you have updates for the isakmp-registry, please send them > > to us. > > I will come back when I have time to go through that one. Okay. Thank you. Best, ~pearl _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
