Yoav Nir writes: > Hi all > > I've just noticed that section 3.12 of the bis draft has the following text: > > Writers of Internet-Drafts who wish to extend this protocol MUST > define a Vendor ID payload to announce the ability to implement the > extension in the Internet-Draft. It is expected that Internet-Drafts > that gain acceptance and are standardized will be given "magic > numbers" out of the Future Use range by IANA, and the requirement to > use a Vendor ID will go away. > > This seems like a weird requirement, and in fact hasn't been in use > so far. Neither the individual extensions nor the extensions > currently created by this WG define any Vendor IDs.
I haven't seen any extension which has been already in use on the net for IKEv2 yet. All the documents we define here in the WG do NOT usually require vendor ID as we do not have any numbers allocated to them yet (i.e. all numbers are "TBA by IANA"). The problem with IKEv1 was that there was vendor A making extension U, which allocated number X from registry F. This registry was IANA registry, but the vendor didn't officially register those numbers, but still put the numbers to the actual products. Then when WG decided to allocate same number X from the same registry we had overlapping numbers allocated from the same registry. For this we created the private use numbers. Use of private use numbers MUST include sending the vendor ID to indicate whose private numbers you are using, so if vendor A is using private number Y, and vendor B is using same private number Y for something else, the other end can know from vendor IDs which number space is used. > The more common procedure is to announce support for the extension > using a notification (private at first and later from IANA) and not > use any VendorID at all. This is supported by section 3.10: "Notify > payloads with status types MAY be added to any message and MUST be > ignored if not recognized." I do not think notification payloads are good for that as even those require registration, and private numbers notifications cannot really be used as they still need Vendor ID payload which tells whose private numebrs they are. Notification payloads are fine for final end result of the protocol, i.e they can be used to indicate support of certain extensions (i.e. MOBIKE_SUPPORTED etc). Notification payloads cannot be used during the development phase of the protocol, i.e. when someone wants take draft-ietf-ipsecme-ikev2-resumption-04 draft now and wants to put it out as a product, which means he needs to allocate the numbers TBA1-5 himself, as IANA will not allocate them before the draft goes forward. So if he picks private numbers for TBA1-5, and adds his own Vendor ID, and then he can use this "private" version of the extension even before it goes forward. I.e. Vendor ID is only required after the draft is in such state that it can be implemented, i.e. after the TBA values are written there, but before IANA has officially allocated them. > How would people feel about demoting this MUST to a MAY ? I think it MUST be kept as MUST. -- kivi...@iki.fi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
