From jefsey@jefsey.com Tue Feb 26 09:27:30 2013 Return-Path: X-Original-To: iucg@ietfa.amsl.com Delivered-To: iucg@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: [iucg] [arch-d] draft-iab-filtering-considerations X-BeenThere: iucg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: internet users contributing group List-Id: internet users contributing group 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