Re: [Tools-discuss] Last Call: <draft-sheffer-running-code-04.txt> (Improving Awareness of Running Code: the Implementation Status Section) to Experimental RFC

[Dave Crocker <[e-mail]>]

On 4/28/2013 8:03 AM, Yaron Sheffer wrote:
> Hi Dave,
>
> Thank you for your thorough review. While I accept many of your
> comments, I must say I disagree with you on a few points, which together
> go to the core of our motivation in writing this document. Thank you for
> helping me clarify these points to myself :-)
>
> - Our goal is much *less* ambitious than defining a framework for
> documenting implementations for long-term protocol projects. Our primary
> goal is to aid working group members in making informed decisions about
> the quality of specifications.

Forgive me, but working group members seem like the /least/ interesting 
target audience, since it is already the most-informed group, by virtue 
of its direct activity over the course of developing the specification.

The people who are most likely to benefit from pointers to 
implementation details are:

    1.  Reviewers, who want a sense of implementation history to 
'season' their analysis;

    2.  IESG members, who are deciding whether to vote approval for the 
specification; and

    3.  Those considering adoption of the technology for use, such as 
other implementers and service operators.

That said, what you propose certainly accommodates #1 and #2, without 
needing to agree on their being a target audience...

[However the small discussion, farther down, about being better able to 
evaluate competing proposals, does provide an example of benefit 
/within/ the working group...]



> - As a result of the above: 1. We define the information as pre-RFC
> only; 2. The main medium is the I-D, as opposed to Web pages/wikis/CMS
> (although we see them as valid alternatives); 3. We focus on WG
> documents, as opposed to "all" IETF documents.

Right.  And here my suggestions were merely to clarify this earlier in 
the proposal document.


> - Despite the glowing counterexample of DKIM, it is rarely practical to
> maintain implementation status information, keeping it current for years
> (put bluntly, you need to pay someone to do that).

Would that I'd been getting paid...  But yeah,it  takes continuing 
effort.  (On the other hand, there isn't much on-going work, after 
initial bursts of development activity.)

At any rate, rather than insisting that the list be external and 
on-going, my intention was to suggest designing it to comfortably 
/allow/ the wg to make the choice of either, gracefully, including an 
easy transition from one to the other.

  - - - - -

>>> existence of running code.  It is up to the individual working
>>> groups to use this information as they see fit, but one result might
>>> be the preferential treatment of documents resulting in them being
>>> processed more rapidly.
>>
>> I think it won't be the working group that 'uses' the information, but
>> rather IETF management and the broader community?
>>
>
> For most documents, AFAIK, most work is done by the WG, and a lot less
> by the rest of the community. Hence the above.

IETF Working groups do not create market demand and do not do develop or 
deployment.  All of that is quite explicitly outside the scope of the 
IETF, and at industry-scale, they represent more aggregate effort than 
is put in by the IETF working group...



>>> The scope of the intended experiment is all Internet-Drafts whether
>>
>> Probably not all I-Ds, since they do not all contain implementable
>> specifications.
>>
>>
>>>
>>>
>>> Sheffer & Farrel        Expires October 14, 2013                [Page
>>> 3]  Internet-Draft                Running Code
>>> April 2013
>>>
>>>
>>> produced within IETF working groups, outside working groups but
>>
>> What I-Ds are produced by "outside working groups"?  I can't tell who
>> this refers to.It's probably just as well to remove the attempted case
>> analysis for groups and just say that the scope is all specifications
>> issued as I-Ds.
>
> In fact others have commented that we should exclude individual
> submissions for process reasons.

Right.  That suggests writing the scoping text a bit more tightly.


>>> o  Participants are motivated to implement protocol proposals, which
>>> helps in discovering protocol flaws at an early stage.
>>
>> The psychological premise seems to be that getting cited in this list
>> will somehow serve as an incentive to implementers. I can imagine that
>> they'll like being listed, but find it extremely difficult to believe
>> that it will affect whether they do the work; not that I think it's a
>> deciding factor, but note that the ego value is further reduced by the
>> information's being ephemeral, since it it removed prior to RFC
>> publication!
>
> Actually not (subtly so). The premise is making this information public
> and an explicit part of WG deliberations will incentivize
> implementations (i.e. not the ego factor at all).

The statements you are making about "incentives" to implementers really 
are in terms of their ego, since you have not stated any other benefit 
that will accrue to /them/.  There will be benefits to the community at 
large, but the question in this section of text is what the motivation 
of the implementer will be.



>>> o  Working group chairs and ADs may use the information provided to
>>> help prioritize the progress of I-Ds in some way.
>>
>> What does "prioritize the progress" mean?
>
> When there are multiple competing proposals to solve some problem.

I think you are trying to say something like:

    By having early implementation examples for competing proposals, the 
working group can better evaluate choices among them.



d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net