Re: [CCAMP] Vendor-Specific Application Code in draft-ietf-ccamp-rwa-wson-encode

"Adrian Farrel" <> Fri, 23 January 2015 18:46 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id E97DB1A86F6 for <>; Fri, 23 Jan 2015 10:46:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -101.9
X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, USER_IN_WHITELIST=-100] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id IRpkh2U60k5O for <>; Fri, 23 Jan 2015 10:46:08 -0800 (PST)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D421A1A7002 for <>; Fri, 23 Jan 2015 10:46:07 -0800 (PST)
Received: from (localhost.localdomain []) by (8.13.8/8.13.8) with ESMTP id t0NIjwJY020876; Fri, 23 Jan 2015 18:45:58 GMT
Received: from 950129200 ( []) (authenticated bits=0) by (8.13.8/8.13.8) with ESMTP id t0NIjtRM020857 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Fri, 23 Jan 2015 18:45:57 GMT
From: "Adrian Farrel" <>
To: "'Leeyoung'" <>, "'Giovanni Martinelli \(giomarti\)'" <>
References: <006901d0371a$9e1f1960$da5d4c20$> <7AEB3D6833318045B4AE71C2C87E8E1729C7E09C@dfweml706-chm>
In-Reply-To: <7AEB3D6833318045B4AE71C2C87E8E1729C7E09C@dfweml706-chm>
Date: Fri, 23 Jan 2015 18:45:54 -0000
Message-ID: <010501d0373c$d34e3db0$79eab910$>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQKAmjcynMdOjxZUzM6y2aNWnfhgwAHd8I9cm15TodA=
Content-Language: en-gb
X-TM-AS-MML: disable
X-TM-AS-Product-Ver: IMSS-
X-TM-AS-Result: No--8.192-10.0-31-10
X-imss-scan-details: No--8.192-10.0-31-10
X-TMASE-MatchedRID: cgbqQT5W8hc4HKI/yaqRm+YAh37ZsBDCQKuv8uQBDjrVl0v7E9Khhjmt pOQ8tq11oL3FOYWIsdHUbKn/PdoC7En4dMSWXlsdttAWxuM5sl5kBDPLxNH5BuRmz46Q29bDXQT /yMDXZh21j2LKTBq2U8Y73AWvgGeH5U8oG6fPYRNIOSHptb5tx9tb21l1J0jcIHMhnr7X7SejxY yRBa/qJX3mXSdV7KK4OubYLCVnBVF5zdAzex5xZmgubNf+0eKAyqKRqIgMlCSSF6dRnbBxF3TUR CkzqBevzRg4qDlub1qUTGVAhB5EbQ==
Archived-At: <>
Subject: Re: [CCAMP] Vendor-Specific Application Code in draft-ietf-ccamp-rwa-wson-encode
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Discussion list for the CCAMP working group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 23 Jan 2015 18:46:10 -0000

> Thanks Adrian for taking this on.

Well, we'll get there eventually!

> My preference is Option 1.

It is my least favorite option because it is most likely to hit interoperability
So, if the WG wants to go this way, we will have to work a little to explain how
it works and why it isn't a problem (specifically for the IESG).

> It would be hard to catch moving target around this
> area if we were to take Option 2.

I see no moving targets at all.
This is how all other vendor-specific fields are handled in protocols.
The way it works is that anyone receiving such a field looks at the first 32
bits and interprets it as an Enterprise Code from the IANA registry (hint: easy
to get and many well-known vendors have them).
If it is an Enterprise Code they recognise they process according to their own
vendor-specific knowledge about the contents.
If they don't recognise the Enterprise Code, they fail the processing.
An Enterprise will often (always?) define their own structure starting with a
version number or something similar, and often using TLVs.

What have I missed about moving targets?