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: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] On Behalf Of
> Yoav Nir
> Sent: Sunday, May 17, 2009 16:17
> To: ipsec@ietf.org
> Subject: [IPsec] Question regarding VID payload
>
> 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
> _______________________________________________
> IPsec mailing list
> IPsec@ietf.org
> https://www.ietf.org/mailman/listinfo/ipsec
>
> Scanned by Check Point Total Security Gateway.
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
