Re: IANA document

[Michael Richardson <mcr@sandelman.ottawa.on.ca>]

-----BEGIN PGP SIGNED MESSAGE-----


>>>>> "Theodore" == Theodore Ts'o <tytso@mit.edu> writes:
    Theodore> I've been looking at RFC 2434, and it looks like there are some
    Theodore> requirements for what needs to be in the IANA consideration
    Theodore> section that doesn't quite meet with what's in
    Theodore> draft-ietf-ipsec-ikev2-iana-01.txt.  In particular, what RFC

  okay, but again, I wasn't asked to write IANA Considerations, but rather,
to extract the text into some nice, consise tables. If I misunderstood, then
fine. please tell me what you want.

    Theodore> In addition, I am wondering if we need to adjust the allocation
    Theodore> policies as currently defined in ikev2-iana-01 document.  It
    Theodore> seems strange to me that the relatively small ranges, such as
    Theodore> the IKEv2 Payload types (only 255 possible values) have
    Theodore> relatively loose policies, such as "Specification Required",

    Theodore> whereas some ranges that are much larger, such as the IKEv2
    Theodore> Integrity Algorithm Transform ID's (with 65536 possible values)
    Theodore> have "Expert Review" as the policy.

  Uh, "Expert Review" is a looser policy than "Specification Required"

  Expert Review means you email IANA, and say:

	 "please allocate me an IKEv2 integrity algorithm transform number
          for TripleRot-13"

  IANA, then forwards to "Expert", and "Expert" says,

	"Yeah, that sounds reasonable, go ahead"

or:	"Wait, TripleRot-13 is a cipher, I think that this request is
	unfounded"     

  That's all.

  Specification Required means that there has to be a document somewhere.
I thought this meant RFC series of some kind, but I've been told that for
ciphers, a publication in a peer-reviewed journal would do. That's a lot 
harder than just sending an email.


  There are some things that do not affect interoperability and the spaces are
large, so the allocations should be easy.
  One pulls back only because one wants to avoid the PPP, DHCP and radius
situation with a lot of options being used widely that started as
vendor-specific options.

  There are some things that would have profound affects on interoperability,
and so one insists that they write things down, even if the allocation space
might be big.


    Theodore> I understand that you probably just used the IANA policies from
    Theodore> the original IKEv1 and ISAKMP specs.  But it's not clear to me
    Theodore> that they are completely coherent.

  No, I thought pretty hard about it. I reviewed what was in IKEv1, and
moderated my thought by 6 years of watching people try to write extensions.

]       ON HUMILITY: to err is human. To moo, bovine.           |  firewalls  [
]   Michael Richardson,    Xelerance Corporation, Ottawa, ON    |net architect[
] mcr@xelerance.com      http://www.sandelman.ottawa.on.ca/mcr/ |device driver[
] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)
Comment: Finger me for keys

iQCVAwUBQBlGV4qHRg3pndX9AQHlXAQAmHDIMsTxUuRe0K/yXi59NMMLRjh2la7V
2My4In3Ps9ImcMX1/14WCHobD8tOUe32VafoCexUk1BE6MWNB5qo+6dRZfuokak6
3fADKorDFVbbLg9gFcT01TWhxc+c5n+XPO+P88UhflSPpwkCMnXV7r+N3U5UYf6y
uWGu8mZTsbY=
=yWDK
-----END PGP SIGNATURE-----