From discuss-bounces@apps.ietf.org Sat Dec 01 20:38:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iydlc-0003gA-8h; Sat, 01 Dec 2007 20:37:08 -0500 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1Iy7ts-0006yW-7Y for discuss-confirm+ok@megatron.ietf.org; Fri, 30 Nov 2007 10:35:32 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iy7tr-0006y4-Ti for discuss@apps.ietf.org; Fri, 30 Nov 2007 10:35:31 -0500 Received: from qmta03.emeryville.ca.mail.comcast.net ([76.96.30.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iy7tq-0002Tc-UC for discuss@apps.ietf.org; Fri, 30 Nov 2007 10:35:31 -0500 Received: from OMTA07.emeryville.ca.mail.comcast.net ([76.96.30.59]) by QMTA03.emeryville.ca.mail.comcast.net with comcast id K1XX1Y0081GXsuc0A0AC00; Fri, 30 Nov 2007 15:35:34 +0000 Received: from Harrington73653 ([24.128.104.207]) by OMTA07.emeryville.ca.mail.comcast.net with comcast id K3bU1Y00B4UVsHU0800000; Fri, 30 Nov 2007 15:35:34 +0000 X-Authority-Analysis: v=1.0 c=1 a=KSJUxJzPonUA:10 a=nKLD2Io1NIw4iaqvex4A:9 a=Tw-MUFs4hJt1eTxRKQoA:7 a=UJ77OrrZXaJLDYQLrM8z5A4y5kQA:4 a=si9q_4b84H0A:10 a=gJcimI5xSWUA:10 From: "David Harrington" To: "'Andy Bierman'" , References: <474E0F71.2050003@andybierman.com> Subject: Why NETCONF needs a data modeling language Date: Fri, 30 Nov 2007 10:35:13 -0500 Message-ID: <241201c83366$9acf8070$6502a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <474E0F71.2050003@andybierman.com> Thread-Index: AcgyI3BWX50RoOCBS32El4WAOg2IiQBOy49g X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Spam-Score: 0.0 (/) X-Scan-Signature: 2086112c730e13d5955355df27e3074b X-Mailman-Approved-At: Sat, 01 Dec 2007 20:37:07 -0500 Cc: yang@ietf.org, 'NETCONF Goes On' X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org > Hi, > > There are a few questions that the IESG and others have asked, > which I will try to address: > > Q1) Why does NETCONF need a DML at all? > Q2) Why is NETCONF special? > Q3) Why won't lots of other WGs want to define their own > protocol-specific DMLs? > Q4) Why isn't XSD or RelaxNG good enough? I'll take a whack at answering the same questions. A1) Why does NETCONF need a DML at all? to promote vendor-neutral interoperable management. It is much easier to develop standards when everybody uses the same basic language to communicate; this "common language for shared communication" is also reflected in the IETF decision to use English text and ASCII documents. This is not just about being able to standardize **device management**; it is a basic step to permit the standardization of **network management** and possibly **services management". The DML is a basic building block. A2) Why is NETCONF special? It is and it isn't. Netconf is only one protocol used for network management. It has some unique requirements, such as using a document-based approach and differentiating the data for config versus state and for dealing with different time-defined contexts such as running and startup configs. This differs from other network management protocols, such as SNMP and syslog and ipfix, which use their own data formats, and usually deal only with the currently-running config. Netconf is a tool designed to meet the special requirements of configuration, and the DML needs to support special features not found in other NM-DMLs. Netconf is not special, in that any language used for network management is likely to have certain common requirements. NM data models are commonly used directly by humans, in their raw form, such as when they troubleshoot problems using network sniffers. NM data models are also commonly used by NMS applications that can handle the translations into a more human-readable format. Designers of NM tools (e.g., protocols and data models) thus need to pay close attention to who will use the information, and to assume that the data will be used both directly by humans and by applications. Operators have complained strongly that OIDs are very hard to work with in raw form, yet operators frequently need to deal with the raw form of the data. A3) Why won't lots of other WGs want to define their own protocol-specific DMLs? To paraphrase a wise man from the SNMP community, when you fill a room with protocol designers and ask for a solution to a problem, is it a surprise when they recommend designing a new protocol? The decision about whether to use an existing protocol/DML or develop a new protocol/DML should be made after a careful analysis of the requirements of the solution. SNMP was designed when CMIP was found to not quite address the needs. The SMI was designed when ASN.1 was found to not quite address the needs. XML was designed when other DMLs were found to not quite address the needs. The decision to explore an XML-based DML and to explore a C-like DML follows years and years and years of debate over the requiremnts of network management, and configuration in particular. If every WG spends as much time analyzing the requirements that the OPS area has spent considering this decision, it might be good for ensuring no new protoocls are designed that are not really needed, but the IETF would also grind to a halt, much as the OPS community has done over our many years of debate. And the delay caused by our debates has made IETF network management largely irrelevant to the operator community (our customers). As always, we need to be vigilant and determine whether enough thought has been given to reuse of existing protocols. We also need to consider the tradeoffs between new protocols and reusing existing protocols in ways they were not designed to be used. A4) Why isn't XSD or RelaxNG good enough? As mentioned in A2, NM data models need to be both machine- and human-readable. XSD is machine-readable, but it is a tough language for humans. RelaxNG seems better. As discussed further in a different email, Netconf will almost certainly need a DML suited to its requirements, and if RelaxNG is found to be human-friendly-enough, we would almost certainly still need to select a subset and adapt it to meet configuration requirements. So the benefit of using RelaxNG over a domain-specific DML may be lost by using an adapted-subset of RelaxNG. Most operators already understand languages like Perl and C and Javascript, because they already need to write lots of scripts to manage their networks. Most implementers of NM support in internetworking devices work in C or a variant of C. It makes a lot of sense to use a language with a C-like syntax for these people, rather than forcing them to learn yet another language that was designed for some other purpose. [soap] somebody commented that the designers of XSD and RelaxNG really understand how to design DMLs, implying that the OPS community does not. Many of the people involved in the ongoing DML discussions over the years, and now, are MIB Doctors and operators and protocol designers, and have had years of experience designing and working with SMI and network management. They understand the requirements of a DML for NM far more than the designers of XSD or RelaxNG, who were not designing their DMLs for NM purposes. [end soap] David Harrington dbharrington@comcast.net ietfdbh@comcast.net From discuss-bounces@apps.ietf.org Sat Dec 01 20:38:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iydls-00045j-FC; Sat, 01 Dec 2007 20:37:24 -0500 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1IyBWn-0002SO-2L for discuss-confirm+ok@megatron.ietf.org; Fri, 30 Nov 2007 14:27:57 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IyBWm-0002Pq-Mi for discuss@apps.ietf.org; Fri, 30 Nov 2007 14:27:56 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IyBWm-0007Ln-C8 for discuss@apps.ietf.org; Fri, 30 Nov 2007 14:27:56 -0500 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-5.cisco.com with ESMTP; 30 Nov 2007 11:27:55 -0800 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id lAUJRtFi020739; Fri, 30 Nov 2007 11:27:55 -0800 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id lAUJRV27004362; Fri, 30 Nov 2007 19:27:55 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 30 Nov 2007 11:27:47 -0800 Received: from dhcp-171-71-97-219.cisco.com ([171.71.97.219]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 30 Nov 2007 11:27:46 -0800 Message-ID: <4750642E.7040307@cisco.com> Date: Fri, 30 Nov 2007 11:27:42 -0800 From: Jim Fenton User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: tbray@textuality.com Subject: Re: My XML session Sunday 3PM References: <517bf110711301021u651701aclff2a63ee37877d2@mail.gmail.com> In-Reply-To: <517bf110711301021u651701aclff2a63ee37877d2@mail.gmail.com> X-Enigmail-Version: 0.95.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 30 Nov 2007 19:27:46.0942 (UTC) FILETIME=[1665A1E0:01C83387] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=993; t=1196450875; x=1197314875; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fenton@cisco.com; z=From:=20Jim=20Fenton=20 |Subject:=20Re=3A=20My=20XML=20session=20Sunday=203PM |Sender:=20; bh=Yi8wi+oveTWCGLwhcoSm3lLmACIsKnCurxiELAbl50w=; b=lqkaz5o8qeE7oo1/LhtIV7axhxXmt9UcU64VzqKFp8xO4dQwPkHMq+DkWdHYlMKO4Xj8t0Ni GwNjgWLAW3wMg0aiM/DN5mQYSn/1orl7XEnDiO8wRgAxpN1LrbtR82Xh; Authentication-Results: sj-dkim-3; header.From=fenton@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 X-Mailman-Approved-At: Sat, 01 Dec 2007 20:37:22 -0500 Cc: Apps Discuss X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org Sounds interesting. Where will you be? -Jim Tim Bray wrote: > Since my agenda isn't posted on the IETF70 site, it might be helpful > for people planning their Sundays to know it, and be sure to stay > away: > > - How to think about whether XML is a good choice or not for use in an > Internet protocol. There are alternatives which are often superior > choices. > - If you are going to use XML, how to think about inventing your own > language as opposed to using an existing one, with a review of some > popular languages you might want to consider adopting. > - If you are going to design your own language, how you might go about > doing so. This would include discussion of: > -- verbosity vs. terseness > -- the use of schemas, and the choice of available schema languages > -- extensibility > -- i18n and encoding issues > > Plus, the crowd will probably be small, so if you have your own > XML/IETF issue that needs discussion, bring it along. -T > > From discuss-bounces@apps.ietf.org Sat Dec 01 20:38:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iydlc-0003g4-50; Sat, 01 Dec 2007 20:37:08 -0500 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1Iy6uM-0004ih-Mc for discuss-confirm+ok@megatron.ietf.org; Fri, 30 Nov 2007 09:31:58 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iy6uM-0004iN-Bg for discuss@apps.ietf.org; Fri, 30 Nov 2007 09:31:58 -0500 Received: from qmta05.emeryville.ca.mail.comcast.net ([76.96.30.48]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iy6uJ-0002AI-2k for discuss@apps.ietf.org; Fri, 30 Nov 2007 09:31:58 -0500 Received: from OMTA13.emeryville.ca.mail.comcast.net ([76.96.30.52]) by QMTA05.emeryville.ca.mail.comcast.net with comcast id JzVe1Y00417UAYk0A0Dd00; Fri, 30 Nov 2007 14:31:58 +0000 Received: from Harrington73653 ([24.128.104.207]) by OMTA13.emeryville.ca.mail.comcast.net with comcast id K2Xs1Y00A4UVsHU0800000; Fri, 30 Nov 2007 14:31:58 +0000 X-Authority-Analysis: v=1.0 c=1 a=I0y0xKm2-w0A:10 a=j3Z76cjpAAAA:8 a=48vgC7mUAAAA:8 a=m7Gx0nXtxD0cURmhWtoA:9 a=Jbp6iasmxlNv7zYQp5EA:7 a=p7ZV2XQxOjHVSLzO9rel6YhuadgA:4 a=lZB815dzVvQA:10 a=FvgKqOQ44qUA:10 a=JrSEOxZJtCQA:10 a=50e4U0PicR4A:10 From: "David Harrington" To: , "'Rohan Mahy'" References: <474E0F71.2050003@andybierman.com><953beacc0711282017p3ad865abw19920b4e68e82e80@mail.gmail.com> <20071129113446.GB10751@elstar.local> Subject: RE: [YANG] Re: Why NETCONF needs a data modeling language Date: Fri, 30 Nov 2007 09:31:37 -0500 Message-ID: <241101c8335d$b84c1c70$6502a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <20071129113446.GB10751@elstar.local> Thread-Index: Acgye+QkPsKmhiGtRFyLmsSo6IbADwA17LEA X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Spam-Score: 0.0 (/) X-Scan-Signature: 03fb21b15d5177c512a4caa19876f30a X-Mailman-Approved-At: Sat, 01 Dec 2007 20:37:07 -0500 Cc: yang@ietf.org, discuss@apps.ietf.org, 'NETCONF Goes On' X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org Hi comments inline. > -----Original Message----- > From: Juergen Schoenwaelder > [mailto:j.schoenwaelder@jacobs-university.de] > Sent: Thursday, November 29, 2007 6:35 AM > To: Rohan Mahy > Cc: yang@ietf.org; discuss@apps.ietf.org; NETCONF Goes On > Subject: [YANG] Re: Why NETCONF needs a data modeling language > > On Wed, Nov 28, 2007 at 08:17:04PM -0800, Rohan Mahy wrote: > > > > NETCONF needs > > > its own MIB language, just like SNMP needs SMIv2. > > > > I don't think you've made a strong case here. You might be > right, but your > > statements above do not strongly motivate a new language. > > NETCONF needs a new language; whether it is a domain specific language > like YANG or an "adapted subset" of some existing XML schema language > does not changFrom discuss-bounces@apps.ietf.org Sat Dec 01 20:38:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iydls-00045j-FC; Sat, 01 Dec 2007 20:37:24 -0500 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1IyBWn-0002SO-2L for discuss-confirm+ok@megatron.ietf.org; Fri, 30 Nov 2007 14:27:57 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IyBWm-0002Pq-Mi for discuss@apps.ietf.org; Fri, 30 Nov 2007 14:27:56 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IyBWm-0007Ln-C8 for discuss@apps.ietf.org; Fri, 30 Nov 2007 14:27:56 -0500 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-5.cisco.com with ESMTP; 30 Nov 2007 11:27:55 -0800 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id lAUJRtFi020739; Fri, 30 Nov 2007 11:27:55 -0800 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id lAUJRV27004362; Fri, 30 Nov 2007 19:27:55 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 30 Nov 2007 11:27:47 -0800 Received: from dhcp-171-71-97-219.cisco.com ([171.71.97.219]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 30 Nov 2007 11:27:46 -0800 Message-ID: <4750642E.7040307@cisco.com> Date: Fri, 30 Nov 2007 11:27:42 -0800 From: Jim Fenton User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: tbray@textuality.com Subject: Re: My XML session Sunday 3PM References: <517bf110711301021u651701aclff2a63ee37877d2@mail.gmail.com> In-Reply-To: <517bf110711301021u651701aclff2a63ee37877d2@mail.gmail.com> X-Enigmail-Version: 0.95.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 30 Nov 2007 19:27:46.0942 (UTC) FILETIME=[1665A1E0:01C83387] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=993; t=1196450875; x=1197314875; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fenton@cisco.com; z=From:=20Jim=20Fenton=20 |Subject:=20Re=3A=20My=20XML=20session=20Sunday=203PM |Sender:=20; bh=Yi8wi+oveTWCGLwhcoSm3lLmACIsKnCurxiELAbl50w=; b=lqkaz5o8qeE7oo1/LhtIV7axhxXmt9UcU64VzqKFp8xO4dQwPkHMq+DkWdHYlMKO4Xj8t0Ni GwNjgWLAW3wMg0aiM/DN5mQYSn/1orl7XEnDiO8wRgAxpN1LrbtR82Xh; Authentication-Results: sj-dkim-3; header.From=fenton@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 X-Mailman-Approved-At: Sat, 01 Dec 2007 20:37:22 -0500 Cc: Apps Discuss X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org Sounds interesting. Where will you be? -Jim Tim Bray wrote: > Since my agenda isn't posted on the IETF70 site, it might be helpful > for people planning their Sundays to know it, and be sure to stay > away: > > - How to think about whether XML is a good choice or not for use in an > Internet protocol. There are alternatives which are often superior > choices. > - If you are going to use XML, how to think about inventing your own > language as opposed to using an existing one, with a review of some > popular languages you might wane that fact that we will need a NETCONF data modeling > language and that we will need tools to understand that language. +1. Since this discussion goes outside the Network Management community in the IETF, I think some background is important. ASN.1 was a general-purpose modeling langugae that did not meet the requirements of network management. For network management standards, it is important to limit the required resources (code footprint, memory, CPU usage) to make implementtions feasible for resource-constrained devices like set-top boxes. That's why SMI is a subset of ASN.1, rather than all of ASN.1. There are aspects of the data models needed for network management that are not necessaily needed for all ASN.1 modeling. Some examples are given below. That's why SMI is an "adapted" subset of ASN.1 Now we are looking to move from the binary ASN.1 to the textual XML as the base language, to meet operators' requests (see RFC3535). Network management still needs an "adapted subset" of a general purpose modeling language or a domain-specific language. > > > I don't think we can take it on blind faith that we need to > do things in > > Netconf the way SNMP did them. I think the way SNMP did things is very inappropriate for configuration purposes (and so most operators apparently). While I strongly support reuse, especially reuse of existing standards, we need to choose the right tools for the job to be done. SNMP is not a viable candidate for confguration in most networks, for reasos described below. >I think it is very important > to look at the > > reasons we thought that SNMP needed to be a certain way, > but we also need to > > acknowledge that SNMP was hardly a success as a > configuration protocol, and > > try to find out why. It is possible that the data model was > too rigid for > > practical configuration use. > > There has been a long discussion about why SNMP failed before the > NETCONF effort was started, all going back to IAB workshop [RFC 3535] > and lots of followup email discussions. I am not sure it is terrible > useful to redo this exercise. From what I recall, the rigidity of the > SMI was never mentioned as a major issue why SNMP failed to be a good > configuration protocol. +1. Let me do a quick review for those who haven't followed those discussions, so we don't have to redo all these discussions from scratch. SNMP was not the only approach for configuration that failed, but we can start there. The 2002 IAB Workshop was toward the end of long discussions about configuration, not the beginning. COPS-PR, SNMPCONF, the Dilbert mailing list, the ops-nm mailing list, and many other discussions focused a lot on configuration requirements. The IAB Workshop achieved consesnus to explore an XML-based approach. The "SNMP standard" has three parts - the protocol, the MIB, and the SMI. The SNMP protocol was found inadequate for configuration for a number of reasons. SNMPv1 lacked security, so many vendors did not support SETs, so operators could not manipulate the configuration of many vendors' devices with SNMP. Even when SET was supported, SNMP was designed to run over unfragmented UDP, which limited message sizes so much it would be impossible to configure a large device in a reasonable amount of time. The major issue with MIBs for configuration was lack of vendor support for MIB modules for all features in their products, which left SNMP without MIB modules to configure everything in a device. And if the CLI could configure everything, and the CLI was needed to configure those things without MIB modules, then it made sense to simply use CLI for everything. A related issue was the long time it takes to get a standard MIB module for a new protocol versus developing a proprietary CLI command set for a new protocol; the delay made the MIB module irrelevant since the problem of configuring the feature would have been already resolved using the CLI. There were some discussions of the rigidity of the SMI, mostly around complex data structures such as nested tables, but there are workarount to consider adopting. > - If you are going to design your own language, how you might go about > doing so. This would include discussion of: > -- verbosity vs. terseness > -- the use of schemas, and the choice of available schema languages > -- extensibility > -- i18n and encoding issues > > Plus, the crowd will probably be small, so if you have your own > XML/IETF issue that needs discussion, bring it along. -T > > From discuss-bounces@apps.ietf.org Sat Dec 01 20:38:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iydlc-0003g4-50; Sat, 01 Dec 2007 20:37:08 -0500 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1Iy6uM-0004ih-Mc for discuss-confirm+ok@megatron.ietf.org; Fri, 30 Nov 2007 09:31:58 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iy6uM-0004iN-Bg for discuss@apps.ietf.org; Fri, 30 Nov 2007 09:31:58 -0500 Received: from qmta05.emeryville.ca.mail.comcast.net ([76.96.30.48]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iy6uJ-0002AI-2k for discuss@apps.ietf.org; Fri, 30 Nov 2007 09:31:58 -0500 Received: from OMTA13.emeryville.ca.mail.comcast.net ([76.96.30.52]) by QMTA05.emeryville.ca.mail.comcast.net with comcast id JzVe1Y00417UAYk0A0Dd00; Fri, 30 Nov 2007 14:31:58 +0000 Received: from Harrington73653 ([24.128.104.207]) by OMTA13.emeryville.ca.mail.comcast.net with comcast id K2Xs1Y00A4UVsHU0800000; Fri, 30 Nov 2007 14:31:58 +0000 X-Authority-Analysis: v=1.0 c=1 a=I0y0xKm2-w0A:10 a=j3Z76cjpAAAA:8 a=48vgC7mUAAAA:8 a=m7Gx0nXtxD0cURmhWtoA:9 a=Jbp6iasmxlNv7zYQp5EA:7 a=p7ZV2XQxOjHVSLzO9rel6YhuadgA:4 a=lZB815dzVvQA:10 a=FvgKqOQ44qUA:10 a=JrSEOxZJtCQA:10 a=50e4U0PicR4A:10 From: "David Harrington" To: , "'Rohan Mahy'" References: <474E0F71.2050003@andybierman.com><953beacc0711282017p3ad865abw19920b4e68e82e80@mail.gmail.com> <20071129113446.GB10751@elstar.local> Subject: RE: [YANG] Re: Why NETCONF needs a data modeling language Date: Fri, 30 Nov 2007 09:31:37 -0500 Message-ID: <241101c8335d$b84c1c70$6502a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <20071129113446.GB10751@elstar.local> Thread-Index: Acgye+QkPsKmhiGtRFyLmsSo6IbADwA17LEA X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Spam-Score: 0.0 (/) X-Scan-Signature: 03fb21b15d5177c512a4caa19876f30a X-Mailman-Approved-At: Sat, 01 Dec 2007 20:37:07 -0500 Cc: yang@ietf.org, discuss@apps.ietf.org, 'NETCONF Goes On' X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org Hi comments inline. > -----Original Message----- > From: Juergen Schoenwaelder > [mailto:j.schoenwaelder@jacobs-university.de] > Sent: Thursday, November 29, 2007 6:35 AM > To: Rohan Mahy > Cc: yang@ietf.org; discuss@apps.ietf.org; NETCONF Goes On > Subject: [YANG] Re: Why NETCONF needs a data modeling language > > On Wed, Nov 28, 2007 at 08:17:04PM -0800, Rohan Mahy wrote: > > > > NETCONF needs > > > its own MIB language, just like SNMP needs SMIv2. > > > > I don't think you've made a strong case here. You might be > right, but your > > statements above do not strongly motivate a new language. > > NETCONF needs a new language; whether it is a domain specific language > like YANG or an "adapted subset" of some existing XML schema language > does not changds for this. AFAIK, relational databases typically do not support nested tables either, so I never considered this a major fault; it just makes it harder to represent structures that can be expressed easily in C, which was the preferred language for agent developers. I think the biggest problem with the SMI is that everybody hates OIDs and wants something more human-readable. But that's not just about configuration. See RFC3535 for more detailed summaries of the IAB Workshop discussions. > > > Look at the following Relax NG in compact form, > side-by-side with YANG. > > > > container aaa { > > container bbb { > > leaf foo { type string; } > > leaf bar { type uint32; } > > } > > } > > > > element aaa { > > element bbb { > > element foo { xsd:string }, > > element bar { xsd:unsignedInt } > > } > > } > > > > This hardly seems like a big difference to me. > > I am not sure which point you are trying to make using examples that > ignore almost all NETCONF specifics. But even then, if you spell out > the additional NETCONF specific semantics which are hidden because > there are suitable defaults for the most common cases, then the YANG > example above actually expands to the following: > > container aaa { > config true; > status current; > container bbb { > status current; > config true; > leaf foo { > type string; > config true; > status current; > mandatory false; > } > leaf bar { > type uint32; > config true; > status current; > mandatory false; > } > } > } > > Statements like 'config true;' are essential for the processing of > NETCONF messages and also for validating content exchanged in NETCONF > messages (and this is why for example generic XML validation tools are > only of limited value for NETCONF implementors). > > I am sure one can define an adapted subset of RNG which takes care of > all this and then at the end this adapted subset likely works like > YANG. However, given the SMI and ASN.1 experience, I do question > > a) that doing so will lead to a large reuse of available RNG tools for > processing NETCONF data models (since they don't know the RNG > subset nor the semantic additions) +1. Tools for XSD or RNG will only be able to do partial validation and processing. Additional validation will be needed that is domain-specific. If XSD forces us to put much of the "adapted" stuff into app-notes, we will need special tools that can validate the content of the app-notes. > > b) that the effort to specify such an extended subset will be less > than the effort for defining a domain specific language like YANG +1; I think it might take longer to develop a RNG-standard-compliant extended subset than working with a domain specific language, because we will constantly be faced with finding workarounds for the constraints imposed by the RNG standard. > > c) that the effort to implement tools understanding the adapted subset > of RNG will be less than writing proper tools for a domain specific > language from scratch +1. > > d) that there will be long term (say 20 year) reliable change control > exercised by the organization that has change control over NETCONF +1. ASN.1 changed a lot after the SMI was developed as an adapted subset of ASN.1-1988. I think ASN.1 became more complex, adding new features for additional uses, and changed in ways that made the SMI no longer compatible with the ASN.1 standard. The separation of the SMI from the underlying langauge has allowed the SMI to remain stable for twenty years. That stability is critically important to motivating vendors to utilize our standards, since they are not faced with a constantly-changing base language. The SMING WG tried to update the SMI, and found that, even with strong pressures to remain backwards compatible with SMIv1 and SMIv2, there is a need to move forward to a new base language that is more human-readable than SMIv1 or SMIv2 (and ASN.1). But whether XML or somee that fact that we will need a NETCONF data modeling > language and that we will need tools to understand that language. +1. Since this discussion goes outside the Network Management community in the IETF, I think some background is important. ASN.1 was a general-purpose modeling langugae that did not meet the requirements of network management. For network management standards, it is important to limit the required resources (code footprint, memory, CPU usage) to make implementtions feasible for resource-constrained devices like set-top boxes. That's why SMI is a subset of ASN.1, rather than all of ASN.1. There are aspects of the data models needed for network management that are not necessaily needed for all ASN.1 modeling. Some examples are given below. That's why SMI is an "adapted" subset of ASN.1 Now we are looking to move from the binary ASN.1 to the textual XML as the base language, to meet operators' requests (see RFC3535). Network management still needs an "adapted subset" of a general purpose modeling language or a domain-specific language. > > > I don't think we can take it on blind faith that we need to > do things in > > Netconf the way SNMP did them. I think the way SNMP did things is very inappropriate for configuration purposes (and so most operators apparently). While I strongly support reuse, especially reuse of existing standards, we need to choose the right tools for the job to be done. SNMP is not a viable candidate for confguration in most networks, for reasos described below. >I think it is very important > to look at the > > reasons we thought that SNMP needed to be a certain way, > but we also need to > > acknowledge that SNMP was hardly a success as a > configuration protocol, and > > try to find out why. It is possible that the data model was > too rigid for > > practical configuration use. > > There has been a long discussion about why SNMP failed before the > NETCONF effort was started, all going back to IAB workshop [RFC 3535] > and lots of followup email discussions. I am not sure it is terrible > useful to redo this exercise. From what I recall, the rigidity of the > SMI was never mentioned as a major issue why SNMP failed to be a good > configuration protocol. +1. Let me do a quick review for those who haven't followed those discussions, so we don't have to redo all these discussions from scratch. SNMP was not the only approach for configuration that failed, but we can start there. The 2002 IAB Workshop was toward the end of long discussions about configuration, not the beginning. COPS-PR, SNMPCONF, the Dilbert mailing list, the ops-nm mailing list, and many other discussions focused a lot on configuration requirements. The IAB Workshop achieved consesnus to explore an XML-based approach. The "SNMP standard" has three parts - the protocol, the MIB, and the SMI. The SNMP protocol was found inadequate for configuration for a number of reasons. SNMPv1 lacked security, so many vendors did not support SETs, so operators could not manipulate the configuration of many vendors' devices with SNMP. Even when SET was supported, SNMP was designed to run over unfragmented UDP, which limited message sizes so much it would be impossible to configure a large device in a reasonable amount of time. The major issue with MIBs for configuration was lack of vendor support for MIB modules for all features in their products, which left SNMP without MIB modules to configure everything in a device. And if the CLI could configure everything, and the CLI was needed to configure those things without MIB modules, then it made sense to simply use CLI for everything. A related issue was the long time it takes to get a standard MIB module for a new protocol versus developing a proprietary CLI command set for a new protocol; the delay made the MIB module irrelevant since the problem of configuring the feature would have been already resolved using the CLI. There were some discussions of the rigidity of the SMI, mostly around complex data structures such as nested tables, but there are workarounthing else, the solution needs to be able to address the requirements of network management, especially human-readability. > > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 > > > _______________________________________________ > YANG mailing list > YANG@ietf.org > https://www1.ietf.org/mailman/listinfo/yang > ds for this. AFAIK, relational databases typically do not support nested tables either, so I never considered this a major fault; it just makes it harder to represent structures that can be expressed easily in C, which was the preferred language for agent developers. I think the biggest problem with the SMI is that everybody hates OIDs and wants something more human-readable. But that's not just about configuration. See RFC3535 for more detailed summaries of the IAB Workshop discussions. > > > Look at the following Relax NG in compact form, > side-by-side with YANG. > > > > container aaa { > > container bbb { > > leaf foo { type string; } > > leaf bar { type uint32; } > > } > > } > > > > element aaa { > > element bbb { > > element foo { xsd:string }, > > element bar { xsd:unsignedInt } > > } > > } > > > > This hardly seems like a big difference to me. > > I am not sure which point you are trying to make using examples that > ignore almost all NETCONF specifics. But even then, if you spell out > the additional NETCONF specific semantics which are hidden because > there are suitable defaults for the most common cases, then the YANG > example above actually expands to the following: > > container aaa { > config true; > status current; > container bbb { > status current; > config true; > leaf foo { > type string; > config true; > status current; > mandatory false; > } > leaf bar { > type uint32; > config true; > status current; > mandatory false; > } > } > } > > Statements like 'config true;' are essential for the processing of > NETCONF messages and also for validating content exchanged in NETCONF > messages (and this is why for example generic XML validation tools are > only of limited value for NETCONF implementors). > > I am sure one can define an adapted subset of RNG which takes care of > all this and then at the end this adapted subset likely works like > YANG. However, given the SMI and ASN.1 experience, I do question > > a) that doing so will lead to a large reuse of available RNG tools for > processing NETCONF data models (since they don't know the RNG > subset nor the semantic additions) +1. Tools for XSD or RNG will only be able to do partial validation and processing. Additional validation will be needed that is domain-specific. If XSD forces us to put much of the "adapted" stuff into app-notes, we will need special tools that can validate the content of the app-notes. > > b) that the effort to specify such an extended subset will be less > than the effort for defining a domain specific language like YANG +1; I think it might take longer to develop a RNG-standard-compliant extended subset than working with a domain specific language, because we will constantly be faced with finding workarounds for the constraints imposed by the RNG standard. > > c) that the effort to implement tools understanding the adapted subset > of RNG will be less than writing proper tools for a domain specific > language from scratch +1. > > d) that there will be long term (say 20 year) reliable change control > exercised by the organization that has change control over NETCONF +1. ASN.1 changed a lot after the SMI was developed as an adapted subset of ASN.1-1988. I think ASN.1 became more complex, adding new features for additional uses, and changed in ways that made the SMI no longer compatible with the ASN.1 standard. The separation of the SMI from the underlying langauge has allowed the SMI to remain stable for twenty years. That stability is critically important to motivating vendors to utilize our standards, since they are not faced with a constantly-changing base language. The SMING WG tried to update the SMI, and found that, even with strong pressures to remain backwards compatible with SMIv1 and SMIv2, there is a need to move forward to a new base language that is more human-readable than SMIv1 or SMIv2 (and ASN.1). But whether XML or something else, the solution needs to be able to address the requirements of network management, especially human-readability. > > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 > > > _______________________________________________ > YANG mailing list > YANG@ietf.org > https://www1.ietf.org/mailman/listinfo/yang > From discuss-bounces@apps.ietf.org Sun Dec 02 13:21:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IytQQ-0003RL-FU; Sun, 02 Dec 2007 13:20:18 -0500 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1IytQO-0003NX-T0 for discuss-confirm+ok@megatron.ietf.org; Sun, 02 Dec 2007 13:20:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IytQO-0003Li-Hr for discuss@apps.ietf.org; Sun, 02 Dec 2007 13:20:16 -0500 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IytQN-0002U1-Kb for discuss@apps.ietf.org; Sun, 02 Dec 2007 13:20:16 -0500 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id A1E0A21310; Sun, 2 Dec 2007 19:20:14 +0100 (CET) X-AuditID: c1b4fb3c-aef95bb0000030cf-27-4752f75e730a Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.124]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 726452106A; Sun, 2 Dec 2007 19:20:14 +0100 (CET) Received: from esealmw127.eemea.ericsson.se ([153.88.254.171]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Sun, 2 Dec 2007 19:20:14 +0100 Received: from [127.0.0.1] ([159.107.148.22]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Sun, 2 Dec 2007 19:20:13 +0100 Message-ID: <4752F757.5030204@ericsson.com> Date: Sun, 02 Dec 2007 10:20:07 -0800 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: David Harrington Subject: Re: Why NETCONF needs a data modeling language References: <474E0F71.2050003@andybierman.com> <241201c83366$9acf8070$6502a8c0@china.huawei.com> In-Reply-To: <241201c83366$9acf8070$6502a8c0@china.huawei.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 02 Dec 2007 18:20:13.0959 (UTC) FILETIME=[FB750170:01C8350F] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: -1.0 (-) X-Scan-Signature: 93e7fb8fef2e780414389440f367c879 Cc: yang@ietf.org, discuss@apps.ietf.org, 'NETCONF Goes On' X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: balazs.lengyel@ericsson.com List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org Hello, >> Q1) Why does NETCONF need a DML at all? If we have an IETF standard DML for NETCONF, device vendors (like my company) will be much more comfortable, much more willing to adapt NETCONF itself. With a standard DML we would see a better chance at having available 3rd party or even freeware toolkits for NETCONF. The above would be important even for a company which would not care about interoperability. Balazs David Harrington wrote: > >> Hi, >> >> There are a few questions that the IESG and others have asked, >> which I will try to address: >> >> Q1) Why does NETCONF need a DML at all? >> Q2) Why is NETCONF special? >> Q3) Why won't lots of other WGs want to define their own >> protocol-specific DMLs? >> Q4) Why isn't XSD or RelaxNG good enough? > > I'll take a whack at answering the same questions. > > A1) Why does NETCONF need a DML at all? > > to promote vendor-neutral interoperable management. > > It is much easier to develop standards when everybody uses the same > basic language to communicate; this "common language for shared > communication" is also reflected in the IETF decision to use English > text and ASCII documents. > > This is not just about being able to standardize **device > management**; it is a basic step to permit the standardization of > **network management** and possibly **services management". The DML is > a basic building block. > > A2) Why is NETCONF special? > > It is and it isn't. Netconf is only one protocol used for network > management. > > It has some unique requirements, such as using a document-based > approach and differentiating the data for config versus state and for > dealing with different time-defined contexts such as running and > startup configs. This differs from other network management protocols, > such as SNMP and syslog and ipfix, which use their own data formats, > and usually deal only with the currently-running config. Netconf is a > tool designed to meet the special requirements of configuration, and > the DML needs to support special features not found in other NM-DMLs. > > Netconf is not special, in that any language used for network > management is likely to have certain common requirements. NM data > models are commonly used directly by humans, in their raw form, such > as when they troubleshoot problems using network sniffers. NM data > models are also commonly used by NMS applications that can handle the > translations into a more human-readable format. Designers of NM tools > (e.g., protocols and data models) thus need to pay close attention to > who will use the information, and to assume that the data will be used > both directly by humans and by applications. Operators have complained > strongly that OIDs are very hard to work with in raw form, yet > operators frequently need to deal with the raw form of the data. > > A3) Why won't lots of other WGs want to define their own > protocol-specific DMLs? > > To paraphrase a wise man from the SNMP community, when you fill a room > with protocol designers and ask for a solution to a problem, is it a > surprise when they recommend designing a new protocol? > > The decision about whether to use an existing protocol/DML or develop > a new protocol/DML should be made after a careful analysis of the > requirements of the solution. SNMP was designed when CMIP was found to > not quite address the needs. The SMI was designed when ASN.1 was found > to not quite address the needs. XML was designed when other DMLs were > found to not quite address the needs. > > The decision to explore an XML-based DML and to explore a C-like DML > follows years and years and years of debate over the requiremnts of > network management, and configuration in particular. > > If every WG spends as much time analyzing the requirements that the > OPS area has spent considering this decision, it might be good for > ensuring no new protoocls are designed that are not really needed, but > the IETF would also grind to a halt, much as the OPS community has > done over our many years of debate. And the delay caused by our > debates has made IETF network management largely irrelevant to the > operator community (our customers). > > As always, we need to be vigilant and determine whether enough thought > has been given to reuse of existing protocols. We also need to > consider the tradeoffs between new protocols and reusing existing > protocols in ways they were not designed to be used. > > A4) Why isn't XSD or RelaxNG good enough? > > As mentioned in A2, NM data models need to be both machine- and > human-readable. XSD is machine-readable, but it is a tough language > for humans. RelaxNG seems better. > > As discussed further in a different email, Netconf will almost > certainly need a DML suited to its requirements, and if RelaxNG is > found to be human-friendly-enough, we would almost certainly still > need to select a subset and adapt it to meet configuration > requirements. So the benefit of using RelaxNG over a domain-specific > DML may be lost by using an adapted-subset of RelaxNG. > > Most operators already understand languages like Perl and C and > Javascript, because they already need to write lots of scripts to > manage their networks. Most implementers of NM support in > internetworking devices work in C or a variant of C. It makes a lot of > sense to use a language with a C-like syntax for these people, rather > than forcing them to learn yet another language that was designed for > some other purpose. > > [soap] > somebody commented that the designers of XSD and RelaxNG really > understand how to design DMLs, implying that the OPS community does > not. Many of the people involved in the ongoing DML discussions over > the years, and now, are MIB Doctors and operators and protocol > designers, and have had years of experience designing and working with > SMI and network management. They understand the requirements of a DML > for NM far more than the designers of XSD or RelaxNG, who were not > designing their DMLs for NM purposes. > [end soap] > > David Harrington > dbharrington@comcast.net > ietfdbh@comcast.net > > > > > > From discuss-bounces@apps.ietf.org Sun Dec 02 14:01:54 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iyu3g-00062Z-SR; Sun, 02 Dec 2007 14:00:52 -0500 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1Iyu3f-0005yM-3Q for discuss-confirm+ok@megatron.ietf.org; Sun, 02 Dec 2007 14:00:51 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iyu3e-0005yD-NQ for discuss@apps.ietf.org; Sun, 02 Dec 2007 14:00:50 -0500 Received: from rs40.luxsci.com ([65.61.166.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iyu3d-0007hI-2m for discuss@apps.ietf.org; Sun, 02 Dec 2007 14:00:50 -0500 Received: from [192.168.20.198] (c-24-91-195-79.hsd1.ma.comcast.net [24.91.195.79]) (authenticated bits=0) by rs40.luxsci.com (8.13.1/8.13.7) with ESMTP id lB2J0kgF005726 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sun, 2 Dec 2007 13:00:47 -0600 In-Reply-To: <4752F757.5030204@ericsson.com> References: <474E0F71.2050003@andybierman.com> <241201c83366$9acf8070$6502a8c0@china.huawei.com> <4752F757.5030204@ericsson.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: multipart/alternative; boundary=Apple-Mail-17--728488243 Message-Id: <94673DD8-1AAB-4ED2-AD27-3AFB4C604F05@jdscons.com> From: Jon Saperia Subject: Re: Why NETCONF needs a data modeling language Date: Sun, 2 Dec 2007 14:00:43 -0500 To: balazs.lengyel@ericsson.com X-Mailer: Apple Mail (2.752.2) X-Spam-Score: -1.0 (-) X-Scan-Signature: 2ce306e4307a2c0b518ae453b13efdd0 Cc: yang@ietf.org, discuss@apps.ietf.org, 'NETCONF Goes On' X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org --Apple-Mail-17--728488243 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Thanks /jon ---------------------- Jon Saperia TSP NM (mobil) 617-201-2655 (office) 978-461-0249 saperia@jdscons.com On Dec 2, 2007, at 1:20 PM, Balazs Lengyel wrote: > Hello, > >> Q1) Why does NETCONF need a DML at all? > > If we have an IETF standard DML for NETCONF, device vendors (like > my company) will be much more comfortable, much more willing to > adapt NETCONF itself. With a standard DML we would see a better > chance at having available 3rd party or even freeware toolkits for > NETCONF. Yes, but does that mean that we will begin to develop a standard configuration objects for say, BGP or DiffServ that would work from one vendor to the next? It would be nice to think so, that would really help interoperability and should be the target of 'our' collective efforts. /jon > > The above would be important even for a company which would not > care about interoperability. > > Balazs > > David Harrington wrote: >> >>> Hi, >>> >>> There are a few questions that the IESG and others have asked, >>> which I will try to address: >>> >>> Q1) Why does NETCONF need a DML at all? >>> Q2) Why is NETCONF special? >>> Q3) Why won't lots of other WGs want to define their own >>> protocol-specific DMLs? >>> Q4) Why isn't XSD or RelaxNG good enough? >> I'll take a whack at answering the same questions. >> A1) Why does NETCONF need a DML at all? >> to promote vendor-neutral interoperable management. It is much >> easier to develop standards when everybody uses the same >> basic language to communicate; this "common language for shared >> communication" is also reflected in the IETF decision to use English >> text and ASCII documents. >> This is not just about being able to standardize **device >> management**; it is a basic step to permit the standardization of >> **network management** and possibly **services management". The >> DML is >> a basic building block. >> A2) Why is NETCONF special? >> It is and it isn't. Netconf is only one protocol used for network >> management. It has some unique requirements, such as using a >> document-based >> approach and differentiating the data for config versus state and for >> dealing with different time-defined contexts such as running and >> startup configs. This differs from other network management >> protocols, >> such as SNMP and syslog and ipfix, which use their own data formats, >> and usually deal only with the currently-running config. Netconf is a >> tool designed to meet the special requirements of configuration, and >> the DML needs to support special features not found in other NM- >> DMLs. Netconf is not special, in that any language used for network >> management is likely to have certain common requirements. NM data >> models are commonly used directly by humans, in their raw form, such >> as when they troubleshoot problems using network sniffers. NM data >> models are also commonly used by NMS applications that can handle the >> translations into a more human-readable format. Designers of NM tools >> (e.g., protocols and data models) thus need to pay close attention to >> who will use the information, and to assume that the data will be >> used >> both directly by humans and by applications. Operators have >> complained >> strongly that OIDs are very hard to work with in raw form, yet >> operators frequently need to deal with the raw form of the data. >> A3) Why won't lots of other WGs want to define their own >> protocol-specific DMLs? >> To paraphrase a wise man from the SNMP community, when you fill a >> room >> with protocol designers and ask for a solution to a problem, is it a >> surprise when they recommend designing a new protocol? >> The decision about whether to use an existing protocol/DML or develop >> a new protocol/DML should be made after a careful analysis of the >> requirements of the solution. SNMP was designed when CMIP was >> found to >> not quite address the needs. The SMI was designed when ASN.1 was >> found >> to not quite address the needs. XML was designed when other DMLs were >> found to not quite address the needs. >> The decision to explore an XML-based DML and to explore a C-like DML >> follows years and years and years of debate over the requiremnts of >> network management, and configuration in particular. If every WG >> spends as much time analyzing the requirements that the >> OPS area has spent considering this decision, it might be good for >> ensuring no new protoocls are designed that are not really needed, >> but >> the IETF would also grind to a halt, much as the OPS community has >> done over our many years of debate. And the delay caused by our >> debates has made IETF network management largely irrelevant to the >> operator community (our customers). >> As always, we need to be vigilant and determine whether enough >> thought >> has been given to reuse of existing protocols. We also need to >> consider the tradeoffs between new protocols and reusing existing >> protocols in ways they were not designed to be used. >> A4) Why isn't XSD or RelaxNG good enough? >> As mentioned in A2, NM data models need to be both machine- and >> human-readable. XSD is machine-readable, but it is a tough language >> for humans. RelaxNG seems better. As discussed further in a >> different email, Netconf will almost >> certainly need a DML suited to its requirements, and if RelaxNG is >> found to be human-friendly-enough, we would almost certainly still >> need to select a subset and adapt it to meet configuration >> requirements. So the benefit of using RelaxNG over a domain-specific >> DML may be lost by using an adapted-subset of RelaxNG. >> Most operators already understand languages like Perl and C and >> Javascript, because they already need to write lots of scripts to >> manage their networks. Most implementers of NM support in >> internetworking devices work in C or a variant of C. It makes a >> lot of >> sense to use a language with a C-like syntax for these people, rather >> than forcing them to learn yet another language that was designed for >> some other purpose. >> [soap] >> somebody commented that the designers of XSD and RelaxNG really >> understand how to design DMLs, implying that the OPS community does >> not. Many of the people involved in the ongoing DML discussions over >> the years, and now, are MIB Doctors and operators and protocol >> designers, and have had years of experience designing and working >> with >> SMI and network management. They understand the requirements of a DML >> for NM far more than the designers of XSD or RelaxNG, who were not >> designing their DMLs for NM purposes. >> [end soap] >> David Harrington >> dbharrington@comcast.net >> ietfdbh@comcast.net > > --Apple-Mail-17--728488243 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1
saperia@jdscons.com


=
On Dec 2, 2007, at 1:20 PM, Balazs Lengyel = wrote:

Hello,
>>=A0 =A0 = Q1) Why does NETCONF need a DML at all?

If we = have an IETF standard DML for NETCONF, device vendors (like my company) = will be much more comfortable, much more willing to adapt NETCONF = itself. With a standard DML we would see a better chance at having = available 3rd party or even freeware toolkits for = NETCONF.

Yes, but does that mean that we = will begin to develop a standard configuration objects for say, BGP or = DiffServ that would work from one vendor to the next? =A0It would be = nice to think so, that would really help interoperability and should be = the target of 'our' collective efforts.
/jon

The above would be important even for a company = which would not care about interoperability.


David Harrington wrote:

=A0

Hi,

There are a few questions that = the IESG and others have asked,
which I will = try to address:

=A0=A0 = Q1) Why does NETCONF need a DML at all?
=A0=A0 = Q2) Why is NETCONF special?
=A0=A0 Q3) Why won't lots of = other WGs want to define their own
=A0=A0 =A0 =A0 protocol-specific = DMLs?
=A0=A0 Q4) Why isn't XSD or = RelaxNG good enough?
I'll take a = whack at answering the same questions.
A1) Why = does NETCONF need a DML at all?
to promote = vendor-neutral interoperable management. It is much easier to develop = standards when everybody uses the same
basic = language to communicate; this "common language for shared
communication" is also reflected in the IETF = decision to use English
text and = ASCII documents.
This is not just about being = able to standardize **device
management**; = it is a basic step to permit the standardization of
**network management** and possibly **services = management". The DML is
a basic = building block.
A2) Why is NETCONF = special?
It is and it isn't. Netconf is = only one protocol used for network
management. = It has some unique requirements, such as using a = document-based
approach and differentiating the = data for config versus state and for
dealing with = different time-defined contexts such as running and
startup configs. This differs from other network = management protocols,
such as SNMP and syslog and = ipfix, which use their own data formats,
and = usually deal only with the currently-running config. Netconf is = a
tool designed to meet the special requirements = of configuration, and
the DML needs to support = special features not found in other NM-DMLs. Netconf is not special, in = that any language used for network
management is = likely to have certain common requirements. NM data
models are commonly used directly by humans, in = their raw form, such
as when they troubleshoot = problems using network sniffers. NM data
models = are also commonly used by NMS applications that can handle the
translations into a more human-readable format. = Designers of NM tools
(e.g., protocols and data = models) thus need to pay close attention to
who = will use the information, and to assume that the data will be = used
both directly by humans and by = applications. Operators have complained
strongly = that OIDs are very hard to work with in raw form, yet
operators frequently need to deal with the raw form = of the data. A3) Why won't lots of other WGs want to define their = own
=A0 =A0 =A0 =A0 protocol-specific = DMLs?
To paraphrase a wise man from = the SNMP community, when you fill a room
with = protocol designers and ask for a solution to a problem, is it = a
surprise when they recommend designing a new = protocol?
The decision about whether to = use an existing protocol/DML or develop
a new = protocol/DML should be made after a careful analysis of the
requirements of the solution. SNMP was designed when = CMIP was found to
not quite address the needs. The = SMI was designed when ASN.1 was found
to not = quite address the needs. XML was designed when other DMLs were
found to not quite address the needs.
The decision to explore an XML-based DML and to = explore a C-like DML
follows years and years and = years of debate over the requiremnts of
network = management, and configuration in particular. If every WG spends as much = time analyzing the requirements that the
OPS area = has spent considering this decision, it might be good for
ensuring no new protoocls are designed that are not = really needed, but
the IETF would also grind = to a halt, much as the OPS community has
done = over our many years of debate. And the delay caused by our
debates has made IETF network management largely = irrelevant to the
operator community (our = customers).
As always, we need to be = vigilant and determine whether enough thought
has been given to reuse of existing protocols. We = also need to
consider the tradeoffs between = new protocols and reusing existing
protocols in = ways they were not designed to be used.
A4) Why = isn't XSD or RelaxNG good enough?
As mentioned = in A2, NM data models need to be both machine- and
human-readable. XSD is machine-readable, but it is a = tough language
for humans. RelaxNG seems = better. As discussed further in a different email, Netconf will = almost
certainly need a DML suited to = its requirements, and if RelaxNG is
found to be = human-friendly-enough, we would almost certainly still
need to select a subset and adapt it to meet = configuration
requirements. So the benefit of = using RelaxNG over a domain-specific
DML may be = lost by using an adapted-subset of RelaxNG.
Most = operators already understand languages like Perl and C and
Javascript, because they already need to write lots = of scripts to
manage their networks. Most = implementers of NM support in
sense to use a language with a C-like syntax = for these people, rather
than forcing = them to learn yet another language that was designed for
some other purpose.
somebody commented that the = designers of XSD and RelaxNG really
understand = how to design DMLs, implying that the OPS community does
not. Many of the people involved in the ongoing DML = discussions over
the years, and now, are MIB = Doctors and operators and protocol
designers, = and have had years of experience designing and working with
SMI and network management. They understand the = requirements of a DML
for NM far more than the = designers of XSD or RelaxNG, who were not
[end = soap]
David Harrington


=

= --Apple-Mail-17--728488243-- From discuss-bounces@apps.ietf.org Sun Dec 02 14:44:01 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IyuiX-0006x7-NL; Sun, 02 Dec 2007 14:43:05 -0500 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1IyuiV-0006uw-Ih for discuss-confirm+ok@megatron.ietf.org; Sun, 02 Dec 2007 14:43:03 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IyuiV-0006ug-8g for discuss@apps.ietf.org; Sun, 02 Dec 2007 14:43:03 -0500 Received: from qwak.roomlinx.com ([64.40.109.249] helo=newqwak1.roomlinx.com) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IyuiT-0004vl-Lw for discuss@apps.ietf.org; Sun, 02 Dec 2007 14:43:03 -0500 Received: (qmail 15804 invoked by uid 513); 2 Dec 2007 05:44:09 -0000 Received: from julian.reschke@gmx.de by qwak.roomlinx.com by uid 502 with qmail-scanner-1.22 (clamdscan: 0.74. spamassassin: 2.63. Clear:RC:1(204.244.69.83):. Processed in 0.142708 secs); 02 Dec 2007 05:44:09 -0000 Received: from swc.roomlinx.com (HELO ?10.0.0.38?) (204.244.69.83) by newqwak1.roomlinx.com with SMTP; 2 Dec 2007 05:44:08 -0000 Message-ID: <47512728.6040201@gmx.de> Date: Sat, 01 Dec 2007 10:19:36 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.0.4) Gecko/20060516 Thunderbird/1.5.0.4 Mnenhy/0.7.4.666 MIME-Version: 1.0 To: Lisa Dusseault Subject: Re: analysis of YANG vs. RELAX NG References: <953beacc0711271504y7aea5f21jc301ccad886d3611@mail.gmail.com> <474D9194.3060103@ericsson.com> <953beacc0711281025w4d993dd7u77d729111074496c@mail.gmail.com> <20071128.230244.254578150.mbj@tail-f.com> <63F8A418-6AF0-4205-ACC7-53A8C7BC6A73@osafoundation.org> In-Reply-To: <63F8A418-6AF0-4205-ACC7-53A8C7BC6A73@osafoundation.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 1.8 (+) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: discuss@apps.ietf.org X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org Lisa Dusseault wrote: > This is another aspect I'd like to understand better: > > On Nov 28, 2007, at 2:02 PM, Martin Bjorklund wrote: > >> Note that in order to validate the different NETCONF messages, you >> >> would either need more than one schema, or a very lax schema which >> >> will validate messages/documents which are not actually valid NETCONF. >> > > Validating XML really limits the customizability, the very extensibility > of the XML. You can't add so much as a or > element without it failing at the other end. Is the > goal here to strictly limit netconf data to only standardized and > implemented schemas? Well, that depends on the schema language. RelaxNG allows to define languages that use the must-ignore rule for new elements. BR, Julian From discuss-bounces@apps.ietf.org Sun Dec 02 15:20:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IyvHW-0007Vg-HO; Sun, 02 Dec 2007 15:19:14 -0500 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1IyvHU-0007SR-Rg for discuss-confirm+ok@megatron.ietf.org; Sun, 02 Dec 2007 15:19:12 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IyvHU-0007RD-Gy for discuss@apps.ietf.org; Sun, 02 Dec 2007 15:19:12 -0500 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IyvHS-0000yC-7i for discuss@apps.ietf.org; Sun, 02 Dec 2007 15:19:12 -0500 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 900C020FD1; Sun, 2 Dec 2007 21:19:09 +0100 (CET) X-AuditID: c1b4fb3c-b0798bb0000030cf-c1-4753133da81f Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 678C0205FE; Sun, 2 Dec 2007 21:19:09 +0100 (CET) Received: from esealmw128.eemea.ericsson.se ([153.88.254.172]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Sun, 2 Dec 2007 21:19:09 +0100 Received: from [127.0.0.1] ([159.107.148.22]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Sun, 2 Dec 2007 21:19:08 +0100 Message-ID: <47531335.9050800@ericsson.com> Date: Sun, 02 Dec 2007 12:19:01 -0800 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: Jon Saperia Subject: Re: Why NETCONF needs a data modeling language References: <474E0F71.2050003@andybierman.com> <241201c83366$9acf8070$6502a8c0@china.huawei.com> <4752F757.5030204@ericsson.com> <94673DD8-1AAB-4ED2-AD27-3AFB4C604F05@jdscons.com> In-Reply-To: <94673DD8-1AAB-4ED2-AD27-3AFB4C604F05@jdscons.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 02 Dec 2007 20:19:08.0998 (UTC) FILETIME=[98458E60:01C83520] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: -1.0 (-) X-Scan-Signature: 42e3ed3f10a1d8bef690f09da16f507a Cc: yang@ietf.org, discuss@apps.ietf.org, 'NETCONF Goes On' X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: balazs.lengyel@ericsson.com List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org Hello, Naturally our aim is to develop standard NETCONF configuration models, and the more people use NETCONF the easier that will be. Balazs Jon Saperia wrote: > > Thanks > /jon > ---------------------- > Jon Saperia > TSP NM > (mobil) 617-201-2655 > (office) 978-461-0249 > saperia@jdscons.com > > > > On Dec 2, 2007, at 1:20 PM, Balazs Lengyel wrote: > >> Hello, >> >> Q1) Why does NETCONF need a DML at all? >> >> If we have an IETF standard DML for NETCONF, device vendors (like my >> company) will be much more comfortable, much more willing to adapt >> NETCONF itself. With a standard DML we would see a better chance at >> having available 3rd party or even freeware toolkits for NETCONF. > > Yes, but does that mean that we will begin to develop a standard > configuration objects for say, BGP or DiffServ that would work from one > vendor to the next? It would be nice to think so, that would really > help interoperability and should be the target of 'our' collective efforts. > /jon >> >> The above would be important even for a company which would not care >> about interoperability. >> >> Balazs >> >> David Harrington wrote: >>> >>> >>> >>>> Hi, >>>> >>>> There are a few questions that the IESG and others have asked, >>>> which I will try to address: >>>> >>>> Q1) Why does NETCONF need a DML at all? >>>> Q2) Why is NETCONF special? >>>> Q3) Why won't lots of other WGs want to define their own >>>> protocol-specific DMLs? >>>> Q4) Why isn't XSD or RelaxNG good enough? >>> I'll take a whack at answering the same questions. >>> A1) Why does NETCONF need a DML at all? >>> to promote vendor-neutral interoperable management. It is much easier >>> to develop standards when everybody uses the same >>> basic language to communicate; this "common language for shared >>> communication" is also reflected in the IETF decision to use English >>> text and ASCII documents. >>> This is not just about being able to standardize **device >>> management**; it is a basic step to permit the standardization of >>> **network management** and possibly **services management". The DML is >>> a basic building block. >>> A2) Why is NETCONF special? >>> It is and it isn't. Netconf is only one protocol used for network >>> management. It has some unique requirements, such as using a >>> document-based >>> approach and differentiating the data for config versus state and for >>> dealing with different time-defined contexts such as running and >>> startup configs. This differs from other network management protocols, >>> such as SNMP and syslog and ipfix, which use their own data formats, >>> and usually deal only with the currently-running config. Netconf is a >>> tool designed to meet the special requirements of configuration, and >>> the DML needs to support special features not found in other NM-DMLs. >>> Netconf is not special, in that any language used for network >>> management is likely to have certain common requirements. NM data >>> models are commonly used directly by humans, in their raw form, such >>> as when they troubleshoot problems using network sniffers. NM data >>> models are also commonly used by NMS applications that can handle the >>> translations into a more human-readable format. Designers of NM tools >>> (e.g., protocols and data models) thus need to pay close attention to >>> who will use the information, and to assume that the data will be used >>> both directly by humans and by applications. Operators have complained >>> strongly that OIDs are very hard to work with in raw form, yet >>> operators frequently need to deal with the raw form of the data. A3) >>> Why won't lots of other WGs want to define their own >>> protocol-specific DMLs? >>> To paraphrase a wise man from the SNMP community, when you fill a room >>> with protocol designers and ask for a solution to a problem, is it a >>> surprise when they recommend designing a new protocol? >>> The decision about whether to use an existing protocol/DML or develop >>> a new protocol/DML should be made after a careful analysis of the >>> requirements of the solution. SNMP was designed when CMIP was found to >>> not quite address the needs. The SMI was designed when ASN.1 was found >>> to not quite address the needs. XML was designed when other DMLs were >>> found to not quite address the needs. >>> The decision to explore an XML-based DML and to explore a C-like DML >>> follows years and years and years of debate over the requiremnts of >>> network management, and configuration in particular. If every WG >>> spends as much time analyzing the requirements that the >>> OPS area has spent considering this decision, it might be good for >>> ensuring no new protoocls are designed that are not really needed, but >>> the IETF would also grind to a halt, much as the OPS community has >>> done over our many years of debate. And the delay caused by our >>> debates has made IETF network management largely irrelevant to the >>> operator community (our customers). >>> As always, we need to be vigilant and determine whether enough thought >>> has been given to reuse of existing protocols. We also need to >>> consider the tradeoffs between new protocols and reusing existing >>> protocols in ways they were not designed to be used. >>> A4) Why isn't XSD or RelaxNG good enough? >>> As mentioned in A2, NM data models need to be both machine- and >>> human-readable. XSD is machine-readable, but it is a tough language >>> for humans. RelaxNG seems better. As discussed further in a different >>> email, Netconf will almost >>> certainly need a DML suited to its requirements, and if RelaxNG is >>> found to be human-friendly-enough, we would almost certainly still >>> need to select a subset and adapt it to meet configuration >>> requirements. So the benefit of using RelaxNG over a domain-specific >>> DML may be lost by using an adapted-subset of RelaxNG. >>> Most operators already understand languages like Perl and C and >>> Javascript, because they already need to write lots of scripts to >>> manage their networks. Most implementers of NM support in >>> internetworking devices work in C or a variant of C. It makes a lot of >>> sense to use a language with a C-like syntax for these people, rather >>> than forcing them to learn yet another language that was designed for >>> some other purpose. >>> [soap] >>> somebody commented that the designers of XSD and RelaxNG really >>> understand how to design DMLs, implying that the OPS community does >>> not. Many of the people involved in the ongoing DML discussions over >>> the years, and now, are MIB Doctors and operators and protocol >>> designers, and have had years of experience designing and working with >>> SMI and network management. They understand the requirements of a DML >>> for NM far more than the designers of XSD or RelaxNG, who were not >>> designing their DMLs for NM purposes. >>> [end soap] >>> David Harrington >>> dbharrington@comcast.net >>> ietfdbh@comcast.net >> >> > From discuss-bounces@apps.ietf.org Sun Dec 02 15:43:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iyvdo-00006W-Pi; Sun, 02 Dec 2007 15:42:16 -0500 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1Iyvdm-0008OP-LQ for discuss-confirm+ok@megatron.ietf.org; Sun, 02 Dec 2007 15:42:14 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iyvdm-0008OB-Bl for discuss@apps.ietf.org; Sun, 02 Dec 2007 15:42:14 -0500 Received: from wa-out-1112.google.com ([209.85.146.179]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iyvdm-0003ut-0L for discuss@apps.ietf.org; Sun, 02 Dec 2007 15:42:14 -0500 Received: by wa-out-1112.google.com with SMTP id m16so4371820waf for ; Sun, 02 Dec 2007 12:42:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:reply-to:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; bh=lKNsvGXydvTPU5D2vvoBPkc2QBUFU8gfnlcvpXj5FHM=; b=VfCPbXpLPHhDeFOGSqcZFgwgLffXndJfzE6BY777pWTtJBTA1DoMhAl6XyqMRBb8hd9oAjk8z9ifmGDGqqKNRLdLSjS/9vNmLCh9JgrZOWMb+wxCKMY+cQsLqeC8Q6ldQZyE2sUU9KAObKLE76JyDKl4wJ8STa7VeKdY88bClu8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=received:message-id:date:from:reply-to:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=v03plQB5H7+hn21IvDhrGI3bTyrNak6WaK9EAtTzhHSfP8S9mx3oH0gWxqvnmFVjQo1hK4Pm33pBU3w1B+LsP15FX/vg5lAAePvbofu4JFzdjHZeqMWbgwF7ZSRt8nMqVeS92ZDpww1mW3s5Dy8OzFEyXASbncOE6H/7b6WHc8A= Received: by 10.115.107.1 with SMTP id j1mr2972350wam.1196628127093; Sun, 02 Dec 2007 12:42:07 -0800 (PST) Received: by 10.114.161.15 with HTTP; Sun, 2 Dec 2007 12:42:07 -0800 (PST) Message-ID: <517bf110712021242v43c462f0v86267f591e5cdfbd@mail.gmail.com> Date: Sun, 2 Dec 2007 12:42:07 -0800 From: "Tim Bray" To: "Julian Reschke" Subject: Re: analysis of YANG vs. RELAX NG In-Reply-To: <47512728.6040201@gmx.de> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <953beacc0711271504y7aea5f21jc301ccad886d3611@mail.gmail.com> <474D9194.3060103@ericsson.com> <953beacc0711281025w4d993dd7u77d729111074496c@mail.gmail.com> <20071128.230244.254578150.mbj@tail-f.com> <63F8A418-6AF0-4205-ACC7-53A8C7BC6A73@osafoundation.org> <47512728.6040201@gmx.de> X-Google-Sender-Auth: 1e4b1276f90654ba X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Cc: discuss@apps.ietf.org X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: tbray@textuality.com List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org On Dec 1, 2007 1:19 AM, Julian Reschke wrote: > Well, that depends on the schema language. RelaxNG allows to define > languages that use the must-ignore rule for new elements. I've been staying off this thread because I don't understand what a NETCONF is or what you'd do with one. But Julian's point is massively important. If you're going to design your own modeling language, you need to spend a *lot* of time thinking about the extensibility model. It's really easy to get wrong. -Tim From discuss-bounces@apps.ietf.org Sun Dec 02 17:44:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IyxXb-00061c-Cb; Sun, 02 Dec 2007 17:43:59 -0500 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1IyxXZ-00060u-C7 for discuss-confirm+ok@megatron.ietf.org; Sun, 02 Dec 2007 17:43:57 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IyxXZ-00060i-2N for discuss@apps.ietf.org; Sun, 02 Dec 2007 17:43:57 -0500 Received: from rs40.luxsci.com ([65.61.166.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IyxXW-00031q-TZ for discuss@apps.ietf.org; Sun, 02 Dec 2007 17:43:57 -0500 Received: from [192.168.20.199] (c-24-91-195-79.hsd1.ma.comcast.net [24.91.195.79]) (authenticated bits=0) by rs40.luxsci.com (8.13.1/8.13.7) with ESMTP id lB2Mho91028679 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sun, 2 Dec 2007 16:43:51 -0600 In-Reply-To: <47531335.9050800@ericsson.com> References: <474E0F71.2050003@andybierman.com> <241201c83366$9acf8070$6502a8c0@china.huawei.com> <4752F757.5030204@ericsson.com> <94673DD8-1AAB-4ED2-AD27-3AFB4C604F05@jdscons.com> <47531335.9050800@ericsson.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: multipart/alternative; boundary=Apple-Mail-1--715098613 Message-Id: <1319D660-EA6A-4C07-AE39-3F179C45B29A@jdscons.com> From: Jon Saperia Subject: Re: Why NETCONF needs a data modeling language Date: Sun, 2 Dec 2007 17:43:53 -0500 To: balazs.lengyel@ericsson.com X-Mailer: Apple Mail (2.752.3) X-Spam-Score: -1.0 (-) X-Scan-Signature: 3419f078334bcda4102d3d704cee11c6 Cc: yang@ietf.org, discuss@apps.ietf.org, 'NETCONF Goes On' X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org --Apple-Mail-1--715098613 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Wrong order - people will push (not just the vendors for convenience) when there is something that makes a real difference. On Dec 2, 2007, at 3:19 PM, Balazs Lengyel wrote: > Hello, > Naturally our aim is to develop standard NETCONF configuration > models, and the more people use NETCONF the easier that will be. > Balazs > > > Jon Saperia wrote: >> Thanks >> /jon >> ---------------------- >> Jon Saperia >> TSP NM >> (mobil) 617-201-2655 >> (office) 978-461-0249 >> saperia@jdscons.com >> On Dec 2, 2007, at 1:20 PM, Balazs Lengyel wrote: >>> Hello, >>> >> Q1) Why does NETCONF need a DML at all? >>> >>> If we have an IETF standard DML for NETCONF, device vendors (like >>> my company) will be much more comfortable, much more willing to >>> adapt NETCONF itself. With a standard DML we would see a better >>> chance at having available 3rd party or even freeware toolkits >>> for NETCONF. >> Yes, but does that mean that we will begin to develop a standard >> configuration objects for say, BGP or DiffServ that would work >> from one vendor to the next? It would be nice to think so, that >> would really help interoperability and should be the target of >> 'our' collective efforts. >> /jon >>> >>> The above would be important even for a company which would not >>> care about interoperability. >>> >>> Balazs >>> >>> David Harrington wrote: >>>> >>>> >>>>> Hi, >>>>> >>>>> There are a few questions that the IESG and others have asked, >>>>> which I will try to address: >>>>> >>>>> Q1) Why does NETCONF need a DML at all? >>>>> Q2) Why is NETCONF special? >>>>> Q3) Why won't lots of other WGs want to define their own >>>>> protocol-specific DMLs? >>>>> Q4) Why isn't XSD or RelaxNG good enough? >>>> I'll take a whack at answering the same questions. >>>> A1) Why does NETCONF need a DML at all? >>>> to promote vendor-neutral interoperable management. It is much >>>> easier to develop standards when everybody uses the same >>>> basic language to communicate; this "common language for shared >>>> communication" is also reflected in the IETF decision to use >>>> English >>>> text and ASCII documents. >>>> This is not just about being able to standardize **device >>>> management**; it is a basic step to permit the standardization of >>>> **network management** and possibly **services management". The >>>> DML is >>>> a basic building block. >>>> A2) Why is NETCONF special? >>>> It is and it isn't. Netconf is only one protocol used for network >>>> management. It has some unique requirements, such as using a >>>> document-based >>>> approach and differentiating the data for config versus state >>>> and for >>>> dealing with different time-defined contexts such as running and >>>> startup configs. This differs from other network management >>>> protocols, >>>> such as SNMP and syslog and ipfix, which use their own data >>>> formats, >>>> and usually deal only with the currently-running config. Netconf >>>> is a >>>> tool designed to meet the special requirements of configuration, >>>> and >>>> the DML needs to support special features not found in other NM- >>>> DMLs. Netconf is not special, in that any language used for network >>>> management is likely to have certain common requirements. NM data >>>> models are commonly used directly by humans, in their raw form, >>>> such >>>> as when they troubleshoot problems using network sniffers. NM data >>>> models are also commonly used by NMS applications that can >>>> handle the >>>> translations into a more human-readable format. Designers of NM >>>> tools >>>> (e.g., protocols and data models) thus need to pay close >>>> attention to >>>> who will use the information, and to assume that the data will >>>> be used >>>> both directly by humans and by applications. Operators have >>>> complained >>>> strongly that OIDs are very hard to work with in raw form, yet >>>> operators frequently need to deal with the raw form of the data. >>>> A3) Why won't lots of other WGs want to define their own >>>> protocol-specific DMLs? >>>> To paraphrase a wise man from the SNMP community, when you fill >>>> a room >>>> with protocol designers and ask for a solution to a problem, is >>>> it a >>>> surprise when they recommend designing a new protocol? >>>> The decision about whether to use an existing protocol/DML or >>>> develop >>>> a new protocol/DML should be made after a careful analysis of the >>>> requirements of the solution. SNMP was designed when CMIP was >>>> found to >>>> not quite address the needs. The SMI was designed when ASN.1 was >>>> found >>>> to not quite address the needs. XML was designed when other DMLs >>>> were >>>> found to not quite address the needs. >>>> The decision to explore an XML-based DML and to explore a C-like >>>> DML >>>> follows years and years and years of debate over the requiremnts of >>>> network management, and configuration in particular. If every WG >>>> spends as much time analyzing the requirements that the >>>> OPS area has spent considering this decision, it might be good for >>>> ensuring no new protoocls are designed that are not really >>>> needed, but >>>> the IETF would also grind to a halt, much as the OPS community has >>>> done over our many years of debate. And the delay caused by our >>>> debates has made IETF network management largely irrelevant to the >>>> operator community (our customers). >>>> As always, we need to be vigilant and determine whether enough >>>> thought >>>> has been given to reuse of existing protocols. We also need to >>>> consider the tradeoffs between new protocols and reusing existing >>>> protocols in ways they were not designed to be used. >>>> A4) Why isn't XSD or RelaxNG good enough? >>>> As mentioned in A2, NM data models need to be both machine- and >>>> human-readable. XSD is machine-readable, but it is a tough language >>>> for humans. RelaxNG seems better. As discussed further in a >>>> different email, Netconf will almost >>>> certainly need a DML suited to its requirements, and if RelaxNG is >>>> found to be human-friendly-enough, we would almost certainly still >>>> need to select a subset and adapt it to meet configuration >>>> requirements. So the benefit of using RelaxNG over a domain- >>>> specific >>>> DML may be lost by using an adapted-subset of RelaxNG. >>>> Most operators already understand languages like Perl and C and >>>> Javascript, because they already need to write lots of scripts to >>>> manage their networks. Most implementers of NM support in >>>> internetworking devices work in C or a variant of C. It makes a >>>> lot of >>>> sense to use a language with a C-like syntax for these people, >>>> rather >>>> than forcing them to learn yet another language that was >>>> designed for >>>> some other purpose. >>>> [soap] >>>> somebody commented that the designers of XSD and RelaxNG really >>>> understand how to design DMLs, implying that the OPS community does >>>> not. Many of the people involved in the ongoing DML discussions >>>> over >>>> the years, and now, are MIB Doctors and operators and protocol >>>> designers, and have had years of experience designing and >>>> working with >>>> SMI and network management. They understand the requirements of >>>> a DML >>>> for NM far more than the designers of XSD or RelaxNG, who were not >>>> designing their DMLs for NM purposes. >>>> [end soap] >>>> David Harrington >>>> dbharrington@comcast.net >>>> ietfdbh@comcast.net >>> >>> > Thanks, /jon ---- Jon Saperia saperia@jdscons.com (mobil) 617-201-2655 (office) 978-461-0249 --Apple-Mail-1--715098613 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1 Wrong order - people will push (not just the vendors for convenience) = when there is something that makes a real difference.
On = Dec 2, 2007, at 3:19 PM, Balazs Lengyel wrote:

Hello,
Naturally our = aim is to develop standard NETCONF configuration models, and the more = people use NETCONF the easier that will be.


Jon = Saperia wrote:
/jon
----------------------
Jon = Saperia
TSP NM
(mobil) 617-201-2655
(office) = 978-461-0249
saperia@jdscons.com <mailto:saperia@jdscons.com>
On Dec 2, 2007, at 1:20 PM, Balazs Lengyel = wrote:
>>=A0 =A0 Q1) Why does NETCONF need = a DML at all?

If we have an IETF standard DML for NETCONF, device = vendors (like my company) will be much more comfortable, much more = willing to adapt NETCONF itself. With a standard DML we would see a = better chance at having available 3rd party or even freeware toolkits = for NETCONF.
Yes, but does = that mean that we will begin to develop a standard configuration objects = for say, BGP or DiffServ that would work from one vendor to the = next?=A0 It would be nice = to think so, that would really help interoperability and should be the = target of 'our' collective efforts.
/jon
=
The above would be important = even for a company which would not care about = interoperability.

Balazs

David Harrington wrote:
=
=A0

Hi,

There are a few questions that = the IESG and others have asked,
which I will = try to address:

=A0=A0 = Q1) Why does NETCONF need a DML at all?
=A0=A0 = Q2) Why is NETCONF special?
=A0=A0 Q3) Why won't lots of = other WGs want to define their own
=A0=A0 =A0 =A0 protocol-specific = DMLs?
=A0=A0 Q4) Why isn't XSD or = RelaxNG good enough?
I'll take a = whack at answering the same questions.
A1) Why = does NETCONF need a DML at all?
to promote = vendor-neutral interoperable management. It is much easier to develop = standards when everybody uses the same
basic = language to communicate; this "common language for shared
communication" is also reflected in the IETF = decision to use English
text and = ASCII documents.
This is not just about being = able to standardize **device
management**; = it is a basic step to permit the standardization of
**network management** and possibly **services = management". The DML is
a basic = building block.
A2) Why is NETCONF = special?
It is and it isn't. Netconf is = only one protocol used for network
management. = It has some unique requirements, such as using a = document-based
approach and differentiating the = data for config versus state and for
dealing with = different time-defined contexts such as running and
startup configs. This differs from other network = management protocols,
such as SNMP and syslog and = ipfix, which use their own data formats,
and = usually deal only with the currently-running config. Netconf is = a
tool designed to meet the special requirements = of configuration, and
the DML needs to support = special features not found in other NM-DMLs. Netconf is not special, in = that any language used for network
management is = likely to have certain common requirements. NM data
models are commonly used directly by humans, in = their raw form, such
as when they troubleshoot = problems using network sniffers. NM data
models = are also commonly used by NMS applications that can handle the
translations into a more human-readable format. = Designers of NM tools
(e.g., protocols and data = models) thus need to pay close attention to
who = will use the information, and to assume that the data will be = used
both directly by humans and by = applications. Operators have complained
strongly = that OIDs are very hard to work with in raw form, yet
operators frequently need to deal with the raw form = of the data. A3) Why won't lots of other WGs want to define their = own
=A0 =A0 =A0 =A0 protocol-specific = DMLs?
To paraphrase a wise man from = the SNMP community, when you fill a room
with = protocol designers and ask for a solution to a problem, is it = a
surprise when they recommend designing a new = protocol?
The decision about whether to = use an existing protocol/DML or develop
a new = protocol/DML should be made after a careful analysis of the
requirements of the solution. SNMP was designed when = CMIP was found to
not quite address the needs. The = SMI was designed when ASN.1 was found
to not = quite address the needs. XML was designed when other DMLs were
found to not quite address the needs.
The decision to explore an XML-based DML and to = explore a C-like DML
follows years and years and = years of debate over the requiremnts of
network = management, and configuration in particular. If every WG spends as much = time analyzing the requirements that the
OPS area = has spent considering this decision, it might be good for
ensuring no new protoocls are designed that are not = really needed, but
the IETF would also grind = to a halt, much as the OPS community has
done = over our many years of debate. And the delay caused by our
debates has made IETF network management largely = irrelevant to the
operator community (our = customers).
As always, we need to be = vigilant and determine whether enough thought
has been given to reuse of existing protocols. We = also need to
consider the tradeoffs between = new protocols and reusing existing
protocols in = ways they were not designed to be used.
A4) Why = isn't XSD or RelaxNG good enough?
As mentioned = in A2, NM data models need to be both machine- and
human-readable. XSD is machine-readable, but it is a = tough language
for humans. RelaxNG seems = better. As discussed further in a different email, Netconf will = almost
certainly need a DML suited to = its requirements, and if RelaxNG is
found to be = human-friendly-enough, we would almost certainly still
need to select a subset and adapt it to meet = configuration
requirements. So the benefit of = using RelaxNG over a domain-specific
DML may be = lost by using an adapted-subset of RelaxNG.
Most = operators already understand languages like Perl and C and
Javascript, because they already need to write lots = of scripts to
manage their networks. Most = implementers of NM support in
sense to use a language with a C-like syntax = for these people, rather
than forcing = them to learn yet another language that was designed for
some other purpose.
somebody commented that the = designers of XSD and RelaxNG really
understand = how to design DMLs, implying that the OPS community does
not. Many of the people involved in the ongoing DML = discussions over
the years, and now, are MIB = Doctors and operators and protocol
designers, = and have had years of experience designing and working with
SMI and network management. They understand the = requirements of a DML
for NM far more than the = designers of XSD or RelaxNG, who were not
[end = soap]
David Harrington
dbharrington@comcast.net <mailto:dbharrington@comcast.net>


=
saperia@jdscons.com
(mob= il) = 617-201-2655
(office) = 978-461-0249



= --Apple-Mail-1--715098613-- From discuss-bounces@apps.ietf.org Sun Dec 02 18:23:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iyy9o-0007Xj-GP; Sun, 02 Dec 2007 18:23:28 -0500 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1Iyy9n-0007SX-Cv for discuss-confirm+ok@megatron.ietf.org; Sun, 02 Dec 2007 18:23:27 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iyy9m-0007Ri-Tt for discuss@apps.ietf.org; Sun, 02 Dec 2007 18:23:26 -0500 Received: from mxout-04.mxes.net ([216.86.168.179]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iyy9m-00085B-It for discuss@apps.ietf.org; Sun, 02 Dec 2007 18:23:26 -0500 Received: from [130.129.84.85] (unknown [130.129.84.85]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTP id 9B878D0502 for ; Sun, 2 Dec 2007 18:23:23 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v752.3) Content-Transfer-Encoding: 7bit Message-Id: <66E22E2C-B8C4-44F0-A8BC-A044584D966C@mnot.net> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: Apps Discuss From: Mark Nottingham Subject: Another ACAP Date: Sun, 2 Dec 2007 15:23:16 -0800 X-Mailer: Apple Mail (2.752.3) X-Spam-Score: -0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org http://www.the-acap.org/ Besides the name collision, this is related to previous APPS area discussions about robots.txt, etc. -- Mark Nottingham http://www.mnot.net/ From discuss-bounces@apps.ietf.org Sun Dec 02 20:56:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iz0Y2-0007XT-CS; Sun, 02 Dec 2007 20:56:38 -0500 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1Iz0Y1-0007XH-6o for discuss-confirm+ok@megatron.ietf.org; Sun, 02 Dec 2007 20:56:37 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iz0Y0-0007X8-T6 for discuss@apps.ietf.org; Sun, 02 Dec 2007 20:56:36 -0500 Received: from wa-out-1112.google.com ([209.85.146.181]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iz0Y0-0000Xl-Du for discuss@apps.ietf.org; Sun, 02 Dec 2007 20:56:36 -0500 Received: by wa-out-1112.google.com with SMTP id m16so4568669waf for ; Sun, 02 Dec 2007 17:56:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:reply-to:sender:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition:x-google-sender-auth; bh=XAprtpwxX7umf8A+VBDz3AgDHOx7ulomN1HEjeH1RNk=; b=S1p+IUMYOwNrND6giB6n/o+N4fo21TseIT/FEpQqjv9/4HlCIws9zuI1tOezcIacoc6VjORofZnr/yel29CQP1zptlCmZdzdES+qSF0Y/zWTJAWYPNmugg3/pwnlZgsiT5dRmfq8qEfe0jJHmDn8lgTyIaSTg03ROjotWIpfDwQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=received:message-id:date:from:reply-to:sender:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition:x-google-sender-auth; b=CY6VM7WwWXiEzzqPWlBydkpv/WgXFwG1w2f2X6cSq4CvS9WqVNl8kBSVJJ1J/k5N/dnpRdYl1p1hvoBNxm7RPK+8wy79WSDixKcdqCWueDA//ymzkZspi2Y7pGyYm4kkBaX3J43yfeuZf5NZMM+dwWcL3UTn1W/20tneclPFC3o= Received: by 10.114.38.2 with SMTP id l2mr3193184wal.1196646995202; Sun, 02 Dec 2007 17:56:35 -0800 (PST) Received: by 10.114.161.15 with HTTP; Sun, 2 Dec 2007 17:56:34 -0800 (PST) Message-ID: <517bf110712021756v5f5d6774ya2489dcaa092e6@mail.gmail.com> Date: Sun, 2 Dec 2007 17:56:34 -0800 From: "Tim Bray" To: "Apps Discuss" Subject: My slides from the Sunday XML session MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Google-Sender-Auth: e15942974f376d9a X-Spam-Score: 0.0 (/) X-Scan-Signature: 01485d64dfa90b45a74269b3ca9d5574 X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: tbray@textuality.com List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org Online at http://www.tbray.org/tmp/IETF70.pdf -Tim From discuss-bounces@apps.ietf.org Mon Dec 03 04:45:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iz7qG-0005a3-BR; Mon, 03 Dec 2007 04:43:56 -0500 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1Iz7qE-0005ZB-FL for discuss-confirm+ok@megatron.ietf.org; Mon, 03 Dec 2007 04:43:54 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iz7qE-0005Z2-5o for discuss@apps.ietf.org; Mon, 03 Dec 2007 04:43:54 -0500 Received: from mx2.nic.fr ([192.134.4.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iz7qC-0002XX-6r for discuss@apps.ietf.org; Mon, 03 Dec 2007 04:43:54 -0500 Received: from mx2.nic.fr (localhost [127.0.0.1]) by mx2.nic.fr (Postfix) with SMTP id 452F01C00F4; Mon, 3 Dec 2007 10:43:51 +0100 (CET) Received: from relay2.nic.fr (relay2.nic.fr [192.134.4.163]) by mx2.nic.fr (Postfix) with ESMTP id 409541C00D7; Mon, 3 Dec 2007 10:43:51 +0100 (CET) Received: from bortzmeyer.nic.fr (batilda.nic.fr [192.134.4.69]) by relay2.nic.fr (Postfix) with ESMTP id 3E7C958ECBE; Mon, 3 Dec 2007 10:43:51 +0100 (CET) Date: Mon, 3 Dec 2007 10:43:51 +0100 From: Stephane Bortzmeyer To: Dave Cridland Subject: Re: I-D Action:draft-newman-email-subaddr-01.txt Message-ID: <20071203094351.GA19449@nic.fr> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Operating-System: Debian GNU/Linux 4.0 X-Kernel: Linux 2.6.18-5-686 i686 Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: Mutt/1.5.13 (2006-08-11) X-Spam-Score: -4.0 (----) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: Apps Discuss X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org [No discussion list indicated in the draft, trying the Application Area general list.] On Fri, Nov 16, 2007 at 12:50:01PM -0500, Internet-Drafts@ietf.org wrote a message of 97 lines which said: > Title : Internet Email Subaddressing > Author(s) : D. Cridland > Filename : draft-newman-email-subaddr-01.txt I'm quite puzzled by this draft and I do not really understand what it normalizes or what its purpose is. The entire idea of subaddressing is to be a local decision, only the final MTA and/or its MDA will have to know it. Besides stuff like RFC 3598, there is little room for IETF work. Some sentences in the draft are strange, in that respect. For instance, section 4.2 says "A subaddress-aware gateway or firewall SHOULD preserve the detail part when rewriting an address." while I thought that the SMTP rule was much stronger: "DO NOT MESS with addresses", and that is a general rule, it is not only for subaddressing. Apart from that, the draft puts too much emphasis on the most common "+" (with a MTA like Postfix, it is trivial to change it - the recipient_delimiter option, and many people do so to avoid the problem of broken software mentioned later). Again, the IETF should not mention this separator, since it is a local decision. Strangely enough, the draft does not talk about *the* big problem with subaddressing: the fact that many stupid and broken Web forms and/or mail software do not accept them or do not handle them properly. Certainly, an informational RFC asking to accept valid email addresses would be an useful document. See a good start in http://www.linuxjournal.com/article/9585, specially the conclusion ("There is some danger that common usage and widespread sloppy coding will establish a de facto standard for e-mail addresses that is more restrictive than the recorded formal standard.") or in http://worsethanfailure.com/Articles/Validating_Email_Addresses.aspx (the comments are interesting, too). From discuss-bounces@apps.ietf.org Mon Dec 03 08:57:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzBmZ-00056H-H5; Mon, 03 Dec 2007 08:56:23 -0500 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1IzBmY-000566-Kc for discuss-confirm+ok@megatron.ietf.org; Mon, 03 Dec 2007 08:56:22 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzBmY-00055o-7Q for discuss@apps.ietf.org; Mon, 03 Dec 2007 08:56:22 -0500 Received: from office2.cesnet.cz ([195.113.144.244]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IzBmW-0004Cx-Kp for discuss@apps.ietf.org; Mon, 03 Dec 2007 08:56:22 -0500 Received: from [198.18.175.153] (unknown [207.236.117.226]) by office2.cesnet.cz (Postfix) with ESMTP id 2CA8CD800C7 for ; Mon, 3 Dec 2007 14:56:13 +0100 (CET) Subject: Re: analysis of YANG vs. RELAX NG From: Ladislav Lhotka To: discuss@apps.ietf.org In-Reply-To: <517bf110712021242v43c462f0v86267f591e5cdfbd@mail.gmail.com> References: <953beacc0711271504y7aea5f21jc301ccad886d3611@mail.gmail.com> <474D9194.3060103@ericsson.com> <953beacc0711281025w4d993dd7u77d729111074496c@mail.gmail.com> <20071128.230244.254578150.mbj@tail-f.com> <63F8A418-6AF0-4205-ACC7-53A8C7BC6A73@osafoundation.org> <47512728.6040201@gmx.de> <517bf110712021242v43c462f0v86267f591e5cdfbd@mail.gmail.com> Content-Type: text/plain; charset=utf-8 Organization: CESNET Date: Mon, 03 Dec 2007 14:56:02 +0100 Message-Id: <1196690162.5874.13.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.12.1 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org Tim Bray p=C3=AD=C5=A1e v Ne 02. 12. 2007 v 12:42 -0800: > I've been staying off this thread because I don't understand what a > NETCONF is or what you'd do with one. But Julian's point is massively > important. If you're going to design your own modeling language, you > need to spend a *lot* of time thinking about the extensibility model. > It's really easy to get wrong. -Tim Indeed. An extensibility problem in YANG is IMO the leaf statement. It is encoded as an XML element but the fact that it is declared as leaf effectively makes it into an XML attribute: It is impossible to extend it (e.g., add a qualifying subelement) without changing the leaf into container. In a RELAX NG schema, if properly designed, such an extension wouldn't have to touch the parent schema. Another problem might be the default statement in leaves (or it is proper to say leafs here?:-) or typedefs. What if a standard data model defines an item, say a hello timer, with such a default, but an implementation wants to use another value for the default? Should it come up with another schema? Lada --=20 Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From discuss-bounces@apps.ietf.org Mon Dec 03 09:10:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzByn-0004kY-Hw; Mon, 03 Dec 2007 09:09:01 -0500 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1IzByl-0004k0-OG for discuss-confirm+ok@megatron.ietf.org; Mon, 03 Dec 2007 09:08:59 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzByl-0004js-Ej for discuss@apps.ietf.org; Mon, 03 Dec 2007 09:08:59 -0500 Received: from hermes.jacobs-university.de ([212.201.44.23]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IzByi-0005Hs-W7 for discuss@apps.ietf.org; Mon, 03 Dec 2007 09:08:59 -0500 Received: from localhost (demetrius.jacobs-university.de [212.201.44.32]) by hermes.jacobs-university.de (Postfix) with ESMTP id A33B686267; Mon, 3 Dec 2007 15:08:55 +0100 (CET) Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 04989-05-6; Mon, 3 Dec 2007 15:08:50 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id E152B8A2D9; Mon, 3 Dec 2007 15:08:46 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id DD4B340671A; Mon, 3 Dec 2007 15:08:46 +0100 (CET) Date: Mon, 3 Dec 2007 15:08:46 +0100 From: Juergen Schoenwaelder To: Ladislav Lhotka Subject: Re: analysis of YANG vs. RELAX NG Message-ID: <20071203140846.GB17536@elstar.local> References: <953beacc0711271504y7aea5f21jc301ccad886d3611@mail.gmail.com> <474D9194.3060103@ericsson.com> <953beacc0711281025w4d993dd7u77d729111074496c@mail.gmail.com> <20071128.230244.254578150.mbj@tail-f.com> <63F8A418-6AF0-4205-ACC7-53A8C7BC6A73@osafoundation.org> <47512728.6040201@gmx.de> <517bf110712021242v43c462f0v86267f591e5cdfbd@mail.gmail.com> <1196690162.5874.13.camel@missotis> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1196690162.5874.13.camel@missotis> User-Agent: Mutt/1.5.17 (2007-11-01) X-Virus-Scanned: amavisd-new 2.3.3 (20050822) at jacobs-university.de X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: discuss@apps.ietf.org X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org On Mon, Dec 03, 2007 at 02:56:02PM +0100, Ladislav Lhotka wrote: > Tim Bray p????e v Ne 02. 12. 2007 v 12:42 -0800: > > I've been staying off this thread because I don't understand what a > > NETCONF is or what you'd do with one. But Julian's point is massively > > important. If you're going to design your own modeling language, you > > need to spend a *lot* of time thinking about the extensibility model. > > It's really easy to get wrong. -Tim > > Indeed. An extensibility problem in YANG is IMO the leaf statement. It > is encoded as an XML element but the fact that it is declared as leaf > effectively makes it into an XML attribute: It is impossible to extend > it (e.g., add a qualifying subelement) without changing the leaf into > container. In a RELAX NG schema, if properly designed, such an extension > wouldn't have to touch the parent schema. Leafs carry data and we strongly dislike mixed contents in NETCONF. So this is actually a YANG feature and not a bug. > Another problem might be the default statement in leaves (or it is > proper to say leafs here?:-) or typedefs. What if a standard data model > defines an item, say a hello timer, with such a default, but an > implementation wants to use another value for the default? Should it > come up with another schema? No. There can only be one standard default. If you are thinking about reusable groupings, then defaults can actually be changed wherever you apply a grouping as far as I know. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From discuss-bounces@apps.ietf.org Mon Dec 03 09:34:25 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzCMV-0006bc-HM; Mon, 03 Dec 2007 09:33:31 -0500 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1IzCMU-0006bA-6P for discuss-confirm+ok@megatron.ietf.org; Mon, 03 Dec 2007 09:33:30 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzCMT-0006ax-ON for discuss@apps.ietf.org; Mon, 03 Dec 2007 09:33:29 -0500 Received: from office2.cesnet.cz ([195.113.144.244]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IzCMT-0007Sl-6D for discuss@apps.ietf.org; Mon, 03 Dec 2007 09:33:29 -0500 Received: from [198.18.175.153] (unknown [207.236.117.226]) by office2.cesnet.cz (Postfix) with ESMTP id C30B3D80098; Mon, 3 Dec 2007 15:33:25 +0100 (CET) Subject: Re: analysis of YANG vs. RELAX NG From: Ladislav Lhotka To: j.schoenwaelder@jacobs-university.de In-Reply-To: <20071203140846.GB17536@elstar.local> References: <953beacc0711271504y7aea5f21jc301ccad886d3611@mail.gmail.com> <474D9194.3060103@ericsson.com> <953beacc0711281025w4d993dd7u77d729111074496c@mail.gmail.com> <20071128.230244.254578150.mbj@tail-f.com> <63F8A418-6AF0-4205-ACC7-53A8C7BC6A73@osafoundation.org> <47512728.6040201@gmx.de> <517bf110712021242v43c462f0v86267f591e5cdfbd@mail.gmail.com> <1196690162.5874.13.camel@missotis> <20071203140846.GB17536@elstar.local> Content-Type: text/plain; charset=utf-8 Organization: CESNET Date: Mon, 03 Dec 2007 15:33:24 +0100 Message-Id: <1196692404.5874.36.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.12.1 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Cc: discuss@apps.ietf.org X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org Juergen Schoenwaelder p=C3=AD=C5=A1e v Po 03. 12. 2007 v 15:08 +0100: > On Mon, Dec 03, 2007 at 02:56:02PM +0100, Ladislav Lhotka wrote: > > Tim Bray p????e v Ne 02. 12. 2007 v 12:42 -0800: > > > I've been staying off this thread because I don't understand what a > > > NETCONF is or what you'd do with one. But Julian's point is massiv= ely > > > important. If you're going to design your own modeling language, y= ou > > > need to spend a *lot* of time thinking about the extensibility mode= l. > > > It's really easy to get wrong. -Tim > >=20 > > Indeed. An extensibility problem in YANG is IMO the leaf statement. I= t > > is encoded as an XML element but the fact that it is declared as leaf > > effectively makes it into an XML attribute: It is impossible to exten= d > > it (e.g., add a qualifying subelement) without changing the leaf into > > container. In a RELAX NG schema, if properly designed, such an extens= ion > > wouldn't have to touch the parent schema. >=20 > Leafs carry data and we strongly dislike mixed contents in NETCONF. So > this is actually a YANG feature and not a bug. It doesn't necessarily mean mixed content, just changing XYZ into ABC XYZ Or, alternatively, the qualification info can be encoded in an attribute, which doesn't seem to be possible in YANG at all. I know, attributes are also frowned upon, but sometimes such a flexibility comes handy - and, after all, in some situations the extra attribute can be understood as metadata. > =20 > > Another problem might be the default statement in leaves (or it is > > proper to say leafs here?:-) or typedefs. What if a standard data mod= el > > defines an item, say a hello timer, with such a default, but an > > implementation wants to use another value for the default? Should it > > come up with another schema? >=20 > No. There can only be one standard default. If you are thinking about > reusable groupings, then defaults can actually be changed wherever you > apply a grouping as far as I know. Protocols specifications in RFCS usually say that a particular default value SHOULD be something. So an impementation might have a reason for using something else. In such cases, the standard data model thus cannot use the default statement, right?=20 Lada --=20 Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From discuss-bounces@apps.ietf.org Mon Dec 03 10:35:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzDJn-00009a-Cb; Mon, 03 Dec 2007 10:34:47 -0500 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1IzDJm-000094-8u for discuss-confirm+ok@megatron.ietf.org; Mon, 03 Dec 2007 10:34:46 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzDJl-00008s-Vg for discuss@apps.ietf.org; Mon, 03 Dec 2007 10:34:45 -0500 Received: from hermes.jacobs-university.de ([212.201.44.23]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IzDJl-0005bN-8I for discuss@apps.ietf.org; Mon, 03 Dec 2007 10:34:45 -0500 Received: from localhost (demetrius.jacobs-university.de [212.201.44.32]) by hermes.jacobs-university.de (Postfix) with ESMTP id B39C28A2DF; Mon, 3 Dec 2007 16:34:44 +0100 (CET) Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 15352-08-10; Mon, 3 Dec 2007 16:34:39 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 5037C8A2FB; Mon, 3 Dec 2007 16:34:10 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 5406540687F; Mon, 3 Dec 2007 16:34:10 +0100 (CET) Date: Mon, 3 Dec 2007 16:34:10 +0100 From: Juergen Schoenwaelder To: Ladislav Lhotka Subject: Re: analysis of YANG vs. RELAX NG Message-ID: <20071203153410.GA17459@elstar.local> References: <953beacc0711271504y7aea5f21jc301ccad886d3611@mail.gmail.com> <474D9194.3060103@ericsson.com> <953beacc0711281025w4d993dd7u77d729111074496c@mail.gmail.com> <20071128.230244.254578150.mbj@tail-f.com> <63F8A418-6AF0-4205-ACC7-53A8C7BC6A73@osafoundation.org> <47512728.6040201@gmx.de> <517bf110712021242v43c462f0v86267f591e5cdfbd@mail.gmail.com> <1196690162.5874.13.camel@missotis> <20071203140846.GB17536@elstar.local> <1196692404.5874.36.camel@missotis> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1196692404.5874.36.camel@missotis> User-Agent: Mutt/1.5.17 (2007-11-01) X-Virus-Scanned: amavisd-new 2.3.3 (20050822) at jacobs-university.de X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Cc: discuss@apps.ietf.org X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org On Mon, Dec 03, 2007 at 03:33:24PM +0100, Ladislav Lhotka wrote: > It doesn't necessarily mean mixed content, just changing > > XYZ > > into > > > ABC > XYZ > > > Or, alternatively, the qualification info can be encoded in an > attribute, which doesn't seem to be possible in YANG at all. I know, > attributes are also frowned upon, but sometimes such a flexibility comes > handy - and, after all, in some situations the extra attribute can be > understood as metadata. Historically, network management protocols did not allow such a change of semantics of a defined construct. Once you have standardized XYZ, then it is supposed to be exactly that. If you allow changes as suggested above, the life of management applications that have to support multiple versions becomes fun. Note also that it is common to have references between different parts of a larger data model and if you are allowed to make changes as above, you might break references you are not aware of. The versioning rules therefore have always been "once published, don't change" and "if broken, create something new which is better". > > > Another problem might be the default statement in leaves (or it is > > > proper to say leafs here?:-) or typedefs. What if a standard data model > > > defines an item, say a hello timer, with such a default, but an > > > implementation wants to use another value for the default? Should it > > > come up with another schema? > > > > No. There can only be one standard default. If you are thinking about > > reusable groupings, then defaults can actually be changed wherever you > > apply a grouping as far as I know. > > Protocols specifications in RFCS usually say that a particular default > value SHOULD be something. So an impementation might have a reason for > using something else. In such cases, the standard data model thus cannot > use the default statement, right? Yes, YANG says: If the leaf has a default value, the server MUST use this value internally if no value is provided by the NETCONF client when the instance is created. So yes, a YANG default is a contract between the device and the manager I can rely on. You may argue this is bad and sure such a discussion can be held. But we did this knowingly and not as an accident. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From discuss-bounces@apps.ietf.org Mon Dec 03 10:36:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzDKr-0001jP-88; Mon, 03 Dec 2007 10:35:53 -0500 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1IzDKp-0001eF-LL for discuss-confirm+ok@megatron.ietf.org; Mon, 03 Dec 2007 10:35:51 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzDKp-0001dm-Bf for discuss@apps.ietf.org; Mon, 03 Dec 2007 10:35:51 -0500 Received: from mx2.nic.fr ([192.134.4.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IzDKn-0005oZ-RE for discuss@apps.ietf.org; Mon, 03 Dec 2007 10:35:51 -0500 Received: from mx2.nic.fr (localhost [127.0.0.1]) by mx2.nic.fr (Postfix) with SMTP id 522871C00E2 for ; Mon, 3 Dec 2007 16:35:49 +0100 (CET) Received: from relay2.nic.fr (relay2.nic.fr [192.134.4.163]) by mx2.nic.fr (Postfix) with ESMTP id 4E6E91C00D7 for ; Mon, 3 Dec 2007 16:35:49 +0100 (CET) Received: from bortzmeyer.nic.fr (batilda.nic.fr [192.134.4.69]) by relay2.nic.fr (Postfix) with ESMTP id 41C1658ECBE for ; Mon, 3 Dec 2007 16:35:49 +0100 (CET) Date: Mon, 3 Dec 2007 16:35:49 +0100 From: Stephane Bortzmeyer To: discuss@apps.ietf.org Subject: Re: I-D Action:draft-klensin-unicode-escapes-07.txt Message-ID: <20071203153549.GA26126@nic.fr> References: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: X-Operating-System: Debian GNU/Linux 4.0 X-Kernel: Linux 2.6.18-5-686 i686 Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: Mutt/1.5.13 (2006-08-11) Content-Transfer-Encoding: quoted-printable X-Spam-Score: -4.0 (----) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org On Sat, Nov 17, 2007 at 02:20:02AM -0500, Internet-Drafts@ietf.org wrote=20 a message of 96 lines which said: > Title : ASCII Escaping of Unicode Characters > Author(s) : J. Klensin > Filename : draft-klensin-unicode-escapes-07.txt I've read it and, IMHO, the small changes between -06 and -07 integrates nicely the remarks (mostly by Martin D=FCrst) about Unicode terminology, which is now more standard. [For the record, I still disagree with the so-called "possible ambiguity" in section 6.2 but it seems I'm the only one.] From discuss-bounces@apps.ietf.org Mon Dec 03 12:24:22 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzF10-0004AW-9J; Mon, 03 Dec 2007 12:23:30 -0500 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1IzF0y-0004AH-Ka for discuss-confirm+ok@megatron.ietf.org; Mon, 03 Dec 2007 12:23:28 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzF0y-0004A7-Ax for discuss@apps.ietf.org; Mon, 03 Dec 2007 12:23:28 -0500 Received: from omr6.networksolutionsemail.com ([205.178.146.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IzF0w-0001Pl-CG for discuss@apps.ietf.org; Mon, 03 Dec 2007 12:23:28 -0500 Received: from mail.networksolutionsemail.com (ns-omr6.mgt.netsol.com [10.49.6.69]) by omr6.networksolutionsemail.com (8.13.6/8.13.6) with SMTP id lB3HNPdN026431 for ; Mon, 3 Dec 2007 12:23:26 -0500 Received: (qmail 910 invoked by uid 78); 3 Dec 2007 17:23:25 -0000 Received: from unknown (HELO ?130.129.85.76?) (andy@andybierman.com@130.129.85.76) by ns-omr6.lb.hosting.dc2.netsol.com with SMTP; 3 Dec 2007 17:23:25 -0000 Message-ID: <47543B30.1060409@andybierman.com> Date: Mon, 03 Dec 2007 09:21:52 -0800 From: Andy Bierman User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: j.schoenwaelder@jacobs-university.de Subject: Re: analysis of YANG vs. RELAX NG References: <953beacc0711271504y7aea5f21jc301ccad886d3611@mail.gmail.com> <474D9194.3060103@ericsson.com> <953beacc0711281025w4d993dd7u77d729111074496c@mail.gmail.com> <20071128.230244.254578150.mbj@tail-f.com> <63F8A418-6AF0-4205-ACC7-53A8C7BC6A73@osafoundation.org> <47512728.6040201@gmx.de> <517bf110712021242v43c462f0v86267f591e5cdfbd@mail.gmail.com> <1196690162.5874.13.camel@missotis> <20071203140846.GB17536@elstar.local> In-Reply-To: <20071203140846.GB17536@elstar.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -1.0 (-) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: discuss@apps.ietf.org X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org Juergen Schoenwaelder wrote: > On Mon, Dec 03, 2007 at 02:56:02PM +0100, Ladislav Lhotka wrote: > >> Tim Bray p????e v Ne 02. 12. 2007 v 12:42 -0800: >> >>> I've been staying off this thread because I don't understand what a >>> NETCONF is or what you'd do with one. But Julian's point is massively >>> important. If you're going to design your own modeling language, you >>> need to spend a *lot* of time thinking about the extensibility model. >>> It's really easy to get wrong. -Tim >>> >> Indeed. An extensibility problem in YANG is IMO the leaf statement. It >> is encoded as an XML element but the fact that it is declared as leaf >> effectively makes it into an XML attribute: It is impossible to extend >> it (e.g., add a qualifying subelement) without changing the leaf into >> container. In a RELAX NG schema, if properly designed, such an extension >> wouldn't have to touch the parent schema. >> > > Leafs carry data and we strongly dislike mixed contents in NETCONF. So > this is actually a YANG feature and not a bug. > > I strongly agree with Juergen. YANG is based (in part) on 18+ years experience with SNMP and SMI. It s absolutely forbidden in NM to redefine the syntax and semantics of a managed object in this way. Andy >> Another problem might be the default statement in leaves (or it is >> proper to say leafs here?:-) or typedefs. What if a standard data model >> defines an item, say a hello timer, with such a default, but an >> implementation wants to use another value for the default? Should it >> come up with another schema? >> > > No. There can only be one standard default. If you are thinking about > reusable groupings, then defaults can actually be changed wherever you > apply a grouping as far as I know. > > /js > > From discuss-bounces@apps.ietf.org Mon Dec 03 13:03:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzFcd-0003hC-Pg; Mon, 03 Dec 2007 13:02:23 -0500 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1IzFcc-0003ed-Az for discuss-confirm+ok@megatron.ietf.org; Mon, 03 Dec 2007 13:02:22 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzFcc-0003ds-1G for discuss@apps.ietf.org; Mon, 03 Dec 2007 13:02:22 -0500 Received: from office2.cesnet.cz ([195.113.144.244]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IzFca-0005db-Fd for discuss@apps.ietf.org; Mon, 03 Dec 2007 13:02:22 -0500 Received: from [130.129.20.210] (dhcp-14d2.ietf70.org [130.129.20.210]) by office2.cesnet.cz (Postfix) with ESMTP id 29307D800C1; Mon, 3 Dec 2007 19:02:10 +0100 (CET) Subject: Re: analysis of YANG vs. RELAX NG From: Ladislav Lhotka To: Andy Bierman In-Reply-To: <47543B30.1060409@andybierman.com> References: <953beacc0711271504y7aea5f21jc301ccad886d3611@mail.gmail.com> <474D9194.3060103@ericsson.com> <953beacc0711281025w4d993dd7u77d729111074496c@mail.gmail.com> <20071128.230244.254578150.mbj@tail-f.com> <63F8A418-6AF0-4205-ACC7-53A8C7BC6A73@osafoundation.org> <47512728.6040201@gmx.de> <517bf110712021242v43c462f0v86267f591e5cdfbd@mail.gmail.com> <1196690162.5874.13.camel@missotis> <20071203140846.GB17536@elstar.local> <47543B30.1060409@andybierman.com> Content-Type: text/plain; charset=utf-8 Organization: CESNET Date: Mon, 03 Dec 2007 19:02:03 +0100 Message-Id: <1196704923.5569.14.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.12.1 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: discuss@apps.ietf.org X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org Andy Bierman p=C3=AD=C5=A1e v Po 03. 12. 2007 v 09:21 -0800: > I strongly agree with Juergen. > YANG is based (in part) on 18+ years experience > with SNMP and SMI. And ignoring the additional flexibility XML can provide. >=20 > It s absolutely forbidden in NM to redefine the syntax and semantics > of a managed object in this way. Why? Even if I explicitly specify I am using another data model? The difference is that if the data model is easily extensible, I can just write import parent-model; and then 5 lines or so describing the differences, so that it is immediately clear what I am doing (and hopefully why). If the extensibility is weak, I have to take the parent model, change few lines and declare it as a new data model - but the differences are not that clear. Lada =20 --=20 Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From discuss-bounces@apps.ietf.org Mon Dec 03 13:12:28 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzFlW-0003Jy-7o; Mon, 03 Dec 2007 13:11:34 -0500 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1IzFlU-0003Hu-UV for discuss-confirm+ok@megatron.ietf.org; Mon, 03 Dec 2007 13:11:32 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzFlU-0003Hm-K5 for discuss@apps.ietf.org; Mon, 03 Dec 2007 13:11:32 -0500 Received: from omr4.networksolutionsemail.com ([205.178.146.54]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IzFlS-0006Pb-Fp for discuss@apps.ietf.org; Mon, 03 Dec 2007 13:11:32 -0500 Received: from mail.networksolutionsemail.com (ns-omr4.mgt.netsol.com [10.49.6.67]) by omr4.networksolutionsemail.com (8.13.6/8.13.6) with SMTP id lB3IAwd5001930 for ; Mon, 3 Dec 2007 13:11:21 -0500 Received: (qmail 30610 invoked by uid 78); 3 Dec 2007 18:10:30 -0000 Received: from unknown (HELO ?130.129.85.76?) (andy@andybierman.com@130.129.85.76) by ns-omr4.lb.hosting.dc2.netsol.com with SMTP; 3 Dec 2007 18:10:30 -0000 Message-ID: <4754463C.2070901@andybierman.com> Date: Mon, 03 Dec 2007 10:09:00 -0800 From: Andy Bierman User-Agent: Thunderbird 1.5.0.13 (Windows/20070809) MIME-Version: 1.0 To: Ladislav Lhotka Subject: Re: analysis of YANG vs. RELAX NG References: <953beacc0711271504y7aea5f21jc301ccad886d3611@mail.gmail.com> <474D9194.3060103@ericsson.com> <953beacc0711281025w4d993dd7u77d729111074496c@mail.gmail.com> <20071128.230244.254578150.mbj@tail-f.com> <63F8A418-6AF0-4205-ACC7-53A8C7BC6A73@osafoundation.org> <47512728.6040201@gmx.de> <517bf110712021242v43c462f0v86267f591e5cdfbd@mail.gmail.com> <1196690162.5874.13.camel@missotis> <20071203140846.GB17536@elstar.local> <47543B30.1060409@andybierman.com> <1196704923.5569.14.camel@missotis> In-Reply-To: <1196704923.5569.14.camel@missotis> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by omr4.networksolutionsemail.com id lB3IAwd5001930 X-Spam-Score: -1.0 (-) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: discuss@apps.ietf.org X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org Ladislav Lhotka wrote: > Andy Bierman p=C3=AD=C5=A1e v Po 03. 12. 2007 v 09:21 -0800: > > =20 >> I strongly agree with Juergen. >> YANG is based (in part) on 18+ years experience >> with SNMP and SMI. >> =20 > > And ignoring the additional flexibility XML can provide. > > =20 flexibility is the enemy of inter-operability. We are trying to create multi-vendor network management systems. It is well understood in the NM world that refining existing data definitions breaks existing manager code. >> It s absolutely forbidden in NM to redefine the syntax and semantics >> of a managed object in this way. >> =20 > > Why? Even if I explicitly specify I am using another data model? The > difference is that if the data model is easily extensible, I can just > write > > import parent-model; > > and then 5 lines or so describing the differences, so that it is > immediately clear what I am doing (and hopefully why). If the > extensibility is weak, I have to take the parent model, change few line= s > and declare it as a new data model - but the differences are not that > clear. > =20 This does not help the running code that expects the old definition of the data object. Deployment of NM code is part of our problem space. It may be irrelevant to APPs work, but not NM. > Lada > =20 > =20 Andy From discuss-bounces@apps.ietf.org Mon Dec 03 15:00:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzHSJ-0002tP-Ty; Mon, 03 Dec 2007 14:59:51 -0500 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1IzHSI-0002rK-Jh for discuss-confirm+ok@megatron.ietf.org; Mon, 03 Dec 2007 14:59:50 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzHSI-0002rB-9v for discuss@apps.ietf.org; Mon, 03 Dec 2007 14:59:50 -0500 Received: from elasmtp-dupuy.atl.sa.earthlink.net ([209.86.89.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IzHSG-0001gW-Rd for discuss@apps.ietf.org; Mon, 03 Dec 2007 14:59:50 -0500 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=StyAxVUCjjMpoDWk5JF/CEBfpDfKxen5fNE4KHK3zZQwGG20m85dg8tBdDmybFmC; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [66.167.78.97] (helo=oemcomputer) by elasmtp-dupuy.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1IzHSG-00058W-0F for discuss@apps.ietf.org; Mon, 03 Dec 2007 14:59:48 -0500 Message-ID: <003801c835e7$4fefeb20$6801a8c0@oemcomputer> From: "Randy Presuhn" To: References: <953beacc0711271504y7aea5f21jc301ccad886d3611@mail.gmail.com><474D9194.3060103@ericsson.com><953beacc0711281025w4d993dd7u77d729111074496c@mail.gmail.com><20071128.230244.254578150.mbj@tail-f.com><63F8A418-6AF0-4205-ACC7-53A8C7BC6A73@osafoundation.org><47512728.6040201@gmx.de><517bf110712021242v43c462f0v86267f591e5cdfbd@mail.gmail.com><1196690162.5874.13.camel@missotis><20071203140846.GB17536@elstar.local><47543B30.1060409@andybierman.com> <1196704923.5569.14.camel@missotis> Subject: Re: analysis of YANG vs. RELAX NG Date: Mon, 3 Dec 2007 12:01:34 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888a4beb055f130b31adbbf079c0b437f70dcb06358f4149882350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 66.167.78.97 X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org Hi - > From: "Ladislav Lhotka" > To: "Andy Bierman" > Cc: > Sent: Monday, December 03, 2007 10:02 AM > Subject: Re: analysis of YANG vs. RELAX NG > > > Andy Bierman píše v Po 03. 12. 2007 v 09:21 -0800: > > > I strongly agree with Juergen. > > YANG is based (in part) on 18+ years experience > > with SNMP and SMI. > > And ignoring the additional flexibility XML can provide. I strongly agree with Andy and Juergen. "Mushy" definitions are disastrous for interoperability. > > It s absolutely forbidden in NM to redefine the syntax and semantics > > of a managed object in this way. Agreed. > Why? Even if I explicitly specify I am using another data model? The > difference is that if the data model is easily extensible, I can just > write > > import parent-model; > > and then 5 lines or so describing the differences, so that it is > immediately clear what I am doing (and hopefully why). If the > extensibility is weak, I have to take the parent model, change few lines > and declare it as a new data model - but the differences are not that > clear. Re-use of definitions in the process of creating *new* definitions is another matter. The important point is that those new definitions in no way affect the models on which they were based, and therefore must not be understood as a redefinition of either the semantics or the syntax of a managed object. Randy From discuss-bounces@apps.ietf.org Mon Dec 03 16:55:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzJG7-0002UN-6e; Mon, 03 Dec 2007 16:55:23 -0500 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1IzJG6-0002TX-7w for discuss-confirm+ok@megatron.ietf.org; Mon, 03 Dec 2007 16:55:22 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzJG5-0002TK-UO for discuss@apps.ietf.org; Mon, 03 Dec 2007 16:55:21 -0500 Received: from qmta01.westchester.pa.mail.comcast.net ([76.96.62.16]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IzJG5-0006h3-Hf for discuss@apps.ietf.org; Mon, 03 Dec 2007 16:55:21 -0500 Received: from OMTA11.westchester.pa.mail.comcast.net ([76.96.62.36]) by QMTA01.westchester.pa.mail.comcast.net with comcast id LMTV1Y0050mv7h00506g00; Mon, 03 Dec 2007 21:55:21 +0000 Received: from Harrington73653 ([130.129.22.202]) by OMTA11.westchester.pa.mail.comcast.net with comcast id LMvG1Y0024McdwJ0300000; Mon, 03 Dec 2007 21:55:21 +0000 X-Authority-Analysis: v=1.0 c=1 a=21GWllOfCAAA:10 a=RUTEL2bYjdvxrp8r000A:9 a=LRp-JdXPf5q49S-GNIoA:7 a=TdZVwVmKYBrLs9sbAjvCr8ZuPfIA:4 a=si9q_4b84H0A:10 a=OS7PZEPQ3MUA:10 a=ucw2XimmUOMA:10 a=gi0PWCVxevcA:10 From: "David Harrington" To: "'Randy Presuhn'" , References: <953beacc0711271504y7aea5f21jc301ccad886d3611@mail.gmail.com><474D9194.3060103@ericsson.com><953beacc0711281025w4d993dd7u77d729111074496c@mail.gmail.com><20071128.230244.254578150.mbj@tail-f.com><63F8A418-6AF0-4205-ACC7-53A8C7BC6A73@osafoundation.org><47512728.6040201@gmx.de><517bf110712021242v43c462f0v86267f591e5cdfbd@mail.gmail.com><1196690162.5874.13.camel@missotis><20071203140846.GB17536@elstar.local><47543B30.1060409@andybierman.com><1196704923.5569.14.camel@missotis> <003801c835e7$4fefeb20$6801a8c0@oemcomputer> Subject: RE: analysis of YANG vs. RELAX NG Date: Mon, 3 Dec 2007 13:55:10 -0800 Message-ID: <013101c835f7$2dbd15e0$ca168182@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <003801c835e7$4fefeb20$6801a8c0@oemcomputer> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 Thread-Index: Acg15zJwfCjby+c6T8iKYm0sJYyN4QADUG0w X-Spam-Score: 0.0 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Cc: X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org I agree with Juergen, Andy, and Randy. Our goal is interoperability between multiple managed devices and multiple management applications - we need system-wide interoperability for M:N relationships.=20 Netconf has different requirements than SNMP, and a Netconf DML will have different requirements than SMI, but NM requirements seem relatively stable on this point. A MIB module is a type of contract between the involved parties, and it is unacceptable to modify the syntax or semantics in ways that would break contract-compliance/interoperability between the parties. The SMI does not allow changes to existing datatypes, with very few exceptions. SMI does permit some extensibility, such as extending enumerations or BITs, but the change controls for the exceptions are clearly defined in the SMI. Those restrictions exist to ensure interoperability among NM entities within the system.=20 David Harrington dbharrington@comcast.net ietfdbh@comcast.net > -----Original Message----- > From: Randy Presuhn [mailto:randy_presuhn@mindspring.com]=20 > Sent: Monday, December 03, 2007 12:02 PM > To: discuss@apps.ietf.org > Subject: Re: analysis of YANG vs. RELAX NG >=20 > Hi - >=20 > > From: "Ladislav Lhotka" > > To: "Andy Bierman" > > Cc: > > Sent: Monday, December 03, 2007 10:02 AM > > Subject: Re: analysis of YANG vs. RELAX NG > > >=20 > > > > Andy Bierman p=ED=B9e v Po 03. 12. 2007 v 09:21 -0800: > > > > > I strongly agree with Juergen. > > > YANG is based (in part) on 18+ years experience > > > with SNMP and SMI. > > > > And ignoring the additional flexibility XML can provide. >=20 > I strongly agree with Andy and Juergen. "Mushy" definitions > are disastrous for interoperability. >=20 > > > It s absolutely forbidden in NM to redefine the syntax=20 > and semantics > > > of a managed object in this way. >=20 > Agreed. >=20 > > Why? Even if I explicitly specify I am using another data model? The > > difference is that if the data model is easily extensible,=20 > I can just > > write > > > > import parent-model; > > > > and then 5 lines or so describing the differences, so that it is > > immediately clear what I am doing (and hopefully why). If the > > extensibility is weak, I have to take the parent model,=20 > change few lines > > and declare it as a new data model - but the differences=20 > are not that > > clear. >=20 > Re-use of definitions in the process of creating *new* definitions is > another matter. The important point is that those new definitions in > no way affect the models on which they were based, and therefore must > not be understood as a redefinition of either the semantics or the > syntax of a managed object. >=20 > Randy >=20 >=20 >=20 >=20 >=20 From discuss-bounces@apps.ietf.org Mon Dec 03 17:14:00 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzJY8-0004Hi-B4; Mon, 03 Dec 2007 17:14:00 -0500 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1IzJY7-0004Gc-SE for discuss-confirm+ok@megatron.ietf.org; Mon, 03 Dec 2007 17:13:59 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzJY7-0004Fg-HD for discuss@apps.ietf.org; Mon, 03 Dec 2007 17:13:59 -0500 Received: from co300216-co-outbound.net.avaya.com ([198.152.13.100] helo=co300216-co-outbound.avaya.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IzJY5-0007QZ-Iw for discuss@apps.ietf.org; Mon, 03 Dec 2007 17:13:59 -0500 X-IronPort-AV: E=Sophos;i="4.23,245,1194238800"; d="scan'208";a="88542500" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by co300216-co-outbound.avaya.com with ESMTP; 03 Dec 2007 17:13:53 -0500 X-IronPort-AV: E=Sophos;i="4.23,245,1194238800"; d="scan'208";a="136487636" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.16]) by co300216-co-erhwest-out.avaya.com with ESMTP; 03 Dec 2007 17:13:08 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable Subject: RE: analysis of YANG vs. RELAX NG Date: Mon, 3 Dec 2007 23:12:50 +0100 Message-ID: In-Reply-To: <1196704923.5569.14.camel@missotis> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: analysis of YANG vs. RELAX NG Thread-Index: Acg11rnLaKEInH81QayS31D83Y0BwQAIiiQg References: <953beacc0711271504y7aea5f21jc301ccad886d3611@mail.gmail.com><474D9194.3060103@ericsson.com><953beacc0711281025w4d993dd7u77d729111074496c@mail.gmail.com><20071128.230244.254578150.mbj@tail-f.com><63F8A418-6AF0-4205-ACC7-53A8C7BC6A73@osafoundation.org><47512728.6040201@gmx.de><517bf110712021242v43c462f0v86267f591e5cdfbd@mail.gmail.com><1196690162.5874.13.camel@missotis><20071203140846.GB17536@elstar.local><47543B30.1060409@andybierman.com> <1196704923.5569.14.camel@missotis> From: "Romascanu, Dan (Dan)" To: "Ladislav Lhotka" , "Andy Bierman" X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Cc: discuss@apps.ietf.org X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org =20 =20 > -----Original Message----- > From: Ladislav Lhotka [mailto:lhotka@cesnet.cz]=20 > Sent: Monday, December 03, 2007 8:02 PM > To: Andy Bierman > Cc: discuss@apps.ietf.org > Subject: Re: analysis of YANG vs. RELAX NG >=20 >=20 > Andy Bierman p=ED=B9e v Po 03. 12. 2007 v 09:21 -0800: >=20 > > I strongly agree with Juergen. > > YANG is based (in part) on 18+ years experience with SNMP and SMI. >=20 > And ignoring the additional flexibility XML can provide. >=20 > >=20 > > It s absolutely forbidden in NM to redefine the syntax and=20 > semantics=20 > > of a managed object in this way. >=20 > Why? Even if I explicitly specify I am using another data=20 > model? The difference is that if the data model is easily=20 > extensible, I can just write >=20 > import parent-model; >=20 > and then 5 lines or so describing the differences, so that it=20 > is immediately clear what I am doing (and hopefully why). If=20 > the extensibility is weak, I have to take the parent model,=20 > change few lines and declare it as a new data model - but the=20 > differences are not that clear. >=20 > Lada > =20 > -- > Ladislav Lhotka, CESNET > PGP Key ID: E74E8C0C >=20 > Lada, How can two different management entities interoperate if the same = object has two different semantics because they have loaded two = different versions of the data model? Only the entity that has loaded = the newer version will be aware about the ' 5 lines or so describing the = differences', what about the older one?=20 Dan (asking as contributor) =20 From discuss-bounces@apps.ietf.org Mon Dec 03 18:00:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzKGl-0003s7-3L; Mon, 03 Dec 2007 18:00:07 -0500 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1IzKGk-0003qQ-0m for discuss-confirm+ok@megatron.ietf.org; Mon, 03 Dec 2007 18:00:06 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzKGj-0003qG-Js for discuss@apps.ietf.org; Mon, 03 Dec 2007 18:00:05 -0500 Received: from office2.cesnet.cz ([195.113.144.244]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IzKGi-0003cc-2a for discuss@apps.ietf.org; Mon, 03 Dec 2007 18:00:05 -0500 Received: from [130.129.53.102] (dhcp-3566.ietf70.org [130.129.53.102]) by office2.cesnet.cz (Postfix) with ESMTP id DD05FD800BD for ; Mon, 3 Dec 2007 23:59:48 +0100 (CET) Subject: Re: analysis of YANG vs. RELAX NG From: Ladislav Lhotka To: discuss@apps.ietf.org In-Reply-To: <003801c835e7$4fefeb20$6801a8c0@oemcomputer> References: <953beacc0711271504y7aea5f21jc301ccad886d3611@mail.gmail.com> <474D9194.3060103@ericsson.com> <953beacc0711281025w4d993dd7u77d729111074496c@mail.gmail.com> <20071128.230244.254578150.mbj@tail-f.com> <63F8A418-6AF0-4205-ACC7-53A8C7BC6A73@osafoundation.org> <47512728.6040201@gmx.de> <517bf110712021242v43c462f0v86267f591e5cdfbd@mail.gmail.com> <1196690162.5874.13.camel@missotis><20071203140846.GB17536@elstar.local> <47543B30.1060409@andybierman.com> <1196704923.5569.14.camel@missotis> <003801c835e7$4fefeb20$6801a8c0@oemcomputer> Content-Type: text/plain; charset=utf-8 Organization: CESNET Date: Mon, 03 Dec 2007 23:59:46 +0100 Message-Id: <1196722786.5835.57.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.12.1 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org Hi, Randy Presuhn p=C3=AD=C5=A1e v Po 03. 12. 2007 v 12:01 -0800: > I strongly agree with Andy and Juergen. "Mushy" definitions > are disastrous for interoperability. I think it's a misunderstanding. I am not pleading for fuzzy (is it approximately what "mushy" means?;-) data models, the models can and should be simple and unambiguous, I am talking about additional flexibility for model *designers*, i.e., straightforward means for reusing and extending existing models into new models (also by adding structure to former leaves, why not?), and here I think YANG is rather rigid when compared to RELAX NG. Lada --=20 Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From discuss-bounces@apps.ietf.org Tue Dec 04 01:19:43 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzR76-0000OR-BK; Tue, 04 Dec 2007 01:18:36 -0500 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1IzR74-0000Me-5b for discuss-confirm+ok@megatron.ietf.org; Tue, 04 Dec 2007 01:18:34 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzR73-0000M9-Mx for discuss@apps.ietf.org; Tue, 04 Dec 2007 01:18:33 -0500 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IzR72-0007j5-Qe for discuss@apps.ietf.org; Tue, 04 Dec 2007 01:18:33 -0500 Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150]) by ithilien.qualcomm.com (8.14.2/8.12.5/1.0) with ESMTP id lB46IVLY008356 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 3 Dec 2007 22:18:31 -0800 Received: from dhcp-407d.ietf70.org (vpn-10-50-16-235.qualcomm.com [10.50.16.235]) by sabrina.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id lB46IT4n002131; Mon, 3 Dec 2007 22:18:30 -0800 Mime-Version: 1.0 Message-Id: In-Reply-To: <20071203094351.GA19449@nic.fr> References: <20071203094351.GA19449@nic.fr> X-Mailer: Eudora for Mac OS X X-message-flag: Warning: Outlook in use. Upgrade to Eudora: Date: Mon, 3 Dec 2007 19:45:47 -0800 To: Stephane Bortzmeyer , Dave Cridland From: Randall Gellens Subject: Re: I-D Action:draft-newman-email-subaddr-01.txt Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Random-Sig-Tag: 1.0b28 X-PerlMx: Message inspected by PerlMx X-PerlMx: Message inspected by PerlMx X-Spam-Score: -4.0 (----) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a Cc: Apps Discuss X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org At 10:43 AM +0100 12/3/07, Stephane Bortzmeyer wrote: > I'm quite puzzled by this draft and I do not really understand what it > normalizes or what its purpose is. > > The entire idea of subaddressing is to be a local decision, only the > final MTA and/or its MDA will have to know it. Besides stuff like RFC > 3598, there is little room for IETF work. Currently, subaddressing is mostly part of the mostly undocumented email lore that some implementers are aware of while others are not. Formalizing the concept is a good thing. It would still be a purely local decision to use it or not, and indeed to define what it means. But having a common basis for information seems helpful to me. Also, the advice for mailing lists to ignore the detail, and the Security Considerations text on command-line handling, seem useful. The mailing list issue argues for a standardized character, but the prevalence of broken web forms argues against it. > Some sentences in the draft are strange, in that respect. For > instance, section 4.2 says "A subaddress-aware gateway or firewall > SHOULD preserve the detail part when rewriting an address." while I > thought that the SMTP rule was much stronger: "DO NOT MESS with > addresses", and that is a general rule, it is not only for > subaddressing. I think a gateway or firewall that rewrites addresses (or in any way alters the mail) is, by definition, within the local delivery domain, and hence the 2821 rule doesn't apply. It is permitted to do as it pleases. Given the widespread ignorance of user-detail addresses, it seems helpful to have something to point to that tells these boxes to preserve this. > Apart from that, the draft puts too much emphasis on the most common > "+" (with a MTA like Postfix, it is trivial to change it - the > recipient_delimiter option, and many people do so to avoid the problem > of broken software mentioned later). Again, the IETF should not > mention this separator, since it is a local decision. Mentioning it, with examples, is probably a good thing, since it can help gain understanding. The text shouldn't dictate the specific character, though. Perhaps the text in Section 1, for example, that currently says In general, deployed forms of subaddressing divide the local-part of an email address into two strings, seperated by a delimiter character. This is most commonly a plus sign, "+". This document does not document all forms of subaddressing, merely the most common form, also known as "plus-addressing". Other forms are also deployed, sometimes using a minus sign, and in some rare cases using encoding rules rather than simple catenation. Could be changed to In general, deployed forms of subaddressing divide the local-part of an email address into two strings, seperated by a delimiter character. This is most commonly a plus sign, "+". For clarity, the examples in this document all use the "+" (which is also known as "plus-addressing". Other forms are also deployed, sometimes using a minus sign, and in some rare cases using encoding rules rather than simple catenation. And then change non-example uses of "+" to "the delimiter". Also add "the delimiter" to the Definitions, and fix the ABNF to allow other safe characters that aren't "%" as the delimiter. Maybe it should also suggest NOT using "%", since many systems treat the presence of this character in the local-part as an attempt to relay and hence an attack. > Strangely enough, the draft does not talk about *the* big problem with > subaddressing: the fact that many stupid and broken Web forms and/or > mail software do not accept them or do not handle them > properly. Yes, this is a major problem. > Certainly, an informational RFC asking to accept valid email > addresses would be an useful document. See a good start in > http://www.linuxjournal.com/article/9585, specially the conclusion > ("There is some danger that common usage and widespread sloppy coding > will establish a de facto standard for e-mail addresses that is more > restrictive than the recorded formal standard.") or in > http://worsethanfailure.com/Articles/Validating_Email_Addresses.aspx > (the comments are interesting, too). This is useful, but separate. (Also, wasn't this done a few years ago?) -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly-selected tag: --------------- If A = B and B = C, then A = C, except where void or prohibited by law. From discuss-bounces@apps.ietf.org Tue Dec 04 02:26:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzS9z-0003BU-SU; Tue, 04 Dec 2007 02:25:39 -0500 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1IzS9z-0003BL-Br for discuss-confirm+ok@megatron.ietf.org; Tue, 04 Dec 2007 02:25:39 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzS9y-0003BA-QG for discuss@apps.ietf.org; Tue, 04 Dec 2007 02:25:38 -0500 Received: from hermes.jacobs-university.de ([212.201.44.23]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IzS9x-0002xA-2X for discuss@apps.ietf.org; Tue, 04 Dec 2007 02:25:38 -0500 Received: from localhost (demetrius.jacobs-university.de [212.201.44.32]) by hermes.jacobs-university.de (Postfix) with ESMTP id 0444386632; Tue, 4 Dec 2007 08:25:36 +0100 (CET) Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 26091-09; Tue, 4 Dec 2007 08:25:31 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 89DF48A147; Tue, 4 Dec 2007 08:25:31 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 9537D4086F9; Tue, 4 Dec 2007 08:25:31 +0100 (CET) Date: Tue, 4 Dec 2007 08:25:31 +0100 From: Juergen Schoenwaelder To: Ladislav Lhotka Subject: Re: analysis of YANG vs. RELAX NG Message-ID: <20071204072531.GA19235@elstar.local> References: <474D9194.3060103@ericsson.com> <953beacc0711281025w4d993dd7u77d729111074496c@mail.gmail.com> <20071128.230244.254578150.mbj@tail-f.com> <63F8A418-6AF0-4205-ACC7-53A8C7BC6A73@osafoundation.org> <47512728.6040201@gmx.de> <517bf110712021242v43c462f0v86267f591e5cdfbd@mail.gmail.com> <47543B30.1060409@andybierman.com> <1196704923.5569.14.camel@missotis> <003801c835e7$4fefeb20$6801a8c0@oemcomputer> <1196722786.5835.57.camel@missotis> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1196722786.5835.57.camel@missotis> User-Agent: Mutt/1.5.17 (2007-11-01) X-Virus-Scanned: amavisd-new 2.3.3 (20050822) at jacobs-university.de X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: discuss@apps.ietf.org X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org On Mon, Dec 03, 2007 at 11:59:46PM +0100, Ladislav Lhotka wrote: > I think it's a misunderstanding. I am not pleading for fuzzy (is it > approximately what "mushy" means?;-) data models, the models can and > should be simple and unambiguous, I am talking about additional > flexibility for model *designers*, i.e., straightforward means for > reusing and extending existing models into new models (also by adding > structure to former leaves, why not?), and here I think YANG is rather > rigid when compared to RELAX NG. The question whether it is a good idea to be able to turn a data containing XML element into a container element in a future revision of a data model is pretty much independent of the schema language. Several network management people believe that having XML elements that sometimes are containers and sometimes leafs does not help interoperability. In fact, we would likely require that any solution (e.g. XSD-+ or RELAX NG-+ extended subset languages) does have versioning rules attached that guarantee the same behaviour. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From discuss-bounces@apps.ietf.org Tue Dec 04 11:18:05 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzaSG-00023H-38; Tue, 04 Dec 2007 11:17:04 -0500 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1IzaSE-0001nr-5M for discuss-confirm+ok@megatron.ietf.org; Tue, 04 Dec 2007 11:17:02 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzaSD-0001lA-P0 for discuss@apps.ietf.org; Tue, 04 Dec 2007 11:17:01 -0500 Received: from mx2.nic.fr ([192.134.4.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IzaSC-0002EQ-92 for discuss@apps.ietf.org; Tue, 04 Dec 2007 11:17:01 -0500 Received: from mx2.nic.fr (localhost [127.0.0.1]) by mx2.nic.fr (Postfix) with SMTP id 516061C0172; Tue, 4 Dec 2007 17:16:59 +0100 (CET) Received: from relay2.nic.fr (relay2.nic.fr [192.134.4.163]) by mx2.nic.fr (Postfix) with ESMTP id 4C0551C016E; Tue, 4 Dec 2007 17:16:59 +0100 (CET) Received: from bortzmeyer.nic.fr (batilda.nic.fr [192.134.4.69]) by relay2.nic.fr (Postfix) with ESMTP id 4930158ECBE; Tue, 4 Dec 2007 17:16:59 +0100 (CET) Date: Tue, 4 Dec 2007 17:16:59 +0100 From: Stephane Bortzmeyer To: Dave Cridland Subject: Re: I-D Action:draft-newman-email-subaddr-01.txt Message-ID: <20071204161659.GA19161@nic.fr> References: <20071203094351.GA19449@nic.fr> <2639.1196720643.545129@peirce.dave.cridland.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2639.1196720643.545129@peirce.dave.cridland.net> X-Operating-System: Debian GNU/Linux 4.0 X-Kernel: Linux 2.6.18-5-686 i686 Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: Mutt/1.5.13 (2006-08-11) X-Spam-Score: -4.0 (----) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: Apps Discuss X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org On Mon, Dec 03, 2007 at 10:24:03PM +0000, Dave Cridland wrote a message of 89 lines which said: > As good as any. May be ietf-smtp@imc.org would have been a better place? > Subaddressing isn't described anywhere, That's the whole point, I believe. Subaddressing has always been a matter of local conventions (like the Firstname.Name@example.org convention in many environments), not needing to be "described". If I understand you well, you suggest to create (not describe) a new concept, "global subaddressing", with a standard delimiter and subaddressing-aware software, allowing new tricks (like the MLM you mention, which accepts mail only from subscribers and who can recognize them even when they use subaddressing). That's may be a good idea but it is something new, not a description of a current practice. > No, every component needs to know about it. > > 1) The final MTA. > 2) The MDA. > 3) The MUA. > 4) The Submission server. Can you explain why the MUA and the MSA need to know it? From discuss-bounces@apps.ietf.org Tue Dec 04 11:21:36 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzaVn-0003PJ-Gk; Tue, 04 Dec 2007 11:20:43 -0500 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1IzaVl-0003P5-Ax for discuss-confirm+ok@megatron.ietf.org; Tue, 04 Dec 2007 11:20:41 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzaVl-0003Ov-0V for discuss@apps.ietf.org; Tue, 04 Dec 2007 11:20:41 -0500 Received: from mx2.nic.fr ([192.134.4.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IzaVk-0002bV-Mq for discuss@apps.ietf.org; Tue, 04 Dec 2007 11:20:40 -0500 Received: from mx2.nic.fr (localhost [127.0.0.1]) by mx2.nic.fr (Postfix) with SMTP id 4C6351C0174; Tue, 4 Dec 2007 17:20:40 +0100 (CET) Received: from relay2.nic.fr (relay2.nic.fr [192.134.4.163]) by mx2.nic.fr (Postfix) with ESMTP id 471F71C0168; Tue, 4 Dec 2007 17:20:40 +0100 (CET) Received: from bortzmeyer.nic.fr (batilda.nic.fr [192.134.4.69]) by relay2.nic.fr (Postfix) with ESMTP id 4392D58ECBE; Tue, 4 Dec 2007 17:20:40 +0100 (CET) Date: Tue, 4 Dec 2007 17:20:40 +0100 From: Stephane Bortzmeyer To: Randall Gellens Subject: Re: I-D Action:draft-newman-email-subaddr-01.txt Message-ID: <20071204162040.GB19161@nic.fr> References: <20071203094351.GA19449@nic.fr> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Operating-System: Debian GNU/Linux 4.0 X-Kernel: Linux 2.6.18-5-686 i686 Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: Mutt/1.5.13 (2006-08-11) X-Spam-Score: -4.0 (----) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: Apps Discuss , Dave Cridland X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org On Mon, Dec 03, 2007 at 07:45:47PM -0800, Randall Gellens wrote a message of 95 lines which said: > Currently, subaddressing is mostly part of the mostly undocumented > email lore that some implementers are aware of while others are not. And that's the right way: subaddressing does not have to be documented, it is a local convention. (How can you tell if bortzmeyer@nic.fr is not an address with subaddressing and "m" as the delimiter?) > Formalizing the concept is a good thing. I'm not convinced. > This is useful, but separate. (Also, wasn't this done a few years ago?) I do not think so, alas. I'm engaged in a personal crusade against such Web forms and the 1 or 2 % of the webmasters who do reply to my complaints always said that bortzmeyer+something@nic.fr is not a legal email address... Pointing them to RFC 2822 does not help, the grammar is too... funny. From discuss-bounces@apps.ietf.org Tue Dec 04 11:43:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Izar8-00075p-9G; Tue, 04 Dec 2007 11:42:46 -0500 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1Izar6-00075g-V7 for discuss-confirm+ok@megatron.ietf.org; Tue, 04 Dec 2007 11:42:44 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Izar6-00075W-LY for discuss@apps.ietf.org; Tue, 04 Dec 2007 11:42:44 -0500 Received: from mx2.nic.fr ([192.134.4.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Izar6-0004kH-Be for discuss@apps.ietf.org; Tue, 04 Dec 2007 11:42:44 -0500 Received: from mx2.nic.fr (localhost [127.0.0.1]) by mx2.nic.fr (Postfix) with SMTP id EE5BF1C0176 for ; Tue, 4 Dec 2007 17:42:43 +0100 (CET) Received: from relay2.nic.fr (relay2.nic.fr [192.134.4.163]) by mx2.nic.fr (Postfix) with ESMTP id EA7311C0135 for ; Tue, 4 Dec 2007 17:42:43 +0100 (CET) Received: from bortzmeyer.nic.fr (batilda.nic.fr [192.134.4.69]) by relay2.nic.fr (Postfix) with ESMTP id DE10458ECBE for ; Tue, 4 Dec 2007 17:42:43 +0100 (CET) Date: Tue, 4 Dec 2007 17:42:43 +0100 From: Stephane Bortzmeyer To: discuss@apps.ietf.org Subject: Do we now require change control on specifications we use? Message-ID: <20071204164243.GA23212@nic.fr> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Operating-System: Debian GNU/Linux 4.0 X-Kernel: Linux 2.6.18-5-686 i686 Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: Mutt/1.5.13 (2006-08-11) X-Spam-Score: -4.0 (----) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org draft-bjorklund-netconf-yang-00.txt says: > o From a process perspective, the IETF lacks any IETF change control > and real input into the update process for XSD. And draft-lengyel-why-yang-00 says: > and we can enjoy long term stability and full chance control in the > IETF, which also exercises change control over NETCONF. That's a completely new argument for me, and a strange one. AFAIK, there is no general rule in the IETF that the IETF must have "change control" over the specifications it uses. Otherwise, we would never used standards from very closed SDOs like ISO or IEEE. And Netconf does not follow this practice, anyway, since it uses XML, hardly a standard that the IETF controls. Asking for "change control" here really looks like a modern form of "NIH". From discuss-bounces@apps.ietf.org Tue Dec 04 12:30:32 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzbaV-0007PL-Hx; Tue, 04 Dec 2007 12:29:39 -0500 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1IzbaU-0007O6-Nd for discuss-confirm+ok@megatron.ietf.org; Tue, 04 Dec 2007 12:29:38 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzbaU-0007MY-CW for discuss@apps.ietf.org; Tue, 04 Dec 2007 12:29:38 -0500 Received: from mailhost.informatik.uni-bremen.de ([2001:638:708:30c9:209:3dff:fe00:7136] helo=informatik.uni-bremen.de) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IzbaT-00019l-Tp for discuss@apps.ietf.org; Tue, 04 Dec 2007 12:29:38 -0500 X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from localhost (maildrop [134.102.201.19]) by informatik.uni-bremen.de (8.14.0/8.14.0) with ESMTP id lB4HTTj3011908; Tue, 4 Dec 2007 18:29:29 +0100 (CET) Message-Id: <3F673E84-8B16-4E1C-AB68-27A7EB3DEB35@tzi.org> From: Carsten Bormann To: Stephane Bortzmeyer In-Reply-To: <20071204164243.GA23212@nic.fr> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v915) Subject: Re: Do we now require change control on specifications we use? Date: Tue, 4 Dec 2007 09:29:28 -0800 References: <20071204164243.GA23212@nic.fr> X-Mailer: Apple Mail (2.915) X-Spam-Score: 4.5 (++++) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: discuss@apps.ietf.org, Carsten Bormann X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org On Dec 04 2007, at 08:42, Stephane Bortzmeyer wrote: > That's a completely new argument for me, and a strange one. AFAIK, > there is no general rule in the IETF that the IETF must have "change > control" over the specifications it uses. Otherwise, we would never > used standards from very closed SDOs like ISO or IEEE. There is no rule. However, past experience with ASN.1 has created enough scars in this community. Using a base standard that is a moving target, in control by people who don't care about our needs, is a problem. XML is *not* a moving target. ASN.1 was. Worse, it was in the control of tool vendors who were living off changes to the "standard" and increasing complexity in order to sell upgrades and keep a high barrier to market entry. Exercise to the reader: Where in this picture is XSD? (Hint: Whose interests/which forces shape this specification and its evolution? Hint2: The existence of an insurgent direct competitor with strong support by large parts of the community is an indicator that there might be something interesting to find in this space.) All that said, I'm not sure that XSD actually is that much of a moving target (1.1 notwithstanding). Gruesse, Carsten From discuss-bounces@apps.ietf.org Tue Dec 04 12:35:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Izbfm-0005nv-R9; Tue, 04 Dec 2007 12:35:06 -0500 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1Izbfl-0005my-SP for discuss-confirm+ok@megatron.ietf.org; Tue, 04 Dec 2007 12:35:05 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Izbfl-0005mb-Im for discuss@apps.ietf.org; Tue, 04 Dec 2007 12:35:05 -0500 Received: from sceptre.pobox.com ([207.106.133.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Izbfl-0001nf-0O for discuss@apps.ietf.org; Tue, 04 Dec 2007 12:35:05 -0500 Received: from sceptre (localhost.localdomain [127.0.0.1]) by sceptre.pobox.com (Postfix) with ESMTP id 6727E2FB; Tue, 4 Dec 2007 12:35:25 -0500 (EST) Received: from MCQWP2 (ip72-197-112-82.sd.sd.cox.net [72.197.112.82]) by sceptre.sasl.smtp.pobox.com (Postfix) with ESMTP id C64B19CD54; Tue, 4 Dec 2007 12:35:23 -0500 (EST) Date: Tue, 4 Dec 2007 09:35:00 -0800 From: Bill McQuillan X-Priority: 3 (Normal) Message-ID: <1623535398.20071204093500@pobox.com> To: Apps-Discusssion Subject: Re: I-D Action:draft-newman-email-subaddr-01.txt In-Reply-To: <20071204161659.GA19161@nic.fr> References: <20071203094351.GA19449@nic.fr> <2639.1196720643.545129@peirce.dave.cridland.net> <20071204161659.GA19161@nic.fr> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org On Tue, 2007-12-04, Stephane Bortzmeyer wrote: > On Mon, Dec 03, 2007 at 10:24:03PM +0000, > Dave Cridland wrote > If I understand you well, you suggest to create (not describe) a new > concept, "global subaddressing", with a standard delimiter and > subaddressing-aware software, allowing new tricks (like the MLM you > mention, which accepts mail only from subscribers and who can > recognize them even when they use subaddressing). > That's may be a good idea but it is something new, not a description > of a current practice. Well, it seems to be "partial" current practice. My public email address goes to a forwarder (pobox.com) that, being fairly knowledgable in the email area, will rewrite my address while preserving the detail portion when forwarding it to my actual ISP. I know they understand the "+" delimiter, but I haven't tested other delimiters. Unfortunately, my current ISP rejects such addresses as Recipient Unknown! This means that MY "local convention" is thwarted by my ISPs "border servers". I would love to point the ISP to an RFC that shows them what ought to be allowed. -- Bill McQuillan From discuss-bounces@apps.ietf.org Tue Dec 04 13:06:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Izc9g-0003kC-BR; Tue, 04 Dec 2007 13:06:00 -0500 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1Izc9f-0003k3-QW for discuss-confirm+ok@megatron.ietf.org; Tue, 04 Dec 2007 13:05:59 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Izc9e-0003jq-TY for discuss@apps.ietf.org; Tue, 04 Dec 2007 13:05:59 -0500 Received: from ka.cs.utk.edu ([160.36.56.221]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Izc9c-0004p9-Po for discuss@apps.ietf.org; Tue, 04 Dec 2007 13:05:58 -0500 Received: from localhost (localhost [127.0.0.1]) by ka.cs.utk.edu (Postfix) with ESMTP id D9A9ACB45C; Tue, 4 Dec 2007 13:05:55 -0500 (EST) X-Virus-Scanned: by amavisd-new with ClamAV and SpamAssasin at cs.utk.edu Received: from ka.cs.utk.edu ([127.0.0.1]) by localhost (ka.cs.utk.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rIWJsgkI2+Cf; Tue, 4 Dec 2007 13:05:53 -0500 (EST) Received: from lust.indecency.org (dhcp-17a4.ietf70.org [130.129.23.164]) by ka.cs.utk.edu (Postfix) with ESMTP id A8188CB440; Tue, 4 Dec 2007 13:05:43 -0500 (EST) Message-ID: <475596E6.502@cs.utk.edu> Date: Tue, 04 Dec 2007 10:05:26 -0800 From: Keith Moore User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: Stephane Bortzmeyer Subject: Re: I-D Action:draft-newman-email-subaddr-01.txt References: <20071203094351.GA19449@nic.fr> <2639.1196720643.545129@peirce.dave.cridland.net> <20071204161659.GA19161@nic.fr> In-Reply-To: <20071204161659.GA19161@nic.fr> X-Enigmail-Version: 0.95.5 OpenPGP: id=E1473978 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: Apps Discuss , Dave Cridland X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org Stephane Bortzmeyer wrote: > If I understand you well, you suggest to create (not describe) a new > concept, "global subaddressing", with a standard delimiter and > subaddressing-aware software, allowing new tricks (like the MLM you > mention, which accepts mail only from subscribers and who can > recognize them even when they use subaddressing). > > That's may be a good idea but it is something new, not a description > of a current practice. > I don't know how widespread the practice is, but my "bulk_mailer" software (which used to get a lot of use, anyway) has supported this kind of fuzzy matching since 2002. (it also does fuzzy matching on the domain part, so that a.example.com is treated as equivalent to b.example.com and example.com) From discuss-bounces@apps.ietf.org Tue Dec 04 13:26:00 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzcSz-0001cm-SN; Tue, 04 Dec 2007 13:25:57 -0500 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1IzcSy-0001aa-Ao for discuss-confirm+ok@megatron.ietf.org; Tue, 04 Dec 2007 13:25:56 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzcSy-0001Zu-17 for discuss@apps.ietf.org; Tue, 04 Dec 2007 13:25:56 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IzcSx-0006l6-KB for discuss@apps.ietf.org; Tue, 04 Dec 2007 13:25:56 -0500 Received: from [130.129.20.216] (dhcp-2476.ietf70.org [130.129.36.118]) (authenticated bits=0) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lB4IPrHr022583 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 4 Dec 2007 11:25:54 -0700 (MST) (envelope-from phoffman@imc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <3F673E84-8B16-4E1C-AB68-27A7EB3DEB35@tzi.org> References: <20071204164243.GA23212@nic.fr> <3F673E84-8B16-4E1C-AB68-27A7EB3DEB35@tzi.org> Date: Tue, 4 Dec 2007 10:25:12 -0800 To: Carsten Bormann From: Paul Hoffman Subject: Re: Do we now require change control on specifications we use? Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: discuss@apps.ietf.org X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org At 9:29 AM -0800 12/4/07, Carsten Bormann wrote: >XML is *not* a moving target. >ASN.1 was. Worse, it was in the control of tool vendors who were >living off changes to the "standard" and increasing complexity in >order to sell upgrades and keep a high barrier to market entry. Oh, please. The "added complexity" that was *needed* to be changed in all the PKIX and S/MIME specs to meet the changes over 20 years of ASN.1 changes are minor and cause no bits-on-the-wire changes. See draft-hoffman-cms-new-asn1-00.txt and draft-hoffman-pkix-new-asn1-00.txt. Those drafts also add a bunch of very simple things that give compilers and validators more tools to find errors in data. Again, no bits-on-the-wire changes. Blaming this on ASN.1 "tool vendors" is silly. First, there is basically only one significant tool vendor. More important, however, is that most of the changes have been to add new data formats that the IETF has completely ignored. Those formats (PER, CER, XER, YAER...) were wanted by other SDOs; that's no skin off our noses. The changes in ASN.1 have had little or no effect on the IETF. We are considering bringing our specs up to date now, and it is quite easy and completely voluntary. From discuss-bounces@apps.ietf.org Tue Dec 04 13:29:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzcWP-0001le-6Q; Tue, 04 Dec 2007 13:29:29 -0500 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1IzcWO-0001jc-8C for discuss-confirm+ok@megatron.ietf.org; Tue, 04 Dec 2007 13:29:28 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzcWN-0001iN-UC for discuss@apps.ietf.org; Tue, 04 Dec 2007 13:29:27 -0500 Received: from elasmtp-junco.atl.sa.earthlink.net ([209.86.89.63]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IzcWM-000754-GV for discuss@apps.ietf.org; Tue, 04 Dec 2007 13:29:27 -0500 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=IcJqH8zEoYREdpDSZgnB9yAffFKZ5aJH2Ja5f09IQwxvzTgELaixSXEYWn4E7Pcz; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [64.105.35.77] (helo=oemcomputer) by elasmtp-junco.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1IzcWL-00073O-A5 for discuss@apps.ietf.org; Tue, 04 Dec 2007 13:29:25 -0500 Message-ID: <001a01c836a3$dc99df60$6801a8c0@oemcomputer> From: "Randy Presuhn" To: References: <20071204164243.GA23212@nic.fr> Subject: Re: Do we now require change control on specifications we use? Date: Tue, 4 Dec 2007 10:31:17 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888a4beb055f130b31a8b7d45ec643c87d529774bbd4caa7d44350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 64.105.35.77 X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org Hi - > From: "Stephane Bortzmeyer" > To: > Sent: Tuesday, December 04, 2007 8:42 AM > Subject: Do we now require change control on specifications we use? ... > That's a completely new argument for me, and a strange one. AFAIK, > there is no general rule in the IETF that the IETF must have "change > control" over the specifications it uses. Otherwise, we would never > used standards from very closed SDOs like ISO or IEEE. > > And Netconf does not follow this practice, anyway, since it uses XML, > hardly a standard that the IETF controls. > > Asking for "change control" here really looks like a modern form of > "NIH". Agreed, but... I understand how the bad experience with ASN.1's mutations over the years could lead to this perspective. The ASN.1 used for SNMP in the 1980s little resembles what is called ASN.1 today. (Those same changes also caused great heartburn in ISO/ITU-land as well. The ripple effects from the dropping of the MACRO notation, bad as it was, turned into a tidal wave of changes to other standards that, for example, relied on ROSE or ANY.) Randy From discuss-bounces@apps.ietf.org Tue Dec 04 13:45:16 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Izclg-0005dS-7I; Tue, 04 Dec 2007 13:45:16 -0500 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1Izclf-0005dJ-Kw for discuss-confirm+ok@megatron.ietf.org; Tue, 04 Dec 2007 13:45:15 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Izclf-0005d7-BI for discuss@apps.ietf.org; Tue, 04 Dec 2007 13:45:15 -0500 Received: from elasmtp-scoter.atl.sa.earthlink.net ([209.86.89.67]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Izcld-0008Ui-Un for discuss@apps.ietf.org; Tue, 04 Dec 2007 13:45:15 -0500 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=OFadx3CkK7iZlm456p+tXObK50y48gmGHO/xvZMX++4dDVNbT1jpCoD0T+SqtYFu; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [66.167.202.36] (helo=oemcomputer) by elasmtp-scoter.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1Izcla-0006Kh-Bl for discuss@apps.ietf.org; Tue, 04 Dec 2007 13:45:10 -0500 Message-ID: <002a01c836a6$10051a20$6801a8c0@oemcomputer> From: "Randy Presuhn" To: References: <20071204164243.GA23212@nic.fr><3F673E84-8B16-4E1C-AB68-27A7EB3DEB35@tzi.org> Subject: Re: Do we now require change control on specifications we use? Date: Tue, 4 Dec 2007 10:47:02 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888a4beb055f130b31ae59e602d31f4b64092a1004e6c8c5961350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 66.167.202.36 X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org Hi - > From: "Paul Hoffman" > To: "Carsten Bormann" > Cc: > Sent: Tuesday, December 04, 2007 10:25 AM > Subject: Re: Do we now require change control on specifications we use? .. > The changes in ASN.1 have had little or no effect on the IETF. ... I disagree. The dropping of the MACRO notation was one of the factors (though by no means the only one) behind the migration from SMIv1 to SMIV2 in SNMP, and one of the reasons why SMIv2 is *not* defined using ASN.1 notation, even though it makes reference to ASN.1 types, etc. The term "adapted subset" really just means that there are some familiar tokens in the language. The whole SNMPv1->v2 transition was an *extremely* painful process, and the net management old-timers cannot help but be wary. I also know first-hand that the changes caused an enormous amount of grief for the CMIP folk in JTC1/SC21/WG4. We were just very glad we hadn't based GDMO on ASN.1, despite significant pressure to do so. Randy From discuss-bounces@apps.ietf.org Tue Dec 04 14:02:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Izd22-0005Hc-30; Tue, 04 Dec 2007 14:02:10 -0500 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1Izd20-0005HR-N1 for discuss-confirm+ok@megatron.ietf.org; Tue, 04 Dec 2007 14:02:08 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Izd20-0005HJ-DQ for discuss@apps.ietf.org; Tue, 04 Dec 2007 14:02:08 -0500 Received: from sparkle.rodents.montreal.qc.ca ([216.46.5.7]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Izd1y-0001HM-Og for discuss@apps.ietf.org; Tue, 04 Dec 2007 14:02:08 -0500 Received: (from mouse@localhost) by Sparkle.Rodents.Montreal.QC.CA (8.8.8/8.8.8) id OAA06181; Tue, 4 Dec 2007 14:02:05 -0500 (EST) From: der Mouse Message-Id: <200712041902.OAA06181@Sparkle.Rodents.Montreal.QC.CA> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Erik-Conspiracy: There is no Conspiracy - and if there were I wouldn't be part of it anyway. X-Message-Flag: Microsoft: the company who gave us the botnet zombies. Date: Tue, 4 Dec 2007 13:54:39 -0500 (EST) To: discuss@apps.ietf.org Subject: Re: I-D Action:draft-newman-email-subaddr-01.txt In-Reply-To: <1623535398.20071204093500@pobox.com> References: <20071203094351.GA19449@nic.fr> <2639.1196720643.545129@peirce.dave.cridland.net> <20071204161659.GA19161@nic.fr> <1623535398.20071204093500@pobox.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org >> [..."global subaddressing"...] >> That's may be a good idea but it is something new, not a description >> of a current practice. > Well, it seems to be "partial" current practice. My public email > address goes to a forwarder (pobox.com) that, being fairly > knowledgable in the email area, will rewrite my address while > preserving the detail portion when forwarding it to my actual ISP. Sure, but this is by private agreement among pobox.com, you, and your actual provider; it is hardly "global", and, as with almost everything else involving local-parts, is the business of nobody but those three parties. > Unfortunately, my current ISP rejects such addresses as Recipient > Unknown! This means that MY "local convention" is thwarted by my > ISPs "border servers". Yes, anyone who rejects plussed addresses because they think the plus sign renders the address invalid is broken. > I would love to point the ISP to an RFC that shows them what ought to > be allowed. 2822 (and 2821, which refers to 2822 for many things, including this). Given their present position, they probably aren't going to want to even read it, much less implement it. To me this means you need to stop getting mail through them, switching instead to someone who actually understands email. Fortunately, there are many places that will cheerfully host email for you, for comparatively little money - you might even be able to find one willing to comp your account. /~\ The ASCII der Mouse \ / Ribbon Campaign X Against HTML mouse@rodents.montreal.qc.ca / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B From discuss-bounces@apps.ietf.org Tue Dec 04 14:04:12 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Izd3z-0006LJ-Sh; Tue, 04 Dec 2007 14:04:11 -0500 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1Izd3y-0006JF-Eu for discuss-confirm+ok@megatron.ietf.org; Tue, 04 Dec 2007 14:04:10 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Izd3y-0006IT-4n for discuss@apps.ietf.org; Tue, 04 Dec 2007 14:04:10 -0500 Received: from mailhost.informatik.uni-bremen.de ([2001:638:708:30c9:209:3dff:fe00:7136] helo=informatik.uni-bremen.de) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Izd3v-0001Pp-PA for discuss@apps.ietf.org; Tue, 04 Dec 2007 14:04:10 -0500 X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.0/8.14.0) with ESMTP id lB4J3xhE005762; Tue, 4 Dec 2007 20:03:59 +0100 (CET) Received: from [130.129.85.253] (unknown [130.129.85.253]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTP id B0D355D8D; Tue, 4 Dec 2007 20:01:33 +0100 (CET) Message-Id: <0817EFA5-CADE-4CB0-BD37-E5DE92A1FD4D@tzi.org> From: Carsten Bormann To: Paul Hoffman In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v915) Subject: Re: Do we now require change control on specifications we use? Date: Tue, 4 Dec 2007 11:00:16 -0800 References: <20071204164243.GA23212@nic.fr> <3F673E84-8B16-4E1C-AB68-27A7EB3DEB35@tzi.org> X-Mailer: Apple Mail (2.915) X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: discuss@apps.ietf.org, Carsten Bormann X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org On Dec 04 2007, at 10:25, Paul Hoffman wrote: > At 9:29 AM -0800 12/4/07, Carsten Bormann wrote: >> XML is *not* a moving target. >> ASN.1 was. Worse, it was in the control of tool vendors who were >> living off changes to the "standard" and increasing complexity in >> order to sell upgrades and keep a high barrier to market entry. > > Oh, please. The "added complexity" that was *needed* to be changed > in all the PKIX and S/MIME specs to meet the changes over 20 years > of ASN.1 changes are minor and cause no bits-on-the-wire changes. So you were lucky. (One could also say the writers of those specs had the right "taste" in using only features that survived.) > Blaming this on ASN.1 "tool vendors" is silly. First, there is > basically only one significant tool vendor. See? The strategy worked for them. (And yes, "tool vendors" is a simplification -- "that part of the ecosystem that benefits from change more than from stability" is a bit long.) The end result is that there is a dearth of useful ASN.1 tools. That matters. > More important, however, is that most of the changes have been to > add new data formats that the IETF has completely ignored. Those > formats (PER, CER, XER, YAER...) were wanted by other SDOs; There is an interesting push-pull relationship to those desires (as in "wanted"), but this is off-topic. > The changes in ASN.1 have had little or no effect on the IETF. Because the IETF uncoupled from the "progress" in those cases where it mattered. > We are considering bringing our specs up to date now, and it is > quite easy and completely voluntary. I was not trying to criticize that. I still think ASN.1 is a textbook example for an external dependency gone wrong, at least for some of its customers. And my point stands that having a dependency on an SDO that does not care about you does not help. Gruesse, Carsten From discuss-bounces@apps.ietf.org Tue Dec 04 16:50:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzffO-00015k-3G; Tue, 04 Dec 2007 16:50:58 -0500 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1IzffM-0000xx-P2 for discuss-confirm+ok@megatron.ietf.org; Tue, 04 Dec 2007 16:50:56 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzffM-0000tz-Av for discuss@apps.ietf.org; Tue, 04 Dec 2007 16:50:56 -0500 Received: from bes.cs.utk.edu ([160.36.56.220]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IzffK-0006Z7-52 for discuss@apps.ietf.org; Tue, 04 Dec 2007 16:50:56 -0500 Received: from localhost (localhost [127.0.0.1]) by bes.cs.utk.edu (Postfix) with ESMTP id AA6A11030F3; Tue, 4 Dec 2007 16:50:53 -0500 (EST) X-Virus-Scanned: by amavisd-new with ClamAV and SpamAssasin at cs.utk.edu Received: from bes.cs.utk.edu ([127.0.0.1]) by localhost (bes.cs.utk.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BRizDntw3F1L; Tue, 4 Dec 2007 16:50:51 -0500 (EST) Received: from lust.indecency.org (dhcp-17a4.ietf70.org [130.129.23.164]) by bes.cs.utk.edu (Postfix) with ESMTP id 4BA771030D9; Tue, 4 Dec 2007 16:50:51 -0500 (EST) Message-ID: <4755CBAA.10003@cs.utk.edu> Date: Tue, 04 Dec 2007 13:50:34 -0800 From: Keith Moore User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: Bill McQuillan Subject: Re: I-D Action:draft-newman-email-subaddr-01.txt References: <20071203094351.GA19449@nic.fr> <2639.1196720643.545129@peirce.dave.cridland.net> <20071204161659.GA19161@nic.fr> <1623535398.20071204093500@pobox.com> In-Reply-To: <1623535398.20071204093500@pobox.com> X-Enigmail-Version: 0.95.5 OpenPGP: id=E1473978 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: Apps-Discusssion X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org > Well, it seems to be "partial" current practice. My public email address > goes to a forwarder (pobox.com) that, being fairly knowledgable in the > email area, will rewrite my address while preserving the detail portion > when forwarding it to my actual ISP. I know they understand the "+" > delimiter, but I haven't tested other delimiters. > > Unfortunately, my current ISP rejects such addresses as Recipient Unknown! > This means that MY "local convention" is thwarted by my ISPs "border > servers". > > I would love to point the ISP to an RFC that shows them what ought to be > allowed. > is this a case of your ISP not supporting subaddressing on its mail servers, or a case of your ISP imposing an interception proxy that interferes with traffic to your own mail servers? From discuss-bounces@apps.ietf.org Tue Dec 04 18:51:24 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzhXs-0007hi-SI; Tue, 04 Dec 2007 18:51:20 -0500 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1IzhXr-0007ha-Uw for discuss-confirm+ok@megatron.ietf.org; Tue, 04 Dec 2007 18:51:19 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzhXr-0007hQ-Kv for discuss@apps.ietf.org; Tue, 04 Dec 2007 18:51:19 -0500 Received: from [2001:838:378:0:211:9ff:fe2c:e28e] (helo=turner.dave.cridland.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IzhXq-0000Cv-Im for discuss@apps.ietf.org; Tue, 04 Dec 2007 18:51:19 -0500 Received: from peirce.dave.cridland.net ([217.155.137.61]) by turner.dave.cridland.net (submission) via TCP with ESMTPA id ; Tue, 4 Dec 2007 23:51:00 +0000 Subject: Re: I-D Action:draft-newman-email-subaddr-01.txt References: <20071203094351.GA19449@nic.fr> <2639.1196720643.545129@peirce.dave.cridland.net> <20071204161659.GA19161@nic.fr> In-Reply-To: <20071204161659.GA19161@nic.fr> MIME-Version: 1.0 Message-Id: <2639.1196812257.522519@peirce.dave.cridland.net> Date: Tue, 04 Dec 2007 23:50:57 +0000 From: Dave Cridland To: Stephane Bortzmeyer Content-Type: text/plain; delsp="yes"; charset="us-ascii"; format="flowed" X-Spam-Score: -1.4 (-) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 Cc: Apps Discuss X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org On Tue Dec 4 16:16:59 2007, Stephane Bortzmeyer wrote: > On Mon, Dec 03, 2007 at 10:24:03PM +0000, > Dave Cridland wrote a message of 89 lines > which said: > > > As good as any. > > May be ietf-smtp@imc.org would have been a better place? > > Possibly. But this one's been picked, now, and subaddressing isn't specific to SMTP, so this one works for me just as well. (Even if I'd somehow become unsubscribed). > > Subaddressing isn't described anywhere, > That's the whole point, I believe. Subaddressing has always been a > matter of local conventions (like the Firstname.Name@example.org > convention in many environments), not needing to be "described". > > Yes, it's a convention local to a specific ADMD. This memo does indeed describe one very common, and useful, convention. John Klensin (and, I think, Keith Moore) both suggested that I add text to make it exceptionally clear that externally to the ADMD, there is no way to tell if a particular address is (in the phrasing of the SIEVE subaddressing extension) a detailed address or not - these are indeed perfectly legal addresses. > If I understand you well, you suggest to create (not describe) a new > concept, "global subaddressing", with a standard delimiter and > subaddressing-aware software, allowing new tricks (like the MLM you > mention, which accepts mail only from subscribers and who can > recognize them even when they use subaddressing). > > That's may be a good idea but it is something new, not a description > of a current practice. > > Well, somewhat to my surprise, Keith said this has been going on for some time, and John said it was not especially different to the use of "post only" addresses. Arguably, this *is* current practise, albeit not widespread, and is unblessed primarily due to the absence of this document. I freely admit that there's cases of interpreting subaddressing where I'm unsure that the actor is doing the Right Thing, and hence there's also some tightening up to do. But, this is not a "global" thing, it's specific to an ADMD. The only case where I suggest (or rather, Chris Newman suggested and I watered down but essentially agree with) that actors external to the ADMD should consider the convention is MLMs, essentially because they're acting per-pro the user in a sense. Using a standard -- or at least heavily promoted -- delimiter doesn't preclude people from choosing another (or another method entirely), but it does mean that when deploying an MTA and a Store, for example, if both claim to be "Subaddress-aware", according to RFC-9999, then they'll both work together nicely. The purposeful use of the phrase "Subaddress-aware" is merely to provide a useful stamp with which to market your product - there's no more sinister intent than that. > > No, every component needs to know about it. > > > 1) The final MTA. > > 2) The MDA. > > 3) The MUA. > > 4) The Submission server. > > Can you explain why the MUA and the MSA need to know it? > > Some MSAs restrict usage of a reverse-path to specific authenticated users, for example, I might only be allowed to use , and not . Such MSAs need to be aware that is also valid for me, because it is the same "primary address", even if they've never seen it before. An MUA wishing to provide a user-friendly UI to subaddressing also needs to know the convention, in order to be capable of forming local-parts for use in both message header fields and envelope reverse-paths. If it's additionally performing some specific actions on message which are to be considered directly addressed to the user, then it needs to know for this, too. Dave. -- Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@jabber.org - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade From discuss-bounces@apps.ietf.org Tue Dec 04 19:23:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Izi30-0005zf-8N; Tue, 04 Dec 2007 19:23:30 -0500 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1Izi2y-0005zV-Qk for discuss-confirm+ok@megatron.ietf.org; Tue, 04 Dec 2007 19:23:28 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Izi2y-0005zN-HF for discuss@apps.ietf.org; Tue, 04 Dec 2007 19:23:28 -0500 Received: from ka.cs.utk.edu ([160.36.56.221]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Izi2x-0002J8-Pj for discuss@apps.ietf.org; Tue, 04 Dec 2007 19:23:28 -0500 Received: from localhost (localhost [127.0.0.1]) by ka.cs.utk.edu (Postfix) with ESMTP id 2D86ECB3FD; Tue, 4 Dec 2007 19:23:27 -0500 (EST) X-Virus-Scanned: by amavisd-new with ClamAV and SpamAssasin at cs.utk.edu Received: from ka.cs.utk.edu ([127.0.0.1]) by localhost (ka.cs.utk.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cyAlQtS1CddP; Tue, 4 Dec 2007 19:23:25 -0500 (EST) Received: from lust.indecency.org (dhcp-17a4.ietf70.org [130.129.23.164]) by ka.cs.utk.edu (Postfix) with ESMTP id 10201CB3FB; Tue, 4 Dec 2007 19:23:24 -0500 (EST) Message-ID: <4755EF6C.8060703@cs.utk.edu> Date: Tue, 04 Dec 2007 16:23:08 -0800 From: Keith Moore User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: Dave Cridland Subject: Re: I-D Action:draft-newman-email-subaddr-01.txt References: <20071203094351.GA19449@nic.fr> <2639.1196720643.545129@peirce.dave.cridland.net> <20071204161659.GA19161@nic.fr> <2639.1196812257.522519@peirce.dave.cridland.net> In-Reply-To: <2639.1196812257.522519@peirce.dave.cridland.net> X-Enigmail-Version: 0.95.5 OpenPGP: id=E1473978 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 2857c5c041d6c02d7181d602c22822c8 Cc: Apps Discuss X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org Dave Cridland wrote: > >> > Subaddressing isn't described anywhere,That's the whole point, I >> believe. Subaddressing has always been a >> matter of local conventions (like the Firstname.Name@example.org >> convention in many environments), not needing to be "described". >> >> > Yes, it's a convention local to a specific ADMD. I don't know what an ADMD is in the context of Internet email. AFAIK it's never been clearly defined in this context and I think it's probably misleading to use the term. > This memo does indeed describe one very common, and useful, > convention. John Klensin (and, I think, Keith Moore) both suggested > that I add text to make it exceptionally clear that externally to the > ADMD, there is no way to tell if a particular address is (in the > phrasing of the SIEVE subaddressing extension) a detailed address or > not - these are indeed perfectly legal addresses. the statement needs to be stronger than that. for the most part, nobody except the authoritative MTAs for the recipient's domain should be interpreting the local part of a recipient address. similarly, nobody except the MSAs for a sender's domain should be interpreting the local part of a return address. having said that, if lists do fuzzy matching on addresses (recognizing that in general there are often several equivalent ways of spelling an email address) they're just using heuristics to decide what traffic to forward to subscribers. this is no different than any other content-based heuristics (e.g. spam or virus filters) that they might employ to decide what traffic to forward to subscribers. nothing (including this document) should require a list to accept mail from an address that is similar to, but not quite the same as, a subscriber address. it would be silly to say to a list "you can filter based on message content but you can't filter based on the local-part of a from or return address". but if a list can tune its filtering heuristics to work better, the list might provide better service to its subscribers. >> If I understand you well, you suggest to create (not describe) a new >> concept, "global subaddressing", with a standard delimiter and >> subaddressing-aware software, allowing new tricks (like the MLM you >> mention, which accepts mail only from subscribers and who can >> recognize them even when they use subaddressing). >> >> That's may be a good idea but it is something new, not a description >> of a current practice. >> >> > Well, somewhat to my surprise, Keith said this has been going on for > some time, and John said it was not especially different to the use of > "post only" addresses. Arguably, this *is* current practise, albeit > not widespread, and is unblessed primarily due to the absence of this > document. I freely admit that there's cases of interpreting > subaddressing where I'm unsure that the actor is doing the Right > Thing, and hence there's also some tightening up to do. fwiw, I was about to write my own version of this document, and I would certainly have mentioned the case of a mailing list doing fuzzy matching on a sender address vs. its list of subscriber addresses. (what I tend to do for most lists is to subscribe twice - once at my normal email address, and again at the subaddress. then I set "nomail" or the equivalent for the normal address. that way I can send mail from my normal address and have the list subscription go to the subaddress) > But, this is not a "global" thing, it's specific to an ADMD. The only > case where I suggest (or rather, Chris Newman suggested and I watered > down but essentially agree with) that actors external to the ADMD > should consider the convention is MLMs, essentially because they're > acting per-pro the user in a sense. > > Using a standard -- or at least heavily promoted -- delimiter doesn't > preclude people from choosing another (or another method entirely), > but it does mean that when deploying an MTA and a Store, for example, > if both claim to be "Subaddress-aware", according to RFC-9999, then > they'll both work together nicely. fwiw, bulk_mailer recognizes - = / . # % + because at the time I wrote the code, I found cases where all of these had been used to delimit subaddresses. compared with just - and +, this adds 6 whole bytes of code and a few dozen cpu cycles per comparison. I really don't think that having one or two widely advertised conventions for subaddress delmiting is a good idea, precisely because I don't want to encourage MSAs and MTAs and MUAs to be too smart about addresses. what I really want to encourage is mostly these two things: 1. giving users an extensible space for their email messages is really useful 2. yes, it's legitimate for these printable characters to appear in the local-part of an email address >> > No, every component needs to know about it. >> > > 1) The final MTA. >> > 2) The MDA. >> > 3) The MUA. >> > 4) The Submission server. >> >> Can you explain why the MUA and the MSA need to know it? >> >> > Some MSAs restrict usage of a reverse-path to specific authenticated > users, for example, I might only be allowed to use > , and not . Such MSAs need to > be aware that is also valid for me, because it > is the same "primary address", even if they've never seen it before. yes, MSAs that verify the return address need to be aware of which return addresses are (a) valid and (b) usable by the authenticated submitter. > An MUA wishing to provide a user-friendly UI to subaddressing also > needs to know the convention, in order to be capable of forming > local-parts for use in both message header fields and envelope > reverse-paths. If it's additionally performing some specific actions > on message which are to be considered directly addressed to the user, > then it needs to know for this, too. so far, I'm unconvinced of this . Keith From discuss-bounces@apps.ietf.org Wed Dec 05 01:28:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iznjj-000630-UQ; Wed, 05 Dec 2007 01:27:59 -0500 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1Iznji-00062p-Ov for discuss-confirm+ok@megatron.ietf.org; Wed, 05 Dec 2007 01:27:58 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iznji-00062h-Bu for discuss@apps.ietf.org; Wed, 05 Dec 2007 01:27:58 -0500 Received: from sparkle.rodents.montreal.qc.ca ([216.46.5.7]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iznjg-0000c9-PH for discuss@apps.ietf.org; Wed, 05 Dec 2007 01:27:58 -0500 Received: (from mouse@localhost) by Sparkle.Rodents.Montreal.QC.CA (8.8.8/8.8.8) id BAA17312; Wed, 5 Dec 2007 01:27:53 -0500 (EST) Date: Wed, 5 Dec 2007 01:27:53 -0500 (EST) From: der Mouse Message-Id: <200712050627.BAA17312@Sparkle.Rodents.Montreal.QC.CA> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Erik-Conspiracy: There is no Conspiracy - and if there were I wouldn't be part of it anyway. X-Message-Flag: Microsoft: the company who gave us the botnet zombies. To: discuss@apps.ietf.org Subject: Re: I-D Action:draft-newman-email-subaddr-01.txt In-Reply-To: <2639.1196812257.522519@peirce.dave.cridland.net> References: <20071203094351.GA19449@nic.fr> <2639.1196720643.545129@peirce.dave.cridland.net> <20071204161659.GA19161@nic.fr> <2639.1196812257.522519@peirce.dave.cridland.net> X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org > [...subaddressing...plussed addresses...] The biggest worry I have is that this will lead to people who currently design busted webforms who reject plussed addresses will start accepting + but none of the other variants, under the impression they're fixing something, and, worse, that they will then point to this as some kind of weird justification for their brokenness. Of course, people with the proverbially-dangerous "little learning" have never been stopped by lack of justificatory documents.... /~\ The ASCII der Mouse \ / Ribbon Campaign X Against HTML mouse@rodents.montreal.qc.ca / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B From discuss-bounces@apps.ietf.org Wed Dec 05 05:10:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzrBl-0000Mc-3s; Wed, 05 Dec 2007 05:09:09 -0500 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1IzrBk-0000ML-03 for discuss-confirm+ok@megatron.ietf.org; Wed, 05 Dec 2007 05:09:08 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzrBj-0000Kt-Hl for discuss@apps.ietf.org; Wed, 05 Dec 2007 05:09:07 -0500 Received: from [2001:838:378:0:211:9ff:fe2c:e28e] (helo=turner.dave.cridland.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IzrBg-0007Zf-FZ for discuss@apps.ietf.org; Wed, 05 Dec 2007 05:09:07 -0500 Received: from peirce.dave.cridland.net ([217.155.137.61]) by turner.dave.cridland.net (submission) via TCP with ESMTPA id ; Wed, 5 Dec 2007 10:08:50 +0000 Subject: Re: I-D Action:draft-newman-email-subaddr-01.txt References: <20071203094351.GA19449@nic.fr> <2639.1196720643.545129@peirce.dave.cridland.net> <20071204161659.GA19161@nic.fr> <2639.1196812257.522519@peirce.dave.cridland.net> <4755EF6C.8060703@cs.utk.edu> In-Reply-To: <4755EF6C.8060703@cs.utk.edu> MIME-Version: 1.0 Message-Id: <2639.1196849327.522853@peirce.dave.cridland.net> Date: Wed, 05 Dec 2007 10:08:47 +0000 From: Dave Cridland To: Keith Moore Content-Type: text/plain; delsp="yes"; charset="us-ascii"; format="flowed" X-Spam-Score: -1.4 (-) X-Scan-Signature: 4b7d60495f1a7f2e853e8cbae7e6dbfc Cc: Apps Discuss X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org On Wed Dec 5 00:23:08 2007, Keith Moore wrote: > I don't know what an ADMD is in the context of Internet email. > AFAIK > it's never been clearly defined in this context and I think it's > probably misleading to use the term. > > I think Dave Crocker defines it in draft-crocker-email-arch section 2.3 pretty well. Pick another term if you feel more comfortable, I'm not particular wed to most of the increasingly clunky language we use to describe actors and addresses within the global MHS, most especially the terms I've had to come up with for this document. ("Detail"? Ugh.) > > This memo does indeed describe one very common, and useful, > > convention. John Klensin (and, I think, Keith Moore) both > suggested > > that I add text to make it exceptionally clear that externally to > the > > ADMD, there is no way to tell if a particular address is (in the > > phrasing of the SIEVE subaddressing extension) a detailed address > or > > not - these are indeed perfectly legal addresses. > the statement needs to be stronger than that. for the most part, > nobody > except the authoritative MTAs for the recipient's domain should be > interpreting the local part of a recipient address. similarly, > nobody > except the MSAs for a sender's domain should be interpreting the > local > part of a return address. > > That text is better, yes. I'll use something very similar. > having said that, if lists do fuzzy matching on addresses > (recognizing > that in general there are often several equivalent ways of spelling > an > email address) they're just using heuristics to decide what traffic > to > forward to subscribers. this is no different than any other > content-based heuristics (e.g. spam or virus filters) that they > might > employ to decide what traffic to forward to subscribers. nothing > (including this document) should require a list to accept mail from > an > address that is similar to, but not quite the same as, a subscriber > address. it would be silly to say to a list "you can filter based > on > message content but you can't filter based on the local-part of a > from > or return address". but if a list can tune its filtering > heuristics to > work better, the list might provide better service to its > subscribers. Or it might screw things up irrevocably... As common as this sort of thing is - and I'm pretty sure that local-parts are treated case-insensitively, for example - I don't want to even attempt to describe or suggest what might happen here. Trying to specify this sort of thing would be simpler by leaving a couple of blank pages and telling the implementor to write whatever they liked in. Whereas, if the MLM is explicitly told that the convention is in use within the ADMD (at least for this subscriber), then it can perform that kind of action without the need for potentially dangerous guesswork. > fwiw, I was about to write my own version of this document, and I > would > certainly have mentioned the case of a mailing list doing fuzzy > matching > on a sender address vs. its list of subscriber addresses. > > FWIW, I think there's a BCP to be written on MLMs; the state of the art is getting quite refined, these days, and it's another area I can't really find much documentation. (List-* header fields not withstanding). > (what I tend to do for most lists is to subscribe twice - once at my > normal email address, and again at the subaddress. then I set > "nomail" > or the equivalent for the normal address. that way I can send mail > from > my normal address and have the list subscription go to the > subaddress) Right, and this sort of thing is possible with most, or even all, MLMs. I'll make it clear that this is essentially a specific case of this functionality, and nothing particularly new. That said, it has been suggested that MLMs might want to go a step further, and rewrite messages such that a message from copied to a mailing list which has a (Subaddress-enabled) subscriber of would cause the MLM to go as far as rewriting headers to the subscribed address. > > Using a standard -- or at least heavily promoted -- delimiter > doesn't > > preclude people from choosing another (or another method > entirely), > > but it does mean that when deploying an MTA and a Store, for > example, > > if both claim to be "Subaddress-aware", according to RFC-9999, > then > > they'll both work together nicely. > fwiw, bulk_mailer recognizes - = / . # % + because at the time I > wrote > the code, I found cases where all of these had been used to delimit > subaddresses. compared with just - and +, this adds 6 whole bytes > of > code and a few dozen cpu cycles per comparison. I really don't > think > that having one or two widely advertised conventions for subaddress > delmiting is a good idea, precisely because I don't want to > encourage > MSAs and MTAs and MUAs to be too smart about addresses. Whereas it's okay for bulk_mailer to be smart about them? Seriously, this sounds like you're arguing that we should describe it as loosely as possible in order to mitigate the damage by people who don't read the specification, or who selectively ignore portions of it. Where there is a convention that local-parts may adhere to, then it makes sense for this to be as usefully defined as possible, such that all components of the MHS - from MTA to MUA and back to MSA - all have the same notion. This is purely a convention of no relevance outside the ADMD. > what I really > want to encourage is mostly these two things: > > 1. giving users an extensible space for their email messages is > really > useful Yup. > 2. yes, it's legitimate for these printable characters to appear in > the > local-part of an email address Right. (FWIW, I think I'll add a paragraph or two explaining that "+" is a character that does appear in local-parts that demonstrably do not have subaddressing). But I think for usability, having a known convention is useful. It allows "checkbox configuration" of all components within the ADMD, as well as certain components outside of it (such as MLMs, which can be told that the local-part convention for the domain is this one). > > An MUA wishing to provide a user-friendly UI to subaddressing also > > needs to know the convention, > so far, I'm unconvinced of this . As an MUA developer of sorts (I don't get paid for it anymore, and it's a mere hobby), I'm very much convinced by it. Sure, it's not essential - but it makes it possible to build a clean UI and several rather neat tricks. It makes it possible to support it such that my mother could use it, rather than restricting it largely to IETF participants and other technically aware people. Don't ask me how the MUA knows the convention is supported, though. I do have an answer, but I'll have to use the "A word", and people seem to get upset by it. :-) Dave. -- Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@jabber.org - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade From discuss-bounces@apps.ietf.org Wed Dec 05 05:55:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Izrte-0006k7-He; Wed, 05 Dec 2007 05:54:30 -0500 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1Izrtd-0006fo-62 for discuss-confirm+ok@megatron.ietf.org; Wed, 05 Dec 2007 05:54:29 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Izrtc-0006fS-P4 for discuss@apps.ietf.org; Wed, 05 Dec 2007 05:54:28 -0500 Received: from ppsw-6.csi.cam.ac.uk ([131.111.8.136]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Izrtb-0000lB-4V for discuss@apps.ietf.org; Wed, 05 Dec 2007 05:54:28 -0500 X-Cam-SpamDetails: Not scanned X-Cam-AntiVirus: No virus found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-1.csi.cam.ac.uk ([131.111.8.51]:54409) by ppsw-6.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.156]:25) with esmtpa (EXTERNAL:fanf2) id 1IzrtX-0006Lx-K1 (Exim 4.67) (return-path ); Wed, 05 Dec 2007 10:54:23 +0000 Received: from fanf2 (helo=localhost) by hermes-1.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1IzrtX-0004JJ-6D (Exim 4.67) (return-path ); Wed, 05 Dec 2007 10:54:23 +0000 Date: Wed, 5 Dec 2007 10:54:23 +0000 From: Tony Finch X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk To: Dave Cridland Subject: Re: I-D Action:draft-newman-email-subaddr-01.txt In-Reply-To: <2639.1196812257.522519@peirce.dave.cridland.net> Message-ID: References: <20071203094351.GA19449@nic.fr> <2639.1196720643.545129@peirce.dave.cridland.net> <20071204161659.GA19161@nic.fr> <2639.1196812257.522519@peirce.dave.cridland.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: -4.0 (----) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: Apps Discuss X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org On Tue, 4 Dec 2007, Dave Cridland wrote: > > An MUA wishing to provide a user-friendly UI to subaddressing also needs to > know the convention, in order to be capable of forming local-parts for use in > both message header fields and envelope reverse-paths. If it's additionally > performing some specific actions on message which are to be considered > directly addressed to the user, then it needs to know for this, too. A particular example would be an in-MUA Sieve implementation. Tony. -- f.a.n.finch http://dotat.at/ SOLE LUNDY FASTNET IRISH SEA SHANNON: WEST OR SOUTHWEST 6 TO GALE 8, OCCASIONALLY SEVERE GALE 9. ROUGH OR VERY ROUGH, OCCASIONALLY HIGH. RAIN OR SQUALLY SHOWERS. MODERATE OR GOOD, OCCASIONALLY POOR. From discuss-bounces@apps.ietf.org Wed Dec 05 10:19:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Izw1h-0008Kb-UU; Wed, 05 Dec 2007 10:19:05 -0500 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1Izw1g-0008KK-ET for discuss-confirm+ok@megatron.ietf.org; Wed, 05 Dec 2007 10:19:04 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Izw1g-0008Ju-43 for discuss@apps.ietf.org; Wed, 05 Dec 2007 10:19:04 -0500 Received: from shu.cs.utk.edu ([160.36.56.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Izw1f-0002PO-DC for discuss@apps.ietf.org; Wed, 05 Dec 2007 10:19:04 -0500 Received: from localhost (localhost [127.0.0.1]) by shu.cs.utk.edu (Postfix) with ESMTP id C153A1EE2CC; Wed, 5 Dec 2007 10:18:57 -0500 (EST) X-Virus-Scanned: by amavisd-new with ClamAV and SpamAssasin at cs.utk.edu Received: from shu.cs.utk.edu ([127.0.0.1]) by localhost (shu.cs.utk.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s6d8NXROcpOB; Wed, 5 Dec 2007 10:18:55 -0500 (EST) Received: from lust.indecency.org (dhcp-415b.ietf70.org [130.129.65.91]) by shu.cs.utk.edu (Postfix) with ESMTP id B2C9F1EE2C1; Wed, 5 Dec 2007 10:18:53 -0500 (EST) Message-ID: <4756C14D.5080407@cs.utk.edu> Date: Wed, 05 Dec 2007 07:18:37 -0800 From: Keith Moore User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: Dave Cridland Subject: Re: I-D Action:draft-newman-email-subaddr-01.txt References: <20071203094351.GA19449@nic.fr> <2639.1196720643.545129@peirce.dave.cridland.net> <20071204161659.GA19161@nic.fr> <2639.1196812257.522519@peirce.dave.cridland.net> <4755EF6C.8060703@cs.utk.edu> <2639.1196849327.522853@peirce.dave.cridland.net> In-Reply-To: <2639.1196849327.522853@peirce.dave.cridland.net> X-Enigmail-Version: 0.95.5 OpenPGP: id=E1473978 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: -4.0 (----) X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4 Cc: Apps Discuss X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org >> > Using a standard -- or at least heavily promoted -- delimiter doesn't >> > preclude people from choosing another (or another method entirely), >> > but it does mean that when deploying an MTA and a Store, for example, >> > if both claim to be "Subaddress-aware", according to RFC-9999, then >> > they'll both work together nicely. >> fwiw, bulk_mailer recognizes - = / . # % + because at the time I wrote >> the code, I found cases where all of these had been used to delimit >> subaddresses. compared with just - and +, this adds 6 whole bytes of >> code and a few dozen cpu cycles per comparison. I really don't think >> that having one or two widely advertised conventions for subaddress >> delmiting is a good idea, precisely because I don't want to encourage >> MSAs and MTAs and MUAs to be too smart about addresses. > > Whereas it's okay for bulk_mailer to be smart about them? Given that the only thing bulk_mailer uses them for is to decide whether an address happens to be "close enough" to a subscriber's address, it seems pretty harmless. But I agree it's tricky to explain why this is harmless while maintaining that other intermediaries that peek at the local-part can do harm. I think people on this list probably understand the difference, but getting the audience of an RFC to understand the difference is difficult. > Seriously, this sounds like you're arguing that we should describe it > as loosely as possible in order to mitigate the damage by people who > don't read the specification, or who selectively ignore portions of it. I'm certainly worried about the potential for damage done by people who read enough of the specification to know what subaddresses look like, and ignore the portion of the specification that says "if you're not the MSA for the sender's domain, nor an authoritative MTA for the recipient's domain, you MUST treat the local-part as opaque". > Where there is a convention that local-parts may adhere to, then it > makes sense for this to be as usefully defined as possible, such that > all components of the MHS - from MTA to MUA and back to MSA - all have > the same notion. This is purely a convention of no relevance outside > the ADMD. I have yet to be convinced that this is at all in scope for _any_ MUA, except in the very broad sense that MUAs should allow users to type in _any_ valid address as a sender or recipient address. I really don't buy the model that an MUA lives within a particular mail domain, perhaps because my MUA is configured to deal with mailboxes in multiple mail domains that are maintained by multiple parties - and this seems increasingly common. I don't really want to see MUAs changing their user interfaces on a per-domain basis. > >> what I really >> want to encourage is mostly these two things: >> >> 1. giving users an extensible space for their email messages is really >> useful > > Yup. > > >> 2. yes, it's legitimate for these printable characters to appear in the >> local-part of an email address > > Right. (FWIW, I think I'll add a paragraph or two explaining that "+" > is a character that does appear in local-parts that demonstrably do > not have subaddressing). > > But I think for usability, having a known convention is useful. It > allows "checkbox configuration" of all components within the ADMD, as > well as certain components outside of it (such as MLMs, which can be > told that the local-part convention for the domain is this one). Along those lines it might be useful to make a list of things that are necessary for each component in a mail system to be compatible with subaddresses. e.g. MSAs must do these things to be subaddress-compatible, MTAs must do these things, MUAs must do these things, MLMs must do these things, mail domains must make sure that all of their MSAs and MTAs are compatible, and that any MLMs that they expect their subscribers to use are compatible, and if they impose particular MUAs on their users or encourage their users to use particular MUAs then they need to make sure that their MUAs are compatible. >> > An MUA wishing to provide a user-friendly UI to subaddressing also >> > needs to know the convention, > > >> so far, I'm unconvinced of this . > > As an MUA developer of sorts (I don't get paid for it anymore, and > it's a mere hobby), I'm very much convinced by it. Sure, it's not > essential - but it makes it possible to build a clean UI and several > rather neat tricks. can you give an example? I can imagine having a clean UI to create new subaddresses, to delete them, to specify what happens to mail sent to a particular subaddress. But absent some sort of standard protocol to communicate this to the delivery agent, I'm not sure that this is a MUA function. I can also imagine an MUA having the ability to use a subaddress as a default From address when reply to mail from a particular folder that is associated with a subaddress. But I don't know why having a per-folder default From address is specific to subaddresses. It seems like a generalization of per-mailbox default >From addresses that many MUAs already support. which reminds me - I am dubious that MUAs or users should assume that there's a relationship between the subaddress and the name of the folder where that mail ends up. at least I've found good reasons for them not to be the same. though admittedly that makes for a more complex user interface. Keith From discuss-bounces@apps.ietf.org Wed Dec 05 13:17:12 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzynD-0002Lp-Nz; Wed, 05 Dec 2007 13:16:19 -0500 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1IzynC-0002Lb-Bh for discuss-confirm+ok@megatron.ietf.org; Wed, 05 Dec 2007 13:16:18 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzynC-0002Ke-1A for discuss@apps.ietf.org; Wed, 05 Dec 2007 13:16:18 -0500 Received: from [2001:838:378:0:211:9ff:fe2c:e28e] (helo=turner.dave.cridland.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IzynA-0003rq-P3 for discuss@apps.ietf.org; Wed, 05 Dec 2007 13:16:18 -0500 Received: from peirce.dave.cridland.net ([217.155.137.61]) by turner.dave.cridland.net (submission) via TCP with ESMTPA id ; Wed, 5 Dec 2007 18:16:06 +0000 Subject: Re: I-D Action:draft-newman-email-subaddr-01.txt References: <20071203094351.GA19449@nic.fr> <2639.1196720643.545129@peirce.dave.cridland.net> <20071204161659.GA19161@nic.fr> <2639.1196812257.522519@peirce.dave.cridland.net> <4755EF6C.8060703@cs.utk.edu> <2639.1196849327.522853@peirce.dave.cridland.net> <4756C14D.5080407@cs.utk.edu> In-Reply-To: <4756C14D.5080407@cs.utk.edu> MIME-Version: 1.0 Message-Id: <7282.1196878561.595377@peirce.dave.cridland.net> Date: Wed, 05 Dec 2007 18:16:01 +0000 From: Dave Cridland To: Keith Moore Content-Type: text/plain; delsp="yes"; charset="us-ascii"; format="flowed" X-Spam-Score: -1.4 (-) X-Scan-Signature: 0ff9c467ad7f19c2a6d058acd7faaec8 Cc: Apps Discuss X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org On Wed Dec 5 15:18:37 2007, Keith Moore wrote: > Given that the only thing bulk_mailer uses them for is to decide > whether > an address happens to be "close enough" to a subscriber's address, > it > seems pretty harmless. But I agree it's tricky to explain why this > is > harmless while maintaining that other intermediaries that peek at > the > local-part can do harm. I think people on this list probably > understand the difference, but getting the audience of an RFC to > understand the difference is difficult. > > Right - hence why I downgraded -00's suggestion to automagically recognise subaddresses to -01's requirement that this be explicitly configurable. > > Seriously, this sounds like you're arguing that we should > describe it > > as loosely as possible in order to mitigate the damage by people > who > > don't read the specification, or who selectively ignore portions > of it. > I'm certainly worried about the potential for damage done by people > who > read enough of the specification to know what subaddresses look > like, > and ignore the portion of the specification that says "if you're > not the > MSA for the sender's domain, nor an authoritative MTA for the > recipient's domain, you MUST treat the local-part as opaque". > > Yes, but short of the world's first RFC with a click-through, I can't see a way of avoiding this. I think ultimately, we have to trust the reader to read the entire document, and ensure that the document makes this very clear. > I have yet to be convinced that this is at all in scope for _any_ > MUA, > except in the very broad sense that MUAs should allow users to type > in > _any_ valid address as a sender or recipient address. I really > don't > buy the model that an MUA lives within a particular mail domain, > perhaps > because my MUA is configured to deal with mailboxes in multiple mail > domains that are maintained by multiple parties - and this seems > increasingly common. I don't really want to see MUAs changing their > user interfaces on a per-domain basis. Well, it's not a change, per-se, it's an addition. But in as much as the MUA is co-operating with a remote store, as is typically the case, it has to expose features of that store, and its interactions with that store are to be considered as being within the scope of the ADMD. I'll cheerfully agree that this is probably a matter of hair splitting. > Along those lines it might be useful to make a list of things that > are > necessary for each component in a mail system to be compatible with > subaddresses. e.g. MSAs must do these things to be > subaddress-compatible, MTAs must do these things, MUAs must do these > things, MLMs must do these things, mail domains must make sure that > all > of their MSAs and MTAs are compatible, and that any MLMs that they > expect their subscribers to use are compatible, and if they impose > particular MUAs on their users or encourage their users to use > particular MUAs then they need to make sure that their MUAs are > compatible. > > I think the document has the beginnings of this. > >> > An MUA wishing to provide a user-friendly UI to subaddressing > also > >> > needs to know the convention, > > > > > >> so far, I'm unconvinced of this . > > > > As an MUA developer of sorts (I don't get paid for it anymore, and > > it's a mere hobby), I'm very much convinced by it. Sure, it's not > > essential - but it makes it possible to build a clean UI and > several > > rather neat tricks. > can you give an example? I can imagine having a clean UI to create > new > subaddresses, to delete them, to specify what happens to mail sent > to a > particular subaddress. But absent some sort of standard protocol to > communicate this to the delivery agent, I'm not sure that this is > a MUA > function. Well, ManageSIEVE is such a protocol. > I can also imagine an MUA having the ability to use a > subaddress as a default From address when reply to mail from a > particular folder that is associated with a subaddress. But I don't > know why having a per-folder default From address is specific to > subaddresses. It seems like a generalization of per-mailbox default > From addresses that many MUAs already support. > > Yes, that kind of thing is a mere specialization of the UI. Cleaner, certainly, but not a dramatic improvement. Similarly, many MUAs know about multiple addresses, and a reply to a message will default the from address to whichever address the message was addressed to - enhancing this to subaddresses is both obvious and trivial. I was thinking that an MUA might, when a mailing list is being subscribed to, automatically generate a suggested subaddress, and have simple drop-downs for subaddresses, rather than the user having to edit the From address each time. That's something that's much harder to deal with without subaddressing being known to the MUA. > which reminds me - I am dubious that MUAs or users should assume > that > there's a relationship between the subaddress and the name of the > folder > where that mail ends up. at least I've found good reasons for them > not > to be the same. though admittedly that makes for a more complex > user > interface. > > Agreed on all counts. Expressly in the document is that by default, there is no such relationship. Dave. -- Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@jabber.org - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade From discuss-bounces@apps.ietf.org Wed Dec 05 17:39:32 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J02tv-00013c-97; Wed, 05 Dec 2007 17:39:31 -0500 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1J02tu-00013P-89 for discuss-confirm+ok@megatron.ietf.org; Wed, 05 Dec 2007 17:39:30 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J02tt-000139-UV for discuss@apps.ietf.org; Wed, 05 Dec 2007 17:39:29 -0500 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J02tt-0004Ej-Ha for discuss@apps.ietf.org; Wed, 05 Dec 2007 17:39:29 -0500 Received: from totoro.qualcomm.com (totoro.qualcomm.com [129.46.61.158]) by ithilien.qualcomm.com (8.14.2/8.12.5/1.0) with ESMTP id lB5MdS9X009496 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 5 Dec 2007 14:39:28 -0800 Received: from dhcp-407d.ietf70.org (vpn-10-50-16-21.qualcomm.com [10.50.16.21]) by totoro.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id lB5MdQXv007606; Wed, 5 Dec 2007 14:39:27 -0800 (PST) Mime-Version: 1.0 Message-Id: In-Reply-To: <20071204162040.GB19161@nic.fr> References: <20071203094351.GA19449@nic.fr> <20071204162040.GB19161@nic.fr> X-Mailer: Eudora for Mac OS X X-message-flag: Warning: Outlook in use. Upgrade to Eudora: Date: Wed, 5 Dec 2007 14:36:00 -0800 To: Stephane Bortzmeyer From: Randall Gellens Subject: Re: I-D Action:draft-newman-email-subaddr-01.txt Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Random-Sig-Tag: 1.0b28 X-Spam-Score: -4.0 (----) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: Apps Discuss , Dave Cridland X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org At 5:20 PM +0100 12/4/07, Stephane Bortzmeyer wrote: > On Mon, Dec 03, 2007 at 07:45:47PM -0800, > Randall Gellens wrote > a message of 95 lines which said: > >> Currently, subaddressing is mostly part of the mostly undocumented >> email lore that some implementers are aware of while others are not. > > And that's the right way: subaddressing does not have to be > documented, it is a local convention. Even as a local convention, it is helpful to have a document that describes it. > (How can you tell if > bortzmeyer@nic.fr is not an address with subaddressing and "m" as the > delimiter?) Only the recipient's environment needs to know. I certainly don't need to know if I'm sending you email if the particular address I have for you is subaddressed. At present, the document does contain text about list servers recognizing subaddressing. This is the one area where I'm not convinced. I can see the benefit, but I think that once we allow for anything that isn't after final delivery knowing about subaddressing, at that point we have changed it from a purely local convention to one that does indeed have meaning elsewhere, and we pretty much are then forced to choose a single (or maybe two) character for the delimiter. Because of this, I am wavering as to if we should mention list servers or not. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly-selected tag: --------------- The nice thing about standards is that there are so many of them to choose from. --Andrew S. Tanenbaum From discuss-bounces@apps.ietf.org Wed Dec 05 17:55:40 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J039X-0004Pj-Rn; Wed, 05 Dec 2007 17:55:39 -0500 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1J039W-0004PI-M4 for discuss-confirm+ok@megatron.ietf.org; Wed, 05 Dec 2007 17:55:38 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J039W-0004OQ-BS for discuss@apps.ietf.org; Wed, 05 Dec 2007 17:55:38 -0500 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J039U-0005vV-P5 for discuss@apps.ietf.org; Wed, 05 Dec 2007 17:55:38 -0500 Received: from totoro.qualcomm.com (totoro.qualcomm.com [129.46.61.158]) by ithilien.qualcomm.com (8.14.2/8.12.5/1.0) with ESMTP id lB5MtZxr011314 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 5 Dec 2007 14:55:35 -0800 Received: from dhcp-407d.ietf70.org (vpn-10-50-16-21.qualcomm.com [10.50.16.21]) by totoro.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id lB5MtS1e013500; Wed, 5 Dec 2007 14:55:29 -0800 (PST) Mime-Version: 1.0 Message-Id: In-Reply-To: <2639.1196849327.522853@peirce.dave.cridland.net> References: <20071203094351.GA19449@nic.fr> <2639.1196720643.545129@peirce.dave.cridland.net> <20071204161659.GA19161@nic.fr> <2639.1196812257.522519@peirce.dave.cridland.net> <4755EF6C.8060703@cs.utk.edu> <2639.1196849327.522853@peirce.dave.cridland.net> X-Mailer: Eudora for Mac OS X X-message-flag: Warning: Outlook in use. Upgrade to Eudora: Date: Wed, 5 Dec 2007 14:45:46 -0800 To: Dave Cridland , Keith Moore From: Randall Gellens Subject: Re: I-D Action:draft-newman-email-subaddr-01.txt Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Random-Sig-Tag: 1.0b28 X-Spam-Score: -4.0 (----) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: Apps Discuss X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org At 10:08 AM +0000 12/5/07, Dave Cridland wrote: > Whereas, if the MLM is explicitly told that the convention is in > use within the ADMD (at least for this subscriber), then it can > perform that kind of action without the need for potentially > dangerous guesswork. There isn't any way to tell the MLM, though, aside from some administrative interface that is beyond the reach of most users of most MLMs. That's why I'm not convinced that the list server text is worth keeping. > FWIW, I think there's a BCP to be written on MLMs; the state of the > art is getting quite refined, these days, and it's another area I > can't really find much documentation. (List-* header fields not > withstanding). There's also a document a while back on using standard addresses, such as the -request address, and standard commands, IIRC. But a BCP on MLMs would be a good thing. > That said, it has been suggested that MLMs might want to go a step > further, and rewrite messages such that a message from > copied to a mailing list which has a > (Subaddress-enabled) subscriber of would > cause the MLM to go as far as rewriting headers to the subscribed > address. This makes me nervous. There may be some reason why a particular subaddress was used for a message. I don't think the MLM is in any position to know what is the right thing to do here. I'd be delighted if my MUA would let me assign a default From address (or "personality" or "account") to use when I send a message to a particular recipient. The MUA is in the best position to do this, and there is still the opportunity for the user to correct it. There is no chance for this at the MLM. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly-selected tag: --------------- We adore chaos because we love to produce order. --M. C. Escher From discuss-bounces@apps.ietf.org Wed Dec 05 17:55:47 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J039f-0004XE-0f; Wed, 05 Dec 2007 17:55:47 -0500 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1J039d-0004Wu-7x for discuss-confirm+ok@megatron.ietf.org; Wed, 05 Dec 2007 17:55:45 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J039c-0004Wi-UO for discuss@apps.ietf.org; Wed, 05 Dec 2007 17:55:44 -0500 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J039b-0005wS-Jf for discuss@apps.ietf.org; Wed, 05 Dec 2007 17:55:44 -0500 Received: from totoro.qualcomm.com (totoro.qualcomm.com [129.46.61.158]) by ithilien.qualcomm.com (8.14.2/8.12.5/1.0) with ESMTP id lB5Mtgfl011320 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 5 Dec 2007 14:55:42 -0800 Received: from dhcp-407d.ietf70.org (vpn-10-50-16-21.qualcomm.com [10.50.16.21]) by totoro.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id lB5MtS1g013500; Wed, 5 Dec 2007 14:55:36 -0800 (PST) Mime-Version: 1.0 Message-Id: In-Reply-To: <4756C14D.5080407@cs.utk.edu> References: <20071203094351.GA19449@nic.fr> <2639.1196720643.545129@peirce.dave.cridland.net> <20071204161659.GA19161@nic.fr> <2639.1196812257.522519@peirce.dave.cridland.net> <4755EF6C.8060703@cs.utk.edu> <2639.1196849327.522853@peirce.dave.cridland.net> <4756C14D.5080407@cs.utk.edu> X-Mailer: Eudora for Mac OS X X-message-flag: Warning: Outlook in use. Upgrade to Eudora: Date: Wed, 5 Dec 2007 14:51:01 -0800 To: Keith Moore , Dave Cridland From: Randall Gellens Subject: Re: I-D Action:draft-newman-email-subaddr-01.txt Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Random-Sig-Tag: 1.0b28 X-Spam-Score: -4.0 (----) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: Apps Discuss X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org At 7:18 AM -0800 12/5/07, Keith Moore wrote: > I am dubious that MUAs or users should assume that > there's a relationship between the subaddress and the name of the folder > where that mail ends up. at least I've found good reasons for them not > to be the same. though admittedly that makes for a more complex user > interface. Yes -- it is better to think of them as a general ability to tag inbound mail for some sort of special processing. The fact that some delivery agents have a default rule of delivering into a mailbox whose name exactly matches the detail part is merely an optimization. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly-selected tag: --------------- A bird in the hand is safer than one overhead. From discuss-bounces@apps.ietf.org Wed Dec 05 19:09:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J04Iv-00065w-EQ; Wed, 05 Dec 2007 19:09:25 -0500 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1J04Iu-00062v-HK for discuss-confirm+ok@megatron.ietf.org; Wed, 05 Dec 2007 19:09:24 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J04Iu-00061o-7N for discuss@apps.ietf.org; Wed, 05 Dec 2007 19:09:24 -0500 Received: from sparkle.rodents.montreal.qc.ca ([216.46.5.7]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J04It-0004Zm-Os for discuss@apps.ietf.org; Wed, 05 Dec 2007 19:09:24 -0500 Received: (from mouse@localhost) by Sparkle.Rodents.Montreal.QC.CA (8.8.8/8.8.8) id TAA28323; Wed, 5 Dec 2007 19:09:21 -0500 (EST) From: der Mouse Message-Id: <200712060009.TAA28323@Sparkle.Rodents.Montreal.QC.CA> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Erik-Conspiracy: There is no Conspiracy - and if there were I wouldn't be part of it anyway. X-Message-Flag: Microsoft: the company who gave us the botnet zombies. Date: Wed, 5 Dec 2007 18:58:55 -0500 (EST) To: discuss@apps.ietf.org Subject: Re: I-D Action:draft-newman-email-subaddr-01.txt In-Reply-To: References: <20071203094351.GA19449@nic.fr> <2639.1196720643.545129@peirce.dave.cridland.net> <20071204161659.GA19161@nic.fr> <2639.1196812257.522519@peirce.dave.cridland.net> <4755EF6C.8060703@cs.utk.edu> <2639.1196849327.522853@peirce.dave.cridland.net> X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org >> Whereas, if the MLM is explicitly told that the convention is in use >> within the ADMD (at least for this subscriber), This raises another hazard of a convention like this: it can lead to things like MLMs assuming that anything with a + (or whatever deliminiter is chosen) is an instance of this convention, leading to severe brokenness when faced with addresses at a site that doesn't work that way. FWIMBW, I'd prefer to see emphasis on the "nobody but the receiver and those with out-of-band knowledge of the receiver have any business assuming anything about local-parts" aspect. If my system happens to have an address with local-part *^%+_!^! (or, more plausibly, one+two) nobody without special knowledge of my system has any business inferring any structure from that; in particular, inferring that local-parts *^% (or one, respectively) even exist, much less bear any relationship to the full form, is broken - absent, of course, specific out-of-band reason to think the relevant mailer uses plussed addresses. >> That said, it has been suggested that MLMs might want to go a step >> further, and rewrite messages such that a message from >> copied to a mailing list which has a >> (Subaddress-enabled) subscriber of would >> cause the MLM to go as far as rewriting headers to the subscribed >> address. > This makes me nervous. Me too. Your reason strikes me as valid, but I'm actually more worried that implementors will lose that "(subaddress-enabled)" part and simply assume subaddresses - after all, it's Standard, right? - and end up sending mail to the wrong places. /~\ The ASCII der Mouse \ / Ribbon Campaign X Against HTML mouse@rodents.montreal.qc.ca / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B From discuss-bounces@apps.ietf.org Wed Dec 05 20:21:56 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J05Q9-00023G-Gc; Wed, 05 Dec 2007 20:20:57 -0500 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1J05Q8-000233-3d for discuss-confirm+ok@megatron.ietf.org; Wed, 05 Dec 2007 20:20:56 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J05Q7-00022v-QJ for discuss@apps.ietf.org; Wed, 05 Dec 2007 20:20:55 -0500 Received: from nj300815-nj-outbound.net.avaya.com ([198.152.12.100] helo=nj300815-nj-outbound.avaya.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J05Q6-0002Ll-Cd for discuss@apps.ietf.org; Wed, 05 Dec 2007 20:20:55 -0500 X-IronPort-AV: E=Sophos;i="4.23,257,1194238800"; d="scan'208";a="83728293" Received: from 5.7.8.135.in-addr.arpa (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by nj300815-nj-outbound.avaya.com with ESMTP; 05 Dec 2007 20:20:49 -0500 X-IronPort-AV: E=Sophos;i="4.23,257,1194238800"; d="scan'208";a="137426495" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.16]) by co300216-co-erhwest-out.avaya.com with ESMTP; 05 Dec 2007 20:20:48 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: FW: [NGO] Thursday Adhoc Discussion on Requirements for ModellingNetconf Content Date: Thu, 6 Dec 2007 02:20:45 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NGO] Thursday Adhoc Discussion on Requirements for ModellingNetconf Content Thread-Index: Acg3pf0G8P4esZDDQkasNhtbkq8CCAAADf4w From: "Romascanu, Dan (Dan)" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org =20 =20 -----Original Message----- From: Sharon Chisholm [mailto:schishol@nortel.com]=20 Sent: Thursday, December 06, 2007 3:19 AM To: ngo@ietf.org Subject: [NGO] Thursday Adhoc Discussion on Requirements for ModellingNetconf Content Hi There is a proposal for an adhoc meeting Thursday at 9 am for those interested in starting to capture the requirements for the framework for defining NETCONF content. I propose we meet at 9am at the message board and then proceed from there. I would also propose that in this first session we focus on understanding and capturing the requirements and defer prioritizing and pruning for a second pass.=20 Sharon Chisholm Nortel Ottawa, Ontario Canada _______________________________________________ NGO mailing list NGO@ietf.org https://www1.ietf.org/mailman/listinfo/ngo From discuss-bounces@apps.ietf.org Thu Dec 06 14:04:32 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0M0Y-0006Gd-Qc; Thu, 06 Dec 2007 14:03:38 -0500 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1J0M0X-00066e-5s for discuss-confirm+ok@megatron.ietf.org; Thu, 06 Dec 2007 14:03:37 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0M0W-00064D-Qi for discuss@apps.ietf.org; Thu, 06 Dec 2007 14:03:36 -0500 Received: from ppsw-1.csi.cam.ac.uk ([131.111.8.131]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J0M0T-0008Nd-61 for discuss@apps.ietf.org; Thu, 06 Dec 2007 14:03:36 -0500 X-Cam-SpamDetails: Not scanned X-Cam-AntiVirus: No virus found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-1.csi.cam.ac.uk ([131.111.8.51]:51565) by ppsw-1.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.151]:25) with esmtpa (EXTERNAL:fanf2) id 1J0M0R-00072w-5I (Exim 4.67) (return-path ); Thu, 06 Dec 2007 19:03:31 +0000 Received: from fanf2 (helo=localhost) by hermes-1.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1J0M0R-000498-KD (Exim 4.67) (return-path ); Thu, 06 Dec 2007 19:03:31 +0000 Date: Thu, 6 Dec 2007 19:03:31 +0000 From: Tony Finch X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk To: discuss@apps.ietf.org Subject: interop problems with getaddrinfo() address selection Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: Ian Jackson X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org Rule 9 of RFC 3484 specifies that the IP addresses (v4 and v6) returned by getaddrinfo() should be sorted according to the size of their common prefix with the local host's chosen source IP address. This defeats DNS round robin load balancing which has led to some severe operational problems. DNS round robin needs to be documented in an RFC, and RFC 3484 should be updated with rule 9 deleted or substantially modified for compatibility with DNS round robin. Ian Jackson has written a thorough description of the problem from the perspective of a proposal that Debian's version of glibc should have the troublesome sorting behaviour removed: http://lists.debian.org/debian-ctte/2007/11/msg00029.html FreeBSD's getaddrinfo() only implements Rule 9 if the kernel's address selection policy is configured, which is not done by default so DNS round robin is honoured. [I originally posted this to the dnsop WG list, but they don't seem to understand or care about the problem...] Tony. -- f.a.n.finch http://dotat.at/ SOLE LUNDY FASTNET: WEST VEERING NORTHWEST 6 TO GALE 8, INCREASING GALE 8 TO STORM 10 FOR A TIME. VERY ROUGH OR HIGH. RAIN OR SQUALLY SHOWERS. MODERATE OR GOOD. From discuss-bounces@apps.ietf.org Thu Dec 06 15:21:12 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0NCl-0002sE-EM; Thu, 06 Dec 2007 15:20:19 -0500 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1J0NCk-0002qd-02 for discuss-confirm+ok@megatron.ietf.org; Thu, 06 Dec 2007 15:20:18 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0NCj-0002qV-Mq for discuss@apps.ietf.org; Thu, 06 Dec 2007 15:20:17 -0500 Received: from sparkle.rodents.montreal.qc.ca ([216.46.5.7]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J0NCi-00056Z-7J for discuss@apps.ietf.org; Thu, 06 Dec 2007 15:20:17 -0500 Received: (from mouse@localhost) by Sparkle.Rodents.Montreal.QC.CA (8.8.8/8.8.8) id PAA16213; Thu, 6 Dec 2007 15:20:14 -0500 (EST) From: der Mouse Message-Id: <200712062020.PAA16213@Sparkle.Rodents.Montreal.QC.CA> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Erik-Conspiracy: There is no Conspiracy - and if there were I wouldn't be part of it anyway. X-Message-Flag: Microsoft: the company who gave us the botnet zombies. Date: Thu, 6 Dec 2007 15:18:52 -0500 (EST) To: discuss@apps.ietf.org Subject: Re: interop problems with getaddrinfo() address selection In-Reply-To: References: X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org > Rule 9 of RFC 3484 specifies that the IP addresses (v4 and v6) > returned by getaddrinfo() should be sorted according to the size of > their common prefix with the local host's chosen source IP address. > This defeats DNS round robin load balancing which has led to some > severe operational problems. I'm interseted in what sort of problems it causes. It sounds reasonable to me, which means there's something operationally important I'm missing. Can you explain, or do you have a reference to somewhere I can read about it? /~\ The ASCII der Mouse \ / Ribbon Campaign X Against HTML mouse@rodents.montreal.qc.ca / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B From discuss-bounces@apps.ietf.org Fri Dec 07 12:47:08 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0hH6-0003Gb-Qs; Fri, 07 Dec 2007 12:46:08 -0500 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1J0hH6-0003GS-3i for discuss-confirm+ok@megatron.ietf.org; Fri, 07 Dec 2007 12:46:08 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0hH5-0003GK-QW for discuss@apps.ietf.org; Fri, 07 Dec 2007 12:46:07 -0500 Received: from ppsw-6.csi.cam.ac.uk ([131.111.8.136]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J0hH4-0005F5-Co for discuss@apps.ietf.org; Fri, 07 Dec 2007 12:46:07 -0500 X-Cam-SpamDetails: Not scanned X-Cam-AntiVirus: No virus found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-1.csi.cam.ac.uk ([131.111.8.51]:49231) by ppsw-6.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.156]:25) with esmtpa (EXTERNAL:fanf2) id 1J0hGz-0005bZ-MW (Exim 4.67) (return-path ); Fri, 07 Dec 2007 17:46:01 +0000 Received: from fanf2 (helo=localhost) by hermes-1.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1J0hGz-0005mj-VE (Exim 4.67) (return-path ); Fri, 07 Dec 2007 17:46:01 +0000 Date: Fri, 7 Dec 2007 17:46:01 +0000 From: Tony Finch X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk To: der Mouse Subject: Re: interop problems with getaddrinfo() address selection In-Reply-To: <200712062020.PAA16213@Sparkle.Rodents.Montreal.QC.CA> Message-ID: References: <200712062020.PAA16213@Sparkle.Rodents.Montreal.QC.CA> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: -4.0 (----) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: discuss@apps.ietf.org X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org On Thu, 6 Dec 2007, der Mouse wrote: > > I'm interseted in what sort of problems it causes. DNS round robin is effective at balancing load evenly across multiple servers, because each client is (in effect) directed to one of the servers at random. If the client sorts the DNS response before using it then the randomization is defeated and the load on the servers is no longer balanced. Ian's message described the problem briefly in point 12, but I forgive you for not reading it :-) Tony. -- f.a.n.finch http://dotat.at/ GERMAN BIGHT HUMBER THAMES DOVER: WEST OR NORTHWEST 7 TO SEVERE GALE 9,BACKING SOUTHWEST 5 OR 6. VERY ROUGH DECREASING ROUGH. SHOWERS, RAIN LATER. GOOD BECOMING MODERATE. From discuss-bounces@apps.ietf.org Fri Dec 07 13:29:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0hwS-0001Hr-WF; Fri, 07 Dec 2007 13:28:53 -0500 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1J0hwS-0001Hc-4Q for discuss-confirm+ok@megatron.ietf.org; Fri, 07 Dec 2007 13:28:52 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0hwR-0001HR-Qz for discuss@apps.ietf.org; Fri, 07 Dec 2007 13:28:51 -0500 Received: from sparkle.rodents.montreal.qc.ca ([216.46.5.7]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J0hwQ-0008U2-DG for discuss@apps.ietf.org; Fri, 07 Dec 2007 13:28:51 -0500 Received: (from mouse@localhost) by Sparkle.Rodents.Montreal.QC.CA (8.8.8/8.8.8) id NAA28966; Fri, 7 Dec 2007 13:28:47 -0500 (EST) From: der Mouse Message-Id: <200712071828.NAA28966@Sparkle.Rodents.Montreal.QC.CA> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Erik-Conspiracy: There is no Conspiracy - and if there were I wouldn't be part of it anyway. X-Message-Flag: Microsoft: the company who gave us the botnet zombies. Date: Fri, 7 Dec 2007 13:27:33 -0500 (EST) To: discuss@apps.ietf.org Subject: Re: interop problems with getaddrinfo() address selection In-Reply-To: References: <200712062020.PAA16213@Sparkle.Rodents.Montreal.QC.CA> X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org >> I'm interseted in what sort of problems it causes. > DNS round robin is effective at balancing load evenly across multiple > servers, because each client is (in effect) directed to one of the > servers at random. If the client sorts the DNS response before using > it then the randomization is defeated and the load on the servers is > no longer balanced. Doh! I knew I was missing something. (What I was missing was looking at the problem from the point of view of the servers, rather than the clients.) Thanks for the explanation. /~\ The ASCII der Mouse \ / Ribbon Campaign X Against HTML mouse@rodents.montreal.qc.ca / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B From discuss-bounces@apps.ietf.org Sat Dec 08 16:21:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J1772-0004gb-EY; Sat, 08 Dec 2007 16:21:28 -0500 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1J1772-0004gT-58 for discuss-confirm+ok@megatron.ietf.org; Sat, 08 Dec 2007 16:21:28 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J1771-0004gL-Rh for discuss@apps.ietf.org; Sat, 08 Dec 2007 16:21:27 -0500 Received: from bes.cs.utk.edu ([160.36.56.220]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J1770-0006Nj-Ib for discuss@apps.ietf.org; Sat, 08 Dec 2007 16:21:27 -0500 Received: from localhost (localhost [127.0.0.1]) by bes.cs.utk.edu (Postfix) with ESMTP id D15A110308D; Sat, 8 Dec 2007 16:21:09 -0500 (EST) X-Virus-Scanned: by amavisd-new with ClamAV and SpamAssasin at cs.utk.edu Received: from bes.cs.utk.edu ([127.0.0.1]) by localhost (bes.cs.utk.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wbn0Gj7qALDk; Sat, 8 Dec 2007 16:21:07 -0500 (EST) Received: from lust.indecency.org (m740f36d0.tmodns.net [208.54.15.116]) by bes.cs.utk.edu (Postfix) with ESMTP id 269EC103084; Sat, 8 Dec 2007 16:21:01 -0500 (EST) Message-ID: <475B0ABC.5090806@cs.utk.edu> Date: Sat, 08 Dec 2007 13:21:00 -0800 From: Keith Moore User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: Tony Finch Subject: Re: interop problems with getaddrinfo() address selection References: <200712062020.PAA16213@Sparkle.Rodents.Montreal.QC.CA> In-Reply-To: X-Enigmail-Version: 0.95.5 OpenPGP: id=E1473978 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: der Mouse , discuss@apps.ietf.org X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org Tony Finch wrote: > On Thu, 6 Dec 2007, der Mouse wrote: > >> I'm interseted in what sort of problems it causes. >> > > DNS round robin is effective at balancing load evenly across multiple > servers, because each client is (in effect) directed to one of the servers > at random. If the client sorts the DNS response before using it then the > randomization is defeated and the load on the servers is no longer > balanced. > this seems like an almost-inherent consequence of IPv6's expecting hosts to have multiple addresses and asking hosts initiating a communication to do address selection. it's not specific to getaddrinfo() - any API that tried to solve that problem would be likely to reorder addresses to some degree. though it should be possible for the client implementation to go through the list of addresses, assign a preference value to each one (based on address type and number of leading bits in common with one of the hosts's local addresses), then perform a stable sort by preference value. From discuss-bounces@apps.ietf.org Sun Dec 09 15:10:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J1STa-000812-0o; Sun, 09 Dec 2007 15:10:10 -0500 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1J1STY-00080w-3g for discuss-confirm+ok@megatron.ietf.org; Sun, 09 Dec 2007 15:10:08 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J1STX-00080o-Q0 for discuss@apps.ietf.org; Sun, 09 Dec 2007 15:10:07 -0500 Received: from ppsw-8.csi.cam.ac.uk ([131.111.8.138]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J1STW-00016M-CY for discuss@apps.ietf.org; Sun, 09 Dec 2007 15:10:07 -0500 X-Cam-SpamDetails: Not scanned X-Cam-AntiVirus: No virus found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-1.csi.cam.ac.uk ([131.111.8.51]:58334) by ppsw-8.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.158]:25) with esmtpa (EXTERNAL:fanf2) id 1J1STT-0002xZ-RB (Exim 4.67) (return-path ); Sun, 09 Dec 2007 20:10:03 +0000 Received: from fanf2 (helo=localhost) by hermes-1.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1J1STT-0001wz-DA (Exim 4.67) (return-path ); Sun, 09 Dec 2007 20:10:03 +0000 Date: Sun, 9 Dec 2007 20:10:03 +0000 From: Tony Finch X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk To: Keith Moore Subject: Re: interop problems with getaddrinfo() address selection In-Reply-To: <475B0ABC.5090806@cs.utk.edu> Message-ID: References: <200712062020.PAA16213@Sparkle.Rodents.Montreal.QC.CA> <475B0ABC.5090806@cs.utk.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: -4.0 (----) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: der Mouse , discuss@apps.ietf.org X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org On Sat, 8 Dec 2007, Keith Moore wrote: > > this seems like an almost-inherent consequence of IPv6's expecting hosts > to have multiple addresses and asking hosts initiating a communication > to do address selection. it's not specific to getaddrinfo() - any API > that tried to solve that problem would be likely to reorder addresses to > some degree. The problem isn't specific to IPv6 - for example see the comments about address selection for "multihomed" MXs in RFC 2821. However in practice we ignore this possibility and treat host names with multiple IP addresses as equally reachable at any address. I don't think IPv6 substantially changes this situation, because most of its common extra addresses have limited scope and will not be published in the DNS. > though it should be possible for the client implementation to go through > the list of addresses, assign a preference value to each one (based on > address type and number of leading bits in common with one of the > hosts's local addresses), then perform a stable sort by preference value. That's essentially what RFC 3484 recommends, and what causes the problem. Tony. -- f.a.n.finch http://dotat.at/ FORTIES: CYCLONIC 7 TO SEVERE GALE 9 BECOMING NORTHERLY 5 TO 7. ROUGH OR VERY ROUGH, OCCASIONALLY HIGH AT FIRST. RAIN OR SHOWERS. MODERATE OR GOOD. From discuss-bounces@apps.ietf.org Sun Dec 09 15:31:44 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J1SoR-0004hh-7d; Sun, 09 Dec 2007 15:31:43 -0500 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1J1SoQ-0004hb-C4 for discuss-confirm+ok@megatron.ietf.org; Sun, 09 Dec 2007 15:31:42 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J1SoP-0004hL-VY for discuss@apps.ietf.org; Sun, 09 Dec 2007 15:31:41 -0500 Received: from m1.imap-partners.net ([64.13.152.131]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J1SoN-0001if-KC for discuss@apps.ietf.org; Sun, 09 Dec 2007 15:31:41 -0500 Received: from lust.indecency.org (m650f36d0.tmodns.net [208.54.15.101]) by m1.imap-partners.net (MOS 3.8.4-GA) with ESMTP id AIE70932 (AUTH admin@network-heretics.com); Sun, 9 Dec 2007 12:30:00 -0800 (PST) Message-ID: <475C5047.3010807@cs.utk.edu> Date: Sun, 09 Dec 2007 12:29:59 -0800 From: Keith Moore User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: Tony Finch Subject: Re: interop problems with getaddrinfo() address selection References: <200712062020.PAA16213@Sparkle.Rodents.Montreal.QC.CA> <475B0ABC.5090806@cs.utk.edu> In-Reply-To: X-Enigmail-Version: 0.95.5 OpenPGP: id=E1473978 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Cc: der Mouse , discuss@apps.ietf.org X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org Tony Finch wrote: > On Sat, 8 Dec 2007, Keith Moore wrote: > >> this seems like an almost-inherent consequence of IPv6's expecting hosts >> to have multiple addresses and asking hosts initiating a communication >> to do address selection. it's not specific to getaddrinfo() - any API >> that tried to solve that problem would be likely to reorder addresses to >> some degree. >> > > The problem isn't specific to IPv6 - for example see the comments about > address selection for "multihomed" MXs in RFC 2821. However in practice we > ignore this possibility and treat host names with multiple IP addresses as > equally reachable at any address. I don't think IPv6 substantially changes > this situation, because most of its common extra addresses have limited > scope and will not be published in the DNS. > I think it's a stretch to assume that in the future that all IP addresses associated with a domain and advertised in DNS are equally reachable. As a start IPv4 isn't going away. So a site may need to advertise both IPv4 and IPv6 addresses in order to be widely reachable, and the party initiating a connection gets to decide which is better. >From my own experience it is a good idea for a site to advertise both 6to4 and native IPv6 addresses. A 6to4 site initiating a connection will probably do better to use the destination's 6to4 address; similarly for a native site using the destination's native address. An IPv4-to-IPv4 connection is almost certainly better than a connection between a native and 6to4 IPv6 address. Then you have ULIAs which are globally unique and globally scoped but which might not be globally reachable. As long as there's an expectation that IPv6 addresses are PA, there will be a need for ULIAs. But networks using ULIAs will interconnect with other networks including those using PA space and other networks using ULIAs. Then you have mobile IP which creates additional choices, and a growing tendency for hosts to have multiple network interfaces where more than one interface can be connected to the Internet. The notion that you can control address visibility using DNS in this world is pretty much a fantasy. >> though it should be possible for the client implementation to go through >> the list of addresses, assign a preference value to each one (based on >> address type and number of leading bits in common with one of the >> hosts's local addresses), then perform a stable sort by preference value. >> > > That's essentially what RFC 3484 recommends, and what causes the problem. > What causes the problem is the assumption that a destination can have multiple addresses, a source can have multiple addresses, and the party initiating the connection can somehow make a good decision about which address pair to use without any information from the network. As for DNS randomization, it's never been reasonable to expect an application to try each of several addresses in the order returned by DNS. The fact that many apps happened to work this way (because it was often the easiest way to do things) was an accident, not something required by the DNS protocol or the defined protocol for most of those apps. Keith From discuss-bounces@apps.ietf.org Mon Dec 10 02:50:24 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J1dP5-0000qR-5D; Mon, 10 Dec 2007 02:50:15 -0500 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1J1dP3-0000qK-5x for discuss-confirm+ok@megatron.ietf.org; Mon, 10 Dec 2007 02:50:13 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J1dOx-0000qA-7t for discuss@apps.ietf.org; Mon, 10 Dec 2007 02:50:07 -0500 Received: from ppsw-0.csi.cam.ac.uk ([131.111.8.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J1dOw-0001B3-PL for discuss@apps.ietf.org; Mon, 10 Dec 2007 02:50:07 -0500 X-Cam-SpamDetails: Not scanned X-Cam-AntiVirus: No virus found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-1.csi.cam.ac.uk ([131.111.8.51]:55712) by ppsw-0.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.150]:25) with esmtpa (EXTERNAL:fanf2) id 1J1dOi-0004Gs-2S (Exim 4.67) (return-path ); Mon, 10 Dec 2007 07:49:52 +0000 Received: from fanf2 (helo=localhost) by hermes-1.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1J1dOi-000783-OG (Exim 4.67) (return-path ); Mon, 10 Dec 2007 07:49:52 +0000 Date: Mon, 10 Dec 2007 07:49:52 +0000 From: Tony Finch X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk To: Keith Moore Subject: Re: interop problems with getaddrinfo() address selection In-Reply-To: <475C5047.3010807@cs.utk.edu> Message-ID: References: <200712062020.PAA16213@Sparkle.Rodents.Montreal.QC.CA> <475B0ABC.5090806@cs.utk.edu> <475C5047.3010807@cs.utk.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: -4.0 (----) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: der Mouse , discuss@apps.ietf.org X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org On Sun, 9 Dec 2007, Keith Moore wrote: > > I think it's a stretch to assume that in the future that all IP > addresses associated with a domain and advertised in DNS are equally > reachable. The examples you listed, based on different kinds of connectivity, are reasonable; what it not is de-randomizing equivalent classes of address. > What causes the problem is the assumption that a destination can have > multiple addresses, a source can have multiple addresses, and the party > initiating the connection can somehow make a good decision about which > address pair to use without any information from the network. Yes :-) > As for DNS randomization, it's never been reasonable to expect an > application to try each of several addresses in the order returned by > DNS. That has been the de facto standard behaviour for over 10 years (though before getaddrinfo they only tried the first). A lot of sites are going to be rather upset if wide deployment of RFC 3484 suddenly breaks their service architecture. Tony. -- f.a.n.finch http://dotat.at/ DOVER: NORTHWESTERLY 6 TO GALE 8, DECREASING 4 LATER. MODERATE OR ROUGH, OCCASIONALLY VERY ROUGH. SQUALLY SHOWERS. GOOD. From discuss-bounces@apps.ietf.org Mon Dec 10 13:15:54 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J1nAQ-000717-TT; Mon, 10 Dec 2007 13:15:46 -0500 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1J1nAO-0006ks-HU for discuss-confirm+ok@megatron.ietf.org; Mon, 10 Dec 2007 13:15:44 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J1nAO-0006kk-74 for discuss@apps.ietf.org; Mon, 10 Dec 2007 13:15:44 -0500 Received: from sparkle.rodents.montreal.qc.ca ([216.46.5.7]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J1nAN-0007rr-Fv for discuss@apps.ietf.org; Mon, 10 Dec 2007 13:15:44 -0500 Received: (from mouse@localhost) by Sparkle.Rodents.Montreal.QC.CA (8.8.8/8.8.8) id NAA27674; Mon, 10 Dec 2007 13:15:41 -0500 (EST) From: der Mouse Message-Id: <200712101815.NAA27674@Sparkle.Rodents.Montreal.QC.CA> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Erik-Conspiracy: There is no Conspiracy - and if there were I wouldn't be part of it anyway. X-Message-Flag: Microsoft: the company who gave us the botnet zombies. Date: Mon, 10 Dec 2007 13:10:27 -0500 (EST) To: discuss@apps.ietf.org Subject: Re: interop problems with getaddrinfo() address selection In-Reply-To: References: <200712062020.PAA16213@Sparkle.Rodents.Montreal.QC.CA> <475B0ABC.5090806@cs.utk.edu> <475C5047.3010807@cs.utk.edu> X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org > The examples you listed, based on different kinds of connectivity, > are reasonable; what it not is de-randomizing equivalent classes of > address. But whose definition of "equivalent" applies? From a client point of view, close addresses are not equivalent to distant addresses - the client wants a nearby server, not unreasonably - making sorting by match length at least moderately reasonable. (Not entirely; routing topology doesn't necessarily parallel matching prefix length. But, absent something like AS path information, it's probably the best available approximation.) >> As for DNS randomization, it's never been reasonable to expect an >> application to try each of several addresses in the order returned >> by DNS. > A lot of sites are going to be rather upset if wide deployment of RFC > 3484 suddenly breaks their service architecture. Any architecture that depends on the DNS preserving record ordering (never mind depending on clients doing anything in particular with the order the DNS happens to give them) is already broken. /~\ The ASCII der Mouse \ / Ribbon Campaign X Against HTML mouse@rodents.montreal.qc.ca / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B From discuss-bounces@apps.ietf.org Mon Dec 10 14:46:58 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J1oad-0006yP-Ft; Mon, 10 Dec 2007 14:46:55 -0500 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1J1oac-0006vf-OK for discuss-confirm+ok@megatron.ietf.org; Mon, 10 Dec 2007 14:46:54 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J1oac-0006tQ-DN for discuss@apps.ietf.org; Mon, 10 Dec 2007 14:46:54 -0500 Received: from ppsw-6.csi.cam.ac.uk ([131.111.8.136]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J1oab-0002Dc-Rq for discuss@apps.ietf.org; Mon, 10 Dec 2007 14:46:54 -0500 X-Cam-SpamDetails: Not scanned X-Cam-AntiVirus: No virus found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-1.csi.cam.ac.uk ([131.111.8.51]:54268) by ppsw-6.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.156]:25) with esmtpa (EXTERNAL:fanf2) id 1J1oaa-0000MK-Js (Exim 4.67) (return-path ); Mon, 10 Dec 2007 19:46:52 +0000 Received: from fanf2 (helo=localhost) by hermes-1.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1J1oaa-0001JN-4o (Exim 4.67) (return-path ); Mon, 10 Dec 2007 19:46:52 +0000 Date: Mon, 10 Dec 2007 19:46:52 +0000 From: Tony Finch X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk To: der Mouse Subject: Re: interop problems with getaddrinfo() address selection In-Reply-To: <200712101815.NAA27674@Sparkle.Rodents.Montreal.QC.CA> Message-ID: References: <200712062020.PAA16213@Sparkle.Rodents.Montreal.QC.CA> <475B0ABC.5090806@cs.utk.edu> <475C5047.3010807@cs.utk.edu> <200712101815.NAA27674@Sparkle.Rodents.Montreal.QC.CA> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: -4.0 (----) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: discuss@apps.ietf.org X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org On Mon, 10 Dec 2007, der Mouse wrote: > > But whose definition of "equivalent" applies? From a client point of > view, close addresses are not equivalent to distant addresses - the > client wants a nearby server, not unreasonably - making sorting by > match length at least moderately reasonable. In practice, services advertise server-specific names as well as umbrella names, so that clients that care about which server they use can ask for it. > Any architecture that depends on the DNS preserving record ordering > (never mind depending on clients doing anything in particular with the > order the DNS happens to give them) is already broken. Services that use round robin DNS do not depend on preserved record ordering: quite the opposite, they depend on disordering. (Bind does round-robin when acting as a cache as well as an authoritative server.) You can claim it's broken until you are blue in the face, but it works in practice and it is widely documented (though not by the IETF) without caveats. Tony. -- f.a.n.finch http://dotat.at/ TYNE DOGGER: NORTHERLY 5 TO 7 BECOMING VARIABLE 4. ROUGH OR VERY ROUGH DECREASING MODERATE OR ROUGH. SHOWERS. MAINLY GOOD. From discuss-bounces@apps.ietf.org Mon Dec 10 18:11:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J1rmd-0005rm-St; Mon, 10 Dec 2007 18:11:31 -0500 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1J1rmc-0005rd-8Z for discuss-confirm+ok@megatron.ietf.org; Mon, 10 Dec 2007 18:11:30 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J1rmb-0005rV-VD for discuss@apps.ietf.org; Mon, 10 Dec 2007 18:11:29 -0500 Received: from sparkle.rodents.montreal.qc.ca ([216.46.5.7]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J1rma-0007CJ-Bs for discuss@apps.ietf.org; Mon, 10 Dec 2007 18:11:29 -0500 Received: (from mouse@localhost) by Sparkle.Rodents.Montreal.QC.CA (8.8.8/8.8.8) id SAA01012; Mon, 10 Dec 2007 18:11:26 -0500 (EST) Date: Mon, 10 Dec 2007 18:11:26 -0500 (EST) From: der Mouse Message-Id: <200712102311.SAA01012@Sparkle.Rodents.Montreal.QC.CA> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Erik-Conspiracy: There is no Conspiracy - and if there were I wouldn't be part of it anyway. X-Message-Flag: Microsoft: the company who gave us the botnet zombies. To: discuss@apps.ietf.org Subject: Re: interop problems with getaddrinfo() address selection In-Reply-To: References: <200712062020.PAA16213@Sparkle.Rodents.Montreal.QC.CA> <475B0ABC.5090806@cs.utk.edu> <475C5047.3010807@cs.utk.edu> <200712101815.NAA27674@Sparkle.Rodents.Montreal.QC.CA> X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org > Services that use round robin DNS do not depend on preserved record > ordering: quite the opposite, they depend on disordering. Hmm? It appears we're talking about differnet things. To me, DNS round-robin refers to the sort of thing the NTP pool project does: rotating the answer(s) returned in response to a query through a larger (usually much larger) set of possible answers. It sounds as though you're talking about simply returning all the answers and hoping that, somewhere along the line, someone will end up choosing one in a way that looks random with respect to the property you care about. For example, see this next quote, which makes sense only for the latter meaning of "round-robin": > (Bind does round-robin when acting as a cache as well as an > authoritative server.) Thanks for making my point for me :-) - this indicates that you can't depend on a caching server preserving the order (or disorder, for that matter) of records it receives from elsewhere. Round-robin - this kind - is not broken per se. Depending on it for correctness (as opposed to efficiency) is - you cannot count on arm's-length DNS servers doing anything you want, be it preserving or disturbing, with the order of RRs handed to it. If your setup depends on spreading the load over multiple servers, then you really need to return different addresses to different queries, not just the same addresses in different orders. > You can claim it's broken until you are blue in the face, but it > works in practice and it is widely documented (though not by the > IETF) without caveats. Whey I say it's broken to depend on it, what I mean is, it may "work", but if/when it fails, it's _your_ bug, and it's unreasonable to expect others to change to work around it. Documentation implying otherwise may exist, but, if so, it's wrong. 1034 section 3.6: "The order of RRs in a set is not significant, and need not be preserved by name servers, resolvers, or other parts of the DNS.". 5.2.1 item 1: "Since the DNS does not preserve the order of RRs," - the rest of this particular quote is actually relevant to the issue that started this thread: "...[name to address translation] may choose to sort the returned addresses...". /~\ The ASCII der Mouse \ / Ribbon Campaign X Against HTML mouse@rodents.montreal.qc.ca / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B From discuss-bounces@apps.ietf.org Mon Dec 10 19:34:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J1t4m-0003ER-FL; Mon, 10 Dec 2007 19:34:20 -0500 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1J1t4l-0003EF-KO for discuss-confirm+ok@megatron.ietf.org; Mon, 10 Dec 2007 19:34:19 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J1t4l-0003E5-Ag for discuss@apps.ietf.org; Mon, 10 Dec 2007 19:34:19 -0500 Received: from m1.imap-partners.net ([64.13.152.131]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J1t4j-0000tB-IB for discuss@apps.ietf.org; Mon, 10 Dec 2007 19:34:19 -0500 Received: from lust.indecency.org ([168.103.150.1]) by m1.imap-partners.net (MOS 3.8.4-GA) with ESMTP id AIG38618 (AUTH admin@network-heretics.com); Mon, 10 Dec 2007 16:32:41 -0800 (PST) Message-ID: <475DDAA7.3060308@cs.utk.edu> Date: Mon, 10 Dec 2007 16:32:39 -0800 From: Keith Moore User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: der Mouse Subject: Re: interop problems with getaddrinfo() address selection References: <200712062020.PAA16213@Sparkle.Rodents.Montreal.QC.CA> <475B0ABC.5090806@cs.utk.edu> <475C5047.3010807@cs.utk.edu> <200712101815.NAA27674@Sparkle.Rodents.Montreal.QC.CA> <200712102311.SAA01012@Sparkle.Rodents.Montreal.QC.CA> In-Reply-To: <200712102311.SAA01012@Sparkle.Rodents.Montreal.QC.CA> X-Enigmail-Version: 0.95.5 OpenPGP: id=E1473978 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: discuss@apps.ietf.org X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org der Mouse wrote: >> Services that use round robin DNS do not depend on preserved record >> ordering: quite the opposite, they depend on disordering. >> > > Hmm? It appears we're talking about differnet things. To me, DNS > round-robin refers to the sort of thing the NTP pool project does: > rotating the answer(s) returned in response to a query through a larger > (usually much larger) set of possible answers. It sounds as though > you're talking about simply returning all the answers and hoping that, > somewhere along the line, someone will end up choosing one in a way > that looks random with respect to the property you care about. > mumble. if what the site really wants it for the client to pick an address at random, then having something besides the DNS server randomize the order of the results doesn't matter so much. (but if the client sorts the addresses, the randomness is lost regardless of how many random reorderings were imposed between DNS and the client). on the other hand, if the site is trying to do dynamic load-balancing with DNS by having DNS favor lightly-used servers, then reordering does matter. >> You can claim it's broken until you are blue in the face, but it >> works in practice and it is widely documented (though not by the >> IETF) without caveats. >> > > Whey I say it's broken to depend on it, what I mean is, it may "work", > but if/when it fails, it's _your_ bug, and it's unreasonable to expect > others to change to work around it. Documentation implying otherwise > may exist, but, if so, it's wrong. 1034 section 3.6: "The order of RRs > in a set is not significant, and need not be preserved by name servers, > resolvers, or other parts of the DNS.". 5.2.1 item 1: "Since the DNS > does not preserve the order of RRs," - the rest of this particular > quote is actually relevant to the issue that started this thread: > "...[name to address translation] may choose to sort the returned > addresses..." you and I (and I expect Tony also) agree on that. but practically speaking it makes little difference. if a feature that used to "work" in IPv4 (even if by coincidence or accident) fails to work in IPv6, IPv6 will get blamed. and this may hinder adoption of IPv6. most of the people affected by this won't bother to read through the RFCs to see who is really to blame. Keith From discuss-bounces@apps.ietf.org Tue Dec 11 04:48:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J21iR-0008G5-G5; Tue, 11 Dec 2007 04:47:51 -0500 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1J21iQ-00089p-El for discuss-confirm+ok@megatron.ietf.org; Tue, 11 Dec 2007 04:47:50 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J21iQ-000878-2C for discuss@apps.ietf.org; Tue, 11 Dec 2007 04:47:50 -0500 Received: from mx2.nic.fr ([192.134.4.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J21iN-000440-RX for discuss@apps.ietf.org; Tue, 11 Dec 2007 04:47:50 -0500 Received: from mx2.nic.fr (localhost [127.0.0.1]) by mx2.nic.fr (Postfix) with SMTP id A4E721C00FA; Tue, 11 Dec 2007 10:47:46 +0100 (CET) Received: from relay2.nic.fr (relay2.nic.fr [192.134.4.163]) by mx2.nic.fr (Postfix) with ESMTP id A04431C00F3; Tue, 11 Dec 2007 10:47:46 +0100 (CET) Received: from bortzmeyer.nic.fr (batilda.nic.fr [192.134.4.69]) by relay2.nic.fr (Postfix) with ESMTP id 9D13182FB01; Tue, 11 Dec 2007 10:47:46 +0100 (CET) Date: Tue, 11 Dec 2007 10:47:46 +0100 From: Stephane Bortzmeyer To: Keith Moore Subject: Re: interop problems with getaddrinfo() address selection Message-ID: <20071211094746.GA29759@nic.fr> References: <200712062020.PAA16213@Sparkle.Rodents.Montreal.QC.CA> <475B0ABC.5090806@cs.utk.edu> <475C5047.3010807@cs.utk.edu> <200712101815.NAA27674@Sparkle.Rodents.Montreal.QC.CA> <200712102311.SAA01012@Sparkle.Rodents.Montreal.QC.CA> <475DDAA7.3060308@cs.utk.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <475DDAA7.3060308@cs.utk.edu> X-Operating-System: Debian GNU/Linux 4.0 X-Kernel: Linux 2.6.18-5-686 i686 Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: Mutt/1.5.13 (2006-08-11) X-Spam-Score: -4.0 (----) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Cc: discuss@apps.ietf.org X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org On Mon, Dec 10, 2007 at 04:32:39PM -0800, Keith Moore wrote a message of 47 lines which said: > on the other hand, if the site is trying to do dynamic > load-balancing with DNS by having DNS favor lightly-used servers, There is a standard way for a site to do this sort of "DNS engineering" and it is SRV (RFC 2782). Everything else can be only a hack since, as explained, the DNS and the subsequent libraries cannot guarantee anything about the order of addresses. From discuss-bounces@apps.ietf.org Tue Dec 11 05:40:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J22Ww-0004yB-4H; Tue, 11 Dec 2007 05:40:02 -0500 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1J22Wv-0004xu-Mw for discuss-confirm+ok@megatron.ietf.org; Tue, 11 Dec 2007 05:40:01 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J22Wv-0004xg-DA for discuss@apps.ietf.org; Tue, 11 Dec 2007 05:40:01 -0500 Received: from ppsw-7.csi.cam.ac.uk ([131.111.8.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J22Wu-00054p-Sa for discuss@apps.ietf.org; Tue, 11 Dec 2007 05:40:01 -0500 X-Cam-SpamDetails: Not scanned X-Cam-AntiVirus: No virus found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-1.csi.cam.ac.uk ([131.111.8.51]:35006) by ppsw-7.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.157]:25) with esmtpa (EXTERNAL:fanf2) id 1J22Wr-0001Ad-P4 (Exim 4.67) (return-path ); Tue, 11 Dec 2007 10:39:57 +0000 Received: from fanf2 (helo=localhost) by hermes-1.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1J22Wr-0001GC-OO (Exim 4.67) (return-path ); Tue, 11 Dec 2007 10:39:57 +0000 Date: Tue, 11 Dec 2007 10:39:57 +0000 From: Tony Finch X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk To: der Mouse Subject: Re: interop problems with getaddrinfo() address selection In-Reply-To: <200712102311.SAA01012@Sparkle.Rodents.Montreal.QC.CA> Message-ID: References: <200712062020.PAA16213@Sparkle.Rodents.Montreal.QC.CA> <475B0ABC.5090806@cs.utk.edu> <475C5047.3010807@cs.utk.edu> <200712101815.NAA27674@Sparkle.Rodents.Montreal.QC.CA> <200712102311.SAA01012@Sparkle.Rodents.Montreal.QC.CA> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: -4.0 (----) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: discuss@apps.ietf.org X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org On Mon, 10 Dec 2007, der Mouse wrote: > > It appears we're talking about differnet things. To me, DNS round-robin > refers to the sort of thing the NTP pool project does: rotating the > answer(s) returned in response to a query through a larger (usually much > larger) set of possible answers. That's incompatible with RFC 2181 section 5 and DNSSEC. > It sounds as though you're talking about simply returning all the > answers and hoping that, somewhere along the line, someone will end up > choosing one in a way that looks random with respect to the property you > care about. Right. Tony. -- f.a.n.finch http://dotat.at/ VIKING NORTH UTSIRE SOUTH UTSIRE FORTIES: NORTHWEST 5 OR 6, BECOMING VARIABLE 3 OR 4, THEN BECOMING SOUTH 5 TO 7, PERHAPS GALE 8 LATER IN VIKING. MODERATE OR ROUGH. SHOWERS. GOOD. From discuss-bounces@apps.ietf.org Tue Dec 11 09:30:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2689-0007k7-1A; Tue, 11 Dec 2007 09:30:41 -0500 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1J2687-0007eM-1j for discuss-confirm+ok@megatron.ietf.org; Tue, 11 Dec 2007 09:30:39 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2686-0007eB-O2 for discuss@apps.ietf.org; Tue, 11 Dec 2007 09:30:38 -0500 Received: from sparkle.rodents.montreal.qc.ca ([216.46.5.7]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J2685-0001Q8-7E for discuss@apps.ietf.org; Tue, 11 Dec 2007 09:30:38 -0500 Received: (from mouse@localhost) by Sparkle.Rodents.Montreal.QC.CA (8.8.8/8.8.8) id JAA08747; Tue, 11 Dec 2007 09:30:36 -0500 (EST) From: der Mouse Message-Id: <200712111430.JAA08747@Sparkle.Rodents.Montreal.QC.CA> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Erik-Conspiracy: There is no Conspiracy - and if there were I wouldn't be part of it anyway. X-Message-Flag: Microsoft: the company who gave us the botnet zombies. Date: Tue, 11 Dec 2007 09:26:31 -0500 (EST) To: discuss@apps.ietf.org Subject: Re: interop problems with getaddrinfo() address selection In-Reply-To: References: <200712062020.PAA16213@Sparkle.Rodents.Montreal.QC.CA> <475B0ABC.5090806@cs.utk.edu> <475C5047.3010807@cs.utk.edu> <200712101815.NAA27674@Sparkle.Rodents.Montreal.QC.CA> <200712102311.SAA01012@Sparkle.Rodents.Montreal.QC.CA> X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org >> It appears we're talking about differnet things. To me, DNS >> round-robin refers to the sort of thing the NTP pool project does: >> rotating the answer(s) returned in response to a query through a >> larger (usually much larger) set of possible answers. > That's incompatible with RFC 2181 section 5 I read through 2181 section 5 and the only thing I see that seems plausible to me as what you're talking about is 5.1: "A query for a specific (or non-specific) label, class, and type, will always return all records in the associated RRSet". All you need to do here is hold your mind a little differently - think of it as changing the RRset instead of returning only some of the records from an unchanging RRset. > and DNSSEC. (a) I don't see how it could be, assuming the mental attitude mentioned above (a small changing RRset instead of part of a large static RRset). (b) So, don't sign such records. :-) /~\ The ASCII der Mouse \ / Ribbon Campaign X Against HTML mouse@rodents.montreal.qc.ca / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B From discuss-bounces@apps.ietf.org Tue Dec 11 13:31:54 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J29tS-000853-IL; Tue, 11 Dec 2007 13:31:46 -0500 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1J29tR-00084x-Ib for discuss-confirm+ok@megatron.ietf.org; Tue, 11 Dec 2007 13:31:45 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J29tR-00084n-8m for discuss@apps.ietf.org; Tue, 11 Dec 2007 13:31:45 -0500 Received: from m1.imap-partners.net ([64.13.152.131]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J29tQ-0006pY-SZ for discuss@apps.ietf.org; Tue, 11 Dec 2007 13:31:45 -0500 Received: from lust.indecency.org (12-46-55-205.seatac.seattwa.wayport.net [12.46.55.205]) by m1.imap-partners.net (MOS 3.8.4-GA) with ESMTP id AIH35450 (AUTH admin@network-heretics.com) for discuss@apps.ietf.org; Tue, 11 Dec 2007 10:31:41 -0800 (PST) Message-ID: <475ED78A.2070608@network-heretics.com> Date: Tue, 11 Dec 2007 10:31:38 -0800 From: Keith Moore User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: Stephane Bortzmeyer Subject: Re: interop problems with getaddrinfo() address selection References: <200712062020.PAA16213@Sparkle.Rodents.Montreal.QC.CA> <475B0ABC.5090806@cs.utk.edu> <475C5047.3010807@cs.utk.edu> <200712101815.NAA27674@Sparkle.Rodents.Montreal.QC.CA> <200712102311.SAA01012@Sparkle.Rodents.Montreal.QC.CA> <475DDAA7.3060308@cs.utk.edu> <20071211094746.GA29759@nic.fr> In-Reply-To: <20071211094746.GA29759@nic.fr> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: discuss@apps.ietf.org X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org >> on the other hand, if the site is trying to do dynamic >> load-balancing with DNS by having DNS favor lightly-used servers, >> > > There is a standard way for a site to do this sort of "DNS > engineering" and it is SRV (RFC 2782). Per RFC 2782, SRV only applies to protocols that are specified to use it. Even then, it's not clear that SRV is good for dynamic load balancing. Keith From discuss-bounces@apps.ietf.org Tue Dec 11 13:33:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J29vG-0001Vr-FM; Tue, 11 Dec 2007 13:33:38 -0500 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1J29vE-0001Iq-Gk for discuss-confirm+ok@megatron.ietf.org; Tue, 11 Dec 2007 13:33:36 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J29vE-0001Ic-6X for discuss@apps.ietf.org; Tue, 11 Dec 2007 13:33:36 -0500 Received: from m1.imap-partners.net ([64.13.152.131]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J29vB-0006rn-V9 for discuss@apps.ietf.org; Tue, 11 Dec 2007 13:33:36 -0500 Received: from lust.indecency.org (12-46-55-205.seatac.seattwa.wayport.net [12.46.55.205]) by m1.imap-partners.net (MOS 3.8.4-GA) with ESMTP id AIH35620 (AUTH admin@network-heretics.com) for discuss@apps.ietf.org; Tue, 11 Dec 2007 10:33:32 -0800 (PST) Message-ID: <475ED7F9.3060703@network-heretics.com> Date: Tue, 11 Dec 2007 10:33:29 -0800 From: Keith Moore User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: der Mouse Subject: Re: interop problems with getaddrinfo() address selection References: <200712062020.PAA16213@Sparkle.Rodents.Montreal.QC.CA> <475B0ABC.5090806@cs.utk.edu> <475C5047.3010807@cs.utk.edu> <200712101815.NAA27674@Sparkle.Rodents.Montreal.QC.CA> <200712102311.SAA01012@Sparkle.Rodents.Montreal.QC.CA> <200712111430.JAA08747@Sparkle.Rodents.Montreal.QC.CA> In-Reply-To: <200712111430.JAA08747@Sparkle.Rodents.Montreal.QC.CA> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: discuss@apps.ietf.org X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org >>> It appears we're talking about differnet things. To me, DNS >>> round-robin refers to the sort of thing the NTP pool project does: >>> rotating the answer(s) returned in response to a query through a >>> larger (usually much larger) set of possible answers. >>> >> That's incompatible with RFC 2181 section 5 >> > > I read through 2181 section 5 and the only thing I see that seems > plausible to me as what you're talking about is 5.1: "A query for a > specific (or non-specific) label, class, and type, will always return > all records in the associated RRSet". > > All you need to do here is hold your mind a little differently - think > of it as changing the RRset instead of returning only some of the > records from an unchanging RRset. > which is fine if and only if it increments the zone serial # each time. Keith From discuss-bounces@apps.ietf.org Tue Dec 11 13:36:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J29yV-0007WH-GZ; Tue, 11 Dec 2007 13:36:59 -0500 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1J29yV-0007WC-2o for discuss-confirm+ok@megatron.ietf.org; Tue, 11 Dec 2007 13:36:59 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J29yU-0007W3-PI for discuss@apps.ietf.org; Tue, 11 Dec 2007 13:36:58 -0500 Received: from m1.imap-partners.net ([64.13.152.131]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J29yU-0006xb-GZ for discuss@apps.ietf.org; Tue, 11 Dec 2007 13:36:58 -0500 Received: from lust.indecency.org (12-46-55-205.seatac.seattwa.wayport.net [12.46.55.205]) by m1.imap-partners.net (MOS 3.8.4-GA) with ESMTP id AIH35602 (AUTH admin@network-heretics.com); Tue, 11 Dec 2007 10:33:21 -0800 (PST) Message-ID: <475ED7EF.7030009@cs.utk.edu> Date: Tue, 11 Dec 2007 10:33:19 -0800 From: Keith Moore User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: der Mouse Subject: Re: interop problems with getaddrinfo() address selection References: <200712062020.PAA16213@Sparkle.Rodents.Montreal.QC.CA> <475B0ABC.5090806@cs.utk.edu> <475C5047.3010807@cs.utk.edu> <200712101815.NAA27674@Sparkle.Rodents.Montreal.QC.CA> <200712102311.SAA01012@Sparkle.Rodents.Montreal.QC.CA> <200712111430.JAA08747@Sparkle.Rodents.Montreal.QC.CA> In-Reply-To: <200712111430.JAA08747@Sparkle.Rodents.Montreal.QC.CA> X-Enigmail-Version: 0.95.5 OpenPGP: id=E1473978 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: discuss@apps.ietf.org X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org >>> It appears we're talking about differnet things. To me, DNS >>> round-robin refers to the sort of thing the NTP pool project does: >>> rotating the answer(s) returned in response to a query through a >>> larger (usually much larger) set of possible answers. >>> >> That's incompatible with RFC 2181 section 5 >> > > I read through 2181 section 5 and the only thing I see that seems > plausible to me as what you're talking about is 5.1: "A query for a > specific (or non-specific) label, class, and type, will always return > all records in the associated RRSet". > > All you need to do here is hold your mind a little differently - think > of it as changing the RRset instead of returning only some of the > records from an unchanging RRset. > which is fine if and only if it increments the zone serial # each time. Keith From discuss-bounces@apps.ietf.org Tue Dec 11 14:42:50 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2B0D-0002AF-Vz; Tue, 11 Dec 2007 14:42:49 -0500 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1J2B0D-0002AA-FH for discuss-confirm+ok@megatron.ietf.org; Tue, 11 Dec 2007 14:42:49 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2B0D-0002A2-5d for discuss@apps.ietf.org; Tue, 11 Dec 2007 14:42:49 -0500 Received: from sparkle.rodents.montreal.qc.ca ([216.46.5.7]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J2B0B-0008TD-PG for discuss@apps.ietf.org; Tue, 11 Dec 2007 14:42:49 -0500 Received: (from mouse@localhost) by Sparkle.Rodents.Montreal.QC.CA (8.8.8/8.8.8) id OAA12236; Tue, 11 Dec 2007 14:42:45 -0500 (EST) From: der Mouse Message-Id: <200712111942.OAA12236@Sparkle.Rodents.Montreal.QC.CA> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Erik-Conspiracy: There is no Conspiracy - and if there were I wouldn't be part of it anyway. X-Message-Flag: Microsoft: the company who gave us the botnet zombies. Date: Tue, 11 Dec 2007 14:40:34 -0500 (EST) To: discuss@apps.ietf.org Subject: Re: interop problems with getaddrinfo() address selection In-Reply-To: <475ED7F9.3060703@network-heretics.com> References: <200712062020.PAA16213@Sparkle.Rodents.Montreal.QC.CA> <475B0ABC.5090806@cs.utk.edu> <475C5047.3010807@cs.utk.edu> <200712101815.NAA27674@Sparkle.Rodents.Montreal.QC.CA> <200712102311.SAA01012@Sparkle.Rodents.Montreal.QC.CA> <200712111430.JAA08747@Sparkle.Rodents.Montreal.QC.CA> <475ED7F9.3060703@network-heretics.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org >> All you need to do here is hold your mind a little differently - >> think of it as changing the RRset instead of returning only some of >> the records from an unchanging RRset. > which is fine if and only if it increments the zone serial # each > time. Agreed. But since almost all queries do not see the zone serial, this is not relevant to whether doing such things in normal operation is reasonable. /~\ The ASCII der Mouse \ / Ribbon Campaign X Against HTML mouse@rodents.montreal.qc.ca / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B From discuss-bounces@apps.ietf.org Wed Dec 12 10:34:16 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2TbB-0002gj-JL; Wed, 12 Dec 2007 10:34:13 -0500 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1J2Tb9-0002Uh-I5 for discuss-confirm+ok@megatron.ietf.org; Wed, 12 Dec 2007 10:34:11 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2Tb8-0002PT-KP for discuss@apps.ietf.org; Wed, 12 Dec 2007 10:34:10 -0500 Received: from ppsw-7.csi.cam.ac.uk ([131.111.8.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J2Tb7-0007th-43 for discuss@apps.ietf.org; Wed, 12 Dec 2007 10:34:10 -0500 X-Cam-SpamDetails: Not scanned X-Cam-AntiVirus: No virus found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-1.csi.cam.ac.uk ([131.111.8.51]:53429) by ppsw-7.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.157]:25) with esmtpa (EXTERNAL:fanf2) id 1J2Tb4-0007YD-PA (Exim 4.67) (return-path ); Wed, 12 Dec 2007 15:34:06 +0000 Received: from fanf2 (helo=localhost) by hermes-1.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1J2Tb4-0005y4-PL (Exim 4.67) (return-path ); Wed, 12 Dec 2007 15:34:06 +0000 Date: Wed, 12 Dec 2007 15:34:06 +0000 From: Tony Finch X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk To: Keith Moore Subject: Re: interop problems with getaddrinfo() address selection In-Reply-To: <475ED78A.2070608@network-heretics.com> Message-ID: References: <200712062020.PAA16213@Sparkle.Rodents.Montreal.QC.CA> <475B0ABC.5090806@cs.utk.edu> <475C5047.3010807@cs.utk.edu> <200712101815.NAA27674@Sparkle.Rodents.Montreal.QC.CA> <200712102311.SAA01012@Sparkle.Rodents.Montreal.QC.CA> <475DDAA7.3060308@cs.utk.edu> <20071211094746.GA29759@nic.fr> <475ED78A.2070608@network-heretics.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: -4.0 (----) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: discuss@apps.ietf.org X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org On Tue, 11 Dec 2007, Keith Moore wrote: > > Per RFC 2782, SRV only applies to protocols that are specified to use > it. Even then, it's not clear that SRV is good for dynamic load balancing. That's OK: we're talking about static load balancing. The SRV and MX specifications both require the client to randomize the RRs, so they achieve this goal. Tony. -- f.a.n.finch http://dotat.at/ SOUTHEAST ICELAND: SOUTHWESTERLY 3 OR 4 BACKING SOUTHERLY 6 TO GALE 8, PERHAPS SEVERE GALE 9 LATER. VERY ROUGH, OCCASIONALLY HIGH LATER. OCCASIONAL RAIN. MODERATE OR GOOD. From discuss-bounces@apps.ietf.org Thu Dec 13 12:13:44 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2rcy-0004WA-UQ; Thu, 13 Dec 2007 12:13:40 -0500 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1J2rcy-0004VY-6T for discuss-confirm+ok@megatron.ietf.org; Thu, 13 Dec 2007 12:13:40 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2rcx-0004Us-SH for discuss@apps.ietf.org; Thu, 13 Dec 2007 12:13:39 -0500 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J2rcw-0001py-5h for discuss@apps.ietf.org; Thu, 13 Dec 2007 12:13:39 -0500 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id D33B0210DB; Thu, 13 Dec 2007 18:11:21 +0100 (CET) X-AuditID: c1b4fb3c-b179abb0000030cf-78-476167b9ea05 Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.124]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id BD510204BF; Thu, 13 Dec 2007 18:11:21 +0100 (CET) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 13 Dec 2007 18:11:21 +0100 Received: from [159.107.197.224] ([159.107.197.224]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 13 Dec 2007 18:11:21 +0100 Message-ID: <476167B8.3000503@ericsson.com> Date: Thu, 13 Dec 2007 18:11:20 +0100 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: Ladislav Lhotka Subject: Re: analysis of YANG vs. RELAX NG References: <953beacc0711271504y7aea5f21jc301ccad886d3611@mail.gmail.com> <474D9194.3060103@ericsson.com> <953beacc0711281025w4d993dd7u77d729111074496c@mail.gmail.com> <20071128.230244.254578150.mbj@tail-f.com> <63F8A418-6AF0-4205-ACC7-53A8C7BC6A73@osafoundation.org> <47512728.6040201@gmx.de> <517bf110712021242v43c462f0v86267f591e5cdfbd@mail.gmail.com> <1196690162.5874.13.camel@missotis><20071203140846.GB17536@elstar.local> <47543B30.1060409@andybierman.com> <1196704923.5569.14.camel@missotis> <003801c835e7$4fefeb20$6801a8c0@oemcomputer> <1196722786.5835.57.camel@missotis> In-Reply-To: <1196722786.5835.57.camel@missotis> Content-Type: text/plain; charset=UTF-8; format=flowed X-OriginalArrivalTime: 13 Dec 2007 17:11:21.0338 (UTC) FILETIME=[2EC455A0:01C83DAB] X-Brightmail-Tracker: AAAAAA== Content-Transfer-Encoding: quoted-printable X-Spam-Score: -1.0 (-) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: discuss@apps.ietf.org X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org Hello, A late reply. I agree with Juergen, Andy et al. but I also have anther reason. Imagine when you have one big model that is modified by a 5 liner a bit. = Then you get the next=20 five liner, the next one. Then you get a five liner that modifies a previ= ous modification. To understand what really goes on in the node you have to know all the li= ttle 5 liners. In Yang you can at least understand the basic model and consider the rest= as extensions,=20 because the basic model is not redefined only extended. Balazs Ladislav Lhotka wrote: > Hi, >=20 > Randy Presuhn p=C3=AD=C5=A1e v Po 03. 12. 2007 v 12:01 -0800: >=20 >> I strongly agree with Andy and Juergen. "Mushy" definitions >> are disastrous for interoperability. >=20 > I think it's a misunderstanding. I am not pleading for fuzzy (is it > approximately what "mushy" means?;-) data models, the models can and > should be simple and unambiguous, I am talking about additional > flexibility for model *designers*, i.e., straightforward means for > reusing and extending existing models into new models (also by adding > structure to former leaves, why not?), and here I think YANG is rather > rigid when compared to RELAX NG. >=20 > Lada >=20 --=20 Balazs Lengyel Ericsson Hungary Ltd. TSP System Manager ECN: 831 7320 Fax: +36 1 4377792 Tel: +36-1-437-7320 email: Balazs.Lengyel@ericsson.com From discuss-bounces@apps.ietf.org Thu Dec 13 12:36:32 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2rz5-00035S-Nq; Thu, 13 Dec 2007 12:36:31 -0500 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1J2rz4-00030t-5R for discuss-confirm+ok@megatron.ietf.org; Thu, 13 Dec 2007 12:36:30 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2rz3-00030k-RS for discuss@apps.ietf.org; Thu, 13 Dec 2007 12:36:29 -0500 Received: from laweleka.osafoundation.org ([204.152.186.98]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J2rz1-00034x-Da for discuss@apps.ietf.org; Thu, 13 Dec 2007 12:36:29 -0500 Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 161BB14220E; Thu, 13 Dec 2007 09:36:28 -0800 (PST) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RYVd7hgAT7AG; Thu, 13 Dec 2007 09:36:21 -0800 (PST) Received: from [192.168.1.103] (unknown [74.95.2.169]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id C4052142207; Thu, 13 Dec 2007 09:36:21 -0800 (PST) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <761895B3-653F-4F15-BAA5-8528ACC62617@osafoundation.org> Content-Transfer-Encoding: 7bit From: Lisa Dusseault Subject: Position papers due Dec 14 Date: Thu, 13 Dec 2007 09:36:21 -0800 To: Apps Discuss , iesg@ietf.org, IAB IAB X-Mailer: Apple Mail (2.752.3) X-Spam-Score: -4.0 (----) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: Chris Newman X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org Remember brief position papers should be sent to Chris and me and/or the Apps Discuss list by end of day (anywhere) Dec 14. thanks! Lisa On Nov 15, 2007, at 2:03 PM, Lisa Dusseault wrote: > > On Feb 11 and 12, there will be an Applications Area Architecture > workshop somewhere in the Bay Area. We hope to nail down a venue > once we've got a better idea of attendance. We are going to look > for a host, but if there are a few expenses not covered, we may ask > for a few 100$ attendance fee. If we need to charge a small fee > we'll ask in advance of the actual meeting. > > Position papers are required of all attendees by Dec 14. These > should be a few pages of text on some topic related to Applications > area architectural issues. Since the group of attendees is > expected to span HTTP and AtomPub, email, IM, calendaring, > directories and more, issues should be of interest to more than one > of these groups. Some existing Applications architecture "modules" > that already are reused include SASL, URLs, MIME types, XML and > XML schemas and namespaces, HTTP as a substrate, TLS, ABNF, BEEP. > > A position paper could describe a problem or make a proposal to > solve a problem. The paper could be a prelude to an I-D of any > kind or to a WG charter, or might simply educate and persuade. An > ideal position paper would seed new work or make progress towards > solving a problem that would benefit Apps protocol designers, > implementors or users. > > Participants may send position papers directly to Lisa and Chris, > although you can send position papers directly to the Apps Discuss > list (we'll be circulating the papers publicly anyway). > > Since the due date for papers is Dec 14, if you'd like to flesh out > an idea, the Vancouver IETF meeting might be a handy place to grab > people and do so. > > In advance of Dec 14, we'd still appreciate early RSVPs. > > Lisa > > From discuss-bounces@apps.ietf.org Thu Dec 13 16:28:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2vbW-0006Jk-W6; Thu, 13 Dec 2007 16:28:26 -0500 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1J2vbV-0006JX-Pv for discuss-confirm+ok@megatron.ietf.org; Thu, 13 Dec 2007 16:28:25 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2vbV-0006JI-GE for discuss@apps.ietf.org; Thu, 13 Dec 2007 16:28:25 -0500 Received: from laweleka.osafoundation.org ([204.152.186.98]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J2vbT-0002R2-Fn for discuss@apps.ietf.org; Thu, 13 Dec 2007 16:28:25 -0500 Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 709A4142274; Thu, 13 Dec 2007 13:28:24 -0800 (PST) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TQoXpxeXKtwT; Thu, 13 Dec 2007 13:28:18 -0800 (PST) Received: from [10.1.1.107] (unknown [157.22.41.236]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 95C7F142217; Thu, 13 Dec 2007 13:28:17 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v752.3) Message-Id: <117C7973-01EA-40F8-A52C-20801F18EAAB@osafoundation.org> Content-Type: multipart/alternative; boundary=Apple-Mail-4-230765277 To: Apps Discuss , Lisa Dusseault's Chairs Subject: Lisa's Apps area activity for Nov 2007 From: Lisa Dusseault Date: Thu, 13 Dec 2007 13:28:17 -0800 X-Mailer: Apple Mail (2.752.3) X-Spam-Score: -1.3 (-) X-Scan-Signature: f2984bf50fb52a9e56055f779793d783 Cc: X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org --Apple-Mail-4-230765277 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Notes AppArea meetling in Vancouver had two topics looking for general interest: - YANG and other proposed schema definition approaches for NETCONF configuration schemas: long discussion of YANG, a new language, reuse of XSD (concrete proposal) and reuse of RelaxNG (no concrete proposal). - Brief overview of draft-garcia-app-area-file-data-format, poll for interest: none App area workshop: now collecting position papers. Other WG meetings mostly focused on resolving internal document issues, see at bottom Document Status and Progress Active Documents: my action - draft-ellermann-news-nntp-uri (Proposed Standard): I need to review - draft-adolf-dvb-urn (Informational): I need to do a writeup -- no document shepherd - draft-goodwin-iso-urn (Informational): I need to do a writeup -- no doc shepherd - draft-sjdcox-cgi-urn (None): I need to do a writeup -- no doc shepherd Stalled, in review, waiting on other: - draft-evain-ebu-urn (Informational): Need new text or version to address secdir review - draft-klensin-rfc2821bis (Draft Standard): in IETF Last Call - draft-ietf-sieve-notify: Ready for IESG Evaluation - draft-ietf-sieve-notify-xmpp: Ready for IESG Evaluation - draft-creed-ogc-urn (Informational): Ready for IESG Evaluation - draft-ietf-sieve-notify-mailto: waiting on new version after IETF last call - draft-snell-atompub-bidi (Proposed Standard): author waiting on some implementation feedback - draft-wilde-sms-uri (Proposed Standard): Waiting for responses or revision to address Last call issues - draft-ietf-sieve-body (Proposed Standard): Waiting on revised ID to deal with gen-art feedback - draft-ietf-imapext-sort (Proposed Standard) : waiting for authors to revise or decide it's ready Finished Processing -- RFC Ed queue and new RFCs - draft-mealling-epc-urn (Informational) - draft-saintandre-rfc4622bis (Proposed Standard) - draft-crocker-rfc4234bis (Standard) - draft-ietf-sieve-3028bis (Proposed Standard) - RFC 5092 - IMAP URL Scheme (Proposed Standard) Newly "Dead" (or just sleeping) - draft-montemurro-gsma-imei-urn (Experimental): draft timed out waiting for authors WG Status - SIEVE pushing final documents through IETF Last Call and IESG Eval. - IMAPEXT stalled waiting for i18n work to complete - ATOMPUB closed - CALSIFY closing down on documents, preparing to do WG last call and IETF last call. - USEFOR stalled on single WG deliverable - HTTP going through issues list and addressing issues in newly organized set of documents that replace RFC2616. --Apple-Mail-4-230765277 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1 - YANG = and other proposed schema definition approaches for NETCONF = configuration schemas: long discussion of YANG, a new language, reuse of = XSD (concrete proposal) and reuse of RelaxNG (no concrete = proposal).=A0=A0
- Brief overview = of=A0draft-garcia-app-area-file-data-format, poll for interest: = none

App area = workshop: now collecting position papers.

Other WG meetings mostly = focused on resolving internal document issues, see at = bottom


Document = Status and Progress

Active Documents: my action
=A0-=A0draft-ellermann-news-nntp-uri (Proposed = Standard): I need to review
=A0-=A0draft-goodwin-iso-urn = (Informational): I need to do a writeup -- no doc shepherd
-=A0draft-sjdcox-cgi-urn (None): I need to do a = writeup -- no doc shepherd=A0

Stalled, in review, waiting on = other:
=A0-=A0draft-evain-ebu-urn = (Informational): Need new text or version=A0 to address secdir = review=A0
=A0-=A0draft-klensin-rfc2821bis (Draft Standard): in IETF Last = Call
=A0- draft-ietf-sieve-notify: = Ready for IESG Evaluation
=A0- = draft-ietf-sieve-notify-xmpp:=A0 Ready=A0for IESG Evaluation
=A0-=A0draft-creed-ogc-urn (Informational): Ready = for IESG Evaluation
=A0- = draft-ietf-sieve-notify-mailto:=A0waiting on new version after IETF last = call
=A0-=A0draft-snell-atompub-bidi = (Proposed Standard): author waiting on some implementation = feedback
=A0-=A0draft-wilde-sms-uri = (Proposed Standard): Waiting for responses or revision to address Last = call issues
=A0-=A0draft-ietf-sieve-body = (Proposed Standard): Waiting on revised ID to deal with gen-art = feedback
=A0-=A0draft-ietf-imapext-sort = (Proposed Standard) : waiting for authors to revise or decide it's = ready

Finished Processing -- RFC Ed queue and new = RFCs
=A0-=A0draft-mealling-epc-urn = (Informational)
=A0-=A0draft-saintandre-rfc4622bis= (Proposed Standard)
=A0-=A0draft-crocker-rfc4234b= is (Standard)
=A0-=A0draft-ietf-sieve-3028bis = (Proposed Standard)
=A0- RFC 5092 -=A0IMAP URL = Scheme (Proposed Standard)

Newly = "Dead" (or just sleeping)

WG Status
=A0- SIEVE = pushing final documents through IETF Last Call and IESG Eval.
=A0- IMAPEXT stalled waiting for i18n work to = complete
=A0- ATOMPUB closed
=A0- CALSIFY closing down on documents, preparing to = do WG last call and IETF last call.
=A0- USEFOR = stalled on single WG deliverable
=A0- HTTP = going through issues list and addressing issues in newly organized set = of documents that replace RFC2616.=A0=A0


= --Apple-Mail-4-230765277-- From discuss-bounces@apps.ietf.org Fri Dec 14 17:49:32 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J3JLR-0000cB-Fa; Fri, 14 Dec 2007 17:49:25 -0500 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1J3JLQ-0000c4-1P for discuss-confirm+ok@megatron.ietf.org; Fri, 14 Dec 2007 17:49:24 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J3JLP-0000bq-Nn for discuss@apps.ietf.org; Fri, 14 Dec 2007 17:49:23 -0500 Received: from dizzyd.com ([207.210.219.225]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J3JLN-0003GA-Ew for discuss@apps.ietf.org; Fri, 14 Dec 2007 17:49:23 -0500 Received: from wrk225.corp.jabber.com (dencfw1.jabber.com [207.182.164.5]) (Authenticated sender: stpeter) by dizzyd.com (Postfix) with ESMTP id E005940077 for ; Fri, 14 Dec 2007 15:49:20 -0700 (MST) Message-ID: <476308CB.4060103@stpeter.im> Date: Fri, 14 Dec 2007 15:50:51 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.1.9) Gecko/20071031 Thunderbird/2.0.0.9 Mnenhy/0.7.5.666 MIME-Version: 1.0 To: discuss@apps.ietf.org Subject: push and pull X-Enigmail-Version: 0.95.5 OpenPGP: id=7BBD0573; url=http://www.saint-andre.com/me/stpeter.asc Jabber-ID: stpeter@jabber.org Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms030308090901030403020309" X-Spam-Score: -0.0 (/) X-Scan-Signature: 225414c974e0d6437992164e91287a51 X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org This is a cryptographically signed message in MIME format. --------------ms030308090901030403020309 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit I started to write a paper for the Apps Area Architecture Workshop, but it morphed into a blog post. Folks here may or may not find it of interest: https://stpeter.im/?p=2108 Peter -- Peter Saint-Andre https://stpeter.im/ --------------ms030308090901030403020309 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIYQDCC B3AwggbZoAMCAQICAQowDQYJKoZIhvcNAQEEBQAwgbAxCzAJBgNVBAYTAklMMQ8wDQYDVQQI EwZJc3JhZWwxDjAMBgNVBAcTBUVpbGF0MRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMRowGAYD VQQLExFDQSBBdXRob3JpdHkgRGVwLjEpMCcGA1UEAxMgRnJlZSBTU0wgQ2VydGlmaWNhdGlv biBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEmFkbWluQHN0YXJ0Y29tLm9yZzAeFw0wNTA0 MDUxNDUyMTNaFw0xMDA0MDQxNDUyMTNaMIGvMQswCQYDVQQGEwJJTDEPMA0GA1UECBMGSXNy YWVsMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSMwIQYDVQQLExpTZWN1cmUgQ2VydGlmaWNh dGUgU2lnbmluZzEvMC0GA1UEAxMmU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEVtYWlsIEZy ZWUgQ0ExITAfBgkqhkiG9w0BCQEWEmFkbWluQHN0YXJ0Y29tLm9yZzCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAPEaOcSx5ZNexwo1zJNcX48UV0UtkNtWX3qa9ZaX2VZilgIz eIrObloQV0Ma2rdgqosW9xMb5u3lBVIumt7fEwgMqqtDa3F2Qudelv93P9z2nbmn7X4GnCKA IQcW97KOSgQQHaVPHq03xGFbszx+LOKrBi/xv3bcGxtYrH+10M1nHbCRo8U2+zcJQowxoI+O U5nhko9vU25Jp8ZQ2fROH6C2TSjZuanzMTyvc5+dJiN2Hm2MhAMrqO7pUGhDKuUvnmKpAcwj eYQHU51mvlB4IId+4bTEwVoG4AMJ8RXB47VdJevN0yqeJSACyoRft4w4OpqFysR1HTT6aE6u xLg9ZC0CAwEAAaOCBBMwggQPMA8GA1UdEwEB/wQFMAMBAf8wCwYDVR0PBAQDAgHmMB0GA1Ud DgQWBBQErNskd1NGRpZfFwFcfUJHvUgZCDCB3QYDVR0jBIHVMIHSgBQcicOWzL3+MtUNjIEx tpidjShkjaGBtqSBszCBsDELMAkGA1UEBhMCSUwxDzANBgNVBAgTBklzcmFlbDEOMAwGA1UE BxMFRWlsYXQxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xGjAYBgNVBAsTEUNBIEF1dGhvcml0 eSBEZXAuMSkwJwYDVQQDEyBGcmVlIFNTTCBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEhMB8G CSqGSIb3DQEJARYSYWRtaW5Ac3RhcnRjb20ub3JnggEAMB0GA1UdEQQWMBSBEmFkbWluQHN0 YXJ0Y29tLm9yZzAdBgNVHRIEFjAUgRJhZG1pbkBzdGFydGNvbS5vcmcwYgYDVR0fBFswWTAp oCegJYYjaHR0cDovL2NlcnQuc3RhcnRjb20ub3JnL2NhLWNybC5jcmwwLKAqoCiGJmh0dHA6 Ly9jcmwuc3RhcnRjb20ub3JnL2NybC9jYS1jcmwuY3JsMIIBSgYDVR0gBIIBQTCCAT0wggE5 BgsrBgEEAYG1NwEBATCCASgwLwYIKwYBBQUHAgEWI2h0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9y Zy9wb2xpY3kucGRmMDUGCCsGAQUFBwIBFilodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvaW50 ZXJtZWRpYXRlLnBkZjCBvQYIKwYBBQUHAgIwgbAwFBYNU3RhcnRDb20gTHRkLjADAgEBGoGX TGltaXRlZCBMaWFiaWxpdHksIHJlYWQgdGhlIHNlY3Rpb24gKkxlZ2FsIExpbWl0YXRpb25z KiBvZiB0aGUgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgUG9saWN5IGF2YWls YWJsZSBhdCBodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvcG9saWN5LnBkZjARBglghkgBhvhC AQEEBAMCAAcwUAYJYIZIAYb4QgENBEMWQVN0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRl cm1lZGlhdGUgRnJlZSBTU0wgRW1haWwgQ2VydGlmaWNhdGVzMDIGCWCGSAGG+EIBBAQlFiNo dHRwOi8vY2VydC5zdGFydGNvbS5vcmcvY2EtY3JsLmNybDAzBglghkgBhvhCAQMEJhYkaHR0 cDovL2NlcnQuc3RhcnRjb20ub3JnL2NydC1jcmwuY3JsMDIGCWCGSAGG+EIBCAQlFiNodHRw Oi8vY2VydC5zdGFydGNvbS5vcmcvcG9saWN5LnBkZjANBgkqhkiG9w0BAQQFAAOBgQBc1g6H yT3ZrGb0Kq+kkqetnSXtcwffHEr6Tia2XqCqPLLzdZ8VTxVjeq/Kpg2u+8cGASIl1U45XmWa v4Vez+jSSnChRHwidmbwjCtNBFxr4C/Nkgs8wk2zNQbh+zlDKNophJT7+DVOhnIMJzdNkQW0 4STurMCFwLoyx5k1rDHQYTCCCGIwggdKoAMCAQICAwF4qjANBgkqhkiG9w0BAQUFADCBrzEL MAkGA1UEBhMCSUwxDzANBgNVBAgTBklzcmFlbDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEj MCEGA1UECxMaU2VjdXJlIENlcnRpZmljYXRlIFNpZ25pbmcxLzAtBgNVBAMTJlN0YXJ0Q29t IENsYXNzIDMgUHJpbWFyeSBFbWFpbCBGcmVlIENBMSEwHwYJKoZIhvcNAQkBFhJhZG1pbkBz dGFydGNvbS5vcmcwHhcNMDcwODIyMjExMzI3WhcNMDgwODIxMjExMzI3WjCBujELMAkGA1UE BhMCVVMxETAPBgNVBAgTCENvbG9yYWRvMQ8wDQYDVQQHEwZEZW52ZXIxGjAYBgNVBAoTEVBl dGVyIFNhaW50LUFuZHJlMSwwKgYDVQQLEyNTdGFydENvbSBUcnVzdGVkIENlcnRpZmljYXRl IE1lbWJlcjEaMBgGA1UEAxMRUGV0ZXIgU2FpbnQtQW5kcmUxITAfBgkqhkiG9w0BCQEWEnN0 cGV0ZXJAc3RwZXRlci5pbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALC1dkqD gghuvUCkEloRDX50TTJ6Szj1BqtMpYq+An66BwkWfP07uay+jHori77776wk1/Ajk1nTSHX+ JWo+JWwVXYWBX+Zd780bB0FGShYlHGwMhd/pxX9sT4KW3D+r8sIHVbTGdudSweuNdBhqr1iE cjze75hpywMkk1OQhTkseQxI5owa9M31JOdNEX0Ja6esyhwwtqqTNC86OujXwa2wew8GTRJE 9p2I0B1VCsKuJaPatbIcf9OFiTSODb5vyoq3+lrElh6V6BXKxEfQ4D2HCSY+5UmlKdnltzvN bqxyaTYQi1YGsFzew7ST3R8P5jrCq2cvRjGrTKVojZXgPZ0CAwEAAaOCBHgwggR0MAwGA1Ud EwQFMAMCAQAwCwYDVR0PBAQDAgSwMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAd BgNVHQ4EFgQUl7CU2dS/alOwLIHV/Oc2RkGDYugwgd0GA1UdIwSB1TCB0oAUBKzbJHdTRkaW XxcBXH1CR71IGQihgbakgbMwgbAxCzAJBgNVBAYTAklMMQ8wDQYDVQQIEwZJc3JhZWwxDjAM BgNVBAcTBUVpbGF0MRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMRowGAYDVQQLExFDQSBBdXRo b3JpdHkgRGVwLjEpMCcGA1UEAxMgRnJlZSBTU0wgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkx ITAfBgkqhkiG9w0BCQEWEmFkbWluQHN0YXJ0Y29tLm9yZ4IBCjCCAUAGA1UdIASCATcwggEz MIIBLwYLKwYBBAGBtTcBAQQwggEeMDUGCCsGAQUFBwIBFilodHRwOi8vY2VydC5zdGFydGNv bS5vcmcvaW50ZXJtZWRpYXRlLnBkZjAvBggrBgEFBQcCARYjaHR0cDovL2NlcnQuc3RhcnRj b20ub3JnL3BvbGljeS5wZGYwgbMGCCsGAQUFBwICMIGmMBQWDVN0YXJ0Q29tIEx0ZC4wAwIB ARqBjUxpbWl0ZWQgTGlhYmlsaXR5LCByZWFkIHRoZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0 aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gUG9saWN5IGF2YWlsYWJsZSBh dCBodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvcG9saWN5LnBkZjBkBgNVHR8EXTBbMCygKqAo hiZodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvY3J0dTMtY3JsLmNybDAroCmgJ4YlaHR0cDov L2NybC5zdGFydGNvbS5vcmcvY3J0dTMtY3JsLmNybDCBhAYIKwYBBQUHAQEEeDB2MDcGCCsG AQUFBzABhitodHRwOi8vb2NzcC5zdGFydGNvbS5vcmcvc3ViL2NsYXNzMy91c2VyL2NhMDsG CCsGAQUFBzAChi9odHRwOi8vY2VydC5zdGFydGNvbS5vcmcvc3ViLmNsYXNzMy51c2VyLmNh LmNydDARBglghkgBhvhCAQEEBAMCBaAwMQYJYIZIAYb4QgENBCQWIlN0YXJ0Q29tIFRydXN0 ZWQgRW1haWwgQ2VydGlmaWNhdGUwMgYJYIZIAYb4QgEEBCUWI2h0dHA6Ly9jZXJ0LnN0YXJ0 Y29tLm9yZy9jYS1jcmwuY3JsMDUGCWCGSAGG+EIBAwQoFiZodHRwOi8vY2VydC5zdGFydGNv bS5vcmcvY3J0dTMtY3JsLmNybDAyBglghkgBhvhCAQgEJRYjaHR0cDovL2NlcnQuc3RhcnRj b20ub3JnL3BvbGljeS5wZGYwIwYDVR0SBBwwGoYYaHR0cDovL2NlcnQuc3RhcnRjb20ub3Jn MA0GCSqGSIb3DQEBBQUAA4IBAQCdG1L0T4OT1x4X/cKsuHxgijRaZGGiVECcn5+1X7E3H54/ yDkUqWAp6MZ3hZm36pzTYYnl+5M6vldLcqFCVpD7MgH6Kmu+r6pXAjU33k1RIHnkBvQ6KGlR p0RjfaZW/2MkG07vF2QTLbx6KIhi0pa9Bg9wlqyw+C2g6FYnfmrdJLgGrxUXek8DSZNjZ/AA 75OoutrWkBtdaL2TbFiawdbGuJbSoQLHqLrNhT8f74Oec7ReOmuUTEL8hsFU0sbY/n2e9Wna 1Vzze3nZPbyPiC5F88p88gVLB9mKkOzleYefYiQw8LABz5x1MI+w0bNKNPLviJ/KnHGFEfVL z1oMHyC3MIIIYjCCB0qgAwIBAgIDAXiqMA0GCSqGSIb3DQEBBQUAMIGvMQswCQYDVQQGEwJJ TDEPMA0GA1UECBMGSXNyYWVsMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSMwIQYDVQQLExpT ZWN1cmUgQ2VydGlmaWNhdGUgU2lnbmluZzEvMC0GA1UEAxMmU3RhcnRDb20gQ2xhc3MgMyBQ cmltYXJ5IEVtYWlsIEZyZWUgQ0ExITAfBgkqhkiG9w0BCQEWEmFkbWluQHN0YXJ0Y29tLm9y ZzAeFw0wNzA4MjIyMTEzMjdaFw0wODA4MjEyMTEzMjdaMIG6MQswCQYDVQQGEwJVUzERMA8G A1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRlbnZlcjEaMBgGA1UEChMRUGV0ZXIgU2FpbnQt QW5kcmUxLDAqBgNVBAsTI1N0YXJ0Q29tIFRydXN0ZWQgQ2VydGlmaWNhdGUgTWVtYmVyMRow GAYDVQQDExFQZXRlciBTYWludC1BbmRyZTEhMB8GCSqGSIb3DQEJARYSc3RwZXRlckBzdHBl dGVyLmltMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAsLV2SoOCCG69QKQSWhEN fnRNMnpLOPUGq0ylir4CfroHCRZ8/Tu5rL6MeiuLvvvvrCTX8COTWdNIdf4laj4lbBVdhYFf 5l3vzRsHQUZKFiUcbAyF3+nFf2xPgpbcP6vywgdVtMZ251LB6410GGqvWIRyPN7vmGnLAyST U5CFOSx5DEjmjBr0zfUk500RfQlrp6zKHDC2qpM0Lzo66NfBrbB7DwZNEkT2nYjQHVUKwq4l o9q1shx/04WJNI4Nvm/Kirf6WsSWHpXoFcrER9DgPYcJJj7lSaUp2eW3O81urHJpNhCLVgaw XN7DtJPdHw/mOsKrZy9GMatMpWiNleA9nQIDAQABo4IEeDCCBHQwDAYDVR0TBAUwAwIBADAL BgNVHQ8EBAMCBLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBSX sJTZ1L9qU7AsgdX85zZGQYNi6DCB3QYDVR0jBIHVMIHSgBQErNskd1NGRpZfFwFcfUJHvUgZ CKGBtqSBszCBsDELMAkGA1UEBhMCSUwxDzANBgNVBAgTBklzcmFlbDEOMAwGA1UEBxMFRWls YXQxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xGjAYBgNVBAsTEUNBIEF1dGhvcml0eSBEZXAu MSkwJwYDVQQDEyBGcmVlIFNTTCBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEhMB8GCSqGSIb3 DQEJARYSYWRtaW5Ac3RhcnRjb20ub3JnggEKMIIBQAYDVR0gBIIBNzCCATMwggEvBgsrBgEE AYG1NwEBBDCCAR4wNQYIKwYBBQUHAgEWKWh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9pbnRl cm1lZGlhdGUucGRmMC8GCCsGAQUFBwIBFiNodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvcG9s aWN5LnBkZjCBswYIKwYBBQUHAgIwgaYwFBYNU3RhcnRDb20gTHRkLjADAgEBGoGNTGltaXRl ZCBMaWFiaWxpdHksIHJlYWQgdGhlIHNlY3Rpb24gKkxlZ2FsIExpbWl0YXRpb25zKiBvZiB0 aGUgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBQb2xpY3kgYXZhaWxhYmxlIGF0IGh0dHA6Ly9j ZXJ0LnN0YXJ0Y29tLm9yZy9wb2xpY3kucGRmMGQGA1UdHwRdMFswLKAqoCiGJmh0dHA6Ly9j ZXJ0LnN0YXJ0Y29tLm9yZy9jcnR1My1jcmwuY3JsMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0 Y29tLm9yZy9jcnR1My1jcmwuY3JsMIGEBggrBgEFBQcBAQR4MHYwNwYIKwYBBQUHMAGGK2h0 dHA6Ly9vY3NwLnN0YXJ0Y29tLm9yZy9zdWIvY2xhc3MzL3VzZXIvY2EwOwYIKwYBBQUHMAKG L2h0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9zdWIuY2xhc3MzLnVzZXIuY2EuY3J0MBEGCWCG SAGG+EIBAQQEAwIFoDAxBglghkgBhvhCAQ0EJBYiU3RhcnRDb20gVHJ1c3RlZCBFbWFpbCBD ZXJ0aWZpY2F0ZTAyBglghkgBhvhCAQQEJRYjaHR0cDovL2NlcnQuc3RhcnRjb20ub3JnL2Nh LWNybC5jcmwwNQYJYIZIAYb4QgEDBCgWJmh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9jcnR1 My1jcmwuY3JsMDIGCWCGSAGG+EIBCAQlFiNodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvcG9s aWN5LnBkZjAjBgNVHRIEHDAahhhodHRwOi8vY2VydC5zdGFydGNvbS5vcmcwDQYJKoZIhvcN AQEFBQADggEBAJ0bUvRPg5PXHhf9wqy4fGCKNFpkYaJUQJyfn7VfsTcfnj/IORSpYCnoxneF mbfqnNNhieX7kzq+V0tyoUJWkPsyAfoqa76vqlcCNTfeTVEgeeQG9DooaVGnRGN9plb/YyQb Tu8XZBMtvHooiGLSlr0GD3CWrLD4LaDoVid+at0kuAavFRd6TwNJk2Nn8ADvk6i62taQG11o vZNsWJrB1sa4ltKhAseous2FPx/vg55ztF46a5RMQvyGwVTSxtj+fZ71adrVXPN7edk9vI+I LkXzynzyBUsH2YqQ7OV5h59iJDDwsAHPnHUwj7DRs0o08u+In8qccYUR9UvPWgwfILcxggQs MIIEKAIBATCBtzCBrzELMAkGA1UEBhMCSUwxDzANBgNVBAgTBklzcmFlbDEWMBQGA1UEChMN U3RhcnRDb20gTHRkLjEjMCEGA1UECxMaU2VjdXJlIENlcnRpZmljYXRlIFNpZ25pbmcxLzAt BgNVBAMTJlN0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBFbWFpbCBGcmVlIENBMSEwHwYJKoZI hvcNAQkBFhJhZG1pbkBzdGFydGNvbS5vcmcCAwF4qjAJBgUrDgMCGgUAoIICSTAYBgkqhkiG 9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wNzEyMTQyMjUwNTFaMCMGCSqG SIb3DQEJBDEWBBSomQ3ApgCGna6MFIfBv1EDt6cpcDBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqG SIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG 9w0DAgIBKDCByAYJKwYBBAGCNxAEMYG6MIG3MIGvMQswCQYDVQQGEwJJTDEPMA0GA1UECBMG SXNyYWVsMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSMwIQYDVQQLExpTZWN1cmUgQ2VydGlm aWNhdGUgU2lnbmluZzEvMC0GA1UEAxMmU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEVtYWls IEZyZWUgQ0ExITAfBgkqhkiG9w0BCQEWEmFkbWluQHN0YXJ0Y29tLm9yZwIDAXiqMIHKBgsq hkiG9w0BCRACCzGBuqCBtzCBrzELMAkGA1UEBhMCSUwxDzANBgNVBAgTBklzcmFlbDEWMBQG A1UEChMNU3RhcnRDb20gTHRkLjEjMCEGA1UECxMaU2VjdXJlIENlcnRpZmljYXRlIFNpZ25p bmcxLzAtBgNVBAMTJlN0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBFbWFpbCBGcmVlIENBMSEw HwYJKoZIhvcNAQkBFhJhZG1pbkBzdGFydGNvbS5vcmcCAwF4qjANBgkqhkiG9w0BAQEFAASC AQCKSlBDU3DNzAX4dBdkDXjjuW/uvhu9YxEWBX8fr2eo/ZszU2tjlP3bzD7DdhCeoesluCfj 6OS08erH8cpUMducQ6mYO6Vvo0OAwSjxX9qCdjhAiw35O5lfsH1iZZLhlJ3/86P+yrg8StfK 6Mv37Z8GQSnEtPRAhIsDUW/dEOLpIytWX5+01CwpcyTGM/ezRrq52eefyGS5yxkP1PGV28/V sXVVfypwAwvAqNaU/iTTEiZ/FPdhEZzIT2uIjlPuXa6yCj4ZZs7yJO2IVOvialCDytM0fPKh 9IY/MrEOpeaZ3bg9a6ZmoZZWAXuqbsk/XPukmA6fSviTl8fBRVFMYdQJAAAAAAAA --------------ms030308090901030403020309-- From discuss-bounces@apps.ietf.org Wed Dec 19 12:39:08 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J52se-0006r9-Jk; Wed, 19 Dec 2007 12:38:52 -0500 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1IzJiK-0003wp-Ug for discuss-confirm+ok@megatron.ietf.org; Mon, 03 Dec 2007 17:24:32 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzJiK-0003wU-Kd for discuss@apps.ietf.org; Mon, 03 Dec 2007 17:24:32 -0500 Received: from [2001:838:378:0:211:9ff:fe2c:e28e] (helo=turner.dave.cridland.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IzJiF-0008UK-Kz for discuss@apps.ietf.org; Mon, 03 Dec 2007 17:24:32 -0500 Received: from peirce.dave.cridland.net ([217.155.137.61]) by turner.dave.cridland.net (submission) via TCP with ESMTPA id ; Mon, 3 Dec 2007 22:24:04 +0000 X-SMTP-Protocol-Errors: PIPELINING Subject: Re: I-D Action:draft-newman-email-subaddr-01.txt References: <20071203094351.GA19449@nic.fr> In-Reply-To: <20071203094351.GA19449@nic.fr> MIME-Version: 1.0 Message-Id: <2639.1196720643.545129@peirce.dave.cridland.net> Date: Mon, 03 Dec 2007 22:24:03 +0000 From: Dave Cridland To: Stephane Bortzmeyer Content-Type: text/plain; delsp="yes"; charset="us-ascii"; format="flowed" X-Spam-Score: -1.4 (-) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 X-Mailman-Approved-At: Wed, 19 Dec 2007 12:38:51 -0500 Cc: Apps Discuss X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org On Mon Dec 3 09:43:51 2007, Stephane Bortzmeyer wrote: > [No discussion list indicated in the draft, trying the Application > Area general list.] > > As good as any. > I'm quite puzzled by this draft and I do not really understand what > it > normalizes or what its purpose is. > > Subaddressing isn't described anywhere, much - the closest we come is in the SIEVE subaddress extension. This is fine - as you say, it's a purely local thing - except that multiple components are involved. From an inter-domain perspective, there is nothing to do - unless you consider mailing list managers - but for the communications between the components of an MHS, there are several areas which would benefit from a consistent handling of subaddressing. > The entire idea of subaddressing is to be a local decision, only the > final MTA and/or its MDA will have to know it. Besides stuff like > RFC > 3598, there is little room for IETF work. > No, every component needs to know about it. 1) The final MTA. 2) The MDA. 3) The MUA. 4) The Submission server. The behaviour of all of these, and in particular how they interact, most certainly is within the scope of the IETF. > Some sentences in the draft are strange, in that respect. For > instance, section 4.2 says "A subaddress-aware gateway or firewall > SHOULD preserve the detail part when rewriting an address." while I > thought that the SMTP rule was much stronger: "DO NOT MESS with > addresses", and that is a general rule, it is not only for > subaddressing. > > Oh, indeed, there's lots of sentences which were much more useful a decade ago, and these days are surplus to requirements. > Apart from that, the draft puts too much emphasis on the most common > "+" (with a MTA like Postfix, it is trivial to change it - the > recipient_delimiter option, and many people do so to avoid the > problem > of broken software mentioned later). Again, the IETF should not > mention this separator, since it is a local decision. > > Now here I disagree - a common syntax for subaddressing isn't absolutely required from a technical perspective, but it makes considerable sense for subaddress-aware entities to have the same general notion of what syntax to use, to reduce configuration requirements, both for sysadmins and users alike. > Strangely enough, the draft does not talk about *the* big problem > with > subaddressing: the fact that many stupid and broken Web forms and/or > mail software do not accept them or do not handle them > properly. Certainly, an informational RFC asking to accept valid > email > addresses would be an useful document. See a good start in > http://www.linuxjournal.com/article/9585, specially the conclusion > ("There is some danger that common usage and widespread sloppy > coding > will establish a de facto standard for e-mail addresses that is more > restrictive than the recorded formal standard.") or in > http://worsethanfailure.com/Articles/Validating_Email_Addresses.aspx > (the comments are interesting, too). You're not the first to raise this, but I'm not convinced that this draft is the right place to give such advice. It would, however, be a useful place for such a draft to point to by way of example. Dave. -- Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@jabber.org - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade From discuss-bounces@apps.ietf.org Wed Dec 19 12:39:47 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J52tX-0000S7-Ob; Wed, 19 Dec 2007 12:39:47 -0500 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1IzNsM-0007RA-Bd for discuss-confirm+ok@megatron.ietf.org; Mon, 03 Dec 2007 21:51:10 -0500 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1IzNsM-0007Qz-2H for discuss@apps.ietf.org; Mon, 03 Dec 2007 21:51:10 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzNqr-0004qL-KE for discuss@apps.ietf.org; Mon, 03 Dec 2007 21:49:37 -0500 Received: from py-out-1112.google.com ([64.233.166.180]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IzNqq-0001o8-Le for discuss@apps.ietf.org; Mon, 03 Dec 2007 21:49:37 -0500 Received: by py-out-1112.google.com with SMTP id j37so7370645pyc for ; Mon, 03 Dec 2007 18:49:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; bh=1LKxWa6IZodzv/Z2EvJbwjLPzSo7W7hYIFXJALAtvL8=; b=Aci11nidhEoH52kupZ6AOYRuXwqRnOOZjxIiXxEHT3j5eVYo3tkFGP1URYhbffBkKR9ZbR8S6b3HjvMOYlAwJsTpMf/hTA+OFwaTLWwyEKD3/+gPrAnLoNPN63buA5F87SB4L/GS/8cVFmHju+2TayWaqKRZEfQXcU5S36MbM+Y= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; b=CVDCfBdJDDcNH+wXEXG5QYQ8m9OfGWUWH8r1JvJU4SbrTCfNQh13TfxH5dYBbNBfua3OOO2wQC0Q8TB23YU6BH6KfIysi3fEvvUmBRIoJQIX+fmU7wmwAMICBbXVGJQ+m4CK7HhmPDPhNzh2+wY97bsebCO2ZgWG/miIBqoGFNY= Received: by 10.65.59.11 with SMTP id m11mr17273983qbk.1196736574694; Mon, 03 Dec 2007 18:49:34 -0800 (PST) Received: by 10.65.188.16 with HTTP; Mon, 3 Dec 2007 18:49:34 -0800 (PST) Message-ID: <248bcd790712031849m75f878b0nd61bb1962d2280b7@mail.gmail.com> Date: Tue, 4 Dec 2007 04:49:34 +0200 From: "Timur Shemsedinov" To: tbray@textuality.com, Tim.Bray@sun.com, discuss@apps.ietf.org Subject: Re: My slides from the Sunday XML session In-Reply-To: <517bf110712021756v5f5d6774ya2489dcaa092e6@mail.gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_12710_1882312.1196736574685" References: <517bf110712021756v5f5d6774ya2489dcaa092e6@mail.gmail.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b X-TMDA-Confirmed: Mon, 03 Dec 2007 21:51:10 -0500 X-Mailman-Approved-At: Wed, 19 Dec 2007 12:39:46 -0500 Cc: X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org ------=_Part_12710_1882312.1196736574685 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hello, 2007-12-03, Tim Bray : > Online at http://www.tbray.org/tmp/IETF70.pdf Thanks for generalizing sight. In addition I wont to notice that it is possible to combine plain text, binary format and xml-like hierarchical language in one approach. It is possible to replace lacks of each approach with of advantages of another. My team in Research Institute of System Technologies has been using various approaches and representation forms for a long time: like XML, Jason, Binary and even own language for structured data called USP (since 1998). Having the same problems with parsing speed and some syntactic excesses as an XML have, we have got insignificant advantage in speed (20-25%) and the size (15-20%). However, loving optimization, we were asked by a question of improvement of this language. Now we have so simple and obvious structure that I don't know why it has taken a lot of time. Example: 1: Node1:Class1 Field1[value1] Field2[Value2] Link1 Set1{item1,item2,item3} 2: SubNode1 Field3[value3] Set2{} Set3{item4,item5} Link2 Field4[value4] 2: SubNode2 Field5[value5] Field6[value6] 3: SubSubNode1 Set4{item6,item7} Field7[value7] Field8[value8] Link3 2: SubNode3 Field9[value9] 3: SubSubNode2:Class2,Class3 Field10[value10] Link4 Comments: - Each node of a tree in a new line - Numbers in the beginning of a line is a hierarchy level of node, i.e. in this example we have tree: Node1 SubNode1 SubNode2 SubSubNode1 SubNode3 SubSubNode2 - Numbering hierarchy gives us two advantages at once: it is possible escape analyzing quantity of open/close blocks, as in: or (...(...(...)...)...(...)...) and it gives us possibility to skip entire branch of tree only with one substring find operation - This format does not concede Binary on brevity. For example, here is binary analogue: [Level 4 bytes][Name][0x00][Class][0x00][FieldName][0x00][Value][0x00][0x13][0x10]... So, full "Binarization" gives no advantage in size or speed, neither in brevity nor in simplicity of syntactic analysis. This approach is tested on applications where the given structure is used not only as an input data format but also as data representation in memory. Besides we use this format for ours network protocols and even have made a databases management system which stores data in this format, placing everyone node in one or more memory page. DBMS organizes indexing, search and fast binding together data of required nodes. So data storage format through network packets (without extra repacking) is direct hits the client application memory. -Timur ------=_Part_12710_1882312.1196736574685 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
Hello,

2007-12-03, Tim Bray <tbray@textuality.com >:
> Online at   http://www.tbray.org/tmp/IETF70.pdf

Thanks for generalizing sight. In addition I wont to notice that it is possible to combine plain text, binary format and xml-like hierarchical language in one approach. It is possible to replace lacks of each approach with of advantages of another.

My team in Research Institute of System Technologies has been using various approaches and representation forms for a long time: like XML, Jason, Binary and even own language for structured data called USP (since 1998). Having the same problems with parsing speed and some syntactic excesses as an XML have, we have got insignificant advantage in speed (20-25%) and the size (15-20%). However, loving optimization, we were asked by a question of improvement of this language. Now we have so simple and obvious structure that I don't know why it has taken a lot of time.

Example:
1: Node1:Class1 Field1[value1] Field2[Value2] Link1<url1> Set1{item1,item2,item3}
2: SubNode1 Field3[value3] Set2{} Set3{item4,item5} Link2<url2> Field4[value4]
2: SubNode2 Field5[value5] Field6[value6]
3: SubSubNode1 Set4{item6,item7} Field7[value7] Field8[value8] Link3<url3>
2: SubNode3 Field9[value9]
3: SubSubNode2:Class2,Class3 Field10[value10] Link4<url4>

Comments:  
- Each node of a tree in a new line
- Numbers in the beginning of a line is a hierarchy level of node, i.e. in this example we have tree:  
   Node1
     SubNode1
     SubNode2
       SubSubNode1
     SubNode3
       SubSubNode2
- Numbering hierarchy gives us two advantages at once: it is possible escape analyzing quantity of open/close blocks, as in:
<tag1><tag2><tag1></tag1></tag2><tag2></tag2></tag1>
or
(...(...(...)...)...(...)...)
and it gives us possibility to skip entire branch of tree only with one substring find operation  
- This format does not concede Binary on brevity. For example, here is binary analogue:  
[Level 4 bytes][Name][0x00][Class][0x00][FieldName][0x00][Value][0x00][0x13][0x10]...  
So, full "Binarization" gives no advantage in size or speed, neither in brevity nor in simplicity of syntactic analysis.

This approach is tested on applications where the given structure is used not only as an input data format but also as data representation in memory. Besides we use this format for ours network protocols and even have made a databases management system which stores data in this format, placing everyone node in one or more memory page. DBMS organizes indexing, search and fast binding together data of required nodes. So data storage format through network packets (without extra repacking) is direct hits the client application memory.

-Timur

 ------=_Part_12710_1882312.1196736574685-- From discuss-bounces@apps.ietf.org Wed Dec 19 12:39:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J52tX-0000Sd-Tm; Wed, 19 Dec 2007 12:39:47 -0500 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1J1ol4-0004fD-5W for discuss-confirm+ok@megatron.ietf.org; Mon, 10 Dec 2007 14:57:42 -0500 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1J1ol3-0004ez-RS for discuss@apps.ietf.org; Mon, 10 Dec 2007 14:57:41 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J1obb-0000VQ-PC for discuss@apps.ietf.org; Mon, 10 Dec 2007 14:47:55 -0500 Received: from m1.imap-partners.net ([64.13.152.131]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J1oba-0002FY-A4 for discuss@apps.ietf.org; Mon, 10 Dec 2007 14:47:55 -0500 Received: from lust.indecency.org (m780f36d0.tmodns.net [208.54.15.120]) by m1.imap-partners.net (MOS 3.8.4-GA) with ESMTP id AIG05276 (AUTH admin@network-heretics.com) for discuss@apps.ietf.org; Mon, 10 Dec 2007 11:46:16 -0800 (PST) Message-ID: <475D977F.9050308@network-heretics.com> Date: Mon, 10 Dec 2007 11:46:07 -0800 From: Keith Moore User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: Tony Finch Subject: Re: interop problems with getaddrinfo() address selection References: <200712062020.PAA16213@Sparkle.Rodents.Montreal.QC.CA> <475B0ABC.5090806@cs.utk.edu> <475C5047.3010807@cs.utk.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a X-TMDA-Confirmed: Mon, 10 Dec 2007 14:57:41 -0500 X-Mailman-Approved-At: Wed, 19 Dec 2007 12:39:46 -0500 Cc: der Mouse , discuss@apps.ietf.org X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org >> As for DNS randomization, it's never been reasonable to expect an >> application to try each of several addresses in the order returned by >> DNS. >> > > That has been the de facto standard behaviour for over 10 years (though > before getaddrinfo they only tried the first). IIRC, very old versions of gethostbyname() only returned a single address, but this was fixed in most platforms long before IPv6. It was still up to the application to reference h_addr_list rather than h_addr, and to choose from the list of returned addresses. > A lot of sites are going to > be rather upset if wide deployment of RFC 3484 suddenly breaks their > service architecture. > yes, they'll be upset, though I wouldn't pin the blame on RFC 3484. and actually I'd be surprised if the sites pinned the blame on RFC 3484 either. it seems more likely that they'd just blame IPv6. as for their "service architecture", expecting everyone else in the Internet to do things your way has always been risky. Keith p.s. I wouldn't have much of a problem with clarifying a successor to RFC 3484 in this regard, though IMHO getaddrinfo() is so messed up that it really needs to be scrapped. yes, I realize this would be a PR disaster. From discuss-bounces@apps.ietf.org Wed Dec 19 12:39:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J52tY-0000UU-4K; Wed, 19 Dec 2007 12:39:48 -0500 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1J2san-0005hg-W3 for discuss-confirm+ok@megatron.ietf.org; Thu, 13 Dec 2007 13:15:29 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2san-0005hP-79 for discuss@apps.ietf.org; Thu, 13 Dec 2007 13:15:29 -0500 Received: from kiwi.cs.ucla.edu ([131.179.128.19]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J2sak-00047X-Re for discuss@apps.ietf.org; Thu, 13 Dec 2007 13:15:29 -0500 Received: from [131.179.33.196] (Cs-33-196.CS.UCLA.EDU [131.179.33.196]) by kiwi.cs.ucla.edu (8.13.8+Sun/8.13.8/UCLACS-6.0) with ESMTP id lBDIFPhh009359; Thu, 13 Dec 2007 10:15:25 -0800 (PST) In-Reply-To: <761895B3-653F-4F15-BAA5-8528ACC62617@osafoundation.org> References: <761895B3-653F-4F15-BAA5-8528ACC62617@osafoundation.org> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Lixia Zhang Subject: Re: Position papers due Dec 14 Date: Thu, 13 Dec 2007 10:15:29 -0800 To: Lisa Dusseault X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab X-Mailman-Approved-At: Wed, 19 Dec 2007 12:39:46 -0500 Cc: Apps Discuss , Chris Newman , IAB IAB , iesg@ietf.org X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org On Dec 13, 2007, at 9:36 AM, Lisa Dusseault wrote: > Remember brief position papers should be sent to Chris and me and/ > or the Apps Discuss list by end of day (anywhere) Dec 14. > > thanks! > Lisa > > On Nov 15, 2007, at 2:03 PM, Lisa Dusseault wrote: > >> >> On Feb 11 and 12, there will be an Applications Area Architecture >> workshop somewhere in the Bay Area. I just noticed that this runs into conflict with E2E RG meeting in Boston (Feb 12-13), but hopefully there is little, if any, overlap between the participants of the two meetings. >> We hope to nail down a venue once we've got a better idea of >> attendance. We are going to look for a host, but if there are a >> few expenses not covered, we may ask for a few 100$ attendance >> fee. If we need to charge a small fee we'll ask in advance of the >> actual meeting. >> >> Position papers are required of all attendees by Dec 14. These >> should be a few pages of text on some topic related to >> Applications area architectural issues. Since the group of >> attendees is expected to span HTTP and AtomPub, email, IM, >> calendaring, directories and more, issues should be of interest to >> more than one of these groups. Some existing Applications >> architecture "modules" that already are reused include SASL, >> URLs, MIME types, XML and XML schemas and namespaces, HTTP as a >> substrate, TLS, ABNF, BEEP. >> >> A position paper could describe a problem or make a proposal to >> solve a problem. The paper could be a prelude to an I-D of any >> kind or to a WG charter, or might simply educate and persuade. An >> ideal position paper would seed new work or make progress towards >> solving a problem that would benefit Apps protocol designers, >> implementors or users. >> >> Participants may send position papers directly to Lisa and Chris, >> although you can send position papers directly to the Apps Discuss >> list (we'll be circulating the papers publicly anyway). >> >> Since the due date for papers is Dec 14, if you'd like to flesh >> out an idea, the Vancouver IETF meeting might be a handy place to >> grab people and do so. >> >> In advance of Dec 14, we'd still appreciate early RSVPs. >> >> Lisa >> >> > > From discuss-bounces@apps.ietf.org Sun Dec 23 18:58:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J6ahm-00067R-SY; Sun, 23 Dec 2007 18:58:02 -0500 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1J6ahl-00067M-KH for discuss-confirm+ok@megatron.ietf.org; Sun, 23 Dec 2007 18:58:01 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J6ahl-00067E-AL for discuss@apps.ietf.org; Sun, 23 Dec 2007 18:58:01 -0500 Received: from outbound-mail-04.bluehost.com ([69.89.21.14]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1J6ahj-0006Xt-Nh for discuss@apps.ietf.org; Sun, 23 Dec 2007 18:58:01 -0500 Received: (qmail 23843 invoked by uid 0); 23 Dec 2007 23:57:58 -0000 Received: from unknown (HELO box7.bluehost.com) (69.89.30.147) by mailproxy1.bluehost.com with SMTP; 23 Dec 2007 23:57:58 -0000 Received: from c-98-207-19-194.hsd1.ca.comcast.net ([98.207.19.194] helo=KingsMountain.com) by box7.bluehost.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1J6ahg-0004Yh-Th for discuss@apps.ietf.org; Sun, 23 Dec 2007 16:57:56 -0700 X-Mailer: exmh version 2.7.2 01/07/2005 (debian 1:2.7.2-7) with nmh-1.1 Subject: fyi: Technical Comparison: OpenID and SAML (Draft 05) To: discuss@apps.ietf.org From: jeff.hodges@kingsmountain.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 23 Dec 2007 15:58:06 -0800 X-Identified-User: {32571:box7.bluehost.com:kingsmou:kingsmountain.com} {sentby:bopbeforesmtp 98.207.19.194 authed with kingsmountain.com} X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Message-Id: X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org Of possible interest... (Draft) Technical Comparison: OpenID and SAML Technical Comparison: OpenID and SAML - Draft 05 http://identitymeme.org/doc/draft-hodges-saml-openid-compare-05.html Abstract This document presents a technical comparison of the OpenID Authentication protocol and the Security Assertion Markup Language (SAML) Web Browser SSO Profile and the SAML framework itself. Topics addressed include design centers, terminology, specification set contents and scope, user identifier treatment, web single sign-on profiles, trust, security, identity provider discovery mechanisms, key agreement approaches, as well as message formats and protocol bindings. An executive summary targeting various audiences, and presented from the perspectives of end-users, implementors, tna deployers, is provided. We do not attempt to assign relative value between OpenID and SAML, e.g. which is "better"; rather, it attempts to present an objective technical comparison. =JeffH