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,

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.

Email secured by Check Point
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Reply via email to