From nobody Mon Oct 12 11:08:23 2015 Return-Path: X-Original-To: appsdir@ietfa.amsl.com Delivered-To: appsdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8ED221ACDF9 for ; Mon, 12 Oct 2015 11:08:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.323 X-Spam-Level: * X-Spam-Status: No, score=1.323 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_37=0.6, RCVD_IN_DNSWL_LOW=-0.7] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kKaeB7-Gad2D for ; Mon, 12 Oct 2015 11:08:20 -0700 (PDT) Received: from mail-ig0-f174.google.com (mail-ig0-f174.google.com [209.85.213.174]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AB6AA1ACDDF for ; Mon, 12 Oct 2015 11:08:20 -0700 (PDT) Received: by igbni9 with SMTP id ni9so43256191igb.1 for ; Mon, 12 Oct 2015 11:08:20 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to :content-type; bh=M9TpXh0wJDwBNutS6JbVV2tbvwB7JgeCSmWxVA7ADtY=; b=A9FmWEIOtPW6ki/d/kaaBWXAoyQHhxKunYdTtOrEQqs1ixY8B6L3ma/k3iJM3KbxPg neRxDG7d2YDNoiQH8zm/PEwbeyVOUo6vOJgPm6PJwnwjBR0ygqpeRr3Ug+8Dy4co9bbc gGbehFFMuZB84uFbz6gx1SMgNFxLltTf6ctyAI2R/fx0n9Pso7O18dU7a7XIeKS9zI4e PvBCfpoDc1KYqgW1RFfeX37ki427+evMUkTFacCHhWZfWNQ6QgRTQ58yGT3d3a8jBHZD R0np1KWlflTdI+hvbSosjYlrZqOOyd6SlfsWvXqQC9Xhc9tBwcIdoYDcTwwrKqMjhFGH u0Ag== X-Gm-Message-State: ALoCoQnRZ8uiigCu2DoJ24h0XQxrQwMIY212hqi5xTmZSIfPbRj3+HYDDIrD2oDCCKMH6gK5XVPH X-Received: by 10.50.57.102 with SMTP id h6mr13648321igq.29.1444673299972; Mon, 12 Oct 2015 11:08:19 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.30.4 with HTTP; Mon, 12 Oct 2015 11:08:00 -0700 (PDT) X-Originating-IP: [24.84.248.61] From: Tim Bray Date: Mon, 12 Oct 2015 11:08:00 -0700 Message-ID: To: The IESG , "appsdir@ietf.org" , draft-ietf-ecrit-additional-data.all@tools.ietf.org Content-Type: multipart/alternative; boundary=047d7bdc165edca7e30521ec3642 Archived-At: Subject: [appsdir] Apps Directorate review of draft-ietf-ecrit-additional-data-36 X-BeenThere: appsdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Apps Area Review List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Oct 2015 18:08:22 -0000 --047d7bdc165edca7e30521ec3642 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I have reviewed this document on behalf of the Apps Directorate. This review covers mostly technical matters, in particular related to the XML message structure. This document describes a variety of XML data structures for use in Public Safety applications, along with MIME and SIP message packaging techniques. There is one issue which will require consideration at the IETF level: Although these messages are acknowledged to contain highly private information, the specification allows the use of plain-text transmission because, and I quote: =E2=80=9Cas an emergency call, it is more important f= or the call to go through than for it to be protected=E2=80=9D. Which is OK as lo= ng as there is a basis of trust that the notion of =E2=80=9Cemergency call=E2=80= =9D is not being used by either criminal elements or abusive government regimes. Is the specification=E2=80=99s language acceptable in the context of RFC7258? That aside, the message framework described here seems well-thought-through and ready for publication. However, I recommend consideration of the following changes for improving the safety and usability of this framework. 1. Must-Ignore policy The last paragraph of section 6 emphasizes =E2=80=9CThe general principle t= hat applies to emergency calls is that it is more important for the call to go through than for for everything to be correct=E2=80=9D. There is one part= icular case related to both this and to the evolution of this format over time. While the draft emphasizes that evolving this message format is difficult, experience suggests that technology providers succumb to the temptation to =E2=80=9Cenrich=E2=80=9D message formats by adding new elements. The standard way to avoid breakage as a consequence, and to facilitate future evolution, is with a =E2=80=9CMust-Ignore=E2=80=9D policy, as discus= sed, for example in RFC7493, see https://tools.ietf.org/html/rfc7493#section-4.2 I think it would be beneficial if, early in the draft, there were a statement of principle that when a receiving implementation encounters an XML element or attribute that it does not recognize, it MUST NOT regard this as a fatal error and MUST NOT alter its behavior. Spelunking through the schema I observe occasional occurrences of xs:any, which suggests some thought has been given to this, but being explicit at the prose level would be beneficial. 2. Schema Choice I think there is fairly widespread consensus in the community of document structure designers that Relax-NG is a schema framework which is vastly superior to XML Schema; capable of modelling more real-world data structures more cleanly and readably. Since there are high-quality automatic conversion tools, perhaps the schema could be offered as Relax-NG= ? Also, I didn=E2=80=99t find any mention of whether the assertions in the sc= hema are to be considered normative, i.e. what is the consequence of a message arrives which does not conform to that schema? As a general principle the IETF has preferred specifications in which the normative English prose is self-contained and doesn=E2=80=99t require understanding a schema. 3. Namespaces The examples could be made considerably more human readable with the wider use of default namespaces. This is already done for vcard examples, but why not extend it. All those colons are reader-hostile. 4. com:Comment Can this contain any markup, for example HTML? This may be explicit in the schema but it's not in the human-readable text. --047d7bdc165edca7e30521ec3642 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I h= ave reviewed this document on behalf of the Apps Directorate.=C2=A0 This re= view covers mostly technical matters, in particular related to the XML mess= age structure.
=
This docum= ent describes a variety of XML data structures for use in Public Safety app= lications, along with MIME and SIP message packaging techniques.

There is one issue which will requi= re consideration at the IETF level: Although these messages are acknowledge= d to contain highly private information, the specification allows the use o= f plain-text transmission because, and I quote: =E2=80=9Cas an emergency ca= ll, it is more important for the call to go through than for it to be prote= cted=E2=80=9D.=C2=A0 Which is OK as long as there is a basis of trust that = the notion of =E2=80=9Cemergency call=E2=80=9D is not being used by either = criminal elements or abusive government regimes.=C2=A0 Is the specification= =E2=80=99s language acceptable in the context of RFC7258?

That aside, the message framework descri= bed here seems well-thought-through and ready for publication.=C2=A0 Howeve= r, I recommend consideration of the following changes for improving the saf= ety and usability of this framework.

1. Must-Ignore policy

The last paragraph of section 6 emphasizes =E2=80=9CThe general = principle that applies to emergency calls is that it is more important for = the call to go through than for for everything to be correct=E2=80=9D. =C2= =A0 There is one particular case related to both this and to the evolution = of this format over time.=C2=A0 While the draft emphasizes that evolving th= is message format is difficult, experience suggests that technology provide= rs succumb to the temptation to =E2=80=9Cenrich=E2=80=9D message formats by= adding new elements.

The= standard way to avoid breakage as a consequence, and to facilitate future = evolution, is with a =E2=80=9CMust-Ignore=E2=80=9D policy, as discussed, fo= r example in RFC7493, see=C2=A0https://tools.ietf.org/html/rfc7493#section-4.2

I think it would be beneficial= if, early in the draft, there were a statement of principle that when a re= ceiving implementation encounters an XML element or attribute that it does = not recognize, it MUST NOT regard this as a fatal error and MUST NOT alter = its behavior.
<= br>
Spelunking = through the schema I observe occasional occurrences of xs:any, which sugges= ts some thought has been given to this, but being explicit at the prose lev= el would be beneficial.

2= . Schema Choice

I think t= here is fairly widespread consensus in the community of document structure = designers that Relax-NG is a schema framework which is vastly superior to X= ML Schema; capable of modelling more real-world data structures more cleanl= y and readably.=C2=A0 Since there are high-quality automatic conversion too= ls, perhaps the schema could be offered as Relax-NG?

Also, I didn=E2=80=99t find any mention of whet= her the assertions in the schema are to be considered normative, i.e. what = is the consequence of a message arrives which does not conform to that sche= ma?=C2=A0 As a general principle the IETF has preferred specifications in w= hich the normative English prose is self-contained and doesn=E2=80=99t requ= ire understanding a schema.

3. Namespaces

The exam= ples could be made considerably more human readable with the wider use of d= efault namespaces.=C2=A0 This is already done for vcard examples, but why n= ot extend it.=C2=A0 All those colons are reader-hostile.

4. com:Comment

Can this contain any markup, for exampl= e HTML?=C2=A0 This may be explicit in the schema but it's not in the hu= man-readable text.

--047d7bdc165edca7e30521ec3642-- From nobody Mon Oct 12 12:16:53 2015 Return-Path: X-Original-To: appsdir@ietfa.amsl.com Delivered-To: appsdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75B2E1B34C7; Mon, 12 Oct 2015 12:16:51 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "MIME-Version" X-Spam-Flag: NO X-Spam-Score: -3.711 X-Spam-Level: X-Spam-Status: No, score=-3.711 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_37=0.6, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BD3pIQT4Uvno; Mon, 12 Oct 2015 12:16:49 -0700 (PDT) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5E12A1B357E; Mon, 12 Oct 2015 12:16:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1444677409; x=1476213409; h=message-id:in-reply-to:references:date:to:from:subject; bh=FOMLOu/79YKIfDlqgsuRswYUsTlVpUZ5x3Mt80UcWZg=; b=IhBIC8sWMiOu6NB/ny6OUdJmkAClvaYNCkOJgLMlHa7/VguWquf0rjwK m0kHUFcCQauvSax9tGUFZLsl5+iXEToMyhFwpkGuomBJNH8RRMHXCzZmC 89IivfhddsyZscc0ty2v+GVyn86v0USvUdFnmvDeQ0A0xNqCW8mV95eIX M=; X-IronPort-AV: E=McAfee;i="5700,7163,7952"; a="143316086" Received: from ironmsg02-l.qualcomm.com ([172.30.48.16]) by wolverine01.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 12 Oct 2015 12:16:48 -0700 X-IronPort-AV: E=Sophos;i="5.17,674,1437462000"; d="scan'208";a="562357882" Received: from plus.qualcomm.com ([10.52.255.8]) by ironmsg02-L.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 12 Oct 2015 12:16:33 -0700 Received: from Ironmsg04-R.qualcomm.com (ironmsg04-R.qualcomm.com [172.30.46.18]) by plus.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id t9CJGDXS010013; Mon, 12 Oct 2015 12:16:16 -0700 X-IronPort-AV: E=Sophos;i="5.17,674,1437462000"; d="scan'208";a="1067334784" X-ojodefuego: yes Received: from unknown (HELO [192.168.5.193]) ([10.64.194.45]) by Ironmsg04-R.qualcomm.com with ESMTP; 12 Oct 2015 12:16:11 -0700 Mime-Version: 1.0 Message-Id: In-Reply-To: References: X-Mailer: Eudora for Mac OS X Date: Mon, 12 Oct 2015 12:12:56 -0700 To: Tim Bray , The IESG , "appsdir@ietf.org" , draft-ietf-ecrit-additional-data.all@tools.ietf.org From: Randall Gellens Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Random-Sig-Tag: 1.0b28 X-Random-Sig-Tag: 1.0b28 X-Random-Sig-Tag: 1.0b28 X-Random-Sig-Tag: 1.0b28 X-Random-Sig-Tag: 1.0b28 Archived-At: Subject: Re: [appsdir] Apps Directorate review of draft-ietf-ecrit-additional-data-36 X-BeenThere: appsdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Apps Area Review List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Oct 2015 19:16:51 -0000 Hi Tim, Thanks for your review. I appreciate the effort that went into it. As it happens, the document went through IETF Last Call some time back, and cleared the last IESG DISCUSS a week or so ago, and was approved by the IESG today. Luckily, your review did not identify any issues that require document changes. Please see in-line for more details. At 11:08 AM -0700 10/12/15, Tim Bray wrote: > I have reviewed this document on behalf of the Apps Directorate. > This review covers mostly technical matters, in particular related > to the XML message structure. > > This document describes a variety of XML data structures for use in > Public Safety applications, along with MIME and SIP message > packaging techniques. > > There is one issue which will require consideration at the IETF > level: Although these messages are acknowledged to contain highly > private information, the specification allows the use of plain-text > transmission because, and I quote: "as an emergency call, it is > more important for the call to go through than for it to be > protected". Which is OK as long as there is a basis of trust that > the notion of "emergency call" is not being used by either criminal > elements or abusive government regimes. Is the specification's > language acceptable in the context of RFC7258? The information will only be sent by a device on calls that the device knows are emergency calls. Likewise, service providers in the call path will only include the information when processing calls initiated as emergency calls. > That aside, the message framework described here seems > well-thought-through and ready for publication. However, I > recommend consideration of the following changes for improving the > safety and usability of this framework. > > 1. Must-Ignore policy > > The last paragraph of section 6 emphasizes "The general principle > that applies to emergency calls is that it is more important for > the call to go through than for for everything to be correct". > There is one particular case related to both this and to the > evolution of this format over time. While the draft emphasizes > that evolving this message format is difficult, experience suggests > that technology providers succumb to the temptation to "enrich" > message formats by adding new elements. > > The standard way to avoid breakage as a consequence, and to > facilitate future evolution, is with a "Must-Ignore" policy, as > discussed, for example in RFC7493, > see https://tools.ietf.org/html/rfc7493#section-4.2 > > I think it would be beneficial if, early in the draft, there were a > statement of principle that when a receiving implementation > encounters an XML element or attribute that it does not recognize, > it MUST NOT regard this as a fatal error and MUST NOT alter its > behavior. This is already a principle of the mechanism. The document already says that entities use the "purpose" parameter values of the Call-Info header fields to identify the data structures available, and access those data structures they are interested in (by local policy). Ipso facto, an entity will not be interested in an unknown data structure, hence, unknown data structures are ignored. Part of the reason for this, as explained in the document, is that some elements may contain information that carries regulatory, legal, or other implications (e.g., medical information), so entities will only want to access structures that they are prepared to handle. > > Spelunking through the schema I observe occasional occurrences of > xs:any, which suggests some thought has been given to this, but > being explicit at the prose level would be beneficial. I think the current text is sufficient; if you disagree, it is possible to add editorial text during AUTH48, which I am happy to consider if you suggest exactly where the text now is deficient. > > 2. Schema Choice > > I think there is fairly widespread consensus in the community of > document structure designers that Relax-NG is a schema framework > which is vastly superior to XML Schema; capable of modelling more > real-world data structures more cleanly and readably. Since there > are high-quality automatic conversion tools, perhaps the schema > could be offered as Relax-NG? It's too late to make any technical changes. > > Also, I didn't find any mention of whether the assertions in the > schema are to be considered normative, i.e. what is the consequence > of a message arrives which does not conform to that schema? As a > general principle the IETF has preferred specifications in which > the normative English prose is self-contained and doesn't require > understanding a schema. The English prose description of the structures is sufficient, and multiple reviews have shown that the English prose description of the structures is consistent with the schemas (we went through a lot of work to check this). Of course it is possible that there is some prose that does not match its schema and that none of the reviewers or authors noticed. If so, this can be addressed by an errata. The general principle that the call go through says that the call won't be failed because of it. Each entity is free to either process non-confirming structures or not, and this is the case if the structure does not confirm to the prose, schema, or nether (should there be any instances where they differ). > > 3. Namespaces > > The examples could be made considerably more human readable with > the wider use of default namespaces. This is already done for > vcard examples, but why not extend it. All those colons are > reader-hostile. Yes, this would have been worth considering had the review arrived a few weeks ago. > > 4. com:Comment > > Can this contain any markup, for example HTML? This may be > explicit in the schema but it's not in the human-readable text. The schema permits any text valid for the xml 'string' type, so while markup is syntactically permitted, the description says that this is human-readable text and not intended to be machine-readable, so I'd say that strongly discourages using markup. I think very few people would try to claim HTML (or XML for that matter) to be human-readable. Thanks again for your review. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- Creativity is just connecting things. [C]reative people [are] able to connect experiences they've had and synthesize new things [because] they've had more experiences or ... have thought more about their experiences than other people. ... A lot of people ... don't have enough dots to connect, and they end up with very linear solutions without a broad perspective on the problem. The broader one's understanding of the human experience, the better design we will have. --Steve Jobs, Wired Magazine, February, 1996 From nobody Tue Oct 20 06:04:23 2015 Return-Path: X-Original-To: appsdir@ietfa.amsl.com Delivered-To: appsdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 213B21A039E for ; Tue, 20 Oct 2015 06:04:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m-RvzOD1ps6l for ; Tue, 20 Oct 2015 06:04:13 -0700 (PDT) Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 734D61A0064 for ; Tue, 20 Oct 2015 06:04:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9646; q=dns/txt; s=iport; t=1445346252; x=1446555852; h=references:subject:to:cc:from:message-id:date: mime-version:in-reply-to; bh=Vnrvy4IjRRuXBmTI8RJl9QTQg3Fummidm1IzQMhGgVM=; b=eF3muwlbZajD1wlkwoXgF8+lAqhYaSpLzifbIJOfI3i82Lg2vMVhxrVm T43szvZrkr3gOs8AaZUfi46Al1xI8Gwqu+fCNWmPHysNw6ohZKmWGZgeU xqGTluGhgc60t6SMoTfQKYiRQd1roz1CJ13MJJBwamq1mHBY3qpx4tbY4 4=; X-Files: signature.asc : 481 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0CrBAAWOyZW/xbLJq1ehApvwAchhX0CggwBAQEBAQGBAAuELgEBBCNVARAsFgsCAgkDAgECAUUGDQgBAYgsDbBokxoBAQEBAQEBAQEBAQEBAQEBAQESCYt1hQ0HgmmBRQEEliR6gVSBYWqIBoFYSIN3gwGTCWOEBTw0hWcBAQE X-IronPort-AV: E=Sophos;i="5.17,707,1437436800"; d="asc'?eml'208?scan'208,208";a="605816487" Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 20 Oct 2015 13:04:10 +0000 Received: from [10.61.162.242] ([10.61.162.242]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id t9KD4AbG029222; Tue, 20 Oct 2015 13:04:10 GMT References: <20151019193955.7161.67975.idtracker@ietfa.amsl.com> To: "appsdir@ietf.org" From: Eliot Lear X-Enigmail-Draft-Status: N1110 X-Forwarded-Message-Id: <20151019193955.7161.67975.idtracker@ietfa.amsl.com> Message-ID: <56263BC9.5050706@cisco.com> Date: Tue, 20 Oct 2015 15:04:09 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <20151019193955.7161.67975.idtracker@ietfa.amsl.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="KvmBldNQFuU2TxncxteRTO1kwBgoWSk9i" Archived-At: Cc: Spencer Dawkins , David Black Subject: [appsdir] Review request: draft-ietf-tsvwg-circuit-breaker-07.txt X-BeenThere: appsdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Apps Area Review List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Oct 2015 13:04:20 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --KvmBldNQFuU2TxncxteRTO1kwBgoWSk9i Content-Type: multipart/mixed; boundary="------------000106030802080104050106" This is a multi-part message in MIME format. --------------000106030802080104050106 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi everyone, The attached draft talks about a "circuit breaker" that could sit at certain points in the network to prevent congestion collapse on otherwise uncontrolled flows. This HAPPENS today and is the normal form of a policing function in a QoS model, and it's great that Gory is documenting it. However, circuit breakers can and do cause applications problems (David can correct me but I think this was part of the impetus of the draft, in fact). A misbehaving circuit breaker in particular might really throw people for a loop. I am seeking a reviewer, and would like to double-team on this draft with that person to get a timely review done for Gory and the TSVWG. Do I have any takers? Please let me know by tomorrow. I'd like to complete work by the end of next week, before people get to Yokohama, if at all possible, and I'm happy to take the first cut (or not). Eliot --------------000106030802080104050106 Content-Type: message/rfc822; name="[tsvwg] I-D Action: draft-ietf-tsvwg-circuit-breaker-07_txt.eml" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename*0="[tsvwg] I-D Action: draft-ietf-tsvwg-circuit-breaker-07_txt."; filename*1="eml" X-Mozilla-Keys: Received: from xch-aln-002.cisco.com (173.36.7.12) by xch-aln-005.cisco.com (173.36.7.15) with Microsoft SMTP Server (TLS) id 15.0.1104.5 via Mailbox Transport; Mon, 19 Oct 2015 14:40:30 -0500 Received: from xch-rcd-020.cisco.com (173.37.102.30) by XCH-ALN-002.cisco.com (173.36.7.12) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Mon, 19 Oct 2015 14:40:29 -0500 Received: from xch-aln-001.cisco.com (173.36.7.11) by XCH-RCD-020.cisco.com (173.37.102.30) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Mon, 19 Oct 2015 14:40:23 -0500 Received: from rcdn-iport-4.cisco.com (173.37.86.75) by mail.cisco.com (173.36.7.11) with Microsoft SMTP Server (TLS) id 15.0.1104.5 via Frontend Transport; Mon, 19 Oct 2015 14:40:23 -0500 Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by rcdn-iport-4.cisco.com with ESMTP; 19 Oct 2015 19:40:40 +0000 Received: from alln-inbound-c.cisco.com (alln-inbound-c.cisco.com [173.37.147.233]) by rcdn-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id t9JJeaLT004013; Mon, 19 Oct 2015 19:40:39 GMT IronPort-PHdr: 9a23:YZqrwRTr8Rqm2msFKyoFpgdXNdpsv+yvbD5Q0YIujvd0So/mwa64YxaN2/xhgRfzUJnB7Loc0qyN4/ymBDxLuM7b+DBaKdoXCE9D0Z1X1yUbQ+e7SmTDZMbwaCI7GMkQHHRExFqcdXZvJcDlelfJqWez5zNBUj/2NA5yO/inUtWK15f/hKiP/YbOaVBNjTu5fbQgMA6osgqUrMQPnIZ5No4wxwfH5HxSdLNN2GlqKFmPygv6/dq655V58i5d6M8n7NNKBKXmY7wjH/sfEys5dWE4+MOtsgPMCg6G538ZW2NRlQJUAg/D91bmRYnuvXjGsb8p2WyWeMTwS7cpXz+vx6ZmVBGujz0IYW0X6mbS3812kK9Bph+94hBlyoDIe6mUOeZwOKTHcoBJDVFdV9pcAnQSSri3aJECWrIM Received-SPF: Pass (alln-inbound-c.cisco.com: domain of tsvwg-bounces@ietf.org designates 2001:1900:3001:11::2c as permitted sender) identity=mailfrom; client-ip=2001:1900:3001:11::2c; receiver=alln-inbound-c.cisco.com; envelope-from="tsvwg-bounces@ietf.org"; x-sender="tsvwg-bounces@ietf.org"; x-conformance=spf_only; x-record-type="v=spf1" Received-SPF: None (alln-inbound-c.cisco.com: no sender authenticity information available from domain of postmaster@mail.ietf.org) identity=helo; client-ip=2001:1900:3001:11::2c; receiver=alln-inbound-c.cisco.com; envelope-from="tsvwg-bounces@ietf.org"; x-sender="postmaster@mail.ietf.org"; x-conformance=spf_only Authentication-Results: alln-inbound-c.cisco.com; spf=Pass smtp.mailfrom=tsvwg-bounces@ietf.org; spf=None smtp.helo=postmaster@mail.ietf.org; dkim=pass (signature verified) header.i=@ietf.org X-from-outside-Cisco: 2001:1900:3001:11::2c X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A8FCAAAuRiVWlwAZASCDgISAEQAsXhkBAQEBDgEBAQUBAQGCVAF/YA++DwENgVAhCoV9gT44FAEBAQEBAQEBAg4BAQEBAQgWB0+CJiEUEAEBAQEBASYBAQEBAQEjAj4xBAIgHQEBBAopAQIDAQIGAiQCIgQCAgMBQxYYiCwMsGpxhGUBBYFyjA8BAQEBAQEBAQEBAQEBAQEBAQEBAQESBoEij0szglKBRY4MiByFGYd8CIFYSIN0liMBAYJGgh9ShWcBAQE X-IPAS-Result: A8FCAAAuRiVWlwAZASCDgISAEQAsXhkBAQEBDgEBAQUBAQGCVAF/YA++DwENgVAhCoV9gT44FAEBAQEBAQEBAg4BAQEBAQgWB0+CJiEUEAEBAQEBASYBAQEBAQEjAj4xBAIgHQEBBAopAQIDAQIGAiQCIgQCAgMBQxYYiCwMsGpxhGUBBYFyjA8BAQEBAQEBAQEBAQEBAQEBAQEBAQESBoEij0szglKBRY4MiByFGYd8CIFYSIN0liMBAYJGgh9ShWcBAQE X-IronPort-AV: E=Sophos;i="5.17,703,1437436800"; d="scan'208";a="92792420" X-Amp-Result: Clean X-Amp-File-Uploaded: False X-IronPort-Outbreak-Status: No, level 0, Unknown - Unknown Received: from mail.ietf.org ([IPv6:2001:1900:3001:11::2c]) by alln-inbound-c.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 19 Oct 2015 19:40:36 +0000 Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 631D81B2CB2; Mon, 19 Oct 2015 12:40:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1445283614; bh=CrYOoYyduaNsIpz6y5UYNlCzfAqpIwlm4AwYxGIU7z0=; h=MIME-Version:Content-Type:Content-Transfer-Encoding:From:To: Message-ID:Date:Cc:Subject:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe:Sender; b=vle/xWYSGXitGVK4Fb+bHdNy+hWH1DmSS+2HFo5lCxuFncTYIxy4+Q004WjkQpEW2 h6wYwgp1lDkhQRNk6OKYlrqOcMlV2dIuSzOwKX1UKR9WB4sSAA7WXxhh+NNLo2iYFq hfRHdpMerRC/KM/s8za9fgURe0P4Az6EzfewSB7M= X-Original-To: tsvwg@ietf.org Delivered-To: tsvwg@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 98BCB1B2C9A; Mon, 19 Oct 2015 12:39:55 -0700 (PDT) Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.6.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20151019193955.7161.67975.idtracker@ietfa.amsl.com> Date: Mon, 19 Oct 2015 12:39:55 -0700 Archived-At: Cc: tsvwg@ietf.org Subject: [tsvwg] I-D Action: draft-ietf-tsvwg-circuit-breaker-07.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tsvwg-bounces@ietf.org Sender: "tsvwg" Return-Path: tsvwg-bounces@ietf.org X-MS-Exchange-Organization-AuthSource: XCH-ALN-001.cisco.com X-MS-Exchange-Organization-AuthAs: Internal X-MS-Exchange-Organization-AuthMechanism: 10 X-MS-Exchange-Organization-Network-Message-Id: 531472d8-00a6-4b03-9d9c-08d2d8bd21b9 X-MS-Exchange-Organization-AVStamp-Enterprise: 1.0 MIME-Version: 1.0 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transport Area Working Group Working Group of the IETF. Title : Network Transport Circuit Breakers Author : Godred Fairhurst Filename : draft-ietf-tsvwg-circuit-breaker-07.txt Pages : 23 Date : 2015-10-19 Abstract: This document explains what is meant by the term "network transport Circuit Breaker" (CB). It describes the need for circuit breakers when using network tunnels, and other non-congestion controlled applications, and explains where circuit breakers are, and are not, needed. It also defines requirements for building a circuit breaker and the expected outcomes of using a circuit breaker within the Internet. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tsvwg-circuit-breaker/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-tsvwg-circuit-breaker-07 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tsvwg-circuit-breaker-07 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ --------------000106030802080104050106-- --KvmBldNQFuU2TxncxteRTO1kwBgoWSk9i Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2 iQEcBAEBCAAGBQJWJjvJAAoJEIe2a0bZ0nozlH0IAMetizT/IKF4dGa11fxOe9Zb 6iMUxz1OEkyv37kP8xychGz7XKtIDSAwdCga8nG4fl4wXhm0yLwWDtB9/vxHhDFA eG7SDmGB1ceEHUGLPHLBIMnrpObXTC9Ljjl1LL5dxDXFkgYZp3u9983U4iic69je b6UbE5AKP84W+BBuBB/Fkqa6EWFXuwMPHqqnUMbwG9c3bIH79PPma73so5Ld62HC YaccQxZ0i8w6ZSlqJTXD6oSjn6W9EPrQZ7S2rj8ramWGlm31QFRVfxoAnDUmkTNF OFRMju3nMgb+4RueMylC+n0cLzihZ9pH6Fx36yyL/HYfSpqO3g+Q2qswGGv9Cvo= =/Bj9 -----END PGP SIGNATURE----- --KvmBldNQFuU2TxncxteRTO1kwBgoWSk9i--