[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: comments on jfk and ikev2 drafts
Ari> Michael Richardson wrote:
>> Suggested text:
>>
>> The Vendor ID Payload contains a vendor defined constant. The
>> constant is used by vendors to identify and recognize remote
>> instances of their implementations. This mechanism allows a
>> vendor to experiment with new features while maintaining backwards
>> compatibility.
>>
>> The Vendor ID payload is both an announcement from the sender of
>> which space private payload types will come from, and also an
>> announcement of the sort of private payloads it is willing to
>> accept.
That is fine for some implementations but I believe this is more
restrictive than necessary.
The first part is clearly true: the Vendor ID identifies the number
space of transmitted private payloads. And presumably that host will
also understand inbound private payloads for that same vendor ID.
But a host that sends vendor ID X may also understand and accept
received private payloads from any number of other vendor IDs. In
fact, this pretty much has to be true if you're experimenting
cross-vendor with a new feature that's encoded in private payloads.
So what I would say instead is:
The Vendor ID payload indicates which space private payload types
transmitted by this node are taken from. A node may be able to
accept and understand private payloads from multiple vendors; in
that case, it would use the received Vendor ID to identify the
number space to which inbound private payload types belong.
paul
Follow-Ups:
References: