Re: I'm struggling with 2219 language again
Hector Santos <hsantos@isdg.net> Fri, 04 January 2013 18:37 UTC
Return-Path: <hsantos@isdg.net>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2240321F872D for <ietf@ietfa.amsl.com>; Fri, 4 Jan 2013 10:37:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level:
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0-xK+jTikU3u for <ietf@ietfa.amsl.com>; Fri, 4 Jan 2013 10:37:00 -0800 (PST)
Received: from listserv.winserver.com (news.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id C721721F872C for <ietf@ietf.org>; Fri, 4 Jan 2013 10:36:59 -0800 (PST)
DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=5520; t=1357324614; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=MODMgC2YzKMYZ4mI9ouzhZCEIy0=; b=DuFHwizevHZgYFBAP2GQ UvyUsZ8p4dR5XLGFMDhTgAQs8y7rjIkZJCMbQoFN0Y3Jc9uAj6ljdlCJaVy/zDGy UyVz37wUvEZRgUU1CNAG+eDnoIifYO3UM3OqLUBmUn+E9/qbHg4n2/NIdks7Lv0/ 5TievhKu6b9D+t07hxeMSvU=
Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for ietf@ietf.org; Fri, 04 Jan 2013 13:36:54 -0500
Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com;
Received: from beta.winserver.com ([208.247.131.23]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 461376777.5411.4132; Fri, 04 Jan 2013 13:36:53 -0500
DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=5520; t=1357324568; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=tep9/J3 PgfV+U3osboFv4my82xy7OwlTzG4CD0ZAOWI=; b=Di0EdfVRN4VJI8zTERhmnU/ FwVWc5Qcs58l/h36HTRttx+TYByxKy/7UIjpJGG72Gf7OayRMgnRGWIC4mTwHphk qjFCnwKJx2iK8U+xRKIPEDrnPjyfq/XA1pjr8YEaxddjMrxR2WVCkCYeh49fM8rt 6oPex0VAOhO9DQRDuoFk=
Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for ietf@ietf.org; Fri, 04 Jan 2013 13:36:08 -0500
Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 1060083992.10.7172; Fri, 04 Jan 2013 13:36:07 -0500
Message-ID: <50E72161.1020101@isdg.net>
Date: Fri, 04 Jan 2013 13:37:21 -0500
From: Hector Santos <hsantos@isdg.net>
Organization: Santronics Software, Inc.
User-Agent: Thunderbird 2.0.0.24 (Windows/20100228)
MIME-Version: 1.0
To: Lou Berger <lberger@labn.net>
Subject: Re: I'm struggling with 2219 language again
References: <7ED55FF1-3E1A-4DF7-918E-07790517B848@softarmor.com> <50E6D7CB.6050905@labn.net>
In-Reply-To: <50E6D7CB.6050905@labn.net>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: ietf@ietf.org, Dean Willis <dean.willis@softarmor.com>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 04 Jan 2013 18:37:03 -0000
+1. I think it is important that we have communications tools for documenting strong minimum protocol requirements and we only have RFC2119 to make that possible. Yet, we need to be careful where the lack of RFC2119 upper case wordings can be used to leverage an argument for relaxation of existing protocols where perhaps only lower case semantics were done. IMO, where there are multiple protocol state choices or paths and where common sense engineering and security functionality is clear, upper vs lower should not matter. I will like to use an example protocol logic I am currently concern with that could be altered due to 2119 related debates: For protocol state condition A, you may do action B or C. If action B is taken, you MUST do D. So action B has 2119 language to do D. Part of the 2219 debate is that doing action B or C are both optional. C is not defined, although it could be said it was implied via other indirect protocol features: You SHOULD do E. and in a protocol change proposal, it is now: You SHOULD do E1 instead of E. Well, to do E or E1, you have to do C, not B. Now the history of this is that original drafts/specs (ones some folks want us to ignore) did have 2119 language on whether you MAY do B or C, and in fact in an extended augmented RFC protocol, it only allowed for a MUST action B for protocol condition A. C was not an option (or at least it wasn't stated) in the extended RFC technology. The problem was the lack of an upper case MAY has provided the notion that none of this is normative thus making the action C more possible and action B less attractive. By making C more possible, this makes E more plausible and now that E1 is a new recommendation and preferred feature than E, the idea of doing action B is now watered down. The issue is sensitive and honestly, it got to a point where one says "Who cares!?" If they want to watered down B, so be it. You don't need to support it protocol changes nor the newer push to the E1 recommendation. The problem for me? Is why is the security aspects of this do not make it obvious of what needs to be done? We got into anal debate of 2119 language and I even recall a few years ago where another debate of the definition of SHOULD got a number of people labeled as 2219 illiterates by an AD. In the example I cited, politics comes into play because you have two industry mindsets under protocol condition A: 1) Those that believe in action B as the more secured action, and 2) Those that DO NOT believe in action B and prefer C. There is where a person like myself is left with the idea of waiting for WGLC to appeal changes to the protocol that will watered down action B. This is all due because of the lack of 2119 language that many believe were naturally in place with just using lower case wordings. No upper case, therefore action B is weak and that was unfair to current implementations that only do action B as its the most secured implementation (and less costly) action to protect users. By allowing RFC2119 or stated arguments the protocol lacked 2119 language, weakens the protocol and makes it more complex for implementations to consider action C which can be more harmful if certain forms of C making it functionality equivalent (security wise) to action B is not done (this is the added complexity). I'm sure this is a dime a dozen story, but to me it is common to see WG chairs, AD and other key cogs throw the proverbial 2119 book at developers to help push specs. IMO, we need it but we also need some common sense engineering and consideration to be done when we review current docs. Ignoring existing implementations SHOULD not be one of them. -- HLS Lou Berger wrote: > > On 1/4/2013 12:15 AM, Dean Willis wrote: > ... >> Are we deliberately evolving our language to use RFC 2119 terms as >> the principle verbs of a formal specification language? > ... > > My view on this has evolved over time. I used to follow the practice of > using 2219 language only for emphasis. Over time, primarily motivated > by reviewers comments and reader questions, I've migrated to the > position that 2119 language should be used whenever and wherever a point > of conformance is being made. While this may be a bit of an extreme > position, it ensures that authors, reviewers, readers, implementors, > etc. are in sync as to what is expected from an interoperable > implementation that conforms to a standard. I think the importance of > such unambiguity has increased over time as the number of implementors > and non-native English speakers in our community have increased. > > I also think it's important to follow section 6 of 2119, i.e., if it's > not a point of interoperability or harmful behavior, there's no need to > use 2119 conformance language. > > So, my view is now: > > a) lower case usage of 2119 key words *in RFCs* means the normal English > meaning of such words, but does not place any requirement on > implementations, i.e., is purely informative text. > > b) upper case usage of 2119 key words *in RFCs*, as stated in [RFC2119], > places "requirements in the specification", i.e., is conformance > language with which an implementation must follow to ensure > interoperability (or harm). (And does not = shouting as would be the > case in other contexts). > > I take this view when writing and reviewing PS drafts... > > Lou > >
- I'm struggling with 2219 language again Dean Willis
- Re: I'm struggling with 2219 language again Brian E Carpenter
- Re: I'm struggling with 2219 language again Dave Cridland
- Re: I'm struggling with 2219 language again Lou Berger
- Re: I'm struggling with 2219 language again Bob Braden
- Re: I'm struggling with 2219 language again Scott Brim
- Re: I'm struggling with 2219 language again Peter Saint-Andre
- Re: I'm struggling with 2219 language again Hector Santos
- Re: I'm struggling with 2219 language again Richard Barnes
- RE: I'm struggling with 2219 language again Adrian Farrel
- Re: I'm struggling with 2219 language again Ben Campbell
- Re: I'm struggling with 2219 language again Thomas Narten
- Re: I'm struggling with 2219 language again Mark Nottingham
- Re: I'm struggling with 2219 language again ned+ietf
- Re: I'm struggling with 2219 language again Hector Santos
- A proposal for a scientific approach to this ques… Marc Petit-Huguenin
- Re: I'm struggling with 2219 language again Pete Resnick
- Re: I'm struggling with 2219 language again ned+ietf
- Re: I'm struggling with 2219 language again Dean Willis
- Re: I'm struggling with 2219 language again Riccardo Bernardini
- Re: I'm struggling with 2219 language again Scott Brim
- Re: I'm struggling with 2219 language again Marc Petit-Huguenin
- Re: I'm struggling with 2219 language again C. M. Heard
- Compliance to a protocol description? (wasRE: I'm… Robin Uyeshiro
- Re: I'm struggling with 2219 language again John Levine
- Re: I'm struggling with 2219 language again John Day
- Re: A proposal for a scientific approach to this … John Day
- Re: A proposal for a scientific approach to this … Dick Franks
- Re: A proposal for a scientific approach to this … John Day
- Re: A proposal for a scientific approach to this … Donald Eastlake
- Re: A proposal for a scientific approach to this … Martin Rex
- Re: A proposal for a scientific approach to this … Marc Petit-Huguenin
- Re: A proposal for a scientific approach to this … John Day
- Re: A proposal for a scientific approach to this … Dick Franks
- Re: A proposal for a scientific approach to this … John Day
- Re: A proposal for a scientific approach to this … Martin Rex
- Re: A proposal for a scientific approach to this … Martin Rex
- Re: A proposal for a scientific approach to this … Hector Santos