From mailman-bounces@core3.amsl.com Fri Feb 1 06:12:07 2008 Return-Path: X-Original-To: ietfarch-architecture-discuss-archive@core3.amsl.com Delivered-To: ietfarch-architecture-discuss-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C314728DB36 for ; Fri, 1 Feb 2008 06:09:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.588 X-Spam-Level: X-Spam-Status: No, score=-2.588 tagged_above=-999 required=5 tests=[AWL=0.011, BAYES_00=-2.599] Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wpVHDM8euEDW for ; Fri, 1 Feb 2008 06:09:50 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ECDDE28EB20 for ; Fri, 1 Feb 2008 05:46:40 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: ietf.org mailing list memberships reminder From: mailman-owner@ietf.org To: architecture-discuss-archive@megatron.ietf.org X-No-Archive: yes Message-ID: Date: Fri, 01 Feb 2008 05:06:15 -0800 Precedence: bulk X-BeenThere: mailman@core3.amsl.com X-Mailman-Version: 2.1.9 List-Id: X-List-Administrivia: yes Sender: mailman-bounces@core3.amsl.com Errors-To: mailman-bounces@core3.amsl.com This is a reminder, sent out once a month, about your ietf.org mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, mailman-request@ietf.org) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. If you have questions, problems, comments, etc, send them to mailman-owner@ietf.org. Thanks! http://www.ietf.org/mailman/options/architecture-discuss/architecture-discuss-archive%40megatron.ietf.org From mailman-bounces@core3.amsl.com Fri Feb 1 06:19:06 2008 Return-Path: X-Original-To: ietfarch-architecture-discuss-archive@core3.amsl.com Delivered-To: ietfarch-architecture-discuss-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6910429653E for ; Fri, 1 Feb 2008 06:10:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.588 X-Spam-Level: X-Spam-Status: No, score=-2.588 tagged_above=-999 required=5 tests=[AWL=0.011, BAYES_00=-2.599] Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K-gaMAPHgkTX for ; Fri, 1 Feb 2008 06:10:41 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0E5DE28CCE7 for ; Fri, 1 Feb 2008 05:46:32 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: ietf.org mailing list memberships reminder From: mailman-owner@ietf.org To: architecture-discuss-archive@megatron.ietf.org X-No-Archive: yes Message-ID: Date: Fri, 01 Feb 2008 05:06:14 -0800 Precedence: bulk X-BeenThere: mailman@core3.amsl.com X-Mailman-Version: 2.1.9 List-Id: X-List-Administrivia: yes Sender: mailman-bounces@core3.amsl.com Errors-To: mailman-bounces@core3.amsl.com This is a reminder, sent out once a month, about your ietf.org mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, mailman-request@ietf.org) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. If you have questions, problems, comments, etc, send them to mailman-owner@ietf.org. Thanks! http://www.ietf.org/mailman/options/architecture-discuss/architecture-discuss-archive%40megatron.ietf.org From architecture-discuss-bounces@ietf.org Wed Feb 6 09:13:05 2008 Return-Path: X-Original-To: ietfarch-architecture-discuss-archive@core3.amsl.com Delivered-To: ietfarch-architecture-discuss-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BFFEC3A6F9B; Wed, 6 Feb 2008 09:13:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.45 X-Spam-Level: X-Spam-Status: No, score=-3.45 tagged_above=-999 required=5 tests=[AWL=0.149, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3I9mBLFLz9O8; Wed, 6 Feb 2008 09:13:00 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F0B173A7024; Wed, 6 Feb 2008 09:12:58 -0800 (PST) X-Original-To: architecture-discuss@core3.amsl.com Delivered-To: architecture-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A20FD3A6A09 for ; Wed, 6 Feb 2008 09:12:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xigtuGy7syyb for ; Wed, 6 Feb 2008 09:12:56 -0800 (PST) Received: from mail.songbird.com (mail.songbird.com [208.184.79.10]) by core3.amsl.com (Postfix) with ESMTP id 372503A6F59 for ; Wed, 6 Feb 2008 09:12:00 -0800 (PST) Received: from [192.168.0.6] (adsl-68-122-32-40.dsl.pltn13.pacbell.net [68.122.32.40]) (authenticated bits=0) by mail.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id m16HCqf1030661 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 6 Feb 2008 09:12:53 -0800 Message-ID: <47A9EABA.6030902@dcrocker.net> Date: Wed, 06 Feb 2008 09:13:30 -0800 From: Dave Crocker User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: architecture-discuss@ietf.org Subject: [arch-d] The proper fole of version numbers X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: architecture-discuss-bounces@ietf.org Errors-To: architecture-discuss-bounces@ietf.org Folks, Howdy. Some specifications embed a version number in the protocol or format data. Most IETF protocols do not. Over the years, I've come to believe that the lesson to us has been that version numbers really aren't all that helpful and that the proper way to distinguish truly incompatible versions is through use of a different value in the underlying multiplexing field. So, different IP field, different number, different DNS underscore "attribute", etc. As a recent, private discussion has progressed, I've started to consider the topic more interesting than I had previously thought and wondered whether there was interest amongst others to pursue it? d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org http://www.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Wed Feb 6 09:29:01 2008 Return-Path: X-Original-To: ietfarch-architecture-discuss-archive@core3.amsl.com Delivered-To: ietfarch-architecture-discuss-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DB2B13A6EB6; Wed, 6 Feb 2008 09:29:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WK2Gwomix4JD; Wed, 6 Feb 2008 09:29:00 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D65BF3A6D60; Wed, 6 Feb 2008 09:29:00 -0800 (PST) X-Original-To: architecture-discuss@core3.amsl.com Delivered-To: architecture-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 617C93A6928 for ; Wed, 6 Feb 2008 09:28:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fwbkkwbwnqar for ; Wed, 6 Feb 2008 09:28:58 -0800 (PST) Received: from QMTA03.emeryville.ca.mail.comcast.net (qmta03.emeryville.ca.mail.comcast.net [76.96.30.32]) by core3.amsl.com (Postfix) with ESMTP id 728623A6C74 for ; Wed, 6 Feb 2008 09:28:58 -0800 (PST) Received: from OMTA10.emeryville.ca.mail.comcast.net ([76.96.30.28]) by QMTA03.emeryville.ca.mail.comcast.net with comcast id mAyv1Y0010cQ2SLA30ZV00; Wed, 06 Feb 2008 17:30:17 +0000 Received: from [10.0.1.33] ([168.122.82.4]) by OMTA10.emeryville.ca.mail.comcast.net with comcast id mHWF1Y00D05biqG8W00000; Wed, 06 Feb 2008 17:30:28 +0000 X-Authority-Analysis: v=1.0 c=1 a=6PAokUpdPXcA:10 a=48vgC7mUAAAA:8 a=mF5McllnaeC28iy51-0A:9 a=xjqXu2BkOHY9fePQty4A:7 a=DDirRg3QNMpMG5hz39X3kvd7MnQA:4 a=ClmATp4dOM8A:10 a=lZB815dzVvQA:10 a=0oFHZcPLJ8YA:10 Mime-Version: 1.0 Message-Id: In-Reply-To: <47A9EABA.6030902@dcrocker.net> References: <47A9EABA.6030902@dcrocker.net> Date: Wed, 6 Feb 2008 12:24:57 -0500 To: dcrocker@bbiw.net, architecture-discuss@ietf.org From: John Day Subject: Re: [arch-d] The proper fole of version numbers X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: architecture-discuss-bounces@ietf.org Errors-To: architecture-discuss-bounces@ietf.org After years of looking at the problem and first realizing that protocol id field couldn't identify the protocol in the layer above, I concluded it was identifying the syntax of the protocol in the layer above. However further consideration determined that that was not so much wrong but the wrong direction. I finally came to the conclusion that: Any requirement for a protocol id field is an indication of either the layer boundary being in the wrong place or a poorly designed layer. Protocol id fields are unnecessary. If you need one, you have done something wrong somewhere else. Go back and re-work it. Take care, John At 9:13 -0800 2008/02/06, Dave Crocker wrote: >Folks, > >Howdy. > >Some specifications embed a version number in the protocol or format >data. Most >IETF protocols do not. > >Over the years, I've come to believe that the lesson to us has been >that version >numbers really aren't all that helpful and that the proper way to distinguish >truly incompatible versions is through use of a different value in the >underlying multiplexing field. So, different IP field, different > number, different DNS underscore "attribute", etc. > >As a recent, private discussion has progressed, I've started to consider the >topic more interesting than I had previously thought and wondered >whether there >was interest amongst others to pursue it? > >d/ > >-- > > Dave Crocker > Brandenburg InternetWorking > bbiw.net >_______________________________________________ >Architecture-discuss mailing list >Architecture-discuss@ietf.org >http://www.ietf.org/mailman/listinfo/architecture-discuss _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org http://www.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Wed Feb 6 09:43:23 2008 Return-Path: X-Original-To: ietfarch-architecture-discuss-archive@core3.amsl.com Delivered-To: ietfarch-architecture-discuss-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 716583A6E43; Wed, 6 Feb 2008 09:43:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DZRTQkaC2ne4; Wed, 6 Feb 2008 09:43:19 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2067B3A6FB2; Wed, 6 Feb 2008 09:43:19 -0800 (PST) X-Original-To: architecture-discuss@core3.amsl.com Delivered-To: architecture-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0A4B63A6FB2 for ; Wed, 6 Feb 2008 09:43:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y7U4tSd6IosI for ; Wed, 6 Feb 2008 09:43:17 -0800 (PST) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 54CEC3A6E43 for ; Wed, 6 Feb 2008 09:43:12 -0800 (PST) Received: from webmail.isi.edu (webmail.isi.edu [128.9.152.28]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id m16HiIgo028048 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 6 Feb 2008 09:44:19 -0800 (PST) Received: (from apache@localhost) by webmail.isi.edu (8.12.8/8.12.7) id m16Hi8kr031276; Wed, 6 Feb 2008 09:44:08 -0800 X-Authentication-Warning: webmail.isi.edu: apache set sender to touch@isi.edu using -f Received: from system212-8.losangeles.af.mil (system212-8.losangeles.af.mil [138.13.212.8]) by webmail.isi.edu (IMP) with HTTP for ; Wed, 6 Feb 2008 09:44:08 -0800 Message-ID: <1202319848.47a9f1e80db19@webmail.isi.edu> Date: Wed, 6 Feb 2008 09:44:08 -0800 From: touch@ISI.EDU To: dcrocker@bbiw.net, Dave Crocker References: <47A9EABA.6030902@dcrocker.net> In-Reply-To: <47A9EABA.6030902@dcrocker.net> MIME-Version: 1.0 User-Agent: Internet Messaging Program (IMP) 3.2.2 X-Originating-IP: 138.13.212.8 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: architecture-discuss@ietf.org Subject: Re: [arch-d] The proper fole of version numbers X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: architecture-discuss-bounces@ietf.org Errors-To: architecture-discuss-bounces@ietf.org Quoting Dave Crocker : > Folks, > > Howdy. > > Some specifications embed a version number in the protocol or format data. > Most IETF protocols do not. I noted this when a blanket request for "lessons learned" went out. > Over the years, I've come to believe that the lesson to us has been that > version numbers really aren't all that helpful and that the proper > way to distinguish truly incompatible versions is through use of a > different value in the underlying multiplexing field. > So, different IP field, different > number, different DNS underscore "attribute", etc. I'd like to understand this more. There are two muxing fields - one defined in the higher level (e.g., Ethernet frames), and one inside the protocol (e.g., IP version). The pair is the overall demuxing; the key question is whether ethernet needs to demux IPv4 differently from IPv6 (FWIW, it currently does, rendering the IP version field moot for ethernet-encapsulated frames). IMO, versioning is the responsibility of the protocol itself, not the parent protocol. Version changes are defined and should thus be contained entirely within a protocol. It doesn't make sense to consume shared demux space at the outer layer protocol to handle problems created by only a subset of protocols. The cost of putting the version field inside the protocol itself is the cost of pinning the first bits of header, and often also then requires the chunksize (8, 16, 32, ... bits), bit, and word order to be fixed through at least the version area. I don't consider this a big issue; if a protocol changes word order, then it can be issued a new higher-level number. IMO, the two () should be considered major/minor revision numbers. There are cases where it is appropriate to increment either; I don't see a great argument to force all increments to occur in either side of that overall field, though I prefer to err on the "keep your mess to yourself" position that says "think twice before incrementing , then don't unless there's no other way". > As a recent, private discussion has progressed, I've started to consider the > topic more interesting than I had previously thought and wondered whether > there was interest amongst others to pursue it? Count me in, obviously... Joe _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org http://www.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Wed Feb 6 10:57:09 2008 Return-Path: X-Original-To: ietfarch-architecture-discuss-archive@core3.amsl.com Delivered-To: ietfarch-architecture-discuss-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 89A6A3A709C; Wed, 6 Feb 2008 10:57:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r4RphQfJhg7d; Wed, 6 Feb 2008 10:57:08 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6F9A93A7093; Wed, 6 Feb 2008 10:57:05 -0800 (PST) X-Original-To: architecture-discuss@core3.amsl.com Delivered-To: architecture-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 150BF3A6E6C for ; Wed, 6 Feb 2008 10:57:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fyk-r0pIKReO for ; Wed, 6 Feb 2008 10:57:03 -0800 (PST) Received: from bender-mail.tigertech.net (bender-mail.tigertech.net [64.62.209.30]) by core3.amsl.com (Postfix) with ESMTP id 7AC753A7074 for ; Wed, 6 Feb 2008 10:56:27 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by bender.tigertech.net (Postfix) with ESMTP id 3B37A7DE5; Wed, 6 Feb 2008 10:57:59 -0800 (PST) Received: from [192.168.0.100] (pool-71-161-50-169.clppva.east.verizon.net [71.161.50.169]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by bender.tigertech.net (Postfix) with ESMTP id 94CB67E58; Wed, 6 Feb 2008 10:57:56 -0800 (PST) Message-ID: <47AA032F.4020508@joelhalpern.com> Date: Wed, 06 Feb 2008 13:57:51 -0500 From: "Joel M. Halpern" User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: dcrocker@bbiw.net References: <47A9EABA.6030902@dcrocker.net> In-Reply-To: <47A9EABA.6030902@dcrocker.net> X-Enigmail-Version: 0.95.6 X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net Cc: architecture-discuss@ietf.org Subject: Re: [arch-d] The proper fole of version numbers X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: architecture-discuss-bounces@ietf.org Errors-To: architecture-discuss-bounces@ietf.org This is something I have debated in quite a few contexts. It seems to me that there are a range of needs, and that a version number can be useful for a specific subset of that range. People frequently tend to treat it much too broadly. I will start however with a caveat. While the following theoretical perspective seems to suggest significant value for a version number, and I frequently try to design one in for these needs, I note that there are few or no places where it has actually been both needed and effective. So the following may be a classic case of something that looks good in theory, but not in practice. With most of the protocols we design, we use a core basic mechanism, and then some form of extension or addition. We hope and try to get it right that the extension mechanisms will be sufficient for what we need. However, it seems sensible to also design for needing to change the basic mechanism (the mandatory fields in the basic message header, or similar core items.) If one wants to deploy such a change, the ability to negotiate which basic header one is using, or at least to confirm compatibility of that basic header, seems very useful. Even if one is not negotiating, the ability to support more than one variation, and to use the one that the other party supports, is conceptually powerful. This seems to work better in pairwise protocols with an opening negotiation (such as BGP or PNNI) than in protocols for more dynamic communication establishment (such as IP or SIP) Yours, Joel Dave Crocker wrote: > Folks, > > Howdy. > > Some specifications embed a version number in the protocol or format data. Most > IETF protocols do not. > > Over the years, I've come to believe that the lesson to us has been that version > numbers really aren't all that helpful and that the proper way to distinguish > truly incompatible versions is through use of a different value in the > underlying multiplexing field. So, different IP field, different > number, different DNS underscore "attribute", etc. > > As a recent, private discussion has progressed, I've started to consider the > topic more interesting than I had previously thought and wondered whether there > was interest amongst others to pursue it? > > d/ > _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org http://www.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Wed Feb 6 11:32:18 2008 Return-Path: X-Original-To: ietfarch-architecture-discuss-archive@core3.amsl.com Delivered-To: ietfarch-architecture-discuss-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EF5273A708F; Wed, 6 Feb 2008 11:32:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.977 X-Spam-Level: X-Spam-Status: No, score=-101.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, USER_IN_WHITELIST=-100] Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AnJyTEFUGI0T; Wed, 6 Feb 2008 11:32:18 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0DCB83A6E8E; Wed, 6 Feb 2008 11:32:17 -0800 (PST) X-Original-To: architecture-discuss@core3.amsl.com Delivered-To: architecture-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4FEC03A6F75 for ; Wed, 6 Feb 2008 11:32:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JF6MUvg6muZP for ; Wed, 6 Feb 2008 11:32:13 -0800 (PST) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.178]) by core3.amsl.com (Postfix) with ESMTP id 32A333A7050 for ; Wed, 6 Feb 2008 11:31:31 -0800 (PST) Received: by wa-out-1112.google.com with SMTP id k40so6288242wah.25 for ; Wed, 06 Feb 2008 11:33:03 -0800 (PST) Received: by 10.114.77.1 with SMTP id z1mr3283723waa.56.1202326383402; Wed, 06 Feb 2008 11:33:03 -0800 (PST) Received: by 10.115.48.17 with HTTP; Wed, 6 Feb 2008 11:33:03 -0800 (PST) Message-ID: Date: Wed, 6 Feb 2008 14:33:03 -0500 From: "Mark Baker" To: dcrocker@bbiw.net In-Reply-To: <47A9EABA.6030902@dcrocker.net> MIME-Version: 1.0 Content-Disposition: inline References: <47A9EABA.6030902@dcrocker.net> X-Google-Sender-Auth: 7f14478e03ed200f Cc: architecture-discuss@ietf.org Subject: Re: [arch-d] The proper fole of version numbers X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: architecture-discuss-bounces@ietf.org Errors-To: architecture-discuss-bounces@ietf.org On 2/6/08, Dave Crocker wrote: > Folks, > > Howdy. > > Some specifications embed a version number in the protocol or format data. Most > IETF protocols do not. > > Over the years, I've come to believe that the lesson to us has been that version > numbers really aren't all that helpful and that the proper way to distinguish > truly incompatible versions is through use of a different value in the > underlying multiplexing field. So, different IP field, different > number, different DNS underscore "attribute", etc. I think there's a place for both approaches, but I do agree that the encapsulating layer mux/dispatch-point isn't used as often as it should be. > As a recent, private discussion has progressed, I've started to consider the > topic more interesting than I had previously thought and wondered whether there > was interest amongst others to pursue it? A BCP for protocol versioning sounds like a good idea. FWIW, at the top of the protocol stack is data versioning, which the W3C TAG (BCCd, because I'm sure they'd be interested) has been exploring; http://www.w3.org/2001/tag/doc/versioning Mark. -- Mark Baker. Ottawa, Ontario, CANADA. http://www.markbaker.ca Coactus; Web-inspired integration strategies http://www.coactus.com _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org http://www.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Wed Feb 6 12:49:16 2008 Return-Path: X-Original-To: ietfarch-architecture-discuss-archive@core3.amsl.com Delivered-To: ietfarch-architecture-discuss-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BFE1E3A71D3; Wed, 6 Feb 2008 12:49:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.235 X-Spam-Level: X-Spam-Status: No, score=-2.235 tagged_above=-999 required=5 tests=[AWL=0.364, BAYES_00=-2.599] Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1-Z9LQNrHoUk; Wed, 6 Feb 2008 12:49:15 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E0EB23A7286; Wed, 6 Feb 2008 12:49:13 -0800 (PST) X-Original-To: architecture-discuss@core3.amsl.com Delivered-To: architecture-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E025B3A693F for ; Wed, 6 Feb 2008 12:49:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4wvmIKIbUU65 for ; Wed, 6 Feb 2008 12:49:12 -0800 (PST) Received: from wr-out-0506.google.com (wr-out-0506.google.com [64.233.184.235]) by core3.amsl.com (Postfix) with ESMTP id 1A85D3A720B for ; Wed, 6 Feb 2008 12:48:58 -0800 (PST) Received: by wr-out-0506.google.com with SMTP id 50so3660387wri.25 for ; Wed, 06 Feb 2008 12:50:29 -0800 (PST) Received: by 10.141.180.5 with SMTP id h5mr6974948rvp.240.1202331028254; Wed, 06 Feb 2008 12:50:28 -0800 (PST) Received: from ?130.216.38.124? ( [130.216.38.124]) by mx.google.com with ESMTPS id k19sm8291640rvb.18.2008.02.06.12.50.27 (version=SSLv3 cipher=RC4-MD5); Wed, 06 Feb 2008 12:50:28 -0800 (PST) Message-ID: <47AA1D92.1090807@gmail.com> Date: Thu, 07 Feb 2008 09:50:26 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: dcrocker@bbiw.net References: <47A9EABA.6030902@dcrocker.net> In-Reply-To: <47A9EABA.6030902@dcrocker.net> Cc: architecture-discuss@ietf.org Subject: Re: [arch-d] The proper fole of version numbers X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: architecture-discuss-bounces@ietf.org Errors-To: architecture-discuss-bounces@ietf.org I'd be grateful if people interested in this question would have a look at http://tools.ietf.org/id/draft-carpenter-extension-recs-02.txt and say whether (a) it's worth resuming work on it (b) what it has to say about versioning makes sense. fwiw I think the abstract value of version numbers depends very much on whether the versioning handles backwards compatibility or not. If you break compatibility, the version number effectively says "this is a new protocol." But since protocol numbers and assigned ports are finite resources, maybe that's what we have to do. Brian On 2008-02-07 06:13, Dave Crocker wrote: > Folks, > > Howdy. > > Some specifications embed a version number in the protocol or format data. Most > IETF protocols do not. > > Over the years, I've come to believe that the lesson to us has been that version > numbers really aren't all that helpful and that the proper way to distinguish > truly incompatible versions is through use of a different value in the > underlying multiplexing field. So, different IP field, different > number, different DNS underscore "attribute", etc. > > As a recent, private discussion has progressed, I've started to consider the > topic more interesting than I had previously thought and wondered whether there > was interest amongst others to pursue it? > > d/ > _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org http://www.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Wed Feb 6 14:08:10 2008 Return-Path: X-Original-To: ietfarch-architecture-discuss-archive@core3.amsl.com Delivered-To: ietfarch-architecture-discuss-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B5DF73A7239; Wed, 6 Feb 2008 14:08:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EcFNaXhs0ZPZ; Wed, 6 Feb 2008 14:08:10 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8A0013A7068; Wed, 6 Feb 2008 14:08:09 -0800 (PST) X-Original-To: architecture-discuss@core3.amsl.com Delivered-To: architecture-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E4CA63A67ED for ; Wed, 6 Feb 2008 14:08:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BsUbJhWaYqK5 for ; Wed, 6 Feb 2008 14:08:05 -0800 (PST) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 4F1843A70D2 for ; Wed, 6 Feb 2008 14:08:04 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.25,314,1199692800"; d="scan'208";a="5211346" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-4.cisco.com with ESMTP; 06 Feb 2008 14:09:35 -0800 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m16M9ZPR007823; Wed, 6 Feb 2008 14:09:35 -0800 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id m16M9VAZ003307; Wed, 6 Feb 2008 22:09:35 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 6 Feb 2008 14:09:31 -0800 Received: from [171.70.245.89] ([171.70.245.89]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 6 Feb 2008 14:09:30 -0800 In-Reply-To: <47AA032F.4020508@joelhalpern.com> References: <47A9EABA.6030902@dcrocker.net> <47AA032F.4020508@joelhalpern.com> Mime-Version: 1.0 (Apple Message framework v753) Message-Id: <8D874E70-BC06-4F01-AF1C-6CBB54332C08@cisco.com> From: Tony Li Date: Wed, 6 Feb 2008 14:09:30 -0800 To: "Joel M. Halpern" X-Mailer: Apple Mail (2.753) X-OriginalArrivalTime: 06 Feb 2008 22:09:30.0947 (UTC) FILETIME=[F2864930:01C8690C] Authentication-Results: sj-dkim-1; header.From=tli@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Cc: dcrocker@bbiw.net, architecture-discuss@ietf.org Subject: Re: [arch-d] The proper fole of version numbers X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: architecture-discuss-bounces@ietf.org Errors-To: architecture-discuss-bounces@ietf.org On Feb 6, 2008, at 10:57 AM, Joel M. Halpern wrote: > I will start however with a caveat. While the following theoretical > perspective seems to suggest significant value for a version > number, and > I frequently try to design one in for these needs, I note that > there are > few or no places where it has actually been both needed and effective. > So the following may be a classic case of something that looks good in > theory, but not in practice. > > With most of the protocols we design, we use a core basic > mechanism, and > then some form of extension or addition. We hope and try to get it > right that the extension mechanisms will be sufficient for what we > need. > However, it seems sensible to also design for needing to change the > basic mechanism (the mandatory fields in the basic message header, or > similar core items.) If one wants to deploy such a change, the > ability > to negotiate which basic header one is using, or at least to confirm > compatibility of that basic header, seems very useful. > Even if one is not negotiating, the ability to support more than one > variation, and to use the one that the other party supports, is > conceptually powerful. > This seems to work better in pairwise protocols with an opening > negotiation (such as BGP or PNNI) than in protocols for more dynamic > communication establishment (such as IP or SIP) I'll have to largely agree with this. In my experience, encoding first for extensibility is a requirement (e.g., TLVs). Once you've done this, you've necessarily made some design choices that involve finite fields (e.g., how many type codes do you have?). Having a version number elsewhere in the packet is some cheap insurance against running out of type codes or making the type field much larger than would seem optimal. The same reasoning would seem to apply to avoiding issues of an inadequate or oversized length field. A version number also allows you to make other changes to the fixed header in the message, Tony _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org http://www.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Wed Feb 6 17:30:53 2008 Return-Path: X-Original-To: ietfarch-architecture-discuss-archive@core3.amsl.com Delivered-To: ietfarch-architecture-discuss-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 66EF73A7126; Wed, 6 Feb 2008 17:30:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zg8le1Pn5+Eh; Wed, 6 Feb 2008 17:30:52 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 54EE33A6DE6; Wed, 6 Feb 2008 17:30:52 -0800 (PST) X-Original-To: architecture-discuss@core3.amsl.com Delivered-To: architecture-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 97A073A6E19 for ; Wed, 6 Feb 2008 17:30:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zbFpaYYlxVHc for ; Wed, 6 Feb 2008 17:30:49 -0800 (PST) Received: from QMTA05.emeryville.ca.mail.comcast.net (qmta05.emeryville.ca.mail.comcast.net [76.96.30.48]) by core3.amsl.com (Postfix) with ESMTP id 9B8E83A6DE6 for ; Wed, 6 Feb 2008 17:30:49 -0800 (PST) Received: from OMTA12.emeryville.ca.mail.comcast.net ([76.96.30.44]) by QMTA05.emeryville.ca.mail.comcast.net with comcast id mJyv1Y00X0x6nqcA50Qj00; Thu, 07 Feb 2008 01:32:09 +0000 Received: from [10.192.28.6] ([66.31.246.32]) by OMTA12.emeryville.ca.mail.comcast.net with comcast id mRYF1Y0060igBKW8Y00000; Thu, 07 Feb 2008 01:32:18 +0000 X-Authority-Analysis: v=1.0 c=1 a=6PAokUpdPXcA:10 a=48vgC7mUAAAA:8 a=_Luv4s8Ria3zxAwnBUQA:9 a=kGxoCOlq5ANXui22Q4IA:7 a=4PxdmAJdR5SE0wwETDswXbCFQLsA:4 a=lZB815dzVvQA:10 a=gi0PWCVxevcA:10 Mime-Version: 1.0 Message-Id: In-Reply-To: <8D874E70-BC06-4F01-AF1C-6CBB54332C08@cisco.com> References: <47A9EABA.6030902@dcrocker.net> <47AA032F.4020508@joelhalpern.com> <8D874E70-BC06-4F01-AF1C-6CBB54332C08@cisco.com> Date: Wed, 6 Feb 2008 20:28:19 -0500 To: Tony Li , "Joel M. Halpern" From: John Day Cc: dcrocker@bbiw.net, architecture-discuss@ietf.org Subject: Re: [arch-d] The proper fole of version numbers X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: architecture-discuss-bounces@ietf.org Errors-To: architecture-discuss-bounces@ietf.org I would have to agree with Tony and Joel on version number fields. They seem better in theory than useful in practice. Probably a waste of time. Better to simply design the protocol to be extensible. But from what I have seen of the modern class of protocols, extensibility is essentially the degenerate case. Version numbers were interesting 20 years ago, but not now. And as Joel indicated, even then it looked better in theory than it turned out in practice. Take care, At 14:09 -0800 2008/02/06, Tony Li wrote: >On Feb 6, 2008, at 10:57 AM, Joel M. Halpern wrote: > >> I will start however with a caveat. While the following theoretical >> perspective seems to suggest significant value for a version >> number, and >> I frequently try to design one in for these needs, I note that >> there are >> few or no places where it has actually been both needed and effective. >> So the following may be a classic case of something that looks good in >> theory, but not in practice. >> >> With most of the protocols we design, we use a core basic >> mechanism, and >> then some form of extension or addition. We hope and try to get it >> right that the extension mechanisms will be sufficient for what we >> need. >> However, it seems sensible to also design for needing to change the >> basic mechanism (the mandatory fields in the basic message header, or >> similar core items.) If one wants to deploy such a change, the >> ability >> to negotiate which basic header one is using, or at least to confirm >> compatibility of that basic header, seems very useful. >> Even if one is not negotiating, the ability to support more than one >> variation, and to use the one that the other party supports, is >> conceptually powerful. >> This seems to work better in pairwise protocols with an opening >> negotiation (such as BGP or PNNI) than in protocols for more dynamic >> communication establishment (such as IP or SIP) > > >I'll have to largely agree with this. In my experience, encoding >first for extensibility is a requirement (e.g., TLVs). Once you've >done this, you've necessarily made some design choices that involve >finite fields (e.g., how many type codes do you have?). Having a >version number elsewhere in the packet is some cheap insurance >against running out of type codes or making the type field much >larger than would seem optimal. The same reasoning would seem to >apply to avoiding issues of an inadequate or oversized length field. >A version number also allows you to make other changes to the fixed >header in the message, > >Tony > >_______________________________________________ >Architecture-discuss mailing list >Architecture-discuss@ietf.org >http://www.ietf.org/mailman/listinfo/architecture-discuss _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org http://www.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Fri Feb 8 11:20:51 2008 Return-Path: X-Original-To: ietfarch-architecture-discuss-archive@core3.amsl.com Delivered-To: ietfarch-architecture-discuss-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5457328C495; Fri, 8 Feb 2008 11:20:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.823 X-Spam-Level: X-Spam-Status: No, score=-1.823 tagged_above=-999 required=5 tests=[AWL=0.776, BAYES_00=-2.599] Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WQoVg680BD38; Fri, 8 Feb 2008 11:20:50 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 50AAA28C3E9; Fri, 8 Feb 2008 11:20:50 -0800 (PST) X-Original-To: architecture-discuss@core3.amsl.com Delivered-To: architecture-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4949E28C480 for ; Fri, 8 Feb 2008 11:20:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F1aJKyGHDdHO for ; Fri, 8 Feb 2008 11:20:48 -0800 (PST) Received: from mk-outboundfilter-1.mail.uk.tiscali.com (mk-outboundfilter-1.mail.uk.tiscali.com [212.74.114.37]) by core3.amsl.com (Postfix) with ESMTP id 1FF4328C362 for ; Fri, 8 Feb 2008 11:20:47 -0800 (PST) X-Trace: 36959544/mk-outboundfilter-1.mail.uk.tiscali.com/PIPEX/$MX-ACCEPTED/pipex-infrastructure/62.241.163.7 X-SBRS: None X-RemoteIP: 62.241.163.7 X-IP-MAIL-FROM: cfinss@dial.pipex.com X-IP-BHB: Once X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CACE7rEc+8aMH/2dsb2JhbACKYocmmmI X-IP-Direction: IN Received: from blaster.systems.pipex.net ([62.241.163.7]) by smtp.pipex.tiscali.co.uk with ESMTP; 08 Feb 2008 19:22:17 +0000 Received: from pc6 (1Cust171.tnt3.lnd4.gbr.da.uu.net [62.188.132.171]) by blaster.systems.pipex.net (Postfix) with SMTP id CF8C4E000088; Fri, 8 Feb 2008 19:22:14 +0000 (GMT) Message-ID: <002201c86a7f$3d3da4a0$0601a8c0@pc6> From: "tom.petch" To: , , "Dave Crocker" References: <47A9EABA.6030902@dcrocker.net> <1202319848.47a9f1e80db19@webmail.isi.edu> Date: Fri, 8 Feb 2008 18:11:11 +0100 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Cc: architecture-discuss@ietf.org Subject: Re: [arch-d] The proper fole of version numbers X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: "tom.petch" List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: architecture-discuss-bounces@ietf.org Errors-To: architecture-discuss-bounces@ietf.org I suspect that it depends on where you are sitting in software development process. If you introduce a new version number, then the software for the old version number must be updated to demux the new version to the appropriate handler. If you use the SAP of the underlying protocol, then your software can continue unaltered, but the software of the underlying protocol must be updated to demux to something else. But if you are a user, who looks at protocol decodes to determine why a network is not working as it should, then having the information all in one place, a version number in the protocol header is always to be preferred, as 'helpful' protocol decoders have a habit of stripping off the lower, 'less interesting' layers. I think that SNMP, retaining the header format and updating the version number, gets it absolutely right. Tom Petch ----- Original Message ----- From: To: ; "Dave Crocker" Cc: Sent: Wednesday, February 06, 2008 6:44 PM Subject: Re: [arch-d] The proper fole of version numbers > Quoting Dave Crocker : > > > Folks, > > > > Howdy. > > > > Some specifications embed a version number in the protocol or format data. > > Most IETF protocols do not. > > I noted this when a blanket request for "lessons learned" went out. > > > Over the years, I've come to believe that the lesson to us has been that > > version numbers really aren't all that helpful and that the proper > > way to distinguish truly incompatible versions is through use of a > > different value in the underlying multiplexing field. > > So, different IP field, different > > number, different DNS underscore "attribute", etc. > > I'd like to understand this more. There are two muxing fields - one defined in > the higher level (e.g., Ethernet frames), and one inside the protocol (e.g., IP > version). The pair is the overall demuxing; the key > question is whether ethernet needs to demux IPv4 differently from IPv6 (FWIW, > it currently does, rendering the IP version field moot for > ethernet-encapsulated frames). > > IMO, versioning is the responsibility of the protocol itself, not the parent > protocol. Version changes are defined and should thus be contained entirely > within a protocol. It doesn't make sense to consume shared demux space at the > outer layer protocol to handle problems created by only a subset of protocols. > > > The cost of putting the version field inside the protocol itself is the cost of > pinning the first bits of header, and often also then requires the chunksize > (8, 16, 32, ... bits), bit, and word order to be fixed through at least the > version area. I don't consider this a big issue; if a protocol changes word > order, then it can be issued a new higher-level number. > > IMO, the two () should be considered major/minor revision numbers. > There are cases where it is appropriate to increment either; I don't see a > great argument to force all increments to occur in either side of that overall > field, though I prefer to err on the "keep your mess to yourself" position that > says "think twice before incrementing , then don't unless there's no > other way". > > > As a recent, private discussion has progressed, I've started to consider the > > topic more interesting than I had previously thought and wondered whether > > there was interest amongst others to pursue it? > > Count me in, obviously... > > Joe > _______________________________________________ > Architecture-discuss mailing list > Architecture-discuss@ietf.org > http://www.ietf.org/mailman/listinfo/architecture-discuss _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org http://www.ietf.org/mailman/listinfo/architecture-discuss