From nobody Wed May 2 10:12:16 2018 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 6C145126DFF for ; Wed, 2 May 2018 10:12:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 26n0Jcog6CaR for ; Wed, 2 May 2018 10:12:09 -0700 (PDT) Received: from mail-lf0-x22c.google.com (mail-lf0-x22c.google.com [IPv6:2a00:1450:4010:c07::22c]) (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 207D4120713 for ; Wed, 2 May 2018 10:12:09 -0700 (PDT) Received: by mail-lf0-x22c.google.com with SMTP id v85-v6so21916696lfa.13 for ; Wed, 02 May 2018 10:12:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=TtF8/WrXYcXH3//tNlrx5j7gK2AGXTgY/XuIepungOY=; b=efOB2lO1s6NWG4UI4OybIzaUhzk1lEJDDSKSw+//W0hjGErNlE2Lxuia53SyiIO3nf XoJ9fghUqywWN3CbnGbyrbvp3x5WDJKFqorYRjJkbeLrwbud/YfpcSUXF9A6ZXW9fD6h kv1YvYMNMqqQ2piqZFia5yu/ltfptlWE0nZyI/vfgByZi/ioB/t0+8MythgBiar1WPJB mvOv/cktNIULX5xsm5sPkEXpJsCHXvU3dAKcS8qS4yswbGtAt40BryC4WXreihyc7/nK ILvDD6L05wPDPT6p3U/3DtLFmrObGyD2HR8fR2IVgGI+oEvUoTY2zlQU/p4WPnZS9dvw TrrA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=TtF8/WrXYcXH3//tNlrx5j7gK2AGXTgY/XuIepungOY=; b=LvkkGDqjxa1EhmAQFZlJsaiKJFsjRbGdcVTr6O1yIhk5p/2Px8evEzdVqg1x+ffP2Y vAbrxhA5bBD0tg8yMZOEC1y2z8u+KBHq8acGetsNM0gcU40z2gjim1iaZvxXj9q90/XT Teg+MmHi8l4oVuuehlFc1ZUzyecoxhdW2NdHBe9AnOMEiQelQpIF8AtqHcjbAARFC4wP REy3VwUW5TJv8NDYVMO6u9X2G8Kc/fJ0NyodZAPqYJqMioN+4JaxehU1y8ghz7n8J0q1 PFH+Bg8Fr7TRlIJ8BxPUG9j0vROcWiFhKeAnwo4kF2puNdJRw8vRKXkeso5QE8mbZbIN JFzQ== X-Gm-Message-State: ALQs6tBAmEVtex9NNsKmIxCQcSiGnPsTO7zTBeQJMI/5X6d8mlycGxvg ZpXshI3zwu9icMIIGbvnFMJB36frBNKytt/Ch+i+hA== X-Google-Smtp-Source: AB8JxZq0aIB0AT1nJJ3iqQYcqWEh25DUMukr8cVWeTpfKxXIFhG3npcD5EOJY5sdeZB0Ddtfn9G2E2qxT9macUCC0cw= X-Received: by 2002:a2e:9c44:: with SMTP id t4-v6mr1716414ljj.86.1525281127053; Wed, 02 May 2018 10:12:07 -0700 (PDT) MIME-Version: 1.0 Received: by 10.46.144.3 with HTTP; Wed, 2 May 2018 10:11:26 -0700 (PDT) From: Shivan Date: Wed, 2 May 2018 13:11:26 -0400 Message-ID: To: hr-rt@irtf.org, architecture-discuss@ietf.org, iab@iab.org Content-Type: multipart/alternative; boundary="000000000000c2c064056b3c2f77" Archived-At: Subject: [arch-d] [HT-rt] HR-RT Review of draft-iab-marnew-report-01 X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.22 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: Wed, 02 May 2018 17:12:13 -0000 --000000000000c2c064056b3c2f77 Content-Type: text/plain; charset="UTF-8" This is a review done within the framework of the Human Rights Review Team. It was done by Amelia Andersdotter and Shivan Kaul Sahib. The Human Rights Review Team aims to implement and improve the guidelines for human rights considerations provided in RFC8280, and seek to mitigate potentially adverse human rights impacts that IETF and IRTF documents might have. We find the topics addressed during the workshop interesting and look forward to following future developments. --- Document: draft-iab-marnew-report-01 https://datatracker.ietf.org/doc/draft-iab-marnew-report/ Review: The Human Rights in Protocols Research Group welcomes the draft report from the MaRNEW workshop. In particular, we welcome the efforts to continue advancing an encrypted, secure and human rights enabling environment, as well as solid assessments of the potential impacts of considered remedies to mobile network operator difficulties on the right to privacy of an individual. In this regard, we wish to remind the drafters and the IAB of the inherent connection between privacy and freedom of expression. The right to privacy, or to one's own personhood, reinforces the freedom of expression and freedom of opinion. Semantic Suggestions =========================== The following sections addresses a few semantic problems in the draft report, that were they solved the draft report would be easier to parse from both a human rights perspective, and from a business, legal or technical perspective. 1. Abstract, para 2: Problem: Draft text contains value judgements on participants' presentations that could be avoided. Solution: Remove the word "honest" in relation to CDN presentations, since it may cause readers to assume that other presenters were less forthcoming. The new paragraph would read The group discussed the current Internet encryption trends and deployment issues identified within the IETF, and the privacy needs of users which should be adhered. Solutions designed around sharing data from the network to the endpoints and vice versa were then discussed as well as analysing whether the current issues experienced on the transport layer are also playing a role here. Content providers and CDNs gave their views of delivering content with mobile network operators. Finally, technical responses to regulation was discussed to help the regulated industries relay the issues of impossible to implement or bad-for-privacy technologies back to regulators. 2. Section 1, Introduction: Problem: It is unclear whether the "requirements" referred to imply regulatory requirements enforceable by government authorities, or technical requirements. Because of the nature of issues discussed during the workshop, understanding what sorts of "requirements" are being referred to is imperative. Solution: Specify the nature of the requirements being referred to, or remove the reference to requirements. The new Introduction would read Mobile networks have a set of properties which places a large emphasis on sophisticated bandwidth optimization. Encryption is increasing on the Internet which is positive for consumer and business privacy and security. Many existing mobile bandwidth optimization solutions primarily operate on non-encrypted communications; this can lead to performance issues being amplified on mobile networks. Encryption on networks will continue to increase; and with this understanding the workshop aimed to understand how we can solve the issues of bandwidth optimization and performance on radio networks in this encrypted world. 3. Section 1.1: Problem: The first paragraph mixes business models with technical necessities. The last paragraph in the section Understanding "Bandwidth Optimization" refers to regulatory requirements (within the meaning of government enforced requirements or legal requirements, cf above) on mobile network operators to perform traffic filtering and monitoring. Solution: It may facilitate understanding of human rights impacts to separate technical considerations from business considerations and legal considerations. Paragraph 3 ("Many of these functions can continue...") could be put as the last paragraph, while Paragraph 1 could be split into a technical section and a business model section, followed by a legal section. For the purposes of this workshop, bandwidth optimization encompasses a variety of technical topics related to traffic engineering, prioritisation, optimisation and efficiency enhancements. It also encompasses user-related topics such as specific subscription or billing models, and may touch upon regulatory aspects or other issues relating to regulatory, within the meaning of government initiated, concerns. The first category of bandwidth optimization includes: o Caching o Prioritisation of interactive traffic over background traffic o Per-user bandwidth limit The second category of bandwidth optimization may depend on either of the first category optimization strategies, but may, in particular, also encompass: o Business-related topics such as content delivery arrangements with specific content providers. Finally, while not strictly speaking traffic management, some networks employ policy-based filtering (e.g., requested parental controls) and many networks support some form of legal interception functionality per applicable laws. Many of these functions can continue as they're performed today, even with more encryption. Others are using methods which inspect parts of the communication that are encrypted, and these will have to be done differently in an encrypted Internet. 4. Section 4: Problem: QUIC is an active area of work for the IETF in the transport layer - this section barely mentions it, and even then does so vaguely. What problems are solved by QUIC that are general problems rather than TCP problems? What was the nature of the disagreement around this? Solution: More detail about how QUIC fits into transport-layer work would make this section more relevant. In addition, there has been discussion involving network operators around technical details that have potential privacy impacts within the QUIC working group (SPIN bit); this section would benefit greatly from an examination of that. Human Rights Considerations =========================== Upon consideration of the draft report, no implications for internationalization ([RFC8280], sec. 6.2.5), heterogeneity support ([RFC8280], sec. 6.2.8), accessibility ([RFC8280], sec. 6.2.11) or localization ([RFC8280], sec. 6.2.12) have been found. We will further suppose that issues relating to Anonymity ([RFC8280], sec. 6.2.9), Pseudonymity ([RFC8280], sec. 6.2.10) and Confidentiality ([RFC8280], sec. 6.2.16) have been sufficiently addressed in the draft as is. In the below text, Security ([RFC8280], sec. 6.2.4), Integrity ([RFC8280], sec. 6.2.16) and Authenticity ([RFC8280], sec. 6.2.17) are further considered to have been addressed, or as in progress of being addressed by the specific endeavours pointed out in the report. As such, this assessment hopes to serve as a complement to remaining Human Rights Considerations Guidelines which were not addressed by the MaRNEW draft. ## Privacy ([RFC8280], sec. 6.2.2) We laud the general emphasis on considering user privacy concerns paramount [Section 2.1.1, 2.3 etc]. In Section 3.1.1, para 1, it would be useful to emphasize that middleboxes that are "authenticated and invoked explicitly" might not be very effective at conserving user privacy if they lead to auto-click through. In practice, "opted-in" middleboxes might not be much better than transparent middleboxes. Additionally, this poses the danger of making matters worse if users assume that because they haven't been asked for middlebox permission, they are not going through a middlebox. For users accessing the Internet on a browser client: if the connection is MITMed by a middlebox, the browser would somehow need to convey this effectively and actionably to the user. Whatever effort is expended on this should involve browser vendors. ## Connectivity ([RFC8280], sec. 6.2.1) It is a priori obvious that a discussion with mobile network operators would touch upon connectivity. As a general comment, the HRPC RG is not concerned that encrypted internet traffic could create topological problems in network deployment with respect to density of base stations. It is more sensible to imagine that the density of base stations is kept low by deployers to save money on infrastructure roll-out. In the MarNEW draft report, middleboxes are brought up frequently as an example of infrastructure rendered less useful by the ubiquitous adoption of encryption. Middleboxes may enhance access to content for individuals, and may also interfere with their ability to enjoy content free of surveillance, censorship or content manipulation. The focus of the workshop of exploring ways in which encrypted materials can benefit from the same speed of deliverance as un-encrypted materials is therefore welcome. ## Content Agnosticism Traffic prioritisation, whether based on technical or commercial grounds, risks interfering with an individual's right to freedom of expression or opinion, by restricting access or enjoy content of their own choosing. As such, prioritisation should be made explicit and obvious, and subject to consent from the individual, whether the motivations for deployment are commercial or technical. It is clear that internet filtering and blocking of content of specific types, whether motivated by network management or regulatory concerns, does not fulfill a content agnosticism criterion. It is the observation of HRPC that [RFC7725] (An HTTP Status Code to Report Legal Obstacles) may assist communication of specific filtering and blocking operations in action. It the the impetus of the Human Rights Guidelines in RFC8280 that content agnosticism be respected by protocols developed in the IETF, and in general an accepted view in the global human rights community that content agnosticism is desirable at all levels of technical infrastructure. As such, the HRPC RG is concerned about ideas that traffic be classified through additional headers or metadata, identifying traffic via 5-tuples, trust models and frameworks, or heuristics. --000000000000c2c064056b3c2f77 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
= This is a rev= iew done within the framework of the Human Rights Review
Team. It was done by Amelia Andersdotter and S= hivan Kaul Sahib. The Human
Rights Review Team aims to implem= ent and improve the guidelines for
human rights consideration= s provided in RFC8280, and seek to mitigate
potentially adver= se human rights impacts that IETF and IRTF documents
might ha= ve.

We find the topics addressed during = the workshop interesting and look
= forward to following future= developments.

= ---

Document: draft-iab-marnew-report-01
https://datatracker.ietf.org/doc/draft-iab-marnew-report/

Review:
<= font color=3D"#333333" face=3D"georgia, serif">
The Huma= n Rights in Protocols Research Group welcomes the draft report from the MaR= NEW workshop. In particular, we welcome the efforts to continue advancing a= n encrypted, secure and human rights enabling environment, as well as solid= assessments of the potential impacts of considered remedies to mobile netw= ork operator difficulties on the right to privacy of an individual.<= /div>

In this regard, we wish to remind the drafters an= d the IAB of the inherent connection between privacy and freedom of express= ion. The right to privacy, or to one's own personhood, reinforces the f= reedom of expression and freedom of opinion.

Semantic Suggestions
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

The following sections addresses a few semantic problems in the draft r= eport, that were they solved the draft report would be easier to parse from= both a human rights perspective, and from a business, legal or technical p= erspective.

1. Abstract, para 2:

Problem: Draft text contains=C2=A0 value judgements= on participants' presentations that could be avoided.
Solution: Remove the word "honest" in relation t= o CDN presentations, since it may cause readers to assume that other presen= ters were less forthcoming.

The new paragr= aph would read

= =C2=A0 =C2=A0The group disc= ussed the current Internet encryption trends and
=C2=A0 =C2= =A0deployment issues identified within the IETF, and the privacy needs
=C2=A0 =C2=A0of users which should be adhered.=C2=A0 Solutions de= signed around sharing
=C2=A0 =C2=A0data from the network to = the endpoints and vice versa were then
=C2=A0 =C2=A0discussed= as well as analysing whether the current issues experienced
= =C2=A0 =C2=A0on the transport layer are also playing a role here.=C2=A0 Con= tent
=C2=A0 =C2=A0providers and CDNs gave their views of del= ivering
=C2=A0 =C2=A0content with mobile network operators.= =C2=A0 Finally, technical responses
=C2=A0 =C2=A0to regulatio= n was discussed to help the regulated industries relay
=C2=A0= =C2=A0the issues of impossible to implement or bad-for-privacy technologie= s
=C2=A0 =C2=A0back to regulators.

<= /div>
2. Section 1, Introduction:

Problem= : It is unclear whether the "requirements" referred to imply regu= latory requirements enforceable by government authorities, or technical req= uirements. Because of the nature of issues discussed during the workshop, u= nderstanding what sorts of "requirements" are being referred to i= s imperative.

<= font color=3D"#333333" face=3D"georgia, serif">Solution: Specify the nature= of the requirements being referred to, or remove the reference to requirem= ents.

The new Introduction would read

=C2=A0 =C2=A0Mobile networks have a set of pro= perties which
=C2=A0 =C2=A0places a large emphasis on sophist= icated bandwidth optimization.
=C2=A0 =C2=A0Encryption is inc= reasing on the Internet which is positive for
=C2=A0 =C2=A0co= nsumer and business privacy and security.=C2=A0 Many existing mobile=
=C2=A0 =C2=A0bandwidth optimization solutions primarily operate on = non-encrypted
=C2=A0 =C2=A0communications; this can lead to p= erformance issues being amplified
= =C2=A0 =C2=A0on mobile netw= orks.=C2=A0 Encryption on networks will continue to
=C2=A0 = =C2=A0increase; and with this understanding the workshop aimed to
=C2=A0 =C2=A0understand how we can solve the issues of bandwidth optim= ization and
=C2=A0 =C2=A0performance on radio networks in thi= s encrypted world.

3. Section 1.1:<= /div>

Problem: The first paragraph mixes business model= s with technical necessities. The last paragraph in the section Understandi= ng "Bandwidth Optimization" refers to regulatory requirements (wi= thin the meaning of government enforced requirements or legal requirements,= cf above) on mobile network operators to perform traffic filtering and mon= itoring.

Solution: It may facilitate under= standing of human rights impacts to separate technical considerations from = business considerations and legal considerations. Paragraph 3 ("Many o= f these functions can continue...") could be put as the last paragraph= , while Paragraph 1 could be split into a technical section and a business = model section, followed by a legal section.

=
=C2=A0 =C2=A0For the purposes of this workshop, bandwi= dth optimization encompasses
=C2=A0 =C2=A0a variety of techni= cal topics related to traffic engineering,
=C2=A0 =C2=A0prior= itisation, optimisation and efficiency enhancements. It also encompasses
=C2=A0 =C2=A0user-related topics such as specific subscription = or billing models, and may touch upon regulatory aspects or other issues re= lating to regulatory, within the meaning of government initiated, concerns.=

=C2=A0 =C2=A0The first category of bandwi= dth optimization includes:

=C2=A0 =C2=A0o= =C2=A0 Caching

= =C2=A0 =C2=A0o=C2=A0 Priori= tisation of interactive traffic over background traffic

<= /font>
=C2=A0 =C2=A0o=C2=A0 Per-user bandwidth limit
= =C2=A0 =C2=A0
=C2=A0 =C2=A0The second category of bandwidth o= ptimization may depend on either of the first category optimization strateg= ies, but may, in particular, also encompass:

=C2=A0 =C2=A0o=C2=A0 Business-related topics such as content delivery ar= rangements with
=C2=A0 =C2=A0 =C2=A0 specific content provide= rs.
=C2=A0 =C2=A0 =C2=A0=C2=A0
=C2=A0 =C2=A0F= inally, while not strictly speaking traffic management, some
= =C2=A0 =C2=A0networks employ policy-based filtering (e.g., requested parent= al
=C2=A0 =C2=A0controls) and many networks support some form= of legal interception
=C2=A0 =C2=A0functionality per applica= ble laws.

=C2=A0 =C2=A0Many of these funct= ions can continue as they're performed today, even
=C2=A0= =C2=A0with more encryption.=C2=A0 Others are using methods which inspect p= arts
=C2=A0 =C2=A0of the communication that are encrypted, a= nd these will have to be
=C2=A0 =C2=A0done differently in an = encrypted Internet.


4. = Section 4:

Problem: QUIC is an active area= of work for the IETF in the transport layer - this section barely mentions= it, and even then does so vaguely. What problems are solved by QUIC that a= re general problems rather than TCP problems? What was the nature of the di= sagreement around this?

Solution: More det= ail about how QUIC fits into transport-layer work would make this section m= ore relevant. In addition, there has been discussion involving network oper= ators around technical details that have potential privacy impacts within t= he QUIC working group (SPIN bit); this section would benefit greatly from a= n examination of that.


=
Human Rights Considerations
=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

Upon consideration of the draft report, no impl= ications for internationalization ([RFC8280], sec. 6.2.5), heterogeneity su= pport ([RFC8280], sec. 6.2.8), accessibility ([RFC8280], sec. 6.2.11) or lo= calization ([RFC8280], sec. 6.2.12) have been found. We will further suppos= e that issues relating to Anonymity ([RFC8280], sec. 6.2.9), Pseudonymity (= [RFC8280], sec. 6.2.10) and Confidentiality ([RFC8280], sec. 6.2.16) have b= een sufficiently addressed in the draft as is.

In the below text, Security ([RFC8280], sec. 6.2.4), Integrity ([RFC82= 80], sec. 6.2.16) and Authenticity ([RFC8280], sec. 6.2.17) are further con= sidered to have been addressed, or as in progress of being addressed by the= specific endeavours pointed out in the report. As such, this assessment ho= pes to serve as a complement to remaining Human Rights Considerations Guide= lines which were not addressed by the MaRNEW draft.

## Privacy ([RFC8280], sec. 6.2.2)

We laud the general emphasis on considering user privacy concerns param= ount [Section 2.1.1, 2.3 etc].=C2=A0

In Se= ction 3.1.1, para 1, it would be useful to emphasize that middleboxes that = are "authenticated and invoked explicitly" might not be very effe= ctive at conserving user privacy if they lead to auto-click through. In pra= ctice, "opted-in" middleboxes might not be much better than trans= parent middleboxes. Additionally, this poses the danger of making matters w= orse if users assume that because they haven't been asked for middlebox= permission, they are not going through a middlebox. For users accessing th= e Internet on a browser client: if the connection is MITMed by a middlebox,= the browser would somehow need to convey this effectively and actionably t= o the user. Whatever effort is expended on this should involve browser vend= ors.

## Connectivity ([RFC8280], sec. 6.2= .1)

It is a priori obvious that a discus= sion with mobile network operators would touch upon connectivity. As a gene= ral comment, the HRPC RG is not concerned that encrypted internet traffic c= ould create topological problems in network deployment with respect to dens= ity of base stations. It is more sensible to imagine that the density of ba= se stations is kept low by deployers to save money on infrastructure roll-o= ut.

In the MarNEW draft report, middlebo= xes are brought up frequently as an example of infrastructure rendered less= useful by the ubiquitous adoption of encryption. Middleboxes may enhance a= ccess to content for individuals, and may also interfere with their ability= to enjoy content free of surveillance, censorship or content manipulation.= The focus of the workshop of exploring ways in which encrypted materials c= an benefit from the same speed of deliverance as un-encrypted materials is = therefore welcome.

## Content Agnosticism<= /font>

Traffic prioritisation, whether based on t= echnical or commercial grounds, risks interfering with an individual's = right to freedom of expression or opinion, by restricting access or enjoy c= ontent of their own choosing. As such, prioritisation should be made explic= it and obvious, and subject to consent from the individual, whether the mot= ivations for deployment are commercial or technical.

It is clear that internet filtering and blocking of content of s= pecific types, whether motivated by network management or regulatory concer= ns, does not fulfill a content agnosticism criterion. It is the observation= of HRPC that [RFC7725] (An HTTP Status Code to Report Legal Obstacles) may= assist communication of specific filtering and blocking operations in acti= on.

It the the impetus of the Human Righ= ts Guidelines in RFC8280 that content agnosticism be respected by protocols= developed in the IETF, and in general an accepted view in the global human= rights community that content agnosticism is desirable at all levels of te= chnical infrastructure. As such, the HRPC RG is concerned about ideas that = traffic be classified through additional headers or metadata, identifying t= raffic via 5-tuples, trust models and frameworks, or heuristics.


--000000000000c2c064056b3c2f77-- From nobody Thu May 3 12:42:13 2018 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 9C80412EABF for ; Thu, 3 May 2018 12:42:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 EdvpSQ7JHEma for ; Thu, 3 May 2018 12:42:00 -0700 (PDT) Received: from mail-yw0-x233.google.com (mail-yw0-x233.google.com [IPv6:2607:f8b0:4002:c05::233]) (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 5A5D712E05D for ; Thu, 3 May 2018 12:42:00 -0700 (PDT) Received: by mail-yw0-x233.google.com with SMTP id v132-v6so6014552ywc.6 for ; Thu, 03 May 2018 12:42:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=51BA51Pfw6XXoEHfiAUKi9yXcKezpjBtmnlzQsTzy28=; b=Ttb//Mruos5t4xs8KBi7vN/Ee6VQOqYRnCMIbbOBUwO2UE5PWr87A9k9eA1nQc9cQJ go6N981rankOy8BtlwYaR1olTW+BUjlI0OEZTcywgEoMlnihIpsZ/DLBIWmcuxlpS1Fd p5XmZ239B7cjQDmcG5aItCUdbN2D0L9EMkX9zlYdSvA1YEXFLi+p+gftQyVGAqpmxJ/z tTUn2WlcnZpMb/7T6OqsIgUsWETH6sTuKeRVVRRH6SbXEbWopyUy5VGenym5oMTbSup+ 9sZyaU/k+yycW0IJuhvcl8JZA1WmuxwKvD9cswaOB19QSI8PwY/9r4/tmTf0ocIUfzrp sX8w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=51BA51Pfw6XXoEHfiAUKi9yXcKezpjBtmnlzQsTzy28=; b=KKbbTocWtTt4ffESQBpbyuVrWduprMi7qFHNReQlf7IXl25kmJvmuLKF536j92rUmP omkQPkuXDXPl/j4Yq9q0uyKJoMhrI0Ajs2kTyUxNrHXYBexs/IEr+v9ynZ8G0W0RTqVL Mp1eTZ2gd5gVHGGsxdC5bM2Gc0QbP79bl9Z1GLZZ3O8us9nveEioLpKe1jAm29zqHSYt fiNev2HHSpgkM5OqYwBnUgyKs66W5jCw7wLh+O1vad/8fGKFYaQ3gwb0NCeIx6PIatKT InymVkWKEWnGVcpUH0ERnuKDxIIz6UPIdYD+YSDowtWoiwOsPZYg8NtcEVrvekrVE3dX FAjA== X-Gm-Message-State: ALQs6tAaPp+2bX+kHhRd5ekUpxSpppWPJysHl81okII/0rFqxkzMfYhw cjyFBK54ew0IDeTABvG3LHKIAaVl8V08oD+dbUY= X-Google-Smtp-Source: AB8JxZpbvaZVQSb/+o5AS1q9cwZAG0CvIbI6yRBINCFlPvwZGsAUAZ7tQ4gttNjpQcepRtD76U09j9MbD/8PtzLHvPM= X-Received: by 2002:a81:29d1:: with SMTP id p200-v6mr13994372ywp.424.1525376519232; Thu, 03 May 2018 12:41:59 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a25:d014:0:0:0:0:0 with HTTP; Thu, 3 May 2018 12:41:58 -0700 (PDT) In-Reply-To: References: From: Spencer Dawkins at IETF Date: Thu, 3 May 2018 14:41:58 -0500 Message-ID: To: Shivan Cc: hr-rt@irtf.org, architecture-discuss@ietf.org, IAB IAB Content-Type: multipart/alternative; boundary="00000000000093e065056b52652d" Archived-At: Subject: Re: [arch-d] [HT-rt] HR-RT Review of draft-iab-marnew-report-01 X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.22 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: Thu, 03 May 2018 19:42:05 -0000 --00000000000093e065056b52652d Content-Type: text/plain; charset="UTF-8" Hi, Shivan, On Wed, May 2, 2018 at 12:11 PM, Shivan wrote: > This is a review done within the framework of the Human Rights Review > Team. It was done by Amelia Andersdotter and Shivan Kaul Sahib. The Human > Rights Review Team aims to implement and improve the guidelines for > human rights considerations provided in RFC8280, and seek to mitigate > potentially adverse human rights impacts that IETF and IRTF documents > might have. > Thanks for the comments. On one point below ... > We find the topics addressed during the workshop interesting and look > forward to following future developments. > > --- > > Document: draft-iab-marnew-report-01 > > https://datatracker.ietf.org/doc/draft-iab-marnew-report/ > > Review: > > The Human Rights in Protocols Research Group welcomes the draft report > from the MaRNEW workshop. In particular, we welcome the efforts to continue > advancing an encrypted, secure and human rights enabling environment, as > well as solid assessments of the potential impacts of considered remedies > to mobile network operator difficulties on the right to privacy of an > individual. > > In this regard, we wish to remind the drafters and the IAB of the inherent > connection between privacy and freedom of expression. The right to privacy, > or to one's own personhood, reinforces the freedom of expression and > freedom of opinion. > > Semantic Suggestions > =========================== > > The following sections addresses a few semantic problems in the draft > report, that were they solved the draft report would be easier to parse > from both a human rights perspective, and from a business, legal or > technical perspective. > > 1. Abstract, para 2: > > Problem: Draft text contains value judgements on participants' > presentations that could be avoided. > > Solution: Remove the word "honest" in relation to CDN presentations, since > it may cause readers to assume that other presenters were less forthcoming. > > The new paragraph would read > > The group discussed the current Internet encryption trends and > deployment issues identified within the IETF, and the privacy needs > of users which should be adhered. Solutions designed around sharing > data from the network to the endpoints and vice versa were then > discussed as well as analysing whether the current issues experienced > on the transport layer are also playing a role here. Content > providers and CDNs gave their views of delivering > content with mobile network operators. Finally, technical responses > to regulation was discussed to help the regulated industries relay > the issues of impossible to implement or bad-for-privacy technologies > back to regulators. > > 2. Section 1, Introduction: > > Problem: It is unclear whether the "requirements" referred to imply > regulatory requirements enforceable by government authorities, or technical > requirements. Because of the nature of issues discussed during the > workshop, understanding what sorts of "requirements" are being referred to > is imperative. > > Solution: Specify the nature of the requirements being referred to, or > remove the reference to requirements. > > The new Introduction would read > > Mobile networks have a set of properties which > places a large emphasis on sophisticated bandwidth optimization. > Encryption is increasing on the Internet which is positive for > consumer and business privacy and security. Many existing mobile > bandwidth optimization solutions primarily operate on non-encrypted > communications; this can lead to performance issues being amplified > on mobile networks. Encryption on networks will continue to > increase; and with this understanding the workshop aimed to > understand how we can solve the issues of bandwidth optimization and > performance on radio networks in this encrypted world. > > 3. Section 1.1: > > Problem: The first paragraph mixes business models with technical > necessities. The last paragraph in the section Understanding "Bandwidth > Optimization" refers to regulatory requirements (within the meaning of > government enforced requirements or legal requirements, cf above) on mobile > network operators to perform traffic filtering and monitoring. > > Solution: It may facilitate understanding of human rights impacts to > separate technical considerations from business considerations and legal > considerations. Paragraph 3 ("Many of these functions can continue...") > could be put as the last paragraph, while Paragraph 1 could be split into a > technical section and a business model section, followed by a legal section. > > > For the purposes of this workshop, bandwidth optimization encompasses > a variety of technical topics related to traffic engineering, > prioritisation, optimisation and efficiency enhancements. It also > encompasses > user-related topics such as specific subscription or billing models, > and may touch upon regulatory aspects or other issues relating to > regulatory, within the meaning of government initiated, concerns. > > The first category of bandwidth optimization includes: > > o Caching > > o Prioritisation of interactive traffic over background traffic > > o Per-user bandwidth limit > > The second category of bandwidth optimization may depend on either of > the first category optimization strategies, but may, in particular, also > encompass: > > o Business-related topics such as content delivery arrangements with > specific content providers. > > Finally, while not strictly speaking traffic management, some > networks employ policy-based filtering (e.g., requested parental > controls) and many networks support some form of legal interception > functionality per applicable laws. > > Many of these functions can continue as they're performed today, even > with more encryption. Others are using methods which inspect parts > of the communication that are encrypted, and these will have to be > done differently in an encrypted Internet. > > > 4. Section 4: > > Problem: QUIC is an active area of work for the IETF in the transport > layer - this section barely mentions it, and even then does so vaguely. > What problems are solved by QUIC that are general problems rather than TCP > problems? What was the nature of the disagreement around this? > > Solution: More detail about how QUIC fits into transport-layer work would > make this section more relevant. In addition, there has been discussion > involving network operators around technical details that have potential > privacy impacts within the QUIC working group (SPIN bit); this section > would benefit greatly from an examination of that. > I have comments from two other reviewers asking that this document actually state the dates of the workshop, and I'll add that. If the version of the draft you reviewed had included those dates, it would have been clearer that the workshop happened in September 2015, which was more than a year before QUIC was chartered (BOF in July 2016, chartered in October 2016). I'm helping the IAB finish this report, so taking direction from them, but my understanding is that IAB workshop reports should reflect the situation at the time of the workshop, so I shouldn't say much about QUIC in the workshop report. FWIW, I agree with you, but I'm keeping that opinion out of the report ... and now you know why. Spencer Human Rights Considerations > =========================== > > Upon consideration of the draft report, no implications for > internationalization ([RFC8280], sec. 6.2.5), heterogeneity support > ([RFC8280], sec. 6.2.8), accessibility ([RFC8280], sec. 6.2.11) or > localization ([RFC8280], sec. 6.2.12) have been found. We will further > suppose that issues relating to Anonymity ([RFC8280], sec. 6.2.9), > Pseudonymity ([RFC8280], sec. 6.2.10) and Confidentiality ([RFC8280], sec. > 6.2.16) have been sufficiently addressed in the draft as is. > > In the below text, Security ([RFC8280], sec. 6.2.4), Integrity ([RFC8280], > sec. 6.2.16) and Authenticity ([RFC8280], sec. 6.2.17) are further > considered to have been addressed, or as in progress of being addressed by > the specific endeavours pointed out in the report. As such, this assessment > hopes to serve as a complement to remaining Human Rights Considerations > Guidelines which were not addressed by the MaRNEW draft. > > ## Privacy ([RFC8280], sec. 6.2.2) > > We laud the general emphasis on considering user privacy concerns > paramount [Section 2.1.1, 2.3 etc]. > > In Section 3.1.1, para 1, it would be useful to emphasize that middleboxes > that are "authenticated and invoked explicitly" might not be very effective > at conserving user privacy if they lead to auto-click through. In practice, > "opted-in" middleboxes might not be much better than transparent > middleboxes. Additionally, this poses the danger of making matters worse if > users assume that because they haven't been asked for middlebox permission, > they are not going through a middlebox. For users accessing the Internet on > a browser client: if the connection is MITMed by a middlebox, the browser > would somehow need to convey this effectively and actionably to the user. > Whatever effort is expended on this should involve browser vendors. > > ## Connectivity ([RFC8280], sec. 6.2..1) > > It is a priori obvious that a discussion with mobile network operators > would touch upon connectivity. As a general comment, the HRPC RG is not > concerned that encrypted internet traffic could create topological problems > in network deployment with respect to density of base stations. It is more > sensible to imagine that the density of base stations is kept low by > deployers to save money on infrastructure roll-out. > > In the MarNEW draft report, middleboxes are brought up frequently as an > example of infrastructure rendered less useful by the ubiquitous adoption > of encryption. Middleboxes may enhance access to content for individuals, > and may also interfere with their ability to enjoy content free of > surveillance, censorship or content manipulation. The focus of the workshop > of exploring ways in which encrypted materials can benefit from the same > speed of deliverance as un-encrypted materials is therefore welcome. > > ## Content Agnosticism > > Traffic prioritisation, whether based on technical or commercial grounds, > risks interfering with an individual's right to freedom of expression or > opinion, by restricting access or enjoy content of their own choosing. As > such, prioritisation should be made explicit and obvious, and subject to > consent from the individual, whether the motivations for deployment are > commercial or technical. > > It is clear that internet filtering and blocking of content of specific > types, whether motivated by network management or regulatory concerns, does > not fulfill a content agnosticism criterion. It is the observation of HRPC > that [RFC7725] (An HTTP Status Code to Report Legal Obstacles) may assist > communication of specific filtering and blocking operations in action. > > It the the impetus of the Human Rights Guidelines in RFC8280 that content > agnosticism be respected by protocols developed in the IETF, and in general > an accepted view in the global human rights community that content > agnosticism is desirable at all levels of technical infrastructure. As > such, the HRPC RG is concerned about ideas that traffic be classified > through additional headers or metadata, identifying traffic via 5-tuples, > trust models and frameworks, or heuristics. > > > > > _______________________________________________ > Architecture-discuss mailing list > Architecture-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/architecture-discuss > > --00000000000093e065056b52652d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi, Shivan,=C2=A0

On Wed, May 2, 2018 at 12:11 PM, Shivan = <shivanka= ul.1993@gmail.com> wrote:
<= div dir=3D"ltr">
This is a review done within the framework of the Human Rights= Review
Team. It was done by Amelia Andersdotter and Shivan Kaul Sahib. The = Human
Righ= ts Review Team aims to implement and improve the guidelines for
human rights consider= ations provided in RFC8280, and seek to mitigate
potentially adverse human rights imp= acts that IETF and IRTF documents
might have.

Thanks for the comments. On one point below ...
=C2=A0
We find the= topics addressed during the workshop interesting and look
=
forward to following f= uture developments.

---
<= br>

The Human Rights in Protocols = Research Group welcomes the draft report from the MaRNEW workshop. In parti= cular, we welcome the efforts to continue advancing an encrypted, secure an= d human rights enabling environment, as well as solid assessments of the po= tential impacts of considered remedies to mobile network operator difficult= ies on the right to privacy of an individual.

In this regard, we wish to remind the draft= ers and the IAB of the inherent connection between privacy and freedom of e= xpression. The right to privacy, or to one's own personhood, reinforces= the freedom of expression and freedom of opinion.

Semantic Suggestions
= =3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

The following sections addresses a = few semantic problems in the draft report, that were they solved the draft = report would be easier to parse from both a human rights perspective, and f= rom a business, legal or technical perspective.

1. Abstract, para 2:

Problem: Draft text contains=C2=A0 v= alue judgements on participants' presentations that could be avoided.

=
Solution: Remove= the word "honest" in relation to CDN presentations, since it may= cause readers to assume that other presenters were less forthcoming.

The new paragraph wo= uld read
<= br>
=C2=A0= =C2=A0The group discussed the current Internet encryption trends and
=C2=A0 =C2=A0de= ployment issues identified within the IETF, and the privacy needs
=C2=A0 =C2=A0of use= rs which should be adhered.=C2=A0 Solutions designed around sharing<= /div>
=C2=A0 =C2=A0data= from the network to the endpoints and vice versa were then
=C2=A0 =C2=A0discussed as= well as analysing whether the current issues experienced
= =C2=A0 =C2=A0on the transpo= rt layer are also playing a role here.=C2=A0 Content
=C2=A0 =C2=A0providers and CDNs = gave their views of delivering
=C2=A0 =C2=A0content with mobile network operators.=C2= =A0 Finally, technical responses
=C2=A0 =C2=A0to regulation was discussed to help the= regulated industries relay
=C2=A0 =C2=A0the issues of impossible to implement or b= ad-for-privacy technologies
=C2=A0 =C2=A0back to regulators.

2. Section 1, Introduction:

Problem: It is unclear w= hether the "requirements" referred to imply regulatory requiremen= ts enforceable by government authorities, or technical requirements. Becaus= e of the nature of issues discussed during the workshop, understanding what= sorts of "requirements" are being referred to is imperative.

Solution: Specify = the nature of the requirements being referred to, or remove the reference t= o requirements.

The new Introduction would read

=C2=A0 =C2=A0Mobile networks have a set of properties w= hich
=C2= =A0 =C2=A0places a large emphasis on sophisticated bandwidth optimization.<= /font>
=C2=A0 =C2= =A0Encryption is increasing on the Internet which is positive for
=C2=A0 =C2=A0consum= er and business privacy and security.=C2=A0 Many existing mobile
=C2=A0 =C2=A0bandwid= th optimization solutions primarily operate on non-encrypted
=C2=A0 =C2=A0communicati= ons; this can lead to performance issues being amplified
<= font color=3D"#333333" face=3D"georgia, serif">=C2=A0 =C2=A0on mobile netwo= rks.=C2=A0 Encryption on networks will continue to
=C2=A0 =C2=A0increase; and with th= is understanding the workshop aimed to
=C2=A0 =C2=A0understand how we can solve the i= ssues of bandwidth optimization and
=C2=A0 =C2=A0performance on radio networks in thi= s encrypted world.

3. Section 1.1:

Problem: The first paragraph mixes business models with technical nece= ssities. The last paragraph in the section Understanding "Bandwidth Op= timization" refers to regulatory requirements (within the meaning of g= overnment enforced requirements or legal requirements, cf above) on mobile = network operators to perform traffic filtering and monitoring.
=

= Solution: It may facilitate= understanding of human rights impacts to separate technical considerations= from business considerations and legal considerations. Paragraph 3 ("= Many of these functions can continue...") could be put as the last par= agraph, while Paragraph 1 could be split into a technical section and a bus= iness model section, followed by a legal section.


=C2=A0 =C2=A0For the purposes of this works= hop, bandwidth optimization encompasses
=C2=A0 =C2=A0a variety of technical topics re= lated to traffic engineering,
=C2=A0 =C2=A0prioritisation, optimisation and efficienc= y enhancements. It also encompasses
=C2=A0 =C2=A0user-related topics such as specific= subscription or billing models, and may touch upon regulatory aspects or o= ther issues relating to regulatory, within the meaning of government initia= ted, concerns.

= =C2=A0 =C2=A0The first category of bandwidth optimization includes:<= /div>

=
=C2=A0 =C2=A0o=C2=A0 C= aching
=C2=A0 = =C2=A0o=C2=A0 Prioritisation of interactive traffic over background traffic=

=C2=A0 =C2=A0o= =C2=A0 Per-user bandwidth limit
=C2=A0 =C2=A0
=C2=A0 =C2=A0The second category of bandwidth opt= imization may depend on either of the first category optimization strategie= s, but may, in particular, also encompass:

=C2=A0 =C2=A0o=C2=A0 Business-related topics su= ch as content delivery arrangements with
=C2=A0 =C2=A0 =C2=A0 specific content provid= ers.
=C2= =A0 =C2=A0 =C2=A0=C2=A0
=C2=A0 =C2=A0Finally, while not strictly speaking traffic man= agement, some
=C2=A0 =C2=A0networks employ policy-based filtering (e.g., requested pa= rental
=C2= =A0 =C2=A0controls) and many networks support some form of legal intercepti= on
=C2=A0 = =C2=A0functionality per applicable laws.

=C2=A0 =C2=A0Many of these functions can continue= as they're performed today, even
=C2=A0 =C2=A0with more encryption.=C2=A0 Others= are using methods which inspect parts
=C2=A0 =C2=A0of the communication that are enc= rypted, and these will have to be
=C2=A0 =C2=A0done differently in an encrypted Inter= net.

<= /font>

4. Section 4:

=
Problem: QUIC is= an active area of work for the IETF in the transport layer - this section = barely mentions it, and even then does so vaguely. What problems are solved= by QUIC that are general problems rather than TCP problems? What was the n= ature of the disagreement around this?

Solution: More detail about how QUIC fits into tran= sport-layer work would make this section more relevant. In addition, there = has been discussion involving network operators around technical details th= at have potential privacy impacts within the QUIC working group (SPIN bit);= this section would benefit greatly from an examination of that.

I have comments from two oth= er reviewers asking that this document actually state the dates of the work= shop, and I'll add that.=C2=A0

If the version = of the draft you reviewed had included those dates, it would have been clea= rer that the workshop happened in September 2015, which was more than a yea= r before QUIC was chartered (BOF in July 2016, chartered in October 2016).<= /div>

I'm helping the IAB finish this report, so tak= ing direction from them, but my understanding is that IAB workshop reports = should reflect the situation at the time of the workshop, so I shouldn'= t say much about QUIC in the workshop report.=C2=A0

FWIW, I agree with you, but I'm keeping that opinion out of the repor= t ... and now you know why.

Spencer

=
Human Rights Considerati= ons
= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D
Upon con= sideration of the draft report, no implications for internationalization ([= RFC8280], sec. 6.2.5), heterogeneity support ([RFC8280], sec. 6.2.8), acces= sibility ([RFC8280], sec. 6.2.11) or localization ([RFC8280], sec. 6.2.12) = have been found. We will further suppose that issues relating to Anonymity = ([RFC8280], sec. 6.2.9), Pseudonymity ([RFC8280], sec. 6.2.10) and Confiden= tiality ([RFC8280], sec. 6.2.16) have been sufficiently addressed in the dr= aft as is.

In t= he below text, Security ([RFC8280], sec. 6.2.4), Integrity ([RFC8280], sec.= 6.2.16) and Authenticity ([RFC8280], sec. 6.2.17) are further considered t= o have been addressed, or as in progress of being addressed by the specific= endeavours pointed out in the report. As such, this assessment hopes to se= rve as a complement to remaining Human Rights Considerations Guidelines whi= ch were not addressed by the MaRNEW draft.

## Privacy ([RFC8280], sec. 6.2.2)
=

= We laud the general emphasi= s on considering user privacy concerns paramount [Section 2.1.1, 2.3 etc].= =C2=A0
In Secti= on 3.1.1, para 1, it would be useful to emphasize that middleboxes that are= "authenticated and invoked explicitly" might not be very effecti= ve at conserving user privacy if they lead to auto-click through. In practi= ce, "opted-in" middleboxes might not be much better than transpar= ent middleboxes. Additionally, this poses the danger of making matters wors= e if users assume that because they haven't been asked for middlebox pe= rmission, they are not going through a middlebox. For users accessing the I= nternet on a browser client: if the connection is MITMed by a middlebox, th= e browser would somehow need to convey this effectively and actionably to t= he user. Whatever effort is expended on this should involve browser vendors= .

## Connectivi= ty ([RFC8280], sec. 6.2..1)

It is a priori obvious that a discussion with mobile network= operators would touch upon connectivity. As a general comment, the HRPC RG= is not concerned that encrypted internet traffic could create topological = problems in network deployment with respect to density of base stations. It= is more sensible to imagine that the density of base stations is kept low = by deployers to save money on infrastructure roll-out.

In the MarNEW draft report, middleb= oxes are brought up frequently as an example of infrastructure rendered les= s useful by the ubiquitous adoption of encryption. Middleboxes may enhance = access to content for individuals, and may also interfere with their abilit= y to enjoy content free of surveillance, censorship or content manipulation= . The focus of the workshop of exploring ways in which encrypted materials = can benefit from the same speed of deliverance as un-encrypted materials is= therefore welcome.

## Content Agnosticism

Traffic prioritisation, whether based on technical or commer= cial grounds, risks interfering with an individual's right to freedom o= f expression or opinion, by restricting access or enjoy content of their ow= n choosing. As such, prioritisation should be made explicit and obvious, an= d subject to consent from the individual, whether the motivations for deplo= yment are commercial or technical.

It is clear that internet filtering and blocking of con= tent of specific types, whether motivated by network management or regulato= ry concerns, does not fulfill a content agnosticism criterion. It is the ob= servation of HRPC that [RFC7725] (An HTTP Status Code to Report Legal Obsta= cles) may assist communication of specific filtering and blocking operation= s in action.

It= the the impetus of the Human Rights Guidelines in RFC8280 that content agn= osticism be respected by protocols developed in the IETF, and in general an= accepted view in the global human rights community that content agnosticis= m is desirable at all levels of technical infrastructure. As such, the HRPC= RG is concerned about ideas that traffic be classified through additional = headers or metadata, identifying traffic via 5-tuples, trust models and fra= meworks, or heuristics.




_______________________________________________
Architecture-discuss mailing list
Architecture-discuss@ietf.= org
https://www.ietf.org/mailman/listinf= o/architecture-discuss


--00000000000093e065056b52652d-- From nobody Thu May 3 14:48:03 2018 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 4116712EA67 for ; Thu, 3 May 2018 14:47:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 NvrUSw7AKOVa for ; Thu, 3 May 2018 14:47:51 -0700 (PDT) Received: from mail-lf0-x229.google.com (mail-lf0-x229.google.com [IPv6:2a00:1450:4010:c07::229]) (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 1059B126DC2 for ; Thu, 3 May 2018 14:47:51 -0700 (PDT) Received: by mail-lf0-x229.google.com with SMTP id m18-v6so28146969lfb.0 for ; Thu, 03 May 2018 14:47:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=l8+FFcRQ6uJawLSIWYH2l1LbX1AUhsBAbTEe55JJBlE=; b=sUMS3rZIkhGlwSVtYh0hgTpXFbaYYe/zehSuMlmufNLJmSbaEmKZaF6Kj0Ny0vnZsa rw7ALyjzDoBiDVQOkIbVKyKVK9oi3kpWymv5QCcC0CsRitPeWYvcfuZbzv4/XZMSHqsh LtrhdZchOhfiItpsuR51qOVX1LXCJ8scrUrgiNohXW7uLgXwGmrYcamKgN6YK3P/yHDl eNsmp4qjf7iQYHB7MvFx39d8gjB0bAlCKE/oSpQnT6SJWaHlCnUYVVEa8mv2SkmXpiE/ Sgo9/8Wb5sM3rema5rBp2v0LV7cnV4bkDgktvYz49EtSsrTiHg2ZPOBNkjlOgrkTRaL7 Gkmg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=l8+FFcRQ6uJawLSIWYH2l1LbX1AUhsBAbTEe55JJBlE=; b=VSD9t1xV5/lmVrb5LkCFEhyz2To+AxvfQClfKjjTj06BLyXNo31FqjF1vLAuG6Keda st/T20bd4gsYDZRQCjdQmm3Bqzv+pJMOAeQmb30FtpUXq1Z5HjJNzTNcEFEV7q/eH9Ck V0Jcwfh1uI3fZRTl+DpqL3+ybstbZtWje0/3BZ8e9xiXxssmnCSxrjRAjKgQgseFeLLs 3+EydduQ+k/lyrfy5T8/P5YgVlX0iQZj2ocYj8L7v735r4IZCYaWqsCR7G4aNldS091V /LZJhrNtm2GPh5pGmiGkW7Tf1oM4edJxLbQ/ZpLI+0FDu4d9oNM6W6fRjH5ZcWc3KtbY tKUw== X-Gm-Message-State: ALQs6tDlyBR9ohPF0r+OSARFBZie73tFXc2OIKD95etk5tBkg3MLlNdI dwV8eobIA2mdlk7YL9oE1SvECSPDEozQbaTxL5s= X-Google-Smtp-Source: AB8JxZpvl+u8Vj8Mp5FP1O1lA+zDfv9Tii8IgHvgsl4oDKgEJHnJ9T1s2clhS2Nj3EnLvcfQ2FYfKn15aJbUmpRnY0I= X-Received: by 2002:a2e:96d2:: with SMTP id d18-v6mr17102815ljj.21.1525384069169; Thu, 03 May 2018 14:47:49 -0700 (PDT) MIME-Version: 1.0 Received: by 10.46.144.3 with HTTP; Thu, 3 May 2018 14:47:08 -0700 (PDT) In-Reply-To: References: From: Shivan Date: Thu, 3 May 2018 17:47:08 -0400 Message-ID: To: Spencer Dawkins at IETF Cc: hr-rt@irtf.org, architecture-discuss@ietf.org, IAB IAB Content-Type: multipart/alternative; boundary="00000000000096daea056b542786" Archived-At: Subject: Re: [arch-d] [HT-rt] HR-RT Review of draft-iab-marnew-report-01 X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.22 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: Thu, 03 May 2018 21:47:56 -0000 --00000000000096daea056b542786 Content-Type: text/plain; charset="UTF-8" Thanks Spencer for the clarification! On Thu, May 3, 2018 at 3:41 PM, Spencer Dawkins at IETF < spencerdawkins.ietf@gmail.com> wrote: > Hi, Shivan, > > On Wed, May 2, 2018 at 12:11 PM, Shivan wrote: > >> This is a review done within the framework of the Human Rights Review >> Team. It was done by Amelia Andersdotter and Shivan Kaul Sahib. The Human >> Rights Review Team aims to implement and improve the guidelines for >> human rights considerations provided in RFC8280, and seek to mitigate >> potentially adverse human rights impacts that IETF and IRTF documents >> might have. >> > > Thanks for the comments. On one point below ... > > >> We find the topics addressed during the workshop interesting and look >> forward to following future developments. >> >> --- >> >> Document: draft-iab-marnew-report-01 >> >> https://datatracker.ietf.org/doc/draft-iab-marnew-report/ >> >> Review: >> >> The Human Rights in Protocols Research Group welcomes the draft report >> from the MaRNEW workshop. In particular, we welcome the efforts to continue >> advancing an encrypted, secure and human rights enabling environment, as >> well as solid assessments of the potential impacts of considered remedies >> to mobile network operator difficulties on the right to privacy of an >> individual. >> >> In this regard, we wish to remind the drafters and the IAB of the >> inherent connection between privacy and freedom of expression. The right to >> privacy, or to one's own personhood, reinforces the freedom of expression >> and freedom of opinion. >> >> Semantic Suggestions >> =========================== >> >> The following sections addresses a few semantic problems in the draft >> report, that were they solved the draft report would be easier to parse >> from both a human rights perspective, and from a business, legal or >> technical perspective. >> >> 1. Abstract, para 2: >> >> Problem: Draft text contains value judgements on participants' >> presentations that could be avoided. >> >> Solution: Remove the word "honest" in relation to CDN presentations, >> since it may cause readers to assume that other presenters were less >> forthcoming. >> >> The new paragraph would read >> >> The group discussed the current Internet encryption trends and >> deployment issues identified within the IETF, and the privacy needs >> of users which should be adhered. Solutions designed around sharing >> data from the network to the endpoints and vice versa were then >> discussed as well as analysing whether the current issues experienced >> on the transport layer are also playing a role here. Content >> providers and CDNs gave their views of delivering >> content with mobile network operators. Finally, technical responses >> to regulation was discussed to help the regulated industries relay >> the issues of impossible to implement or bad-for-privacy technologies >> back to regulators. >> >> 2. Section 1, Introduction: >> >> Problem: It is unclear whether the "requirements" referred to imply >> regulatory requirements enforceable by government authorities, or technical >> requirements. Because of the nature of issues discussed during the >> workshop, understanding what sorts of "requirements" are being referred to >> is imperative. >> >> Solution: Specify the nature of the requirements being referred to, or >> remove the reference to requirements. >> >> The new Introduction would read >> >> Mobile networks have a set of properties which >> places a large emphasis on sophisticated bandwidth optimization. >> Encryption is increasing on the Internet which is positive for >> consumer and business privacy and security. Many existing mobile >> bandwidth optimization solutions primarily operate on non-encrypted >> communications; this can lead to performance issues being amplified >> on mobile networks. Encryption on networks will continue to >> increase; and with this understanding the workshop aimed to >> understand how we can solve the issues of bandwidth optimization and >> performance on radio networks in this encrypted world. >> >> 3. Section 1.1: >> >> Problem: The first paragraph mixes business models with technical >> necessities. The last paragraph in the section Understanding "Bandwidth >> Optimization" refers to regulatory requirements (within the meaning of >> government enforced requirements or legal requirements, cf above) on mobile >> network operators to perform traffic filtering and monitoring. >> >> Solution: It may facilitate understanding of human rights impacts to >> separate technical considerations from business considerations and legal >> considerations. Paragraph 3 ("Many of these functions can continue...") >> could be put as the last paragraph, while Paragraph 1 could be split into a >> technical section and a business model section, followed by a legal section. >> >> >> For the purposes of this workshop, bandwidth optimization encompasses >> a variety of technical topics related to traffic engineering, >> prioritisation, optimisation and efficiency enhancements. It also >> encompasses >> user-related topics such as specific subscription or billing models, >> and may touch upon regulatory aspects or other issues relating to >> regulatory, within the meaning of government initiated, concerns. >> >> The first category of bandwidth optimization includes: >> >> o Caching >> >> o Prioritisation of interactive traffic over background traffic >> >> o Per-user bandwidth limit >> >> The second category of bandwidth optimization may depend on either of >> the first category optimization strategies, but may, in particular, also >> encompass: >> >> o Business-related topics such as content delivery arrangements with >> specific content providers. >> >> Finally, while not strictly speaking traffic management, some >> networks employ policy-based filtering (e.g., requested parental >> controls) and many networks support some form of legal interception >> functionality per applicable laws. >> >> Many of these functions can continue as they're performed today, even >> with more encryption. Others are using methods which inspect parts >> of the communication that are encrypted, and these will have to be >> done differently in an encrypted Internet. >> >> >> 4. Section 4: >> >> Problem: QUIC is an active area of work for the IETF in the transport >> layer - this section barely mentions it, and even then does so vaguely. >> What problems are solved by QUIC that are general problems rather than TCP >> problems? What was the nature of the disagreement around this? >> >> Solution: More detail about how QUIC fits into transport-layer work would >> make this section more relevant. In addition, there has been discussion >> involving network operators around technical details that have potential >> privacy impacts within the QUIC working group (SPIN bit); this section >> would benefit greatly from an examination of that. >> > > I have comments from two other reviewers asking that this document > actually state the dates of the workshop, and I'll add that. > > If the version of the draft you reviewed had included those dates, it > would have been clearer that the workshop happened in September 2015, which > was more than a year before QUIC was chartered (BOF in July 2016, chartered > in October 2016). > > I'm helping the IAB finish this report, so taking direction from them, but > my understanding is that IAB workshop reports should reflect the situation > at the time of the workshop, so I shouldn't say much about QUIC in the > workshop report. > > FWIW, I agree with you, but I'm keeping that opinion out of the report ... > and now you know why. > > Spencer > > Human Rights Considerations >> =========================== >> >> Upon consideration of the draft report, no implications for >> internationalization ([RFC8280], sec. 6.2.5), heterogeneity support >> ([RFC8280], sec. 6.2.8), accessibility ([RFC8280], sec. 6.2.11) or >> localization ([RFC8280], sec. 6.2.12) have been found. We will further >> suppose that issues relating to Anonymity ([RFC8280], sec. 6.2.9), >> Pseudonymity ([RFC8280], sec. 6.2.10) and Confidentiality ([RFC8280], sec. >> 6.2.16) have been sufficiently addressed in the draft as is. >> >> In the below text, Security ([RFC8280], sec. 6.2.4), Integrity >> ([RFC8280], sec. 6.2.16) and Authenticity ([RFC8280], sec. 6.2.17) are >> further considered to have been addressed, or as in progress of being >> addressed by the specific endeavours pointed out in the report. As such, >> this assessment hopes to serve as a complement to remaining Human Rights >> Considerations Guidelines which were not addressed by the MaRNEW draft. >> >> ## Privacy ([RFC8280], sec. 6.2.2) >> >> We laud the general emphasis on considering user privacy concerns >> paramount [Section 2.1.1, 2.3 etc]. >> >> In Section 3.1.1, para 1, it would be useful to emphasize that >> middleboxes that are "authenticated and invoked explicitly" might not be >> very effective at conserving user privacy if they lead to auto-click >> through. In practice, "opted-in" middleboxes might not be much better than >> transparent middleboxes. Additionally, this poses the danger of making >> matters worse if users assume that because they haven't been asked for >> middlebox permission, they are not going through a middlebox. For users >> accessing the Internet on a browser client: if the connection is MITMed by >> a middlebox, the browser would somehow need to convey this effectively and >> actionably to the user. Whatever effort is expended on this should involve >> browser vendors. >> >> ## Connectivity ([RFC8280], sec. 6.2..1) >> >> It is a priori obvious that a discussion with mobile network operators >> would touch upon connectivity. As a general comment, the HRPC RG is not >> concerned that encrypted internet traffic could create topological problems >> in network deployment with respect to density of base stations. It is more >> sensible to imagine that the density of base stations is kept low by >> deployers to save money on infrastructure roll-out. >> >> In the MarNEW draft report, middleboxes are brought up frequently as an >> example of infrastructure rendered less useful by the ubiquitous adoption >> of encryption. Middleboxes may enhance access to content for individuals, >> and may also interfere with their ability to enjoy content free of >> surveillance, censorship or content manipulation. The focus of the workshop >> of exploring ways in which encrypted materials can benefit from the same >> speed of deliverance as un-encrypted materials is therefore welcome. >> >> ## Content Agnosticism >> >> Traffic prioritisation, whether based on technical or commercial grounds, >> risks interfering with an individual's right to freedom of expression or >> opinion, by restricting access or enjoy content of their own choosing. As >> such, prioritisation should be made explicit and obvious, and subject to >> consent from the individual, whether the motivations for deployment are >> commercial or technical. >> >> It is clear that internet filtering and blocking of content of specific >> types, whether motivated by network management or regulatory concerns, does >> not fulfill a content agnosticism criterion. It is the observation of HRPC >> that [RFC7725] (An HTTP Status Code to Report Legal Obstacles) may assist >> communication of specific filtering and blocking operations in action. >> >> It the the impetus of the Human Rights Guidelines in RFC8280 that content >> agnosticism be respected by protocols developed in the IETF, and in general >> an accepted view in the global human rights community that content >> agnosticism is desirable at all levels of technical infrastructure. As >> such, the HRPC RG is concerned about ideas that traffic be classified >> through additional headers or metadata, identifying traffic via 5-tuples, >> trust models and frameworks, or heuristics. >> >> >> >> >> _______________________________________________ >> Architecture-discuss mailing list >> Architecture-discuss@ietf.org >> https://www.ietf.org/mailman/listinfo/architecture-discuss >> >> > --00000000000096daea056b542786 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks Spencer for the clarification!<= /div>

On Thu= , May 3, 2018 at 3:41 PM, Spencer Dawkins at IETF <spencerdawk= ins.ietf@gmail.com> wrote:
=
Hi, Shivan,=C2=A0

On Wed, May 2, 2018 at 12:11 PM, Shivan <= span dir=3D"ltr"><shivankaul.1993@gmail.com> wrote:
This is a review done within the framework of= the Human Rights Review
Team. It was done by Amelia Andersdotter and Shivan= Kaul Sahib. The Human
Rights Review Team aims to implement and improve the guideline= s for
huma= n rights considerations provided in RFC8280, and seek to mitigate
potentially adverse= human rights impacts that IETF and IRTF documents
might have.

Thanks for the comments. On= one point below ...
=C2=A0
We find the topics addressed during the= workshop interesting and look
forward to following future developments.

<= div>---


Review:

The Human Rights in Protocols Research Group welcomes the = draft report from the MaRNEW workshop. In particular, we welcome the effort= s to continue advancing an encrypted, secure and human rights enabling envi= ronment, as well as solid assessments of the potential impacts of considere= d remedies to mobile network operator difficulties on the right to privacy = of an individual.

In this regard, we wish to remind the drafters and the IAB of the inhere= nt connection between privacy and freedom of expression. The right to priva= cy, or to one's own personhood, reinforces the freedom of expression an= d freedom of opinion.

Semantic Suggestions
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D

The following sections addresses a few semantic problems in = the draft report, that were they solved the draft report would be easier to= parse from both a human rights perspective, and from a business, legal or = technical perspective.

1. Abstract, para 2:

Problem: Draft text contains=C2=A0 value judgements on parti= cipants' presentations that could be avoided.

Solution: Remove the word "honest= " in relation to CDN presentations, since it may cause readers to assu= me that other presenters were less forthcoming.

The new paragraph would read
<= div>
<= font color=3D"#333333" face=3D"georgia, serif">=C2=A0 =C2=A0The group discu= ssed the current Internet encryption trends and
=C2=A0 =C2=A0deployment issues identi= fied within the IETF, and the privacy needs
=C2=A0 =C2=A0of users which should be adh= ered.=C2=A0 Solutions designed around sharing
=C2=A0 =C2=A0data from the network to = the endpoints and vice versa were then
=C2=A0 =C2=A0discussed as well as analysing wh= ether the current issues experienced
=C2=A0 =C2=A0on the transport layer are also pla= ying a role here.=C2=A0 Content
=C2=A0 =C2=A0providers and CDNs gave their views of d= elivering
= =C2=A0 =C2=A0content with mobile network operators.=C2=A0 Finally, technica= l responses
=C2= =A0 =C2=A0the issues of impossible to implement or bad-for-privacy technolo= gies
=C2= =A0 =C2=A0back to regulators.

2. Section 1, Introduction:

Problem: It is unclear whether the "requir= ements" referred to imply regulatory requirements enforceable by gover= nment authorities, or technical requirements. Because of the nature of issu= es discussed during the workshop, understanding what sorts of "require= ments" are being referred to is imperative.

Solution: Specify the nature of the requi= rements being referred to, or remove the reference to requirements.<= /div>

=
The new Introduction w= ould read
=
=C2= =A0 =C2=A0Mobile networks have a set of properties which
<= font color=3D"#333333" face=3D"georgia, serif">=C2=A0 =C2=A0places a large = emphasis on sophisticated bandwidth optimization.
=C2=A0 =C2=A0Encryption is increasi= ng on the Internet which is positive for
=C2=A0 =C2=A0consumer and business privacy a= nd security.=C2=A0 Many existing mobile
=C2=A0 =C2=A0bandwidth optimization solutions= primarily operate on non-encrypted
=C2=A0 =C2=A0communications; this can lead to per= formance issues being amplified
=C2=A0 =C2=A0on mobile networks.=C2=A0 Encryption on = networks will continue to
=C2=A0 =C2=A0increase; and with this understanding the work= shop aimed to
=C2=A0 =C2=A0understand how we can solve the issues of bandwidth optimi= zation and
=C2=A0 =C2=A0performance on radio networks in this encrypted world.=

3. Section 1.1:

Problem: The first p= aragraph mixes business models with technical necessities. The last paragra= ph in the section Understanding "Bandwidth Optimization" refers t= o regulatory requirements (within the meaning of government enforced requir= ements or legal requirements, cf above) on mobile network operators to perf= orm traffic filtering and monitoring.

Solution: It may facilitate understanding of human r= ights impacts to separate technical considerations from business considerat= ions and legal considerations. Paragraph 3 ("Many of these functions c= an continue...") could be put as the last paragraph, while Paragraph 1= could be split into a technical section and a business model section, foll= owed by a legal section.


=C2=A0 =C2=A0For the purposes of this workshop, bandwidth optimization= encompasses
=C2=A0 =C2=A0a variety of technical topics related to traffic engineerin= g,
=C2=A0 = =C2=A0prioritisation, optimisation and efficiency enhancements. It also enc= ompasses
= =C2=A0 =C2=A0user-related topics such as specific subscription or billing m= odels, and may touch upon regulatory aspects or other issues relating to re= gulatory, within the meaning of government initiated, concerns.

=C2=A0 =C2=A0The first cat= egory of bandwidth optimization includes:

=C2=A0 =C2=A0o=C2=A0 Caching

=C2=A0 =C2=A0o=C2=A0 Prioritisatio= n of interactive traffic over background traffic

=C2=A0 =C2=A0o=C2=A0 Per-user bandwidth l= imit
=C2= =A0 =C2=A0
=C2=A0 =C2=A0The second category of bandwidth optimization may depend on e= ither of the first category optimization strategies, but may, in particular= , also encompass:

=C2=A0 =C2=A0o=C2=A0 Business-related topics such as content delivery ar= rangements with
=C2=A0 =C2=A0 =C2=A0 specific content providers.
=C2=A0 =C2=A0 =C2=A0=C2=A0
=C2=A0 =C2=A0= Finally, while not strictly speaking traffic management, some
<= div>=C2=A0 =C2=A0networks e= mploy policy-based filtering (e.g., requested parental
=C2=A0 =C2=A0controls) and man= y networks support some form of legal interception
=C2=A0 =C2=A0functionality per app= licable laws.

= =C2=A0 =C2=A0Many of these functions can continue as they're performed = today, even
=C2=A0 =C2=A0of the communication that are encrypted, and these will hav= e to be
= =C2=A0 =C2=A0done differently in an encrypted Internet.


4. Section 4:

Problem: QUIC is an active area of wor= k for the IETF in the transport layer - this section barely mentions it, an= d even then does so vaguely. What problems are solved by QUIC that are gene= ral problems rather than TCP problems? What was the nature of the disagreem= ent around this?

Human Rights Cons= iderations
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D

Up= on consideration of the draft report, no implications for internationalizat= ion ([RFC8280], sec. 6.2.5), heterogeneity support ([RFC8280], sec. 6.2.8),= accessibility ([RFC8280], sec. 6.2.11) or localization ([RFC8280], sec. 6.= 2.12) have been found. We will further suppose that issues relating to Anon= ymity ([RFC8280], sec. 6.2.9), Pseudonymity ([RFC8280], sec. 6.2.10) and Co= nfidentiality ([RFC8280], sec. 6.2.16) have been sufficiently addressed in = the draft as is.


## Privacy ([RFC8280], sec. 6.2.2)=

We laud the general e= mphasis on considering user privacy concerns paramount [Section 2.1.1, 2.3 = etc].=C2=A0
In = Section 3.1.1, para 1, it would be useful to emphasize that middleboxes tha= t are "authenticated and invoked explicitly" might not be very ef= fective at conserving user privacy if they lead to auto-click through. In p= ractice, "opted-in" middleboxes might not be much better than tra= nsparent middleboxes. Additionally, this poses the danger of making matters= worse if users assume that because they haven't been asked for middleb= ox permission, they are not going through a middlebox. For users accessing = the Internet on a browser client: if the connection is MITMed by a middlebo= x, the browser would somehow need to convey this effectively and actionably= to the user. Whatever effort is expended on this should involve browser ve= ndors.
#= # Connectivity ([RFC8280], sec. 6.2..1)
<= font color=3D"#333333" face=3D"georgia, serif">
It is a priori obvious that a dis= cussion with mobile network operators would touch upon connectivity. As a g= eneral comment, the HRPC RG is not concerned that encrypted internet traffi= c could create topological problems in network deployment with respect to d= ensity of base stations. It is more sensible to imagine that the density of= base stations is kept low by deployers to save money on infrastructure rol= l-out.
In the M= arNEW draft report, middleboxes are brought up frequently as an example of = infrastructure rendered less useful by the ubiquitous adoption of encryptio= n. Middleboxes may enhance access to content for individuals, and may also = interfere with their ability to enjoy content free of surveillance, censors= hip or content manipulation. The focus of the workshop of exploring ways in= which encrypted materials can benefit from the same speed of deliverance a= s un-encrypted materials is therefore welcome.

## Content Agnosticism

Traffic prioritisation, whether bas= ed on technical or commercial grounds, risks interfering with an individual= 's right to freedom of expression or opinion, by restricting access or = enjoy content of their own choosing. As such, prioritisation should be made= explicit and obvious, and subject to consent from the individual, whether = the motivations for deployment are commercial or technical.

It is clear that internet filt= ering and blocking of content of specific types, whether motivated by netwo= rk management or regulatory concerns, does not fulfill a content agnosticis= m criterion. It is the observation of HRPC that [RFC7725] (An HTTP Status C= ode to Report Legal Obstacles) may assist communication of specific filteri= ng and blocking operations in action.

It the the impetus of the Human Rights Guidelines in= RFC8280 that content agnosticism be respected by protocols developed in th= e IETF, and in general an accepted view in the global human rights communit= y that content agnosticism is desirable at all levels of technical infrastr= ucture. As such, the HRPC RG is concerned about ideas that traffic be class= ified through additional headers or metadata, identifying traffic via 5-tup= les, trust models and frameworks, or heuristics.




_______________________________________________
Architecture-discuss mailing list
Architec= ture-discuss@ietf.org
https://www.ietf.org/mailman/listinf= o/architecture-discuss



--00000000000096daea056b542786-- From nobody Wed May 9 19:05:35 2018 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 C957112E89F for ; Wed, 9 May 2018 19:05:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 OWLmXhwP70-n for ; Wed, 9 May 2018 19:05:19 -0700 (PDT) Received: from mail-pg0-x235.google.com (mail-pg0-x235.google.com [IPv6:2607:f8b0:400e:c05::235]) (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 2796E12E88B for ; Wed, 9 May 2018 19:05:19 -0700 (PDT) Received: by mail-pg0-x235.google.com with SMTP id k11-v6so248282pgo.10 for ; Wed, 09 May 2018 19:05:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:references:from:organization:to:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=0cNCONHUV1esiNdoO7IK16gfY7CALQubPAkz1yQDhy0=; b=J/aJZS3IWi8/1SE0R9z03uBRpUuMh3vua11Z/ZkhJrwaY9M8vi8mDSfoPfMV/n7AzH nmvVeh1V3gjbFnMTAMyFgomNIfUI4Z6yIB+ERweDwEJMf5eC1ODEVn9BJIbSC7yHJasy QYuo5b0EC6uB6UeIiZ70WiXzuMb8mRwdxVpIe0Blru8bqfuE6/hFS63EazoPiuGA28Gk RAgH7OQ49Lln135/okY3I/NJkPEBe0hgCT1ZZI6WBvxDRYmYxbcqnP7AmUSSKNY81gll 6kAWBdIQ87JEjS4Ocm8G0xRQmXibEfTrFnReds56yuJpHGwrBmYHiSRQ0iKkLp72e+iq 3mRQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:references:from:organization:to :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=0cNCONHUV1esiNdoO7IK16gfY7CALQubPAkz1yQDhy0=; b=dmu6eVaPTKWojbXLzlKT7wynl0+vRncCms2yqgsACdVtnTewVKkhla0zdnxu7SsVtU ddvOm8TNrAmzdfBMQQu6aMqtGkY7ZnlrJjS0BJ/7YmCkv3Ws+tZb4hmJfprZmTRTk3sg SZztiFz+Ki571XI8dZAVjbNYUXklsPtHngEImUsPrsxkRnHgH6kC3dtoiiSkaOf7gpTq 3nIbBlElF9IQ3lA/1nvXKEJyUwKppEA0hhABSRuKHNAKFIC4NMR/8XDkxQatpQpw576c kXWbz4ds0jAkdA7D5tkIP8RJIEH2BdwUZ/YNnt7oOK8ivjrtS4yqHpuTiuhNwy4ySMru 8x/A== X-Gm-Message-State: ALQs6tB409QfS5LutfYNsCU1m9tIdW24E7w9jOIPqFxnzuntMLYoefwU 0oD/rBghWsGfXYHz7aLnPt9uoA== X-Google-Smtp-Source: AB8JxZrOa34+ygn6dAiWkH91pJeqolO0I3Ko7b5NM7wr2PtOokJNFom2cfrlgex+CANaqAzr9jjIkA== X-Received: by 2002:a63:2647:: with SMTP id m68-v6mr37679244pgm.56.1525917918338; Wed, 09 May 2018 19:05:18 -0700 (PDT) Received: from [130.216.38.35] (sc-cs-567-laptop.uoa.auckland.ac.nz. [130.216.38.35]) by smtp.gmail.com with ESMTPSA id s7sm48676828pfm.114.2018.05.09.19.05.16 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 09 May 2018 19:05:17 -0700 (PDT) References: <152538075241.4552.6760702690778529507@ietfa.amsl.com> From: Brian E Carpenter Organization: University of Auckland To: architecture-discuss@ietf.org Message-ID: Date: Thu, 10 May 2018 14:05:20 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: <152538075241.4552.6760702690778529507@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [arch-d] I-D Action: draft-iab-protocol-maintenance-00.txt X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.22 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: Thu, 10 May 2018 02:05:23 -0000 Hi, I have very mixed feelings about this draft. Firstly, let me clarify that although I was the editor of RFC 1958, the wording about the robustness principle was either drafted by or wordsmithed by Jon Postel himself. That being said, it isn't sacred. But the present draft uses language that describes it as a failure, which is far from true. Before this becomes a community document, IMHO the tone *really* needs to change, starting with the title. How about "Some Unintended Consequences of the Robustness Principle" or even "When to Apply the Robustness Principle"? I regret that we didn't discuss this topic in RFC 6709 ("Design Considerations for Protocol Extensions"). Interestingly, a poster child for extensibility problems in that RFC is TLS, the first problem case mentioned in the present draft. Just read this extract: > It has turned out that many SSLv3 and TLS implementations that do not > support TLS extensions did not ignore the unknown extensions, as > required by the protocol specifications, but instead failed to > establish connections. Since several of the implementations behaving > in this manner are used by high-profile Internet sites, such as > online banking sites, this has caused a significant delay in the > deployment of clients supporting TLS extensions, and several of the > clients that have enabled support are using heuristics that allow > them to disable the functionality when they detect a problem. In this case, heuristics are needed to get round implementations that don't respect the robustness principle. In general I think the present draft doesn't pay enough attention to extensions, which are after all the second main reason for maintaining protocols, along with bug fixes. The draft is seriously unbalanced, it seems to me, by not containing an explicit description of the benefits of the robustness principle and of cases where it is necessary. Frankly I am surprised to see it as an IAB draft in its current state. > 5. Active Protocol Maintenance > > The robustness principle is best suited to safeguarding against flaws > in a specification that is intended to remain unchanged for an > extended period of time. I don't think that's true. Firstly, very few people publish protocol designs that they intend to be updated after a short period of time. I'd argue that at the time of publication, all designs are intended to remain unchanged indefinitely. Secondly, I always understood that the robustness principle was primarily a safeguard against flaws in *implementations*. That's why we normally specify MBZ bits as MUST be zero on transmission and MUST be ignored on reception, etc. If we *expect* a protocol to be extended by adding options or message types, the robustness principle leads to very different text, like: > If an unrecognized MESSAGE_TYPE is received in a unicast message, an > Invalid message (Section 2.8.12) MAY be returned. Otherwise the > message MAY be logged and MUST be discarded. If an unrecognized > MESSAGE_TYPE is received in a multicast message, it MAY be logged and > MUST be silently discarded. In this case the Postel principle allows nodes that support different but overlapping sets of message types to communicate robustly. That's not a problem; it's a solution. (As TLS shows, this approach may not be acceptable for a security protocol where downgrade attacks are a problem. But that's a subset of all protocols.) I think the draft in its present unbalanced form is misleading. A balanced discussion of when the Postel principle is useful, and when it's harmful, would be more what I'd expect from the IAB. Brian From nobody Thu May 10 07:42:39 2018 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 3A6D312EAF9 for ; Thu, 10 May 2018 07:42:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=rad365.onmicrosoft.com 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 LICaHCFocabD for ; Thu, 10 May 2018 07:42:35 -0700 (PDT) Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-ve1eur01on0072.outbound.protection.outlook.com [104.47.1.72]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6AA3112EAF7 for ; Thu, 10 May 2018 07:42:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rad365.onmicrosoft.com; s=selector1-rad-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=FPAZlBjBR+ev+AjpW4bSPV14Uy9Fer8teIxz6EE+8tg=; b=qjQMPOWRl0IND1HJT8Yf48Wbiu2j1tE6tupVGQ6Yp1x18Gxp1jEvYwMP4ANOscKPuZ/dF+Sn2QsXF/kx5WPvHYTS68WeHDAxlcax4p2waGxh3B+p0UhsvFu2HODHMI0uxnEr2RpmXmV2Pip6vQHFbHjW/x6OwqXC0IisbFSomgY= Received: from VI1PR0301MB2576.eurprd03.prod.outlook.com (10.168.135.136) by VI1PR0301MB2031.eurprd03.prod.outlook.com (10.167.208.141) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.735.19; Thu, 10 May 2018 14:42:30 +0000 Received: from VI1PR0301MB2576.eurprd03.prod.outlook.com ([fe80::40d2:f2db:59f5:2dd7]) by VI1PR0301MB2576.eurprd03.prod.outlook.com ([fe80::40d2:f2db:59f5:2dd7%15]) with mapi id 15.20.0755.012; Thu, 10 May 2018 14:42:31 +0000 From: Yaakov Stein To: "architecture-discuss@ietf.org" Thread-Topic: [arch-d] I-D Action: draft-iab-protocol-maintenance-00.txt Thread-Index: AQHT6ANj1anDETXUN0SjHPmhPCcnDKQo/XUA Date: Thu, 10 May 2018 14:42:30 +0000 Message-ID: References: <152538075241.4552.6760702690778529507@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=yaakov_s@rad.com; x-originating-ip: [37.142.0.79] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; VI1PR0301MB2031; 7:ZBzgz0xarCCuryCBGVS2UglmLrOLRbDg3H4ALjNZOJH5o00B7svoAfWStNPd4zUt/V6hf1KWL3VMR1ma4aytzX/KY8dWyM7DRDVaXpYJ3m4NUUv5diLhAM/IUzfUPDCJMg1ZWwh623nNZlDAS+oTLyuNpE1y2RoQLOus+cYWPOZ0UK2FoYVheFJU+cclLfE3VdI2m7zIqLv2hzrqRtfII9VxMvLo3wIzgsnlSXah7swZm8rzPcUYty0rWk6EErgB x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(48565401081)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7153060)(7193020); SRVR:VI1PR0301MB2031; x-ms-traffictypediagnostic: VI1PR0301MB2031: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(131327999870524); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(10201501046)(93006095)(93001095)(3002001)(3231254)(944501410)(52105095)(6055026)(149027)(150027)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(20161123564045)(20161123558120)(20161123562045)(6072148)(201708071742011); SRVR:VI1PR0301MB2031; BCL:0; PCL:0; RULEID:; SRVR:VI1PR0301MB2031; x-forefront-prvs: 066898046A x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(39860400002)(366004)(346002)(396003)(39380400002)(199004)(189003)(59450400001)(446003)(74316002)(476003)(8676002)(3846002)(2900100001)(105586002)(81166006)(2906002)(106356001)(6116002)(486006)(81156014)(11346002)(7736002)(99286004)(14454004)(25786009)(97736004)(6916009)(229853002)(5660300001)(305945005)(5250100002)(76176011)(9686003)(478600001)(66066001)(3280700002)(5640700003)(6246003)(86362001)(2351001)(6436002)(68736007)(3660700001)(7696005)(102836004)(2501003)(8936002)(186003)(561944003)(33656002)(26005)(53936002)(316002)(6506007)(55016002); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR0301MB2031; H:VI1PR0301MB2576.eurprd03.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: rad.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: 4cUSwEe98f+UvqgryxjT/pjdIA8h1Ky19tKo9KHbRFbg3ppDGWSTGTjQdxb+TWUJRULLKeHus3obDBu/+MyGe/MD+fTgIlsHwaaM9w6rbrRTfD6nhcX24xnivucc6Ux5ndbQBa9Dj+blwST20bl48RLgNLDdLTJikGuNWWa7heGmrQS0BnDL1CJ1DaI4t4vR spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Office365-Filtering-Correlation-Id: 1ae1fd38-0ffc-4424-5b81-08d5b6844281 X-OriginatorOrg: rad.com X-MS-Exchange-CrossTenant-Network-Message-Id: 1ae1fd38-0ffc-4424-5b81-08d5b6844281 X-MS-Exchange-CrossTenant-originalarrivaltime: 10 May 2018 14:42:30.9099 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f9047108-cc2c-4e48-97a3-43fad1b3bf9d X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0301MB2031 Archived-At: Subject: Re: [arch-d] I-D Action: draft-iab-protocol-maintenance-00.txt X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.22 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: Thu, 10 May 2018 14:42:38 -0000 I have a meta-comment on this draft, or alternatively a proposal for a diff= erent draft. I'm sure a lot of you have heard Scott Shenker's talk "The future of networ= k and the past of protocols", in which he makes the case for SDN. His basic tenet is that computer science has perfected methods for implemen= ting software very quickly while protocols take a tremendously long time to design, perfect, and imple= ment. So, he concludes, throw out protocols and run everything on a centralized s= erver. Putting aside the obvious fact that he overlooks that protocols between mul= tiple network elements need to be standardized so that every implementation can interwork with every other one (while an a= lgorithm running on a single CPU doesn't require standardization), he makes a good point. A lot of the speed of programming comes from use of "abstractions". If every time one coded an app for a smartphone one needed to return to opc= odes and bits,=20 then it would indeed be a lengthy error-prone process. But instead programmers stand on the shoulders of those who came before the= m. It works something like this. Say someone solves some problem. The solution is initially made into a routine or function that can be open-= sourced and reused. No-one need write that routine again. If the solution is really successful it can be made into a library with var= ious initializations and options that can be loaded when needed.=20 You needn't know how the library works, and if someone comes up with a bett= er implementation it can refactored without the programmer knowing about it= . If it becomes even more successful it can be turned into an object that can= be inherited and extended and even changed without looking at the source c= ode. If it is wildly successful, the functionality becomes part of the next gene= ration of programming languages, and everyone has access to it without givi= ng it any thought. The SDN theorists claim that networking has no abstractions (or at least th= at they don't know of any), and suggest a very strong abstraction - the "whitebox" switch (which can be= any network element - an Ethernet bridge, an IP router, a firewall, etc). That jump in logic aside, they have a point. Every time we design a protoco= l we go back to the basics. We usually make a bit diagram (in ASCII art no less). We don't formally inh= erit functionality expect by riding over an existing protocol (e.g., running a protocol over TCP can give it reliability). As a concrete example, we often obtain protocol extensibility by utilizing = TLVs. Now, the designers of LDP came up with a nice idea to handle the case of an= implementation not knowing a particular type - the U bit. If the U bit is set it signifies that this unknown type can be gracefully i= gnored. Otherwise an error message must be returned. Were we to work like computer scientists, once this idea was implemented it= should be automatically inherited by every future protocol using TLVs. Automatically. Not - if you heard about it put a U bit into your bit diagra= m. A while back the IEEE 802 people tried doing something like this when they = design the Generic Attribute Registration Protocol. GVRP and GMRP inherited it, but nothing else. What can we do in the IETF to turn our ideas into abstractions that are inh= erited? Y(J)S From nobody Fri May 11 00:48:55 2018 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 D8DA012711A for ; Fri, 11 May 2018 00:48:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 eGPmtG9I54ei for ; Fri, 11 May 2018 00:48:51 -0700 (PDT) Received: from mail-ot0-x230.google.com (mail-ot0-x230.google.com [IPv6:2607:f8b0:4003:c0f::230]) (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 C449C126BF6 for ; Fri, 11 May 2018 00:48:50 -0700 (PDT) Received: by mail-ot0-x230.google.com with SMTP id m11-v6so5247370otf.3 for ; Fri, 11 May 2018 00:48:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=NrP03MtQq5e7qPy9h+D5H7rtgqMlHFMP5YZg+eQa4DQ=; b=ip+7lCaOvYtDssOfRc0Ud5ZAJWW/lUUYCnMbocKzu2DI18libSUBIkND1nOAFl+m7G yy0Qpx5l3zOPgrBmWHVulQ0W6w7j5E/uN6B93kspGUeBargFN7fH8WDCdUYHaXCqC/Cz M0f+XCozaMSi+t/EfWxJyAY9IIj7uts1uF3K034WzRxRQzfQoqyocEnC2Nx+i4Y1+VOy SiSttqMY8Gx7L7cjaXFh99QHOWsSFyummHFtnKlaMhP+6ksmjswSyJ0L9PQZQX+8JReC v0lsWyKljXOujTsUcxnGV3GOqYzG5fnvefkVCwqoI+XnhuwaaCU0nrDzCLvdKzdRerK0 uDnA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=NrP03MtQq5e7qPy9h+D5H7rtgqMlHFMP5YZg+eQa4DQ=; b=uRoPw7qNbYeXAFvs+b7ZA0aBECLrkYuF1Q0ONujhOEK276z/cqVK9gwf164YUXQ7mr /JCvrYe2i7ssxhm0yD9pAZ0Az6VJqjL7NQqyZ4HPJVsQrmx55hIN8/12xR9YmvFb3lCZ NeE6oCWemV4XO6Fh9Ksh/h5RQNi43nmH10kk+H50IsmGyYPBinh6KCIXxdFz+YeR2RX5 4/IrFYa75LSBCLELlfbiLc/Ki4DWiaKvyvf+0BhhPExtes8bEKzqBHUpSrerbhnYpgxw TbO7+pAKESyTqbjrB1NGKascdKqb62G7Q4VxXncJmRL72219WboBUxWA54GjBvdFq2AR eJZQ== X-Gm-Message-State: ALKqPwedz26ymRCF35zr3njWQnBaD5oZvVxh7UdzjSXtWGSvFq3IPmxm nAmhgMlgZXR54T03sh8q8wPGzNwBpi5qHLnY17c= X-Google-Smtp-Source: AB8JxZqOhT1ErJYEQyHsWk0C5DCH2C3ppJcEqaRDm8t/GxZfA5ArzGmcAiaZ6tb3TXAo1Z4FlGSg5V8D/79nja78vsc= X-Received: by 2002:a9d:524d:: with SMTP id q13-v6mr3259984otg.241.1526024929881; Fri, 11 May 2018 00:48:49 -0700 (PDT) MIME-Version: 1.0 References: <152538075241.4552.6760702690778529507@ietfa.amsl.com> In-Reply-To: From: Martin Thomson Date: Fri, 11 May 2018 17:48:38 +1000 Message-ID: To: Brian E Carpenter Cc: architecture-discuss@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [arch-d] I-D Action: draft-iab-protocol-maintenance-00.txt X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.22 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: Fri, 11 May 2018 07:48:54 -0000 Hi Brian, Thanks for your note. This is a very valuable contribution. I suspect that we might have a fundamental disagreement, but it's definitely worth exploring the issues you raise a little more. Firstly, this draft was intended to be a comprehensive rebuttal of Postel's principle. The tone is intentional, largely as a means of reinforcing the message that the robustness principle does more harm than good. It's a big idea, and pervasive, and I believe that a strong response is justified. There are almost certainly ways in which that could be softened, but I'm not in favour of changing the underlying message in the ways you suggest. It's possible that our disagreement stems from a disconnect regarding the scope of the application of the robustness principle. I think that the "When in doubt" part clearly limits its applicability to situations where there is insufficient or unclear specification. It seems like you might have a broader notion of the idea. It might pay to push on that notion a little. I've done a little of that below. I've staged a few changes to the document based on your feedback. There are definitely a few places where the emphasis was wrong (and an outright mistake on my part). Others separately made points about extensibility, which suggests that it wasn't paid sufficient attention. Preview here: https://martinthomson.github.io/postel-was-wrong/implementation-robustness/draft-iab-protocol-maintenance.html Of course I don't consider this to be the end of the discussion. More inline. On Thu, May 10, 2018 at 12:05 PM Brian E Carpenter < brian.e.carpenter@gmail.com> wrote: > How about > "Some Unintended Consequences of the Robustness Principle" > or even > "When to Apply the Robustness Principle"? This would be a mistake, I think. The answer to the question is in my opinion: "as little as possible, ideally never". > Interestingly, a poster child for extensibility problems > in that RFC is TLS, the first problem case mentioned in the > present draft. I'm familiar with the many of the ways in which TLS has failed over the years. As you say, it has long history of being a bad example. Separately, my hope is that it can now be the source of a few good examples in addition to the many bad ones. I personally attribute the bad examples to its age, plus the extended period of relative neglect it saw. In many ways, the protocol hasn't had any significant maintenance until recently, when we started work on TLS 1.3. TLS 1.2 is fundamentally the same protocol as SSL 3. > > It has turned out that many SSLv3 and TLS implementations that do not > > support TLS extensions did not ignore the unknown extensions, as > > required by the protocol specifications, but instead failed to > > establish connections. Since several of the implementations behaving > > in this manner are used by high-profile Internet sites, such as > > online banking sites, this has caused a significant delay in the > > deployment of clients supporting TLS extensions, and several of the > > clients that have enabled support are using heuristics that allow > > them to disable the functionality when they detect a problem. > In this case, heuristics are needed to get round implementations > that don't respect the robustness principle. That's a conclusion I might have once agreed to, but that was before I started working on TLS. The extension mechanism in TLS relied on a hole in the original specification of SSL 3. So yes, the robustness principle was applied and it was in fact critical in enabling extensions. TLS extensions rely on SSL 3 implementations consistently applying the robustness principle when dealing with the inner and outer length of the ClientHello message. Then, when it was clear that some implementations were stricter in their parsing, the principle was again used in applying heuristics to work around the problem. In this case, the short term impact was interoperation. Of course, those were undocumented workarounds which made it hard to build an interoperable client, but that's a minor drawback in the grand scheme. The long term effect was devastating. The most common technique clients used to work around extension intolerance was to make another connection without extensions. Some clients still include the code that does that, and it has since been repurposed many times to work around other forms of server intolerance. One of the consequences of that has been that certain classes of errors have been tolerated for many years. Clients could be relied on to try again with a different configuration, so there is less pressure on servers to implement features correctly. This added significant delays to the deployment of new TLS versions, and was a huge problem in the design of TLS 1.3. Once particularly nasty consequence was the application of this retry to version intolerance. That is, there was a strong tendency of servers to fail to connect if a client offered a newer protocol version. For example, we saw astonishingly high rates of intolerance to TLS 1.3 before the version negotiation mechanism there was redesigned. Some tests saw around 20% failure rates. That resulted in TLS - as deployed - being vulnerable to a range of trivial downgrade attacks, some of which are listed in RFC 7457. > In general I think the present draft doesn't pay enough > attention to extensions, which are after all the second > main reason for maintaining protocols, along with bug fixes. This is a fair criticism. We might draw different conclusions here, but here's my take, which expands on the text that I've staged. Regarding extensibility as the application of the robustness principle is a mistake. There are examples, such as with TLS, where extensibility was added to a protocol by relying on the tolerance of implementations to unexpected inputs. However, this is a poor strategy for extensibility. That particular case went disastrously, as RFC 6709 explains. Planning for new uses of a protocol means laying down expectations for what implementations will do when presented with unspecified inputs. Your MBZ bit example is a nice demonstration of how that works: you specify semantics for zero (do what this specification says), explicitly decline to define semantics for one, and then say two things that hopefully make it possible to start using one in future: "don't send one unless you know what it means" (an obvious thing really, but somehow still necessary), and the more important "if you don't know what one means, don't change your behaviour". There are also alternatives like "if you don't know what one means, ignore this much of the message" and "generate an error of the following type", but examples like the M bit in L2TP or the critical extensions in X.509 show that these options are chosen less often. Critically, none of this results in any doubt about what to do. So the recipient never has cause to contemplate the advice in "When in doubt, discard faulty input silently, [...]". There is still room for doubt even with a good design unfortunately, but that's the subject of a different draft, which you can read here: https://martinthomson.github.io/use-it-or-lose-it/draft-thomson-use-it-or-lose-it.html > > 5. Active Protocol Maintenance > > > > The robustness principle is best suited to safeguarding against flaws > > in a specification that is intended to remain unchanged for an > > extended period of time. > I don't think that's true. I agree. With the perspective you add, it's clear that this is not a good formulation. The edit that I shared above is an attempt a fixing this. > Firstly, very few people publish protocol > designs that they intend to be updated after a short period of time. > I'd argue that at the time of publication, all designs are intended > to remain unchanged indefinitely. I disagree with this. This is not the stance I've seen - at least in the groups I've been participating in. There, the recognition that the combination of an imperfect specification and the vicissitudes of time mean that there is never any expectation that the protocol will be viable in perpetuity. Yes, the intent is to provide something that is fit for purpose, which means deployment lifetimes measured in years, but that never means forever. For the gap between specification and perfection, there is the responsibility to tend to the ecosystem. QUIC might have over-rotated here, I'll admit. There's talk of shipping two versions on day 1, or having version 2 within a period as short as 6 months. But we had the same discussions with HTTP/2 and we while QUIC means less pressure to start on HTTP/3, it's still been a while now. > Secondly, I always understood that > the robustness principle was primarily a safeguard against flaws > in *implementations*. Yes, that's the mistake here. I agree. > If we *expect* a protocol to be extended by adding options or message > types, the robustness principle leads to very different text, like: > > If an unrecognized MESSAGE_TYPE is received in a unicast message, an > > Invalid message (Section 2.8.12) MAY be returned. Otherwise the > > message MAY be logged and MUST be discarded. If an unrecognized > > MESSAGE_TYPE is received in a multicast message, it MAY be logged and > > MUST be silently discarded. > In this case the Postel principle allows nodes that support different > but overlapping sets of message types to communicate robustly. That's > not a problem; it's a solution. As I said above, if the extensibility is well-defined (invoke 6709!), then the robustness principle never gets to play. I couldn't pick out this example easily, so without knowing the expectations around the handling of Invalid messages, I don't know if this is indeed a case where robustness would help. That said, if it would, then I would say that the specification needs to be improved rather than advice reliance on robustness. > (As TLS shows, this approach may not be acceptable for a security > protocol where downgrade attacks are a problem. But that's a subset > of all protocols.) People often point at TLS and say "oh, that's special", but I don't think that's accurate at all. At least not any more. The bulk of TLS is fairly mundane protocol engineering, with lessons that apply to many other protocols. Hence it being the perennial poster child. Of course, that's more true now than it was historically, so the misconception is understandable. > I think the draft in its present unbalanced form is misleading. > A balanced discussion of when the Postel principle is useful, > and when it's harmful, would be more what I'd expect from the IAB. My apologies, but that made me think "Fair and balanced," which I'm sure was not at all your intent :) In any case, if we disagree here, I think that's OK. However, my hope is that discussing the point about the scope of the statement will help. From nobody Fri May 11 00:59:58 2018 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 B8F541270FC for ; Fri, 11 May 2018 00:59:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 RaylFb6i7vzo for ; Fri, 11 May 2018 00:59:54 -0700 (PDT) Received: from mail-oi0-x22a.google.com (mail-oi0-x22a.google.com [IPv6:2607:f8b0:4003:c06::22a]) (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 A9289126BF6 for ; Fri, 11 May 2018 00:59:54 -0700 (PDT) Received: by mail-oi0-x22a.google.com with SMTP id e80-v6so4000270oig.11 for ; Fri, 11 May 2018 00:59:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=DKPSLevrq3MgZmSHjhiTWMk4Ql9ycNhmkXlqv9Er6Us=; b=GEgzKTzhTDYBojYWcAcX1RM5M3zL779UHIySpNlbSOA0xkMoX5Ma83EC8RLtenYscJ ybGgLMj82GRwTe+8+DsUHOsSIC84TQ/xZFj/NFUV5Rd1jnK0cB1ekr5fd2dUePnfogYN SGH4bynopLFInA3l5Mx537fzs+bHiI9sJVMf1qtT08Ig2Sa2/NJqa1rPYQRTnJSSAr2/ iil7eZrPKD5HjY8JOrlMaXDrbOscVPxVc4YK0bthlFDVle1GZopYZ805e/zsFDBXLe8X 1aO1ChDDuUkt/QVtiZr4aFe5RHjue3RH0eJBlS+lcQiokumOfsJIdlwBrYunKrXRPo2W Yacg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=DKPSLevrq3MgZmSHjhiTWMk4Ql9ycNhmkXlqv9Er6Us=; b=pm/bfy04CW4ac7mMvscb7voXqKAFSDsc/UCI3qWIP0qkzhtJVgHelQ4Fzhmajp2xoU zD1OQYjRphUnFY3nZFAVpR0YcGMsPaRWprLeJO0Fz+gkukBtI8CKz7rX3Q8OkCDiVnnj hXvCbNd5RqapTMpp4Rn5Y3qmP8ywfpGtWFhEElbviUPYl6+oKDUYCj4Dk64F3wnbCxeN jh1tK7f1B0MJaKcPUJA5M3+WMkVflP/4KdyuVx/KnSXWq0Uqh1oZPGqwfZ/XH4QYeFBv jEHKbtUDZLwUum7qlYTdUjBfNejml5qowwwM4phWE9mTlx9Qlf0hVlDK8g3jzWsQ8uOk HZNA== X-Gm-Message-State: ALKqPwf+CvfrROSj6FkSPfEy1LWm1icZ5+lEN8BTNqMXhgjkG15I++TT yqlFwu5HOSQoikfg+fojzJ4WWLlTYqafQsY1pfc= X-Google-Smtp-Source: AB8JxZqO3kfy0/1GqCqsFnnCKzXpBEFE9Udfcuzl/akMT0HdX3ZFu7moADj4w9o/wcS6yZ+IUGiVsIDQa8H8JXTalBA= X-Received: by 2002:aca:ebd4:: with SMTP id j203-v6mr2838623oih.110.1526025593774; Fri, 11 May 2018 00:59:53 -0700 (PDT) MIME-Version: 1.0 References: <152538075241.4552.6760702690778529507@ietfa.amsl.com> In-Reply-To: From: Martin Thomson Date: Fri, 11 May 2018 17:59:42 +1000 Message-ID: To: yaakov_s@rad.com Cc: architecture-discuss@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [arch-d] I-D Action: draft-iab-protocol-maintenance-00.txt X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.22 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: Fri, 11 May 2018 07:59:57 -0000 Thanks for the message Yaakov. It's an interesting thought, but I definitely think that it's a different draft. If you get the time, I'd be interested in reading it. Especially if you have ideas about how to go about solving the problem without every protocol having precisely one implementation. That's a failure mode we've lived already and it wasn't pleasant. The IAB has in the past attempted to create guidance on patterns for protocols that work. I agree that's not materially the same as a directly usable protocol component though. It's possible that the new waist of the Internet hourglass - https://people.eecs.berkeley.edu/~alig/papers/http.pdf - is the reusable component you are talking about. We're getting a lot of traction with reuse there. Of course, that's also a version of a horrible nightmare for many. Cheers, On Fri, May 11, 2018 at 12:42 AM Yaakov Stein wrote: > I have a meta-comment on this draft, or alternatively a proposal for a different draft. > I'm sure a lot of you have heard Scott Shenker's talk "The future of network and the past of protocols", > in which he makes the case for SDN. > His basic tenet is that computer science has perfected methods for implementing software very quickly > while protocols take a tremendously long time to design, perfect, and implement. > So, he concludes, throw out protocols and run everything on a centralized server. > Putting aside the obvious fact that he overlooks that protocols between multiple network elements need to be standardized > so that every implementation can interwork with every other one (while an algorithm running on a single CPU doesn't require standardization), > he makes a good point. > A lot of the speed of programming comes from use of "abstractions". > If every time one coded an app for a smartphone one needed to return to opcodes and bits, > then it would indeed be a lengthy error-prone process. > But instead programmers stand on the shoulders of those who came before them. > It works something like this. Say someone solves some problem. > The solution is initially made into a routine or function that can be open-sourced and reused. No-one need write that routine again. > If the solution is really successful it can be made into a library with various initializations and options that can be loaded when needed. > You needn't know how the library works, and if someone comes up with a better implementation it can refactored without the programmer knowing about it. > If it becomes even more successful it can be turned into an object that can be inherited and extended and even changed without looking at the source code. > If it is wildly successful, the functionality becomes part of the next generation of programming languages, and everyone has access to it without giving it any thought. > The SDN theorists claim that networking has no abstractions (or at least that they don't know of any), > and suggest a very strong abstraction - the "whitebox" switch (which can be any network element - an Ethernet bridge, an IP router, a firewall, etc). > That jump in logic aside, they have a point. Every time we design a protocol we go back to the basics. > We usually make a bit diagram (in ASCII art no less). We don't formally inherit functionality expect by riding over an existing protocol > (e.g., running a protocol over TCP can give it reliability). > As a concrete example, we often obtain protocol extensibility by utilizing TLVs. > Now, the designers of LDP came up with a nice idea to handle the case of an implementation not knowing a particular type - the U bit. > If the U bit is set it signifies that this unknown type can be gracefully ignored. Otherwise an error message must be returned. > Were we to work like computer scientists, once this idea was implemented it should be automatically inherited by every future protocol using TLVs. > Automatically. Not - if you heard about it put a U bit into your bit diagram. > A while back the IEEE 802 people tried doing something like this when they design the Generic Attribute Registration Protocol. > GVRP and GMRP inherited it, but nothing else. > What can we do in the IETF to turn our ideas into abstractions that are inherited? > Y(J)S > _______________________________________________ > Architecture-discuss mailing list > Architecture-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/architecture-discuss From nobody Wed May 16 20:43:06 2018 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 A05F412E897 for ; Wed, 16 May 2018 20:43:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 9u4qlzKcIuWF for ; Wed, 16 May 2018 20:43:01 -0700 (PDT) Received: from mail-pl0-x232.google.com (mail-pl0-x232.google.com [IPv6:2607:f8b0:400e:c01::232]) (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 356CF124B18 for ; Wed, 16 May 2018 20:43:01 -0700 (PDT) Received: by mail-pl0-x232.google.com with SMTP id c41-v6so1643574plj.10 for ; Wed, 16 May 2018 20:43:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:to:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=rQK/Dal7edgUKzZpJUZ5ARyiTkLWeF6T64YRbw7a+yo=; b=SzgAA0uWGHLF4jU4U8mBYJm9XEfHGHyWVjGgdNdE/5AQZvwoqC1/Qzp3fAb4/AX5bt xmJuRAzPr0fBi3rNDpSAUXvcyPHUlNMslci4zH4MwQHqpsD8d7Ms+PDCvVcW7Xf4YcSP fEYu+dWMGlMo7e/kBF3UV/4WecR6c8U+iHT+plf2XgnjaylkhVIkqI6grQTUM9acLa23 2/XcAHXr+4qcNkoRabyKy/fFHNYRzdxZW/bXJQ2bX0V47TydztmNTs1SoahyU08Qvlib AcYlQSp/KUU4AwaV1/jBHl7XSExsnaMUgN+8sxgWnbGFEjltl+6PWiVOLl5yNpocOeqA D4yw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:to:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=rQK/Dal7edgUKzZpJUZ5ARyiTkLWeF6T64YRbw7a+yo=; b=R3Q+7EPCTIS6wHGcwSDUrHbwm/A7Zc+5Xj3R09XOOqt94jLch5h179hl8SuaxrppjV dz99QbLd1te+CXCF/HvBrFDhXYA1DBW7D1XQI9s0GTmP4DOI+NATDedS/cKNYU4WUocm BEAP6TjusaVBlTHeCbHPRY+JOosMsN7PP/IR51utPSJ9qPoAzgpP+A3hfVLv6sRdc8rN /bXylaAbi60IJ0DH/Zdew+/Zv0U/g0M8ANXXcXQyivIYZ7HXL3v9D8o9UetW2jSqjxV6 dgj6mGY25ZPJGK8Ogd1KHrVj26XHs9UbhEZwHJ9xFcmkTJG99upe+t1haX16jkYsyNbO Zbew== X-Gm-Message-State: ALKqPwdK3twoVcQYrV4s7XlmOzGNfpqeP4g6DCeEZcVlvTc3X3Lsbiwp XV9QNZDq1UGkopjPGyRClZy2Pw== X-Google-Smtp-Source: AB8JxZrZC3tOD5m5HBEYRPG5Kp3lrpXFWc+SnwgTf6Cf29KRRtaIn2SAIVO6N2gphfGM3Xh1N7NEAQ== X-Received: by 2002:a17:902:5327:: with SMTP id b36-v6mr3664371pli.316.1526528580302; Wed, 16 May 2018 20:43:00 -0700 (PDT) Received: from [192.168.178.21] ([118.148.121.80]) by smtp.gmail.com with ESMTPSA id b5-v6sm6528394pfc.16.2018.05.16.20.42.57 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 16 May 2018 20:42:59 -0700 (PDT) Sender: Brian Carpenter To: Yaakov Stein , "architecture-discuss@ietf.org" References: <152538075241.4552.6760702690778529507@ietfa.amsl.com> From: Brian E Carpenter Message-ID: Date: Thu, 17 May 2018 15:43:02 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: [arch-d] Inheriting protocol abstractions [I-D Action: draft-iab-protocol-maintenance-00.txt] X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.22 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: Thu, 17 May 2018 03:43:04 -0000 Yaakov, > What can we do in the IETF to turn our ideas into abstractions that are inherited? At the level of blocks of protocol design, I don't have an answer, unless we specify the protocols in a suitable OO language. That would be an IRTF topic for a good number of years, I suspect. At the level of components of PDUs, isn't that an argument for using CBOR instead of TLVs? CBOR isn't OO as such but it can be used to construct abstractions and re-useable components. Regards Brian On 11/05/2018 02:42, Yaakov Stein wrote: > I have a meta-comment on this draft, or alternatively a proposal for a different draft. > > I'm sure a lot of you have heard Scott Shenker's talk "The future of network and the past of protocols", > in which he makes the case for SDN. > > His basic tenet is that computer science has perfected methods for implementing software very quickly > while protocols take a tremendously long time to design, perfect, and implement. > So, he concludes, throw out protocols and run everything on a centralized server. > > Putting aside the obvious fact that he overlooks that protocols between multiple network elements need to be standardized > so that every implementation can interwork with every other one (while an algorithm running on a single CPU doesn't require standardization), > he makes a good point. > > A lot of the speed of programming comes from use of "abstractions". > If every time one coded an app for a smartphone one needed to return to opcodes and bits, > then it would indeed be a lengthy error-prone process. > But instead programmers stand on the shoulders of those who came before them. > > It works something like this. Say someone solves some problem. > The solution is initially made into a routine or function that can be open-sourced and reused. No-one need write that routine again. > If the solution is really successful it can be made into a library with various initializations and options that can be loaded when needed. > You needn't know how the library works, and if someone comes up with a better implementation it can refactored without the programmer knowing about it. > If it becomes even more successful it can be turned into an object that can be inherited and extended and even changed without looking at the source code. > If it is wildly successful, the functionality becomes part of the next generation of programming languages, and everyone has access to it without giving it any thought. > > The SDN theorists claim that networking has no abstractions (or at least that they don't know of any), > and suggest a very strong abstraction - the "whitebox" switch (which can be any network element - an Ethernet bridge, an IP router, a firewall, etc). > > That jump in logic aside, they have a point. Every time we design a protocol we go back to the basics. > We usually make a bit diagram (in ASCII art no less). We don't formally inherit functionality expect by riding over an existing protocol > (e.g., running a protocol over TCP can give it reliability). > > As a concrete example, we often obtain protocol extensibility by utilizing TLVs. > Now, the designers of LDP came up with a nice idea to handle the case of an implementation not knowing a particular type - the U bit. > If the U bit is set it signifies that this unknown type can be gracefully ignored. Otherwise an error message must be returned. > Were we to work like computer scientists, once this idea was implemented it should be automatically inherited by every future protocol using TLVs. > Automatically. Not - if you heard about it put a U bit into your bit diagram. > > A while back the IEEE 802 people tried doing something like this when they design the Generic Attribute Registration Protocol. > GVRP and GMRP inherited it, but nothing else. > > What can we do in the IETF to turn our ideas into abstractions that are inherited? > > Y(J)S > > _______________________________________________ > Architecture-discuss mailing list > Architecture-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/architecture-discuss > From nobody Thu May 17 00:37:06 2018 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 C0A7912E8EA for ; Thu, 17 May 2018 00:37:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=rad365.onmicrosoft.com 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 4GlFGTEgvVf8 for ; Thu, 17 May 2018 00:37:00 -0700 (PDT) Received: from EUR02-HE1-obe.outbound.protection.outlook.com (mail-eopbgr10046.outbound.protection.outlook.com [40.107.1.46]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E55641200C1 for ; Thu, 17 May 2018 00:36:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rad365.onmicrosoft.com; s=selector1-rad-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Z1ACDwIOMjaWEVPJ/88ZIeb/tHLHMsYtJXr/en+i5XE=; b=ck8HMJoAlcMU9yVScMbm0GLtHq+dnCvmd9gUjbyojZriHCwHI0lLRRxWQT7Bpcnn87FJkdczN/l1LgKX2gSkGZ8v9y2H+uVXnkSLDBfMuIf+LJf1dacvv293cncq0dUOHU7EagCkrM1xkR3Fi1/CdyqhQhvRrMAud7j8wzS53Us= Received: from AM5PR0301MB2561.eurprd03.prod.outlook.com (10.169.149.16) by AM5PR0301MB2468.eurprd03.prod.outlook.com (10.169.148.140) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.776.11; Thu, 17 May 2018 07:36:57 +0000 Received: from AM5PR0301MB2561.eurprd03.prod.outlook.com ([fe80::71fd:ffb2:2d38:3f65]) by AM5PR0301MB2561.eurprd03.prod.outlook.com ([fe80::71fd:ffb2:2d38:3f65%8]) with mapi id 15.20.0776.010; Thu, 17 May 2018 07:36:57 +0000 From: Yaakov Stein To: Brian E Carpenter , "architecture-discuss@ietf.org" Thread-Topic: Inheriting protocol abstractions [I-D Action: draft-iab-protocol-maintenance-00.txt] Thread-Index: AQHT7ZEp2McirDQ3RkK6RZJW0PQaIqQzg/1A Date: Thu, 17 May 2018 07:36:57 +0000 Message-ID: References: <152538075241.4552.6760702690778529507@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=yaakov_s@rad.com; x-originating-ip: [2.55.8.234] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; AM5PR0301MB2468; 7:x10s+BxON6+T5DBjyImHfDJnnkzZybFXGJmpdSwdrBEwrJi2znG0+FYxifieM4jPWsOrqvCtHUi2EOXlbg1cYM0ZTXy3Mt04uHfy+Y0Nj76U0KwBK/hR6VXehMR7/1+IWcSWvYh47kUxS8yuSF9+X8sNUaWYlueU78fvP9blfPTMELpySV1WeAMM3mqtOFvw6Ctx7t19pM6tU8TyUJmORuW0qQHDdJmJ4J24hlDFFBZdSZkBU5No0QGq0CHWPPmY x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(48565401081)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7153060)(7193020); SRVR:AM5PR0301MB2468; x-ms-traffictypediagnostic: AM5PR0301MB2468: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(189930954265078)(131327999870524)(85827821059158)(279801643600669)(45079756050767); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(3002001)(93006095)(93001095)(3231254)(944501410)(52105095)(10201501046)(6055026)(149027)(150027)(6041310)(20161123560045)(20161123564045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123562045)(20161123558120)(6072148)(201708071742011)(7699016); SRVR:AM5PR0301MB2468; BCL:0; PCL:0; RULEID:; SRVR:AM5PR0301MB2468; x-forefront-prvs: 067553F396 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(396003)(366004)(346002)(39860400002)(39380400002)(13464003)(199004)(189003)(476003)(966005)(9686003)(446003)(229853002)(93886005)(561944003)(6306002)(2900100001)(55016002)(5250100002)(45080400002)(478600001)(316002)(6436002)(11346002)(33656002)(110136005)(66066001)(2501003)(486006)(86362001)(3846002)(59450400001)(6506007)(26005)(6116002)(7696005)(53546011)(102836004)(8936002)(99286004)(81166006)(7736002)(105586002)(81156014)(39060400002)(186003)(106356001)(76176011)(5660300001)(14454004)(74316002)(68736007)(25786009)(2906002)(8676002)(3660700001)(53936002)(6246003)(305945005)(97736004)(3280700002); DIR:OUT; SFP:1101; SCL:1; SRVR:AM5PR0301MB2468; H:AM5PR0301MB2561.eurprd03.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: rad.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: ZRMCxdXSKgnJuGkLlCD4VcGfi6tLJMdLFOwpgz72hPD2Xwti+occGr2rUsIl+8G3wbDNJHxaH9d1o1HV0cnS3iJJH0S7KGLi03VYXSM38UmPggr5yitTtO35Wg5c8CGuw4/Hu5PyMhydKnzjqUyiKNfcDR5fTPHaTjPcO4QpIQ/ehJK+oQR6EfjpPZaMbr0D spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Office365-Filtering-Correlation-Id: 2b1e550d-7b26-48cd-0998-08d5bbc8f806 X-OriginatorOrg: rad.com X-MS-Exchange-CrossTenant-Network-Message-Id: 2b1e550d-7b26-48cd-0998-08d5bbc8f806 X-MS-Exchange-CrossTenant-originalarrivaltime: 17 May 2018 07:36:57.1010 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f9047108-cc2c-4e48-97a3-43fad1b3bf9d X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM5PR0301MB2468 Archived-At: Subject: Re: [arch-d] Inheriting protocol abstractions [I-D Action: draft-iab-protocol-maintenance-00.txt] X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.22 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: Thu, 17 May 2018 07:37:04 -0000 QnJpYW4sIA0KDQpDQk9SIGlzIGEgbmljZSBwbGF0Zm9ybSBmb3Igc29tZSB0eXBlcyBvZiB3b3Jr LCBpZiB0aGUgZ29hbHMgYXJlIHNtYWxsIGNvZGUvbWVzc2FnZSBzaXplIGFuZCBleHRlbnNpYmls aXR5IHdpdGhvdXQgdmVyc2lvbiBuZWdvdGlhdGlvbi4NCklmIHlvdSB3YW50IG9iamVjdCBvcmll bnRhdGVkIGV4dGVuc2liaWxpdHksIENPUkJBIGFjaGlldmVkIHRoYXQsIGFuZCBoYWQgbWFwcGlu Z3MgdG8gYWxsIHVzZWZ1bCBwcm9ncmFtbWluZyBsYW5ndWFnZXMuDQoNCkJ1dCwgd2hhdCBJIHdh cyB0YWxraW5nIGFib3V0IHdhcyAoYXQgbGVhc3QgaW5pdGlhbGx5KSBhIG1pbmRzZXQuDQoNCklu IFRJQ1RPQyB3ZSBub3cgaGF2ZSBhIGRyYWZ0IG9uIHRpbWVzdGFtcCBmb3JtYXRzLg0KSWRlYWxs eSwgaXQgd291bGQgZ2l2ZSBvcHRpb25zIHdpdGggc29tZSBzdGFuZGFyZGl6ZWQgbm9tZW5jbGF0 dXJlLCBhbmQgdGhlbiBhbGwgZnV0dXJlIHdvcmsgd291bGQgcmVmZXIgdG8gdGhpcyBkb2N1bWVu dCwNCnRodXMgYWNoaWV2aW5nIGJhc2ljIGluaGVyaXRhbmNlIChpbmNsdWRpbmcgYSBjZXJ0YWlu IGRlZ3JlZSBvZiBvcHRpb25zKS4NCg0KSSBjYW4gaW1hZ2luZSBhIHNldCBvZiBhYnN0cmFjdCBS RkNzIHNwZWNpZnlpbmcgaG93IHRvIGZvcm1hdCB0aW1lc3RhbXBzLCBhZGRyZXNzZXMsIFFvUyBs ZXZlbHMsIGhvcCBjb3VudHMsIGV0Yy4NClRoZW4gYSBzZXQgb2YgYWJzdHJhY3QgUkZDcyBmb3Ig cHJvY2VkdXJlcyAtIGRpc2NvdmVyeSwgaGFuZHNoYWtpbmcsIG9wdGlvbiBuZWdvdGlhdGlvbiwg dmVyc2lvbmluZyAoaWYgbm90IGRvaW5nIHNvbWV0aGluZyBsaWtlIENCT1IpLCBlcnJvciByZWNv dmVyeSwgcmVzaWxpZW5jZSwgIGV0Yy4NCg0KVGhlIG5leHQgc3RlcCB3b3VsZCBiZSBzdGFuZGFy ZCBPcGVuIFNvdXJjZSBpbXBsZW1lbnRhdGlvbnMgb2YgYWxsIG9mIHRoZXNlIFJGQ3MuDQoNCk1h eWJlIHdlIHNob3VsZCBzdGFydCB3aXRoIGRlZmluaW5nIHdoYXQgZWxlbWVudHMvcHJvY2VkdXJl cyBuZWVkIHRvIGJlIGRlZmluZWQsDQphbmQgdHJ5IHRvIHdyaXRlIGZvcm1hbGl6ZWQgdmVyc2lv bnMgb2Ygc29tZSBvZiB0aGUgaW1wb3J0YW50IHByb3RvY29scy4NCg0KWShKKVMNCg0KDQoNCi0t LS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBCcmlhbiBDYXJwZW50ZXIgW21haWx0bzpi ZWNhcnBlbnRlcjQ2QGdtYWlsLmNvbV0gT24gQmVoYWxmIE9mIEJyaWFuIEUgQ2FycGVudGVyDQpT ZW50OiAxNy8wNS8yMDE4IDA2OjQzDQpUbzogWWFha292IFN0ZWluIDx5YWFrb3Zfc0ByYWQuY29t PjsgYXJjaGl0ZWN0dXJlLWRpc2N1c3NAaWV0Zi5vcmcNClN1YmplY3Q6IEluaGVyaXRpbmcgcHJv dG9jb2wgYWJzdHJhY3Rpb25zIFtJLUQgQWN0aW9uOiBkcmFmdC1pYWItcHJvdG9jb2wtbWFpbnRl bmFuY2UtMDAudHh0XQ0KDQpZYWFrb3YsDQoNCj4gV2hhdCBjYW4gd2UgZG8gaW4gdGhlIElFVEYg dG8gdHVybiBvdXIgaWRlYXMgaW50byBhYnN0cmFjdGlvbnMgdGhhdCBhcmUgaW5oZXJpdGVkPw0K DQpBdCB0aGUgbGV2ZWwgb2YgYmxvY2tzIG9mIHByb3RvY29sIGRlc2lnbiwgSSBkb24ndCBoYXZl IGFuIGFuc3dlciwgdW5sZXNzIHdlIHNwZWNpZnkgdGhlIHByb3RvY29scyBpbiBhIHN1aXRhYmxl IE9PIGxhbmd1YWdlLiBUaGF0IHdvdWxkIGJlIGFuIElSVEYgdG9waWMgZm9yIGEgZ29vZCBudW1i ZXIgb2YgeWVhcnMsIEkgc3VzcGVjdC4NCg0KQXQgdGhlIGxldmVsIG9mIGNvbXBvbmVudHMgb2Yg UERVcywgaXNuJ3QgdGhhdCBhbiBhcmd1bWVudCBmb3IgdXNpbmcgQ0JPUiBpbnN0ZWFkIG9mIFRM VnM/IENCT1IgaXNuJ3QgT08gYXMgc3VjaCBidXQgaXQgY2FuIGJlIHVzZWQgdG8gY29uc3RydWN0 IGFic3RyYWN0aW9ucyBhbmQgcmUtdXNlYWJsZSBjb21wb25lbnRzLg0KDQpSZWdhcmRzDQogICBC cmlhbg0KDQpPbiAxMS8wNS8yMDE4IDAyOjQyLCBZYWFrb3YgU3RlaW4gd3JvdGU6DQo+IEkgaGF2 ZSBhIG1ldGEtY29tbWVudCBvbiB0aGlzIGRyYWZ0LCBvciBhbHRlcm5hdGl2ZWx5IGEgcHJvcG9z YWwgZm9yIGEgZGlmZmVyZW50IGRyYWZ0Lg0KPiANCj4gSSdtIHN1cmUgYSBsb3Qgb2YgeW91IGhh dmUgaGVhcmQgU2NvdHQgU2hlbmtlcidzIHRhbGsgIlRoZSBmdXR1cmUgb2YgDQo+IG5ldHdvcmsg YW5kIHRoZSBwYXN0IG9mIHByb3RvY29scyIsIGluIHdoaWNoIGhlIG1ha2VzIHRoZSBjYXNlIGZv ciBTRE4uDQo+IA0KPiBIaXMgYmFzaWMgdGVuZXQgaXMgdGhhdCBjb21wdXRlciBzY2llbmNlIGhh cyBwZXJmZWN0ZWQgbWV0aG9kcyBmb3IgDQo+IGltcGxlbWVudGluZyBzb2Z0d2FyZSB2ZXJ5IHF1 aWNrbHkgd2hpbGUgcHJvdG9jb2xzIHRha2UgYSB0cmVtZW5kb3VzbHkgbG9uZyB0aW1lIHRvIGRl c2lnbiwgcGVyZmVjdCwgYW5kIGltcGxlbWVudC4NCj4gU28sIGhlIGNvbmNsdWRlcywgdGhyb3cg b3V0IHByb3RvY29scyBhbmQgcnVuIGV2ZXJ5dGhpbmcgb24gYSBjZW50cmFsaXplZCBzZXJ2ZXIu DQo+IA0KPiBQdXR0aW5nIGFzaWRlIHRoZSBvYnZpb3VzIGZhY3QgdGhhdCBoZSBvdmVybG9va3Mg dGhhdCBwcm90b2NvbHMgDQo+IGJldHdlZW4gbXVsdGlwbGUgbmV0d29yayBlbGVtZW50cyBuZWVk IHRvIGJlIHN0YW5kYXJkaXplZCBzbyB0aGF0IA0KPiBldmVyeSBpbXBsZW1lbnRhdGlvbiBjYW4g aW50ZXJ3b3JrIHdpdGggZXZlcnkgb3RoZXIgb25lICh3aGlsZSBhbiBhbGdvcml0aG0gcnVubmlu ZyBvbiBhIHNpbmdsZSBDUFUgZG9lc24ndCByZXF1aXJlIHN0YW5kYXJkaXphdGlvbiksIGhlIG1h a2VzIGEgZ29vZCBwb2ludC4NCj4gDQo+IEEgbG90IG9mIHRoZSBzcGVlZCBvZiBwcm9ncmFtbWlu ZyBjb21lcyBmcm9tIHVzZSBvZiAiYWJzdHJhY3Rpb25zIi4NCj4gSWYgZXZlcnkgdGltZSBvbmUg Y29kZWQgYW4gYXBwIGZvciBhIHNtYXJ0cGhvbmUgb25lIG5lZWRlZCB0byByZXR1cm4gDQo+IHRv IG9wY29kZXMgYW5kIGJpdHMsIHRoZW4gaXQgd291bGQgaW5kZWVkIGJlIGEgbGVuZ3RoeSBlcnJv ci1wcm9uZSBwcm9jZXNzLg0KPiBCdXQgaW5zdGVhZCBwcm9ncmFtbWVycyBzdGFuZCBvbiB0aGUg c2hvdWxkZXJzIG9mIHRob3NlIHdobyBjYW1lIGJlZm9yZSB0aGVtLg0KPiANCj4gSXQgd29ya3Mg c29tZXRoaW5nIGxpa2UgdGhpcy4gU2F5IHNvbWVvbmUgc29sdmVzIHNvbWUgcHJvYmxlbS4NCj4g VGhlIHNvbHV0aW9uIGlzIGluaXRpYWxseSBtYWRlIGludG8gYSByb3V0aW5lIG9yIGZ1bmN0aW9u IHRoYXQgY2FuIGJlIG9wZW4tc291cmNlZCBhbmQgcmV1c2VkLiBOby1vbmUgbmVlZCB3cml0ZSB0 aGF0IHJvdXRpbmUgYWdhaW4uDQo+IElmIHRoZSBzb2x1dGlvbiBpcyByZWFsbHkgc3VjY2Vzc2Z1 bCBpdCBjYW4gYmUgbWFkZSBpbnRvIGEgbGlicmFyeSB3aXRoIHZhcmlvdXMgaW5pdGlhbGl6YXRp b25zIGFuZCBvcHRpb25zIHRoYXQgY2FuIGJlIGxvYWRlZCB3aGVuIG5lZWRlZC4gDQo+IFlvdSBu ZWVkbid0IGtub3cgaG93IHRoZSBsaWJyYXJ5IHdvcmtzLCBhbmQgaWYgc29tZW9uZSBjb21lcyB1 cCB3aXRoIGEgYmV0dGVyIGltcGxlbWVudGF0aW9uIGl0IGNhbiByZWZhY3RvcmVkIHdpdGhvdXQg dGhlIHByb2dyYW1tZXIga25vd2luZyBhYm91dCBpdC4NCj4gSWYgaXQgYmVjb21lcyBldmVuIG1v cmUgc3VjY2Vzc2Z1bCBpdCBjYW4gYmUgdHVybmVkIGludG8gYW4gb2JqZWN0IHRoYXQgY2FuIGJl IGluaGVyaXRlZCBhbmQgZXh0ZW5kZWQgYW5kIGV2ZW4gY2hhbmdlZCB3aXRob3V0IGxvb2tpbmcg YXQgdGhlIHNvdXJjZSBjb2RlLg0KPiBJZiBpdCBpcyB3aWxkbHkgc3VjY2Vzc2Z1bCwgdGhlIGZ1 bmN0aW9uYWxpdHkgYmVjb21lcyBwYXJ0IG9mIHRoZSBuZXh0IGdlbmVyYXRpb24gb2YgcHJvZ3Jh bW1pbmcgbGFuZ3VhZ2VzLCBhbmQgZXZlcnlvbmUgaGFzIGFjY2VzcyB0byBpdCB3aXRob3V0IGdp dmluZyBpdCBhbnkgdGhvdWdodC4NCj4gDQo+IFRoZSBTRE4gdGhlb3Jpc3RzIGNsYWltIHRoYXQg bmV0d29ya2luZyBoYXMgbm8gYWJzdHJhY3Rpb25zIChvciBhdCANCj4gbGVhc3QgdGhhdCB0aGV5 IGRvbid0IGtub3cgb2YgYW55KSwgYW5kIHN1Z2dlc3QgYSB2ZXJ5IHN0cm9uZyBhYnN0cmFjdGlv biAtIHRoZSAid2hpdGVib3giIHN3aXRjaCAod2hpY2ggY2FuIGJlIGFueSBuZXR3b3JrIGVsZW1l bnQgLSBhbiBFdGhlcm5ldCBicmlkZ2UsIGFuIElQIHJvdXRlciwgYSBmaXJld2FsbCwgZXRjKS4N Cj4gDQo+IFRoYXQganVtcCBpbiBsb2dpYyBhc2lkZSwgdGhleSBoYXZlIGEgcG9pbnQuIEV2ZXJ5 IHRpbWUgd2UgZGVzaWduIGEgcHJvdG9jb2wgd2UgZ28gYmFjayB0byB0aGUgYmFzaWNzLg0KPiBX ZSB1c3VhbGx5IG1ha2UgYSBiaXQgZGlhZ3JhbSAoaW4gQVNDSUkgYXJ0IG5vIGxlc3MpLiBXZSBk b24ndCANCj4gZm9ybWFsbHkgaW5oZXJpdCBmdW5jdGlvbmFsaXR5IGV4cGVjdCBieSByaWRpbmcg b3ZlciBhbiBleGlzdGluZyBwcm90b2NvbCAoZS5nLiwgcnVubmluZyBhIHByb3RvY29sIG92ZXIg VENQIGNhbiBnaXZlIGl0IHJlbGlhYmlsaXR5KS4NCj4gDQo+IEFzIGEgY29uY3JldGUgZXhhbXBs ZSwgd2Ugb2Z0ZW4gb2J0YWluIHByb3RvY29sIGV4dGVuc2liaWxpdHkgYnkgdXRpbGl6aW5nIFRM VnMuDQo+IE5vdywgdGhlIGRlc2lnbmVycyBvZiBMRFAgY2FtZSB1cCB3aXRoIGEgbmljZSBpZGVh IHRvIGhhbmRsZSB0aGUgY2FzZSBvZiBhbiBpbXBsZW1lbnRhdGlvbiBub3Qga25vd2luZyBhIHBh cnRpY3VsYXIgdHlwZSAtIHRoZSBVIGJpdC4NCj4gSWYgdGhlIFUgYml0IGlzIHNldCBpdCBzaWdu aWZpZXMgdGhhdCB0aGlzIHVua25vd24gdHlwZSBjYW4gYmUgZ3JhY2VmdWxseSBpZ25vcmVkLiBP dGhlcndpc2UgYW4gZXJyb3IgbWVzc2FnZSBtdXN0IGJlIHJldHVybmVkLg0KPiBXZXJlIHdlIHRv IHdvcmsgbGlrZSBjb21wdXRlciBzY2llbnRpc3RzLCBvbmNlIHRoaXMgaWRlYSB3YXMgaW1wbGVt ZW50ZWQgaXQgc2hvdWxkIGJlIGF1dG9tYXRpY2FsbHkgaW5oZXJpdGVkIGJ5IGV2ZXJ5IGZ1dHVy ZSBwcm90b2NvbCB1c2luZyBUTFZzLg0KPiBBdXRvbWF0aWNhbGx5LiBOb3QgLSBpZiB5b3UgaGVh cmQgYWJvdXQgaXQgcHV0IGEgVSBiaXQgaW50byB5b3VyIGJpdCBkaWFncmFtLg0KPiANCj4gQSB3 aGlsZSBiYWNrIHRoZSBJRUVFIDgwMiBwZW9wbGUgdHJpZWQgZG9pbmcgc29tZXRoaW5nIGxpa2Ug dGhpcyB3aGVuIHRoZXkgZGVzaWduIHRoZSBHZW5lcmljIEF0dHJpYnV0ZSBSZWdpc3RyYXRpb24g UHJvdG9jb2wuDQo+IEdWUlAgYW5kIEdNUlAgaW5oZXJpdGVkIGl0LCBidXQgbm90aGluZyBlbHNl Lg0KPiANCj4gV2hhdCBjYW4gd2UgZG8gaW4gdGhlIElFVEYgdG8gdHVybiBvdXIgaWRlYXMgaW50 byBhYnN0cmFjdGlvbnMgdGhhdCBhcmUgaW5oZXJpdGVkPw0KPiANCj4gWShKKVMNCj4gDQo+IF9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IEFyY2hpdGVj dHVyZS1kaXNjdXNzIG1haWxpbmcgbGlzdA0KPiBBcmNoaXRlY3R1cmUtZGlzY3Vzc0BpZXRmLm9y Zw0KPiBodHRwczovL2VtZWEwMS5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJs PWh0dHBzJTNBJTJGJTJGd3d3DQo+IC5pZXRmLm9yZyUyRm1haWxtYW4lMkZsaXN0aW5mbyUyRmFy Y2hpdGVjdHVyZS1kaXNjdXNzJmRhdGE9MDElN0MwMSU3Q3kNCj4gYWFrb3ZfcyU0MHJhZC5jb20l N0M5NjljNDM2NGJlZjA0ZDZjNjRkNDA4ZDViYmE4NGE1NSU3Q2Y5MDQ3MTA4Y2MyYzRlNA0KPiA4 OTdhMzQzZmFkMWIzYmY5ZCU3QzEmc2RhdGE9Skk3NjhhU0xBUEVNOTdoOThibWZtREV3ZndzVSUy QmR5QzNSN1o5eUpsDQo+IDlIbyUzRCZyZXNlcnZlZD0wDQo+IA0K From nobody Fri May 18 13:46:55 2018 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 052AA12E03C for ; Fri, 18 May 2018 13:46:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 3TKbxeX4ii_s for ; Fri, 18 May 2018 13:46:51 -0700 (PDT) Received: from mail-pf0-x22b.google.com (mail-pf0-x22b.google.com [IPv6:2607:f8b0:400e:c00::22b]) (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 8F75D12E03F for ; Fri, 18 May 2018 13:46:51 -0700 (PDT) Received: by mail-pf0-x22b.google.com with SMTP id a22-v6so4285919pfn.6 for ; Fri, 18 May 2018 13:46:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:to:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=0nsrIct698uXUuzND4fxNoWr2yyCMBrcA4ThkabDioI=; b=UuhcMJy/npXPcaKXRcb8JH+9kGdlOjy81d3xzEfSQp6WazIsNeQmKgT+5QpHAXSDHk iexWLwsm8a364z8xoB0x+um0MOlBQCvOibF7ngYixtpp2E67+t6/NSEhf2GogJVl5SAd lP+RAxUdWofXR2gEzEEZkAvyyp9wJlkhBWazpK4u70hAMmp2qz2s/QCZpTyZj8pwZK9a +D3bWU0xHPinAHTbPw6qHI5245i0IOy3BMTqDZ+0gZcLNmbNQh9mXFANV+M0VkQLc0ja YHhKD5FPs9NOonZTVQPy0CAFPErZCB2PGgEid56II0WtkRX0+TuBF7pFdv7iilcR0boP mTQA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:to:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=0nsrIct698uXUuzND4fxNoWr2yyCMBrcA4ThkabDioI=; b=stkOKVxjWg2HNm4kxdpkay4mFMfvwAa2vbL+lu2pUA28ssFSLIygfb9oZKxdU1f9ZY E61mdN9pccP+2QbX7ZuvFjGu7MGVj60LwrgHzz4kHjwXXUTqHTLoUjBQd4PTh245rL1X 4rroJYtFUQFTiUaibzS7ZltIqQAxCL5GMaqbMkmA3jsbqHD1c2EBf6G8S2DcQpOPnOGW NA1FMv+5+zJBW63hg7m+lk2utjF7oOPNKEY2af/oX8cNDJBG1cJt+R/1ps2zK7BXweh9 wIBdUoeK0E9MdKeK9vPZ5TNbLdLXT7tWs9YXIe/y1cYoMgQfyfsO2gvsUjyCu578UiIu iKMw== X-Gm-Message-State: ALKqPwdee685rvfyPNJP0VV8e6d9Hrdt90mrCs+B/MHWD1Dhkfc7HPY/ ZYmDhEBQTG+4Dgq2fn0kTThCGQ== X-Google-Smtp-Source: AB8JxZo6aZnWv4iX/AS0MgNqP5fOvJF8+hLAIqUxurlTCviKx+xxZn9tPcApkfMzwUDs/DvE+YY/jQ== X-Received: by 2002:a62:fe0e:: with SMTP id z14-v6mr10903678pfh.73.1526676410639; Fri, 18 May 2018 13:46:50 -0700 (PDT) Received: from [192.168.178.21] ([118.148.121.80]) by smtp.gmail.com with ESMTPSA id n10-v6sm18741531pfj.68.2018.05.18.13.46.47 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 18 May 2018 13:46:49 -0700 (PDT) Sender: Brian Carpenter To: Yaakov Stein , "architecture-discuss@ietf.org" References: <152538075241.4552.6760702690778529507@ietfa.amsl.com> From: Brian E Carpenter Message-ID: Date: Sat, 19 May 2018 08:46:56 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [arch-d] Inheriting protocol abstractions [I-D Action: draft-iab-protocol-maintenance-00.txt] X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.22 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: Fri, 18 May 2018 20:46:54 -0000 On 17/05/2018 19:36, Yaakov Stein wrote: > Brian, > > CBOR is a nice platform for some types of work, if the goals are small code/message size and extensibility without version negotiation. (Which doesn't imply that CBOR prevents version negotiation. It just isn't particularly necessary.) What types of work are not suitable for CBOR? We switched the design of GRASP from TLV to CBOR, and it was certainly an improvement. > If you want object orientated extensibility, CORBA achieved that, and had mappings to all useful programming languages. Hmm. I think some of my worst nightmares 15 to 20 years ago were about CORBA. I guess we are a bit less scared of complexity now than then. > But, what I was talking about was (at least initially) a mindset. Well, re-use in general is a mindset. > In TICTOC we now have a draft on timestamp formats. > Ideally, it would give options with some standardized nomenclature, and then all future work would refer to this document, > thus achieving basic inheritance (including a certain degree of options). Yes. This is something you can do with CDDL in the case of CBOR. > I can imagine a set of abstract RFCs specifying how to format timestamps, addresses, QoS levels, hop counts, etc. > Then a set of abstract RFCs for procedures - discovery, handshaking, option negotiation, versioning (if not doing something like CBOR), error recovery, resilience, etc. > > The next step would be standard Open Source implementations of all of these RFCs. > > Maybe we should start with defining what elements/procedures need to be defined, > and try to write formalized versions of some of the important protocols. Sounds like an IRTF project. Regards Brian > > Y(J)S > > > > -----Original Message----- > From: Brian Carpenter [mailto:becarpenter46@gmail.com] On Behalf Of Brian E Carpenter > Sent: 17/05/2018 06:43 > To: Yaakov Stein ; architecture-discuss@ietf.org > Subject: Inheriting protocol abstractions [I-D Action: draft-iab-protocol-maintenance-00.txt] > > Yaakov, > >> What can we do in the IETF to turn our ideas into abstractions that are inherited? > > At the level of blocks of protocol design, I don't have an answer, unless we specify the protocols in a suitable OO language. That would be an IRTF topic for a good number of years, I suspect. > > At the level of components of PDUs, isn't that an argument for using CBOR instead of TLVs? CBOR isn't OO as such but it can be used to construct abstractions and re-useable components. > > Regards > Brian > > On 11/05/2018 02:42, Yaakov Stein wrote: >> I have a meta-comment on this draft, or alternatively a proposal for a different draft. >> >> I'm sure a lot of you have heard Scott Shenker's talk "The future of >> network and the past of protocols", in which he makes the case for SDN. >> >> His basic tenet is that computer science has perfected methods for >> implementing software very quickly while protocols take a tremendously long time to design, perfect, and implement. >> So, he concludes, throw out protocols and run everything on a centralized server. >> >> Putting aside the obvious fact that he overlooks that protocols >> between multiple network elements need to be standardized so that >> every implementation can interwork with every other one (while an algorithm running on a single CPU doesn't require standardization), he makes a good point. >> >> A lot of the speed of programming comes from use of "abstractions". >> If every time one coded an app for a smartphone one needed to return >> to opcodes and bits, then it would indeed be a lengthy error-prone process. >> But instead programmers stand on the shoulders of those who came before them. >> >> It works something like this. Say someone solves some problem. >> The solution is initially made into a routine or function that can be open-sourced and reused. No-one need write that routine again. >> If the solution is really successful it can be made into a library with various initializations and options that can be loaded when needed. >> You needn't know how the library works, and if someone comes up with a better implementation it can refactored without the programmer knowing about it. >> If it becomes even more successful it can be turned into an object that can be inherited and extended and even changed without looking at the source code. >> If it is wildly successful, the functionality becomes part of the next generation of programming languages, and everyone has access to it without giving it any thought. >> >> The SDN theorists claim that networking has no abstractions (or at >> least that they don't know of any), and suggest a very strong abstraction - the "whitebox" switch (which can be any network element - an Ethernet bridge, an IP router, a firewall, etc). >> >> That jump in logic aside, they have a point. Every time we design a protocol we go back to the basics. >> We usually make a bit diagram (in ASCII art no less). We don't >> formally inherit functionality expect by riding over an existing protocol (e.g., running a protocol over TCP can give it reliability). >> >> As a concrete example, we often obtain protocol extensibility by utilizing TLVs. >> Now, the designers of LDP came up with a nice idea to handle the case of an implementation not knowing a particular type - the U bit. >> If the U bit is set it signifies that this unknown type can be gracefully ignored. Otherwise an error message must be returned. >> Were we to work like computer scientists, once this idea was implemented it should be automatically inherited by every future protocol using TLVs. >> Automatically. Not - if you heard about it put a U bit into your bit diagram. >> >> A while back the IEEE 802 people tried doing something like this when they design the Generic Attribute Registration Protocol. >> GVRP and GMRP inherited it, but nothing else. >> >> What can we do in the IETF to turn our ideas into abstractions that are inherited? >> >> Y(J)S >> >> _______________________________________________ >> Architecture-discuss mailing list >> Architecture-discuss@ietf.org >> https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww >> .ietf.org%2Fmailman%2Flistinfo%2Farchitecture-discuss&data=01%7C01%7Cy >> aakov_s%40rad.com%7C969c4364bef04d6c64d408d5bba84a55%7Cf9047108cc2c4e4 >> 897a343fad1b3bf9d%7C1&sdata=JI768aSLAPEM97h98bmfmDEwfwsU%2BdyC3R7Z9yJl >> 9Ho%3D&reserved=0 >> From nobody Fri May 18 18:53:14 2018 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 9FB8C1250B8 for ; Fri, 18 May 2018 18:53:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 hlPUg3_tiEed for ; Fri, 18 May 2018 18:53:09 -0700 (PDT) Received: from mail-pl0-x22b.google.com (mail-pl0-x22b.google.com [IPv6:2607:f8b0:400e:c01::22b]) (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 52BB8124C27 for ; Fri, 18 May 2018 18:53:09 -0700 (PDT) Received: by mail-pl0-x22b.google.com with SMTP id t12-v6so5550375plo.7 for ; Fri, 18 May 2018 18:53:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=1MSVwGYjscuWipUijFAuIuseQ+EYB5mWAlqOvDB5EX8=; b=ld3Ke9/eEqMxO3YeKk2ErNXVu6okHkz44MKXZGs1nlZz/Iyk2aK3FYAD6ErFhghiBx S/z6nLzpTpqKkFcKP/4XYn6oPB0NBcotbKDw2inF7IA1fNElbjABo/d/S8nPzhseRpYD 88auI1HgHz088T2CbRgz1XphSZrCMevyfbbl6/yt5oXW74XhzWU1o/zS5bLr7vKCckWJ Htg3BejVWcHY3530OuaefDujjT+LVJu6/dBVNvROaJKo3PLJ84XJg/NWbiY83a0QCn/J Rd/yRMkjDhIuEgpPzZ+exJr2V/rl8S03ow70t/HfvnGzJOx9MnX8hMwcEx8dK9yrbita BA9g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:to:cc:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=1MSVwGYjscuWipUijFAuIuseQ+EYB5mWAlqOvDB5EX8=; b=ZsaecihJllBnHwuD80iQKkUQG9rrOtsgxwk+qtl8eAq1+9GUOiZRXGloXKaPT9t20l fzpYBdFtOWcyR0mOoczD4o29vBwXqKHoCk6kaXDZyS9KIcG6rILy+bAUNnzpXWLm7mt9 gQSJAur2in0gfg/C+DTWCFIR+7Jsn/MGqDSUyqWlKU1PbmnWPUGD/M0JQeG95Uf+FMje lRODElcxbXcaSFt2b3bPA+yGhZSopGnsFyiwFf5GyBtZqnIybqAEKvyKpJKqoGZXrhFG s9GsDg+3aYWUajROO+IbuIrM9nUqJYHrYSreblY9IjGLlGfAFLdM31dqwBYxO8C7kTz2 8T3w== X-Gm-Message-State: ALKqPwesVYN2WGYZjrdQ2F3amXVmvfwbT3tHE/x3S9BghKG66cFiPY6q NvOQfv0zjcyDSBx5tn0bPQX3Hw== X-Google-Smtp-Source: AB8JxZqcz7TsKGvHcAnI2eSfU1/Hyrne2RDhCmrD6AJQFYtrMt4sliZ4EMhWy6JPg2uK+TO5u/LWDQ== X-Received: by 2002:a17:902:b692:: with SMTP id c18-v6mr11616804pls.307.1526694788496; Fri, 18 May 2018 18:53:08 -0700 (PDT) Received: from [192.168.178.21] ([118.148.121.80]) by smtp.gmail.com with ESMTPSA id b81-v6sm14890479pfj.56.2018.05.18.18.53.05 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 18 May 2018 18:53:07 -0700 (PDT) Sender: Brian Carpenter To: Martin Thomson Cc: architecture-discuss@ietf.org References: <152538075241.4552.6760702690778529507@ietfa.amsl.com> From: Brian E Carpenter Message-ID: Date: Sat, 19 May 2018 13:53:14 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [arch-d] I-D Action: draft-iab-protocol-maintenance-00.txt X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.22 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, 19 May 2018 01:53:13 -0000 Martin, Comments in line... On 11/05/2018 19:48, Martin Thomson wrote: > Hi Brian, > > Thanks for your note. This is a very valuable contribution. I suspect > that we might have a fundamental disagreement, but it's definitely worth > exploring the issues you raise a little more. > > Firstly, this draft was intended to be a comprehensive rebuttal of Postel's > principle. The tone is intentional, largely as a means of reinforcing the > message that the robustness principle does more harm than good. It's a big > idea, and pervasive, and I believe that a strong response is justified. > There are almost certainly ways in which that could be softened, but I'm > not in favour of changing the underlying message in the ways you suggest. Clearly you're entitled to that view. But equally clearly it can't become a view promulgated by the IAB without a wide debate. (RFC1958 was signed by the IAB *and* IESG and was openly discussed on ietf@ietf.org, so it's clear that any significant update deserves the same.) If we don't hear from other voices here, that isn't OK. > It's possible that our disagreement stems from a disconnect regarding the > scope of the application of the robustness principle. I think that the > "When in doubt" part clearly limits its applicability to situations where > there is insufficient or unclear specification. It seems like you might > have a broader notion of the idea. It might pay to push on that notion a > little. I've done a little of that below. I think there are several aspects. #1. The robustness principle should indirectly guide protocol design. Firstly there should be no unspecified parts of any PDU. Secondly, there should be no unspecified responses to any valid or invalid parts of any PDU. If you do that correctly, the robustness principle isn't needed in any implementation. But we know that in real life either specifications are imperfect, or implementations are imperfect, or both. Therefore: #2. Test or reference implementations should verify that all parts of all PDUs are valid. Invalid items should be logged and reported. (Whether test implementations should also generate invalid PDUs in order to test the other end is a separate question.) I hope we agree so far. Then we get to: #3. Production implementations should ... where we apparently disagree. The fact is that production implementations have to make the best of what they are given, which is typically a mixture of design errors in the protocol and implementation errors in other implementations. What is an implementer going to do except tolerate and recover from errors? Users expect apps to work, whatever happens. So that's what implementers will do, regardless of RFCs. The only thing that's changed since the robustness principle was formulated is that there are thousands of times more users and they are less tolerant than ever of failure modes. > I've staged a few changes to the document based on your feedback. There > are definitely a few places where the emphasis was wrong (and an outright > mistake on my part). Others separately made points about extensibility, > which suggests that it wasn't paid sufficient attention. Preview here: > > https://martinthomson.github.io/postel-was-wrong/implementation-robustness/draft-iab-protocol-maintenance.html That's 404, unfortunately. Synch problem?? > > Of course I don't consider this to be the end of the discussion. More > inline. > > On Thu, May 10, 2018 at 12:05 PM Brian E Carpenter < > brian.e.carpenter@gmail.com> wrote: >> How about >> "Some Unintended Consequences of the Robustness Principle" >> or even >> "When to Apply the Robustness Principle"? > > This would be a mistake, I think. The answer to the question is in my > opinion: "as little as possible, ideally never". Again: your opinion under your name is fine. But under the IAB's name I expect a community view. I know there's no IETF consensus rule for the IAB, but this sort of topic really does need some level of consensus, as we did for RFC1958 and, iirc, was done for RFC3439 (not even an IAB document), RFC5218 and the like. >> Interestingly, a poster child for extensibility problems >> in that RFC is TLS, the first problem case mentioned in the >> present draft. > > I'm familiar with the many of the ways in which TLS has failed over the > years. As you say, it has long history of being a bad example. > Separately, my hope is that it can now be the source of a few good examples > in addition to the many bad ones. > > I personally attribute the bad examples to its age, plus the extended > period of relative neglect it saw. In many ways, the protocol hasn't had > any significant maintenance until recently, when we started work on TLS > 1.3. TLS 1.2 is fundamentally the same protocol as SSL 3. And also it didn't even start out as an IETF consensus proposal. >>> It has turned out that many SSLv3 and TLS implementations that do not >>> support TLS extensions did not ignore the unknown extensions, as >>> required by the protocol specifications, but instead failed to >>> establish connections. Since several of the implementations behaving >>> in this manner are used by high-profile Internet sites, such as >>> online banking sites, this has caused a significant delay in the >>> deployment of clients supporting TLS extensions, and several of the >>> clients that have enabled support are using heuristics that allow >>> them to disable the functionality when they detect a problem. > >> In this case, heuristics are needed to get round implementations >> that don't respect the robustness principle. > > That's a conclusion I might have once agreed to, but that was before I > started working on TLS. > > The extension mechanism in TLS relied on a hole in the original > specification of SSL 3. So yes, the robustness principle was applied and > it was in fact critical in enabling extensions. TLS extensions rely on SSL > 3 implementations consistently applying the robustness principle when > dealing with the inner and outer length of the ClientHello message. Then, > when it was clear that some implementations were stricter in their parsing, > the principle was again used in applying heuristics to work around the > problem. In this case, the short term impact was interoperation. Of > course, those were undocumented workarounds which made it hard to build an > interoperable client, but that's a minor drawback in the grand scheme. > > The long term effect was devastating. The most common technique clients > used to work around extension intolerance was to make another connection > without extensions. Some clients still include the code that does that, > and it has since been repurposed many times to work around other forms of > server intolerance. One of the consequences of that has been that certain > classes of errors have been tolerated for many years. Clients could be > relied on to try again with a different configuration, so there is less > pressure on servers to implement features correctly. This added > significant delays to the deployment of new TLS versions, and was a huge > problem in the design of TLS 1.3. > > Once particularly nasty consequence was the application of this retry to > version intolerance. That is, there was a strong tendency of servers to > fail to connect if a client offered a newer protocol version. For example, > we saw astonishingly high rates of intolerance to TLS 1.3 before the > version negotiation mechanism there was redesigned. Some tests saw around > 20% failure rates. That resulted in TLS - as deployed - being vulnerable > to a range of trivial downgrade attacks, some of which are listed in RFC > 7457. Yes. But all of this seems to be due to weak design in SSL; blame that, not the subsequent 3rd party efforts to fix that design, as the root cause. >> In general I think the present draft doesn't pay enough >> attention to extensions, which are after all the second >> main reason for maintaining protocols, along with bug fixes. > > This is a fair criticism. We might draw different conclusions here, but > here's my take, which expands on the text that I've staged. > > Regarding extensibility as the application of the robustness principle is a > mistake. There are examples, such as with TLS, where extensibility was > added to a protocol by relying on the tolerance of implementations to > unexpected inputs. However, this is a poor strategy for extensibility. > That particular case went disastrously, as RFC 6709 explains. I agree. That's why I believe we should have discussed the robustness principle in RFC6709, to point out that it is not intended to replace proper design for extensibility. A lot of protocols do specify the behaviour for unknown extensions, but it can still be problematic (see RFC7045 and RFC7872, for example). > Planning for new uses of a protocol means laying down expectations for what > implementations will do when presented with unspecified inputs. We agree violently on that. > Your MBZ bit example is a nice demonstration of how that works: you specify > semantics for zero (do what this specification says), explicitly decline to > define semantics for one, and then say two things that hopefully make it > possible to start using one in future: "don't send one unless you know what > it means" (an obvious thing really, but somehow still necessary), and the > more important "if you don't know what one means, don't change your > behaviour". > > There are also alternatives like "if you don't know what one means, ignore > this much of the message" and "generate an error of the following type", > but examples like the M bit in L2TP or the critical extensions in X.509 > show that these options are chosen less often. > > Critically, none of this results in any doubt about what to do. So the > recipient never has cause to contemplate the advice in "When in doubt, > discard faulty input silently, [...]". > > There is still room for doubt even with a good design unfortunately, but > that's the subject of a different draft, which you can read here: > https://martinthomson.github.io/use-it-or-lose-it/draft-thomson-use-it-or-lose-it.html Yes, that's all good stuff. >>> 5. Active Protocol Maintenance >>> >>> The robustness principle is best suited to safeguarding against flaws >>> in a specification that is intended to remain unchanged for an >>> extended period of time. > >> I don't think that's true. > > I agree. With the perspective you add, it's clear that this is not a good > formulation. The edit that I shared above is an attempt a fixing this. > >> Firstly, very few people publish protocol >> designs that they intend to be updated after a short period of time. >> I'd argue that at the time of publication, all designs are intended >> to remain unchanged indefinitely. > > I disagree with this. This is not the stance I've seen - at least in the > groups I've been participating in. Fair enough. It does indeed depend on the experience of the designers involved. With experience, we all learn that change is inevitable. s/all designs/some designs/ would be more accurate. > There, the recognition that the > combination of an imperfect specification and the vicissitudes of time mean > that there is never any expectation that the protocol will be viable in > perpetuity. Yes, the intent is to provide something that is fit for > purpose, which means deployment lifetimes measured in years, but that never > means forever. For the gap between specification and perfection, there is > the responsibility to tend to the ecosystem. > > QUIC might have over-rotated here, I'll admit. There's talk of shipping > two versions on day 1, or having version 2 within a period as short as 6 > months. But we had the same discussions with HTTP/2 and we while QUIC > means less pressure to start on HTTP/3, it's still been a while now. > >> Secondly, I always understood that >> the robustness principle was primarily a safeguard against flaws >> in *implementations*. > > Yes, that's the mistake here. I agree. > >> If we *expect* a protocol to be extended by adding options or message >> types, the robustness principle leads to very different text, like: > >>> If an unrecognized MESSAGE_TYPE is received in a unicast message, an >>> Invalid message (Section 2.8.12) MAY be returned. Otherwise the >>> message MAY be logged and MUST be discarded. If an unrecognized >>> MESSAGE_TYPE is received in a multicast message, it MAY be logged and >>> MUST be silently discarded. > >> In this case the Postel principle allows nodes that support different >> but overlapping sets of message types to communicate robustly. That's >> not a problem; it's a solution. > > As I said above, if the extensibility is well-defined (invoke 6709!), then > the robustness principle never gets to play. Yes, that's how I see it too (except when there are faulty implementations). > > I couldn't pick out this example easily, so without knowing the > expectations around the handling of Invalid messages, I don't know if this > is indeed a case where robustness would help. That said, if it would, then > I would say that the specification needs to be improved rather than advice > reliance on robustness. FYI, the protocol's already in the RFC queue: https://datatracker.ietf.org/doc/draft-ietf-anima-grasp/ We believe its extension mechanism will work, but your point about exercising it is a good one. >> (As TLS shows, this approach may not be acceptable for a security >> protocol where downgrade attacks are a problem. But that's a subset >> of all protocols.) > > People often point at TLS and say "oh, that's special", but I don't think > that's accurate at all. At least not any more. The bulk of TLS is fairly > mundane protocol engineering, with lessons that apply to many other > protocols. Hence it being the perennial poster child. Of course, that's > more true now than it was historically, so the misconception is > understandable. Fair enough, but downgrade attacks are mainly a problem for security protocols, I think. Using an older version is normally benign for applications, except for missing features. >> I think the draft in its present unbalanced form is misleading. >> A balanced discussion of when the Postel principle is useful, >> and when it's harmful, would be more what I'd expect from the IAB. > > My apologies, but that made me think "Fair and balanced," which I'm sure > was not at all your intent :) No. But I still like "When to Apply the Robustness Principle", or if you prefer "When Not to Apply the Robustness Principle". > In any case, if we disagree here, I think that's OK. However, my hope is > that discussing the point about the scope of the statement will help. Yes, and that's why I don't think the document title should be hard over. Regards Brian From nobody Sat May 19 08:34:11 2018 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 8391312D951 for ; Sat, 19 May 2018 08:34:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 eR5P3NB-LoMN for ; Sat, 19 May 2018 08:34:07 -0700 (PDT) Received: from mx43-out1.antispamcloud.com (mx43-out1.antispamcloud.com [138.201.61.189]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8914812D945 for ; Sat, 19 May 2018 08:34:07 -0700 (PDT) Received: from xsmtp06.mail2web.com ([168.144.250.232]) by mx37.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.89) (envelope-from ) id 1fK3rv-00084u-8Z for architecture-discuss@ietf.org; Sat, 19 May 2018 17:34:04 +0200 Received: from [10.5.2.31] (helo=xmail09.myhosting.com) by xsmtp06.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1fK3rp-0001Ec-RN for architecture-discuss@ietf.org; Sat, 19 May 2018 11:33:59 -0400 Received: (qmail 5335 invoked from network); 19 May 2018 15:33:55 -0000 Received: from unknown (HELO [192.168.1.103]) (Authenticated-user:_huitema@huitema.net@[172.56.42.66]) (envelope-sender ) by xmail09.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 19 May 2018 15:33:55 -0000 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Christian Huitema X-Mailer: iPhone Mail (15E302) In-Reply-To: Date: Sat, 19 May 2018 08:33:52 -0700 Cc: Martin Thomson , architecture-discuss@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <152538075241.4552.6760702690778529507@ietfa.amsl.com> To: Brian E Carpenter X-Originating-IP: 168.144.250.232 X-AntiSpamCloud-Domain: xsmtpout.mail2web.com X-AntiSpamCloud-Username: 168.144.250.0/24 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com X-AntiSpamCloud-Outgoing-Class: unsure X-AntiSpamCloud-Outgoing-Evidence: Combined (0.28) X-Recommended-Action: accept X-Filter-ID: EX5BVjFpneJeBchSMxfU5qoTmthm3mWtlUnVYXE4xC5602E9L7XzfQH6nu9C/Fh9KJzpNe6xgvOx q3u0UDjvO+3YL77OvPxouGQ1xMm1oSy+p7nQ/m1z/T26qK1vx/ktbNbo7palBZjCExzO+3olYjCg WxzONQQ0ePHvgDRXJPPO4k7ydv2Rs1VgfbHBQGgnSBWlL1zfgiPkRstzHteqQdXNRT855i79d4tT S+Wl2h8f0wQn+qGFwFhnrZWr3AIw/crUMSB3/ZTeY4yyWjyvJUSUj3/0l2xJw0rGpf82c3OJ/VWX a+0QBQ+ZkcKKFGIcDD2gT2inkFvv0JWjnb/IrJf6jJtPGaYptgB1ChFr0Ohv21n4LnI5zZgAaRoQ /U07baxQrmdDZMJ0s9i7rqNbvbnr7jXzNR45DRBcGqXviIDXs2KsRjKrCowEavDwQuKo6VTIajXH Y4aCJYKyswb405nckpWaLvahyBjmQxBKOzsnNZ6tILGOfNglqio4kQd7pMsJmbYg5MneJhAYyRhh CYGsG5ZWx5PsclCqKTOq3CgmkF/5SF3EVraG1YhoPX6VNZqCufrpkAH3VB2oMrzlWPCg9K7VkSDb tWwFyseTwFLZ389CO9Uzva25oyTDMNHuc9R0JKI/o475sN1EN2Xsba/u/44OujV1KIniKSyCYqyF e4T7wQ6YA5gvl1zvcLOaknW1q5pTKqaAtnVVwskgFYuW2VxLnS94njDgTNmyTXFWBO7QqsqSOVl9 KloeGECwAPh4Fqwd4Jrn9OwTTVxw826/CrNEqgqUViIlzLTqPP6SPI51OLWixpQPK5w/G1y12BDR xB3Xx+FirTp5EI71EUCh2Oh/sEgqFb8L6rsww4gBYKmy7DAUtwkrtE2FvyjzmHbm/2FP3B+uEIkw J0Q5gCjBRB0t/r7fzY7HnTQ5j8Py3deP8vNnmz84mDUvZqxnB1hYVULyg3fWh5tbcz2mAZ8cnCTk Cpq77TlC9Y6rgjH3eR5zIpOIm00VR4vLLm1t X-Report-Abuse-To: spam@quarantine6.antispamcloud.com Archived-At: Subject: Re: [arch-d] I-D Action: draft-iab-protocol-maintenance-00.txt X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.22 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, 19 May 2018 15:34:10 -0000 > On May 18, 2018, at 6:53 PM, Brian E Carpenter wrote: ... >=20 > #3. Production implementations should ... >=20 > where we apparently disagree. The fact is that production > implementations have to make the best of what they are given, > which is typically a mixture of design errors in the protocol > and implementation errors in other implementations. What is > an implementer going to do except tolerate and recover from > errors? Users expect apps to work, whatever happens. So that's > what implementers will do, regardless of RFCs. The only thing > that's changed since the robustness principle was formulated > is that there are thousands of times more users and they are less > tolerant than ever of failure modes. That's indeed the core of the debate. On one hand, tolerance maximizes inter= operability in the short term. On the other hand, intolerance causes product= ion applications to work as the "protocol police". This harnesses network ef= fects to block unsanctioned extensions. Martin's argument is that this leads= to a healthier ecosystem. Brian's proposal place the burden of maintaining this healthy environment on= reference implementations and test suites. That's probably the weakest part= of his argument. Experience shows that offline tests have no teeth. My worry with "policing in production" is that it places a lot of power in t= he dominant implementations, and can lead to big barriers of entry for compe= ting new implementations. We sort of see that today in the browser market. And then there is ossification. Each of the approaches carries its own risks= . -- Christian Huitema=20= From nobody Sat May 19 09:49:23 2018 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 ED3BC12DA13 for ; Sat, 19 May 2018 09:49:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 HHG3UwmWQ95S for ; Sat, 19 May 2018 09:49:18 -0700 (PDT) Received: from mail-vk0-x232.google.com (mail-vk0-x232.google.com [IPv6:2607:f8b0:400c:c05::232]) (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 A056512DA0C for ; Sat, 19 May 2018 09:49:18 -0700 (PDT) Received: by mail-vk0-x232.google.com with SMTP id 131-v6so6630982vkf.8 for ; Sat, 19 May 2018 09:49:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=wOZ0XCTUIuFwM6SE8Zup/qii7EzIzCQib20CCcnF8yY=; b=uB1k8VOP8S6zjp2Fo7PwciYeu7kxB1ThvEQ3CAwMhIeKFlw6u0TYc9UzmlDtBBHDtX BtgP1R3lJVLjYMhPBLVTT7jng+1e4UhGyFzJIuoCUTVRCpIB+8c3ukISYUfMVppI/UD4 968lk28NdQblrPLdPpPGhZES5eDbi5T1CmLjwbLQG/PYvKnVPh8JOsnsmvS99GmH9ht+ 1Pty21MuV3C6PTqJXgM4q872S3KBG5khYW1KgrWKxW3uoM1vBB3csaguarC30xvHmrkS 0FcA9Lwn0cmFacp4FSlaJXt6pvog2LWuWjwMiX/Lu/7qbcGBkl6AAAcG6O7QzYd21jsp +DIg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=wOZ0XCTUIuFwM6SE8Zup/qii7EzIzCQib20CCcnF8yY=; b=OqTssSdlb0NfB164llIWt8KrTUdKHTkvuGyA+PL3L6L7gaFouM33HwpMB2JolGOqX+ P07Vbc2W8viJukcySbKBSz413LgqN/tIlzM308MBMr4KXN27i1qQvL2GQlj8Mx6YKKJ6 W3IDd/qpDtfwTEDwWingdM4zdkJfu6nGpPOgFbmYsApYk4v2hosqD0EZVThk5qeMqHD4 8YzACq3fTV2sTLCX/21P1Vb0+qruoaCYBYYPfJERrcyc5rF5RA/QLC07SFcCIsd80nT0 klygksRBHKnuwRT/QgnZHvRu3RCHwolGWb3oagxmKMbubSjsXA9Z2p5cH2OFU14GIkAg R+Dg== X-Gm-Message-State: ALKqPwcB8ceCWdslKTPB5HibxjmAgDy12B3HN7eapRyIXYzTToGN+cdg GW+pYZ+1YqeMkbyIySQYquCzz6EKueYRmiJik80= X-Google-Smtp-Source: AB8JxZr3aakKkrVKxCNntJhDHQ5EypU9k3HuMiukjiUDH4YsH6aPfWoa7HVJv94R7jrKh3rsRhTPJ96xMoPyA6GkZV0= X-Received: by 2002:a1f:304:: with SMTP id 4-v6mr10222432vkd.120.1526748557309; Sat, 19 May 2018 09:49:17 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a9f:32c1:0:0:0:0:0 with HTTP; Sat, 19 May 2018 09:48:56 -0700 (PDT) In-Reply-To: References: <152538075241.4552.6760702690778529507@ietfa.amsl.com> From: Bernard Aboba Date: Sat, 19 May 2018 09:48:56 -0700 Message-ID: To: Martin Thomson Cc: architecture-discuss@ietf.org Content-Type: multipart/alternative; boundary="0000000000006b8329056c91d908" Archived-At: Subject: Re: [arch-d] I-D Action: draft-iab-protocol-maintenance-00.txt X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.22 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, 19 May 2018 16:49:22 -0000 --0000000000006b8329056c91d908 Content-Type: text/plain; charset="UTF-8" Martin -- While the document largely focuses on implementation flaws or differences in interpretation, I would suggest that the arguments could be made stronger by consideration of non-conformance more severe than Jon Postel's maxim was intended to address - the deployment of implementations so far removed from the standard that they constitute "protocol dialects" or "uncoordinated protocol development". In the face of such a large scale deviation from the standard, "liberal in what you accept" implies development and maintenance of multiple code paths. This can be highly burdensome not just for development but also for testing, particularly if the dialects are undocumented or poorly documented. One example that comes to mind was the mass self-allocation of standards-space RADIUS code points by Ascend during the 1990s, establishing a widely deployed proprietary and non-interoperable variant of RADIUS. Today, more than 20 years after Ascend shipped their RADIUS dialect, the IETF has still not completed the task of fully documenting (as informational RFCs) all aspects of Ascend's RADIUS dialect. The "dialect" problem has been particularly prevalent in Web standards over the years, so that could also provide a rich set of examples. The IAB has in the past recognized the harm caused by protocol dialects. While RFC 5407 "Uncoordinated Protocol Development Considered Harmful" focuses on lack of coordination between SDOs, the arguments are equally valid if applied to vendor "dialects": The uncoordinated adaptation of a protocol, parameter, or code-point ... either through the allocation of a code-point without following the formal registration procedures or by unilaterally modifying the semantics of the protocol or intended use of the code-point itself, poses a risk of harm to the Internet [RFC4775 ]. Nowhere in RFC 5407 is Postel's maxim mentioned - which I interpret as a recognition that it does not apply to these situations. On Wed, May 9, 2018 at 7:05 PM, Brian E Carpenter < brian.e.carpenter@gmail.com> wrote: > Hi, > > I have very mixed feelings about this draft. > > Firstly, let me clarify that although I was the editor of > RFC 1958, the wording about the robustness principle was either > drafted by or wordsmithed by Jon Postel himself. > > That being said, it isn't sacred. But the present draft uses > language that describes it as a failure, which is far from true. > Before this becomes a community document, IMHO the tone *really* > needs to change, starting with the title. How about > "Some Unintended Consequences of the Robustness Principle" > or even > "When to Apply the Robustness Principle"? > > I regret that we didn't discuss this topic in RFC 6709 > ("Design Considerations for Protocol Extensions"). > Interestingly, a poster child for extensibility problems > in that RFC is TLS, the first problem case mentioned in the > present draft. Just read this extract: > > > It has turned out that many SSLv3 and TLS implementations that do not > > support TLS extensions did not ignore the unknown extensions, as > > required by the protocol specifications, but instead failed to > > establish connections. Since several of the implementations behaving > > in this manner are used by high-profile Internet sites, such as > > online banking sites, this has caused a significant delay in the > > deployment of clients supporting TLS extensions, and several of the > > clients that have enabled support are using heuristics that allow > > them to disable the functionality when they detect a problem. > > In this case, heuristics are needed to get round implementations > that don't respect the robustness principle. > > In general I think the present draft doesn't pay enough > attention to extensions, which are after all the second > main reason for maintaining protocols, along with bug fixes. > > The draft is seriously unbalanced, it seems to me, by not > containing an explicit description of the benefits of the > robustness principle and of cases where it is necessary. > Frankly I am surprised to see it as an IAB draft in its > current state. > > > 5. Active Protocol Maintenance > > > > The robustness principle is best suited to safeguarding against flaws > > in a specification that is intended to remain unchanged for an > > extended period of time. > > I don't think that's true. Firstly, very few people publish protocol > designs that they intend to be updated after a short period of time. > I'd argue that at the time of publication, all designs are intended > to remain unchanged indefinitely. Secondly, I always understood that > the robustness principle was primarily a safeguard against flaws > in *implementations*. That's why we normally specify MBZ bits as > MUST be zero on transmission and MUST be ignored on reception, etc. > > If we *expect* a protocol to be extended by adding options or message > types, the robustness principle leads to very different text, like: > > > If an unrecognized MESSAGE_TYPE is received in a unicast message, an > > Invalid message (Section 2.8.12) MAY be returned. Otherwise the > > message MAY be logged and MUST be discarded. If an unrecognized > > MESSAGE_TYPE is received in a multicast message, it MAY be logged and > > MUST be silently discarded. > > In this case the Postel principle allows nodes that support different > but overlapping sets of message types to communicate robustly. That's > not a problem; it's a solution. > > (As TLS shows, this approach may not be acceptable for a security > protocol where downgrade attacks are a problem. But that's a subset > of all protocols.) > > I think the draft in its present unbalanced form is misleading. > A balanced discussion of when the Postel principle is useful, > and when it's harmful, would be more what I'd expect from the IAB. > > Brian > > > _______________________________________________ > Architecture-discuss mailing list > Architecture-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/architecture-discuss > --0000000000006b8329056c91d908 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Martin --

While the document= largely focuses on implementation flaws or differences in interpretation, = I would suggest that the arguments could be made stronger by consideration = of non-conformance more severe than Jon Postel's maxim was intended to = address - the deployment of implementations so far removed from the standar= d that they constitute "protocol dialects" or "uncoordinated= protocol development".=C2=A0=C2=A0=C2= =A0In the face of such a large scale deviation from the standard, &q= uot;liberal in what you accept" implies development and maintenance of= multiple code paths. This can be highly burdensome not just for developmen= t but also for testing, particularly if the dialects are undocumented or po= orly documented.=C2=A0

One example that com= es to mind was the mass self-allocation of standards-space RADIUS code poin= ts by Ascend during the 1990s, establishing a widely deployed proprietary a= nd non-interoperable variant of RADIUS. Today, more than 20 years after Asc= end shipped their RADIUS dialect, the IETF has still not completed the task= of fully documenting (as informational RFCs) all aspects of Ascend's R= ADIUS dialect.=C2=A0 The "dialect" problem has been particularly = prevalent in Web standards over the years, so that could also provide a ric= h set of examples.=C2=A0

The IAB has in the past r= ecognized the harm caused by protocol dialects.=C2=A0 While RFC 5407 "= Uncoordinated Protocol Development Considered Harmful" focuses on lack= of coordination between SDOs, the arguments are equally valid if applied t= o vendor "dialects":=C2=A0


   The uncoordinated adaptation of a protocol, parameter=
, or code-point
   ... either through the allocation of a code-point without following the<=
/pre>
  =
 formal registration procedures or by unilaterally modifying the semantics<=
/pre>
  =
 of the protocol or intended use of the code-point itself, poses a risk of<=
/pre>
  =
 harm to the Internet [RFC4775].

<=
br>

Nowhere in RFC 5407 is Postel&#= 39;s maxim mentioned - which I interpret as a recognition that it does not = apply to these situations.=C2=A0

On Wed, May 9, 2018 at 7:05 PM, Brian E Carpenter &l= t;brian.e.= carpenter@gmail.com> wrote:
Hi,

I have very mixed feelings about this draft.

Firstly, let me clarify that although I was the editor of
RFC 1958, the wording about the robustness principle was either
drafted by or wordsmithed by Jon Postel himself.

That being said, it isn't sacred. But the present draft uses
language that describes it as a failure, which is far from true.
Before this becomes a community document, IMHO the tone *really*
needs to change, starting with the title. How about
"Some Unintended Consequences of the Robustness Principle"
or even
"When to Apply the Robustness Principle"?

I regret that we didn't discuss this topic in RFC 6709
("Design Considerations for Protocol Extensions").
Interestingly, a poster child for extensibility problems
in that RFC is TLS, the first problem case mentioned in the
present draft. Just read this extract:

> It has turned out that many SSLv3 and TLS implementations that do not<= br> > support TLS extensions did not ignore the unknown extensions, as
> required by the protocol specifications, but instead failed to
> establish connections.=C2=A0 Since several of the implementations beha= ving
> in this manner are used by high-profile Internet sites, such as
> online banking sites, this has caused a significant delay in the
> deployment of clients supporting TLS extensions, and several of the > clients that have enabled support are using heuristics that allow
> them to disable the functionality when they detect a problem.

In this case, heuristics are needed to get round implementations
that don't respect the robustness principle.

In general I think the present draft doesn't pay enough
attention to extensions, which are after all the second
main reason for maintaining protocols, along with bug fixes.

The draft is seriously unbalanced, it seems to me, by not
containing an explicit description of the benefits of the
robustness principle and of cases where it is necessary.
Frankly I am surprised to see it as an IAB draft in its
current state.

> 5.=C2=A0 Active Protocol Maintenance
>
>=C2=A0 =C2=A0 The robustness principle is best suited to safeguarding a= gainst flaws
>=C2=A0 =C2=A0 in a specification that is intended to remain unchanged f= or an
>=C2=A0 =C2=A0 extended period of time.

I don't think that's true. Firstly, very few people publish protoco= l
designs that they intend to be updated after a short period of time.
I'd argue that at the time of publication, all designs are intended
to remain unchanged indefinitely. Secondly, I always understood that
the robustness principle was primarily a safeguard against flaws
in *implementations*. That's why we normally specify MBZ bits as
MUST be zero on transmission and MUST be ignored on reception, etc.

If we *expect* a protocol to be extended by adding options or message
types, the robustness principle leads to very different text, like:

> If an unrecognized MESSAGE_TYPE is received in a unicast message, an > Invalid message (Section 2.8.12) MAY be returned.=C2=A0 Otherwise the<= br> > message MAY be logged and MUST be discarded.=C2=A0 If an unrecognized<= br> > MESSAGE_TYPE is received in a multicast message, it MAY be logged and<= br> > MUST be silently discarded.

In this case the Postel principle allows nodes that support different
but overlapping sets of message types to communicate robustly. That's not a problem; it's a solution.

(As TLS shows, this approach may not be acceptable for a security
protocol where downgrade attacks are a problem. But that's a subset
of all protocols.)

I think the draft in its present unbalanced form is misleading.
A balanced discussion of when the Postel principle is useful,
and when it's harmful, would be more what I'd expect from the IAB.<= br>
=C2=A0 =C2=A0Brian


_______________________________________________
Architecture-discuss mailing list
Architecture-discuss@ietf.= org
https://www.ietf.org/mailman/listinf= o/architecture-discuss

--0000000000006b8329056c91d908-- From nobody Sat May 19 10:49:04 2018 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 CCA5212D86C for ; Sat, 19 May 2018 10:49:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.988 X-Spam-Level: X-Spam-Status: No, score=-1.988 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=strayalpha.com 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 MqC9uPDWRYDF for ; Sat, 19 May 2018 10:48:58 -0700 (PDT) Received: from server217-3.web-hosting.com (server217-3.web-hosting.com [198.54.115.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4FC9512DA15 for ; Sat, 19 May 2018 10:48:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=To:References:Message-Id:Cc:Date:In-Reply-To: From:Subject:Mime-Version:Content-Type:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=jCHTFH10ATa/eP6Q2pvxQ60rZQuKrikU83wn6+DLt74=; b=qbc2tW2OhUsvY73Yw145GI8Vi tRHPORSPCR7OTOr5OdvrHD4V29H8Qw8VrMLW/y4smWC9L50Tfq/GMUomcUyxlBH0o5RBj9FYP7nrQ 7uW2IC6g5VQBRfdejqxvpXLF/v8++N3KWZ1HvKyeq3jx65BobrpbRSvkRr0fX4kZEPxmqvNWG0tpx rTQxBvaxTg+eR86fCDsIxLi0aSq4UTmWTZbBraGROTBNnyWy10c69PjVDscbgcMZkFGdBUvGfG2PD aS9D/9PNH8NqH4UXeQ8oxmDSDaULZE7733rMpED24SE6wjdnCBQNkjzKPuxwEGiiS8hNmVORaOSsd 4xzHdKOjg==; Received: from cpe-172-250-240-132.socal.res.rr.com ([172.250.240.132]:65351 helo=[192.168.1.77]) by server217.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.91) (envelope-from ) id 1fK5yS-0035TR-2R; Sat, 19 May 2018 13:48:57 -0400 Content-Type: multipart/alternative; boundary="Apple-Mail=_7B644600-A78A-4D3D-8AB2-269EC2B867B0" Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) From: Joe Touch In-Reply-To: Date: Sat, 19 May 2018 10:48:55 -0700 Cc: Martin Thomson , architecture-discuss@ietf.org Message-Id: <7450EBEB-F32A-409D-B0DF-1A262B6DB556@strayalpha.com> References: <152538075241.4552.6760702690778529507@ietfa.amsl.com> To: Bernard Aboba X-Mailer: Apple Mail (2.3445.6.18) X-OutGoing-Spam-Status: No, score=-1.0 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server217.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - strayalpha.com X-Get-Message-Sender-Via: server217.web-hosting.com: authenticated_id: touch@strayalpha.com X-Authenticated-Sender: server217.web-hosting.com: touch@strayalpha.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Subject: Re: [arch-d] I-D Action: draft-iab-protocol-maintenance-00.txt X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.22 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, 19 May 2018 17:49:01 -0000 --Apple-Mail=_7B644600-A78A-4D3D-8AB2-269EC2B867B0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On May 19, 2018, at 9:48 AM, Bernard Aboba = wrote: >=20 > The IAB has in the past recognized the harm caused by protocol = dialects. While RFC 5407 "Uncoordinated Protocol Development Considered = Harmful" focuses on lack of coordination between SDOs, the arguments are = equally valid if applied to vendor "dialects":=20 >=20 >=20 > The uncoordinated adaptation of a protocol, parameter, or = code-point > ... either through the allocation of a code-point without following = the > formal registration procedures or by unilaterally modifying the = semantics > of the protocol or intended use of the code-point itself, poses a = risk of > harm to the Internet [RFC4775 = ]. >=20 >=20 > Nowhere in RFC 5407 is Postel's maxim mentioned - which I interpret as = a recognition that it does not apply to these situations.=20 >=20 I agree that adapting to such behavior is NOT an application of the = Postel principle. IMO, that principle applies to =E2=80=9Callowed but = unexpected=E2=80=9D behaviors, not behaviors that vary completely = outside the envelope of what is defined. Here=E2=80=99s an example, IMO: - (expected) TCP can optimize for packets arriving in order - (Postel principle - allowed but unexpected) TCP must always = accept packets out of order that arrive in-window - (outside envelope) TCP *must never* attempt to interpret = *any* information in packets arriving out of the window Put more directly, IMO, there are three principles that work *together* = (and that protocol designers and implementers confuse or ignore at their = peril): COMPLIANCE: 1) a protocol is defined not only by what it is, but by what it = is not frankly, that=E2=80=99s true for *any* definition=09 the rules of a protocol define what is =E2=80=9Callowed=E2= =80=9D and =E2=80=9Cnot allowed=E2=80=9D OPTIMIZATION: 2) protocols are often optimized for what is =E2=80=9Cexpected" - both sides must still avoid the =E2=80=9Cunallowed=E2=80= =9D, otherwise the protocol is undefined ROBUSTNESS: 3) the Postel principle recognizes that: - the sending side of a protocol should prefer to behave = as =E2=80=9Cexpected=E2=80=9D rather than =E2=80=9Cunexpected, but = allowed=E2=80=9D - the receiving side of a protocol should allow both = =E2=80=9Cexpected=E2=80=9D and =E2=80=9Cunexpected, but allowed=E2=80=9D Joe --Apple-Mail=_7B644600-A78A-4D3D-8AB2-269EC2B867B0 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On May 19, 2018, at 9:48 AM, Bernard Aboba <bernard.aboba@gmail.com> wrote:

The IAB has in the past recognized the harm caused by = protocol dialects.  While RFC 5407 "Uncoordinated Protocol = Development Considered Harmful" focuses on lack of coordination between = SDOs, the arguments are equally valid if applied to vendor = "dialects": 


   The =
uncoordinated adaptation of a protocol, parameter, or code-point
   ... either through the allocation of a code-point without following =
the
   formal =
registration procedures or by unilaterally modifying the =
semantics
   of the =
protocol or intended use of the code-point itself, poses a risk =
of
   harm to =
the Internet [RFC4775].


Nowhere in RFC 5407 is Postel's maxim mentioned - which I = interpret as a recognition that it does not apply to these = situations. 


I agree that adapting to = such behavior is NOT an application of the Postel principle. IMO, that = principle applies to =E2=80=9Callowed but unexpected=E2=80=9D behaviors, = not behaviors that vary completely outside the envelope of what is = defined.

Here=E2=80=99s an example, IMO:
- =  (expected) TCP can optimize for packets arriving in = order
- (Postel principle - allowed but = unexpected) TCP must always accept packets out of order that arrive = in-window
- (outside envelope)  TCP = *must never* attempt to interpret *any* information in packets arriving = out of the window

Put more directly, IMO, there are three principles that work = *together* (and that protocol designers and implementers confuse or = ignore at their peril):

= COMPLIANCE:
1) a protocol is defined not only = by what it is, but by what it is not
= frankly, that=E2=80=99s true for *any* definition =
the rules of a protocol = define what is =E2=80=9Callowed=E2=80=9D and =E2=80=9Cnot = allowed=E2=80=9D

= OPTIMIZATION:
2) protocols are often optimized = for what is =E2=80=9Cexpected"
- = both sides must still avoid the =E2=80=9Cunallowed=E2=80=9D, otherwise = the protocol is undefined

= ROBUSTNESS:
3) the Postel principle = recognizes that:
- the sending side of a = protocol should prefer to behave as =E2=80=9Cexpected=E2=80=9D rather = than =E2=80=9Cunexpected, but allowed=E2=80=9D
- = the receiving side of a protocol should allow both =E2=80=9Cexpected=E2=80= =9D and =E2=80=9Cunexpected, but allowed=E2=80=9D
Joe

= --Apple-Mail=_7B644600-A78A-4D3D-8AB2-269EC2B867B0-- From nobody Wed May 23 13:22:41 2018 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 E16AD12D7F6 for ; Wed, 23 May 2018 13:22:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=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 Oz44aVWfahBu for ; Wed, 23 May 2018 13:22:28 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E86B312D7E6 for ; Wed, 23 May 2018 13:22:27 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id A4268300A23 for ; Wed, 23 May 2018 16:22:25 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id TVS2Nb7uAqHm for ; Wed, 23 May 2018 16:22:24 -0400 (EDT) Received: from a860b60074bd.home (pool-108-45-101-150.washdc.fios.verizon.net [108.45.101.150]) by mail.smeinc.net (Postfix) with ESMTPSA id 5903330048E for ; Wed, 23 May 2018 16:22:24 -0400 (EDT) From: Russ Housley Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Wed, 23 May 2018 16:22:25 -0400 References: <152538075241.4552.6760702690778529507@ietfa.amsl.com> To: architecture-discuss@ietf.org In-Reply-To: Message-Id: <7E740995-3B63-4CE6-BC58-9DDC0F3BA07E@vigilsec.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [arch-d] I-D Action: draft-iab-protocol-maintenance-00.txt X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.22 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: Wed, 23 May 2018 20:22:39 -0000 > On May 19, 2018, at 11:33 AM, Christian Huitema = wrote: >=20 >> On May 18, 2018, at 6:53 PM, Brian E Carpenter = wrote: > .... >>=20 >> #3. Production implementations should ... >>=20 >> where we apparently disagree. The fact is that production >> implementations have to make the best of what they are given, >> which is typically a mixture of design errors in the protocol >> and implementation errors in other implementations. What is >> an implementer going to do except tolerate and recover from >> errors? Users expect apps to work, whatever happens. So that's >> what implementers will do, regardless of RFCs. The only thing >> that's changed since the robustness principle was formulated >> is that there are thousands of times more users and they are less >> tolerant than ever of failure modes. >=20 > That's indeed the core of the debate. On one hand, tolerance maximizes = interoperability in the short term. On the other hand, intolerance = causes production applications to work as the "protocol police". This = harnesses network effects to block unsanctioned extensions. Martin's = argument is that this leads to a healthier ecosystem. >=20 > Brian's proposal place the burden of maintaining this healthy = environment on reference implementations and test suites. That's = probably the weakest part of his argument. Experience shows that offline = tests have no teeth. >=20 > My worry with "policing in production" is that it places a lot of = power in the dominant implementations, and can lead to big barriers of = entry for competing new implementations. We sort of see that today in = the browser market. >=20 > And then there is ossification. Each of the approaches carries its own = risks. In security protocols, accepting things that does not completely conform = to the specification does increase interoperability, but it might be = done at the expense of actual security. Russ From nobody Wed May 23 13:55:55 2018 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 1D725127010 for ; Wed, 23 May 2018 13:55:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 YOojNcLaD5TV for ; Wed, 23 May 2018 13:55:47 -0700 (PDT) Received: from mail-pl0-x229.google.com (mail-pl0-x229.google.com [IPv6:2607:f8b0:400e:c01::229]) (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 E8B4812D7F0 for ; Wed, 23 May 2018 13:55:42 -0700 (PDT) Received: by mail-pl0-x229.google.com with SMTP id t12-v6so13741512plo.7 for ; Wed, 23 May 2018 13:55:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=VOV59P79AXEMufwLGq7zhSNl6YZcyj51fOZGyDDnq3M=; b=OLNsXif5fsdI4JvF+XLu265lOELsKXP4glmE0pmJFfWRRrKqTTSQCDHIzaXte4Xq+Y XuOsn3LsJ0O8gYAKz311cxrZOiZLRVdtRGkkWouNfUlT1H5OUdiaGCF/8sVjsqBwKGkO JWsbS9t9bw1cPvIYMY5SlfLN6bux6EbQ4PvPn0cpNSz5fX8Bf62Nv31550dfou4E70Qn 5WSenayZZJxUb+flNQnRJnjA1KwG3lWKlo5LCroe2IO0WndYDdJ47qGORcKVBbLO+/mb XYKpGcWMR9vpnYfyb1yxNVfSYFWx3WalIfxmDqNloYQYPFo57Ns7CEkLNhERPS6c9+IF iVqg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=VOV59P79AXEMufwLGq7zhSNl6YZcyj51fOZGyDDnq3M=; b=aoRZqBOgen9NR+Cq42uhZdAJ2WobpH5HGFsKOP8x1bjqbKqZrvbDok1aeLz2jwLJ7K mA2vIilWYbQX3SiY3+dQaWdWIovUWRsa6FeM3U0Kq+VYO+JDAJBsiqy7ZIxIDzYhgo0P TaBUEJrsCU3Co7pQ2A30M6Ge6ZTU1uuRQF0BTrvbJB+vzpbPEVyNO3RpTmK6nZoN90dg MisRT+5dHJjSXpdkDvaR1XfW0dvFZjttnNt9fJlbxWReL3hyIq13K35MuXVcMwz3GyAq tLyoGpZKt9Ji/7Z9nY3mZjbPyjU/eGr4DKou2z/MYgV+Jzsw6wOZ9AFPJVc4nr0vDx0q lo+A== X-Gm-Message-State: ALKqPweDT/Qmuwf1AKtV2o8HaM+iOs4EgRbUaQykqGhYhqerLdQveEGs gZuWPjDH0IRZXyO6ibNPuc20kA== X-Google-Smtp-Source: AB8JxZqs9S6ysOtpiWEZlCd+Rs/QVRuPPGZmD0eGLOyT1xUESSixk/MIlnJegv28akjYOKFBDO5J5A== X-Received: by 2002:a17:902:7b97:: with SMTP id w23-v6mr4497259pll.116.1527108942116; Wed, 23 May 2018 13:55:42 -0700 (PDT) Received: from [192.168.178.21] ([118.148.121.80]) by smtp.gmail.com with ESMTPSA id y24-v6sm35004538pfn.23.2018.05.23.13.55.39 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 23 May 2018 13:55:41 -0700 (PDT) To: Russ Housley , architecture-discuss@ietf.org References: <152538075241.4552.6760702690778529507@ietfa.amsl.com> <7E740995-3B63-4CE6-BC58-9DDC0F3BA07E@vigilsec.com> From: Brian E Carpenter Message-ID: Date: Thu, 24 May 2018 08:55:44 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: <7E740995-3B63-4CE6-BC58-9DDC0F3BA07E@vigilsec.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [arch-d] I-D Action: draft-iab-protocol-maintenance-00.txt X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.22 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: Wed, 23 May 2018 20:55:53 -0000 On 24/05/2018 08:22, Russ Housley wrote: > >> On May 19, 2018, at 11:33 AM, Christian Huitema wrote: >> >>> On May 18, 2018, at 6:53 PM, Brian E Carpenter wrote: >> .... >>> >>> #3. Production implementations should ... >>> >>> where we apparently disagree. The fact is that production >>> implementations have to make the best of what they are given, >>> which is typically a mixture of design errors in the protocol >>> and implementation errors in other implementations. What is >>> an implementer going to do except tolerate and recover from >>> errors? Users expect apps to work, whatever happens. So that's >>> what implementers will do, regardless of RFCs. The only thing >>> that's changed since the robustness principle was formulated >>> is that there are thousands of times more users and they are less >>> tolerant than ever of failure modes. >> >> That's indeed the core of the debate. On one hand, tolerance maximizes interoperability in the short term. On the other hand, intolerance causes production applications to work as the "protocol police". This harnesses network effects to block unsanctioned extensions. Martin's argument is that this leads to a healthier ecosystem. >> >> Brian's proposal place the burden of maintaining this healthy environment on reference implementations and test suites. That's probably the weakest part of his argument. Experience shows that offline tests have no teeth. >> >> My worry with "policing in production" is that it places a lot of power in the dominant implementations, and can lead to big barriers of entry for competing new implementations. We sort of see that today in the browser market. >> >> And then there is ossification. Each of the approaches carries its own risks. > > In security protocols, accepting things that does not completely conform to the specification does increase interoperability, but it might be done at the expense of actual security. Exactly. That's why I'm reasonably sympathetic to Martin's argument for security protocols, but less so for "normal" protocols. While I'm here, I'll respond to Christian's point that reference implementations and test suites have no teeth. It's certainly true; we learnt that from OSI. Still, I think they have value - include a slow, very picky implementation with lots of diagnostics in an interop hackathon and you will improve the quality of the other implementations. Brian From nobody Wed May 23 14:10:22 2018 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 B4D4712D7E6 for ; Wed, 23 May 2018 14:10:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.989 X-Spam-Level: X-Spam-Status: No, score=-1.989 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=strayalpha.com 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 TaMaSFZB_yb5 for ; Wed, 23 May 2018 14:10:04 -0700 (PDT) Received: from server217-3.web-hosting.com (server217-3.web-hosting.com [198.54.115.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8DD3112D7F0 for ; Wed, 23 May 2018 14:10:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=Message-ID:References:In-Reply-To:Subject:Cc: To:From:Date:Content-Type:MIME-Version:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=r5OH2JCzo/NFSW4z8hkFIjFy+n8iXPF8jw71mENChcY=; b=urcBKOBbP7U/BJuD47jqOvYlf t3Dvg5JDvYSMsgS/VeCDm5QEgCHmx2xrC79YHx1u8E/ZM5E40Y1T/+z2+YZ753LndGWgppx7cIQAb wlo9d9pu6svoclvGfjXW2GpkbQRgXpQGDsic+NgjY52u8u0Ru6wfUXms5EyKqmGc7H10SbCP4M7TW NUlg9jRJ5M02ej1OuVagOqiogvYqMwJFTeMsV7idZxFKkOziCZOoABcy9W5CkXzDhv4Frg76f1AEx Q92wpG+0KmQ06Q2IhcpKbRZe3sJ7jEh7q3a7aN9Xa8WLciea6Yif4XSg3/gHZVmt4zCJ4yMaMxgWK OgAHlI26A==; Received: from [::1] (port=57360 helo=server217.web-hosting.com) by server217.web-hosting.com with esmtpa (Exim 4.91) (envelope-from ) id 1fLb1H-002Spn-2N; Wed, 23 May 2018 17:10:03 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_820d884442c6fbb75c2e8b088edd7771" Date: Wed, 23 May 2018 17:10:03 -0400 From: Joe Touch To: Russ Housley Cc: architecture-discuss@ietf.org In-Reply-To: <7E740995-3B63-4CE6-BC58-9DDC0F3BA07E@vigilsec.com> References: <152538075241.4552.6760702690778529507@ietfa.amsl.com> <7E740995-3B63-4CE6-BC58-9DDC0F3BA07E@vigilsec.com> Message-ID: X-Sender: touch@strayalpha.com User-Agent: Roundcube Webmail/1.3.3 X-OutGoing-Spam-Status: No, score=-1.0 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server217.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - strayalpha.com X-Get-Message-Sender-Via: server217.web-hosting.com: authenticated_id: touch@strayalpha.com X-Authenticated-Sender: server217.web-hosting.com: touch@strayalpha.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Subject: Re: [arch-d] I-D Action: draft-iab-protocol-maintenance-00.txt X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.22 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: Wed, 23 May 2018 21:10:09 -0000 --=_820d884442c6fbb75c2e8b088edd7771 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII On 2018-05-23 16:22, Russ Housley wrote:. > In security protocols, accepting things that does not completely conform to the specification does increase interoperability, but it might be done at the expense of actual security. Being generous in what you receive does not imply being indiscriminately accomodating or naive. It's more (IMO) about not being over-restrictive, i.e., not letting the "expected case" drive the protocol to its minimum permitted behaviors. I.e., no magic or special cases are needed for security protocols. In all cases, being generous still means playing inside the known lines. Joe --=_820d884442c6fbb75c2e8b088edd7771 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=UTF-8


 


On 2018-05-23 16:22, Russ Housley wrote:.

=
In security protocols, accepting things that does not completely con= form to the specification does increase interoperability, but it might be d= one at the expense of actual security.
=  
= Being generous in what you receive does not imply being indiscrim= inately accomodating or naive.
=  
= It's more (IMO) about not being over-restrictive, i.e., not letting the "ex= pected case" drive the protocol to its minimum permitted behaviors.
=  
= I.e., no magic or special cases are needed for security protocols. In all c= ases, being generous still means playing inside the known lines.
=  
= Joe
--=_820d884442c6fbb75c2e8b088edd7771-- From nobody Wed May 23 14:15:58 2018 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 24991127010 for ; Wed, 23 May 2018 14:15:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 l-PvKuKiZtDS for ; Wed, 23 May 2018 14:15:55 -0700 (PDT) Received: from outprodmail01.cc.columbia.edu (outprodmail01.cc.columbia.edu [128.59.72.39]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 606E41201F8 for ; Wed, 23 May 2018 14:15:55 -0700 (PDT) Received: from hazelnut (hazelnut.cc.columbia.edu [128.59.213.250]) by outprodmail01.cc.columbia.edu (8.14.4/8.14.4) with ESMTP id w4NLD9mQ027876 for ; Wed, 23 May 2018 17:15:54 -0400 Received: from hazelnut (localhost.localdomain [127.0.0.1]) by hazelnut (Postfix) with ESMTP id 2B6A46D for ; Wed, 23 May 2018 17:15:54 -0400 (EDT) Received: from sendprodmail01.cc.columbia.edu (sendprodmail01.cc.columbia.edu [128.59.72.13]) by hazelnut (Postfix) with ESMTP id 1429F7E for ; Wed, 23 May 2018 17:15:54 -0400 (EDT) Received: from mail-ot0-f197.google.com (mail-ot0-f197.google.com [74.125.82.197]) by sendprodmail01.cc.columbia.edu (8.14.4/8.14.4) with ESMTP id w4NLFrKA048966 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT) for ; Wed, 23 May 2018 17:15:53 -0400 Received: by mail-ot0-f197.google.com with SMTP id y49-v6so17127725oti.11 for ; Wed, 23 May 2018 14:15:53 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=dLdD30NGu/4N1IIWpZQIEHstvpV9lQksNa7loSvAXaA=; b=bf+HN6BPISz2OUg/oFEBdSLhjqXS6xz9AXukQKswCE0JXDSQOmMC2a+5mbxc76/m0g 4LpE1aHPzJi3eOnxKd47HqMPxJl78RRYrw//2dHDmUV37IUsO1VzwVvOcwxHTmqinI1r J11cwizlyC9YOQN/r2FruwxqN3uhMhCyh5gV48utRR7hMVOaroU7StBjHuOsuDkqvU9p eBgZ2aFPky5toOpIUINHzr8jmDhyFdHBDXo4M8xusSwWhhWJV81yhyV27oerijiOrNdZ zwzZ0yb/s7pq4otZ3j3+6A/lBFmBPvS82WPznNKXnfw+YR5fuT3jSkW37JczU55Xg31s TMCQ== X-Gm-Message-State: ALKqPwfTsoiRuT/2eKK+BwMinEU0Ayu3USvBclM+XKSQJw7UUAw7cpiA YNchxXI3L9U05/QF8kGuFO48oo5q4nhImgiCGVefykfpm1nCmeyMT7qHmf2uYSWRzphAP7VXKRr Ja1hmhDw0p4aMHOuDaAE54MdsFU55+ZMAebDLki3H3liT+nUj9Q== X-Received: by 2002:a9d:2f49:: with SMTP id h67-v6mr2971664otb.185.1527110152984; Wed, 23 May 2018 14:15:52 -0700 (PDT) X-Google-Smtp-Source: AB8JxZp9zYlyIhm71TirDtjJAgCAMTgGNfleO7XIQA+Yn0btbPgFdjnmx2v1VRlXKeQm6t2tNw0vMDuEtMZEoIG3T40= X-Received: by 2002:a9d:2f49:: with SMTP id h67-v6mr2971651otb.185.1527110152628; Wed, 23 May 2018 14:15:52 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a9d:59cd:0:0:0:0:0 with HTTP; Wed, 23 May 2018 14:15:32 -0700 (PDT) In-Reply-To: References: <152538075241.4552.6760702690778529507@ietfa.amsl.com> <7E740995-3B63-4CE6-BC58-9DDC0F3BA07E@vigilsec.com> From: Henning Schulzrinne Date: Wed, 23 May 2018 17:15:32 -0400 Message-ID: To: Joe Touch Cc: Russ Housley , architecture-discuss@ietf.org Content-Type: multipart/alternative; boundary="0000000000002e3d09056ce60aa0" X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.78 on 128.59.72.13 Archived-At: Subject: Re: [arch-d] I-D Action: draft-iab-protocol-maintenance-00.txt X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.22 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: Wed, 23 May 2018 21:15:57 -0000 --0000000000002e3d09056ce60aa0 Content-Type: text/plain; charset="UTF-8" I think this discussion would benefit from citing specific (historical) examples. My hunch is that all the contributors to this discussion have specific cases or issues in mind that may actually be non-overlapping and may illustrate different problems. For example, some may be ambiguities where the text omits some restriction that the ABNF or more formal specification includes, and then implementations follow the text. Henning On Wed, May 23, 2018 at 5:10 PM, Joe Touch wrote: > > > > > On 2018-05-23 16:22, Russ Housley wrote:. > > > In security protocols, accepting things that does not completely conform > to the specification does increase interoperability, but it might be done > at the expense of actual security. > > > Being generous in what you receive does not imply being indiscriminately > accomodating or naive. > > It's more (IMO) about not being over-restrictive, i.e., not letting the > "expected case" drive the protocol to its minimum permitted behaviors. > > I.e., no magic or special cases are needed for security protocols. In all > cases, being generous still means playing inside the known lines. > > Joe > > _______________________________________________ > Architecture-discuss mailing list > Architecture-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/architecture-discuss > > --0000000000002e3d09056ce60aa0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I think this discussion would benefit from citing specific= (historical) examples. My hunch is that all the contributors to this discu= ssion have specific cases or issues in mind that may actually be non-overla= pping and may illustrate different problems. For example, some may be ambig= uities where the text omits some restriction that the ABNF or more formal s= pecification includes, and then implementations follow the text.

Henning

On Wed, May 23, 2018 at 5:10 PM, Joe Touch <= ;touch@strayalpha= .com> wrote:


=C2=A0


On 2018-05-23 16:22, Russ Housley wrote:.


In security protocols, accepting things that does not = completely conform to the specification does increase interoperability, but= it might be done at the expense of actual security.
=C2=A0
Being generous in what you receive does not imply=C2=A0bein= g=C2=A0indiscriminately accomodating or naive.
=C2=A0
It's more (IMO) about not being over-restrictive, i.e.,= not letting the "expected case" drive the protocol to its=C2=A0m= inimum permitted behaviors.
=C2=A0
I.e., no magic or special cases are needed for security pro= tocols. In all cases, being generous still means playing inside the known l= ines.
=C2=A0
Joe

_______________________________________________
Architecture-discuss mailing list
Architecture-discuss@ietf.= org
https://www.ietf.org/mailman/listinf= o/architecture-discuss


--0000000000002e3d09056ce60aa0-- From nobody Wed May 23 14:26:05 2018 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 80DFD12D7E6 for ; Wed, 23 May 2018 14:26:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.403 X-Spam-Level: X-Spam-Status: No, score=-1.403 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.248, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.248, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 EtTsT0UnhNys for ; Wed, 23 May 2018 14:26:01 -0700 (PDT) Received: from mail-pf0-x230.google.com (mail-pf0-x230.google.com [IPv6:2607:f8b0:400e:c00::230]) (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 8B5EF127010 for ; Wed, 23 May 2018 14:26:01 -0700 (PDT) Received: by mail-pf0-x230.google.com with SMTP id c10-v6so11101316pfi.12 for ; Wed, 23 May 2018 14:26:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=JuRQbk0LirXYW0U7f2zJbG2AgE7UKoPjYJnnAeGdi34=; b=N53seQs/KU8Nu2vQKJGGdg1hUc7r+eXiDuhdSv8vJ0dGs7q+twKkSWi49n12Zq4Ja7 MLv1oS5MtO82rV7uzGsFhdabPfuvzewaUEPU2Cwz+K38HwGdto13OShzUIUJtn7Tj1gL R8XkDL1kGTpGes6LqoEJW1YF/4dG9HqTff3vXQWdnJqw3nFq+BoufFCCi2UiVflaxbFj I6p72XqZsl6oBhdLldVdIjpTdcemeGSB8tx1UGHDcHFBlIjplaYs8y8UUNMpgheMl7sH qQX2Cf+5vsh9jt9TKn9zoCZQCU0XnXJxVpDDUpGx4tJK0N6zlHKd4mbZ4uW+ijTfpbnI 6fuQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=JuRQbk0LirXYW0U7f2zJbG2AgE7UKoPjYJnnAeGdi34=; b=dnIEIBxi+ExGEsb4Pfgz3zCemRbNQqdax2ctHXF/y702UaCIYSN9QWqxZKe2OydKsq piQYHx7yNWMlGsO5c28RguKLcefuuUfw2HiVVnSnnyDD4pfwUv9FavKcwq5hOx3r3ARW Hn8i+y5ZsKCDd31eunJKfzczLZR2BIFLLVC+rjJem/Vxpao/gq9NQpxyaCEJZ4wTew+W zXbyzHawVl5mIBofHncYtTAbqeeG2z1jmE1USoiHRJMkNGdNuMzsNzAkI++SIkP52wew mQ2EFxGyKPhQfD+BqxfCS7Dilcw8rvvmMTSTd/HkeCJ/wXvgk5Geurk79wDCR5hjg3qx 3DYA== X-Gm-Message-State: ALKqPwfkbzjgN6p8cYpPggiyu3KaZg5T7B/9VulUY470vf4WDAUjsMnT SPpsrEEWVMRRacwaQPNljfU= X-Google-Smtp-Source: AB8JxZp969Wq/j+59q5RM3KG8tIFqm9n5MFv8EAfvh4EAcbY3kTws1qERdS+6EMmfJV8wQqOH3fazg== X-Received: by 2002:a63:7c0b:: with SMTP id x11-v6mr3502982pgc.384.1527110761213; Wed, 23 May 2018 14:26:01 -0700 (PDT) Received: from [172.22.228.216] ([162.210.130.3]) by smtp.gmail.com with ESMTPSA id t131-v6sm26344110pgc.34.2018.05.23.14.26.00 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 23 May 2018 14:26:00 -0700 (PDT) Sender: Tony Li From: tony.li@tony.li Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_ED085973-1EDF-483F-B20A-E1A0CF8D298D" Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) Date: Wed, 23 May 2018 14:25:59 -0700 In-Reply-To: Cc: Russ Housley , architecture-discuss@ietf.org To: Brian E Carpenter References: <152538075241.4552.6760702690778529507@ietfa.amsl.com> <7E740995-3B63-4CE6-BC58-9DDC0F3BA07E@vigilsec.com> X-Mailer: Apple Mail (2.3445.6.18) Archived-At: Subject: Re: [arch-d] I-D Action: draft-iab-protocol-maintenance-00.txt X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.22 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: Wed, 23 May 2018 21:26:04 -0000 --Apple-Mail=_ED085973-1EDF-483F-B20A-E1A0CF8D298D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > While I'm here, I'll respond to Christian's point that reference > implementations and test suites have no teeth. It's certainly true; > we learnt that from OSI. Still, I think they have value - include > a slow, very picky implementation with lots of diagnostics in an > interop hackathon and you will improve the quality of the other > implementations. While they do add value, the real teeth happen during the installation = process, where one implementation has to interoperate with another = implementation, in a particular configuration, for the first time. The reality is that the customer always holds the newly installed = equipment responsible. It does not matter one whit what the spec says or = that the older equipment is completely insane. If the newly installed = equipment can interoperate, then it stays. If not, then the vendor = loses. Experienced vendors come to revere Jon=E2=80=99s wisdom. While I certainly agree that protocol maintenance is an eventual = necessity, toleration of variations in syntax or sequence that do not = violate the semantics of the protocol can and should be tolerated. The discussion however, is effectively moot: the market will not accept = implementations that do not interoperate. If you choose to be strict in = what you accept, then no one will use your implementation. And Darwin = will win again. Tony --Apple-Mail=_ED085973-1EDF-483F-B20A-E1A0CF8D298D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
While I'm here, I'll respond to = Christian's point that reference
implementations and test suites have no teeth. It's certainly = true;
we learnt = that from OSI. Still, I think they have value - include
a slow, very picky = implementation with lots of diagnostics in an
interop hackathon and you will = improve the quality of the other
implementations.


While = they do add value, the real teeth happen during the installation = process, where one implementation has to interoperate with another = implementation, in a particular configuration, for the = first time.

The = reality is that the customer always holds the newly installed equipment = responsible. It does not matter one whit what the spec says or that the = older equipment is completely insane. If the newly installed equipment = can interoperate, then it stays. If not, then the vendor = loses.

Experienced vendors come to revere Jon=E2=80=99s = wisdom.

While = I certainly agree that protocol maintenance is an eventual necessity, = toleration of variations in syntax or sequence that do not violate the = semantics of the protocol can and should be tolerated.

The discussion however, = is effectively moot: the market will not accept implementations that do = not interoperate. If you choose to be strict in what you accept, then no = one will use your implementation. And Darwin will win again.

Tony

= --Apple-Mail=_ED085973-1EDF-483F-B20A-E1A0CF8D298D-- From nobody Wed May 23 14:34:10 2018 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 291C4127010 for ; Wed, 23 May 2018 14:34:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.403 X-Spam-Level: X-Spam-Status: No, score=-1.403 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.248, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.248, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 iUy-DgBE7REa for ; Wed, 23 May 2018 14:34:06 -0700 (PDT) Received: from mail-pl0-x22f.google.com (mail-pl0-x22f.google.com [IPv6:2607:f8b0:400e:c01::22f]) (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 41C7D1201F8 for ; Wed, 23 May 2018 14:34:06 -0700 (PDT) Received: by mail-pl0-x22f.google.com with SMTP id t12-v6so13794620plo.7 for ; Wed, 23 May 2018 14:34:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=6Z8l+LLRQsOSxdh6Ye6PeuC+kJq/M539kD4gu5cNu1c=; b=d6kaZDg73zHs3p4LF63vxRxRTMgZXFNEr7S2+fpJcikAE4qh8G0rkOsHFb2tkoieYl yk+CWKTmMVoNcrIIAqz44Ta3lB9Pl15DsmLCohiAaNrYjEWQy3kj4EO8antjXiM+sJ8o b0X3+oerw96P2JHT6RyooMISWEHoPPXWv1OHuCokfu9jQYkCF+jP1UJs4bepbmRUPK2f wlr9LvtDoLqXZTb46p/zEXTfQmr9nNYgKx/068aQU/eNuygW2IrMEg8JaEDmPQd10y/z Ba7BFYfFfR8t4I0VLaAlDmAXGxintLuIGTvoxMmN+gbtAFThYEohlVnMA4bI0DB3EAw7 jiVw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=6Z8l+LLRQsOSxdh6Ye6PeuC+kJq/M539kD4gu5cNu1c=; b=cuI3poQHI/UKsKTmaAjMZMI2Oaj/4ZWSQbdAJxYOHJzuYTM8aAQC5BUym2AzZE7jcK paP0Hif/Pl1F7+FOjYJH3REooYa5u+s6Fa7pckCP6mTGo7a+1LQ8EJZsxHsgU2KQ6wW4 vJobwSnXmrGppdw3mz03xNKJ37aJRg8FiKvUj5ZSIQLcFBuha4HcCbZdrnV6o/AAlZuJ MCVrPyLL4h8Tm8OoJRFZ/9CkPKSn0q71bY7Nuk/MRgXlObMHNLoqeIdyNdkkXkhxXTnP M83JNjh6UypryXBa97s5hW/kMS5ENYWnJmdjYjJIk3PKZC0W/5c9b1NF2goDd3PGGi+s yvIg== X-Gm-Message-State: ALKqPwcwDG3WbQCCQSNuWLY7GQ0bytUbgJ+1F3npWmXm5X6dv7LUTFQh ErhT/4I19plZU/Zw2C1nKVDwX8eI X-Google-Smtp-Source: AB8JxZosKbDaOTAzYiE1V74uNN4PeeB6LgMfBf8b8aHK0aRjzlspV7eEw3EKaR8lJEA59PBvrMDJuw== X-Received: by 2002:a17:902:850a:: with SMTP id bj10-v6mr4421278plb.239.1527111245896; Wed, 23 May 2018 14:34:05 -0700 (PDT) Received: from [172.22.228.216] ([162.210.130.3]) by smtp.gmail.com with ESMTPSA id r80-v6sm41791470pfe.44.2018.05.23.14.34.04 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 23 May 2018 14:34:05 -0700 (PDT) Sender: Tony Li From: tony.li@tony.li Message-Id: <3786F6A2-6276-4A92-9BDA-BC042617ED86@tony.li> Content-Type: multipart/alternative; boundary="Apple-Mail=_56D14835-2E02-4DF8-8BDB-CF09613C1455" Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) Date: Wed, 23 May 2018 14:34:04 -0700 In-Reply-To: Cc: Joe Touch , architecture-discuss@ietf.org To: Henning Schulzrinne References: <152538075241.4552.6760702690778529507@ietfa.amsl.com> <7E740995-3B63-4CE6-BC58-9DDC0F3BA07E@vigilsec.com> X-Mailer: Apple Mail (2.3445.6.18) Archived-At: Subject: Re: [arch-d] I-D Action: draft-iab-protocol-maintenance-00.txt X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.22 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: Wed, 23 May 2018 21:34:08 -0000 --Apple-Mail=_56D14835-2E02-4DF8-8BDB-CF09613C1455 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > I think this discussion would benefit from citing specific = (historical) examples. My hunch is that all the contributors to this = discussion have specific cases or issues in mind that may actually be = non-overlapping and may illustrate different problems. For example, some = may be ambiguities where the text omits some restriction that the ABNF = or more formal specification includes, and then implementations follow = the text. If it helps, sure, but names are withheld to protect the guilty=E2=80=A6 Once upon a time Vendor X specified and implemented protocol P. = Somehow, they mis-implemented one particular field, using the most = significant bit in the field as a flag, where the spec had used the = least significant bit. Vendor X got to market first. Vendor X was = notified of the bug, but to date has chosen not to repair it as their = implementation would simply become non-interoperable with previous = releases. Today, all other vendors use the exact same bit as Vendor X. The spec = has NOT been maintained to reflect Vendor X=E2=80=99s reality (a bug, = IMHO), and Vendors A, B, C, D, etc. all make use of the most significant = bit. The points are simple: - The market rules. The market wants interoperability. - What the spec says is pretty much irrelevant. The market doesn=E2=80=99t= care about the spec. - The market is not affected by idealistic ramblings about how we should = be more pedantic. - Postel=E2=80=99s Principle helps interoperability. A lot. - This is reality. Accept it. Tony --Apple-Mail=_56D14835-2E02-4DF8-8BDB-CF09613C1455 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

I think this = discussion would benefit from citing specific (historical) examples. My = hunch is that all the contributors to this discussion have specific = cases or issues in mind that may actually be non-overlapping and may = illustrate different problems. For example, some may be ambiguities = where the text omits some restriction that the ABNF or more formal = specification includes, and then implementations follow the = text.


If it = helps, sure, but names are withheld to protect the guilty=E2=80=A6

Once upon a time = Vendor X specified and implemented protocol P.  Somehow, they = mis-implemented one particular field, using the most significant bit in = the field as a flag, where the spec had used the least significant bit. =  Vendor X got to market first. Vendor X was notified of the bug, = but to date has chosen not to repair it as their implementation would = simply become non-interoperable with previous releases.

Today, all other vendors = use the exact same bit as Vendor X. The spec has NOT been maintained to = reflect Vendor X=E2=80=99s reality (a bug, IMHO), and Vendors A, B, C, = D, etc. all make use of the most significant bit.
The points are simple:
- The market rules. The market wants = interoperability.
- What the spec says is pretty = much irrelevant. The market doesn=E2=80=99t care about the = spec.
- The market is not affected by idealistic = ramblings about how we should be more pedantic.
- = Postel=E2=80=99s Principle helps interoperability. A lot.
- This is reality. Accept it.

Tony

= --Apple-Mail=_56D14835-2E02-4DF8-8BDB-CF09613C1455-- From nobody Wed May 23 19:12:44 2018 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 7EF9712D883 for ; Wed, 23 May 2018 19:12:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 d7gFHSmhg85X for ; Wed, 23 May 2018 19:12:40 -0700 (PDT) Received: from mail-oi0-x22e.google.com (mail-oi0-x22e.google.com [IPv6:2607:f8b0:4003:c06::22e]) (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 ABD4F129C53 for ; Wed, 23 May 2018 19:12:40 -0700 (PDT) Received: by mail-oi0-x22e.google.com with SMTP id v2-v6so68556oif.3 for ; Wed, 23 May 2018 19:12:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Wtx3p2WXuTTarHvwB9/TWjpoVw/sweMDFY9257A7r9c=; b=tnSYyIdOcXcrkQbgesNyyRg8/SFqQ56B/HqKxYAL1gbE7BJ8Besq8/Zw5YFkv/Iprv 0u190YdGgvkbU+2ZqZsK5rqgFlsIF2/XTyTWgq/DwJ9/Bpn/W6dMpBLXOR9AJPD6R08G YUU2NVU4aisy1V2bwtqEZFqijX1K/1hEfBIvWucOb/7AdAIw/DClYaiqoIl72FtzMX0g Eb/iB4uZIdh9CB7+NopoyThThmbBJt8EqoqarlRhQjgJmQ+4MxwBx47ssXFzYaqz7MgN TVtyQ1nmA42nuOmD96vxvrY74qlxvGimmA/aQyv3TZkDY4eCErm3WIreSI8xGl9UCHPl dK8A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Wtx3p2WXuTTarHvwB9/TWjpoVw/sweMDFY9257A7r9c=; b=jtSbPczyKa63QcZsAAPqVpDJ63I3QjF+Gj/0hBxB8gc7SWwo1FCiG9jHGCKR1nUumo 2wBN79WsHQrbl9OwdiDMhQAEjuT7H7gOLxRicnYLemYO4GtQbLbHWYvdUPaDJ67QUc6k zqeprtimeXxbnZA+3F64e+JzUqLHwm+jQkB2eHMkqz3Ihw0BodcqTURMR3dUBX2+R73G lOnyk35ONKbswxDxdEfZh9P7A35PvbRjXJqQ8+ZeWOPCCZKjNy53TZLspilXDaYbCMsU bMNsT2OzNGJe+M8iWp+bz2UYVjvBY0m1IxO7Ftv5/NVllGjKkAtHloWi75jpN3G/d2yi JwJQ== X-Gm-Message-State: ALKqPwdPIRG8DBfLeXIi86H2EPW/5EbV/29SA/Fk7zjacLGN+R/twkfT uQyPRRuT7koRp0ERmIRkn4MjEMkB0JG4h/gjeNX2ooOo X-Google-Smtp-Source: AB8JxZrkku/xFAK0mXOHUwTm/UZOtrpFMlO/3sgzQH8dewgRXD3TSseusUVOwd1yHMWRgX4btEratPUB78HGQy90S+c= X-Received: by 2002:aca:5bc5:: with SMTP id p188-v6mr2732836oib.295.1527127959913; Wed, 23 May 2018 19:12:39 -0700 (PDT) MIME-Version: 1.0 References: <152538075241.4552.6760702690778529507@ietfa.amsl.com> In-Reply-To: From: Martin Thomson Date: Thu, 24 May 2018 12:12:29 +1000 Message-ID: To: Brian E Carpenter Cc: architecture-discuss@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [arch-d] I-D Action: draft-iab-protocol-maintenance-00.txt X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.22 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: Thu, 24 May 2018 02:12:43 -0000 Hi Brian, Thanks for articulating your views here. I think that we have different notions of what this thing is still... On Sat, May 19, 2018 at 11:53 AM Brian E Carpenter < brian.e.carpenter@gmail.com> wrote: > If we don't hear from other voices here, that isn't OK. Work in progress :) > > It's possible that our disagreement stems from a disconnect regarding the > > scope of the application of the robustness principle. I think that the > > "When in doubt" part clearly limits its applicability to situations where > > there is insufficient or unclear specification. It seems like you might > > have a broader notion of the idea. It might pay to push on that notion a > > little. I've done a little of that below. > I think there are several aspects. > #1. The robustness principle should indirectly guide protocol design. > Firstly there should be no unspecified parts of any PDU. Secondly, > there should be no unspecified responses to any valid or invalid parts > of any PDU. If you do that correctly, the robustness principle isn't > needed in any implementation. Hmm, perhaps we see this differently. I see this more as a case of "well, we know that implementations are going to screw this up if we don't specify things, what can we do to avoid that?". That mostly involves specifying semantics for everything. Describing what it means to send every valid value and describing what to do with every other value. I don't see this as being informed by the robustness principle as much as it is just writing down a complete specification. > But we know that in real life either specifications are imperfect, > or implementations are imperfect, or both. Therefore: > #2. Test or reference implementations should verify that all parts > of all PDUs are valid. Invalid items should be logged and reported. > (Whether test implementations should also generate invalid PDUs > in order to test the other end is a separate question.) > I hope we agree so far. Then we get to: > #3. Production implementations should ... > where we apparently disagree. The fact is that production > implementations have to make the best of what they are given, > which is typically a mixture of design errors in the protocol > and implementation errors in other implementations. What is > an implementer going to do except tolerate and recover from > errors? Users expect apps to work, whatever happens. So that's > what implementers will do, regardless of RFCs. The only thing > that's changed since the robustness principle was formulated > is that there are thousands of times more users and they are less > tolerant than ever of failure modes. Yes. We clearly disagree. Maybe there's a time sequence that we need to be sensitive to here though. The first implementation, A, contains a mistake. It allows value X, which is maybe not specified clearly enough, to be interpreted as a Y. The second implementation, B, sends X sometimes. This is also a mistake, but it doesn't get caught because A does that. The third implementation, C, rejects messages with X. Now we have an interop issue sometimes when B talks to C. So you say that the robustness principle leaps to the rescue. C can discover the problem and adjust to tolerate X somehow. But C just kicked the can down the road. How does C discover that Y is the right way to interpret X? What if they choose Z? Things might appear to continue to work, but the difference between Y and Z mean that you have new problems until the next fix. The application of the robustness principle assumes that C discovers the problem first (which is likely, see also Langley's law of the internet: "blame attaches to the last thing that changed" -- https://www.imperialviolet.org/2016/05/16/agility.html ). It also assumes that A and B won't or can't change, and that the spec can't be fixed. That sounds like more work with limited prospects for success. But I think that's a little defeatist. The apathy that its application implies, as much as the principle itself, is the target I'm aiming at here. It is less possible now than it ever was to release software (or protocols) onto the Internet and walk away, so the odds of finding and engaging with other implementers is pretty good. > > https://martinthomson.github.io/postel-was-wrong/implementation-robustness/draft-iab-protocol-maintenance.html > That's 404, unfortunately. Synch problem?? Name change problem. We have an intarchboard repo on github, and we recently moved this there. https://intarchboard.github.io/protocol-maintenance/implementation-robustness/draft-iab-protocol-maintenance.html > > Once particularly nasty consequence was the application of this retry to > > version intolerance. That is, there was a strong tendency of servers to > > fail to connect if a client offered a newer protocol version. For example, > > we saw astonishingly high rates of intolerance to TLS 1.3 before the > > version negotiation mechanism there was redesigned. Some tests saw around > > 20% failure rates. That resulted in TLS - as deployed - being vulnerable > > to a range of trivial downgrade attacks, some of which are listed in RFC > > 7457. > Yes. But all of this seems to be due to weak design in SSL; blame that, > not the subsequent 3rd party efforts to fix that design, as the > root cause. This is a good point to latch on to. We might like to believe that a good design is the answer, but I don't think that SSL is fundamentally a bad design, mostly it's just some choices, some of which might be made differently by different people. Yes, failing to allow for extensibility is a fairly bad mistake, and there were others that were worse. I don't think that we can so easily dismiss the example because the protocol was so bad. As RFC 5218 established, we don't really get to choose which protocols become successful, and a good design is no prerequisite. We might extract different wisdom from the lesson, but I see this an application of maintenance. TLS extensions are effectively 100% reliable today. And mainly because the community collectively has maintained both the specification and the implementations. If you like, think of it as pigs flying given sufficient thrust; which is perhaps a good analogy for the lessons of RFC 5218. From nobody Wed May 23 19:39:27 2018 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 725C712D86F for ; Wed, 23 May 2018 19:39:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 KqpU2Qquw5gP for ; Wed, 23 May 2018 19:39:23 -0700 (PDT) Received: from mail-oi0-x229.google.com (mail-oi0-x229.google.com [IPv6:2607:f8b0:4003:c06::229]) (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 CF1DA126CC7 for ; Wed, 23 May 2018 19:39:23 -0700 (PDT) Received: by mail-oi0-x229.google.com with SMTP id c203-v6so102627oib.7 for ; Wed, 23 May 2018 19:39:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=3Qt8aMX43iuc47p/LsPgI6E9MHBmPjPirSOus14AgRE=; b=UPQdDwrtH07b/9Z9nSg+oG50fLpMsUviKJBxrGMvXG9kEYwSUdOe6N8y/LOyXvYjT3 qNcpswBuI8bbsqlyqeUc0Q8YUb4CwWQ4mrxjDLwwkNgKyRlAw4QsUECYVAq8hOt7n/yb p5nxCs6VOf9UWDyloEyBddzSQtJ35tqIIDLt0ELQKquuBuQqCDZxdIlALvKffvY68e9M vaidBmnp3T/9Xc2mZRnwx9IxRuQZatm2TD1VohjyV6x5e/bfp9waZR5DCDtJ+5fSwrD/ KLzRzk41dVxIV1L/HgjPioqZV3z/zq/hkbq4TYXR+uC3RKhRigumNZgdZw21ezp3ZVKB WntQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=3Qt8aMX43iuc47p/LsPgI6E9MHBmPjPirSOus14AgRE=; b=fZvYiL/SowScmx34+rdEu5bXCOj42LeE2gfUG4s6BrhPTP5Pp7LsVZ1oeF7nyDA4sM kGEIRpZET3D3u9guJiAL08tJPm0zf4A2LokQfCp7lEOoNng7I/iRuwNc1/kMWDoErbsh df2FF7GA5byCXpjZHYmEv1umW80yC8bm2UYd8aNQujfZuOooLJFp7OwFJC9QJNvVxnJT 1VnXSoWODMHqfYtRm4ySCJGJ3h9p7QVHZpp7z9irdtfThCVY8fY6atI244D8o10PGGgH 5eF51QAARV8C5bGqtpJk3WYoMHky/00pEREr+KW7M+ieWrheZRzFWNZYi3OKrIrRs99K VzeA== X-Gm-Message-State: ALKqPwc3+WAP6VwRmp91mQBZsgyR6E3se63A7YLUO+O8MnO8fmVcXgPa nAQWgh/pRFaACUGDlTqju0UQvREAbfTmtcMf4Ho= X-Google-Smtp-Source: AB8JxZpl97C1CWog+LozW1YHjuP/fDEFovUq03IDtsOeehZIfLrrhp3PT5o1Mff9eGRjzFkjcVUOgQ//AFCDkeTNS7w= X-Received: by 2002:aca:5bc5:: with SMTP id p188-v6mr2764226oib.295.1527129563105; Wed, 23 May 2018 19:39:23 -0700 (PDT) MIME-Version: 1.0 References: <152538075241.4552.6760702690778529507@ietfa.amsl.com> In-Reply-To: From: Martin Thomson Date: Thu, 24 May 2018 12:39:12 +1000 Message-ID: To: Christian Huitema Cc: Brian E Carpenter , architecture-discuss@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [arch-d] I-D Action: draft-iab-protocol-maintenance-00.txt X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.22 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: Thu, 24 May 2018 02:39:26 -0000 On Sun, May 20, 2018 at 1:34 AM Christian Huitema wrote: > My worry with "policing in production" is that it places a lot of power in the dominant implementations, and can lead to big barriers of entry for competing new implementations. We sort of see that today in the browser market. Yes, we've seen the effect that a need to interoperate with big players causes. That's something I'm quite sensitive to, and as a browser I know we try hard to avoid using the power we don't want to have. But we don't always succeed. What I've observed there is that ensuring that specifications match reality has helped new implementations considerably. If you need to be bug-for-bug compatible in a particular way, documenting that as an interoperability requirement in a specification means that new implementations have less of a barrier to entry. The dominant implementation might have all the existing code, but they also suffer from the other problems of incumbency (more users, more use cases, more legacy code, etc...). It's not perfect, but were specifications not maintained, the costs for entry would be hard to understand. In the end, if big implementations match the spec, then it's probably OK. That means the spec remains relevant. This was the lesson from deploying HTTP/2. If existing implementations took steps to exclude implementations that violated rules of the specification, then we got fewer non-conforming implementations. That was a little rocky early on for some errors, but those are now almost purely historical. We generate zero INADEQUATE_SECURITY errors now, where it was a little difficult early one (I'm looking at a sample of 4 billion that claim). That same attitude has served us well with that protocol thus far. From nobody Wed May 23 19:48:22 2018 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 00A111273E2 for ; Wed, 23 May 2018 19:48:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 r9tJWifAwp5l for ; Wed, 23 May 2018 19:48:17 -0700 (PDT) Received: from mail-oi0-x22f.google.com (mail-oi0-x22f.google.com [IPv6:2607:f8b0:4003:c06::22f]) (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 21DF0126CC7 for ; Wed, 23 May 2018 19:48:17 -0700 (PDT) Received: by mail-oi0-x22f.google.com with SMTP id 11-v6so114426ois.8 for ; Wed, 23 May 2018 19:48:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Mkwk/8gN592yCGX5VkRH3QHYg0QMsWh+xiPRv4FE0oc=; b=hp+wqfXsAjNJ1JVUOT5y4ILVOckWgMXteQ/9D1JIMa2XGIepYydE+UIITfal8ZyTb5 26lrgJGSUfNzXFUF+CZSU2aE0U+pYF97//lviWqn1okER0ya4aMtVBJqu8q2uyaYaD1O Sx/SjgrsrOCuM40nCKusJewScNVtYSPNdfRHXA47WYu4zZh8npHdnf7Zyzy9YFjwvU8g yYLvgmb+UAD+7VjgXd88bMRZI7/N1c9ZkXA2EJRcFEFRa093V3IHwlqNf5GNZP+DE0av xdvOmu4QbPHt9Jt8qqruiLPQLS+1ek1Ij2bhMokkpHOrQQHAgaaEucfMJdly3faGcDpY rLJg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Mkwk/8gN592yCGX5VkRH3QHYg0QMsWh+xiPRv4FE0oc=; b=YSUW6vvL1fWN1ZmYP11YvaBmJSFPeS62rsybxJY18N8OX4JhFSwEu275+L8I8oCHpg /uHuyM0cfT4Pn1AP2h/KKQpfne/wQW/XNleRg/FI+AO7znm3df7i1XnAxCKAGEGEI1yl kVlsjZ+DBjmrt5PMtMf9CuewS9ZI7P13YOR34FQGu40k4BMY9WTCpQVMO4Y4ntPxaVTs aM5olocfOa6SZH0LVxArXHQKlWIwqvDRZtJsKFR5H/U+A6QEBzUssbdNjlvn0bzasOnA tenYEkxqKGu7k4w7nLgRHGDSnnVj5VSk6EHEdv+Fnp6VxAQ6r55fqZSKXo9wlrcZZpbr NE/Q== X-Gm-Message-State: ALKqPwemG3KO62bNBvgM9RoDF5YgSlFoCmeWglOYx5YuNsxjxM+UxYPg 3S/m3AkyqWXz8bB297vEuKneL9+jxY37iF9rYFN6nA== X-Google-Smtp-Source: AB8JxZolHxTGKu56Ul1vT8IjPVSClu61CRz+5z5zK0KJXC9HuL+hBhAaFTPe03Bg6A8mYWE0+iFl9FWBkTYAVcjtkus= X-Received: by 2002:aca:4e15:: with SMTP id c21-v6mr2757264oib.254.1527130096455; Wed, 23 May 2018 19:48:16 -0700 (PDT) MIME-Version: 1.0 References: <152538075241.4552.6760702690778529507@ietfa.amsl.com> In-Reply-To: From: Martin Thomson Date: Thu, 24 May 2018 12:48:06 +1000 Message-ID: To: Bernard Aboba Cc: architecture-discuss@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [arch-d] I-D Action: draft-iab-protocol-maintenance-00.txt X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.22 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: Thu, 24 May 2018 02:48:19 -0000 On Sun, May 20, 2018 at 2:49 AM Bernard Aboba wrote: > The IAB has in the past recognized the harm caused by protocol dialects. While RFC 5407 "Uncoordinated Protocol Development Considered Harmful" focuses on lack of coordination between SDOs, the arguments are equally valid if applied to vendor "dialects": Yes, it's a concern I share, but there are two problems in there. The first is what 5407 tackles: the use of protocols that are ostensibly the same, but that have different semantics attached to the same codepoints. As you say, that's a disaster. The second is protocol mitosis. The emergence of divergent communities of use for the same protocol that find that they no longer share the ability to communicate. I think that's possible even without applying the robustness principle, just with the accretion of disjoint sets of protocol extensions that eventually become critical to applications. The IAB has stated a desire to address small issues in its recent work, so I'm a little reluctant to increase scope here. I can appreciate that being tolerant of inputs can lead you further into a situation where you thought that you had one protocol when there were really two, but without a concrete example, I'm not sure how useful saying that would be. I'd prefer to work separately on the general protocol mitosis problem. > Nowhere in RFC 5407 is Postel's maxim mentioned - which I interpret as a recognition that it does not apply to these situations. I'm not sure that I'd try to read too much into it. 5407 hits a pretty easy target, I'm not sure that robustness necessarily entered into consideration. From nobody Thu May 24 05:27:42 2018 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 E7AA512DA22 for ; Thu, 24 May 2018 05:27:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 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_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.com 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 KuOQzluBfNSe for ; Thu, 24 May 2018 05:27:39 -0700 (PDT) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BCC0A1201F2 for ; Thu, 24 May 2018 05:27:39 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id ACE101C0D68; Thu, 24 May 2018 05:27:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1527164859; bh=il5ll275h8TilABXdim6H8HDwuZL4gf5XQ90Cz7Z+sY=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=c3HzQ0us/GgFxfalWq4q6NdmsC0Te94yDkzjABeg80mS3tZRaO/FZ/skG0b32rS2S B0dKtI/BlW3T1w3kBPH7xqo/jzzU7m2TJP8KJkCDiJ4dGzGenatulEZnNgBnR/llu7 F/n+2x+nQh2lLz7zMTKGzL2TOpqWT3jM96+qyoHo= X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from Joels-MacBook-Pro.local (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 3E39F1C07B3; Thu, 24 May 2018 05:27:39 -0700 (PDT) To: Martin Thomson Cc: architecture-discuss@ietf.org References: <152538075241.4552.6760702690778529507@ietfa.amsl.com> From: "Joel M. Halpern" Message-ID: <1558e14f-88b9-1af6-dbcf-01b24b4edf57@joelhalpern.com> Date: Thu, 24 May 2018 08:27:38 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [arch-d] I-D Action: draft-iab-protocol-maintenance-00.txt X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.22 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: Thu, 24 May 2018 12:27:41 -0000 Watching this discussion, I think that there are two points that most folks agree on, and that may help the community if they are stated 1) When writing specs, try our best to be clear and specific. leaving behavior unspecified tends to lead to interoperability failures down the road. When we are sure that it does not matter, we can say that. 1') Do make sure that restrictions we put in specs actually affect interoperability, even if it is future interoperability. Whenever possible, explain the implications so folks do not ignore the restriction. 2) As implementors, do not permit behaviors that violate the spec. The restrictions are there for reason. The Postel principle is NOT an instruction to violate the spec. Having those two things, there is one additional aspect that I think we need to keep in mind. I don't know whether folks agree with 3) We can not cover every possible case in a spec. In order to improve interoperability, implementors should assume for processing incoming messages that all behaviors not prohibited are permitted. At the same time, implementors should hew as close to the explicit text of the spec when generating messages. From nobody Thu May 24 09:52:18 2018 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 3834E12EAF9 for ; Thu, 24 May 2018 09:52:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.989 X-Spam-Level: X-Spam-Status: No, score=-1.989 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=strayalpha.com 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 ce6yj2DJCVSo for ; Thu, 24 May 2018 09:52:06 -0700 (PDT) Received: from server217-3.web-hosting.com (server217-3.web-hosting.com [198.54.115.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1C7C412EAE6 for ; Thu, 24 May 2018 09:52:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=Message-ID:References:In-Reply-To:Subject:Cc: To:From:Date:Content-Type:MIME-Version:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=knmUweMuyCN861o7MISUps7sChRMYXiww7m1DSb1lYs=; b=wz0ofi5sTjXAgk370mFr/xLJS 1Kl6fSBVIqFw9olA3eTzyioXge8gY4VoYD6C8jdYgl6/MrXhaSvVOhk1gaQu8ux8Djg/Et/UGxGEb 5Icocp6pJ1GOWjnDzLAiwV/e7237ZojRSUv6v4YVKsfWbeQSKeW5AiSFEUQfNTDv6ABGdLiw9pnUj IZB2e5+pM+nPGAc9TngjqyDKBU2RhhvoeGyd1RbMBSSUiNwfagt9PbeOnFs4PrHrHvjbnKwoL1vNv QMed5al1I84eNQPg2IzbPhmhmpvELEDCpAN+StLMZS9l9Y1IaKvtjImjXGtwDaRA+++VFvsAuJtJa y2orQCWDA==; Received: from [::1] (port=44842 helo=server217.web-hosting.com) by server217.web-hosting.com with esmtpa (Exim 4.91) (envelope-from ) id 1fLtTA-001kSo-Bm; Thu, 24 May 2018 12:52:05 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_c18d44d4b0f5fc8c12b23ee59eb34043" Date: Thu, 24 May 2018 09:52:04 -0700 From: Joe Touch To: "Joel M. Halpern" Cc: Martin Thomson , architecture-discuss@ietf.org In-Reply-To: <1558e14f-88b9-1af6-dbcf-01b24b4edf57@joelhalpern.com> References: <152538075241.4552.6760702690778529507@ietfa.amsl.com> <1558e14f-88b9-1af6-dbcf-01b24b4edf57@joelhalpern.com> Message-ID: <427a34ba804f299893b1b1bf02f56617@strayalpha.com> X-Sender: touch@strayalpha.com User-Agent: Roundcube Webmail/1.3.3 X-OutGoing-Spam-Status: No, score=-1.0 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server217.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - strayalpha.com X-Get-Message-Sender-Via: server217.web-hosting.com: authenticated_id: touch@strayalpha.com X-Authenticated-Sender: server217.web-hosting.com: touch@strayalpha.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Subject: Re: [arch-d] I-D Action: draft-iab-protocol-maintenance-00.txt X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.22 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: Thu, 24 May 2018 16:52:17 -0000 --=_c18d44d4b0f5fc8c12b23ee59eb34043 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Hi, Joel, On 2018-05-24 05:27, Joel M. Halpern wrote: > ... > Having those two things, there is one additional aspect that I think we need to keep in mind. I don't know whether folks agree with > > 3) We can not cover every possible case in a spec. In order to improve interoperability, implementors should assume for processing incoming messages that all behaviors not prohibited are permitted. At the same time, implementors should hew as close to the explicit text of the spec when generating messages. Agreed - but there may be an additional nuance here. When you say "permitted", it could mean many things: - act on as actively as possible (inferring intended behavior) - act on as benignly as possible (e.g., silently ignore or repeat the last ACK in TCP) - some combination of the two above (e.g., act where possible, ignore where not) I think there are some basic dimensions of a reasonable approach that should be included: - do not infer malice where ignorance or benign behavior could suffice - be agnostic about content that is undefined (don't over-infer) - the same holds on transmission, focusing on implying rather than inferring I call these, in summary: on sending, do not IMPLY on receiving, do not INFER Joe --=_c18d44d4b0f5fc8c12b23ee59eb34043 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=UTF-8

Hi, Joel,

On 2018-05-24 05:27, Joel M. Halpern wrote:

= =2E..
Having those two things, there is one additional aspect that I = think we need to keep in mind.  I don't know whether folks agree with<= br />
3) We can not cover every possible case in a spec.  In ord= er to improve interoperability, implementors should assume for processing i= ncoming messages that all behaviors not prohibited are permitted.  At = the same time, implementors should hew as close to the explicit text of the= spec when generating messages.
=  
= Agreed - but there may be an additional nuance here.
=  
= When you say "permitted", it could mean many things:
= - act on as actively as possible (inferring intended behavior)
= - act on as benignly as possible (e.g., silently ignore or repeat the last = ACK in TCP)
= - some combination of the two above (e.g., act where possible, ignore where= not)
=  
= I think there are some basic dimensions of a reasonable approach that shoul= d be included:
= - do not infer malice where ignorance or benign behavior could suffice
= - be agnostic about content that is undefined (don't over-infer)
= - the same holds on transmission, focusing on implying rather than inferrin= g 
=  
= I call these, in summary:
=  
=      on sending, do not IMPLY
=      on receiving, do not INFER
=  
= Joe
=  
=  
=  
--=_c18d44d4b0f5fc8c12b23ee59eb34043-- From nobody Thu May 24 11:09:58 2018 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 3EA4512EAFC for ; Thu, 24 May 2018 11:09:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.879 X-Spam-Level: X-Spam-Status: No, score=-1.879 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 A-19_i_f1BDO for ; Thu, 24 May 2018 11:09:46 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 F2BBA12EB12 for ; Thu, 24 May 2018 11:09:45 -0700 (PDT) Received: from unescapeable.local ([47.186.17.148]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id w4OI9jr5069881 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Thu, 24 May 2018 13:09:45 -0500 (CDT) (envelope-from rjsparks@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host [47.186.17.148] claimed to be unescapeable.local To: architecture-discuss@ietf.org References: <152538075241.4552.6760702690778529507@ietfa.amsl.com> From: Robert Sparks Message-ID: Date: Thu, 24 May 2018 13:09:44 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [arch-d] I-D Action: draft-iab-protocol-maintenance-00.txt X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.22 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: Thu, 24 May 2018 18:09:57 -0000 On 5/23/18 9:39 PM, Martin Thomson wrote: > On Sun, May 20, 2018 at 1:34 AM Christian Huitema > wrote: >> My worry with "policing in production" is that it places a lot of power > in the dominant implementations, and can lead to big barriers of entry for > competing new implementations. We sort of see that today in the browser > market. > > Yes, we've seen the effect that a need to interoperate with big players > causes. That's something I'm quite sensitive to, and as a browser I know > we try hard to avoid using the power we don't want to have. But we don't > always succeed. > > What I've observed there is that ensuring that specifications match reality > has helped new implementations considerably. So, there was a case in SIP where an influential vendor had a bug in their parser that caused them to fail if they received a message formatted correctly according to RFC3261 (this is the lr; vs lr=true; in Via header field values issue - you can find a lot about it digging through the sip-implementors archives). It took, IIRC, more than a year before their heavily deployed application was updated to accept what the specification said. During that year (and for a few years after) all implementations spoke the lr=true; variant. After the bug was fixed, and a couple of years passed, the implementation base universally went back to lr; If I read what you suggest correctly, you would have preferred that the IETF have updated 3261 shortly after it was clear that this variant was pervasive in deployment, and updated it again after the variant went away? Or do I misunderstand the time-scope of ensuring that specifications match reality above? If I have it right, note that there is a frog-boiling problem on when to decide to reflect the variant in the specifications. For the high-order vs low-order bit variant discussed earlier, when would it have been reasonable for the specs to be changed? Also, please reread the above paragraph substituting "bug" for "variant" and see if it changes anything. Then reread it thinking "sips:". RjS > If you need to be bug-for-bug > compatible in a particular way, documenting that as an interoperability > requirement in a specification means that new implementations have less of > a barrier to entry. The dominant implementation might have all the > existing code, but they also suffer from the other problems of incumbency > (more users, more use cases, more legacy code, etc...). It's not perfect, > but were specifications not maintained, the costs for entry would be hard > to understand. > > In the end, if big implementations match the spec, then it's probably OK. > That means the spec remains relevant. > > This was the lesson from deploying HTTP/2. If existing implementations > took steps to exclude implementations that violated rules of the > specification, then we got fewer non-conforming implementations. That was > a little rocky early on for some errors, but those are now almost purely > historical. We generate zero INADEQUATE_SECURITY errors now, where it was > a little difficult early one (I'm looking at a sample of 4 billion that > claim). That same attitude has served us well with that protocol thus far. > > _______________________________________________ > Architecture-discuss mailing list > Architecture-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/architecture-discuss From nobody Thu May 24 11:44:24 2018 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 DCED012E898 for ; Thu, 24 May 2018 11:44:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 h5UROWO9TxSp for ; Thu, 24 May 2018 11:44:18 -0700 (PDT) Received: from outprodmail02.cc.columbia.edu (outprodmail02.cc.columbia.edu [128.59.72.51]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7B17C12EB14 for ; Thu, 24 May 2018 11:44:18 -0700 (PDT) Received: from hazelnut (hazelnut.cc.columbia.edu [128.59.213.250]) by outprodmail02.cc.columbia.edu (8.14.4/8.14.4) with ESMTP id w4OIduCi039154 for ; Thu, 24 May 2018 14:44:17 -0400 Received: from hazelnut (localhost.localdomain [127.0.0.1]) by hazelnut (Postfix) with ESMTP id 996BB90 for ; Thu, 24 May 2018 14:44:17 -0400 (EDT) Received: from sendprodmail01.cc.columbia.edu (sendprodmail01.cc.columbia.edu [128.59.72.13]) by hazelnut (Postfix) with ESMTP id 0DA4F90 for ; Thu, 24 May 2018 14:44:15 -0400 (EDT) Received: from mail-ot0-f200.google.com (mail-ot0-f200.google.com [74.125.82.200]) by sendprodmail01.cc.columbia.edu (8.14.4/8.14.4) with ESMTP id w4OIiE7C024960 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT) for ; Thu, 24 May 2018 14:44:14 -0400 Received: by mail-ot0-f200.google.com with SMTP id t1-v6so1460229oth.3 for ; Thu, 24 May 2018 11:44:14 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=hvu76aS/5VbKiRpV9AQgGS/vjdSH1JsGuDAS8OlTbFE=; b=F8nRaMsWf1b96sMRkqc1IaoLXj5dLGxHKEGNxraH42sN/SojZYp2S+4vgP+Ud0LV1N ppR50YrSaRzNsQSEfgURTdUUpq+9fMrTJCXax/XsmjvyI90RYZZmtjsqhRYVE9TO89M+ GswflI6t+nu0zv5YmAlMnS4MmSwQLaS3apYqFlEmo2esphIwuL/GrlgC8F80VsesqvwB Ph/Au93SEAVoY52tezT2lsHUtpQ4XzOa1VihsHLcDt3JN7ZEKSeBOvMZ1Dnjlc4Dqce3 GtHat9u4zMLVFa1krx78kcgpAIyBaAqxFpAFKz77rSNWJ1PMysQ3vKwPZfogNuPfZI/w VUHw== X-Gm-Message-State: ALKqPweXV97N2TcIj2JbJik56v2oidDN3uGhi8Gd9IPqhI3HsaGMBfBv jZq6taGmgUF4UOXN3AVhrQB1Cab6fAajRZItJyHsr2NnM9e7fYJb3hfRz+37fn3djQKj1VBuxf5 24LGT+5EksyOIjcs/+PPe+VbcGGXSncDOyIX9po+mr9hM/fnavg== X-Received: by 2002:a9d:2482:: with SMTP id z2-v6mr5024033ota.168.1527187453922; Thu, 24 May 2018 11:44:13 -0700 (PDT) X-Google-Smtp-Source: AB8JxZoucy3BXhhih60ssya4E1WYlQq+IEO8VnUQo4hi+2edlTmtC9SOPtvZEqdm4y+1ugUWVUMcWXK+LjuO890ZeV4= X-Received: by 2002:a9d:2482:: with SMTP id z2-v6mr5024014ota.168.1527187453432; Thu, 24 May 2018 11:44:13 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a9d:59cd:0:0:0:0:0 with HTTP; Thu, 24 May 2018 11:43:52 -0700 (PDT) In-Reply-To: References: <152538075241.4552.6760702690778529507@ietfa.amsl.com> From: Henning Schulzrinne Date: Thu, 24 May 2018 14:43:52 -0400 Message-ID: To: Robert Sparks Cc: architecture-discuss@ietf.org Content-Type: multipart/alternative; boundary="000000000000aae29e056cf80959" X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.78 on 128.59.72.13 Archived-At: Subject: Re: [arch-d] I-D Action: draft-iab-protocol-maintenance-00.txt X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.22 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: Thu, 24 May 2018 18:44:23 -0000 --000000000000aae29e056cf80959 Content-Type: text/plain; charset="UTF-8" The reason I was asking for examples is exactly that: from my experience, the case of implementations not accepting valid input and then forcing everybody else, by market dominance or avoiding blame, to implement either restricted or wrong behavior. Common cases I have seen: * the spec says case-insensitive, but applications are case-sensitive; * the spec doesn't say ASCII or even explicitly allows binary or UTF-8 content, but the implementation barfs on anything but ASCII; * the spec has extension mechanisms that demand that unknown elements (headers) get passed unmodified, but intermediate entities don't ("for security reasons"); * the spec doesn't impose a length limit (or a very liberal one), but the implementation does. This seems more common in text-based protocols as these often seem to get implemented by looking at the examples only. Beyond the sips: case, there's the well-known SIP multi-part payload case. This occurs even if the "intolerant" application is in the minority, not just for market-dominant implementations. See https://medium.com/incerto/the-most-intolerant-wins-the-dictatorship-of-the-small-minority-3f1f83ce4e15 for one take on this. One good example of where protocols have to "reign in" applications might be RFC 2822, Section 4 and A.6 Earlier versions of this standard allowed for different (usually more liberal) syntax than is allowed in this version. Also, there have been syntactic elements used in messages on the Internet whose interpretation have never been documented. The following are examples of obsolete (that is, the "MUST NOT generate") syntactic elements described in section 4 of this document. Henning On Thu, May 24, 2018 at 2:09 PM, Robert Sparks wrote: > > > On 5/23/18 9:39 PM, Martin Thomson wrote: > >> On Sun, May 20, 2018 at 1:34 AM Christian Huitema >> wrote: >> >>> My worry with "policing in production" is that it places a lot of power >>> >> in the dominant implementations, and can lead to big barriers of entry for >> competing new implementations. We sort of see that today in the browser >> market. >> >> Yes, we've seen the effect that a need to interoperate with big players >> causes. That's something I'm quite sensitive to, and as a browser I know >> we try hard to avoid using the power we don't want to have. But we don't >> always succeed. >> >> What I've observed there is that ensuring that specifications match >> reality >> has helped new implementations considerably. >> > So, there was a case in SIP where an influential vendor had a bug in their > parser > that caused them to fail if they received a message formatted correctly > according > to RFC3261 (this is the lr; vs lr=true; in Via header field values issue - > you can > find a lot about it digging through the sip-implementors archives). It > took, IIRC, > more than a year before their heavily deployed application was updated to > accept > what the specification said. During that year (and for a few years after) > all > implementations spoke the lr=true; variant. After the bug was fixed, and a > couple > of years passed, the implementation base universally went back to lr; > > If I read what you suggest correctly, you would have preferred that the > IETF have > updated 3261 shortly after it was clear that this variant was pervasive in > deployment, > and updated it again after the variant went away? Or do I misunderstand > the time-scope > of ensuring that specifications match reality above? If I have it right, > note that there is > a frog-boiling problem on when to decide to reflect the variant in the > specifications. > For the high-order vs low-order bit variant discussed earlier, when would > it have been > reasonable for the specs to be changed? > > Also, please reread the above paragraph substituting "bug" for "variant" > and see if it > changes anything. > > Then reread it thinking "sips:". > > RjS > >> If you need to be bug-for-bug >> compatible in a particular way, documenting that as an interoperability >> requirement in a specification means that new implementations have less of >> a barrier to entry. The dominant implementation might have all the >> existing code, but they also suffer from the other problems of incumbency >> (more users, more use cases, more legacy code, etc...). It's not perfect, >> but were specifications not maintained, the costs for entry would be hard >> to understand. >> >> In the end, if big implementations match the spec, then it's probably OK. >> That means the spec remains relevant. >> >> This was the lesson from deploying HTTP/2. If existing implementations >> took steps to exclude implementations that violated rules of the >> specification, then we got fewer non-conforming implementations. That was >> a little rocky early on for some errors, but those are now almost purely >> historical. We generate zero INADEQUATE_SECURITY errors now, where it was >> a little difficult early one (I'm looking at a sample of 4 billion that >> claim). That same attitude has served us well with that protocol thus >> far. >> >> _______________________________________________ >> Architecture-discuss mailing list >> Architecture-discuss@ietf.org >> https://www.ietf.org/mailman/listinfo/architecture-discuss >> > > _______________________________________________ > Architecture-discuss mailing list > Architecture-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/architecture-discuss > --000000000000aae29e056cf80959 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
The reason I was asking for examples is exactly that: from= my experience, the case of implementations not accepting valid input and t= hen forcing everybody else, by market dominance or avoiding blame, to imple= ment either restricted or wrong behavior. Common cases I have seen:
* t= he spec says case-insensitive, but applications are case-sensitive;
* the spec doesn't say ASCII or even explicitly allows binary or UTF= -8 content, but the implementation barfs on anything but ASCII;
*= the spec has extension mechanisms that demand that unknown elements (heade= rs) get passed unmodified, but intermediate entities don't ("for s= ecurity reasons");
* the spec doesn't impose a length li= mit (or a very liberal one), but the implementation does.

This seems more common in text-based protocols as these often seem = to get implemented by looking at the examples only.

Beyond the sips: case, there's the well-known SIP multi-part payload = case.

This occurs even if the "intolerant"= application is in the minority, not just for market-dominant implementatio= ns. See
for one take on this.

One good example of where protocols have to "reign in" a= pplications might be RFC 2822, Section 4 and A.6

<= pre style=3D"color:rgb(0,0,0);font-style:normal;font-variant-ligatures:norm= al;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-alig= n:start;text-indent:0px;text-transform:none;word-spacing:0px;text-decoratio= n-style:initial;text-decoration-color:initial;word-wrap:break-word;white-sp= ace:pre-wrap"> Earlier versions of this standard allowed for different (usu= ally more liberal) syntax than is allowed in this version. Also, there have been syntactic elements used in messages on the Internet whose interpretation have never been documented. 
The following are examples of obsolete (that is, the "MUST NOT ge=
nerate") syntactic elements described in section 4 of this document.

Henning


On Thu, May 24, 2018 at 2:0= 9 PM, Robert Sparks <rjsparks@nostrum.com> wrote:


On 5/23/18 9:39 PM, Martin Thomson wrote:
On Sun, May 20, 2018 at 1:34 AM Christian Huitema <huitema@huitema.net>
wrote:
My worry with "policing in production" is that it places a lot of= power
in the dominant implementations, and can lead to big barriers of entry for<= br> competing new implementations. We sort of see that today in the browser
market.

Yes, we've seen the effect that a need to interoperate with big players=
causes.=C2=A0 That's something I'm quite sensitive to, and as a bro= wser I know
we try hard to avoid using the power we don't want to have.=C2=A0 But w= e don't
always succeed.

What I've observed there is that ensuring that specifications match rea= lity
has helped new implementations considerably.
So, there was a case in SIP where an influential vendor had a bug in their = parser
that caused them to fail if they received a message formatted correctly acc= ording
to RFC3261 (this is the lr; vs lr=3Dtrue; in Via header field values issue = - you can
find a lot about it digging through the sip-implementors archives). It took= , IIRC,
more than a year before their heavily deployed application was updated to a= ccept
what the specification said. During that year (and for a few years after) a= ll
implementations spoke the lr=3Dtrue; variant. After the bug was fixed, and = a couple
of years passed, the implementation base universally went back to lr;

If I read what you suggest correctly, you would have preferred that the IET= F have
updated 3261 shortly after it was clear that this variant was pervasive in = deployment,
and updated it again after the variant went away? Or do I misunderstand the= time-scope
of ensuring that specifications match reality above? If I have it right, no= te that there is
a frog-boiling problem on when to decide to reflect the variant in the spec= ifications.
For the high-order vs low-order bit variant discussed earlier, when would i= t have been
reasonable for the specs to be changed?

Also, please reread the above paragraph substituting "bug" for &q= uot;variant" and see if it
changes anything.

Then reread it thinking "sips:".

RjS
=C2=A0 If you need to be bug-for-bug
compatible in a particular way, documenting that as an interoperability
requirement in a specification means that new implementations have less of<= br> a barrier to entry.=C2=A0 The dominant implementation might have all the existing code, but they also suffer from the other problems of incumbency (more users, more use cases, more legacy code, etc...).=C2=A0 It's not = perfect,
but were specifications not maintained, the costs for entry would be hard to understand.

In the end, if big implementations match the spec, then it's probably O= K.
That means the spec remains relevant.

This was the lesson from deploying HTTP/2.=C2=A0 If existing implementation= s
took steps to exclude implementations that violated rules of the
specification, then we got fewer non-conforming implementations.=C2=A0 That= was
a little rocky early on for some errors, but those are now almost purely historical.=C2=A0 We generate zero INADEQUATE_SECURITY errors now, where it= was
a little difficult early one (I'm looking at a sample of 4 billion that=
claim).=C2=A0 That same attitude has served us well with that protocol thus= far.

_______________________________________________
Architecture-discuss mailing list
Architec= ture-discuss@ietf.org
https://www.ietf.org/mailman/listinf= o/architecture-discuss

_______________________________________________
Architecture-discuss mailing list
Architec= ture-discuss@ietf.org
https://www.ietf.org/mailman/listinf= o/architecture-discuss

--000000000000aae29e056cf80959-- From nobody Thu May 24 11:53:21 2018 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 6AFEF12EB14 for ; Thu, 24 May 2018 11:53:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.988 X-Spam-Level: X-Spam-Status: No, score=-1.988 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=strayalpha.com 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 1xTa1XSdNTJo for ; Thu, 24 May 2018 11:53:04 -0700 (PDT) Received: from server217-3.web-hosting.com (server217-3.web-hosting.com [198.54.115.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 97ADB12EB10 for ; Thu, 24 May 2018 11:53:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=Message-ID:References:In-Reply-To:Subject:Cc: To:From:Date:Content-Type:MIME-Version:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=tswO1Zr/3pKzkJZBG5MkmwRWHO1cIFjH5HhyfrCoCT4=; b=YCDQH9tg62eDwhSC4hABhigE5 bAXTTNUZeLUvGX6f66a2LJucamINq8mP4x21KwNHNeTX/vbCiZ0OHkzNGm2qfw5sgoIvwLE0hMHUK U/9pZ5BH994Q5nuXlh6sTJ9s9Fp/dGnhpIneVfnn2Sd47F4luSncmEUQUiT9t7bE1ztMVKFyZ9jtF HWe3frx41LryQqp8IcBdTrnlzlvtkHyJNps+HLqIPG/JOX3R9kD9UIry3pb3RxGr5l8u20Xg454cR X629LCkeI/IBgbOb2NFu+DMLO5yTh55E0MsULo8SUZBWiU2AQcO6Nf9bkSlUYA0EFQJLDs0SiyHSX /L7jX3I6g==; Received: from [::1] (port=52260 helo=server217.web-hosting.com) by server217.web-hosting.com with esmtpa (Exim 4.91) (envelope-from ) id 1fLvME-003cXj-M8; Thu, 24 May 2018 14:53:03 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_667484e8f23de4c2285c9b6b908a8d6a" Date: Thu, 24 May 2018 11:53:02 -0700 From: Joe Touch To: Henning Schulzrinne Cc: Robert Sparks , architecture-discuss@ietf.org In-Reply-To: References: <152538075241.4552.6760702690778529507@ietfa.amsl.com> Message-ID: <370fc7abe18207138498d335bb688a7e@strayalpha.com> X-Sender: touch@strayalpha.com User-Agent: Roundcube Webmail/1.3.3 X-OutGoing-Spam-Status: No, score=-1.0 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server217.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - strayalpha.com X-Get-Message-Sender-Via: server217.web-hosting.com: authenticated_id: touch@strayalpha.com X-Authenticated-Sender: server217.web-hosting.com: touch@strayalpha.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Subject: Re: [arch-d] I-D Action: draft-iab-protocol-maintenance-00.txt X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.22 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: Thu, 24 May 2018 18:53:20 -0000 --=_667484e8f23de4c2285c9b6b908a8d6a Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Hi, Henning, These cases are somewhat different, IMO, as noted below. On 2018-05-24 11:43, Henning Schulzrinne wrote: > The reason I was asking for examples is exactly that: from my experience, the case of implementations not accepting valid input and then forcing everybody else, by market dominance or avoiding blame, to implement either restricted or wrong behavior. Common cases I have seen: > * the spec says case-insensitive, but applications are case-sensitive; I don't think it's being "generous" to go outside explicit spec requirements. The implementation is in violation of the spec. > * the spec doesn't say ASCII or even explicitly allows binary or UTF-8 content, but the implementation barfs on anything but ASCII; That implementation is, IMO, too restrictive. We can't say it's in violation of the spec, but clearly in violation of the Postal Principle - and a good example of where it is important, IMO. > * the spec has extension mechanisms that demand that unknown elements (headers) get passed unmodified, but intermediate entities don't ("for security reasons"); Those intermediate entities are in violation of the spec. I don't care what their reasons are - if they want to block a protocol for"security reasons", fine, but don't half-block and half-allow... > * the spec doesn't impose a length limit (or a very liberal one), but the implementation does. Strictly, the implementation should allow fairly large sizes to be as generous as possible (Postel Principle), but it's reasonable to have a limit to how generous it can be (e.g., resource limitations). Being generous doesn't mean shooting yourself in the foot. ---- > This seems more common in text-based protocols as these often seem to get implemented by looking at the examples only. > > Beyond the sips: case, there's the well-known SIP multi-part payload case. > > This occurs even if the "intolerant" application is in the minority, not just for market-dominant implementations. See > https://medium.com/incerto/the-most-intolerant-wins-the-dictatorship-of-the-small-minority-3f1f83ce4e15 > for one take on this. > > One good example of where protocols have to "reign in" applications might be RFC 2822, Section 4 and A.6 > > Earlier versions of this standard allowed for different (usually more > liberal) syntax than is allowed in this version. Also, there have > been syntactic elements used in messages on the Internet whose > interpretation have never been documented. > > The following are examples of obsolete (that is, the "MUST NOT generate") syntactic elements described in section 4 of this document. > > Henning > > On Thu, May 24, 2018 at 2:09 PM, Robert Sparks wrote: > > On 5/23/18 9:39 PM, Martin Thomson wrote: > On Sun, May 20, 2018 at 1:34 AM Christian Huitema > wrote: > My worry with "policing in production" is that it places a lot of power in the dominant implementations, and can lead to big barriers of entry for > competing new implementations. We sort of see that today in the browser > market. > > Yes, we've seen the effect that a need to interoperate with big players > causes. That's something I'm quite sensitive to, and as a browser I know > we try hard to avoid using the power we don't want to have. But we don't > always succeed. > > What I've observed there is that ensuring that specifications match reality > has helped new implementations considerably. So, there was a case in SIP where an influential vendor had a bug in their parser that caused them to fail if they received a message formatted correctly according to RFC3261 (this is the lr; vs lr=true; in Via header field values issue - you can find a lot about it digging through the sip-implementors archives). It took, IIRC, more than a year before their heavily deployed application was updated to accept what the specification said. During that year (and for a few years after) all implementations spoke the lr=true; variant. After the bug was fixed, and a couple of years passed, the implementation base universally went back to lr; If I read what you suggest correctly, you would have preferred that the IETF have updated 3261 shortly after it was clear that this variant was pervasive in deployment, and updated it again after the variant went away? Or do I misunderstand the time-scope of ensuring that specifications match reality above? If I have it right, note that there is a frog-boiling problem on when to decide to reflect the variant in the specifications. For the high-order vs low-order bit variant discussed earlier, when would it have been reasonable for the specs to be changed? Also, please reread the above paragraph substituting "bug" for "variant" and see if it changes anything. Then reread it thinking "sips:". RjS > If you need to be bug-for-bug > compatible in a particular way, documenting that as an interoperability > requirement in a specification means that new implementations have less of > a barrier to entry. The dominant implementation might have all the > existing code, but they also suffer from the other problems of incumbency > (more users, more use cases, more legacy code, etc...). It's not perfect, > but were specifications not maintained, the costs for entry would be hard > to understand. > > In the end, if big implementations match the spec, then it's probably OK. > That means the spec remains relevant. > > This was the lesson from deploying HTTP/2. If existing implementations > took steps to exclude implementations that violated rules of the > specification, then we got fewer non-conforming implementations. That was > a little rocky early on for some errors, but those are now almost purely > historical. We generate zero INADEQUATE_SECURITY errors now, where it was > a little difficult early one (I'm looking at a sample of 4 billion that > claim). That same attitude has served us well with that protocol thus far. > > _______________________________________________ > Architecture-discuss mailing list > Architecture-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/architecture-discuss _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www.ietf.org/mailman/listinfo/architecture-discuss _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www.ietf.org/mailman/listinfo/architecture-discuss --=_667484e8f23de4c2285c9b6b908a8d6a Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=UTF-8


 

Hi, Henning,

These cases are somewhat different, IMO, as noted below.

On 2018-05-24 11:43, Henning Schulzrinne wrote:

The reason I was asking for examples is exactly that: from= my experience, the case of implementations not accepting valid input and t= hen forcing everybody else, by market dominance or avoiding blame, to imple= ment either restricted or wrong behavior. Common cases I have seen:
* the spec says case-insensitive, but applications are case-sensitive;=
 
I don't think it's being "generous" to go outside explicit spec requir= ements. The implementation is in violation of the spec.
 
* the spec doesn't say ASCII or even explicitly allows binary or UTF-8= content, but the implementation barfs on anything but ASCII;
 
That implementation is, IMO, too restrictive. We can't say it's in vio= lation of the spec, but clearly in violation of the Postal Principle - and = a good example of where it is important, IMO.
 
* the spec has extension mechanisms that demand that unknown elements = (headers) get passed unmodified, but intermediate entities don't ("for secu= rity reasons");
 
Those intermediate entities are in violation of the spec. I don't care= what their reasons are - if they want to block a protocol for"security rea= sons", fine, but don't half-block and half-allow...
 
* the spec doesn't impose a length limit (or a very liberal one), but = the implementation does.
 
Strictly, the implementation should allow fairly large sizes to be as = generous as possible (Postel Principle), but it's reasonable to have a limi= t to how generous it can be (e.g., resource limitations). Being generous do= esn't mean shooting yourself in the foot.
 
----
 
This seems more common in text-based protocols as these often seem to = get implemented by looking at the examples only.
 
Beyond the sips: case, there's the well-known SIP multi-part payload c= ase.
 
This occurs even if the "intolerant" application is in the minority, n= ot just for market-dominant implementations. See
for one take on this.
 
One good example of where protocols have to "reign in" applications mi= ght be RFC 2822, Section 4 and A.6
 
 Earlier versions of this standard =
allowed for different (usually more
   liberal) syntax than is allowed in this version.  Also, there have
   been syntactic elements used in messages on the Internet whose
   interpretation have never been documented. 
The following are examples of obsol=
ete (that is, the "MUST NOT generate") syntactic elements described in sect=
ion 4 of this document.
 
Henning
 

On Thu, May 24, 2018 at 2:09 PM, Robert Sparks <= span><rjsparks@nostrum.com&g= t; wrote:


On 5/23/18 9:39 PM, Marti= n Thomson wrote:
On Sun, May 20, 2018 at 1:34 AM Christ= ian Huitema <huitema@huitema.net<= /a>>
wrote:
My worry with "policing in production"= is that it places a lot of power
in the dominant implementations, and can lead to big barriers of entry for<= br /> competing new implementations. We sort of see that today in the brows= er
market.

Yes, we've seen the effect that a need to inte= roperate with big players
causes.  That's something I'm quite se= nsitive to, and as a browser I know
we try hard to avoid using the po= wer we don't want to have.  But we don't
always succeed.
What I've observed there is that ensuring that specifications match re= ality
has helped new implementations considerably.
So, there was a case in SIP where an influential vendor had a bug in their = parser
that caused them to fail if they received a message formatted = correctly according
to RFC3261 (this is the lr; vs lr=3Dtrue; in Via = header field values issue - you can
find a lot about it digging throu= gh the sip-implementors archives). It took, IIRC,
more than a year be= fore their heavily deployed application was updated to accept
what th= e specification said. During that year (and for a few years after) all
implementations spoke the lr=3Dtrue; variant. After the bug was fixed, an= d a couple
of years passed, the implementation base universally went = back to lr;

If I read what you suggest correctly, you would hav= e preferred that the IETF have
updated 3261 shortly after it was clea= r that this variant was pervasive in deployment,
and updated it again= after the variant went away? Or do I misunderstand the time-scope
of= ensuring that specifications match reality above? If I have it right, note= that there is
a frog-boiling problem on when to decide to reflect th= e variant in the specifications.
For the high-order vs low-order bit = variant discussed earlier, when would it have been
reasonable for the= specs to be changed?

Also, please reread the above paragraph s= ubstituting "bug" for "variant" and see if it
changes anything.
=
Then reread it thinking "sips:".

RjS
  If you need to be bug-for-bug compatible in a particular way, documenting that as an interoperabilit= y
requirement in a specification means that new implementations have = less of
a barrier to entry.  The dominant implementation might h= ave all the
existing code, but they also suffer from the other proble= ms of incumbency
(more users, more use cases, more legacy code, etc= =2E..).  It's not perfect,
but were specifications not maintaine= d, the costs for entry would be hard
to understand.

In th= e end, if big implementations match the spec, then it's probably OK.
= That means the spec remains relevant.

This was the lesson from = deploying HTTP/2.  If existing implementations
took steps to exc= lude implementations that violated rules of the
specification, then w= e got fewer non-conforming implementations.  That was
a little r= ocky early on for some errors, but those are now almost purely
histor= ical.  We generate zero INADEQUATE_SECURITY errors now, where it was a little difficult early one (I'm looking at a sample of 4 billion tha= t
claim).  That same attitude has served us well with that proto= col thus far.

_______________________________________________ Architecture-discuss mailing list
Architecture-discuss@ietf.org
https://www.ietf.org/mailman/listinfo/architecture= -discuss

_______________________________________________
Architecture-d= iscuss mailing list
A= rchitecture-discuss@ietf.org
https://www.ietf.org/mailman/listinfo/architecture-discuss

= _______________________________________________
Architecture-discuss = mailing list
Architec= ture-discuss@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/architecture-discuss
--=_667484e8f23de4c2285c9b6b908a8d6a-- From nobody Thu May 24 12:09:55 2018 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 2DBC312EAEA for ; Thu, 24 May 2018 12:09:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 yT4bXzJfW3kS for ; Thu, 24 May 2018 12:09:51 -0700 (PDT) Received: from outprodmail02.cc.columbia.edu (outprodmail02.cc.columbia.edu [128.59.72.51]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 58E4C12E8E4 for ; Thu, 24 May 2018 12:09:51 -0700 (PDT) Received: from hazelnut (hazelnut.cc.columbia.edu [128.59.213.250]) by outprodmail02.cc.columbia.edu (8.14.4/8.14.4) with ESMTP id w4OJ53Jb050856 for ; Thu, 24 May 2018 15:09:49 -0400 Received: from hazelnut (localhost.localdomain [127.0.0.1]) by hazelnut (Postfix) with ESMTP id 54CA184 for ; Thu, 24 May 2018 15:09:49 -0400 (EDT) Received: from sendprodmail04.cc.columbia.edu (sendprodmail04.cc.columbia.edu [128.59.72.16]) by hazelnut (Postfix) with ESMTP id 5DEED87 for ; Thu, 24 May 2018 15:09:48 -0400 (EDT) Received: from mail-oi0-f69.google.com (mail-oi0-f69.google.com [209.85.218.69]) by sendprodmail04.cc.columbia.edu (8.14.4/8.14.4) with ESMTP id w4OJ9lia021493 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT) for ; Thu, 24 May 2018 15:09:48 -0400 Received: by mail-oi0-f69.google.com with SMTP id u13-v6so1342091oif.0 for ; Thu, 24 May 2018 12:09:48 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Wy4VUw9fkUkMiMQRl01m/v9Bd2gR79lvzf5ElkS8zyY=; b=tAitAbZ1I5VurIDrQl1KUs+7X1iEYzjbrCYfR8056cVfMtow1H+QyztdaPdvCrbdP+ KSa5IEJz1BcStojP+Kcc0s0+tk5o3v4Z1rN0Rqqt6t2NZ2nFbbAMpvXGoWAa1UTEmUbW UBZoQMM9mWa9gq4k/u9rXWdh0p9ZFPj5fNV4nMlXzKvDPXy02AWw2Z0UxxPIBk+d+0U+ njsKO9VTlm1titfd7z6fHJ38Sn2/2FN4Wo8mq1ERUPP/fJIBgIvNNFr+YzLEEsdGAILO xjq7KCQ2/1e54fZnKkl6CN2eZGq123VnN74Sn7leNq0LBAE8codlNn+jEe7+/S2jNxtU Bz+A== X-Gm-Message-State: ALKqPwdrdRRBKwcpE7gAqTpq+xZm2Peu+Sz6xNPEHa3BgZtC82oSew7V wbl3leTcI/2Uiwr1cIGUcRuouWUIWxFHGnCGqcdaSHUg0Zsg/jcE51oalggTDDmORrkJEESk/F0 tkSjS32NxNxiyugtGmSK65Nw1wUeETz2KuSMpW9k2mcmmSznA1Q== X-Received: by 2002:aca:2b14:: with SMTP id i20-v6mr4284868oik.239.1527188986955; Thu, 24 May 2018 12:09:46 -0700 (PDT) X-Google-Smtp-Source: AB8JxZodrAIhF7/ufFued/gPa7+HorZaU+CYpEOI87bTf4zFNMGKP7TD2MBDUy6XEClh4k0760c4gYlwyJhPk2rAz3Q= X-Received: by 2002:aca:2b14:: with SMTP id i20-v6mr4284854oik.239.1527188986588; Thu, 24 May 2018 12:09:46 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a9d:59cd:0:0:0:0:0 with HTTP; Thu, 24 May 2018 12:09:26 -0700 (PDT) In-Reply-To: <370fc7abe18207138498d335bb688a7e@strayalpha.com> References: <152538075241.4552.6760702690778529507@ietfa.amsl.com> <370fc7abe18207138498d335bb688a7e@strayalpha.com> From: Henning Schulzrinne Date: Thu, 24 May 2018 15:09:26 -0400 Message-ID: To: Joe Touch Cc: Robert Sparks , architecture-discuss@ietf.org Content-Type: multipart/alternative; boundary="0000000000000d06d5056cf86565" X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.78 on 128.59.72.16 Archived-At: Subject: Re: [arch-d] I-D Action: draft-iab-protocol-maintenance-00.txt X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.22 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: Thu, 24 May 2018 19:09:54 -0000 --0000000000000d06d5056cf86565 Content-Type: text/plain; charset="UTF-8" Indeed, we are agreeing and I wasn't clear on my point. What I'm saying is that most cases (except the egregious "protocol dialects" mentioned earlier), the problem doesn't seem to be the Postel principle, but overly restrictive implementations that then force other applications to "dumb down" the spec that can be implemented or work around the limitations. This is why is was asking for examples where "liberal acceptance" caused problems as I'm having a hard time coming up with examples, with the exception of the 2822 gray areas mentioned (which seem to fit into the "it made sense at one time" or "we didn't really mean to allow this"). What I'm looking for is where an overly liberal implementation forced others to conform to their errant ways. I can think of lots of overly conservative examples forcing implementations to change their behavior, as per my list. (Temptation to draw political analogies resisted.) Henning On Thu, May 24, 2018 at 2:53 PM, Joe Touch wrote: > > > > Hi, Henning, > > These cases are somewhat different, IMO, as noted below. > > On 2018-05-24 11:43, Henning Schulzrinne wrote: > > The reason I was asking for examples is exactly that: from my experience, > the case of implementations not accepting valid input and then forcing > everybody else, by market dominance or avoiding blame, to implement either > restricted or wrong behavior. Common cases I have seen: > * the spec says case-insensitive, but applications are case-sensitive; > > > I don't think it's being "generous" to go outside explicit spec > requirements. The implementation is in violation of the spec. > > > * the spec doesn't say ASCII or even explicitly allows binary or UTF-8 > content, but the implementation barfs on anything but ASCII; > > > That implementation is, IMO, too restrictive. We can't say it's in > violation of the spec, but clearly in violation of the Postal Principle - > and a good example of where it is important, IMO. > > > * the spec has extension mechanisms that demand that unknown elements > (headers) get passed unmodified, but intermediate entities don't ("for > security reasons"); > > > Those intermediate entities are in violation of the spec. I don't care > what their reasons are - if they want to block a protocol for"security > reasons", fine, but don't half-block and half-allow... > > > * the spec doesn't impose a length limit (or a very liberal one), but the > implementation does. > > > Strictly, the implementation should allow fairly large sizes to be as > generous as possible (Postel Principle), but it's reasonable to have a > limit to how generous it can be (e.g., resource limitations). Being > generous doesn't mean shooting yourself in the foot. > > ---- > > > This seems more common in text-based protocols as these often seem to get > implemented by looking at the examples only. > > Beyond the sips: case, there's the well-known SIP multi-part payload case. > > This occurs even if the "intolerant" application is in the minority, not > just for market-dominant implementations. See > https://medium.com/incerto/the-most-intolerant-wins-the- > dictatorship-of-the-small-minority-3f1f83ce4e15 > for one take on this. > > One good example of where protocols have to "reign in" applications might > be RFC 2822, Section 4 and A.6 > > > Earlier versions of this standard allowed for different (usually more > liberal) syntax than is allowed in this version. Also, there have > been syntactic elements used in messages on the Internet whose > interpretation have never been documented. > > The following are examples of obsolete (that is, the "MUST NOT generate") syntactic elements described in section 4 of this document. > > > Henning > > --0000000000000d06d5056cf86565 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Indeed, we are agreeing and I wasn't clear on my point= . What I'm saying is that most cases (except the egregious "protoc= ol dialects" mentioned earlier), the problem doesn't seem to be th= e Postel principle, but overly restrictive implementations that then force = other applications to "dumb down" the spec that can be implemente= d or work around the limitations.

This is why is was ask= ing for examples where "liberal acceptance" caused problems as I&= #39;m having a hard time coming up with examples, with the exception of the= 2822 gray areas mentioned (which seem to fit into the "it made sense = at one time" or "we didn't really mean to allow this").<= /div>

What I'm looking for is where an overly libera= l implementation forced others to conform to their errant ways. I can think= of lots of overly conservative examples forcing implementations to change = their behavior, as per my list. (Temptation to draw political analogies res= isted.)

Henning

=
On Thu, May 24, 2018 at 2:53 PM, Joe Touch <= touch@strayalpha.com> wrote:


=C2=A0

Hi, Henning,

These cases are somewhat different, IMO, as noted below.

On 2018-05-24 11:43, Henning Schulzrinne wrote:

The reason I was asking for examples is exactly that: from= my experience, the case of implementations not accepting valid input and t= hen forcing everybody else, by market dominance or avoiding blame, to imple= ment either restricted or wrong behavior. Common cases I have seen:
* the spec says case-insensitive, but applications are case-sensitive;=
=C2=A0
I don't think it's being "generous" to go outside ex= plicit spec requirements. The implementation is in violation of the spec.
=C2=A0
* the spec doesn't say ASCII or even explicitly allows binary or U= TF-8 content, but the implementation barfs on anything but ASCII;
=C2=A0
That implementation is, IMO, too restrictive. We can't say it'= s in violation of the spec, but clearly in violation of the Postal Principl= e - and a good example of where it is important, IMO.
=C2=A0
* the spec has extension mechanisms that demand that unknown elements = (headers) get passed unmodified, but intermediate entities don't ("= ;for security reasons");
=C2=A0
Those intermediate entities are in violation of the spec. I don't = care what their reasons are - if they want to block a protocol for"sec= urity reasons", fine, but don't half-block and half-allow...
=C2=A0
* the spec doesn't impose a length limit (or a very liberal one), = but the implementation does.
=C2=A0
Strictly, the implementation should allow fairly large sizes to be as = generous as possible (Postel Principle), but it's reasonable to have a = limit to how generous it can be (e.g., resource limitations). Being generou= s doesn't mean shooting yourself in the foot.
=C2=A0
----
=C2=A0
This seems more common in text-based protocols as these often seem to = get implemented by looking at the examples only.
=C2=A0
Beyond the sips: case, there's the well-known SIP multi-part paylo= ad case.
=C2=A0
This occurs even if the "intolerant" application is in the m= inority, not just for market-dominant implementations. See
for one take on this.
=C2=A0
One good example of where protocols have to "reign in" appli= cations might be RFC 2822, Section 4 and A.6
=C2=A0
 Earlier versions of this standard allowed for different (usual=
ly more
   liberal) syntax than is allowed in this version.  Also, there have
   been syntactic elements used in messages on the Internet whose
   interpretation have never been documented. 
The following are examples of obsolete (that is, the "MUST=
 NOT generate") syntactic elements described in section 4 of this docu=
ment.
=C2=A0
Henning

--0000000000000d06d5056cf86565-- From nobody Thu May 24 12:18:54 2018 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 E5A48128961 for ; Thu, 24 May 2018 12:18:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.988 X-Spam-Level: X-Spam-Status: No, score=-1.988 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=strayalpha.com 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 3saSGdsZXc_z for ; Thu, 24 May 2018 12:18:49 -0700 (PDT) Received: from server217-3.web-hosting.com (server217-3.web-hosting.com [198.54.115.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 02276127869 for ; Thu, 24 May 2018 12:18:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=Message-ID:References:In-Reply-To:Subject:Cc: To:From:Date:Content-Type:MIME-Version:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=vy7J30LuCiRinBL9AGxfwx3OGreQKKCXfTrFExyFjnM=; b=NmdMrTitdMOz5K+7xr6k3Vh0H 6NGVzr1N/2jmdxmkUmRS6uBrhtjAxbOcJ7OTVIwju1ejYk+dxoizXnU6ms4N/Gt53RiGP30to3f3x B6sudHLFzkvHG/BFTUAABnRt1mSr3Hnwq1QlyoGnKo1rvcyne8gTjPW/oGBKnwm4oiIQtMVgQYyer PlhsYgPsnEIwekhiQOwAR0F6eUU9k2JDVIHmtVmtvYgpAttLDO2YGvK/KPrqHyAXNHed8TzZ0vTRE mHt3wohV3wmh0H6XFXAt4HFN8j9YA+usMF2alUzSWzfJfEAToXs5FPkb1j5TisaWRTizzo4d2c3qb Z+xMa9h8A==; Received: from [::1] (port=51466 helo=server217.web-hosting.com) by server217.web-hosting.com with esmtpa (Exim 4.91) (envelope-from ) id 1fLvl8-003ygr-Rm; Thu, 24 May 2018 15:18:47 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_df21d5757199fa9490668349dac34ac8" Date: Thu, 24 May 2018 12:18:46 -0700 From: Joe Touch To: Henning Schulzrinne Cc: Robert Sparks , architecture-discuss@ietf.org In-Reply-To: References: <152538075241.4552.6760702690778529507@ietfa.amsl.com> <370fc7abe18207138498d335bb688a7e@strayalpha.com> Message-ID: <9ef0db90cc9c99b597918a6d92257228@strayalpha.com> X-Sender: touch@strayalpha.com User-Agent: Roundcube Webmail/1.3.3 X-OutGoing-Spam-Status: No, score=-1.0 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server217.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - strayalpha.com X-Get-Message-Sender-Via: server217.web-hosting.com: authenticated_id: touch@strayalpha.com X-Authenticated-Sender: server217.web-hosting.com: touch@strayalpha.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Subject: Re: [arch-d] I-D Action: draft-iab-protocol-maintenance-00.txt X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.22 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: Thu, 24 May 2018 19:18:52 -0000 --=_df21d5757199fa9490668349dac34ac8 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII On 2018-05-24 12:09, Henning Schulzrinne wrote: > Indeed, we are agreeing and I wasn't clear on my point. What I'm saying is that most cases (except the egregious "protocol dialects" mentioned earlier), the problem doesn't seem to be the Postel principle, but overly restrictive implementations that then force other applications to "dumb down" the spec that can be implemented or work around the limitations. Generally, I would agree - I saw this in the constant stream of TCP "additions" based on what was deployed that I felt only served to make TCP more fragile by violating the Postal Principle. I pushed to have those deviations called "bugs", not "de-facto deployment features". > This is why is was asking for examples where "liberal acceptance" caused problems as I'm having a hard time coming up with examples, with the exception of the 2822 gray areas mentioned (which seem to fit into the "it made sense at one time" or "we didn't really mean to allow this"). We could argue that accepting RSTs anywhere in the TCP window was over-application of the Postal Principle caused the vulnerabilities described in RFC 4953, and RFC 5961 closed that gap. > What I'm looking for is where an overly liberal implementation forced others to conform to their errant ways. See above, but it's a tough call. I tend to think that one is a case of robustness in the face of reboot which now might require an exchange to clean up, though. > I can think of lots of overly conservative examples forcing implementations to change their behavior, as per my list. (Temptation to draw political analogies resisted.) > > Henning > > On Thu, May 24, 2018 at 2:53 PM, Joe Touch wrote: > > Hi, Henning, > > These cases are somewhat different, IMO, as noted below. > > On 2018-05-24 11:43, Henning Schulzrinne wrote: > The reason I was asking for examples is exactly that: from my experience, the case of implementations not accepting valid input and then forcing everybody else, by market dominance or avoiding blame, to implement either restricted or wrong behavior. Common cases I have seen: > * the spec says case-insensitive, but applications are case-sensitive; > > I don't think it's being "generous" to go outside explicit spec requirements. The implementation is in violation of the spec. > > * the spec doesn't say ASCII or even explicitly allows binary or UTF-8 content, but the implementation barfs on anything but ASCII; > > That implementation is, IMO, too restrictive. We can't say it's in violation of the spec, but clearly in violation of the Postal Principle - and a good example of where it is important, IMO. > > * the spec has extension mechanisms that demand that unknown elements (headers) get passed unmodified, but intermediate entities don't ("for security reasons"); > > Those intermediate entities are in violation of the spec. I don't care what their reasons are - if they want to block a protocol for"security reasons", fine, but don't half-block and half-allow... > > * the spec doesn't impose a length limit (or a very liberal one), but the implementation does. > > Strictly, the implementation should allow fairly large sizes to be as generous as possible (Postel Principle), but it's reasonable to have a limit to how generous it can be (e.g., resource limitations). Being generous doesn't mean shooting yourself in the foot. > ---- > > This seems more common in text-based protocols as these often seem to get implemented by looking at the examples only. > Beyond the sips: case, there's the well-known SIP multi-part payload case. > This occurs even if the "intolerant" application is in the minority, not just for market-dominant implementations. See > https://medium.com/incerto/the-most-intolerant-wins-the-dictatorship-of-the-small-minority-3f1f83ce4e15 > for one take on this. > One good example of where protocols have to "reign in" applications might be RFC 2822, Section 4 and A.6 > > Earlier versions of this standard allowed for different (usually more > liberal) syntax than is allowed in this version. Also, there have > been syntactic elements used in messages on the Internet whose > interpretation have never been documented. > > The following are examples of obsolete (that is, the "MUST NOT generate") syntactic elements described in section 4 of this document. > > Henning --=_df21d5757199fa9490668349dac34ac8 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=UTF-8


 


On 2018-05-24 12:09, Henning Schulzrinne wrote:

Indeed, we are agreeing and I wasn't clear on my point. Wh= at I'm saying is that most cases (except the egregious "protocol dialects" = mentioned earlier), the problem doesn't seem to be the Postel principle, bu= t overly restrictive implementations that then force other applications to = "dumb down" the spec that can be implemented or work around the limitations= =2E
 
Generally, I would agree - I saw this in the constant stream of TCP "a= dditions" based on what was deployed that I felt only served to make TCP mo= re fragile by violating the Postal Principle. I pushed to have those d= eviations called "bugs", not "de-facto deployment features".
 
This is why is was asking for examples where "liberal acceptance" caus= ed problems as I'm having a hard time coming up with examples, with the exc= eption of the 2822 gray areas mentioned (which seem to fit into the "it mad= e sense at one time" or "we didn't really mean to allow this").
 
We could argue that accepting RSTs anywhere in the TCP window was over= -application of the Postal Principle caused the vulnerabilities described i= n RFC 4953, and RFC 5961 closed that gap.
 
What I'm looking for is where an overly liberal implementation forced = others to conform to their errant ways.
 
See above, but it's a tough call. I tend to think that one is a case o= f robustness in the face of reboot which now might require an exchange to c= lean up, though.
 
I can think of lots of overly conservative examples forcing implementa= tions to change their behavior, as per my list. (Temptation to draw politic= al analogies resisted.)
 
Henning

On Thu, May 24, 2018 at 2:53 PM, Joe Touch <touch@strayalpha.com> wrote:


Hi, Henning,

These cases are somewhat different, IMO, as noted below.

On 2018-05-24 11:43, Henning Schulzrinne wrote:

The reason I was asking for examples is exactly that: from= my experience, the case of implementations not accepting valid input and t= hen forcing everybody else, by market dominance or avoiding blame, to imple= ment either restricted or wrong behavior. Common cases I have seen:
* the spec says case-insensitive, but applications are case-sensitive;=
I don't think it's being "generous" to go outside explicit spec requir= ements. The implementation is in violation of the spec.
* the spec doesn't say ASCII or even explicitly allows binary or UTF-8= content, but the implementation barfs on anything but ASCII;
That implementation is, IMO, too restrictive. We can't say it's in vio= lation of the spec, but clearly in violation of the Postal Principle - and = a good example of where it is important, IMO.
* the spec has extension mechanisms that demand that unknown elements = (headers) get passed unmodified, but intermediate entities don't ("for secu= rity reasons");
Those intermediate entities are in violation of the spec. I don't care= what their reasons are - if they want to block a protocol for"security rea= sons", fine, but don't half-block and half-allow...
* the spec doesn't impose a length limit (or a very liberal one), but = the implementation does.
Strictly, the implementation should allow fairly large sizes to be as = generous as possible (Postel Principle), but it's reasonable to have a limi= t to how generous it can be (e.g., resource limitations). Being generous do= esn't mean shooting yourself in the foot.
----
This seems more common in text-based protocols as these often seem to = get implemented by looking at the examples only.
Beyond the sips: case, there's the well-known SIP multi-part payload c= ase.
This occurs even if the "intolerant" application is in the minority, n= ot just for market-dominant implementations. See
for one take on this.
One good example of where protocols have to "reign in" applications mi= ght be RFC 2822, Section 4 and A.6
 Earlier versions of this standard =
allowed for different (usually more
   liberal) syntax than is allowed in this version.  Also, there have
   been syntactic elements used in messages on the Internet whose
   interpretation have never been documented. 
The following are examples of obsol=
ete (that is, the "MUST NOT generate") syntactic elements described in sect=
ion 4 of this document.
Henning
--=_df21d5757199fa9490668349dac34ac8-- From nobody Thu May 24 13:56:58 2018 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 4899A12D7E5 for ; Thu, 24 May 2018 13:56:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=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 Kk9BLYsRbvYF for ; Thu, 24 May 2018 13:56:54 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 74D8112D77D for ; Thu, 24 May 2018 13:56:54 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 489A1300A2C for ; Thu, 24 May 2018 16:56:52 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id cZL4cXOdkbaA for ; Thu, 24 May 2018 16:56:51 -0400 (EDT) Received: from a860b60074bd.home (pool-108-45-101-150.washdc.fios.verizon.net [108.45.101.150]) by mail.smeinc.net (Postfix) with ESMTPSA id 36E50300537; Thu, 24 May 2018 16:56:51 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Russ Housley In-Reply-To: Date: Thu, 24 May 2018 16:56:52 -0400 Cc: architecture-discuss@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <5D59E88E-DB8B-4909-91A9-70AA90D77C29@vigilsec.com> References: <152538075241.4552.6760702690778529507@ietfa.amsl.com> <7E740995-3B63-4CE6-BC58-9DDC0F3BA07E@vigilsec.com> To: Henning Schulzrinne X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [arch-d] I-D Action: draft-iab-protocol-maintenance-00.txt X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.22 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: Thu, 24 May 2018 20:56:56 -0000 Henning: >=20 > I think this discussion would benefit from citing specific = (historical) examples. My hunch is that all the contributors to this = discussion have specific cases or issues in mind that may actually be = non-overlapping and may illustrate different problems. For example, some = may be ambiguities where the text omits some restriction that the ABNF = or more formal specification includes, and then implementations follow = the text. Sometimes the specification authors make the mistake, and when the = mistake is fixed implementation and other specifications are still = broken. Here is one that keeps causing trouble for me. Too many specifications allow two encodings for ASN.1 = AlgorithmIdentifier parameters. The two alternatives arise from the = loss of the OPTIONAL associated with the algorithm identifier parameters = when the 1988 syntax for AlgorithmIdentifier was translated into the = 1997 syntax. Later, the OPTIONAL was recovered via a defect report, but = by then many people thought that algorithm parameters were mandatory. = Because of this history, some implementations encode parameters as a = NULL element while others omit them entirely. The correct encoding is = to omit the parameters field; however, when some uses of these = algorithms were defined, it was done using the NULL parameters rather = than absent parameters. For example, PKCS#1 [RFC3447] requires that the = padding used for RSA signatures MUST use SHA2 AlgorithmIdentifiers with = NULL parameters. Russ From nobody Thu May 24 14:13:19 2018 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 9F2A112D7EF for ; Thu, 24 May 2018 14:13:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 OIAvu9bJEOvB for ; Thu, 24 May 2018 14:13:15 -0700 (PDT) Received: from outprodmail01.cc.columbia.edu (outprodmail01.cc.columbia.edu [128.59.72.39]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 677D412D77D for ; Thu, 24 May 2018 14:13:15 -0700 (PDT) Received: from hazelnut (hazelnut.cc.columbia.edu [128.59.213.250]) by outprodmail01.cc.columbia.edu (8.14.4/8.14.4) with ESMTP id w4OLAVM4021237 for ; Thu, 24 May 2018 17:13:14 -0400 Received: from hazelnut (localhost.localdomain [127.0.0.1]) by hazelnut (Postfix) with ESMTP id 534EE6D for ; Thu, 24 May 2018 17:13:14 -0400 (EDT) Received: from sendprodmail04.cc.columbia.edu (sendprodmail04.cc.columbia.edu [128.59.72.16]) by hazelnut (Postfix) with ESMTP id 214806D for ; Thu, 24 May 2018 17:13:14 -0400 (EDT) Received: from mail-ot0-f200.google.com (mail-ot0-f200.google.com [74.125.82.200]) by sendprodmail04.cc.columbia.edu (8.14.4/8.14.4) with ESMTP id w4OLDD36022466 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT) for ; Thu, 24 May 2018 17:13:14 -0400 Received: by mail-ot0-f200.google.com with SMTP id b5-v6so1699261otf.8 for ; Thu, 24 May 2018 14:13:13 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=CnfpYl/NdkcekaruPGpBgt7m+GYiyU1liMYlLbNS25Q=; b=kWohBAwmmoBs4m6F4a/8mse+wtbZCP533BOAX/D2mbDVVgiEdmh6Ms/iBGwzZ/VZOu ISvsEVbRAa+4UEiY9A8HO7vQRBN0hRP6nk1j8TpKsvEW0gh3m9En+4ziGZ45zDGXMBI/ SiL3I6xqfh4wqCuXOeLZkUmkAMa6vgx8Kv7FlDyy6SZRthlbU2GVrkcG2zkWa/J/kriR XKkvRqe0ID6TNibpEnSA+pBsMNnlahOuA8Ys/Lt2xpDb/WkFHVaVOAGLNewJJpz4WqTj rSQ2LbGHpDjCN8cIqfHbpYzYOfc/qi/jNBIEgmdfdmchP58FZYUFJhMzX9pHqNcXQ62u avOw== X-Gm-Message-State: ALKqPwcaF/GdfWllirVri+H5UtwDBMqfg3gH2rI7qalbPN38KNxvueaU Svq7tQIKpzVccFjujY/icxGHyB0IwKO6TZg5jZrT/4bEJQlCxlr2NU4qDpuM+JMCus+qXHYqzUI ql7YhZ4uAwy24+H09VMrtT6fOWzm5sz3/DiPeZroxVfYuIYUFXA== X-Received: by 2002:a9d:26e2:: with SMTP id i31-v6mr5352672otd.27.1527196393131; Thu, 24 May 2018 14:13:13 -0700 (PDT) X-Google-Smtp-Source: AB8JxZrqexeHnoiTsc55fGE81bl02CV28rC/2fmWjQrMJooy4i06kq2RbpOdDzy66v+X/+fMmydWpxmEroFLQPKLvuk= X-Received: by 2002:a9d:26e2:: with SMTP id i31-v6mr5352664otd.27.1527196392828; Thu, 24 May 2018 14:13:12 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a9d:59cd:0:0:0:0:0 with HTTP; Thu, 24 May 2018 14:12:52 -0700 (PDT) In-Reply-To: <5D59E88E-DB8B-4909-91A9-70AA90D77C29@vigilsec.com> References: <152538075241.4552.6760702690778529507@ietfa.amsl.com> <7E740995-3B63-4CE6-BC58-9DDC0F3BA07E@vigilsec.com> <5D59E88E-DB8B-4909-91A9-70AA90D77C29@vigilsec.com> From: Henning Schulzrinne Date: Thu, 24 May 2018 17:12:52 -0400 Message-ID: To: Russ Housley Cc: architecture-discuss@ietf.org Content-Type: multipart/alternative; boundary="0000000000007f4462056cfa1e32" X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.78 on 128.59.72.16 Archived-At: Subject: Re: [arch-d] I-D Action: draft-iab-protocol-maintenance-00.txt X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.22 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: Thu, 24 May 2018 21:13:18 -0000 --0000000000007f4462056cfa1e32 Content-Type: text/plain; charset="UTF-8" Interesting example. Sounds like we could use a checklist of common problem areas, some very specific (such as Russ' example) and some more generic (e.g., cautions about case-sensitivity and character sets). Henning On Thu, May 24, 2018 at 4:56 PM, Russ Housley wrote: > Henning: > > > > I think this discussion would benefit from citing specific (historical) > examples. My hunch is that all the contributors to this discussion have > specific cases or issues in mind that may actually be non-overlapping and > may illustrate different problems. For example, some may be ambiguities > where the text omits some restriction that the ABNF or more formal > specification includes, and then implementations follow the text. > > Sometimes the specification authors make the mistake, and when the mistake > is fixed implementation and other specifications are still broken. Here is > one that keeps causing trouble for me. > > Too many specifications allow two encodings for ASN.1 AlgorithmIdentifier > parameters. The two alternatives arise from the loss of the OPTIONAL > associated with the algorithm identifier parameters when the 1988 syntax > for AlgorithmIdentifier was translated into the 1997 syntax. Later, the > OPTIONAL was recovered via a defect report, but by then many people thought > that algorithm parameters were mandatory. Because of this history, some > implementations encode parameters as a NULL element while others omit them > entirely. The correct encoding is to omit the parameters field; however, > when some uses of these algorithms were defined, it was done using the NULL > parameters rather than absent parameters. For example, PKCS#1 [RFC3447] > requires that the padding used for RSA signatures MUST use SHA2 > AlgorithmIdentifiers with NULL parameters. > > Russ > > --0000000000007f4462056cfa1e32 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Interesting example. Sounds like we could use a checklist = of common problem areas, some very specific (such as Russ' example) and= some more generic (e.g., cautions about case-sensitivity and character set= s).

Henning

On Thu, May 24, 2018 at 4:56 PM, Russ Housley <housley@vigilsec.com> wrote:
Henning:
>
> I think this discussion would benefit from citing specific (historical= ) examples. My hunch is that all the contributors to this discussion have s= pecific cases or issues in mind that may actually be non-overlapping and ma= y illustrate different problems. For example, some may be ambiguities where= the text omits some restriction that the ABNF or more formal specification= includes, and then implementations follow the text.

Sometimes the specification authors make the mistake, and when the mistake = is fixed implementation and other specifications are still broken.=C2=A0 He= re is one that keeps causing trouble for me.

Too many specifications allow two encodings for ASN.1 AlgorithmIdentifier p= arameters.=C2=A0 The two alternatives arise from the loss of the OPTIONAL a= ssociated with the algorithm identifier parameters when the 1988 syntax for= AlgorithmIdentifier was translated into the 1997 syntax.=C2=A0 Later, the = OPTIONAL was recovered via a defect report, but by then many people thought= that algorithm parameters were mandatory.=C2=A0 Because of this history, s= ome implementations encode parameters as a NULL element while others omit t= hem entirely.=C2=A0 The correct encoding is to omit the parameters field; h= owever, when some uses of these algorithms were defined, it was done using = the NULL parameters rather than absent parameters.=C2=A0 For example, PKCS#= 1 [RFC3447] requires that the padding used for RSA signatures MUST use SHA2= AlgorithmIdentifiers with NULL parameters.

Russ


--0000000000007f4462056cfa1e32-- From nobody Thu May 24 15:04:17 2018 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 EB6AB12E8A1; Thu, 24 May 2018 15:04:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 v6f6HBLr_U0M; Thu, 24 May 2018 15:04:09 -0700 (PDT) Received: from mail-yw0-x236.google.com (mail-yw0-x236.google.com [IPv6:2607:f8b0:4002:c05::236]) (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 65A6C12E89C; Thu, 24 May 2018 15:04:09 -0700 (PDT) Received: by mail-yw0-x236.google.com with SMTP id u71-v6so1084453ywf.8; Thu, 24 May 2018 15:04:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Ik97aEVuVrzTw5m9P6craQO1HSM/eDHMAQSYV6iap7E=; b=bC0UGRmkCAYnbzYec1OQIFa2zh99JTgOnQ7bi01yiX2bYfTNjTH7Eavs9u7kYiEaku /mg/wrIYEXP+DBLhhvuWmVREOa0IjuslYuNs/ebAd39znqjs07sgIfQ+qs/Bsw/0tEjA kLWMrO1M8g0K4X4vCrSw1xVTi0fjS9vvbmv9F0eA7qkR7Wck0TXI+zv0p3bdLyxI2M2p jLE6kUa5yxSZ12PDeXLqYCU1ZsdH1FRduNgm44Qy2HZUiocr7ahJv1RujwaxCN464gZ6 qM1440fW1Lfaw8KaaNFr+RyM2iL3HabEki5asXSp4PXSl63uooZs2Iep7sde913zD5T7 FkYg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Ik97aEVuVrzTw5m9P6craQO1HSM/eDHMAQSYV6iap7E=; b=ON+s/t6MZDJMWHg9g/K9PPYpiLivFo3JWrVzlwd0ZkGdvRC5npv5V5QZZz/X5w+Hw6 fy8mvyu4T8GkLUkXKs1Vx2wAALZBQy1m608tj0/RZ+aFGZx24pEvjYGTdA/2FcnMU4eb FRslT3AV4cEi2vSDizCH6IBNvLrrtSdC/7hP3mM1I8bqgZWuEe+IUYQmpSr7XCHevEmA qX/YGAOTXbrBJnOFvUnyOctDXUU1LZ0nfRyYJB9Dhe4TRKhUvVSMK520f7O36q5Ct6oO qNH7qcrmnNYoffFkuIobB9o5Cl4E3tBAh4xCfBn2Svyjd6LqC06zikPsPhbLufyqcIgd uvow== X-Gm-Message-State: ALKqPwfSK/d2D15k0xzi88gqeiOkXvXTTDQAaq8vSxrDgANQsvpuUNQY 3Wy4iKBnNa5dQzPFJgzrn+s/7DPzWGYn/1Vlg1g= X-Google-Smtp-Source: AB8JxZr9KH1kKCLBP93UF3J5jLR8VNZSIXgCPGaAS+uai9CzznUHUjRQmTUqmJi8WenKoIT9sAN0hugCTgBIbo+mAnM= X-Received: by 2002:a0d:db07:: with SMTP id d7-v6mr2313006ywe.424.1527199448402; Thu, 24 May 2018 15:04:08 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Spencer Dawkins at IETF Date: Thu, 24 May 2018 17:03:56 -0500 Message-ID: To: Bob Hinden Cc: architecture-discuss@ietf.org, IAB Content-Type: multipart/alternative; boundary="0000000000009f9028056cfad46b" Archived-At: Subject: Re: [arch-d] Comments on X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.22 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: Thu, 24 May 2018 22:04:14 -0000 --0000000000009f9028056cfad46b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi, Bob, On Fri, Apr 6, 2018 at 12:00 PM Bob Hinden wrote: > Hi, > > A few comments on . This ranges from > editorial to substantive. > Thanks for these. They;re especially valuable because I'm just too close to this topic to see what's not clear to people who didn't attend the workshop= . Inline. > > Bob > > ------------ > > When was this workshop? I could not find a meeting date in the draft. > Duh. Fixed! > > ---- > > 1.1. Understanding "Bandwidth Optimization" > > =E2=80=A6. > > o Prioritisation of interactive traffic over background traffic > > What do you mean by =E2=80=9Cbackground traffic=E2=80=9D? Customers on m= obile networks > don=E2=80=99t consider their email or web browsing as =E2=80=9Cbackground= traffic=E2=80=9D. For > that matter, what do you mean by interactive traffic? Voice? Please > clarify. > I don't know that this was defined precisely in a way that all participants would have agreed with. I think the intention was something like "- Prioritisation of traffic for applications with a "human in the loop" who is waiting for a response". I made that change. There was one other use of "interactive" later in the document, describing the target for SPROUT, but I was able to simply remove that use. The resulting sentence is "- SPROUT: research at MIT which is a transport protocol for applications that desire high throughput and low delay. {{SPROUT}}". > > =E2=80=A6 > > o Business-related topics such as content delivery arrangements with > specific content providers. > > Like practices that violate network neutrality? > I suppose that would be part of the same space, but after looking back at detailed minutes, I'm pretty sure the point is about cooperation between operators and content providers - if an operator doesn't cooperate the same way across all content providers, yes, but the concern was whether operators could collaborate with ANY content providers if they're just carrying random bits. I think "specific" is a red herring/distraction, so I removed that word. > > =E2=80=94=E2=80=94 > > Quite a typo in: > > 1.4. Use of Note Well and Charter House Rule > > The workshop was conducted under the IETF [NOTE_WELL] with the > exception of the "Technical Analysis and Response to Potential > Regulatory Reaction" session which was conducted under > [CHATHAM_HOUSE_RULE]. > > I assume you mean =E2=80=9CChatham House Rule=E2=80=9D in the section hea= der. > D'oh! Fixed. > > =E2=80=94=E2=80=94=E2=80=94 > > Section 2.1 Scene Setting > > I don=E2=80=99t think this section did an adequate job describing a mobil= e > network. For example, my understanding is that mobile networks the radio > part is confined to the edges, the rest of the network is wired. There > isn=E2=80=99t any architectural differences with the wired part as compar= ed with > other ISP networks. I think the report would be better if it went into > more detail about this. The issues are in or near the radio network. > > I realize this is a report on a meeting, but there wasn=E2=80=99t any dis= cussion > of the tradeoff so creating smaller cell site to get more bandwidth and > reduced latency. This can also be a solution to some of the issues > discussed here. > Yeah, about that. We tried to dig on exactly the topic you mentioned for roughly a year, and finally chartered the ACCORD BOF in Yokohama to press down on that. Details at https://www.ietf.org/proceedings/94/accord.html. So I couldn't agree with you more, but the workshop didn't explore that. The closest we came was brainstorming on how to work together to improve our mutual understanding, and (speaking only for myself) I'd say that a sizable minority of the QUIC working group in London still thinks that measuring encrypted traffic is at least as much a research topic as an engineering topic - and that's in 2018. I wish the workshop outcome had been different. > > =E2=80=94=E2=80=94 > > 2.1.2 Encryption Statistics > > Good to see that encrypted content is reaching around 50%. But as I note= d > earlier when was this? What is it today? > Depending on who was measuring what ... Mozilla was reporting 50 percent as of the workshop date in 2014. Akamai was reporting percentages in the 30s from 2014 and expecting more than 50 percent in the next couple of years. I'll rely on Brian Trammell and the IAB for clue about this point, but my understanding is that IAB reports try to present the conversation as of the workshop date, rather than trying to update the workshop report based on a continued investigation. If that's the case, I probably won't try to provide updated statistics. And yes, 2014 was a long time ago ... > > =E2=80=94=E2=80=94=E2=80=94 > > 2.3. Awareness of User Choice (Privacy) > > =E2=80=A6. > > If users and content providers are to opt-in to user network > management services with negative privacy impacts they should see > clear value from using these services, and understand the impacts on > clear interfaces. Users should also have easy abilities to opt-out. > Some users will always automatically click through consent requests, > so any model relying on explicit consent is flawed for these users. > Understanding the extent of "auto click through" may help make better > decisions for consent requests in the future. One model (Cooperative > Traffic Management) works as an agent of the user; by opting-in > metadata can be shared. Issues with this involve trust only being > applied at endpoints. > > I note my personal view is that I am fine with providers using me as the > product when I am using a free service (like gmail that I am using to sen= d > this). I strongly dislike my information being used when I pay for the > service. Since mobile operators don=E2=80=99t usually provide a free ser= vice, I > don=E2=80=99t think they should be using our data to make additional mone= y. Enough > is enough. > > This would be a good topic for the IAB to explore. > Understood, and your comment is aging very well - it sounds smarter every day :-( ... > > ---------- > > 3.1. Sending Data Up / Down for Network Management Benefits > > =E2=80=A6. > > o Network Status API: An API for operators to share congestion > status or the state of a cell before an application starts sending > data could allow applications to change their behaviour. > > So this would be something like giving the hosts a way to understand > what=E2=80=99s going on inside a particular network (or access network)? = Does this > scale? This seems to me to be looking at the mobile network as the cente= r > and not just a part of the Internet. Could you clarify this? > Someone from the GSMA side is probably more excited than I am about this - I was one of the TRIGTRAN BOF co-chairs in the early 2000s, and we couldn't make a plausible case for a "local link up/down" signal, much less congestion information that is a lot more volatile on a wireless link than overall link status. I still see smart people who are working in this space presenting results, but they're presenting at ICCRG meetings because this is still research, not engineering. So, yes, I think you're exactly right ("the mobile network is the center and the source of all the answers to your problems"), and if you're only talking about congestion status for a local wireless link, and the information is only intended for mobile devices in a single cell (or even "mobile devices actively sending in a single cell"), you probably could scale that, but scaling is the least of your problems. (The closer the wireline endpoint is to the wireless link, the more accurate it is to treat the mobile network as the center, if you push content all the way to the cell site controller, but that's another conversation) I'm not thinking I should change something here. I think this was an accurate assessment in 2014. > > =E2=80=94=E2=80=94=E2=80=94 > > 7. Suggested Principles and Solutions > > =E2=80=A6. > > o CDNs and Caches: placing caches closer to the mobile user or > making more intelligent CDNs would result in faster content > delivery and less train on the network. Related work includes: > > Does this mean putting caches closer to the the edge where the radios are= ? > Yes, I think so. I suspect that o CDNs and Caches: placing caches closer to the edge of the radio network, as close as possible to the mobile user, or making more intelligent CDNs would result in faster content delivery and less train on the network. might be clearer. Does it seem to help? Also, fixing "train on the network". > =E2=80=A6. > > o One bit for latency / bandwidth trade-off: determining whether > using a single bit to distinguish between traffic that the sender > prefers to be queued and traffic that the sender would prefer to > drop rather than delay provides additional benefits beyond what > can be achieved without this signaling. > > A bit in the IP header? Who=E2=80=99s going to set this bit? Why not su= pport > RFC3514 too and solve all security problems too? > I don't think anyone in the room was thinking "in the IP header". This was definitely about transport space solutions. Something like SPUD (which added an unencrypted header for encrypted payloads being carried in UDP) or the QUIC public header were on people's minds. The QUIC "spin bit" is still on people's minds in 2018. I can see this being ambiguous enough that I should clarify this. I'll go with "one bit in an unencrypted transport header" and see if anyone else struggles with that. If this was a personal draft, I'd add 3514 as a reference in a heartbeat ;-) ... > > =E2=80=94=E2=80=94 > > 8. Since MaRNEW > > =E2=80=A6.. > > The most rewarding output of MaRNEW is perhaps the most intangible. > MaRNEW gave two rather divergent industry groups the opportunity to > connect and discuss common technologies and issues affecting users > and operations. Mobile Network providers and key Internet engineers > and experts have developed a greater collaborative relationship to > aid development of further standards which work across networks in a > secure manner. > > Very good! > > > _______________________________________________ > Architecture-discuss mailing list > Architecture-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/architecture-discuss > --0000000000009f9028056cfad46b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi, Bob,

On Fri, Apr 6, 2018 at 12:00 PM Bob Hinden <bob.hinden@gmail.com> wrote:
Hi,

A few comments on <draft-iab-marnew-report-01>.=C2=A0 This ranges fro= m editorial to substantive.

Thanks for = these. They;re especially valuable because I'm just too close to this t= opic to see what's not clear to people who didn't attend the worksh= op.

Inline.
=C2=A0

Bob

------------

When was this workshop?=C2=A0 I could not find a meeting date in the draft.=

Duh. Fixed!
=C2=A0

----

1.1.=C2=A0 Understanding "Bandwidth Optimization"

=C2=A0 =C2=A0=E2=80=A6.

=C2=A0 =C2=A0o=C2=A0 Prioritisation of interactive traffic over background = traffic

What do you mean by =E2=80=9Cbackground traffic=E2=80=9D?=C2=A0 Customers o= n mobile networks don=E2=80=99t consider their email or web browsing as =E2= =80=9Cbackground traffic=E2=80=9D.=C2=A0 For that matter, what do you mean = by interactive traffic?=C2=A0 Voice?=C2=A0 Please clarify.
=

I don't know that this was defined precisely in a w= ay that all participants would have agreed with.=C2=A0

=
I think the intention was something like "- Prioritisation of tra= ffic for applications with a "human in the loop" who is waiting f= or a response".=C2=A0

I made that change. The= re was one other use of "interactive" later in the document, desc= ribing the target for SPROUT, but I was able to simply remove that use. The= resulting sentence is "- SPROUT: research at MIT which is a transport= protocol for applications that desire high throughput and low delay. {{SPR= OUT}}".
=C2=A0

=E2=80=A6

=C2=A0 =C2=A0o=C2=A0 Business-related topics such as content delivery arran= gements with
=C2=A0 =C2=A0 =C2=A0 specific content providers.

Like practices that violate network neutrality?

I suppose that would be part of the same space, but after looking = back at detailed minutes, I'm pretty sure the point is about cooperatio= n between operators and content providers - if an operator doesn't coop= erate the same way across all content providers, yes, but the concern was w= hether operators could collaborate with ANY content providers if they'r= e just carrying random bits.=C2=A0

I think "s= pecific" is a red herring/distraction, so I removed that word.
=C2=A0

=E2=80=94=E2=80=94

Quite a typo in:

1.4.=C2=A0 Use of Note Well and Charter House Rule

=C2=A0 =C2=A0The workshop was conducted under the IETF [NOTE_WELL] with the=
=C2=A0 =C2=A0exception of the "Technical Analysis and Response to Pote= ntial
=C2=A0 =C2=A0Regulatory Reaction" session which was conducted under =C2=A0 =C2=A0[CHATHAM_HOUSE_RULE].

I assume you mean =E2=80=9CChatham House Rule=E2=80=9D in the section heade= r.

D'oh! Fixed.
=C2=A0

=E2=80=94=E2=80=94=E2=80=94

Section 2.1 Scene Setting

I don=E2=80=99t think this section did an adequate job describing a mobile = network.=C2=A0 For example, my understanding is that mobile networks the ra= dio part is confined to the edges, the rest of the network is wired.=C2=A0 = There isn=E2=80=99t any architectural differences with the wired part as co= mpared with other ISP networks.=C2=A0 I think the report would be better if= it went into more detail about this.=C2=A0 The issues are in or near the r= adio network.

I realize this is a report on a meeting, but there wasn=E2=80=99t any discu= ssion of the tradeoff so creating smaller cell site to get more bandwidth a= nd reduced latency.=C2=A0 This can also be a solution to some of the issues= discussed here.

Yeah, about that. We t= ried to dig on exactly the topic you mentioned for roughly a year, and fina= lly chartered the ACCORD BOF in Yokohama to press down on that. Details at= =C2=A0https://w= ww.ietf.org/proceedings/94/accord.html.=C2=A0

= So I couldn't agree with you more, but the workshop didn't explore = that. The closest we came was brainstorming on how to work together to impr= ove our mutual understanding, and (speaking only for myself) I'd say th= at a sizable minority of the QUIC working group in London still thinks that= measuring encrypted traffic is at least as much a research topic as an eng= ineering topic - and that's in 2018.

I wish th= e workshop outcome had been different.
=C2=A0

=E2=80=94=E2=80=94

2.1.2=C2=A0 Encryption Statistics

Good to see that encrypted content is reaching around 50%.=C2=A0 But as I n= oted earlier when was this?=C2=A0 What is it today?
Depending on who was measuring what ... Mozilla was reporting = 50 percent as of the workshop date in 2014. Akamai was reporting percentage= s in the 30s from 2014 and expecting more than 50 percent in the next coupl= e of years.=C2=A0

I'll rely on Brian Trammell = and the IAB for clue about this point, but my understanding is that IAB rep= orts try to present the conversation as of the workshop date, rather than t= rying to update the workshop report based on a continued investigation. If = that's the case, I probably won't try to provide updated statistics= .=C2=A0

And yes, 2014 was a long time ago ...
=C2=A0

=E2=80=94=E2=80=94=E2=80=94

2.3.=C2=A0 Awareness of User Choice (Privacy)

=E2=80=A6.

=C2=A0 =C2=A0If users and content providers are to opt-in to user network =C2=A0 =C2=A0management services with negative privacy impacts they should = see
=C2=A0 =C2=A0clear value from using these services, and understand the impa= cts on
=C2=A0 =C2=A0clear interfaces.=C2=A0 Users should also have easy abilities = to opt-out.
=C2=A0 =C2=A0Some users will always automatically click through consent req= uests,
=C2=A0 =C2=A0so any model relying on explicit consent is flawed for these u= sers.
=C2=A0 =C2=A0Understanding the extent of "auto click through" may= help make better
=C2=A0 =C2=A0decisions for consent requests in the future.=C2=A0 One model = (Cooperative
=C2=A0 =C2=A0Traffic Management) works as an agent of the user; by opting-i= n
=C2=A0 =C2=A0metadata can be shared.=C2=A0 Issues with this involve trust o= nly being
=C2=A0 =C2=A0applied at endpoints.

I note my personal view is that I am fine with providers using me as the pr= oduct when I am using a free service (like gmail that I am using to send th= is).=C2=A0 =C2=A0I strongly dislike my information being used when I pay fo= r the service.=C2=A0 Since mobile operators don=E2=80=99t usually provide a= free service, I don=E2=80=99t think they should be using our data to make = additional money.=C2=A0 Enough is enough.

This would be a good topic for the IAB to explore.
Understood, and your comment is aging very well - it sounds sma= rter every day :-( ...
=C2=A0

----------

3.1.=C2=A0 Sending Data Up / Down for Network Management Benefits

=E2=80=A6.

=C2=A0 =C2=A0o=C2=A0 Network Status API: An API for operators to share cong= estion
=C2=A0 =C2=A0 =C2=A0 status or the state of a cell before an application st= arts sending
=C2=A0 =C2=A0 =C2=A0 data could allow applications to change their behaviou= r.

So this would be something like giving the hosts a way to understand what= =E2=80=99s going on inside a particular network (or access network)?=C2=A0 = Does this scale?=C2=A0 This seems to me to be looking at the mobile network= as the center and not just a part of the Internet.=C2=A0 Could you clarify= this?

Someone from the GSMA side is pr= obably more excited than I am about this - I was one of the TRIGTRAN BOF co= -chairs in the early 2000s, and we couldn't make a plausible case for a= "local link up/down" signal, much less congestion information th= at is a lot more volatile on a wireless link than overall link status.=C2= =A0

I still see smart people who are working in th= is space presenting results, but they're presenting at ICCRG meetings b= ecause this is still research, not engineering.=C2=A0

<= div>So, yes, I think you're exactly right ("the mobile network is = the center and the source of all the answers to your problems"), and i= f you're only talking about congestion status for a local wireless link= , and the information is only intended for mobile devices in a single cell = (or even "mobile devices actively sending in a single cell"), you= probably could scale that, but scaling is the least of your problems.

(The closer the wireline endpoint is to the wireless l= ink, the more accurate it is to treat the mobile network as the center, if = you push content all the way to the cell site controller, but that's an= other conversation)

I'm not thinking I should = change something here. I think this was an accurate assessment in 2014.
=C2=A0

=E2=80=94=E2=80=94=E2=80=94

7.=C2=A0 Suggested Principles and Solutions

=E2=80=A6.

=C2=A0 =C2=A0o=C2=A0 CDNs and Caches: placing caches closer to the mobile u= ser or
=C2=A0 =C2=A0 =C2=A0 making more intelligent CDNs would result in faster co= ntent
=C2=A0 =C2=A0 =C2=A0 delivery and less train on the network.=C2=A0 Related = work includes:

Does this mean putting caches closer to the the edge where the radios are?<= br>

Yes, I think so. I suspect that=C2=A0

=C2=A0=C2=A0 o=C2=A0 CDNs and Caches: placi= ng caches closer to the edge of the radio network, as close as possible to = the mobile user, or
=C2=A0 =C2=A0 =C2=A0 making more intell= igent CDNs would result in faster content
=C2=A0 =C2=A0 =C2= =A0 delivery and less train on the network.=C2=A0=C2=A0

might be clearer. Does it seem to help?
=

Also, fixing "train on the network".=C2=A0=C2= =A0


=E2=80=A6.

=C2=A0 =C2=A0o=C2=A0 One bit for latency / bandwidth trade-off: determining= whether
=C2=A0 =C2=A0 =C2=A0 using a single bit to distinguish between traffic that= the sender
=C2=A0 =C2=A0 =C2=A0 prefers to be queued and traffic that the sender would= prefer to
=C2=A0 =C2=A0 =C2=A0 drop rather than delay provides additional benefits be= yond what
=C2=A0 =C2=A0 =C2=A0 can be achieved without this signaling.

A bit in the IP header?=C2=A0 Who=E2=80=99s going to set this bit?=C2=A0 Wh= y not support RFC3514 too and solve all security problems too?

I don't think anyone in the room was thinking &= quot;in the IP header". This was definitely about transport space solu= tions. Something like SPUD (which added an unencrypted header for encrypted= payloads being carried in UDP) or the QUIC public header were on people= 9;s minds.=C2=A0 The QUIC "spin bit" is still on people's min= ds in 2018.=C2=A0

I can see this being ambiguous e= nough that I should clarify this. I'll go with "one bit in an unen= crypted transport header" and see if anyone else struggles with that.= =C2=A0

If this was a personal draft, I'd add 3= 514 as a reference in a heartbeat ;-) ...
=C2=A0

=E2=80=94=E2=80=94

8.=C2=A0 Since MaRNEW

=E2=80=A6..

=C2=A0 =C2=A0The most rewarding output of MaRNEW is perhaps the most intang= ible.
=C2=A0 =C2=A0MaRNEW gave two rather divergent industry groups the opportuni= ty to
=C2=A0 =C2=A0connect and discuss common technologies and issues affecting u= sers
=C2=A0 =C2=A0and operations.=C2=A0 Mobile Network providers and key Interne= t engineers
=C2=A0 =C2=A0and experts have developed a greater collaborative relationshi= p to
=C2=A0 =C2=A0aid development of further standards which work across network= s in a
=C2=A0 =C2=A0secure manner.

Very good!


_______________________________________________
Architecture-discuss mailing list
Architec= ture-discuss@ietf.org
https://www.ietf.org/mailman/listinfo/arc= hitecture-discuss
--0000000000009f9028056cfad46b-- From nobody Thu May 24 15:33:50 2018 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 A4FE71201F8 for ; Thu, 24 May 2018 15:33:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 mceWpoXNxtcD for ; Thu, 24 May 2018 15:33:46 -0700 (PDT) Received: from mail-pl0-x234.google.com (mail-pl0-x234.google.com [IPv6:2607:f8b0:400e:c01::234]) (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 8A47912E8D7 for ; Thu, 24 May 2018 15:33:46 -0700 (PDT) Received: by mail-pl0-x234.google.com with SMTP id m24-v6so1890875pls.11 for ; Thu, 24 May 2018 15:33:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=8nNOMDNhNf9U86DDFRdmoBmwsgy3f1GKtMOzv3EJJKg=; b=myu6aDFEnqc+mksxaaqkRkj2rUDq4gpLvDUm/rZjSgm0lpLM12PCiqx/SKL08+d6Jf A2j0iUAKO0NX+uMWu22oSS8k3YIn/bAcWdM2x63x6jS1ckF22sRKOXPyNdes2MBBT0cu X+ig2aVPlnzF7NsjwUEbfv7n0gNOS3P4ngWDUkdOEL80jH6shh1PY2uQQqCiqNVt9Z6N CiAWoksM8EcAhRtt1tJbb5E9Qv9aNXDiPVcHv+zaK1ei+5NFB9SHDqhUyZBrWlIPMh7I jnmWfRQdWKsnetjHysNr7OsBX7rzQysAgbME9fPEZQhN7ZlpucgoSkUd8Ku6Phym0izL qYOw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=8nNOMDNhNf9U86DDFRdmoBmwsgy3f1GKtMOzv3EJJKg=; b=h9c6axb5tOpcxVyOArz386XCYKZEtCuHjiFRzUz5acZ/ZpejMYa4tTpUShi6MzpdcL p0gSTe8wrE59r2zP+KrfUvz+UutBCOC9vdlUyvVnG5AmKjcEc9Cqv9ToTHdf0HXV8x07 Bmuppei/A80AmjoQ+IAcYJg05lMr4R8uuMadamr53KDNtqAX0x3VmCqEk+g4kYrUmgrO 7mbk3/wbEoaO34VvfgnzcGIQeaTJ329AWjagmjicvMpaEWi/92Ros3XEayL6BmnFRPgd 3GJKL7Ug5odqDCXs0tV7tkAwlgdK2sLfSw/wQHnrNiRzpEMfgRIpYEi7fz7+P0lTcf4V ziJw== X-Gm-Message-State: ALKqPweuqhAqSKra5PZCpmHhNxNOASGvrAb7TSRxhigOqEGYhPc1ikhS 0gWsjB4L4ojYLTpqFO3fCwpE7w== X-Google-Smtp-Source: AB8JxZr5YQfHgLGtKiat9lp3/yue7Bdb500gNMBlyMp8FEkI3sHJh0/GtUtWih9KS/kFNuMeVUfP4g== X-Received: by 2002:a17:902:c81:: with SMTP id 1-v6mr9256827plt.126.1527201225578; Thu, 24 May 2018 15:33:45 -0700 (PDT) Received: from [192.168.178.21] ([118.148.121.80]) by smtp.gmail.com with ESMTPSA id z13-v6sm59079327pfk.156.2018.05.24.15.33.42 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 24 May 2018 15:33:44 -0700 (PDT) To: Henning Schulzrinne , Russ Housley Cc: architecture-discuss@ietf.org References: <152538075241.4552.6760702690778529507@ietfa.amsl.com> <7E740995-3B63-4CE6-BC58-9DDC0F3BA07E@vigilsec.com> <5D59E88E-DB8B-4909-91A9-70AA90D77C29@vigilsec.com> From: Brian E Carpenter Message-ID: <446a18e2-aba2-736a-50f7-e1f27cdc266b@gmail.com> Date: Fri, 25 May 2018 10:33:49 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [arch-d] I-D Action: draft-iab-protocol-maintenance-00.txt X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.22 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: Thu, 24 May 2018 22:33:49 -0000 On 25/05/2018 09:12, Henning Schulzrinne wrote: > Interesting example. Sounds like we could use a checklist of common problem > areas, some very specific (such as Russ' example) and some more generic > (e.g., cautions about case-sensitivity and character sets). Yes. Whatever position the eventual form of the document takes, the more concrete problem cases we have the better. Also, when we think about what the IETF+IAB can actually do, rather than merely say, it seems more relevant to tease out recommendations for protocol *specifications* to be less prone to problems that will invoke the robustness principle. As Tony Li eloquently said, implementers will in any case do what they need to do for interoperability. Brian > > Henning > > On Thu, May 24, 2018 at 4:56 PM, Russ Housley wrote: > >> Henning: >>> >>> I think this discussion would benefit from citing specific (historical) >> examples. My hunch is that all the contributors to this discussion have >> specific cases or issues in mind that may actually be non-overlapping and >> may illustrate different problems. For example, some may be ambiguities >> where the text omits some restriction that the ABNF or more formal >> specification includes, and then implementations follow the text. >> >> Sometimes the specification authors make the mistake, and when the mistake >> is fixed implementation and other specifications are still broken. Here is >> one that keeps causing trouble for me. >> >> Too many specifications allow two encodings for ASN.1 AlgorithmIdentifier >> parameters. The two alternatives arise from the loss of the OPTIONAL >> associated with the algorithm identifier parameters when the 1988 syntax >> for AlgorithmIdentifier was translated into the 1997 syntax. Later, the >> OPTIONAL was recovered via a defect report, but by then many people thought >> that algorithm parameters were mandatory. Because of this history, some >> implementations encode parameters as a NULL element while others omit them >> entirely. The correct encoding is to omit the parameters field; however, >> when some uses of these algorithms were defined, it was done using the NULL >> parameters rather than absent parameters. For example, PKCS#1 [RFC3447] >> requires that the padding used for RSA signatures MUST use SHA2 >> AlgorithmIdentifiers with NULL parameters. >> >> Russ >> >> > > > > _______________________________________________ > Architecture-discuss mailing list > Architecture-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/architecture-discuss > From nobody Thu May 24 15:43:02 2018 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 57BE512E8DA for ; Thu, 24 May 2018 15:43:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 PXDO2o_Jk6pI for ; Thu, 24 May 2018 15:42:58 -0700 (PDT) Received: from outprodmail01.cc.columbia.edu (outprodmail01.cc.columbia.edu [128.59.72.39]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9650A12E8D9 for ; Thu, 24 May 2018 15:42:58 -0700 (PDT) Received: from hazelnut (hazelnut.cc.columbia.edu [128.59.213.250]) by outprodmail01.cc.columbia.edu (8.14.4/8.14.4) with ESMTP id w4OMerUm048062 for ; Thu, 24 May 2018 18:42:57 -0400 Received: from hazelnut (localhost.localdomain [127.0.0.1]) by hazelnut (Postfix) with ESMTP id 72C676D for ; Thu, 24 May 2018 18:42:57 -0400 (EDT) Received: from sendprodmail03.cc.columbia.edu (sendprodmail03.cc.columbia.edu [128.59.72.15]) by hazelnut (Postfix) with ESMTP id 77CFD83 for ; Thu, 24 May 2018 18:42:56 -0400 (EDT) Received: from mail-oi0-f70.google.com (mail-oi0-f70.google.com [209.85.218.70]) by sendprodmail03.cc.columbia.edu (8.14.4/8.14.4) with ESMTP id w4OMgtNp012281 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT) for ; Thu, 24 May 2018 18:42:56 -0400 Received: by mail-oi0-f70.google.com with SMTP id k186-v6so1620235oib.7 for ; Thu, 24 May 2018 15:42:55 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=hlMvPIlqPrbu39K6t0nbSyfbECc1FG4TXLyU85Pi2ZA=; b=PF77HgU+mNv5eSpSH+aohBt44Kw+LAYyjiwBxvuqM3p7EU+ZU8bFXoLIoRbRL47qD0 4vgqyKUM6g/6rRIRVH1jKoOg615f8KsAbnIyQa/wSQmvAVqBTY6OIy9Xbnk/laQiSDD8 JhfDg/rnXEOGzGul2GdNZ+svlF9VqyuMBArPh5eoyVQ8Mavot3Q07QzKPwE8UDSS6E4y GqJsxgFKdFJNvN4INvEBs8LQ4SFsosL8jmjR7zr6PYSF5E4Vs9s3U2rrLecUlhqljCX9 etFGmd4dbhMlU8wILcyzGytd0ha5t2alhtVomvCMciWC3/EYOm8TEngVqHBdIqIQRiA2 QGzw== X-Gm-Message-State: ALKqPwe+aQr7z+2UTR6aSldbYHfCapBql+0VYm/SzV/8nQoX3ul2yNQg CSF9ejlX71dK8HLxvn0Dch4ehWyqjPyx0Sr/FJVXQHtnm15RbSIl+nv85c2MQFdRfZB5Z7V3Edc 0f5AJ8DbDOMDnYT35daI0c76+a0wkphZesbC7hIi7yT9PCUTcKA== X-Received: by 2002:aca:4e15:: with SMTP id c21-v6mr4681599oib.254.1527201774807; Thu, 24 May 2018 15:42:54 -0700 (PDT) X-Google-Smtp-Source: AB8JxZoNBwyCL7npZhsE/UXkSbyEMg/ZmKlH9w4CMjHxz76SaxY8QBZP7IopiNsO6tRQYCOAET3YINY5pxyZs65aP4U= X-Received: by 2002:aca:4e15:: with SMTP id c21-v6mr4681587oib.254.1527201774441; Thu, 24 May 2018 15:42:54 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a9d:59cd:0:0:0:0:0 with HTTP; Thu, 24 May 2018 15:42:33 -0700 (PDT) In-Reply-To: <446a18e2-aba2-736a-50f7-e1f27cdc266b@gmail.com> References: <152538075241.4552.6760702690778529507@ietfa.amsl.com> <7E740995-3B63-4CE6-BC58-9DDC0F3BA07E@vigilsec.com> <5D59E88E-DB8B-4909-91A9-70AA90D77C29@vigilsec.com> <446a18e2-aba2-736a-50f7-e1f27cdc266b@gmail.com> From: Henning Schulzrinne Date: Thu, 24 May 2018 18:42:33 -0400 Message-ID: To: Brian E Carpenter Cc: Russ Housley , architecture-discuss@ietf.org Content-Type: multipart/alternative; boundary="000000000000443a51056cfb5f19" X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.78 on 128.59.72.15 Archived-At: Subject: Re: [arch-d] I-D Action: draft-iab-protocol-maintenance-00.txt X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.22 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: Thu, 24 May 2018 22:43:02 -0000 --000000000000443a51056cfb5f19 Content-Type: text/plain; charset="UTF-8" One mechanism that I think could help and maybe be mentioned as a concrete step is the RFC errata. This can be a good way to highlight areas of ambiguity or "frequently made mistakes". In the SIP world, the SIPit events have proven to be quite useful, but they require an organization that can make them happen regularly and some liaison who can report interoperability issues back to the IETF, acting as institutional memory. Publishing test cases and torture tests is also probably a useful activity. I agree that just berating developers is unlikely to make much difference, but removing excuses for laziness could. As an IETF example, the working group could maintain a "resources for developers" page for key protocols that highlight resources that facilitate interoperability, such as implementor mailing lists (the SIP implementors list was mentioned and was/is quite helpful, in my view; developers may not care about protocol discussions, so overloading the regular IETF list is not usually a good idea, even if the list persists after the WG shuts down.). On Thu, May 24, 2018 at 6:33 PM, Brian E Carpenter < brian.e.carpenter@gmail.com> wrote: > On 25/05/2018 09:12, Henning Schulzrinne wrote: > > Interesting example. Sounds like we could use a checklist of common > problem > > areas, some very specific (such as Russ' example) and some more generic > > (e.g., cautions about case-sensitivity and character sets). > > Yes. Whatever position the eventual form of the document takes, the > more concrete problem cases we have the better. > > Also, when we think about what the IETF+IAB can actually do, rather than > merely say, it seems more relevant to tease out recommendations for > protocol *specifications* to be less prone to problems that will invoke > the robustness principle. As Tony Li eloquently said, implementers > will in any case do what they need to do for interoperability. > > Brian > > > > > Henning > > > > On Thu, May 24, 2018 at 4:56 PM, Russ Housley > wrote: > > > >> Henning: > >>> > >>> I think this discussion would benefit from citing specific (historical) > >> examples. My hunch is that all the contributors to this discussion have > >> specific cases or issues in mind that may actually be non-overlapping > and > >> may illustrate different problems. For example, some may be ambiguities > >> where the text omits some restriction that the ABNF or more formal > >> specification includes, and then implementations follow the text. > >> > >> Sometimes the specification authors make the mistake, and when the > mistake > >> is fixed implementation and other specifications are still broken. > Here is > >> one that keeps causing trouble for me. > >> > >> Too many specifications allow two encodings for ASN.1 > AlgorithmIdentifier > >> parameters. The two alternatives arise from the loss of the OPTIONAL > >> associated with the algorithm identifier parameters when the 1988 syntax > >> for AlgorithmIdentifier was translated into the 1997 syntax. Later, the > >> OPTIONAL was recovered via a defect report, but by then many people > thought > >> that algorithm parameters were mandatory. Because of this history, some > >> implementations encode parameters as a NULL element while others omit > them > >> entirely. The correct encoding is to omit the parameters field; > however, > >> when some uses of these algorithms were defined, it was done using the > NULL > >> parameters rather than absent parameters. For example, PKCS#1 [RFC3447] > >> requires that the padding used for RSA signatures MUST use SHA2 > >> AlgorithmIdentifiers with NULL parameters. > >> > >> Russ > >> > >> > > > > > > > > _______________________________________________ > > Architecture-discuss mailing list > > Architecture-discuss@ietf.org > > https://www.ietf.org/mailman/listinfo/architecture-discuss > > > --000000000000443a51056cfb5f19 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
One mechanism that I think could help and maybe be mention= ed as a concrete step is the RFC errata. This can be a good way to highligh= t areas of ambiguity or "frequently made mistakes".

In the SIP world, the SIPit events have proven to be quite useful, bu= t they require an organization that can make them happen regularly and some= liaison who can report interoperability issues back to the IETF, acting as= institutional memory.

Publishing test cases and t= orture tests is also probably a useful activity.

I= agree that just berating developers is unlikely to make much difference, b= ut removing excuses for laziness could.

As an IETF= example, the working group could maintain a "resources for developers= " page for key protocols that highlight resources that facilitate inte= roperability, such as implementor mailing lists (the SIP implementors list = was mentioned and was/is quite helpful, in my view; developers may not care= about protocol discussions, so overloading the regular IETF list is not us= ually a good idea, even if the list persists after the WG shuts down.).

On Thu, Ma= y 24, 2018 at 6:33 PM, Brian E Carpenter <brian.e.carpenter@gmai= l.com> wrote:
On 25/05/2018= 09:12, Henning Schulzrinne wrote:
> Interesting example. Sounds like we could use a checklist of common pr= oblem
> areas, some very specific (such as Russ' example) and some more ge= neric
> (e.g., cautions about case-sensitivity and character sets).

Yes. Whatever position the eventual form of the document takes, the
more concrete problem cases we have the better.

Also, when we think about what the IETF+IAB can actually do, rather than merely say, it seems more relevant to tease out recommendations for
protocol *specifications* to be less prone to problems that will invoke
the robustness principle. As Tony Li eloquently said, implementers
will in any case do what they need to do for interoperability.

=C2=A0 =C2=A0 Brian

>
> Henning
>
> On Thu, May 24, 2018 at 4:56 PM, Russ Housley <housley@vigilsec.com> wrote:
>
>> Henning:
>>>
>>> I think this discussion would benefit from citing specific (hi= storical)
>> examples. My hunch is that all the contributors to this discussion= have
>> specific cases or issues in mind that may actually be non-overlapp= ing and
>> may illustrate different problems. For example, some may be ambigu= ities
>> where the text omits some restriction that the ABNF or more formal=
>> specification includes, and then implementations follow the text.<= br> >>
>> Sometimes the specification authors make the mistake, and when the= mistake
>> is fixed implementation and other specifications are still broken.= =C2=A0 Here is
>> one that keeps causing trouble for me.
>>
>> Too many specifications allow two encodings for ASN.1 AlgorithmIde= ntifier
>> parameters.=C2=A0 The two alternatives arise from the loss of the = OPTIONAL
>> associated with the algorithm identifier parameters when the 1988 = syntax
>> for AlgorithmIdentifier was translated into the 1997 syntax.=C2=A0= Later, the
>> OPTIONAL was recovered via a defect report, but by then many peopl= e thought
>> that algorithm parameters were mandatory.=C2=A0 Because of this hi= story, some
>> implementations encode parameters as a NULL element while others o= mit them
>> entirely.=C2=A0 The correct encoding is to omit the parameters fie= ld; however,
>> when some uses of these algorithms were defined, it was done using= the NULL
>> parameters rather than absent parameters.=C2=A0 For example, PKCS#= 1 [RFC3447]
>> requires that the padding used for RSA signatures MUST use SHA2 >> AlgorithmIdentifiers with NULL parameters.
>>
>> Russ
>>
>>
>
>
>
> _______________________________________________
> Architecture-discuss mailing list
> Architecture-discuss@= ietf.org
> https://www.ietf.org/mailman/lis= tinfo/architecture-discuss
>

--000000000000443a51056cfb5f19-- From nobody Thu May 24 16:04:15 2018 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 198D312EA76 for ; Thu, 24 May 2018 16:04:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 mO5kj5Q1ja-j for ; Thu, 24 May 2018 16:04:10 -0700 (PDT) Received: from mail-yb0-x233.google.com (mail-yb0-x233.google.com [IPv6:2607:f8b0:4002:c09::233]) (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 56BFD12E9DC for ; Thu, 24 May 2018 16:04:05 -0700 (PDT) Received: by mail-yb0-x233.google.com with SMTP id p22-v6so1202631yba.13 for ; Thu, 24 May 2018 16:04:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=5JhY61luxQv/QqLXXVVvri1dCs3/k8KSMOQp9C6WUJw=; b=Tnzk0mBDxF1Wss1Hg56VczEnMQzNruw9z3L6I4uZlcG93wzNWz8QNCOy8J2jgdn3Cu Sj7w2WhqsJ6yfqivV1UF7HSoi/lzwGhrjxAj703kFTuNq7MzqpZlOSRCFaenrOnmceLI cUur1GMPGjL0Z8FXi8TKx7vYDAHdau8OAG4pZpZKUDTlG3fIaD9ZJsMa94jOLk2l76xs g6t8UnT8UlTPHfIUOGI5V7P7MFAhg+cA5zwgWSi0y2Wae/sXUE2rl9D1UY9NgsPVM0+U I7hBK19vWPzYi4cRZmiymDlTwoCLEde2GPoqNjrR9mF51uaa4CiitihhQY8q4jg8GWn5 WTCg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=5JhY61luxQv/QqLXXVVvri1dCs3/k8KSMOQp9C6WUJw=; b=CmHIhkYK8QDcSu5HxPKZMKKTSfXTiJ5lgPNFxbM+7fVM6fJzxDdtilGUnRgu7xT2uc 4TfOUnfMjO6iQArEfYcZa0+PSUYJgm3u16uqJL/frTSGJAUO7TeT6sd/AM5CrFOkMXzJ hEJqcBKCZ1UcAOdy8A+I+9sOHICXHzzufMvKSqaEui5OlYsp5SgMDP9TNLBjD/1ztDQQ 4ZMMf0rCDlTyfRgv5N0AORwuPshO9QTszRD5PGtpdGXexc7wvXtI8yjzJcsrPLosTSTm v9N6ElPNfTt38Nuir+HXXWZyDZ0XpYxK04QQu1/eeKyBJyCJjECGHLoqts/jb/2BMMAF WJrQ== X-Gm-Message-State: ALKqPwcqfsArgAcwbR7N1nedW4bTym6oruQMdNzvlA8Zaw+OVii3cz86 cDiU1OBeh4Jq/8t48Y7vL8/Tm8UejmRRR4rVAN4= X-Google-Smtp-Source: AB8JxZqB2Q+MEBRecbA/dtymejUy7Ja4nl8UY+yfiBr6lPil31u8f52dxxeW8y6sxlFrVE9K5RvQZf/PwJX6COt0mVo= X-Received: by 2002:a25:ba48:: with SMTP id z8-v6mr5539595ybj.110.1527203044358; Thu, 24 May 2018 16:04:04 -0700 (PDT) MIME-Version: 1.0 References: <152279331966.23985.3238502800355132103.idtracker@ietfa.amsl.com> In-Reply-To: From: Spencer Dawkins at IETF Date: Thu, 24 May 2018 18:03:53 -0500 Message-ID: To: Warren Kumari Cc: architecture-discuss@ietf.org, IAB IAB Content-Type: multipart/alternative; boundary="000000000000f57fc7056cfbaaca" Archived-At: Subject: Re: [arch-d] Call for Comment: (IAB Workshop on Managing Radio Networks in an Encrypted World (MaRNEW) Report) X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.22 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: Thu, 24 May 2018 23:04:13 -0000 --000000000000f57fc7056cfbaaca Content-Type: text/plain; charset="UTF-8" Hi, Warren, Thanks for the comments! Inline ... On Tue, Apr 10, 2018 at 5:10 PM Warren Kumari wrote: > I think it would be useful to have the date of the MarNEW workshop > near the top of the document (perhaps "The MarNEW workshop (September, > 2015) aimed ...") - our tone and understanding of the issues being > discussed has changed significantly in the 2 years, 7 months since the > workshop happened. > Absolutely. > > The document also talks about things like "From a recent study > [Pew2014] 64% of users said..." -- Pew2014 was ~1 year old when the > workshop occurred, but it's now 3 years 5 months in the past -- not > really "recent" any more. > Yeah ... I found two occurrences, which are now "then-current". I think that's fair. > Nits: > Abstract: > "The MarNEW workshop" MarNEW -> MaRNEW > This text was actually replaced, and the new text has the capitalization correct. > > s/understandinf/understanding/ > Fixed. > > > W > > > On Tue, Apr 3, 2018 at 6:08 PM, IAB Executive Administrative Manager > wrote: > > This is an announcement of an IETF-wide Call for Comment on > > draft-iab-marnew-report-01. > > > > The document is being considered for publication as an Informational RFC > > within the IAB stream, and is available for inspection at: > > https://datatracker.ietf.org/doc/draft-iab-marnew-report/ > > > > The Call for Comment will last until 2018-05-01. Please send comments to > > architecture-discuss@ietf.org and iab@iab.org. > > > > > > Abstract > > > > The MarNEW workshop aimed to discuss solutions for bandwidth > > optimisation on mobile networks for encrypted content, as current > > solutions rely on unencrypted content which is not indicative of the > > security needs of today's Internet users. The workshop gathered IETF > > attendees, IAB members and various organisations involved in the > > telecommunications industry including original equipment > > manufacturers and mobile network operators. > > > > The group discussed the current Internet encryption trends and > > deployment issues identified within the IETF, and the privacy needs > > of users which should be adhered. Solutions designed around sharing > > data from the network to the endpoints and vice versa were then > > discussed as well as analysing whether the current issues experienced > > on the transport layer are also playing a role here. Content > > providers and CDNs gave an honest view of their experiences delivery > > content with mobile network operators. Finally, technical responses > > to regulation was discussed to help the regulated industries relay > > the issues of impossible to implement or bad-for-privacy technologies > > back to regulators. > > > > A group of suggested solutions were devised which will be discussed > > in various IETF groups moving forward. > > > > > > -- > I don't think the execution is relevant when it was obviously a bad > idea in the first place. > This is like putting rabid weasels in your pants, and later expressing > regret at having chosen those particular rabid weasels and that pair > of pants. > ---maf > > _______________________________________________ > Architecture-discuss mailing list > Architecture-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/architecture-discuss > --000000000000f57fc7056cfbaaca Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi, Warren,

Thanks for the comments!=C2= =A0

Inline ...=C2=A0

On Tue, Apr 10, 2018 at 5:10 PM Warren Kumari &l= t;warren@kumari.net> wrote:
=
I think it would be useful to have the= date of the MarNEW workshop
near the top of the document (perhaps "The MarNEW workshop (September,=
2015) aimed ...") - our tone and understanding of the issues being
discussed has changed significantly in the 2 years, 7 months since the
workshop happened.

Absolutely.=C2=A0
=C2=A0

The document also talks about things like "From a recent study
[Pew2014] 64% of users said..." -- Pew2014 was ~1 year old when the workshop occurred, but it's now 3 years 5 months in the past -- not
really "recent" any more.

Yea= h ... I found two occurrences, which are now "then-current". I th= ink that's fair.=C2=A0
=C2=A0
Nits:
Abstract:
"The MarNEW workshop" MarNEW -> MaRNEW
This text was actually replaced, and the new text has the capi= talization correct.=C2=A0=C2=A0

s/understandinf/understanding/

Fixed.
=C2=A0


W


On Tue, Apr 3, 2018 at 6:08 PM, IAB Executive Administrative Manager
<execd@iab.org>= ; wrote:
> This is an announcement of an IETF-wide Call for Comment on
> draft-iab-marnew-report-01.
>
> The document is being considered for publication as an Informational R= FC
> within the IAB stream, and is available for inspection at:
> https://datatracker.ietf.org/doc/draft= -iab-marnew-report/
>
> The Call for Comment will last until 2018-05-01. Please send comments = to
> arc= hitecture-discuss@ietf.org and iab@iab.org.
>
>
> Abstract
>
>=C2=A0 =C2=A0 The MarNEW workshop aimed to discuss solutions for bandwi= dth
>=C2=A0 =C2=A0 optimisation on mobile networks for encrypted content, as= current
>=C2=A0 =C2=A0 solutions rely on unencrypted content which is not indica= tive of the
>=C2=A0 =C2=A0 security needs of today's Internet users.=C2=A0 The w= orkshop gathered IETF
>=C2=A0 =C2=A0 attendees, IAB members and various organisations involved= in the
>=C2=A0 =C2=A0 telecommunications industry including original equipment<= br> >=C2=A0 =C2=A0 manufacturers and mobile network operators.
>
>=C2=A0 =C2=A0 The group discussed the current Internet encryption trend= s and
>=C2=A0 =C2=A0 deployment issues identified within the IETF, and the pri= vacy needs
>=C2=A0 =C2=A0 of users which should be adhered.=C2=A0 Solutions designe= d around sharing
>=C2=A0 =C2=A0 data from the network to the endpoints and vice versa wer= e then
>=C2=A0 =C2=A0 discussed as well as analysing whether the current issues= experienced
>=C2=A0 =C2=A0 on the transport layer are also playing a role here.=C2= =A0 Content
>=C2=A0 =C2=A0 providers and CDNs gave an honest view of their experienc= es delivery
>=C2=A0 =C2=A0 content with mobile network operators.=C2=A0 Finally, tec= hnical responses
>=C2=A0 =C2=A0 to regulation was discussed to help the regulated industr= ies relay
>=C2=A0 =C2=A0 the issues of impossible to implement or bad-for-privacy = technologies
>=C2=A0 =C2=A0 back to regulators.
>
>=C2=A0 =C2=A0 A group of suggested solutions were devised which will be= discussed
>=C2=A0 =C2=A0 in various IETF groups moving forward.
>



--
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
=C2=A0 =C2=A0---maf

_______________________________________________
Architecture-discuss mailing list
Architec= ture-discuss@ietf.org
https://www.ietf.org/mailman/listinfo/arc= hitecture-discuss
--000000000000f57fc7056cfbaaca-- From nobody Thu May 24 21:24:02 2018 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 9B94412D885 for ; Thu, 24 May 2018 21:23:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 tkK9DtOjT368 for ; Thu, 24 May 2018 21:23:55 -0700 (PDT) Received: from mail-yb0-x233.google.com (mail-yb0-x233.google.com [IPv6:2607:f8b0:4002:c09::233]) (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 7CCFF12D88B for ; Thu, 24 May 2018 21:23:55 -0700 (PDT) Received: by mail-yb0-x233.google.com with SMTP id g140-v6so1411511ybf.6 for ; Thu, 24 May 2018 21:23:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=3XumPmNTH7m/Vt5/Gcxhnf81ehxhaTAP/YHnVxxpofQ=; b=JUmVWYlmDxQgjeY3/m8R7iMvQvJNR97oreZ8pPudsGnejRQHufmfg7ZCTPAEDsTYP6 1CBqYBupo0ECWMF8RRXanunkBPqPXqXubZ3lb5pnjsO3aeJxZyZ7IhtKfLOFZ86OnPMK 6CcOjnTxegN0HSxISBrBS2OIwuWqYnyV9UPTaAOKY3RBSHi1JP61H1eKygy85BVpAbWa 7O/fMMhqzRNsAusKKg5tLDQXnOEDxNkZFkBAKOY8rGqX+x6+3EABm9lmvbRgsOHnnKBh ZxNqfxsAMnSCO0Dr05CXVjgQ/CUNOaDlw0WVeNGNe0Usui1Eh4B4QzsdkPwco4Ig+eSl R0mQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=3XumPmNTH7m/Vt5/Gcxhnf81ehxhaTAP/YHnVxxpofQ=; b=JCVY36gCdEFTYYBTr8ogx2toZ9uiXdrJFocXSHMqUkv4X+d88hKhV9JU8eKD4DIJaP jd0BaMHKnupFz5fnRFpK1ei4slXuAhX9SIOYBE6Cnpt1Vm6re941xHPo8+qcJ/ZJsHi1 gC4gbWhTF6LWEI+ZmtZvHCcsXsREFV/9FJwD8YksLi2svSdJXJzIoUZ4bdO8fcWuHF2i gOmifyq3K87yEpboPzaYryoSCWsAvzQkl4ul17OYPFM/poAEl5bZR7A+VM2EcsFO6dQG RG5ptoVhSZNn45M3l26CxR1djsIl7a18zwuoqkguxhfYzoEGr3WSHv7bXaYFZnIXtFxK j8aw== X-Gm-Message-State: ALKqPwfnj2mlRgqsbtnJrFhJJhvyGxZEW/srW1HGVs0oRfY0LlOmPcXB FXXqKJaLRUs7hCyeuiRDBWuIEtn/lynJEz4Qpe4= X-Google-Smtp-Source: AB8JxZpuSZ6KzYC0dBRy1ZEl7TSYaNepkKbS7bpIqq3jTgyThRb78iYlE1pYI/71OnaFE3F0qwlhD2NIoIS4Uca7wKY= X-Received: by 2002:a25:618f:: with SMTP id v137-v6mr406023ybb.221.1527222234507; Thu, 24 May 2018 21:23:54 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Spencer Dawkins at IETF Date: Thu, 24 May 2018 23:23:42 -0500 Message-ID: To: Shivan Cc: hr-rt@irtf.org, architecture-discuss@ietf.org, IAB IAB Content-Type: multipart/alternative; boundary="000000000000c7ee5a056d002298" Archived-At: Subject: Re: [arch-d] [HT-rt] HR-RT Review of draft-iab-marnew-report-01 X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.22 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: Fri, 25 May 2018 04:24:00 -0000 --000000000000c7ee5a056d002298 Content-Type: text/plain; charset="UTF-8" Hi, Amelia and Shivan, On Wed, May 2, 2018 at 12:12 PM Shivan wrote: > This is a review done within the framework of the Human Rights Review > Team. It was done by Amelia Andersdotter and Shivan Kaul Sahib. The Human > Rights Review Team aims to implement and improve the guidelines for > human rights considerations provided in RFC8280, and seek to mitigate > potentially adverse human rights impacts that IETF and IRTF documents > might have. > An aside - I'm glad we're doing this (and I get to say that as an IESG member), but I hadn't heard that we would be doing it. I'm glad this document was picked to review. Thanks for that. Inline ... > > We find the topics addressed during the workshop interesting and look > forward to following future developments. > > --- > > Document: draft-iab-marnew-report-01 > > https://datatracker.ietf.org/doc/draft-iab-marnew-report/ > > Review: > > The Human Rights in Protocols Research Group welcomes the draft report > from the MaRNEW workshop. In particular, we welcome the efforts to continue > advancing an encrypted, secure and human rights enabling environment, as > well as solid assessments of the potential impacts of considered remedies > to mobile network operator difficulties on the right to privacy of an > individual. > > In this regard, we wish to remind the drafters and the IAB of the inherent > connection between privacy and freedom of expression. The right to privacy, > or to one's own personhood, reinforces the freedom of expression and > freedom of opinion. > > Semantic Suggestions > =========================== > > The following sections addresses a few semantic problems in the draft > report, that were they solved the draft report would be easier to parse > from both a human rights perspective, and from a business, legal or > technical perspective. > > 1. Abstract, para 2: > > Problem: Draft text contains value judgements on participants' > presentations that could be avoided. > > Solution: Remove the word "honest" in relation to CDN presentations, since > it may cause readers to assume that other presenters were less forthcoming. > > The new paragraph would read > > The group discussed the current Internet encryption trends and > deployment issues identified within the IETF, and the privacy needs > of users which should be adhered. Solutions designed around sharing > data from the network to the endpoints and vice versa were then > discussed as well as analysing whether the current issues experienced > on the transport layer are also playing a role here. Content > providers and CDNs gave their views of delivering > content with mobile network operators. Finally, technical responses > to regulation was discussed to help the regulated industries relay > the issues of impossible to implement or bad-for-privacy technologies > back to regulators. > I adjusted this to "gave their own views", but, yes. > > 2. Section 1, Introduction: > > Problem: It is unclear whether the "requirements" referred to imply > regulatory requirements enforceable by government authorities, or technical > requirements. Because of the nature of issues discussed during the > workshop, understanding what sorts of "requirements" are being referred to > is imperative. > > Solution: Specify the nature of the requirements being referred to, or > remove the reference to requirements. > > The new Introduction would read > > Mobile networks have a set of properties which > places a large emphasis on sophisticated bandwidth optimization. > Encryption is increasing on the Internet which is positive for > consumer and business privacy and security. Many existing mobile > bandwidth optimization solutions primarily operate on non-encrypted > communications; this can lead to performance issues being amplified > on mobile networks. Encryption on networks will continue to > increase; and with this understanding the workshop aimed to > understand how we can solve the issues of bandwidth optimization and > performance on radio networks in this encrypted world. > I used this (with one s/;/,/). > > 3. Section 1.1: > > Problem: The first paragraph mixes business models with technical > necessities. The last paragraph in the section Understanding "Bandwidth > Optimization" refers to regulatory requirements (within the meaning of > government enforced requirements or legal requirements, cf above) on mobile > network operators to perform traffic filtering and monitoring. > > Solution: It may facilitate understanding of human rights impacts to > separate technical considerations from business considerations and legal > considerations. Paragraph 3 ("Many of these functions can continue...") > could be put as the last paragraph, while Paragraph 1 could be split into a > technical section and a business model section, followed by a legal section. > > > For the purposes of this workshop, bandwidth optimization encompasses > a variety of technical topics related to traffic engineering, > prioritisation, optimisation and efficiency enhancements. It also > encompasses > user-related topics such as specific subscription or billing models, > and may touch upon regulatory aspects or other issues relating to > regulatory, within the meaning of government initiated, concerns. > > The first category of bandwidth optimization includes: > > o Caching > > o Prioritisation of interactive traffic over background traffic > > o Per-user bandwidth limit > > The second category of bandwidth optimization may depend on either of > the first category optimization strategies, but may, in particular, also > encompass: > > o Business-related topics such as content delivery arrangements with > specific content providers. > > Finally, while not strictly speaking traffic management, some > networks employ policy-based filtering (e.g., requested parental > controls) and many networks support some form of legal interception > functionality per applicable laws. > > Many of these functions can continue as they're performed today, even > with more encryption. Others are using methods which inspect parts > of the communication that are encrypted, and these will have to be > done differently in an encrypted Internet. > I used this structure, and made a few editorial changes that seemed to clarify the text. > > > 4. Section 4: > > Problem: QUIC is an active area of work for the IETF in the transport > layer - this section barely mentions it, and even then does so vaguely. > What problems are solved by QUIC that are general problems rather than TCP > problems? What was the nature of the disagreement around this? > > Solution: More detail about how QUIC fits into transport-layer work would > make this section more relevant. In addition, there has been discussion > involving network operators around technical details that have potential > privacy impacts within the QUIC working group (SPIN bit); this section > would benefit greatly from an examination of that. > This topic has grown in interest significantly after the MaRNEW workshop - the QUIC BOF happened nearly a year later, and formation of the working group happened a few months after the BOF. We really didn't talk about QUIC at the workshop, except when people (often from Google) referred to specific experiences with the proprietary QUIC protocol in discussion. I look forward to seeing what the next workshop in this space says in its workshop report ;-) ... > > > > Human Rights Considerations > =========================== > > Upon consideration of the draft report, no implications for > internationalization ([RFC8280], sec. 6.2.5), heterogeneity support > ([RFC8280], sec. 6.2.8), accessibility ([RFC8280], sec. 6.2.11) or > localization ([RFC8280], sec. 6.2.12) have been found. We will further > suppose that issues relating to Anonymity ([RFC8280], sec. 6.2.9), > Pseudonymity ([RFC8280], sec. 6.2.10) and Confidentiality ([RFC8280], sec. > 6.2.16) have been sufficiently addressed in the draft as is. > > In the below text, Security ([RFC8280], sec. 6.2.4), Integrity ([RFC8280], > sec. 6.2.16) and Authenticity ([RFC8280], sec. 6.2.17) are further > considered to have been addressed, or as in progress of being addressed by > the specific endeavours pointed out in the report. As such, this assessment > hopes to serve as a complement to remaining Human Rights Considerations > Guidelines which were not addressed by the MaRNEW draft. > > ## Privacy ([RFC8280], sec. 6.2.2) > > We laud the general emphasis on considering user privacy concerns > paramount [Section 2.1.1, 2.3 etc]. > > In Section 3.1.1, para 1, it would be useful to emphasize that middleboxes > that are "authenticated and invoked explicitly" might not be very effective > at conserving user privacy if they lead to auto-click through. In practice, > "opted-in" middleboxes might not be much better than transparent > middleboxes. Additionally, this poses the danger of making matters worse if > users assume that because they haven't been asked for middlebox permission, > they are not going through a middlebox. For users accessing the Internet on > a browser client: if the connection is MITMed by a middlebox, the browser > would somehow need to convey this effectively and actionably to the user. > Whatever effort is expended on this should involve browser vendors. > I agree with your point here, but this issue wasn't raised in the workshop at the time. This is good information to keep in mind as we move forward on standardization efforts in a post-MaRNEW world. > > ## Connectivity ([RFC8280], sec. 6.2..1) > > It is a priori obvious that a discussion with mobile network operators > would touch upon connectivity. As a general comment, the HRPC RG is not > concerned that encrypted internet traffic could create topological problems > in network deployment with respect to density of base stations. It is more > sensible to imagine that the density of base stations is kept low by > deployers to save money on infrastructure roll-out. > > In the MarNEW draft report, middleboxes are brought up frequently as an > example of infrastructure rendered less useful by the ubiquitous adoption > of encryption. Middleboxes may enhance access to content for individuals, > and may also interfere with their ability to enjoy content free of > surveillance, censorship or content manipulation. The focus of the workshop > of exploring ways in which encrypted materials can benefit from the same > speed of deliverance as un-encrypted materials is therefore welcome. > I agree, and would say that this is a guiding principle for current specification efforts in places like the QUIC working group. > > ## Content Agnosticism > > Traffic prioritisation, whether based on technical or commercial grounds, > risks interfering with an individual's right to freedom of expression or > opinion, by restricting access or enjoy content of their own choosing. As > such, prioritisation should be made explicit and obvious, and subject to > consent from the individual, whether the motivations for deployment are > commercial or technical. > > It is clear that internet filtering and blocking of content of specific > types, whether motivated by network management or regulatory concerns, does > not fulfill a content agnosticism criterion. It is the observation of HRPC > that [RFC7725] (An HTTP Status Code to Report Legal Obstacles) may assist > communication of specific filtering and blocking operations in action. > > It the the impetus of the Human Rights Guidelines in RFC8280 that content > agnosticism be respected by protocols developed in the IETF, and in general > an accepted view in the global human rights community that content > agnosticism is desirable at all levels of technical infrastructure. As > such, the HRPC RG is concerned about ideas that traffic be classified > through additional headers or metadata, identifying traffic via 5-tuples, > trust models and frameworks, or heuristics. > These last points are good things to keep in mind as our specification work moves forward. Again, thank you for all of this, and I look forward to considering these issues more consistently in the future than we were in 2015. Spencer > > > _______________________________________________ > Architecture-discuss mailing list > Architecture-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/architecture-discuss > --000000000000c7ee5a056d002298 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi, Amelia and Shivan,

<= div dir=3D"ltr">On Wed, May 2, 2018 at 12:12 PM Shivan <shivankaul.1993@gmail.com> wrote:
This is a review done wi= thin the framework of the Human Rights Review
Team. It was done by Amelia An= dersdotter and Shivan Kaul Sahib. The Human
Rights Review Team aims to implement and = improve the guidelines for
human rights considerations provided in RFC8280, and seek = to mitigate
might have.

An aside - I&= #39;m glad we're doing this (and I get to say that as an IESG member), = but I hadn't heard that we would be doing it.

= I'm glad this document was picked to review. Thanks for that.=C2=A0

Inline ...
=C2=A0

We find the topics addressed during the workshop interesting and= look
forw= ard to following future developments.

---

Document: draft-iab-marnew-report-01

<= /font>
Review:

<= /div>
The Human Rights = in Protocols Research Group welcomes the draft report from the MaRNEW works= hop. In particular, we welcome the efforts to continue advancing an encrypt= ed, secure and human rights enabling environment, as well as solid assessme= nts of the potential impacts of considered remedies to mobile network opera= tor difficulties on the right to privacy of an individual.

In this regard, we wish to remi= nd the drafters and the IAB of the inherent connection between privacy and = freedom of expression. The right to privacy, or to one's own personhood= , reinforces the freedom of expression and freedom of opinion.
=

= Semantic Suggestions=
=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

<= div>The following sections = addresses a few semantic problems in the draft report, that were they solve= d the draft report would be easier to parse from both a human rights perspe= ctive, and from a business, legal or technical perspective.

1. Abstract, para 2:

Problem: Draft text cont= ains=C2=A0 value judgements on participants' presentations that could b= e avoided.

Solu= tion: Remove the word "honest" in relation to CDN presentations, = since it may cause readers to assume that other presenters were less forthc= oming.
The new = paragraph would read

=C2=A0 =C2=A0The group discussed the current Internet encryption tren= ds and
=C2= =A0 =C2=A0deployment issues identified within the IETF, and the privacy nee= ds
=C2=A0 = =C2=A0of users which should be adhered.=C2=A0 Solutions designed around sha= ring
=C2= =A0 =C2=A0data from the network to the endpoints and vice versa were then
=C2=A0 =C2= =A0discussed as well as analysing whether the current issues experienced
=C2=A0 =C2= =A0on the transport layer are also playing a role here.=C2=A0 Content
=C2=A0 =C2=A0pr= oviders and CDNs gave their views of delivering
=C2=A0 =C2=A0content with mobile netw= ork operators.=C2=A0 Finally, technical responses
=C2=A0 =C2=A0to regulation was disc= ussed to help the regulated industries relay
=C2=A0 =C2=A0the issues of impossible = to implement or bad-for-privacy technologies
=C2=A0 =C2=A0back to regulators.

I adjusted this t= o "gave their own views", but, yes.
=C2=A0

2. Section 1, Introduction:

Problem: It is unclear whether the &qu= ot;requirements" referred to imply regulatory requirements enforceable= by government authorities, or technical requirements. Because of the natur= e of issues discussed during the workshop, understanding what sorts of &quo= t;requirements" are being referred to is imperative.
=
Solution: Specify the nature of = the requirements being referred to, or remove the reference to requirements= .

The new Intro= duction would read

=C2=A0 =C2=A0Mobile networks have a set of properties which
=C2=A0 =C2=A0places a= large emphasis on sophisticated bandwidth optimization.
<= font color=3D"#333333" face=3D"georgia, serif">=C2=A0 =C2=A0Encryption is i= ncreasing on the Internet which is positive for
=C2=A0 =C2=A0consumer and business pr= ivacy and security.=C2=A0 Many existing mobile
=C2=A0 =C2=A0bandwidth optimization so= lutions primarily operate on non-encrypted
=C2=A0 =C2=A0communications; this can lead= to performance issues being amplified
=C2=A0 =C2=A0on mobile networks.=C2=A0 Encrypt= ion on networks will continue to
=C2=A0 =C2=A0increase; and with this understanding t= he workshop aimed to
=C2=A0 =C2=A0understand how we can solve the issues of bandwidth= optimization and
=C2=A0 =C2=A0performance on radio networks in this encrypted world.=

I used this= (with one s/;/,/).=C2=A0

3. Section 1.= 1:

Problem: The= first paragraph mixes business models with technical necessities. The last= paragraph in the section Understanding "Bandwidth Optimization" = refers to regulatory requirements (within the meaning of government enforce= d requirements or legal requirements, cf above) on mobile network operators= to perform traffic filtering and monitoring.

Solution: It may facilitate understanding o= f human rights impacts to separate technical considerations from business c= onsiderations and legal considerations. Paragraph 3 ("Many of these fu= nctions can continue...") could be put as the last paragraph, while Pa= ragraph 1 could be split into a technical section and a business model sect= ion, followed by a legal section.


=C2=A0 =C2=A0For the purposes of this workshop, bandwidth op= timization encompasses
=C2=A0 =C2=A0a variety of technical topics related to traffic = engineering,
=C2=A0 =C2=A0prioritisation, optimisation and efficiency enhancements. I= t also encompasses
=C2=A0 =C2=A0user-related topics such as specific subscription or = billing models, and may touch upon regulatory aspects or other issues relat= ing to regulatory, within the meaning of government initiated, concerns.

<= /div>
=C2=A0 =C2=A0The = first category of bandwidth optimization includes:

=C2=A0 =C2=A0o=C2=A0 Caching

=C2=A0 =C2=A0o=C2=A0 Pri= oritisation of interactive traffic over background traffic

=C2=A0 =C2=A0o=C2=A0 Per-user b= andwidth limit
=C2=A0 =C2=A0
=C2=A0 =C2=A0The second category of bandwidth optimization may dep= end on either of the first category optimization strategies, but may, in pa= rticular, also encompass:

=C2=A0 =C2=A0o=C2=A0 Business-related topics such as content del= ivery arrangements with
=C2=A0 =C2=A0 =C2=A0 specific content providers.
=
=C2=A0 =C2=A0 =C2=A0= =C2=A0
=C2= =A0 =C2=A0Finally, while not strictly speaking traffic management, some
=C2=A0 =C2=A0= networks employ policy-based filtering (e.g., requested parental
=C2=A0 =C2=A0control= s) and many networks support some form of legal interception
=C2=A0 =C2=A0functionali= ty per applicable laws.

=C2=A0 =C2=A0Many of these functions can continue as they're p= erformed today, even
=C2=A0 =C2=A0with more encryption.=C2=A0 Others are using method= s which inspect parts
=C2=A0 =C2=A0of the communication that are encrypted, and these= will have to be
=C2=A0 =C2=A0done differently in an encrypted Internet.
=

I used this structure, a= nd made a few editorial changes that seemed to clarify the text.=C2=A0=C2= =A0


4. Section 4:

Problem: QUIC is an active area of wor= k for the IETF in the transport layer - this section barely mentions it, an= d even then does so vaguely. What problems are solved by QUIC that are gene= ral problems rather than TCP problems? What was the nature of the disagreem= ent around this?




Human Rights Considerations
=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

Upon consideration o= f the draft report, no implications for internationalization ([RFC8280], se= c. 6.2.5), heterogeneity support ([RFC8280], sec. 6.2.8), accessibility ([R= FC8280], sec. 6.2.11) or localization ([RFC8280], sec. 6.2.12) have been fo= und. We will further suppose that issues relating to Anonymity ([RFC8280], = sec. 6.2.9), Pseudonymity ([RFC8280], sec. 6.2.10) and Confidentiality ([RF= C8280], sec. 6.2.16) have been sufficiently addressed in the draft as is.

=
In the below tex= t, Security ([RFC8280], sec. 6.2.4), Integrity ([RFC8280], sec. 6.2.16) and= Authenticity ([RFC8280], sec. 6.2.17) are further considered to have been = addressed, or as in progress of being addressed by the specific endeavours = pointed out in the report. As such, this assessment hopes to serve as a com= plement to remaining Human Rights Considerations Guidelines which were not = addressed by the MaRNEW draft.

## Privacy ([RFC8280], sec. 6.2.2)

We laud the general emphasis on consid= ering user privacy concerns paramount [Section 2.1.1, 2.3 etc].=C2=A0

In Section 3.1.1, pa= ra 1, it would be useful to emphasize that middleboxes that are "authe= nticated and invoked explicitly" might not be very effective at conser= ving user privacy if they lead to auto-click through. In practice, "op= ted-in" middleboxes might not be much better than transparent middlebo= xes. Additionally, this poses the danger of making matters worse if users a= ssume that because they haven't been asked for middlebox permission, th= ey are not going through a middlebox. For users accessing the Internet on a= browser client: if the connection is MITMed by a middlebox, the browser wo= uld somehow need to convey this effectively and actionably to the user. Wha= tever effort is expended on this should involve browser vendors.

I agree with your poin= t here, but this issue wasn't raised in the workshop at the time. This = is good information to keep in mind as we move forward on standardization e= fforts in a post-MaRNEW world.
=C2=A0

## Connectivity ([RFC8280], sec. 6.2..1)

It is a priori obvious that a discussi= on with mobile network operators would touch upon connectivity. As a genera= l comment, the HRPC RG is not concerned that encrypted internet traffic cou= ld create topological problems in network deployment with respect to densit= y of base stations. It is more sensible to imagine that the density of base= stations is kept low by deployers to save money on infrastructure roll-out= .

In the MarNEW= draft report, middleboxes are brought up frequently as an example of infra= structure rendered less useful by the ubiquitous adoption of encryption. Mi= ddleboxes may enhance access to content for individuals, and may also inter= fere with their ability to enjoy content free of surveillance, censorship o= r content manipulation. The focus of the workshop of exploring ways in whic= h encrypted materials can benefit from the same speed of deliverance as un-= encrypted materials is therefore welcome.

I agree, and would say that this is a guiding= principle for current specification efforts in places like the QUIC workin= g group.=C2=A0
=C2=A0
## Cont= ent Agnosticism

Traffic prioritisation, whether based on technical or commercial grounds, = risks interfering with an individual's right to freedom of expression o= r opinion, by restricting access or enjoy content of their own choosing. As= such, prioritisation should be made explicit and obvious, and subject to c= onsent from the individual, whether the motivations for deployment are comm= ercial or technical.

It is clear that internet filtering and blocking of content of specif= ic types, whether motivated by network management or regulatory concerns, d= oes not fulfill a content agnosticism criterion. It is the observation of H= RPC that [RFC7725] (An HTTP Status Code to Report Legal Obstacles) may assi= st communication of specific filtering and blocking operations in action.

=
It the the impet= us of the Human Rights Guidelines in RFC8280 that content agnosticism be re= spected by protocols developed in the IETF, and in general an accepted view= in the global human rights community that content agnosticism is desirable= at all levels of technical infrastructure. As such, the HRPC RG is concern= ed about ideas that traffic be classified through additional headers or met= adata, identifying traffic via 5-tuples, trust models and frameworks, or he= uristics.

Th= ese last points are good things to keep in mind as our specification work m= oves forward.

Again, thank you for all of this, an= d I look forward to considering these issues more consistently in the futur= e than we were in 2015.

Spencer
=C2=A0


_______________________________________________
Architecture-discuss mailing list
Architec= ture-discuss@ietf.org
https://www.ietf.org/mailman/listinfo/arc= hitecture-discuss
--000000000000c7ee5a056d002298-- From nobody Fri May 25 14:26:19 2018 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 15DE4127601 for ; Fri, 25 May 2018 14:26:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 a4ZJsbSBHWK6 for ; Fri, 25 May 2018 14:26:15 -0700 (PDT) Received: from mail-yb0-x22a.google.com (mail-yb0-x22a.google.com [IPv6:2607:f8b0:4002:c09::22a]) (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 0C9F6128959 for ; Fri, 25 May 2018 14:26:15 -0700 (PDT) Received: by mail-yb0-x22a.google.com with SMTP id o80-v6so2291706ybc.7 for ; Fri, 25 May 2018 14:26:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=krH5L962b34VHrZinTvuA9h5e9qCYyQzKKnPrj3wYNA=; b=oqngvwIsW7B+AN0MNkxbTEPvqWpy4wvnV2asRO8GzDB3ihVKwCqVaZIHbP/HhUBwx6 Gi2NYXegjCB8zy+lbKFK1fNsRLMcNfLSzQaOrLR7TsojiWFJ0X9k6zPnIFiDrRga3zJK YfsIrRpkHlhJRAJ70TH+L9yT955ZnWsoASaTPQDD53ldkLlbAknE1boRlI5dTCafDRMW RsQPgaR6IKDE3NUoQtrCZHtKFGBu1csuJr8ePUCY1pKpFu6slyOJvGDeXzJV3g+Xx0sM ExlUXh6Ymh43FS7qQau66h5tPN7ztgxCEyxCdL6D0MO8MCPINLIjTP5Pi5s6WQMcFr29 pvVg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=krH5L962b34VHrZinTvuA9h5e9qCYyQzKKnPrj3wYNA=; b=o28IJ+cKBYfbb88IB7NiYYzpPC1RRfjC+ktfcC4bN8nygSfmh7lEfBrH9zV1uiKcI6 psAqunFHcR9WW8uKIl195L+pw41G1WmUOec5szpNot0yrgjGgtXUh6MxKoutBiAHQpAM 1FjMdZgcT+4QMJhNDHglLTilY0OId1UHeD4113uj1XsxMgV0UWZ9GDshUqHraU1QAiM0 eFqtQp3vNaZodwe6e3AG9RzHT44o/+10bnHpQQHeecQdjJO7yH7OtjbVpoUNmx6cRewt Ts/6oQs2lYXOPnfJ4g3XMXgYBtFpFDDECa6GvgCUpH3KFv7YjTVhyW7U5Ve5BoNUrFar C6QA== X-Gm-Message-State: ALKqPwegiF4a4G4C3IkpUPYY72kxSUMZWud7s3lupOnWVGSNBWwsnhKf GRFbfQ2N75b2WyPj457RjdSqEwofyiw1H4311nQ2hQ== X-Google-Smtp-Source: ADUXVKIgNVepWZBhMq3QabpF198VrtzQ9TnpXCVBeDOBdmcjNMLZEsy848kEGA75aSdbbi6GJvzacDaUfxbNqXnO9MU= X-Received: by 2002:a25:6a55:: with SMTP id f82-v6mr2353921ybc.235.1527283573810; Fri, 25 May 2018 14:26:13 -0700 (PDT) MIME-Version: 1.0 References: <152279331966.23985.3238502800355132103.idtracker@ietfa.amsl.com> In-Reply-To: <152279331966.23985.3238502800355132103.idtracker@ietfa.amsl.com> From: Spencer Dawkins at IETF Date: Fri, 25 May 2018 16:26:01 -0500 Message-ID: To: IAB IAB Cc: architecture-discuss@ietf.org Content-Type: multipart/alternative; boundary="000000000000e36bde056d0e6aeb" Archived-At: Subject: Re: [arch-d] Call for Comment: (IAB Workshop on Managing Radio Networks in an Encrypted World (MaRNEW) Report) X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.22 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: Fri, 25 May 2018 21:26:18 -0000 --000000000000e36bde056d0e6aeb Content-Type: text/plain; charset="UTF-8" Dear IAB, On Tue, Apr 3, 2018 at 5:09 PM IAB Executive Administrative Manager < execd@iab.org> wrote: > This is an announcement of an IETF-wide Call for Comment on > draft-iab-marnew-report-01. > > The document is being considered for publication as an Informational RFC > within the IAB stream, and is available for inspection at: > https://datatracker.ietf.org/doc/draft-iab-marnew-report/ > > The Call for Comment will last until 2018-05-01. Please send comments to > architecture-discuss@ietf.org and iab@iab.org. > After discussions with Brian Trammell, I've submitted a post-Call for Comments version -02 of this draft. The datatracker URL is https://datatracker.ietf.org/doc/draft-iab-marnew-report/. I addressed comments from Bob Hinden and Warren Kumari, and responded to a Human Rights Review Team review by Amelia Andersdotter and Shivan Kaul Sahib. In addition, I made a pass through the draft looking for editorial issues, and found more than I was hoping for, but have resolved them. I believe this version is ready for publication in the IAB stream. Please let me know if there are any comments that result from IAB discussion of this draft. And thanks for letting me help with this. Spencer --000000000000e36bde056d0e6aeb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear IAB,

On Tue, Apr 3, 2018 at 5:09 PM IAB Executive Administrative Manager <= ;execd@iab.org> wrote:
This is an announcement of a= n IETF-wide Call for Comment on
draft-iab-marnew-report-01.

The document is being considered for publication as an Informational RFC within the IAB stream, and is available for inspection at:
https://datatracker.ietf.org/doc/draft-ia= b-marnew-report/

The Call for Comment will last until 2018-05-01. Please send comments to architec= ture-discuss@ietf.org and iab@iab.org.

After discussions = with Brian Trammell, I've submitted a post-Call for Comments version -0= 2 of this draft.=C2=A0


I addressed comments from Bob Hinden and Warren Kumari, an= d responded to a Human Rights Review Team review by=C2=A0Amelia Andersdotte= r and Shivan Kaul Sahib.

In addition, I made a pas= s through the draft looking for editorial issues, and found more than I was= hoping for, but have resolved them.

I believe thi= s version is ready for publication in the IAB stream.

<= div>Please let me know if there are any comments that result from IAB discu= ssion of this draft.

And thanks for letting me hel= p with this.=C2=A0

Spencer
--000000000000e36bde056d0e6aeb-- From nobody Mon May 28 00:11:35 2018 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 E34EB1277BB for ; Mon, 28 May 2018 00:11:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 HFdcPovMEYih for ; Mon, 28 May 2018 00:11:31 -0700 (PDT) Received: from mail-oi0-x22b.google.com (mail-oi0-x22b.google.com [IPv6:2607:f8b0:4003:c06::22b]) (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 24CE0127876 for ; Mon, 28 May 2018 00:11:31 -0700 (PDT) Received: by mail-oi0-x22b.google.com with SMTP id a6-v6so9571751oia.2 for ; Mon, 28 May 2018 00:11:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=zckVrcBgkl37mcaGLrj7KoxWgVClIGRlif5CtTjBLP0=; b=HR18Jme/i7LjNKtqARoLfGhUSkCnZXT4+GWMlAUdJQhK5WMGhHnAKKnCIjbyHhKRXL F+EK3xOv+4Da0xCncD6r/Bit7rX+mOZK4n1cOzJWNrECCxT0ugsAhbLZ7qffHR5vT7FA PaEbuN57W5zowvbTY6geFmzG5lRjhjZfzpldvuLg5r3MYr3QEmF9oNF/+opIjXX3jak3 ffkdRNz/g+ug09BodJJgEaDp3Un4IwZV5ti48Rea+jblOxmG+JsHbn1ASuTN4QgAyA5D Erzve4MXf15fM00WZaGr1GE7xW6gdfGkTrqRZ4fC0dHqLZzafqr0QW0qXgpNVj/vaegw yX6g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=zckVrcBgkl37mcaGLrj7KoxWgVClIGRlif5CtTjBLP0=; b=UnJ2kghxXRPo0EW3IZz6U7yHED5Thdxy0CFdDEnqzKIwnC9ZfFd939RnmLMPERwwrg E+iWZNOhl2cStkb9Qor15ncwSAluAZHOYn7t+4OZxuyqc2N6xxQdnaBSkXxMw0aDjq6k b7DjuUq+0cMRoiAUkoAKzXuLI4nqITFFNth1bMLTcnXKAq05T2ntsD6xeoFX0qT3IXbP Z1rTx00kS6ytj3uiLSx8JEpWKVlpXHrHcLDAZY5k7CZonm5J8r6Dc6N/aQqMoh+ElX9m MMH0+6Pffg9w0TMozXZD6rM6nrTPrPG8YU8inL0HhQXeSC99zHRMXHTkCk7tQeYjN3p8 rUBA== X-Gm-Message-State: ALKqPwdndxiT06TRwEKAJeKBaH5uEUMNZXCth1TStebITmIL9P1hH6Ak 0+jK7OYP9mRQyHx7CshlFj1YuLc/OUSXDuYqe2sHYl4T X-Google-Smtp-Source: ADUXVKI38mIQZ96V5+FOn0A5UM1137Vec2OWBcVNsauz35sC6g0xAliH3PGDzCxIx9YBd+CyI21cpCLGqME4QPGZSDc= X-Received: by 2002:aca:5bc5:: with SMTP id p188-v6mr6398975oib.295.1527491490347; Mon, 28 May 2018 00:11:30 -0700 (PDT) MIME-Version: 1.0 References: <152538075241.4552.6760702690778529507@ietfa.amsl.com> In-Reply-To: From: Martin Thomson Date: Mon, 28 May 2018 17:11:18 +1000 Message-ID: To: Robert Sparks Cc: architecture-discuss@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [arch-d] I-D Action: draft-iab-protocol-maintenance-00.txt X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.22 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, 28 May 2018 07:11:34 -0000 Top-posting here because I think that this highlights a common error we make in our building of standards. Henning gave a concise example of another such example as well: "the spec says case-insensitive, but applications are case-sensitive" (and several others, all of which I've seen). [1] The standard exists to record an agreement, and if it is a poor match for reality, it isn't worth much. If we consider the RFC to be a declaration by fiat that this is what shall be, then if that agreement is demonstrably different because the code says otherwise, what then? So, to answer Robert's question: On Fri, May 25, 2018 at 4:10 AM Robert Sparks wrote: > If I read what you suggest correctly, you would have preferred that the > IETF have updated 3261 shortly after it was clear that this variant was pervasive > in deployment, and updated it again after the variant went away? More or less. If you are maintaining the protocol specification, you need to reach an agreement with protocol participants. If the agreement was that the clearly bad implementation needed to comply, then that's it. But that really only works if the infringing party was willing to change - or other implementations were willing to exclude that (popular) application. Given that particular situation, which involved a non-trivial period of non-compliance, I might have suggested that documenting the variant would be help, but frankly a year isn't that long. As long as the bug was well-known, distributing knowledge might have been enough. Publishing an RFC might have taken longer than fixing the bug. (That's another sad story, but not for here.) The article that Henning cited was a great read. One thing in the thesis there is that change (both good and bad) is primarily driven by a minority, and that the primary precondition for success is that the minority is intolerant. I still think that there is value in virtuous intolerance - an earlier version of this draft advocated for it - the challenge being two-fold: first in deciding whether one is being virtuous, and second in managing the cost of your own exclusion for being so intolerant. [1] As an aside, SIP (also, SMTP and HTTP before it) invited this error by allowing messages to be case-insensitive, then providing nicely consistent casing in examples. When you consider the value provided by this "feature" of these protocols, the cost has over time far outweighed the benefits. Programmers are well used to getting case right, but the number of problems from case variations has been high. I consider the case-insensitivity in these protocols to be a misfeature. We were lucky to be able to remove that feature for HTTP header fields with HTTP/2, but that was the result of taking advantage of a rare opportunity. From nobody Mon May 28 00:29:15 2018 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 44172124B17 for ; Mon, 28 May 2018 00:29:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 AhKduTtbOGKj for ; Mon, 28 May 2018 00:29:13 -0700 (PDT) Received: from mail-oi0-x230.google.com (mail-oi0-x230.google.com [IPv6:2607:f8b0:4003:c06::230]) (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 F16C4120047 for ; Mon, 28 May 2018 00:29:12 -0700 (PDT) Received: by mail-oi0-x230.google.com with SMTP id a6-v6so9606153oia.2 for ; Mon, 28 May 2018 00:29:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=IgpOgS9Olzvmias2+D/jYIQXdKWKe8LJj+4IRhgnfPo=; b=qRHUjoRwsFJOdcHLjI7+wNcKcku4Wr/Soxmxt4+Pc/19r8tYLVMROB1xn5VMniHvAp lzIW4JkNGK8gLGSKmTfvyxvUXvhSvtK1CdGTdpPFjfi/WhTnfai3pSMVL0xx+xp+vNiu s9xHZndLqQTWSRm20w2WBknGf25TeZdy6e0/YeOweN33b3KJbZ1OqGgTT1jndqWNHaHm IgXo3mILoTivbvf8mgRN8jctlK39zYLq9hZfrN6Wq7OKdF2OL33MJ1BL3zYqQZezUXdd dNR1TTCU3jvdcyrovi078rfDIcGk9YNkZ95cTMTkZpoyst0UIBSEaArLuHGka6D4MWiZ 6Fiw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=IgpOgS9Olzvmias2+D/jYIQXdKWKe8LJj+4IRhgnfPo=; b=uVy5f8AUugjLddzGE7aE/4G0HkbTJ0xClKkqJG+BBILGLxNzpFWbT1+AymatM/pWQD VMzH4KuDf3dYOBFycysY27ltNkve6PJ5u+yN1m248uztqc2p7OAZSiwT8O3UEZYaenIz VY+QNWBqLfbuKd1HpLwsj+f/lMBDZZkmHXxt6rByGCslhv8JQW/yPrKhYk/KRFeSarhr YJVGlHYRYkUZ6GSZkohi+5rr6nYGZGwp9+M54O2JFsEzf+vGEYBGWsyHtjHVLbX/HZ86 DUD045gr9Df99Xe6OVcEQiV9dzIRTQr6xrlXDjqYPihPCG66K2zcmZXZabV9hhUNi2BI b6cA== X-Gm-Message-State: ALKqPwdMlBYftuR4cwbwbA/qVrOFC5NaHl1vKW30j4dB+v+pnHYCcRCL 4t2Rti4vGJrnE852zX7+gqBlBnsetCsqvJlwyX2mgw== X-Google-Smtp-Source: ADUXVKLL3DG/+JjfU3A7cACSiweZ5sMJqEKPd3hHnz/KMX5bl/otn2gk0xSnLJOuRwhBmQUtYtzwziwiKewSnYp2U2A= X-Received: by 2002:aca:1218:: with SMTP id 24-v6mr4086317ois.144.1527492552262; Mon, 28 May 2018 00:29:12 -0700 (PDT) MIME-Version: 1.0 References: <152538075241.4552.6760702690778529507@ietfa.amsl.com> <370fc7abe18207138498d335bb688a7e@strayalpha.com> <9ef0db90cc9c99b597918a6d92257228@strayalpha.com> In-Reply-To: <9ef0db90cc9c99b597918a6d92257228@strayalpha.com> From: Martin Thomson Date: Mon, 28 May 2018 17:29:01 +1000 Message-ID: To: touch@strayalpha.com Cc: Henning Schulzrinne , architecture-discuss@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [arch-d] I-D Action: draft-iab-protocol-maintenance-00.txt X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.22 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, 28 May 2018 07:29:14 -0000 On Fri, May 25, 2018 at 5:19 AM Joe Touch wrote: > Generally, I would agree - I saw this in the constant stream of TCP "additions" based on what was deployed that I felt only served to make TCP more fragile by violating the Postal Principle. I pushed to have those deviations called "bugs", not "de-facto deployment features". That's just another case of uncoordinated standards development. The failure there exists in the gap between what is specified/documented and what is practiced. If what was practiced was in your view poor, then that's sad, but it doesn't change the fact that it was the protocol that was deployed and the specifications weren't serving the community well. I understand that the situation with TCP continues to improve, in both specification fidelity and implementation quality. > We could argue that accepting RSTs anywhere in the TCP window was over-application of the Postal Principle caused the vulnerabilities described in RFC 4953, and RFC 5961 closed that gap. The TCP RFC is very clear on this point, so I'd chalk this up to a simple spec bug. From nobody Mon May 28 00:46:54 2018 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 E313312702E for ; Mon, 28 May 2018 00:46:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 wj3TESAz5l7O for ; Mon, 28 May 2018 00:46:50 -0700 (PDT) Received: from mail-oi0-x241.google.com (mail-oi0-x241.google.com [IPv6:2607:f8b0:4003:c06::241]) (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 DA4E8126D74 for ; Mon, 28 May 2018 00:46:49 -0700 (PDT) Received: by mail-oi0-x241.google.com with SMTP id c203-v6so9626009oib.7 for ; Mon, 28 May 2018 00:46:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=1voauYFvoRFYL6Ma4oGFqR1aIqOzJ+/ZXazHjalSmFo=; b=DNxw6vAqnq8rRMx1vcX6+Z3mOpRBId8a9ZbedqqaJJjGrVjhoO4HLuZcg6W9/rcDA2 yUuBdUp/urpUiN1QV97kqfKwxjDU61lyWJwd1V3lJcKInqGOIVBHe7lhGtMgNtySvdR+ GtXZbtBp4RrGa99DVK+/deB4Thd++M8aNbBP2In1Tc7tNOFG0LLA2n4Y4ZzJoHdQjaOV xcwSCWgZlng/Jpq9/9Q8MYmAFeAMw2+tM0hEKQirVoOYCkC7yC2AV6I6SoYC6dQXz5NH JG2f5O0GBu7vD7JRbMGPDHVoeveWCrSAah8ic3FzPYFf1MtL8Cmos+kDnfTDLsPLkRod 5ZcA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=1voauYFvoRFYL6Ma4oGFqR1aIqOzJ+/ZXazHjalSmFo=; b=f3NSbWdtSrF06KfnyEucOhCYIuccm2kOryb/HwA+uPWqcMQwvwZfJlqyvLGmpHoZ95 rbWmXLkLpEEx0wgz7B49XQb8lAn0L7kBlsAasiQDfAV1DnRbGa1fFMSiJc2VzF0VlWar PR60B4IziXWzR5hNVQ3YV1gzyj6Mh/pmfP0jXEJgEe4VskwhIPdjUHQXYM83llXRoUB+ bjrJZqC33z93KnY8n/4DahVtYhxpWnGDalgm+9Y9AOY8oWtJnkGn5OBCjwnqGlxGSYF/ NCex8QYffwHcS3sgxszq1j+lKAQ4KaWljfcroY3w2gm4BFcjFJ0UKyKNPP2eyzvjbNjR XGIQ== X-Gm-Message-State: ALKqPweLf6Zcfftxfpf+2kjqsrdtwm+8cZabx82hR4wTV+Bd3KKD3EdQ xNnRUYptNjjLTFeW2Lwp9L0MVGmLhgFrgTohXWw= X-Google-Smtp-Source: ADUXVKLGLn6wcSKAeD+i0ekmt6repL3zohxgRARg5gi2PEuVi6XEX4wN5nNmW9cL4DAy14FlJjhxmM1t2LjSmi8Isx4= X-Received: by 2002:aca:d593:: with SMTP id m141-v6mr7264305oig.346.1527493609147; Mon, 28 May 2018 00:46:49 -0700 (PDT) MIME-Version: 1.0 References: <152538075241.4552.6760702690778529507@ietfa.amsl.com> <370fc7abe18207138498d335bb688a7e@strayalpha.com> In-Reply-To: From: Martin Thomson Date: Mon, 28 May 2018 17:46:37 +1000 Message-ID: To: Henning Schulzrinne Cc: touch@strayalpha.com, architecture-discuss@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [arch-d] I-D Action: draft-iab-protocol-maintenance-00.txt X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.22 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, 28 May 2018 07:46:52 -0000 On Fri, May 25, 2018 at 5:10 AM Henning Schulzrinne wrote: > Indeed, we are agreeing and I wasn't clear on my point.. What I'm saying is that most cases (except the egregious "protocol dialects" mentioned earlier), the problem doesn't seem to be the Postel principle, but overly restrictive implementations that then force other applications to "dumb down" the spec that can be implemented or work around the limitations. There are two suggested actions, and yeah, most of our examples of bad appear to fall on the "be conservative in what you send" side. I'm not sure about "dumbing down" being bad. If our specifications can't be implemented easily, without errors, can't we claim some of the fault? We've learned the value of defensive design with crypto: yes it's possible to use RSA without creating a side channel, but it's shockingly hard. Absent AES-NI, the same can be said for AES-GCM. Those sorts of sharp edges have mostly been filed off for all of the recent primitives. > What I'm looking for is where an overly liberal implementation forced others to conform to their errant ways. Not an example of a forcing function, because Google don't seem to care, but perhaps relevant: https://www.theregister.co.uk/2018/04/10/gmail_netflix_phishing_vector/ I confess, I don't have any such examples ready-to-hand other than the above. I agree, it would be interesting if tolerance wasn't a problem here, but the tolerant rarely make a fuss, so their voices are harder to hear. From nobody Mon May 28 06:22:20 2018 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 098B8124217 for ; Mon, 28 May 2018 06:22:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 NSo-1rkai2Ds for ; Mon, 28 May 2018 06:22:15 -0700 (PDT) Received: from outprodmail02.cc.columbia.edu (outprodmail02.cc.columbia.edu [128.59.72.51]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 16083126579 for ; Mon, 28 May 2018 06:22:14 -0700 (PDT) Received: from hazelnut (hazelnut.cc.columbia.edu [128.59.213.250]) by outprodmail02.cc.columbia.edu (8.14.4/8.14.4) with ESMTP id w4SDKArD032625 for ; Mon, 28 May 2018 09:22:13 -0400 Received: from hazelnut (localhost.localdomain [127.0.0.1]) by hazelnut (Postfix) with ESMTP id BF2CA7E for ; Mon, 28 May 2018 09:22:13 -0400 (EDT) Received: from sendprodmail04.cc.columbia.edu (sendprodmail04.cc.columbia.edu [128.59.72.16]) by hazelnut (Postfix) with ESMTP id BB5616D for ; Mon, 28 May 2018 09:22:12 -0400 (EDT) Received: from mail-oi0-f71.google.com (mail-oi0-f71.google.com [209.85.218.71]) by sendprodmail04.cc.columbia.edu (8.14.4/8.14.4) with ESMTP id w4SDMCEa023561 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT) for ; Mon, 28 May 2018 09:22:12 -0400 Received: by mail-oi0-f71.google.com with SMTP id d1-v6so6965813oib.23 for ; Mon, 28 May 2018 06:22:12 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=gkntnlkjMW9pLs2dDGc6JQ6aKeAeWDGiVFHRIQ2WxWU=; b=Xrps4AVDrBuuPCXWdM7eg8ssTSwJE9FfgrB5NMNJ1Ez3tAmSNFroXrrwoA8duDaJaS wrVyIffpyaLUZQhadzJMUXzaEVWoZn/7hda3G+VjTlvg3HThZmRUljtm3OQKxjCurO28 wfV6tQ90s7f7ndTOJ7Zev5lA22kHrn34LdE9uWWYmtQ0DumrgfYUg2NFYlCO32vbCMKf sxTzkCU4wvUkpeVma3YK2iu4UAbT+b8d0y72qiGclhmXipmV8/3fxMnjwTWekfEGwaxA N3wcFJjYcRPe8QdKu5UCUxKHVIpf4IHMJ4qNpqXjf+N0Z+u8P7TmtnKkw8KoC7Y73+z6 pvXQ== X-Gm-Message-State: ALKqPwcoNw0LOxwnsU6bwiu0tBbaIUJD+vhDKNjzDCb6FUSef718YrcA kiZNZySfMx377aSUYhmarohPeioZC4SHVFA+T9hviWfyPIB0ljNFrAav9/OOk9NRHI4xyDjUOv/ WgEu9f2wav0tDqsJZzUQJbaYP0OlkwIFS+MVqz2ytVSmKQlEkCA== X-Received: by 2002:a9d:2f49:: with SMTP id h67-v6mr8897221otb.185.1527513731885; Mon, 28 May 2018 06:22:11 -0700 (PDT) X-Google-Smtp-Source: AB8JxZqDf8je6N/39yuue0TVWpMrNELwSI/CTZyVV4TmG70Qbe5G8P/UbvY7TqiOp9uGvzwPTryZzY4u0Y9Qm9Peigw= X-Received: by 2002:a9d:2f49:: with SMTP id h67-v6mr8897204otb.185.1527513731432; Mon, 28 May 2018 06:22:11 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a9d:59cd:0:0:0:0:0 with HTTP; Mon, 28 May 2018 06:21:50 -0700 (PDT) In-Reply-To: References: <152538075241.4552.6760702690778529507@ietfa.amsl.com> From: Henning Schulzrinne Date: Mon, 28 May 2018 13:21:50 +0000 Message-ID: To: Martin Thomson Cc: Robert Sparks , architecture-discuss@ietf.org Content-Type: multipart/alternative; boundary="0000000000005a16ce056d440195" X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.78 on 128.59.72.16 Archived-At: Subject: Re: [arch-d] I-D Action: draft-iab-protocol-maintenance-00.txt X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.22 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, 28 May 2018 13:22:18 -0000 --0000000000005a16ce056d440195 Content-Type: text/plain; charset="UTF-8" I think this adds up to a slightly different recommendation: "liberal" specifications that allow lots of variability in syntax or behavior are a bad idea. With hindsight, I think our text-based protocols would be better off without case-insensitivity, with very limited white space, no line folding and other restrictions. (Escaping is probably another common source of interoperability problems at the syntax level.) This partially explains the recent move (back) towards binary-style protocols. On Mon, May 28, 2018 at 7:11 AM, Martin Thomson wrote: > Top-posting here because I think that this highlights a common error we > make in our building of standards. > > Henning gave a concise example of another such example as well: "the spec > says case-insensitive, but applications are case-sensitive" (and several > others, all of which I've seen). [1] > > The standard exists to record an agreement, and if it is a poor match for > reality, it isn't worth much. If we consider the RFC to be a declaration > by fiat that this is what shall be, then if that agreement is demonstrably > different because the code says otherwise, what then? > > So, to answer Robert's question: > > On Fri, May 25, 2018 at 4:10 AM Robert Sparks > wrote: > > If I read what you suggest correctly, you would have preferred that the > > IETF have updated 3261 shortly after it was clear that this variant was > pervasive > > in deployment, and updated it again after the variant went away? > > More or less. If you are maintaining the protocol specification, you need > to reach an agreement with protocol participants. If the agreement was > that the clearly bad implementation needed to comply, then that's it. But > that really only works if the infringing party was willing to change - or > other implementations were willing to exclude that (popular) application. > > Given that particular situation, which involved a non-trivial period of > non-compliance, I might have suggested that documenting the variant would > be help, but frankly a year isn't that long. As long as the bug was > well-known, distributing knowledge might have been enough. Publishing an > RFC might have taken longer than fixing the bug. (That's another sad > story, but not for here.) > > The article that Henning cited was a great read. One thing in the thesis > there is that change (both good and bad) is primarily driven by a minority, > and that the primary precondition for success is that the minority is > intolerant. I still think that there is value in virtuous intolerance - an > earlier version of this draft advocated for it - the challenge being > two-fold: first in deciding whether one is being virtuous, and second in > managing the cost of your own exclusion for being so intolerant. > > [1] As an aside, SIP (also, SMTP and HTTP before it) invited this error by > allowing messages to be case-insensitive, then providing nicely consistent > casing in examples. When you consider the value provided by this "feature" > of these protocols, the cost has over time far outweighed the benefits. > Programmers are well used to getting case right, but the number of problems > from case variations has been high. I consider the case-insensitivity in > these protocols to be a misfeature. We were lucky to be able to remove > that feature for HTTP header fields with HTTP/2, but that was the result of > taking advantage of a rare opportunity. > > _______________________________________________ > Architecture-discuss mailing list > Architecture-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/architecture-discuss > --0000000000005a16ce056d440195 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I think this adds up to a slightly different recommendatio= n: "liberal" specifications that allow lots of variability in syn= tax or behavior are a bad idea.=C2=A0

With hindsight, I = think our text-based protocols would be better off without case-insensitivi= ty, with very limited white space, no line folding and other restrictions. = (Escaping is probably another common source of interoperability problems at= the syntax level.)

This partially explains the re= cent move (back) towards binary-style protocols.

On Mon, May 28, 2018 at 7:11 AM, Martin = Thomson <martin.thomson@gmail.com> wrote:
Top-posting here because I think that this highlight= s a common error we
make in our building of standards.

Henning gave a concise example of another such example as well: "the s= pec
says case-insensitive, but applications are case-sensitive" (and sever= al
others, all of which I've seen). [1]

The standard exists to record an agreement, and if it is a poor match for reality, it isn't worth much.=C2=A0 If we consider the RFC to be a decl= aration
by fiat that this is what shall be, then if that agreement is demonstrably<= br> different because the code says otherwise, what then?

So, to answer Robert's question:

On Fri, May 25, 2018 at 4:10 AM Robert Sparks <rjsparks@nostrum.com> wrote:
> If I read what you suggest correctly, you would have preferred that th= e
> IETF have updated 3261 shortly after it was clear that this variant wa= s
pervasive
> in deployment, and updated it again after the variant went away?

More or less.=C2=A0 If you are maintaining the protocol specification, you = need
to reach an agreement with protocol participants.=C2=A0 If the agreement wa= s
that the clearly bad implementation needed to comply, then that's it.= =C2=A0 But
that really only works if the infringing party was willing to change - or other implementations were willing to exclude that (popular) application.
Given that particular situation, which involved a non-trivial period of
non-compliance, I might have suggested that documenting the variant would be help, but frankly a year isn't that long.=C2=A0 As long as the bug w= as
well-known, distributing knowledge might have been enough.=C2=A0 Publishing= an
RFC might have taken longer than fixing the bug.=C2=A0 (That's another = sad
story, but not for here.)

The article that Henning cited was a great read.=C2=A0 One thing in the the= sis
there is that change (both good and bad) is primarily driven by a minority,=
and that the primary precondition for success is that the minority is
intolerant.=C2=A0 I still think that there is value in virtuous intolerance= - an
earlier version of this draft advocated for it - the challenge being
two-fold: first in deciding whether one is being virtuous, and second in managing the cost of your own exclusion for being so intolerant.

[1] As an aside, SIP (also, SMTP and HTTP before it) invited this error by<= br> allowing messages to be case-insensitive, then providing nicely consistent<= br> casing in examples.=C2=A0 When you consider the value provided by this &quo= t;feature"
of these protocols, the cost has over time far outweighed the benefits.
Programmers are well used to getting case right, but the number of problems=
from case variations has been high.=C2=A0 I consider the case-insensitivity= in
these protocols to be a misfeature.=C2=A0 We were lucky to be able to remov= e
that feature for HTTP header fields with HTTP/2, but that was the result of=
taking advantage of a rare opportunity.

_______________________________________________
Architecture-discuss mailing list
Architecture-discuss@ietf.= org
https://www.ietf.org/mailman/listinf= o/architecture-discuss

--0000000000005a16ce056d440195-- From nobody Mon May 28 13:55:16 2018 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 6272112DA73 for ; Mon, 28 May 2018 13:55:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=kumari-net.20150623.gappssmtp.com 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 ew-mDmiTu2IQ for ; Mon, 28 May 2018 13:55:11 -0700 (PDT) Received: from mail-wm0-x230.google.com (mail-wm0-x230.google.com [IPv6:2a00:1450:400c:c09::230]) (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 9E6EA12DB6E for ; Mon, 28 May 2018 13:55:10 -0700 (PDT) Received: by mail-wm0-x230.google.com with SMTP id x2-v6so27596433wmh.5 for ; Mon, 28 May 2018 13:55:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari-net.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=8m4TqpQ/E3N6qs90P+jTBnE/ezaEt2U5gpiuUHu4b1Q=; b=FhsciM9rThr3qbPMnngVRi2dQ4ABNQdEU/nGzd5oLNSjpjJ04khibS1z5QQQsabi2C bm3KbaEUdcFcDANB/FPblBSCVsIaR9RNOj5ejoSCf4HF2E4MD0wEwT1UTWo1AOuBbt7m 35/tTgynr814pzlGtlfgE2tI9KMSwkQmL9taTUhbEKd1M1hoIflkPPZpy2NHUf6PqqVk DjzmKo1tQKWJkpweFwJzptHaAXYn6d1QdcK0cVKO3F8iHpzbhA/HHc5rq86xPwiY0HVN csAsTqyWrKmYplkkVIYDPj/B9Oyk0AcTMvjjl06uCKiZcPDiYqehkmY2KWnGCf2Q/cvh plMQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=8m4TqpQ/E3N6qs90P+jTBnE/ezaEt2U5gpiuUHu4b1Q=; b=GiRlWOJvdITbO0Jg7E8eWCoc7nF152jyKjTFN2ZeMToymjyHIUkXwiyYpdEzSR4bZn 4EzI4d5X7ad0Cjc5AKtzqEG7XPh2eWN3MPl347pCwNReqGbKsNWcbdnbUFcA6H/8w4VB ZZigf3dx2uuCF+N8mbAe5boK/i6DlxWCuF7g9Ouo+dRh3pqxEdcNEp0Bu9Vpp5WGb4BR hSnGs3hA+s+mkLDVVhapD3r2bCjh77eIgMsAlVm/7WbCFwxYjFZVHYEIKlqc13YmELxA ezZsRQ8BFL4YSMJvFsQlRdsr/nGIHElSuHi+UT/mjtQADMHuO7CCJM+QTBhrL+KwKAKb 3asA== X-Gm-Message-State: ALKqPwdJZPOIWekA9X9EDbM3hROcZaHEVsN5ka8YEoLV8Zz8U4Ds9PW0 AHC9ehktQ600pkAwjwaUQLkM1jHo1A8wS6pB/eKTWg== X-Google-Smtp-Source: ADUXVKL2bl3q7oKQ1Omn5c1Rt8WLChht8e+36cbWo6+77aINNmwdkIQ8h1+1bHwWSA7HZlLcEHRQEPUHuzbfw/UqyPM= X-Received: by 2002:a1c:1103:: with SMTP id 3-v6mr9158120wmr.26.1527540908585; Mon, 28 May 2018 13:55:08 -0700 (PDT) MIME-Version: 1.0 References: <152279331966.23985.3238502800355132103.idtracker@ietfa.amsl.com> In-Reply-To: From: Warren Kumari Date: Mon, 28 May 2018 16:54:57 -0400 Message-ID: To: Spencer Dawkins at IETF Cc: IAB IAB , architecture-discuss@ietf.org Content-Type: multipart/alternative; boundary="0000000000003c8b6d056d4a555a" Archived-At: Subject: Re: [arch-d] Call for Comment: (IAB Workshop on Managing Radio Networks in an Encrypted World (MaRNEW) Report) X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.22 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, 28 May 2018 20:55:15 -0000 --0000000000003c8b6d056d4a555a Content-Type: text/plain; charset="UTF-8" Great, thanks! W On Thu, May 24, 2018 at 7:04 PM Spencer Dawkins at IETF < spencerdawkins.ietf@gmail.com> wrote: > Hi, Warren, > > Thanks for the comments! > > Inline ... > > On Tue, Apr 10, 2018 at 5:10 PM Warren Kumari wrote: > >> I think it would be useful to have the date of the MarNEW workshop >> near the top of the document (perhaps "The MarNEW workshop (September, >> 2015) aimed ...") - our tone and understanding of the issues being >> discussed has changed significantly in the 2 years, 7 months since the >> workshop happened. >> > > Absolutely. > > >> >> The document also talks about things like "From a recent study >> [Pew2014] 64% of users said..." -- Pew2014 was ~1 year old when the >> workshop occurred, but it's now 3 years 5 months in the past -- not >> really "recent" any more. >> > > Yeah ... I found two occurrences, which are now "then-current". I think > that's fair. > > >> Nits: >> Abstract: >> "The MarNEW workshop" MarNEW -> MaRNEW >> > > This text was actually replaced, and the new text has the capitalization > correct. > >> >> s/understandinf/understanding/ >> > > Fixed. > > >> >> >> W >> >> >> On Tue, Apr 3, 2018 at 6:08 PM, IAB Executive Administrative Manager >> wrote: >> > This is an announcement of an IETF-wide Call for Comment on >> > draft-iab-marnew-report-01. >> > >> > The document is being considered for publication as an Informational RFC >> > within the IAB stream, and is available for inspection at: >> > https://datatracker.ietf.org/doc/draft-iab-marnew-report/ >> > >> > The Call for Comment will last until 2018-05-01. Please send comments to >> > architecture-discuss@ietf.org and iab@iab.org. >> > >> > >> > Abstract >> > >> > The MarNEW workshop aimed to discuss solutions for bandwidth >> > optimisation on mobile networks for encrypted content, as current >> > solutions rely on unencrypted content which is not indicative of the >> > security needs of today's Internet users. The workshop gathered IETF >> > attendees, IAB members and various organisations involved in the >> > telecommunications industry including original equipment >> > manufacturers and mobile network operators. >> > >> > The group discussed the current Internet encryption trends and >> > deployment issues identified within the IETF, and the privacy needs >> > of users which should be adhered. Solutions designed around sharing >> > data from the network to the endpoints and vice versa were then >> > discussed as well as analysing whether the current issues experienced >> > on the transport layer are also playing a role here. Content >> > providers and CDNs gave an honest view of their experiences delivery >> > content with mobile network operators. Finally, technical responses >> > to regulation was discussed to help the regulated industries relay >> > the issues of impossible to implement or bad-for-privacy technologies >> > back to regulators. >> > >> > A group of suggested solutions were devised which will be discussed >> > in various IETF groups moving forward. >> > >> >> >> >> -- >> I don't think the execution is relevant when it was obviously a bad >> idea in the first place. >> This is like putting rabid weasels in your pants, and later expressing >> regret at having chosen those particular rabid weasels and that pair >> of pants. >> ---maf >> >> _______________________________________________ >> Architecture-discuss mailing list >> Architecture-discuss@ietf.org >> https://www.ietf.org/mailman/listinfo/architecture-discuss >> > -- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf --0000000000003c8b6d056d4a555a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Great, thanks!


W

On Thu, May 24, = 2018 at 7:04 PM Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com> wrote:
Hi, Warren,

Thanks for = the comments!=C2=A0

Inline ...=C2=A0

<= div class=3D"gmail_quote">
On Tue, Apr 10, 2018 at 5:10 PM Warren Kumari <warren@kumari.net&g= t; wrote:
I think it would be usefu= l to have the date of the MarNEW workshop
near the top of the document (perhaps "The MarNEW workshop (September,=
2015) aimed ...") - our tone and understanding of the issues being
discussed has changed significantly in the 2 years, 7 months since the
workshop happened.

<= div>
Absolutely.=C2=A0
=
=C2=A0

The document also talks about things like "From a recent study
[Pew2014] 64% of users said..." -- Pew2014 was ~1 year old when the workshop occurred, but it's now 3 years 5 months in the past -- not
really "recent" any more.

Yeah ... I f= ound two occurrences, which are now "then-current". I think that&= #39;s fair.=C2=A0
=C2=A0
Nits:
Abstract:
"The MarNEW workshop" MarNEW -> MaRNEW
<= div>This text was actually replaced, and the new text has the capitalizatio= n correct.=C2=A0=C2=A0

s/understandinf/understanding/

Fixed.
=C2=A0


W


On Tue, Apr 3, 2018 at 6:08 PM, IAB Executive Administrative Manager
<execd@iab.org>= ; wrote:
> This is an announcement of an IETF-wide Call for Comment on
> draft-iab-marnew-report-01.
>
> The document is being considered for publication as an Informational R= FC
> within the IAB stream, and is available for inspection at:
> https://datatracker.ietf.org/doc/draft= -iab-marnew-report/
>
> The Call for Comment will last until 2018-05-01. Please send comments = to
> arc= hitecture-discuss@ietf.org and iab@iab.org.
>
>
> Abstract
>
>=C2=A0 =C2=A0 The MarNEW workshop aimed to discuss solutions for bandwi= dth
>=C2=A0 =C2=A0 optimisation on mobile networks for encrypted content, as= current
>=C2=A0 =C2=A0 solutions rely on unencrypted content which is not indica= tive of the
>=C2=A0 =C2=A0 security needs of today's Internet users.=C2=A0 The w= orkshop gathered IETF
>=C2=A0 =C2=A0 attendees, IAB members and various organisations involved= in the
>=C2=A0 =C2=A0 telecommunications industry including original equipment<= br> >=C2=A0 =C2=A0 manufacturers and mobile network operators.
>
>=C2=A0 =C2=A0 The group discussed the current Internet encryption trend= s and
>=C2=A0 =C2=A0 deployment issues identified within the IETF, and the pri= vacy needs
>=C2=A0 =C2=A0 of users which should be adhered.=C2=A0 Solutions designe= d around sharing
>=C2=A0 =C2=A0 data from the network to the endpoints and vice versa wer= e then
>=C2=A0 =C2=A0 discussed as well as analysing whether the current issues= experienced
>=C2=A0 =C2=A0 on the transport layer are also playing a role here.=C2= =A0 Content
>=C2=A0 =C2=A0 providers and CDNs gave an honest view of their experienc= es delivery
>=C2=A0 =C2=A0 content with mobile network operators.=C2=A0 Finally, tec= hnical responses
>=C2=A0 =C2=A0 to regulation was discussed to help the regulated industr= ies relay
>=C2=A0 =C2=A0 the issues of impossible to implement or bad-for-privacy = technologies
>=C2=A0 =C2=A0 back to regulators.
>
>=C2=A0 =C2=A0 A group of suggested solutions were devised which will be= discussed
>=C2=A0 =C2=A0 in various IETF groups moving forward.
>



--
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
=C2=A0 =C2=A0---maf

_______________________________________________
Architecture-discuss mailing list
Architec= ture-discuss@ietf.org
https://www.ietf.org/mailman/listinfo/arc= hitecture-discuss
--
I d= on't think the execution is relevant when it was obviously a bad idea i= n the first place.
This is like putting rabid weasels in your pants, and= later expressing regret at having chosen those particular rabid weasels an= d that pair of pants.
=C2=A0 =C2=A0---maf
--0000000000003c8b6d056d4a555a-- From nobody Mon May 28 16:15:55 2018 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 5A37712E866 for ; Mon, 28 May 2018 16:15:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 PtYDo7URF5P3 for ; Mon, 28 May 2018 16:15:50 -0700 (PDT) Received: from mail-pl0-x22d.google.com (mail-pl0-x22d.google.com [IPv6:2607:f8b0:400e:c01::22d]) (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 618DA12E04F for ; Mon, 28 May 2018 16:15:50 -0700 (PDT) Received: by mail-pl0-x22d.google.com with SMTP id 30-v6so7836658pld.13 for ; Mon, 28 May 2018 16:15:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=s0/U7oyj8nzIV37O7b+SFoLCUGXd37S5t8OWavYzdGc=; b=gvdtm+vJTqOB9rKFzCGItC6RRjuhXeR4ptZ2orr2m9eKCVDQ2PCX1bNtwPLzEmib3l gl71J3opLHLUUh824Y2yzS19pUV2hKD9I+B7m5VLpPFKQ3+hnNFspiUfsKVZofYCQ6zt VSy2i6aSMeunTnIXY5ziJJORwhgG7j3JAOuFoKYRpD34a5VA/y22PIuyfeTtVsrvCjKE egiLBzIJpzluL8gUltV5z4p7XmmCApsgO+3zDvckAKtzUvb/1n+BV3b0YhbjCZYJH5Xg OocMEnsh2cUGBXaS4xVYd719CIvj/taSIerQTJnXM5I3wG+YCkm7Liu+4pBTQCqZbJSj DZhQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=s0/U7oyj8nzIV37O7b+SFoLCUGXd37S5t8OWavYzdGc=; b=ME7khDwN2X1UOfb6buCN7foLUg/jLG7WoTmJlJ9dgGWT8SaWI3pgnLRnFoUwyHySK9 T8rEFlbCboSbwem9tmlM1GUhDAYt+E/A2VB0W0/RHdQnRYyns/viuELYGWzth8sATXRS Czz0qHVh+UixmAqRQCVi0VMK27BfmKFo4Hhdv8Uu/vqOSp5+8YEsXIx6z8PHzUf6PNLI flOI2AdBfVmyCfXC3j/bAoay1VGYV638FLsE5lxg/gYM9JowAKHJDAsXTbw4tmaAe6qR uTaeut+TBVM6oOWMuwTjLJOMaUNkd72LOB0x9FVi6q0FgnI5WoE85fnoWXnall0QLuXA orkQ== X-Gm-Message-State: ALKqPwdijGrwrOEHr68dhRY+1Zom7H7Np8s6/ROwrdwWLdK3Q7EVfg8g nr1ovZ5dRbBG2AdvYYq8ICdwcg== X-Google-Smtp-Source: AB8JxZp6Gt4QZY8MCn/J2SAiAOZEgZUykc5ankJTq+k06dS/mC0gGIZ733DOs09ChbMsyz5kg0ZlAQ== X-Received: by 2002:a17:902:7b97:: with SMTP id w23-v6mr15599636pll.116.1527549349425; Mon, 28 May 2018 16:15:49 -0700 (PDT) Received: from [192.168.178.21] ([118.148.121.80]) by smtp.gmail.com with ESMTPSA id v5-v6sm48719470pff.130.2018.05.28.16.15.46 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 28 May 2018 16:15:48 -0700 (PDT) To: Martin Thomson Cc: architecture-discuss@ietf.org References: <152538075241.4552.6760702690778529507@ietfa.amsl.com> From: Brian E Carpenter Message-ID: <09be44d2-929e-0e2c-52e1-c72ce93a6410@gmail.com> Date: Tue, 29 May 2018 11:15:46 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [arch-d] I-D Action: draft-iab-protocol-maintenance-00.txt X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.22 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, 28 May 2018 23:15:54 -0000 On 24/05/2018 14:12, Martin Thomson wrote: > Hi Brian, > > Thanks for articulating your views here. I think that we have different > notions of what this thing is still... > > On Sat, May 19, 2018 at 11:53 AM Brian E Carpenter < > brian.e.carpenter@gmail.com> wrote: >> If we don't hear from other voices here, that isn't OK. > > Work in progress :) Indeed. I paused for a few days to see what other people thought. > >>> It's possible that our disagreement stems from a disconnect regarding > the There's an issiue right there: sloppy specification of line wrapping in email, plus the way it interacts with "> " quoting and/or CRLF vs LF alone, not to mention some UAs that appear to generate only html, all leads to shattered text that needs human or artificial intelligence to process properly. >>> scope of the application of the robustness principle. I think that the >>> "When in doubt" part clearly limits its applicability to situations > where >>> there is insufficient or unclear specification. It seems like you might >>> have a broader notion of the idea. It might pay to push on that notion > a >>> little. I've done a little of that below. > >> I think there are several aspects. > >> #1. The robustness principle should indirectly guide protocol design. >> Firstly there should be no unspecified parts of any PDU. Secondly, >> there should be no unspecified responses to any valid or invalid parts >> of any PDU. If you do that correctly, the robustness principle isn't >> needed in any implementation. > > Hmm, perhaps we see this differently. I see this more as a case of "well, > we know that implementations are going to screw this up if we don't specify > things, what can we do to avoid that?". That mostly involves specifying > semantics for everything. Describing what it means to send every valid > value and describing what to do with every other value. > > I don't see this as being informed by the robustness principle as much as > it is just writing down a complete specification. My argument is really that designers need to bear in mind that if they leave loose ends of any kind, it is very probable that implementers *will* deal with those loose ends via the robustness principle, for reasons that Tony Li stated. If you argue that this is a bad thing, I won't disagree, but my conclusion is not that the robustness principle is a mistake - it's that specs should not leave loose ends. > >> But we know that in real life either specifications are imperfect, >> or implementations are imperfect, or both. Therefore: > >> #2. Test or reference implementations should verify that all parts >> of all PDUs are valid. Invalid items should be logged and reported. >> (Whether test implementations should also generate invalid PDUs >> in order to test the other end is a separate question.) > >> I hope we agree so far. Then we get to: > >> #3. Production implementations should ... > >> where we apparently disagree. The fact is that production >> implementations have to make the best of what they are given, >> which is typically a mixture of design errors in the protocol >> and implementation errors in other implementations. What is >> an implementer going to do except tolerate and recover from >> errors? Users expect apps to work, whatever happens. So that's >> what implementers will do, regardless of RFCs. The only thing >> that's changed since the robustness principle was formulated >> is that there are thousands of times more users and they are less >> tolerant than ever of failure modes. > > Yes. We clearly disagree. Maybe there's a time sequence that we need to > be sensitive to here though. > > The first implementation, A, contains a mistake. It allows value X, which > is maybe not specified clearly enough, to be interpreted as a Y. > > The second implementation, B, sends X sometimes. This is also a mistake, > but it doesn't get caught because A does that. > > The third implementation, C, rejects messages with X. Now we have an > interop issue sometimes when B talks to C. > > So you say that the robustness principle leaps to the rescue. C can > discover the problem and adjust to tolerate X somehow. > > But C just kicked the can down the road. How does C discover that Y is the > right way to interpret X? What if they choose Z? Things might appear to > continue to work, but the difference between Y and Z mean that you have new > problems until the next fix. > > The application of the robustness principle assumes that C discovers the > problem first (which is likely, see also Langley's law of the internet: > "blame attaches to the last thing that changed" -- > https://www.imperialviolet.org/2016/05/16/agility.html ). It also assumes > that A and B won't or can't change, That's right. And if A and B have 100% of the market when C arrives, then C has little choice. It can't even carve out a niche for itself, and it has no commercial choice but to hack whatever needs to be hacked to interoperate with both of the others. As the conversation has showed, this isn't a theoretical argument. > and that the spec can't be fixed. Even if we do fix the spec, it's very unclear that A or B will change, because it will cost them money and will only help C. > > That sounds like more work with limited prospects for success. But I think > that's a little defeatist. The apathy that its application implies, as > much as the principle itself, is the target I'm aiming at here. I don't think it is apathy - it's in the commercial self-interest of A and B to keep C out of the market. Open source might help here, of course, since it changes the incentives and the motivations of the players. > It is less > possible now than it ever was to release software (or protocols) onto the > Internet and walk away, so the odds of finding and engaging with other > implementers is pretty good. I think that still varies enormously from case to case. Basically that's why I believe the draft is unbalanced. >>> > https://martinthomson.github.io/postel-was-wrong/implementation-robustness/draft-iab-protocol-maintenance.html > >> That's 404, unfortunately. Synch problem?? > > Name change problem. We have an intarchboard repo on github, and we > recently moved this there. > > https://intarchboard.github.io/protocol-maintenance/implementation-robustness/draft-iab-protocol-maintenance.html Thanks. The proposed changes are all improvements. All the same, I still think the tone (including the title) is wrong. I think we agree that the robustness principle isn't a get-out-of-jail card; it's more of a survival tactic. The draft doesn't recognise that in many situations it's unavoidable. Minimising those situations is a very valid goal. >>> Once particularly nasty consequence was the application of this retry to >>> version intolerance. That is, there was a strong tendency of servers to >>> fail to connect if a client offered a newer protocol version. For > example, >>> we saw astonishingly high rates of intolerance to TLS 1.3 before the >>> version negotiation mechanism there was redesigned. Some tests saw > around >>> 20% failure rates. That resulted in TLS - as deployed - being > vulnerable >>> to a range of trivial downgrade attacks, some of which are listed in RFC >>> 7457. > >> Yes. But all of this seems to be due to weak design in SSL; blame that, >> not the subsequent 3rd party efforts to fix that design, as the >> root cause. > > This is a good point to latch on to. We might like to believe that a good > design is the answer, but I don't think that SSL is fundamentally a bad > design, mostly it's just some choices, some of which might be made > differently by different people. Yes, failing to allow for extensibility > is a fairly bad mistake, and there were others that were worse. I don't > think that we can so easily dismiss the example because the protocol was so > bad. As RFC 5218 established, we don't really get to choose which > protocols become successful, and a good design is no prerequisite. Also, of course, "good" is always a judgment. But postulating that SSL is fundamentally a good design, it clearly had defects too, and it still remains to be seen whether TLS has finally fixed them. > We might extract different wisdom from the lesson, but I see this an > application of maintenance. TLS extensions are effectively 100% reliable > today. And mainly because the community collectively has maintained both > the specification and the implementations. If you like, think of it as > pigs flying given sufficient thrust; which is perhaps a good analogy for > the lessons of RFC 5218. The other thing about SSL/TLS is that it was, and is, terribly important: a viable approach to e2e security for any arbitrary pair of endpoints, unlike IPsec. That amplifies the effect of its defects. Regards Brian From nobody Mon May 28 17:51:02 2018 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 2E06E12E05D for ; Mon, 28 May 2018 17:51:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 uCbLAd-Y3heO for ; Mon, 28 May 2018 17:50:58 -0700 (PDT) Received: from mail-ot0-x236.google.com (mail-ot0-x236.google.com [IPv6:2607:f8b0:4003:c0f::236]) (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 9D12212E050 for ; Mon, 28 May 2018 17:50:58 -0700 (PDT) Received: by mail-ot0-x236.google.com with SMTP id l13-v6so15125077otk.9 for ; Mon, 28 May 2018 17:50:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=IuuTRDnHI3aAHHIjwCzGlfopPg8WGbmpxunZfJglZGY=; b=f3qGnn31Q7pDckYLp8iTGFFssraUFTGwqkrt9aBxf4LfLo3RPgqgCHOiVkMtG5xCgH JD8BY9B5J1ZY5UJNV+OcF1KRUgynt/JJmt/NlyiXCOu57ZPFit8l33vyuC70aQ7XgKIM fU16ansBfeAkTTJ4G3Lj5HOPPfkVit/u6K8yfrdI3GECyn2NdZW3vsfjRf0nRqHIyo2R ne6K0RQ350RCQIw82DI5vEke2rHQZ8Fi/yMjFM7zZIx/7eVKx+w6fxPDhrHcRFaR/lX5 fZsfGnLkquMOrqey3ddfyiI2ozZsjBDZo/8a02x4aqXrAMyv9m2Kcg9SkEODmt9A10oG iFFA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=IuuTRDnHI3aAHHIjwCzGlfopPg8WGbmpxunZfJglZGY=; b=sk1VhTrelnJ4ia7jCghc0xPGf59+nX+RXTwsc9Q+8d+fBPeIEV1yRaxqZmH4vxKqjE OHXzTpBOfIoBkteh/Ue1mrer8dsX/HjGPGoX+mbvOiWVb1VNednOYldVBbwWrFO0NFka MUOwHfIl/eJshCcpIF3m0jyZnQyvhs9RPspMgP3RAd2hyJLjot7O9G8MbKtZ6P9+EBBa u2djDi5JrJVTUs7B8rFfdzxc/wUTArZrztOAGw3VzdL1MKm3nfCNubC/hfIduLLPtiBq PyEeGLMBq+kqbeQGGUzGJhHQy8l+t210B8VwEii/tJQolaVvdHPgtKYwlTMNnIhWs70S mM9g== X-Gm-Message-State: ALKqPwdGUZGI8mjSoTIB0M8nLtKP7ZeIqqG/V9pQgQp92XZ9BttdIPK1 WXEihpCzKJDSdS60kW4W7UCBiY9gMYfVQEuMewIv6A6t X-Google-Smtp-Source: ADUXVKL2cmaRwjhUim99mcnmXjKx4IsInuC2mt0LLbuHE2g3CgHDeG6Kr1Nw3Y7mwO3Ive0t+FzuphIEah8AoicINe8= X-Received: by 2002:a9d:3637:: with SMTP id w52-v6mr9396098otb.394.1527555057856; Mon, 28 May 2018 17:50:57 -0700 (PDT) MIME-Version: 1.0 References: <152538075241.4552.6760702690778529507@ietfa.amsl.com> In-Reply-To: From: Martin Thomson Date: Tue, 29 May 2018 10:50:47 +1000 Message-ID: To: Henning Schulzrinne Cc: Robert Sparks , architecture-discuss@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [arch-d] I-D Action: draft-iab-protocol-maintenance-00.txt X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.22 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, 29 May 2018 00:51:00 -0000 On Mon, May 28, 2018 at 11:22 PM Henning Schulzrinne wrote: > I think this adds up to a slightly different recommendation: "liberal" specifications that allow lots of variability in syntax or behavior are a bad idea. Yes, that too :) > With hindsight, I think our text-based protocols would be better off without case-insensitivity, with very limited white space, no line folding and other restrictions. (Escaping is probably another common source of interoperability problems at the syntax level.) Actually I was going to use SDP as an example of this. It's not case-sensitive, nor is it supposed to be tolerant of arbitrary whitespace. You read the RFCs and you could be forgiven from getting the impression that the usual separator is a single space (not tab nor zero-width non-breaking space). However, it turns out that it is a great example of over-tolerance being imposed on others. I don't know when this started, but SDP implementations have to accept HTAB in practice. We saw this when we were beating the SDP parser we were bequeathed into shape. It's one of the originals, and it seems like this is simply a result of being overly tolerant. From nobody Mon May 28 18:06:11 2018 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 195A212E87D for ; Mon, 28 May 2018 18:06:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 D46YCfCcQmmj for ; Mon, 28 May 2018 18:06:08 -0700 (PDT) Received: from outprodmail02.cc.columbia.edu (outprodmail02.cc.columbia.edu [128.59.72.51]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 13BD612E881 for ; Mon, 28 May 2018 18:06:07 -0700 (PDT) Received: from hazelnut (hazelnut.cc.columbia.edu [128.59.213.250]) by outprodmail02.cc.columbia.edu (8.14.4/8.14.4) with ESMTP id w4T166Hg040986 for ; Mon, 28 May 2018 21:06:06 -0400 Received: from hazelnut (localhost.localdomain [127.0.0.1]) by hazelnut (Postfix) with ESMTP id B5BE98D for ; Mon, 28 May 2018 21:06:06 -0400 (EDT) Received: from sendprodmail03.cc.columbia.edu (sendprodmail03.cc.columbia.edu [128.59.72.15]) by hazelnut (Postfix) with ESMTP id 7F38295 for ; Mon, 28 May 2018 21:06:03 -0400 (EDT) Received: from mail-oi0-f69.google.com (mail-oi0-f69.google.com [209.85.218.69]) by sendprodmail03.cc.columbia.edu (8.14.4/8.14.4) with ESMTP id w4T1637l056238 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT) for ; Mon, 28 May 2018 21:06:03 -0400 Received: by mail-oi0-f69.google.com with SMTP id p186-v6so1323186oic.22 for ; Mon, 28 May 2018 18:06:03 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=eva1BMiH+k8LtGchgXsbMKIC1lfrKkdG/9PY7zQeL2o=; b=Ur0gdzMsqBzWx9gGxnQk+7DMcU8aWnPScdg6YjrR4MGWQfluBPyrcGTMaj78oplJSi 8lTIYjvqKoCbs1H/49IjkgKLStHztv01OtIG0WH6chWDVsRd2X7MWMCPHSNEtRPQ28dd +9wbS/OYLF7C7gfk/UM7+zanZoJ9xnCCC9zHWC9qJ22F0jsG3F/rVqRfX7xhu5+T5pcw 4Ipz3h56ph/2gXjxkNUFSB/Mnu/NO1+2X1xD+BVf15e2aOlYJ5eFP4nZDwudLQ14gJSW lVKYRoTQkH/f6gMww3zYbo4b4sMRbkMbCCUhasT7Y1VzjadlanYsevCTl6vsIv360GAR peBw== X-Gm-Message-State: ALKqPwfJQBLCNx1SCAGUSFCiGvynXH0DR0SVeH+emZ2fkr+orz+WJesl KQX7Sk2MYWRn+zIJZIryaFGK7lNTHZMgbG2oCq8GX5JFx/VQFYrB25iDxtop9XQLgAExNzcNNW+ sXuqtI4oKWGKgMswLijThMaCLcOlu9EfkH2bVR7L2XufR/Bxf1A== X-Received: by 2002:a9d:3898:: with SMTP id p24-v6mr3609909otc.267.1527555962734; Mon, 28 May 2018 18:06:02 -0700 (PDT) X-Google-Smtp-Source: ADUXVKLpHphXy8/qEQnTP2dmb7swcC4Iqg8pc+ARLzRYdQjFs+4J1lR975Y6GkPOXY2WKsiYZ7g1H246scisBnMYUmY= X-Received: by 2002:a9d:3898:: with SMTP id p24-v6mr3609897otc.267.1527555962376; Mon, 28 May 2018 18:06:02 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a9d:59cd:0:0:0:0:0 with HTTP; Mon, 28 May 2018 18:05:41 -0700 (PDT) In-Reply-To: References: <152538075241.4552.6760702690778529507@ietfa.amsl.com> From: Henning Schulzrinne Date: Tue, 29 May 2018 01:05:41 +0000 Message-ID: To: Martin Thomson Cc: Robert Sparks , architecture-discuss@ietf.org Content-Type: multipart/alternative; boundary="0000000000008335d9056d4dd6c7" X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.78 on 128.59.72.15 Archived-At: Subject: Re: [arch-d] I-D Action: draft-iab-protocol-maintenance-00.txt X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.22 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, 29 May 2018 01:06:10 -0000 --0000000000008335d9056d4dd6c7 Content-Type: text/plain; charset="UTF-8" Thanks for the example. I don't know how this started, but I suspect that this is one way how "culture" beats back attempts to reign in older bad ideas. Since all (or almost all) other IETF text protocols accept HTAB as separator, implementors may just assume that they should, too. The only advice I can deduce: if your spec deviates from long-held cultural assumptions, shout out the deviation (and motivate it), rather than letting the ABNF whisper. On Tue, May 29, 2018 at 12:50 AM, Martin Thomson wrote: > On Mon, May 28, 2018 at 11:22 PM Henning Schulzrinne > wrote: > > I think this adds up to a slightly different recommendation: "liberal" > specifications that allow lots of variability in syntax or behavior are a > bad idea. > > Yes, that too :) > > > With hindsight, I think our text-based protocols would be better off > without case-insensitivity, with very limited white space, no line folding > and other restrictions. (Escaping is probably another common source of > interoperability problems at the syntax level.) > > Actually I was going to use SDP as an example of this. It's not > case-sensitive, nor is it supposed to be tolerant of arbitrary whitespace. > You read the RFCs and you could be forgiven from getting the impression > that the usual separator is a single space (not tab nor zero-width > non-breaking space). > > However, it turns out that it is a great example of over-tolerance being > imposed on others. I don't know when this started, but SDP implementations > have to accept HTAB in practice. We saw this when we were beating the SDP > parser we were bequeathed into shape. It's one of the originals, and it > seems like this is simply a result of being overly tolerant. > --0000000000008335d9056d4dd6c7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks for the example. I don't know how this started,= but I suspect that this is one way how "culture" beats back atte= mpts to reign in older bad ideas. Since all (or almost all) other IETF text= protocols accept HTAB as separator, implementors may just assume that they= should, too.=C2=A0

The only advice I can deduce: if you= r spec deviates from long-held cultural assumptions, shout out the deviatio= n (and motivate it), rather than letting the ABNF whisper.

On Tue, May 29, 2018 at 12:50 = AM, Martin Thomson <martin.thomson@gmail.com> wrote:<= br>
On Mon, May 28, 2018 at 11:22 PM Henning = Schulzrinne <hgs@cs.columbia.edu<= /a>>
wrote:
> I think this adds up to a slightly different recommendation: "lib= eral"
specifications that allow lots of variability in syntax or behavior are a bad idea.

Yes, that too :)

> With hindsight, I think our text-based protocols would be better off without case-insensitivity, with very limited white space, no line folding<= br> and other restrictions. (Escaping is probably another common source of
interoperability problems at the syntax level.)

Actually I was going to use SDP as an example of this.=C2=A0 It's not case-sensitive, nor is it supposed to be tolerant of arbitrary whitespace.<= br> You read the RFCs and you could be forgiven from getting the impression
that the usual separator is a single space (not tab nor zero-width
non-breaking space).

However, it turns out that it is a great example of over-tolerance being imposed on others.=C2=A0 I don't know when this started, but SDP implem= entations
have to accept HTAB in practice.=C2=A0 We saw this when we were beating the= SDP
parser we were bequeathed into shape.=C2=A0 It's one of the originals, = and it
seems like this is simply a result of being overly tolerant.

--0000000000008335d9056d4dd6c7-- From nobody Mon May 28 18:35:02 2018 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 16AB112E865 for ; Mon, 28 May 2018 18:35:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=nomountain-net.20150623.gappssmtp.com 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 r7Q7AB-GtpMk for ; Mon, 28 May 2018 18:34:57 -0700 (PDT) Received: from mail-pf0-x232.google.com (mail-pf0-x232.google.com [IPv6:2607:f8b0:400e:c00::232]) (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 9702112E8C5 for ; Mon, 28 May 2018 18:34:57 -0700 (PDT) Received: by mail-pf0-x232.google.com with SMTP id a20-v6so6498661pfo.0 for ; Mon, 28 May 2018 18:34:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nomountain-net.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=BkQWMxNDBpdpwuuQNjn+lirxrRQpa0ypzLaGHGnoytc=; b=J+UettKwyzw/6SpYsvY8tmfBlnbkjcVLSV7UrcwT1KqRpRBKPSUrsGMVFt67MJOZEA +93a0Z1/gkis3E1hlI3PZE2j6p+cujBJcQV9+EqTohfAP7hGU8fUqDrjFgWEqLqXiQxu fnGC7W5F8rGxSwmnnvtSBtTCa9pdMEH5759MswT52D0Du3gbjJJJvo1BwYNCkfw7Wb9v Uy8oMrIsC5sBbd6xspuuLCcfBsfhRR0IqE9dJlw8kJbvtkyLliUwfCmkpNQSb3eCJsR2 H9dOv9yqJ/gkUvkqsYPmLRXn9PQBuvx5ET9EZKDR0kSDIToDQMvR9hLS/ct+hVTm2qJi zSnA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=BkQWMxNDBpdpwuuQNjn+lirxrRQpa0ypzLaGHGnoytc=; b=Y9pgK60wYerO7mvCwNNQQbmdpJWwgLtD2U5s8ykMQ4JW8YbBG8S83TTOduQRc8ag2t 03uBMzhOJyFCVH9StUoSYCD1yIPCp7PFgQ67GbhvpuxMlxS9ytwv78BBmPaAja7Lb42a 1NLczRUPXZxwM+il8+y9WHZCfTTXFS2r57XcjT8eNR7qh4bTOHisYSnyUnRgdGeXp5vo FbIFZc1Kl/F6M+ln0+zzI1IVj1gzmimEpOkINk+gcRd/cZcycRI7WOgU+iMs59CiaSRD Cx4siP48LgO9jxtJu4CSjiyM/4fyoPIO390edNttWe9T1dUkNTeKoyHsNcYySUcm+ECX eWcg== X-Gm-Message-State: ALKqPwec/w2ztPSE/3p6Sh5SOCD9ojdt76MC9J4lp14iwFj81mUd3htE vKIVqWufYTtpoPns21wnnPDw2ts= X-Google-Smtp-Source: AB8JxZqGIhbTB+1F3eGzPWDCy61VvPh0YWYRVn/g7slxaA288iKD4k9xKixFwqiArt1J9KeEZe9bFA== X-Received: by 2002:a65:6496:: with SMTP id e22-v6mr12206865pgv.386.1527557696870; Mon, 28 May 2018 18:34:56 -0700 (PDT) Received: from aspen.local (63-140-82-121-radius.dynamic.acsalaska.net. [63.140.82.121]) by smtp.gmail.com with ESMTPSA id n5-v6sm49130406pff.134.2018.05.28.18.34.55 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 28 May 2018 18:34:56 -0700 (PDT) To: architecture-discuss@ietf.org References: <152538075241.4552.6760702690778529507@ietfa.amsl.com> <370fc7abe18207138498d335bb688a7e@strayalpha.com> From: Melinda Shore Message-ID: <998ae111-dc0d-e128-9d0d-123a61e627c0@nomountain.net> Date: Mon, 28 May 2018 17:34:54 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [arch-d] I-D Action: draft-iab-protocol-maintenance-00.txt X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.22 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, 29 May 2018 01:35:00 -0000 On 5/27/18 11:46 PM, Martin Thomson wrote: > I'm not sure about "dumbing down" being bad. If our specifications can't > be implemented easily, without errors, can't we claim some of the fault? I think so. It's been my experience that for general guidance for implementers tends to be appreciated primarily by the authors of the guidance, and implementers of IETF protocols will tend not to root around in IETF documents not directly related to the protocol spec. So I think that if there's anything productive to be done here it's probably best written for an IETF audience (esp. for those people who tend to do document reviews). At this point I think we have a pretty good handle on what sorts of implementation errors are made most often, and figuring out how to specify defensively seems like a worthwhile effort. I'm not sure that revisiting the Postel rule will, in and of itself, change much. That is to say that I can see the value in a document along these lines, but I think that framing it in terms of revising the Postel rule will tend not to reach quite the right audience for fixing known problems, and not incidentally has all sorts of cultural baggage associated with it that I'm not sure would be productive to deal with. Melinda -- Software longa, hardware brevis PGP fingerprint: 4F68 2D93 2A17 96F8 20F2 34C0 DFB8 9172 9A76 DB8F From nobody Tue May 29 07:32:50 2018 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 7B8AC126C3D for ; Tue, 29 May 2018 07:32:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 p6bgFUyI-eZ3 for ; Tue, 29 May 2018 07:32:46 -0700 (PDT) Received: from mail-yb0-x22e.google.com (mail-yb0-x22e.google.com [IPv6:2607:f8b0:4002:c09::22e]) (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 099E3126CF9 for ; Tue, 29 May 2018 07:32:46 -0700 (PDT) Received: by mail-yb0-x22e.google.com with SMTP id l2-v6so5135415ybp.8 for ; Tue, 29 May 2018 07:32:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=1YlX+SKJgKasJq88AaNPX/r1DEtKibCBZEJ0KLhn7To=; b=R9Bm7v03Q/Cfh/gOoxAKJGFqw/CIPB8GBulLfJbnhfdPJl9d3gzTkEZznOadyBkH3w hmOADykXp02dmwTKwUJnaXXrERNnkudduXzGdtaYKukTau6szGFgyqlqYoAxg8nM6GSL WGqV/An0Omh+I37Fo+fkyRK15hKj7Ix5UzMEKlxpc4Jh9AgFTH02zh0gnt6aV449ILcu yWbh3kz0iELLdoa1yHkga1w0RIImljnaA8wqm5yId4RQZ6BMzRUsqbmS/dXBjatOUkr9 aM8fc6cwTteptF3ewRSk1hwqndkr8OlrBPR8lOZhL+ubcQbzc+A7qtESmzEqVpH0EIRg NXzQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=1YlX+SKJgKasJq88AaNPX/r1DEtKibCBZEJ0KLhn7To=; b=VEVtet3Nsy8/7NmR72FwpIB8g7TUnS6ZiCpbZ6oAsIl2ctFMnuz0bbBVN/lE5NrVaE 43Y3rzb8sgxCZJqnPsrHCtmcny8pfOFaI+TK6rOHQokZO0J8Gq23xeqkQLwhH3MGPl0O o1lZMYCl2nck0YtAtiMschBSh61LHsWbGcaNOXiMJv3+3391a+3+vrAoPvV84U2wRI8k 5zPvcyGovWlEzAjt27oZ+X6pjKiNe+Eo6fF/V+qCHVY9wKFKM18nq7hH0GYCnqXvzdxc MyxJ1RupEVYUUPFV6yF0I3s/kHoGGulghooCUDq3wVzbY5N6niehAlIilIE47RxyAw5w bE4w== X-Gm-Message-State: ALKqPwfH56gVD/shn7y0Bjox1GK52RZ8lRgPjp47yPV9Mrertt4yT4Tj JTvVfrmUwSQy1QYVmoIEYVCn/KBRpUUzTZYMdPM= X-Google-Smtp-Source: AB8JxZqqtErybYUbb0Aw9X5HertVF2rRQom9VxZmE8x2L7V4zuMCqS6nRPVRv3pf+kTaO7HW6PUAItyIAMUKbmn6Npc= X-Received: by 2002:a25:b212:: with SMTP id i18-v6mr9766079ybj.471.1527604364961; Tue, 29 May 2018 07:32:44 -0700 (PDT) MIME-Version: 1.0 References: <152538075241.4552.6760702690778529507@ietfa.amsl.com> <370fc7abe18207138498d335bb688a7e@strayalpha.com> <998ae111-dc0d-e128-9d0d-123a61e627c0@nomountain.net> In-Reply-To: <998ae111-dc0d-e128-9d0d-123a61e627c0@nomountain.net> From: Spencer Dawkins at IETF Date: Tue, 29 May 2018 09:32:32 -0500 Message-ID: To: Melinda Shore Cc: architecture-discuss@ietf.org Content-Type: multipart/alternative; boundary="00000000000087eb3b056d591b38" Archived-At: Subject: Re: [arch-d] I-D Action: draft-iab-protocol-maintenance-00.txt X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.22 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, 29 May 2018 14:32:49 -0000 --00000000000087eb3b056d591b38 Content-Type: text/plain; charset="UTF-8" I'm watching this discussion with quiet interest. On one (of many excellent) point(s) ... On Mon, May 28, 2018 at 8:35 PM Melinda Shore wrote: > On 5/27/18 11:46 PM, Martin Thomson wrote: > > I'm not sure about "dumbing down" being bad. If our specifications can't > > be implemented easily, without errors, can't we claim some of the fault? > > I think so. It's been my experience that for general guidance > for implementers tends to be appreciated primarily by the authors > of the guidance, and implementers of IETF protocols will tend not to > root around in IETF documents not directly related to the protocol > spec. So I think that if there's anything productive to be done > here it's probably best written for an IETF audience (esp. for those > people who tend to do document reviews). At this point I think we > have a pretty good handle on what sorts of implementation errors > are made most often, and figuring out how to specify defensively > seems like a worthwhile effort. I'm not sure that revisiting > the Postel rule will, in and of itself, change much. > > That is to say that I can see the value in a document along these > lines, but I think that framing it in terms of revising the > Postel rule will tend not to reach quite the right audience for > fixing known problems, and not incidentally has all sorts of > cultural baggage associated with it that I'm not sure would > be productive to deal with. > This is actually kind of a hot button for me, because it's really tempting when a standards-track protocol specification is going through IESG Evaluation, for ADs to ask, "could this non-normative text about why things are the way they are, etc. be moved to an appendix? Or to an informational draft? Or just kept in the working group's wiki?", and that kind of falls down Melinda's rabbit hole of who will see the guidance they need to see, as it gets further and further from the mechanisms it's explaining. So I think we need to be pretty selective about what background and guidance we provide, but I think we need to provide the most useful guidance we can provide in places where people who need to see it, will see it. But this is more for me to think about. Spencer > Melinda > > -- > Software longa, hardware brevis > > PGP fingerprint: 4F68 2D93 2A17 96F8 20F2 > 34C0 DFB8 9172 9A76 DB8F > > _______________________________________________ > Architecture-discuss mailing list > Architecture-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/architecture-discuss > --00000000000087eb3b056d591b38 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I'm watching this discussion with quiet interest. On o= ne (of many excellent) point(s) ...

On Mon, May 28, 2018 at 8:35 PM Melinda Shore <melinda.shore@nomountain.net> wr= ote:
On 5/27/18 11:46 PM, Martin Th= omson wrote:
> I'm not sure about "dumbing down" being bad.=C2=A0 If ou= r specifications can't
> be implemented easily, without errors, can't we claim some of the = fault?

I think so.=C2=A0 It's been my experience that for general guidance
for implementers tends to be appreciated primarily by the authors
of the guidance, and implementers of IETF protocols will tend not to
root around in IETF documents not directly related to the protocol
spec.=C2=A0 So I think that if there's anything productive to be done here it's probably best written for an IETF audience (esp. for those people who tend to do document reviews).=C2=A0 At this point I think we
have a pretty good handle on what sorts of implementation errors
are made most often, and figuring out how to specify defensively
seems like a worthwhile effort.=C2=A0 I'm not sure that revisiting
the Postel rule will, in and of itself, change much.

That is to say that I can see the value in a document along these
lines, but I think that framing it in terms of revising the
Postel rule will tend not to reach quite the right audience for
fixing known problems, and not incidentally has all sorts of
cultural baggage associated with it that I'm not sure would
be productive to deal with.

This is act= ually kind of a hot button for me, because it's really tempting when a = standards-track protocol specification is going through IESG Evaluation, fo= r ADs to ask, "could this non-normative text about why things are the = way they are, etc. be moved to an appendix? Or to an informational draft? O= r just kept in the working group's wiki?", and that kind of falls = down Melinda's rabbit hole of who will see the guidance they need to se= e, as it gets further and further from the mechanisms it's explaining.<= /div>

So I think we need to be pretty selective about wh= at background and guidance we provide, but I think we need to provide the m= ost useful guidance we can provide in places where people who need to see i= t, will see it.

But this is more for me to think a= bout.=C2=A0

Spencer
=C2=A0
Melinda

--
Software longa, hardware brevis

PGP fingerprint: 4F68 2D93 2A17 96F8 20F2
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A034C0 DFB8 917= 2 9A76 DB8F

_______________________________________________
Architecture-discuss mailing list
Architec= ture-discuss@ietf.org
https://www.ietf.org/mailman/listinfo/arc= hitecture-discuss
--00000000000087eb3b056d591b38--