Subject: [IPsec] Question regarding VID payload

From: Yoav Nir <[email-masked]>
Date: Sun, 17 May 2009 16:17:08 +0300

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. 

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."

How would people feel about demoting this MUST to a MAY ?
Email secured by Check Point

---

From: Yaron Sheffer <[email-masked]>
Date: Sun, 17 May 2009 17:46:08 +0300

Hi Yoav,

If we don't require a VID, what's there to prevent a conflict between two
vendors' private notifications, with the recipient misinterpreting the
sender's notification? Note that we never required private notification
numbers to be picked at random, so conflict are likely to occur.

Thanks,
	Yaron

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Yoav Nir
> Sent: Sunday, May 17, 2009 16:17
> To: [email-masked]
> Subject: [IPsec] Question regarding VID payload
> 
> Hi all
> 
> 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.
> 
> 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."
> 
> _______________________________________________
> IPsec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ipsec
> 
> Scanned by Check Point Total Security Gateway.

---

From: Yoav Nir <[email-masked]>
Date: Sun, 17 May 2009 18:34:16 +0300

OK. I won't use Evolution's MAPI plug-in any more...

The section is addressed specifically to I-D writers. 

All I-Ds that I've seen don't have text that says "use notification type XXXXX until IANA assigns something else, and in the meantime, use Vendor ID e1b57aa457022526a6b4430bd2fa0101"

I don't think it's even acceptable to have a VID in the I-D and then remove it in AUTH48, nor can you get an IANA assignment before last call. I could be wrong on this.

Either we allow or even encourage text like the above (and this much editing in AUTH48), or else we shouldn't mandate this for document writers. Maybe for implementors.

===================
Hi Yoav,

Thanks,
        Yaron

---

From: Tero Kivinen <[email-masked]>
Date: Mon, 18 May 2009 12:15:21 +0300

Yoav Nir writes:
> 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.
-- 
[email-masked]