Subject: Re: [spfbis] #11: RFC 4408 Section 4 check_host() function

From: S Moonesamy <[email-masked]>
Date: Fri, 23 Mar 2012 01:59:20 -0700

At 03:44 08-02-2012, spfbis issue tracker wrote:
>#11: RFC 4408 Section 4 check_host() function
>
>  Message from Murray Kucherawy on 7 Feb 2012:
>
>  The use of a "check_host()" in a standards track RFC smacks of us defining
>  an API, which I think the IETF tries to avoid.  (The greybeards in here
>  can correct me if I'm wrong.)  After staring at the RFC4408 text for a
>  while, it seems to me it could be rewritten to avoid this construct
>  without losing any detail.
>
>  I realize that's a little bit hypocritical coming from one of the co-
>  editors of RFC6376, which defined a set of inputs, some outputs (one
>  required, others optional), and some end states, but RFC4408 is a lot more
>  blatant about it, for example by going so far as naming the function;
>  somehow in my head it crosses a line that RFC6376 avoided.  I think it
>  comes down to the difference between specifying a function and describing
>  an algorithm.
>
>  http://www.ietf.org/mail-archive/web/spfbis/current/msg00359.html

[snip]

>Ticket URL: <http://trac.tools.ietf.org/wg/spfbis/trac/ticket/11>

Please comment on Issue #11.  I am opening it so 
that it can also be discussed during the IETF meeting.

Regards,
S. Moonesamy
SPFBIS WG co-chair

---

From: Scott Kitterman <[email-masked]>
Date: Fri, 23 Mar 2012 05:39:06 -0400

On Friday, March 23, 2012 01:59:20 AM S Moonesamy wrote:
> >  The use of a "check_host()" in a standards track RFC smacks of us
> >  defining an API, which I think the IETF tries to avoid.  (The
> >  greybeards in here can correct me if I'm wrong.)  After staring at
> >  the RFC4408 text for a while, it seems to me it could be rewritten to
> >  avoid this construct without losing any detail.
> >  
> >  required, others optional), and some end states, but RFC4408 is a lot
> >  more blatant about it, for example by going so far as naming the
> >  function; somehow in my head it crosses a line that RFC6376 avoided. 
> >  I think it comes down to the difference between specifying a function
> >  and describing an algorithm.
> >  

-1 on this proposal.

Maintaining backwards compatiblity is a very high priority in the charter.  
When we re-write text, and particularly re-writing entire sections, we risk 
introdcuing inadvertent functional changes.  We don't have the benefit of 
assuming future readers of 4408bis will know we meant to be compatible with 
4408 and understand from that intent how to interpret new text.

The best way to maintain backward compatibility is not to change things.  For 
an issue like this, where there's no technical issue, just a stylist one, 
taking the risk of inadvertently changing some aspect of the technical 
functionality is not worth whatever modest benefit might be associated with a 
different style of writing the document.

Scott K

---

From: Alessandro Vesely <[email-masked]>
Date: Fri, 23 Mar 2012 11:03:31 +0100

On 23/Mar/12 10:39, Scott Kitterman wrote:
>>> RFC4408 is a lot more blatant about it, for example by going so
>>> far as naming the function; somehow in my head it crosses a
>>> line that RFC6376 avoided. I think it comes down to the
>>> difference between specifying a function and describing an
>>> algorithm.
>> 
>> Please comment on Issue #11.  I am opening it so that it can also
>> be discussed during the IETF meeting.
> 
> -1 on this proposal.
> 
> Maintaining backwards compatiblity is a very high priority in the
> charter. When we re-write text, and particularly re-writing entire
> sections, we risk introdcuing inadvertent functional changes.  We
> don't have the benefit of assuming future readers of 4408bis will
> know we meant to be compatible with 4408 and understand from that
> intent how to interpret new text.
> 
> The best way to maintain backward compatibility is not to change
> things.  For an issue like this, where there's no technical issue,
> just a stylist one, taking the risk of inadvertently changing some
> aspect of the technical functionality is not worth whatever modest
> benefit might be associated with a different style of writing the
> document.

Although I basically agree with Scott, it could be added (e.g. in
Section 1.2) that the function name being used is not an API entry
point and that such terminology is used for clarity and historical
reasons only.

---

From: Scott Kitterman <[email-masked]>
Date: Fri, 23 Mar 2012 08:31:33 -0400

> point and that such terminology is used for clarity and historical

I think something like this is reasonable.

Scott K

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 23 Mar 2012 17:20:22 +0000

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Scott Kitterman
> Sent: Friday, March 23, 2012 5:32 AM
> To: [email-masked]
> Subject: Re: [spfbis] #11: RFC 4408 Section 4 check_host() function
> 

By the same token, I don't agree that the change I'm proposing makes any threat to backward compatibility.  The algorithm itself is certainly unchanged; it's the presentation of the algorithm in the form of a (loose) API definition that I think we should avoid.

We went through a similar exercise with the promotion of DKIM to Draft Standard and it was successful, so I'm looking to provide SPF with the benefits.

> > > benefit might be associated with a different style of writing the

I think it's more than a stylistic point.  For Experimental documents the bar is pretty low in terms of what gets through to publication, but for Standards Track documents the evaluation is more rigorous.  In that sense, the "We shouldn't specify APIs" mantra that pops its head up now and then in the IETF is more likely to strike us this time around.  We need to be careful to avoid it or we'll be forced to deal with it at a less convenient point in the document's evolution.

> I think something like this is reasonable.

Adding text to say the "check_host()" thing is an illustration point only and not an API definition is probably a reasonable compromise.  We could ask our ADs to be sure.

-MSK

---

From: S Moonesamy <[email-masked]>
Date: Tue, 27 Mar 2012 05:45:37 -0700

This is a quick summary of Issue #11.  The issue is based on a 
message posted on February 7 [1].

Scott Kitterman mentioned that maintaining backwards compatiblity is 
a very high priority in the charter [2].  When we re-write text, and 
particularly re-writing entire sections, there is a risk of 
inadvertent functional changes.  He is of the view that it is a 
stylistic issue.  Alessandro Vesely agreed [3].  He also suggested 
adding text (e.g. in Section 1.2) that the function name being used 
is not an API entry point and that such terminology is used for 
clarity and historical reasons only, to which Scott Kitterman agreed.

Murray Kucherawy did not agree that the change threatens backward 
compatibility.  He thinks that it is more than a stylistic point [4] 
and mentioned that adding text to say the "check_host()" thing is an 
illustration point only and not an API definition is probably a 
reasonable compromise.

Regards,
S. Moonesamy

1. http://www.ietf.org/mail-archive/web/spfbis/current/msg00359.html
2. http://www.ietf.org/mail-archive/web/spfbis/current/msg00968.html
3. http://www.ietf.org/mail-archive/web/spfbis/current/msg00970.html
4. http://www.ietf.org/mail-archive/web/spfbis/current/msg00976.html