From acooper@cdt.org Sat Feb 23 03:47:47 2013 Return-Path: X-Original-To: architecture-discuss@ietfa.amsl.com Delivered-To: architecture-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03D2921F8519 for ; Sat, 23 Feb 2013 03:47:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.623 X-Spam-Level: X-Spam-Status: No, score=-102.623 tagged_above=-999 required=5 tests=[AWL=-0.024, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pve-j2RecUE1 for ; Sat, 23 Feb 2013 03:47:46 -0800 (PST) Received: from mail.maclaboratory.net (mail.maclaboratory.net [209.190.215.232]) by ietfa.amsl.com (Postfix) with ESMTP id 3496521F8510 for ; Sat, 23 Feb 2013 03:47:46 -0800 (PST) X-Footer: Y2R0Lm9yZw== Received: from localhost ([127.0.0.1]) by mail.maclaboratory.net (using TLSv1/SSLv3 with cipher AES128-SHA (128 bits)) for architecture-discuss@ietf.org; Sat, 23 Feb 2013 06:47:45 -0500 From: Alissa Cooper Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Sat, 23 Feb 2013 06:47:44 -0500 References: <20130223114219.26311.4367.idtracker@ietfa.amsl.com> To: architecture-discuss@ietf.org Message-Id: Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: [arch-d] Fwd: New Version Notification for draft-iab-filtering-considerations-02.txt X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Feb 2013 11:47:47 -0000 FYI Begin forwarded message: > From: internet-drafts@ietf.org > Date: February 23, 2013 6:42:19 AM EST > To: acooper@cdt.org > Cc: olaf@nlnetlabs.nl, rbarnes@bbn.com > Subject: New Version Notification for = draft-iab-filtering-considerations-02.txt >=20 >=20 > A new version of I-D, draft-iab-filtering-considerations-02.txt > has been successfully submitted by Alissa Cooper and posted to the > IETF repository. >=20 > Filename: draft-iab-filtering-considerations > Revision: 02 > Title: Technical Considerations for Internet Service = Blocking and Filtering > Creation date: 2013-02-23 > Group: iab > Number of pages: 24 > URL: = http://www.ietf.org/internet-drafts/draft-iab-filtering-considerations-02.= txt > Status: = http://datatracker.ietf.org/doc/draft-iab-filtering-considerations > Htmlized: = http://tools.ietf.org/html/draft-iab-filtering-considerations-02 > Diff: = http://www.ietf.org/rfcdiff?url2=3Ddraft-iab-filtering-considerations-02 >=20 > Abstract: > The Internet is structured to be an open communications medium. = This > openness is one of the key underpinnings of Internet innovation, but > it can also allow communications that may be viewed as undesirable = by > certain parties. Thus, as the Internet has grown, so have = mechanisms > to limit the extent and impact of abusive or allegedly illegal > communications. Recently, there has been an increasing emphasis on > "blocking" and "filtering," the active prevention of such > communications. This document examines several technical approaches > to Internet content blocking and filtering in terms of their > alignment with the overall Internet architecture. In general, the > approach to content blocking and filtering that is most coherent = with > the Internet architecture is to inform endpoints about potentially > undesirable services, so that the communicants can avoid engaging in > abusive or illegal communications. >=20 >=20 >=20 >=20 > The IETF Secretariat >=20 >=20 From acooper@cdt.org Sat Feb 23 03:48:08 2013 Return-Path: X-Original-To: architecture-discuss@ietfa.amsl.com Delivered-To: architecture-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47E5E21F8836 for ; Sat, 23 Feb 2013 03:48:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.473 X-Spam-Level: X-Spam-Status: No, score=-102.473 tagged_above=-999 required=5 tests=[AWL=-0.174, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EsEDL337VEhI for ; Sat, 23 Feb 2013 03:48:07 -0800 (PST) Received: from mail.maclaboratory.net (mail.maclaboratory.net [209.190.215.232]) by ietfa.amsl.com (Postfix) with ESMTP id 92D1121F8621 for ; Sat, 23 Feb 2013 03:48:07 -0800 (PST) X-Footer: Y2R0Lm9yZw== Received: from localhost ([127.0.0.1]) by mail.maclaboratory.net (using TLSv1/SSLv3 with cipher AES128-SHA (128 bits)); Sat, 23 Feb 2013 06:47:59 -0500 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: Alissa Cooper In-Reply-To: Date: Sat, 23 Feb 2013 06:47:59 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <74157556-3608-41A4-AD4F-0789051B6CB7@cdt.org> References: To: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= X-Mailer: Apple Mail (2.1084) Cc: architecture-discuss@ietf.org Subject: Re: [arch-d] draft-iab-filtering-considerations X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Feb 2013 11:48:08 -0000 Hi Patrik, We have posted a new version: = . Some = comments are inline below. On Oct 26, 2012, at 1:58 PM, Patrik F=E4ltstr=F6m wrote: >=20 > On 26 okt 2012, at 13:32, Alissa Cooper wrote: >=20 >> The IAB is working on a document about "Technical Considerations for = Internet Service Filtering," = . = Feedback and discussion are welcome on this list. >=20 > Thanks for the pointer to this document that I have missed earlier. >=20 > First, what is the intended goal with this document? I do not really = see any recommendations in it. Is the idea to come with recommendations = on how to do blocking given there is consensus on what to block? I don't think we plan to do much more than clarify the technical = implications and trade-offs of various blocking strategies. Since = different entities that want to block things have different constraints = and motivations, I think it would be hard to make meaningful = recommendations with wide applicability. With that said, I think there = is a clear conclusion in the draft that endpoint-based blocking comes = into the least conflict with the Internet architecture. >=20 > Secondly, I think you should try to remove lots and lots of words. It = is very long at the moment and I think / feel it would be more crisp if = you manage later on to not be repetitive, and be more "to the point". Agreed. We did not do this yet given that the text is still changing = quite a bit. Hopefully on the next round we can cut it down. >=20 > Thirdly, even if this is a technical document, I think it is valuable = to explain why it is a *technical* paper. =46rom my point of view it is = because IAB has not intention on walking down the path of describing the = other half of "good blocking" which is "how to decide what to block". I = would like you at least say this, so the reader do understand this = "other piece" is also needed. We tried to clarify this in section 1. >=20 > Lastly, please have a look at the just released SSAC document SAC056 = (and the earlier SAC050) that you can find on = . I think you find some = ideas there that can help you when you do future versions of this = document. Thanks, and we have added a pointer to this. Best, Alissa >=20 > Regards, Patrik >=20 >=20 From paf@frobbit.se Sun Feb 24 05:56:25 2013 Return-Path: X-Original-To: architecture-discuss@ietfa.amsl.com Delivered-To: architecture-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 518CE21F8FCA for ; Sun, 24 Feb 2013 05:56:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.3 X-Spam-Level: X-Spam-Status: No, score=-2.3 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dOjwqQxOCfvk for ; Sun, 24 Feb 2013 05:56:24 -0800 (PST) Received: from mail.frobbit.se (mail.frobbit.se [IPv6:2a02:80:3ffe::176]) by ietfa.amsl.com (Postfix) with ESMTP id 333EE21F8F95 for ; Sun, 24 Feb 2013 05:56:24 -0800 (PST) Received: from [IPv6:2a02:80:3ffc::12] (unknown [IPv6:2a02:80:3ffc::12]) by mail.frobbit.se (Postfix) with ESMTPA id 4CCD321B21; Sun, 24 Feb 2013 14:56:23 +0100 (CET) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= In-Reply-To: <74157556-3608-41A4-AD4F-0789051B6CB7@cdt.org> Date: Sun, 24 Feb 2013 14:56:22 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <888D3D05-BF47-432C-A9C2-B2D4AE27EC62@frobbit.se> References: <74157556-3608-41A4-AD4F-0789051B6CB7@cdt.org> To: Alissa Cooper X-Mailer: Apple Mail (2.1499) Cc: architecture-discuss@ietf.org Subject: Re: [arch-d] draft-iab-filtering-considerations X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Feb 2013 13:56:25 -0000 Thanks for this new version. It is definitely from my perspective a = great improvement. But, of course the world has moved on since the last version :-P = Specifically we had the WCIT in dec 2012 where filtering and security = issues once again was discussed. I am looking at this text, which might have to be changed a bit: > Both blocking and > filtering can be effectuated at the level of "services" (web hosting > or video streaming, for example) or at the level of particular > "content." One sensitive issue that did come up in the WCIT discussions where = whether "responsibilities to act" (or responsibility for communication) = requires inspection of "content" or not. As you say in this document, it = is of course a question of how one look at the definition of "content". = Some people for example do only view the body of an email message as = content, while other might include the full SMTP conversation as content = while the traditional 5-tuple identifying the flow of communication as = non-content. This came up in the discussion related to "spam" where there was a = strong view from specifically some member states that did not sign the = proposed treaty that "content issues should not be included in the = treaties". Because of this, the reader might *today* (as compared to before the = meeting in December) look for clues where IAB do believe the blocking is = the result of inspection of content, or whether the blocking is not so. My personal view is that what is content is in the eyes of the = inspector. Someone that operate at some layer in the value chain do view = everything above that layer as content. And what in reality parties = where discussing was whether a player that is responsible for moving for = example IP packets (deals with routing etc) treat various contents of = the IP packet as content or not. What they are allowed to do and not. With that now on the table, I ask myself whether not "blocking" implies = that someone that operates at a certain layer in the value chain does = NOT look what that party believe is content while "filtering" do imply = inspection of content. I.e. that what you say here about "blocking" and "filtering" in reality = is connected with specifically section 2.2 about layering. Together with = the locality that also we in SSAC wrote about (impact on third party) -- = with the addition that if one talk about enterprises for example, = locality can be administrative (contractual) and not only based on AS. One thing I would like to have more clear in the earlier part of the = document and not only in last paragraph of 4.1.1, and that is what I = personally divide into three different things: A. Decision making process on what is to be blocked B. Inspection of traffic (which is described in 4.1.1) whether it falls = into the class of things that should be blocked C. The blocking action itself In some cases the action (A+B+C) because of weakness in [A], in other = cases [B] due to privacy laws is not allowed, and finally one have to = ask where the most effective action [C] is to be implemented so that = number of impact is minimized. Patrik On 23 feb 2013, at 12:47, Alissa Cooper wrote: > Hi Patrik, >=20 > We have posted a new version: = . Some = comments are inline below. >=20 > On Oct 26, 2012, at 1:58 PM, Patrik F=E4ltstr=F6m wrote: >=20 >>=20 >> On 26 okt 2012, at 13:32, Alissa Cooper wrote: >>=20 >>> The IAB is working on a document about "Technical Considerations for = Internet Service Filtering," = . = Feedback and discussion are welcome on this list. >>=20 >> Thanks for the pointer to this document that I have missed earlier. >>=20 >> First, what is the intended goal with this document? I do not really = see any recommendations in it. Is the idea to come with recommendations = on how to do blocking given there is consensus on what to block? >=20 > I don't think we plan to do much more than clarify the technical = implications and trade-offs of various blocking strategies. Since = different entities that want to block things have different constraints = and motivations, I think it would be hard to make meaningful = recommendations with wide applicability. With that said, I think there = is a clear conclusion in the draft that endpoint-based blocking comes = into the least conflict with the Internet architecture. >=20 >>=20 >> Secondly, I think you should try to remove lots and lots of words. It = is very long at the moment and I think / feel it would be more crisp if = you manage later on to not be repetitive, and be more "to the point". >=20 > Agreed. We did not do this yet given that the text is still changing = quite a bit. Hopefully on the next round we can cut it down. >=20 >>=20 >> Thirdly, even if this is a technical document, I think it is valuable = to explain why it is a *technical* paper. =46rom my point of view it is = because IAB has not intention on walking down the path of describing the = other half of "good blocking" which is "how to decide what to block". I = would like you at least say this, so the reader do understand this = "other piece" is also needed. >=20 > We tried to clarify this in section 1. >=20 >>=20 >> Lastly, please have a look at the just released SSAC document SAC056 = (and the earlier SAC050) that you can find on = . I think you find some = ideas there that can help you when you do future versions of this = document. >=20 > Thanks, and we have added a pointer to this. >=20 > Best, > Alissa >=20 >>=20 >> Regards, Patrik >>=20 >>=20 >=20 >=20 From jeanjour@comcast.net Sun Feb 24 09:21:09 2013 Return-Path: X-Original-To: architecture-discuss@ietfa.amsl.com Delivered-To: architecture-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7555421F9079 for ; Sun, 24 Feb 2013 09:21:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.137 X-Spam-Level: X-Spam-Status: No, score=-100.137 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, MIME_8BIT_HEADER=0.3, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yAX7Urp0k1Dk for ; Sun, 24 Feb 2013 09:21:08 -0800 (PST) Received: from qmta09.westchester.pa.mail.comcast.net (qmta09.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:96]) by ietfa.amsl.com (Postfix) with ESMTP id 3393B21F906E for ; Sun, 24 Feb 2013 09:21:08 -0800 (PST) Received: from omta14.westchester.pa.mail.comcast.net ([76.96.62.60]) by qmta09.westchester.pa.mail.comcast.net with comcast id 4DP91l0011HzFnQ59HM75y; Sun, 24 Feb 2013 17:21:07 +0000 Received: from [10.0.1.3] ([98.229.211.49]) by omta14.westchester.pa.mail.comcast.net with comcast id 4HM61l01914WE023aHM6S2; Sun, 24 Feb 2013 17:21:07 +0000 Mime-Version: 1.0 Message-Id: In-Reply-To: <888D3D05-BF47-432C-A9C2-B2D4AE27EC62@frobbit.se> References: <74157556-3608-41A4-AD4F-0789051B6CB7@cdt.org> <888D3D05-BF47-432C-A9C2-B2D4AE27EC62@frobbit.se> Date: Sun, 24 Feb 2013 12:20:09 -0500 To: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= , Alissa Cooper From: John Day Content-Type: text/plain; charset="iso-8859-1" ; format="flowed" Content-Transfer-Encoding: quoted-printable DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1361726467; bh=zitr4WZkZgcGsOKSj5H1Np1N3a2Ty6JI/UcO85s0RVQ=; h=Received:Received:Mime-Version:Message-Id:Date:To:From:Subject: Content-Type; b=KR2eFkkoPDPaveDchGyg9Er2TEfys007a/TAXznNV27rSFWGN1m7n/zimZIGYKO4j Nm32orgzRRrjCcenNfO07i/xqPzhFlrYWGWLXWkTyj3+7mfvcaxKefB43uhBFSKcQZ vJL+ILMJQlDJrQ0o9cxPdRgDEebPMQgvi9+5hiUkluGi2jB1wXQR4gEPDLMTOrABUo Y1MRV//0Jwzy8Z1P+Cv3NU+7gEKMq3SwSEfgR43UZZnSqEYC5RvkXUXbNv2K/1Ecmh 2Fzp/p5AAu3UX0XGCcXudMPXtXwkdkSW2/88XF71y8GtoB55IynViw76+4SnoErILx QUd/usT3O0loA== Cc: architecture-discuss@ietf.org Subject: Re: [arch-d] draft-iab-filtering-considerations X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Feb 2013 17:21:09 -0000 I would take the view that content is anything in=20 the Application Layer, i.e. anything above TCP. =46rom there down can be regulated by communication=20 regulators, e.g. the FCC, anything above that is=20 either private and nobodies business or business=20 which is regulated by the usual kinds of trade=20 ministries, e.g. in the US, Dept of Commerce,=20 =46ederal Trade Commission, etc. To use your WCIT=20 example, the web is outside their scope. It may=20 be inside the WTO scope. One can't use what sorts of standards various=20 SGOs produce as a guide. SGOs are driven bottom=20 up. If enough people agree to do something, it=20 is done. Another way to get at the same thing is to use=20 the distinction I use for distinguishing=20 application protocols from data transfer=20 protocols: Application protocols act on objects=20 (or modifies state) outside the protocol, e.g.=20 =46TP, SMTP, HTTP, SNMP, OSPF, etc. Whereas data=20 transfer protocols act on objects (or modifies=20 state) inside the protocol, e.g. TCP, Ethernet,=20 IP, SCTP, etc. OSPF is an interesting example of=20 an application that has a layer management role=20 within the layer. Only data transfer protocols fall within the=20 domain of WCIT might be concerned with. I believe this is a rather clean distinction and=20 can be related to first principles, whereas=20 others are as you indicate more less clear. I=20 would also strongly suggest that not taking a=20 strong position along these lines leads to=20 situations we would like to avoid. Take care, John Day At 2:56 PM +0100 2/24/13, Patrik F=E4ltstr=F6m wrote: >Thanks for this new version. It is definitely=20 >from my perspective a great improvement. > >But, of course the world has moved on since the=20 >last version :-P Specifically we had the WCIT in=20 >dec 2012 where filtering and security issues=20 >once again was discussed. > >I am looking at this text, which might have to be changed a bit: > >> Both blocking and >> filtering can be effectuated at the level of "services" (web hosting >> or video streaming, for example) or at the level of particular >> "content." > >One sensitive issue that did come up in the WCIT=20 >discussions where whether "responsibilities to=20 >act" (or responsibility for communication)=20 >requires inspection of "content" or not. As you=20 >say in this document, it is of course a question=20 >of how one look at the definition of "content".=20 >Some people for example do only view the body of=20 >an email message as content, while other might=20 >include the full SMTP conversation as content=20 >while the traditional 5-tuple identifying the=20 >flow of communication as non-content. > >This came up in the discussion related to "spam"=20 >where there was a strong view from specifically=20 >some member states that did not sign the=20 >proposed treaty that "content issues should not=20 >be included in the treaties". > >Because of this, the reader might *today* (as=20 >compared to before the meeting in December) look=20 >for clues where IAB do believe the blocking is=20 >the result of inspection of content, or whether=20 >the blocking is not so. > > >My personal view is that what is content is in=20 >the eyes of the inspector. Someone that operate=20 >at some layer in the value chain do view=20 >everything above that layer as content. And what=20 >in reality parties where discussing was whether=20 >a player that is responsible for moving for=20 >example IP packets (deals with routing etc)=20 >treat various contents of the IP packet as=20 >content or not. What they are allowed to do and=20 >not. > >With that now on the table, I ask myself whether=20 >not "blocking" implies that someone that=20 >operates at a certain layer in the value chain=20 >does NOT look what that party believe is content=20 >while "filtering" do imply inspection of content. > >I.e. that what you say here about "blocking" and=20 >"filtering" in reality is connected with=20 >specifically section 2.2 about layering.=20 >Together with the locality that also we in SSAC=20 >wrote about (impact on third party) -- with the=20 >addition that if one talk about enterprises for=20 >example, locality can be administrative=20 >(contractual) and not only based on AS. > >One thing I would like to have more clear in the=20 >earlier part of the document and not only in=20 >last paragraph of 4.1.1, and that is what I=20 >personally divide into three different things: > >A. Decision making process on what is to be blocked >B. Inspection of traffic (which is described in=20 >4.1.1) whether it falls into the class of things=20 >that should be blocked >C. The blocking action itself > >In some cases the action (A+B+C) because of=20 >weakness in [A], in other cases [B] due to=20 >privacy laws is not allowed, and finally one=20 >have to ask where the most effective action [C]=20 >is to be implemented so that number of impact is=20 >minimized. > > Patrik > >On 23 feb 2013, at 12:47, Alissa Cooper wrote: > >> Hi Patrik, >> >> We have posted a new version:=20 >>.=20 >>Some comments are inline below. >> >> On Oct 26, 2012, at 1:58 PM, Patrik F=E4ltstr=F6m wrote: >> >>> >>> On 26 okt 2012, at 13:32, Alissa Cooper wrote: >>> >>>> The IAB is working on a document about=20 >>>>"Technical Considerations for Internet=20 >>>>Service Filtering,"=20 >>>>.=20 >>>>Feedback and discussion are welcome on this=20 >>>>list. >>> >>> Thanks for the pointer to this document that I have missed earlier. >>> >>> First, what is the intended goal with this=20 >>>document? I do not really see any=20 >>>recommendations in it. Is the idea to come=20 >>>with recommendations on how to do blocking=20 >>>given there is consensus on what to block? >> >> I don't think we plan to do much more than=20 >>clarify the technical implications and=20 >>trade-offs of various blocking strategies.=20 >>Since different entities that want to block=20 >>things have different constraints and=20 >>motivations, I think it would be hard to make=20 >>meaningful recommendations with wide=20 >>applicability. With that said, I think there is=20 >>a clear conclusion in the draft that=20 >>endpoint-based blocking comes into the least=20 >>conflict with the Internet architecture. >> >>> >>> Secondly, I think you should try to remove=20 >>>lots and lots of words. It is very long at the=20 >>>moment and I think / feel it would be more=20 >>>crisp if you manage later on to not be=20 >>>repetitive, and be more "to the point". >> >> Agreed. We did not do this yet given that the=20 >>text is still changing quite a bit. Hopefully=20 >>on the next round we can cut it down. >> >>> >>> Thirdly, even if this is a technical=20 >>>document, I think it is valuable to explain=20 >>>why it is a *technical* paper. From my point=20 >>>of view it is because IAB has not intention on=20 >>>walking down the path of describing the other=20 >>>half of "good blocking" which is "how to=20 >>>decide what to block". I would like you at=20 >>>least say this, so the reader do understand=20 >>>this "other piece" is also needed. >> >> We tried to clarify this in section 1. >> >>> >>> Lastly, please have a look at the just=20 >>>released SSAC document SAC056 (and the earlier=20 >>>SAC050) that you can find on=20 >>>.=20 >>>I think you find some ideas there that can=20 >>>help you when you do future versions of this=20 >>>document. >> >> Thanks, and we have added a pointer to this. >> >> Best, >> Alissa >> >>> >>> Regards, Patrik >>> >>> >> >> > >_______________________________________________ >Architecture-discuss mailing list >Architecture-discuss@ietf.org >https://www.ietf.org/mailman/listinfo/architecture-discuss From cdel@firsthand.net Mon Feb 25 08:42:06 2013 Return-Path: X-Original-To: architecture-discuss@ietfa.amsl.com Delivered-To: architecture-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBE3421F950A for ; Mon, 25 Feb 2013 08:42:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.203 X-Spam-Level: X-Spam-Status: No, score=-1.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mPAngZXqoofH for ; Mon, 25 Feb 2013 08:42:05 -0800 (PST) Received: from bmtwo.vm.bytemark.co.uk (mail.firsthand.net [IPv6:2001:41c8:1:6062::d46e:bc35]) by ietfa.amsl.com (Postfix) with ESMTP id 4BB9C21F9501 for ; Mon, 25 Feb 2013 08:42:04 -0800 (PST) Received: (qmail 14354 invoked from network); 25 Feb 2013 16:41:42 +0000 Received: from 22.red-83-55-175.dynamicip.rima-tde.net (HELO ?192.168.1.178?) (83.55.175.22) by mail.firsthand.net with ESMTPSA (AES128-SHA encrypted, authenticated); 25 Feb 2013 16:41:37 +0000 References: <74157556-3608-41A4-AD4F-0789051B6CB7@cdt.org> <888D3D05-BF47-432C-A9C2-B2D4AE27EC62@frobbit.se> In-Reply-To: Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Message-Id: <834A3A9B-CA42-431F-9197-B258E1C5799B@firsthand.net> X-Mailer: iPad Mail (10B146) From: "cdel.firsthand.net" Date: Mon, 25 Feb 2013 17:39:59 +0100 To: John Day Cc: "architecture-discuss@ietf.org" Subject: Re: [arch-d] draft-iab-filtering-considerations X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Feb 2013 16:42:06 -0000 So you are proposing a list of "data transfer" protocols that are fair game t= o "wire" regulators? Or the other way round?=20 Best Christian de Larrinaga On 24 Feb 2013, at 18:20, John Day wrote: > I would take the view that content is anything in the Application Layer, i= .e. anything above TCP. >=20 > =46rom there down can be regulated by communication regulators, e.g. the FC= C, anything above that is either private and nobodies business or business w= hich is regulated by the usual kinds of trade ministries, e.g. in the US, De= pt of Commerce, Federal Trade Commission, etc. To use your WCIT example, th= e web is outside their scope. It may be inside the WTO scope. >=20 > One can't use what sorts of standards various SGOs produce as a guide. SG= Os are driven bottom up. If enough people agree to do something, it is done= . >=20 > Another way to get at the same thing is to use the distinction I use for d= istinguishing application protocols from data transfer protocols: Applicati= on protocols act on objects (or modifies state) outside the protocol, e.g. FT= P, SMTP, HTTP, SNMP, OSPF, etc. Whereas data transfer protocols act on objec= ts (or modifies state) inside the protocol, e.g. TCP, Ethernet, IP, SCTP, et= c. OSPF is an interesting example of an application that has a layer manage= ment role within the layer. >=20 > Only data transfer protocols fall within the domain of WCIT might be conce= rned with. >=20 > I believe this is a rather clean distinction and can be related to first p= rinciples, whereas others are as you indicate more less clear. I would also= strongly suggest that not taking a strong position along these lines leads t= o situations we would like to avoid. >=20 > Take care, > John Day >=20 > At 2:56 PM +0100 2/24/13, Patrik F=C3=A4ltstr=C3=B6m wrote: >> Thanks for this new version. It is definitely from my perspective a great= improvement. >>=20 >> But, of course the world has moved on since the last version :-P Specific= ally we had the WCIT in dec 2012 where filtering and security issues once ag= ain was discussed. >>=20 >> I am looking at this text, which might have to be changed a bit: >>=20 >>> Both blocking and >>> filtering can be effectuated at the level of "services" (web hosting >>> or video streaming, for example) or at the level of particular >>> "content." >>=20 >> One sensitive issue that did come up in the WCIT discussions where whethe= r "responsibilities to act" (or responsibility for communication) requires i= nspection of "content" or not. As you say in this document, it is of course a= question of how one look at the definition of "content". Some people for ex= ample do only view the body of an email message as content, while other migh= t include the full SMTP conversation as content while the traditional 5-tupl= e identifying the flow of communication as non-content. >>=20 >> This came up in the discussion related to "spam" where there was a strong= view from specifically some member states that did not sign the proposed tr= eaty that "content issues should not be included in the treaties". >>=20 >> Because of this, the reader might *today* (as compared to before the meet= ing in December) look for clues where IAB do believe the blocking is the res= ult of inspection of content, or whether the blocking is not so. >>=20 >>=20 >> My personal view is that what is content is in the eyes of the inspector.= Someone that operate at some layer in the value chain do view everything ab= ove that layer as content. And what in reality parties where discussing was w= hether a player that is responsible for moving for example IP packets (deals= with routing etc) treat various contents of the IP packet as content or not= . What they are allowed to do and not. >>=20 >> With that now on the table, I ask myself whether not "blocking" implies t= hat someone that operates at a certain layer in the value chain does NOT loo= k what that party believe is content while "filtering" do imply inspection o= f content. >>=20 >> I.e. that what you say here about "blocking" and "filtering" in reality i= s connected with specifically section 2.2 about layering. Together with the l= ocality that also we in SSAC wrote about (impact on third party) -- with the= addition that if one talk about enterprises for example, locality can be ad= ministrative (contractual) and not only based on AS. >>=20 >> One thing I would like to have more clear in the earlier part of the docu= ment and not only in last paragraph of 4.1.1, and that is what I personally d= ivide into three different things: >>=20 >> A. Decision making process on what is to be blocked >> B. Inspection of traffic (which is described in 4.1.1) whether it falls i= nto the class of things that should be blocked >> C. The blocking action itself >>=20 >> In some cases the action (A+B+C) because of weakness in [A], in other cas= es [B] due to privacy laws is not allowed, and finally one have to ask where= the most effective action [C] is to be implemented so that number of impact= is minimized. >>=20 >> Patrik >>=20 >> On 23 feb 2013, at 12:47, Alissa Cooper wrote: >>=20 >>> Hi Patrik, >>>=20 >>> We have posted a new version: . Some comments are inline below. >>>=20 >>> On Oct 26, 2012, at 1:58 PM, Patrik F=C3=A4ltstr=C3=B6m wrote: >>>=20 >>>>=20 >>>> On 26 okt 2012, at 13:32, Alissa Cooper wrote: >>>>=20 >>>>> The IAB is working on a document about "Technical Considerations for I= nternet Service Filtering," . Feedback and discussion are welcome on this list. >>>>=20 >>>> Thanks for the pointer to this document that I have missed earlier. >>>>=20 >>>> First, what is the intended goal with this document? I do not really se= e any recommendations in it. Is the idea to come with recommendations on how= to do blocking given there is consensus on what to block? >>>=20 >>> I don't think we plan to do much more than clarify the technical implica= tions and trade-offs of various blocking strategies. Since different entitie= s that want to block things have different constraints and motivations, I th= ink it would be hard to make meaningful recommendations with wide applicabil= ity. With that said, I think there is a clear conclusion in the draft that e= ndpoint-based blocking comes into the least conflict with the Internet archi= tecture. >>>=20 >>>>=20 >>>> Secondly, I think you should try to remove lots and lots of words. It i= s very long at the moment and I think / feel it would be more crisp if you m= anage later on to not be repetitive, and be more "to the point". >>>=20 >>> Agreed. We did not do this yet given that the text is still changing qui= te a bit. Hopefully on the next round we can cut it down. >>>=20 >>>>=20 >>>> Thirdly, even if this is a technical document, I think it is valuable t= o explain why it is a *technical* paper. =46rom my point of view it is becau= se IAB has not intention on walking down the path of describing the other ha= lf of "good blocking" which is "how to decide what to block". I would like y= ou at least say this, so the reader do understand this "other piece" is also= needed. >>>=20 >>> We tried to clarify this in section 1. >>>=20 >>>>=20 >>>> Lastly, please have a look at the just released SSAC document SAC056 (a= nd the earlier SAC050) that you can find on . I think you find some ideas there that can help you when yo= u do future versions of this document. >>>=20 >>> Thanks, and we have added a pointer to this. >>>=20 >>> Best, >>> Alissa >>>=20 >>>>=20 >>>> Regards, Patrik >>=20 >> _______________________________________________ >> Architecture-discuss mailing list >> Architecture-discuss@ietf.org >> https://www.ietf.org/mailman/listinfo/architecture-discuss >=20 > _______________________________________________ > Architecture-discuss mailing list > Architecture-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/architecture-discuss From touch@isi.edu Mon Feb 25 09:12:01 2013 Return-Path: X-Original-To: architecture-discuss@ietfa.amsl.com Delivered-To: architecture-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40BE321F95DB for ; Mon, 25 Feb 2013 09:12:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.114 X-Spam-Level: X-Spam-Status: No, score=-105.114 tagged_above=-999 required=5 tests=[AWL=1.485, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fB3xYzC8N-kt for ; Mon, 25 Feb 2013 09:12:00 -0800 (PST) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id 07ACE21F9511 for ; Mon, 25 Feb 2013 09:12:00 -0800 (PST) Received: from [192.168.1.96] (pool-71-105-87-221.lsanca.dsl-w.verizon.net [71.105.87.221]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id r1PH3XBY001743 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 25 Feb 2013 09:03:42 -0800 (PST) Message-ID: <512B9969.3040603@isi.edu> Date: Mon, 25 Feb 2013 09:03:37 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: John Day References: <74157556-3608-41A4-AD4F-0789051B6CB7@cdt.org> <888D3D05-BF47-432C-A9C2-B2D4AE27EC62@frobbit.se> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: architecture-discuss@ietf.org Subject: Re: [arch-d] draft-iab-filtering-considerations X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Feb 2013 17:12:01 -0000 Hi, John, et al., On 2/24/2013 9:20 AM, John Day wrote: > I would take the view that content is anything in the Application Layer, > i.e. anything above TCP. For the purposes of this doc, IMO "content" ought to be anything above the layer of the service I pay you for. There are no other distinctions; what you call an application protocol I might call a transport or network, esp. when I tunnel TCP or IP over it. I.e., if I pay for IP access, then TCP and other transports are content, and you have no business looking at it - and can't look at it if I encrypt it. If I pay for "portal" access - e.g., HTTP, IMAP, etc., but not direct IP forwarding - then "content" is whatever those protocols carry. HTTP might carry web pages, but it might also carry any other service over HTTP (there are many). IMO, the regulators ought to require service providers to explain the service they are providing and be held to that. Joe From touch@isi.edu Mon Feb 25 11:17:09 2013 Return-Path: X-Original-To: architecture-discuss@ietfa.amsl.com Delivered-To: architecture-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A92F721E80B1 for ; Mon, 25 Feb 2013 11:17:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.179 X-Spam-Level: X-Spam-Status: No, score=-103.179 tagged_above=-999 required=5 tests=[AWL=-0.580, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bOKu7gB-fNHd for ; Mon, 25 Feb 2013 11:17:09 -0800 (PST) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id 17A5521E809E for ; Mon, 25 Feb 2013 11:17:09 -0800 (PST) Received: from [192.168.1.96] (pool-71-105-87-221.lsanca.dsl-w.verizon.net [71.105.87.221]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id r1PJFYcd022662 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 25 Feb 2013 11:15:38 -0800 (PST) Message-ID: <512BB85B.5030302@isi.edu> Date: Mon, 25 Feb 2013 11:15:39 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: John Day References: <74157556-3608-41A4-AD4F-0789051B6CB7@cdt.org> <888D3D05-BF47-432C-A9C2-B2D4AE27EC62@frobbit.se> <512B9969.3040603@isi.edu> In-Reply-To: <512B9969.3040603@isi.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: architecture-discuss@ietf.org Subject: Re: [arch-d] draft-iab-filtering-considerations X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Feb 2013 19:17:10 -0000 Some other comments: - content-based usage restrictions go back to long before 1988; the NSFNet prohibited commercial use. Granted this isn't an historical summary, but it should be noted that this issue has been with us for a very long time - we do have a definition of what it means to be on the Internet (RFCs 1122/1123, from a host viewpoint, e.g.); many "access providers" don't provide Internet service because they block critical signalling (some ICMP messages) or limit what can be in an IP packet The whole point of IP is an internetworking layer. *ANYTHING* that limits what can be in an IP packet except by length is interfering with that. IMO, filtered access simply isn't the Internet, and shouldn't be passed off as such. But until we have compliance certification, the point seems moot. - blocking on ports ought to be pointed out as useless. a port is both a point of demux and an indicator of a service, but ONLY between cooperating endpoints. port numbers have no meaning outside that of a "flow" outside the two endpoints of a connection. assigning meaning to those numbers only creates a situation where users WILL remap the correlation between ports and services The net effect is to require more Internet infrastructure (e.g., dynamic service discovery). Assuming that a port means a service ought to be highlighted as the nonsense it is. - short of introducing compliance certification, I don't think its useful for the IAB to try to explain any of this or even take a position on it. JOe From touch@isi.edu Mon Feb 25 11:21:48 2013 Return-Path: X-Original-To: architecture-discuss@ietfa.amsl.com Delivered-To: architecture-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E87621F92EB for ; Mon, 25 Feb 2013 11:21:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.143 X-Spam-Level: X-Spam-Status: No, score=-103.143 tagged_above=-999 required=5 tests=[AWL=-0.544, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ikB2hmwRg53R for ; Mon, 25 Feb 2013 11:21:46 -0800 (PST) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id 40A3E21F92D5 for ; Mon, 25 Feb 2013 11:21:46 -0800 (PST) Received: from [192.168.1.96] (pool-71-105-87-221.lsanca.dsl-w.verizon.net [71.105.87.221]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id r1PJKq4q024305 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 25 Feb 2013 11:20:55 -0800 (PST) Message-ID: <512BB999.2050003@isi.edu> Date: Mon, 25 Feb 2013 11:20:57 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: John Day References: <74157556-3608-41A4-AD4F-0789051B6CB7@cdt.org> <888D3D05-BF47-432C-A9C2-B2D4AE27EC62@frobbit.se> <512B9969.3040603@isi.edu> <512BB85B.5030302@isi.edu> In-Reply-To: <512BB85B.5030302@isi.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: architecture-discuss@ietf.org Subject: Re: [arch-d] draft-iab-filtering-considerations X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Feb 2013 19:21:48 -0000 PS - my view of what's required is here: http://www.isi.edu/touch/internet-rights/ It takes into account the desire to avoid being spammed/DOS attacked, but ensures that communication can be established between cooperating endpoints. Any service provider offering Internet service ought to held to abide by this list, IMO. Joe On 2/25/2013 11:15 AM, Joe Touch wrote: > Some other comments: > > - content-based usage restrictions go back to long before 1988; the > NSFNet prohibited commercial use. Granted this isn't an historical > summary, but it should be noted that this issue has been with us for a > very long time > > - we do have a definition of what it means to be on the Internet (RFCs > 1122/1123, from a host viewpoint, e.g.); many "access providers" don't > provide Internet service because they block critical signalling (some > ICMP messages) or limit what can be in an IP packet > > The whole point of IP is an internetworking layer. *ANYTHING* that > limits what can be in an IP packet except by length is interfering with > that. IMO, filtered access simply isn't the Internet, and shouldn't be > passed off as such. But until we have compliance certification, the > point seems moot. > > - blocking on ports ought to be pointed out as useless. a port is both a > point of demux and an indicator of a service, but ONLY between > cooperating endpoints. port numbers have no meaning outside that of a > "flow" outside the two endpoints of a connection. assigning meaning to > those numbers only creates a situation where users WILL remap the > correlation between ports and services > > The net effect is to require more Internet infrastructure (e.g., dynamic > service discovery). Assuming that a port means a service ought to be > highlighted as the nonsense it is. > > - short of introducing compliance certification, I don't think its > useful for the IAB to try to explain any of this or even take a position > on it. > > JOe From jefsey@jefsey.com Tue Feb 26 09:27:30 2013 Return-Path: X-Original-To: architecture-discuss@ietfa.amsl.com Delivered-To: architecture-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73F3421F8988; Tue, 26 Feb 2013 09:27:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.449 X-Spam-Level: X-Spam-Status: No, score=-102.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c9uLOxj-9N2t; Tue, 26 Feb 2013 09:27:27 -0800 (PST) Received: from sonic.altserver.com (sonic.altserver.com [72.34.37.74]) by ietfa.amsl.com (Postfix) with ESMTP id 603CB21F8942; Tue, 26 Feb 2013 09:27:26 -0800 (PST) Received: from lns-c10k03-v-62-35-238-138.dsl.sta.abo.bbox.fr ([62.35.238.138]:59322 helo=MORFIN-PC.jefsey.com) by sonic.altserver.com with esmtpa (Exim 4.80) (envelope-from ) id 1UAOJJ-0003gG-Ed; Tue, 26 Feb 2013 09:27:26 -0800 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 26 Feb 2013 18:27:20 +0100 To: architecture-discuss@ietf.org From: JFC Morfin Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: 8bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - sonic.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Get-Message-Sender-Via: sonic.altserver.com: authenticated_id: jefsey+jefsey.com/only user confirmed/virtual account not confirmed Message-Id: <20130226172726.603CB21F8942@ietfa.amsl.com> Cc: iucg@ietf.org, iutf@iutf.org Subject: Re: [arch-d] draft-iab-filtering-considerations X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Feb 2013 17:27:30 -0000 This mail was blocked by the system due to to many destinations as I copied the various interested parties This definitly belongs to the architecture-discuss issues. jfc ---- https://datatracker.ietf.org/doc/draft-iab-filtering-considerations/ .... in the wake of RFC 6852 "We embrace a modern paradigm for standards where the economics of global markets, fueled by technological advancements, drive global deployment of standards regardless of their formal status"? At 20:15 25/02/2013, Joe Touch wrote: >- short of introducing compliance certification, I don't think its >useful for the IAB to try to explain any of this or even take a position on it. Amen. --- At 18:20 24/02/2013, John Day wrote: >I would take the view that content is anything in the Application >Layer, i.e. anything above TCP. [rest is at the end] John Innovation is said to be either incremental (IETF) or disruptive (IRTF). Actually, the Internet brings a new form of "fundamental innovation" due to its deployment being faster than technical development. The same searchers and technical risk takers can review their choices that were made 40 years ago to the light of what they learned and forgot during those 40 years. We saw this at the WG/IDNABis where IDNA2008 reviewed IDNA2003 (after only 5 years, but this was a foreseen possibility) at the impulse of Patrik Fälstrom and John Klensin. Due to their clarifying cosmetics, the same causes led to the same but still more visible blocking effects. Until Pete Resnick and John Hoffmann saved the day with their RFC 5895, I was able to read as the missing proof of the internet concept matching Norman Hardy's Tymnet ISIS (I come from) core "agoric" concept: fringe standalone service subsidiarity. From then on, it is possible to revise and extend the OSI model in such a way that the current conceptual architectural drift and related patches can be integrated so that they fit together better. The missing presentation layer can be supported as well as the intelligent content one as well as the semantic, shared cognition and mutual empathy further layers that you may investigate above. Where they belong as per RFC 1958: at the fringe. The fringe concerns the IETF, but it is not IETF end to end territory. This was clarified by the IESG and IAB responses to my appeals. It permits (1) the IETF to keep focusing on making the Internet work better, while possibly making RFC 6852 acceptable within the limits of the "commercial end to end commodity" business management (2) to discuss the fringe to fringe intelligence at other fora (e.g. http://iutf.org/wiki). This means that the use of the Internet, as the core of any "Internet+" (fringe to fringe relations at plugged layers on the user side [PLUS]) or "Intersem" (any kind of semiotic Internet) strata, can only be based upon the trust that the TCP/IP layers ARE (not only MUST be) trustable, i.e. as neutral, reliable, secure, protected, and private as the copper layer. The rule for the IETF should, therefore, be to limit itself to a more trustable virtual copper, making sure that it stays within the end to end limits in order to not interfere with the fringe to fringe (and above) layers security schemes. This is why, as Joe Touch puts it, short of introducing compliance certification, it is not useful, IMHO it is undesirable, for the IAB to try to explain any internet filtering or even take a position on it. RFC 4645, 5646 and 4647 already are about content filtering: I obtained them to be what they are, but they definitly do not belong to the IETF scope, end to end bits not being culturally dependent. Actually, the question we discuss is always the same. Where does belong the Presentation layer ? Is there a Presentation sub-layer which might belong to a neutral, democratic, transparent Internet, complying with the RFC 3935 core values? RFC 1958, W3C, IDNA2008 RFC 5895, etc seem to say "no, however we are interested in making sure the TCP/IP layers are stable and trustable enough for others to support fringe to fringe Presentation the way both ends may whish it". Now, in addition we have a new question: is RFC 6852 compatible with RFC 3539 and RFC 3869. jfc > > From there down can be regulated by communication regulators, e.g. > the FCC, anything above that is either private and nobodies > business or business which is regulated by the usual kinds of trade > ministries, e.g. in the US, Dept of Commerce, Federal Trade > Commission, etc. To use your WCIT example, the web is outside > their scope. It may be inside the WTO scope. > >One can't use what sorts of standards various SGOs produce as a >guide. SGOs are driven bottom up. If enough people agree to do >something, it is done. > >Another way to get at the same thing is to use the distinction I use >for distinguishing application protocols from data transfer >protocols: Application protocols act on objects (or modifies state) >outside the protocol, e.g. FTP, SMTP, HTTP, SNMP, OSPF, etc. Whereas >data transfer protocols act on objects (or modifies state) inside >the protocol, e.g. TCP, Ethernet, IP, SCTP, etc. OSPF is an >interesting example of an application that has a layer management >role within the layer. > >Only data transfer protocols fall within the domain of WCIT might be >concerned with. > >I believe this is a rather clean distinction and can be related to >first principles, whereas others are as you indicate more less >clear. I would also strongly suggest that not taking a strong >position along these lines leads to situations we would like to avoid. > >Take care, >John Day > >At 2:56 PM +0100 2/24/13, Patrik Fältström wrote: >>Thanks for this new version. It is definitely from my perspective a >>great improvement. >> >>But, of course the world has moved on since the last version :-P >>Specifically we had the WCIT in dec 2012 where filtering and >>security issues once again was discussed. >> >>I am looking at this text, which might have to be changed a bit: >> >>> Both blocking and >>> filtering can be effectuated at the level of "services" (web hosting >>> or video streaming, for example) or at the level of particular >>> "content." >> >>One sensitive issue that did come up in the WCIT discussions where >>whether "responsibilities to act" (or responsibility for >>communication) requires inspection of "content" or not. As you say >>in this document, it is of course a question of how one look at the >>definition of "content". Some people for example do only view the >>body of an email message as content, while other might include the >>full SMTP conversation as content while the traditional 5-tuple >>identifying the flow of communication as non-content. >> >>This came up in the discussion related to "spam" where there was a >>strong view from specifically some member states that did not sign >>the proposed treaty that "content issues should not be included in >>the treaties". >> >>Because of this, the reader might *today* (as compared to before >>the meeting in December) look for clues where IAB do believe the >>blocking is the result of inspection of content, or whether the >>blocking is not so. >> >> >>My personal view is that what is content is in the eyes of the >>inspector. Someone that operate at some layer in the value chain do >>view everything above that layer as content. And what in reality >>parties where discussing was whether a player that is responsible >>for moving for example IP packets (deals with routing etc) treat >>various contents of the IP packet as content or not. What they are >>allowed to do and not. >> >>With that now on the table, I ask myself whether not "blocking" >>implies that someone that operates at a certain layer in the value >>chain does NOT look what that party believe is content while >>"filtering" do imply inspection of content. >> >>I.e. that what you say here about "blocking" and "filtering" in >>reality is connected with specifically section 2.2 about layering. >>Together with the locality that also we in SSAC wrote about (impact >>on third party) -- with the addition that if one talk about >>enterprises for example, locality can be administrative >>(contractual) and not only based on AS. >> >>One thing I would like to have more clear in the earlier part of >>the document and not only in last paragraph of 4.1.1, and that is >>what I personally divide into three different things: >> >>A. Decision making process on what is to be blocked >>B. Inspection of traffic (which is described in 4.1.1) whether it >>falls into the class of things that should be blocked >>C. The blocking action itself >> >>In some cases the action (A+B+C) because of weakness in [A], in >>other cases [B] due to privacy laws is not allowed, and finally one >>have to ask where the most effective action [C] is to be >>implemented so that number of impact is minimized. >> >> Patrik >> >>On 23 feb 2013, at 12:47, Alissa Cooper wrote: >> >>> Hi Patrik, >>> >>> We have posted a new version: >>> >>> . Some comments are inline below. >>> >>> On Oct 26, 2012, at 1:58 PM, Patrik Fältström wrote: >>> >>>> >>>> On 26 okt 2012, at 13:32, Alissa Cooper wrote: >>>> >>>>> The IAB is working on a document about "Technical >>>>> Considerations for Internet Service Filtering," >>>>> >>>> 1>. Feedback and discussion are welcome on this list. >>>> >>>> Thanks for the pointer to this document that I have missed earlier. >>>> >>>> First, what is the intended goal with this document? I do not >>>> really see any recommendations in it. Is the idea to come with >>>> recommendations on how to do blocking given there is consensus >>>> on what to block? >>> >>> I don't think we plan to do much more than clarify the technical >>> implications and trade-offs of various blocking strategies. Since >>> different entities that want to block things have different >>> constraints and motivations, I think it would be hard to make >>> meaningful recommendations with wide applicability. With that >>> said, I think there is a clear conclusion in the draft that >>> endpoint-based blocking comes into the least conflict with the >>> Internet architecture. >>> >>>> >>>> Secondly, I think you should try to remove lots and lots of >>>> words. It is very long at the moment and I think / feel it would >>>> be more crisp if you manage later on to not be repetitive, and >>>> be more "to the point". >>> >>> Agreed. We did not do this yet given that the text is still >>> changing quite a bit. Hopefully on the next round we can cut it down. >>> >>>> >>>> Thirdly, even if this is a technical document, I think it is >>>> valuable to explain why it is a *technical* paper. From my point >>>> of view it is because IAB has not intention on walking down the >>>> path of describing the other half of "good blocking" which is >>>> "how to decide what to block". I would like you at least say >>>> this, so the reader do understand this "other piece" is also needed. >>> >>> We tried to clarify this in section 1. >>> >>>> >>>> Lastly, please have a look at the just released SSAC document >>>> SAC056 (and the earlier SAC050) that you can find on >>>> . I think you >>>> find some ideas there that can help you when you do future >>>> versions of this document. >>> >>> Thanks, and we have added a pointer to this. >>> >>> Best, >>> Alissa >>> >>>> >>>> Regards, Patrik From jeanjour@comcast.net Tue Feb 26 11:44:45 2013 Return-Path: X-Original-To: architecture-discuss@ietfa.amsl.com Delivered-To: architecture-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4F0421F87FB for ; Tue, 26 Feb 2013 11:44:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.287 X-Spam-Level: X-Spam-Status: No, score=-100.287 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qJLBl3kyvjDB for ; Tue, 26 Feb 2013 11:44:45 -0800 (PST) Received: from qmta14.westchester.pa.mail.comcast.net (qmta14.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:212]) by ietfa.amsl.com (Postfix) with ESMTP id 2DAE221F8807 for ; Tue, 26 Feb 2013 11:44:45 -0800 (PST) Received: from omta07.westchester.pa.mail.comcast.net ([76.96.62.59]) by qmta14.westchester.pa.mail.comcast.net with comcast id 53WK1l0031GhbT85E7kd8T; Tue, 26 Feb 2013 19:44:37 +0000 Received: from [10.0.1.3] ([98.229.211.49]) by omta07.westchester.pa.mail.comcast.net with comcast id 57kc1l00M14WE023T7kckA; Tue, 26 Feb 2013 19:44:37 +0000 Mime-Version: 1.0 Message-Id: In-Reply-To: <512B9969.3040603@isi.edu> References: <74157556-3608-41A4-AD4F-0789051B6CB7@cdt.org> <888D3D05-BF47-432C-A9C2-B2D4AE27EC62@frobbit.se> <512B9969.3040603@isi.edu> Date: Tue, 26 Feb 2013 14:35:19 -0500 To: Joe Touch , John Day From: John Day Content-Type: text/plain; charset="us-ascii" ; format="flowed" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1361907877; bh=PEIOiiNRQP3BqqXAyeDcncWco7epCje0ym+wBQF63cM=; h=Received:Received:Mime-Version:Message-Id:Date:To:From:Subject: Content-Type; b=LSuGA08FUPC4xNm8vWWZQv2EY+ZY1uzYDxadfq48xsE6n6h2ZdddfPZNqdt/LETeR /tn9S2/8F/wf0etThVVQygczKfOfCYLkJcy81rbqL6/Wu+aUymLyiNdcF8xEZTGMeO pBmoe5WazRGRkumh2xOQBK8YzLx0QjbDDuPo1y4MQGFFI5fZa+9j//GIifQFLIu62j wtJhWfKKVYekp6hx1xiY2IKlyUigjiyXUDaUu80gEulBHkUjhlJvMSFT+9xoXNQewu 5+l60Iq506ewDgkWfNdv2I8/Mn246Fc7evTzsk7Qm18r8gHJClfpdnyjb5nISlpB1q t/ms86bcQRhjQ== Cc: architecture-discuss@ietf.org Subject: Re: [arch-d] draft-iab-filtering-considerations X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Feb 2013 19:44:45 -0000 At 9:03 AM -0800 2/25/13, Joe Touch wrote: >Hi, John, et al., > >On 2/24/2013 9:20 AM, John Day wrote: >>I would take the view that content is anything in the Application Layer, >>i.e. anything above TCP. > >For the purposes of this doc, IMO "content" ought to be anything >above the layer of the service I pay you for. So if my provider provides email, and bundles it in what I pay, even if I don't use it, then email is not "content." That doesn't work. > >There are no other distinctions; what you call an application >protocol I might call a transport or network, esp. when I tunnel TCP >or IP over it. Not the way I defined it. It has nothing to do with what is encapsulated in what. > >I.e., if I pay for IP access, then TCP and other transports are >content, and you have no business looking at it - and can't look at >it if I encrypt it. > >If I pay for "portal" access - e.g., HTTP, IMAP, etc., but not >direct IP forwarding - then "content" is whatever those protocols >carry. HTTP might carry web pages, but it might also carry any other >service over HTTP (there are many). Defining "data" in HTTP may be a bit difficult. Take care, John > > >IMO, the regulators ought to require service providers to explain >the service they are providing and be held to that. > >Joe From touch@isi.edu Tue Feb 26 11:56:53 2013 Return-Path: X-Original-To: architecture-discuss@ietfa.amsl.com Delivered-To: architecture-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18EED21F87D5 for ; Tue, 26 Feb 2013 11:56:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.147 X-Spam-Level: X-Spam-Status: No, score=-103.147 tagged_above=-999 required=5 tests=[AWL=-0.548, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bI71gvGmVCmb for ; Tue, 26 Feb 2013 11:56:52 -0800 (PST) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by ietfa.amsl.com (Postfix) with ESMTP id E87E021F87C3 for ; Tue, 26 Feb 2013 11:56:46 -0800 (PST) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id r1QJtIIR001730 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 26 Feb 2013 11:55:18 -0800 (PST) Message-ID: <512D131A.5020302@isi.edu> Date: Tue, 26 Feb 2013 11:55:06 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130215 Thunderbird/17.0.3 MIME-Version: 1.0 To: John Day References: <74157556-3608-41A4-AD4F-0789051B6CB7@cdt.org> <888D3D05-BF47-432C-A9C2-B2D4AE27EC62@frobbit.se> <512B9969.3040603@isi.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: architecture-discuss@ietf.org Subject: Re: [arch-d] draft-iab-filtering-considerations X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Feb 2013 19:56:53 -0000 Hi, John (et al.) On 2/26/2013 11:35 AM, John Day wrote: > At 9:03 AM -0800 2/25/13, Joe Touch wrote: >> Hi, John, et al., >> >> On 2/24/2013 9:20 AM, John Day wrote: >>> I would take the view that content is anything in the Application Layer, >>> i.e. anything above TCP. >> >> For the purposes of this doc, IMO "content" ought to be anything above >> the layer of the service I pay you for. > > So if my provider provides email, and bundles it in what I pay, even if > I don't use it, then email is not "content." That doesn't work. If you pay for IP, then the fact that the packet is email vs. file transfer is content. As is anything above that, including the email or file content. If you pay for email access, then the fact that you're doing email isn't content, but the content of the email is. >> There are no other distinctions; what you call an application protocol >> I might call a transport or network, esp. when I tunnel TCP or IP over >> it. > > Not the way I defined it. It has nothing to do with what is > encapsulated in what. You referred directly to protocols, but those protocols don't exist at exactly one layer in a stack. >> I.e., if I pay for IP access, then TCP and other transports are >> content, and you have no business looking at it - and can't look at it >> if I encrypt it. >> >> If I pay for "portal" access - e.g., HTTP, IMAP, etc., but not direct >> IP forwarding - then "content" is whatever those protocols carry. HTTP >> might carry web pages, but it might also carry any other service over >> HTTP (there are many). > > Defining "data" in HTTP may be a bit difficult. HTTP data is the response to a GET or "enclosed" with a PUT or PATCH. The stuff you send to make that happen inside the HTTP protocol messages isn't data; it's control. I.e., data is the part of an HTTP message that interpreters don't parse. Joe From jeanjour@comcast.net Tue Feb 26 12:19:27 2013 Return-Path: X-Original-To: architecture-discuss@ietfa.amsl.com Delivered-To: architecture-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF10F21F87FB for ; Tue, 26 Feb 2013 12:19:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.362 X-Spam-Level: X-Spam-Status: No, score=-100.362 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id umuQXIy0jmV6 for ; Tue, 26 Feb 2013 12:19:24 -0800 (PST) Received: from qmta03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:32]) by ietfa.amsl.com (Postfix) with ESMTP id 33FA421F8815 for ; Tue, 26 Feb 2013 12:19:24 -0800 (PST) Received: from omta18.westchester.pa.mail.comcast.net ([76.96.62.90]) by qmta03.westchester.pa.mail.comcast.net with comcast id 50wk1l0041wpRvQ538KPDM; Tue, 26 Feb 2013 20:19:23 +0000 Received: from [10.0.1.3] ([98.229.211.49]) by omta18.westchester.pa.mail.comcast.net with comcast id 58KN1l00D14WE023e8KPrb; Tue, 26 Feb 2013 20:19:23 +0000 Mime-Version: 1.0 Message-Id: In-Reply-To: <512D131A.5020302@isi.edu> References: <74157556-3608-41A4-AD4F-0789051B6CB7@cdt.org> <888D3D05-BF47-432C-A9C2-B2D4AE27EC62@frobbit.se> <512B9969.3040603@isi.edu> <512D131A.5020302@isi.edu> Date: Tue, 26 Feb 2013 15:18:09 -0500 To: Joe Touch , John Day From: John Day Content-Type: text/plain; charset="us-ascii" ; format="flowed" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1361909963; bh=WLeW91BK+GfKiO5H1GCHj2jj33GDonB294kUuhMDdYg=; h=Received:Received:Mime-Version:Message-Id:Date:To:From:Subject: Content-Type; b=mU/7ot9uRfKyGiDyLoAXYSSir090xxpIliwEOW3Sga82RtUphLL237MWAI/OxfCag LGQ9Va8I9NhoEeh7fh4rrGqV5DjdfbLStPty3rHpFFE8Q+aKjEZHaB3AO9FKws3mVY LXw/HvbAmyQtruEzCCuopnMCysCV3MUPfqs6vJbpoz+v8nfDoYo3iQ0cgsvfJrxUt3 qb/AzF+0mIabp5vGIjalmAPPR476yRN7ahDg0S/9KD2xBIjg9IdzijIAKJnyvGGOLY GVAS9FYt425iEp1SPVNVgBcL8NIm5l9NHiAv0uri0y/fR+ofJiSmDkXIumvkmcK5ZW BicC1XEwQp+KA== Cc: architecture-discuss@ietf.org Subject: Re: [arch-d] draft-iab-filtering-considerations X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Feb 2013 20:19:28 -0000 At 11:55 AM -0800 2/26/13, Joe Touch wrote: >Hi, John (et al.) > >On 2/26/2013 11:35 AM, John Day wrote: >>At 9:03 AM -0800 2/25/13, Joe Touch wrote: >>>Hi, John, et al., >>> >>>On 2/24/2013 9:20 AM, John Day wrote: >>>>I would take the view that content is anything in the Application Layer, >>>>i.e. anything above TCP. >>> >>>For the purposes of this doc, IMO "content" ought to be anything above >>>the layer of the service I pay you for. >> >>So if my provider provides email, and bundles it in what I pay, even if >>I don't use it, then email is not "content." That doesn't work. > >If you pay for IP, then the fact that the packet is email vs. file >transfer is content. As is anything above that, including the email >or file content. > >If you pay for email access, then the fact that you're doing email >isn't content, but the content of the email is. Ahhh, so you agree with me. Email performs operations external to the protocol. > >>>There are no other distinctions; what you call an application protocol >>>I might call a transport or network, esp. when I tunnel TCP or IP over >>>it. >> >>Not the way I defined it. It has nothing to do with what is >>encapsulated in what. > >You referred directly to protocols, but those protocols don't exist >at exactly one layer in a stack. I never said they did. I spoke of a class of protocols defined by their characteristics. Not where they are in the stack. Where in the stack is irrelevant. Take care, John > >>>I.e., if I pay for IP access, then TCP and other transports are >>>content, and you have no business looking at it - and can't look at it >>>if I encrypt it. >>> >>>If I pay for "portal" access - e.g., HTTP, IMAP, etc., but not direct >>>IP forwarding - then "content" is whatever those protocols carry. HTTP >>>might carry web pages, but it might also carry any other service over >>>HTTP (there are many). >> >>Defining "data" in HTTP may be a bit difficult. > >HTTP data is the response to a GET or "enclosed" with a PUT or PATCH. > >The stuff you send to make that happen inside the HTTP protocol >messages isn't data; it's control. > >I.e., data is the part of an HTTP message that interpreters don't parse. > >Joe From touch@isi.edu Tue Feb 26 12:56:01 2013 Return-Path: X-Original-To: architecture-discuss@ietfa.amsl.com Delivered-To: architecture-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C0F021F882A for ; Tue, 26 Feb 2013 12:56:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.126 X-Spam-Level: X-Spam-Status: No, score=-105.126 tagged_above=-999 required=5 tests=[AWL=1.473, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ntWQmo2mhHx4 for ; Tue, 26 Feb 2013 12:56:00 -0800 (PST) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id 6523821F87EA for ; Tue, 26 Feb 2013 12:56:00 -0800 (PST) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id r1QKsxUl024536 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 26 Feb 2013 12:54:59 -0800 (PST) Message-ID: <512D2116.9020403@isi.edu> Date: Tue, 26 Feb 2013 12:54:46 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130215 Thunderbird/17.0.3 MIME-Version: 1.0 To: John Day References: <74157556-3608-41A4-AD4F-0789051B6CB7@cdt.org> <888D3D05-BF47-432C-A9C2-B2D4AE27EC62@frobbit.se> <512B9969.3040603@isi.edu> <512D131A.5020302@isi.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: architecture-discuss@ietf.org Subject: Re: [arch-d] draft-iab-filtering-considerations X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Feb 2013 20:56:01 -0000 On 2/26/2013 12:18 PM, John Day wrote: > At 11:55 AM -0800 2/26/13, Joe Touch wrote: >> Hi, John (et al.) >> >> On 2/26/2013 11:35 AM, John Day wrote: >>> At 9:03 AM -0800 2/25/13, Joe Touch wrote: >>>> Hi, John, et al., >>>> >>>> On 2/24/2013 9:20 AM, John Day wrote: >>>>> I would take the view that content is anything in the Application >>>>> Layer, >>>>> i.e. anything above TCP. >>>> >>>> For the purposes of this doc, IMO "content" ought to be anything above >>>> the layer of the service I pay you for. >>> >>> So if my provider provides email, and bundles it in what I pay, even if >>> I don't use it, then email is not "content." That doesn't work. >> >> If you pay for IP, then the fact that the packet is email vs. file >> transfer is content. As is anything above that, including the email or >> file content. >> >> If you pay for email access, then the fact that you're doing email >> isn't content, but the content of the email is. > > Ahhh, so you agree with me. Email performs operations external to the > protocol. TCP does it by reading/writing byte streams. IP does it by reading/writing buffers. Those operations are just the upper layer API, and most protocols have - or could have - one. >>>> There are no other distinctions; what you call an application protocol >>>> I might call a transport or network, esp. when I tunnel TCP or IP over >>>> it. >>> >>> Not the way I defined it. It has nothing to do with what is >>> encapsulated in what. >> >> You referred directly to protocols, but those protocols don't exist at >> exactly one layer in a stack. > > I never said they did. I spoke of a class of protocols defined by their > characteristics. Not where they are in the stack. Where in the stack > is irrelevant. You gave examples in each category. My point is that the examples fit in either category depending on how they're used. Joe