Re: Protocol Definition

Alessandro Vesely <vesely@tana.it> Tue, 19 June 2012 11:20 UTC

Return-Path: <vesely@tana.it>
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 6EC5B21F85E5 for <ietf@ietfa.amsl.com>; Tue, 19 Jun 2012 04:20:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.418
X-Spam-Level:
X-Spam-Status: No, score=-4.418 tagged_above=-999 required=5 tests=[AWL=0.301, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0ja2Bx7j3uLa for <ietf@ietfa.amsl.com>; Tue, 19 Jun 2012 04:20:01 -0700 (PDT)
Received: from wmail.tana.it (mail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 6C07C21F85C9 for <ietf@ietf.org>; Tue, 19 Jun 2012 04:20:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1340104798; bh=vy59P97R1EhWcCX+PEZoW91AKKdr1emHrMw8UmbfP6c=; l=3388; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=lDU1r02vb4FpILlEGUzabffDdCXBZFyVGPAmkWDl0ag5qHxkSVYN54asHhP3AJyr0 pHnkp2nPIbHa7DAegvCK8YFr61IxSJSKKIQYXDzNnk3oRgnycCHlDqWOF2iuX03Cjh RgdQZbBVIFyNqqiVHZ9RPa6UqeDAMO1G+opuyLLQ=
Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 515, TLS: TLS1.0,256bits,RSA_AES_256_CBC_SHA1) by wmail.tana.it with ESMTPSA; Tue, 19 Jun 2012 13:19:58 +0200 id 00000000005DC035.000000004FE0605E.00001E40
Message-ID: <4FE0605E.50004@tana.it>
Date: Tue, 19 Jun 2012 13:19:58 +0200
From: Alessandro Vesely <vesely@tana.it>
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:13.0) Gecko/20120614 Thunderbird/13.0.1
MIME-Version: 1.0
To: ietf@ietf.org
Subject: Re: Protocol Definition
References: <4FDF0362.3050101@tana.it> <4FDFAF49.7070708@isi.edu>
In-Reply-To: <4FDFAF49.7070708@isi.edu>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
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: Tue, 19 Jun 2012 11:20:02 -0000

On Tue 19/Jun/2012 00:44:25 +0200 Joe Touch wrote:
> On 6/18/2012 3:30 AM, Alessandro Vesely wrote:
> ...
>> one can give a full description (or coding) of, say, sqrt, without
>> actually saying that the square of the result will match its argument
>> up to some rounding error.  The specification does not have to relate
>> the underlying mathematical abstraction.
> 
> This is the difference between a behavioral description and a
> procedural description.
> 
> Behavioral treats a system as a "black box", and defines the system as
> a function and how it transforms its input into its output.
> 
> Procedural specifies the particular steps taken inside the box.
> 
> Procedural is more specific than behavioral:
> 
>     behavioral = any of a number of ways of calculating SQRT
>     procedural = one specific algorithm for calculating SQRT
> 
> Semantics is a completely different thing - the assignment of
> "meaning" to symbols. Neither procedural nor behavioral descriptions
> need to include semantic descriptions.

We agree that including semantic descriptions is optional.  But what
is better?  For SQRT, I'd hold that a short, crispy reference to the
theoretical background may be useful and wouldn't harm.  For the
general case, I'm not sure.

>> Protocol specifications, especially when dealing with policies, do not
>> have to describe the exact meaning of the relevant tokens.  To do that
>> would often look like mandating a state or a reaction, neither of
>> which is needed to ensure interoperability.
> 
> In a protocol, state transitions and response messages are specified.

When they're part of the protocol proper, they are specified indeed.
Policy tweaks, however, live in some limbo.  For example, recursion
for DNS, access restrictions for HTTP, ADSP for SMTP.  Specifications
can hardly discuss such topics.  If they do, they get criticized for
interfering with deployment.  In addition, as policies typically
involve subjective considerations, it is quite rare to gather rough
consensus on any specific advice about them.

> Protocols are typically described procedurally, FWIW.

Yes.  And quite often a procedural description is the most accurate
way to reverse engineer the actual meaning of a message.  Policies
don't enjoy such practice.

>> In fact, the protocol just has to ensure that a policy can be
>> transmitted correctly.  Many would rather leave a policy token
>> underspecified than get involved in its details.
> 
> This is like claiming that a protocol is just "bits on the wire",
> and it is not accurate.

Well, it is not accurate to assume full knowledge about the policies
and their consequences.  Let me try and express that better below.

> Conduct, intention, and semantics refer to human interpretations of
> events. Unless a human is part of your protocol stack, they're not
> relevant.
> 
> I agree with AB - these issues aren't relevant to IETF descriptions of
> protocols.

Besides development, humans typically configure some implementations
of one or more protocols.  That is what makes protocols run, so it has
to be relevant to us.  Hostmasters who carry out that task are skilled
staff.  However, they have to infer the exact meaning of a policy
token by the wording of its definition and/or by trial and error,
neither of which seems to be formally adequate to me.  What am I missing?