Hi Fred,
Thanks for your review. Responding to you, and to other similar comments
on the list:
The draft refers to two "styles" of documenting implementation: in-line
in the Internet draft, and by a reference to (presumably) a database or
a wiki. The draft is also quite clear that the Implementation Status
section should be removed from the I-D before publication. We do not
specify what happens with Implementation wikis that are referenced by
the I-D, presumably in most cases they will be abandoned.
The in-line style is obviously simpler to set up (no infrastructure is
needed) and in fact, this was the path taken by the 4 I-Ds that are
using this option to date.
There are two problems with long-term maintenance of implementation data:
- The technical infrastructure (wiki, registration, etc.) should be set
up. This is not too difficult, and there are lots of people who'd be
happy to implement such a thing.
- There should be long-term commitment to maintain the data. I think we
simply don't have such processes in place, and personally I don't want
to even try to deal with this problem. I suspect that we'd have to
eventually use paid help if we are serious about keeping the information
current, and I don't even think it would be worth the cost.
Thanks,
Yaron
On 2013-04-26 01:09, Fred Baker wrote:
On Apr 12, 2013, at 2:57 PM, The IESG <iesg-secretary(_at_)ietf(_dot_)org>
wrote:
Abstract
This document describes a simple process that allows authors of
Internet-Drafts to record the status of known implementations by
including an Implementation Status section. This will allow
reviewers and working groups to assign due consideration to documents
that have the benefit of running code, by considering the running
code as evidence of valuable experimentation and feedback that has
made the implemented protocols more mature.
The process in this document is offered as an experiment. Authors of
Internet-Drafts are encouraged to consider using the process for
their documents, and working groups are invited to think about
applying the process to all of their protocol specifications. The
authors of this document intend to collate experiences with this
experiment and to report them to the community.
I have read the draft. I like the concept. It applies primarily to protocols
and procedures, as opposed to white papers. It, however, puts emphasis on the
experience behind the usefulness of a protocol or procedure, which is good.
BTW, once upon a time we required implementation reports for routing protocols,
which I thought was a good thing and am concerned about the loss of in recent
times. That resulted in the publication of sets like RFCs 1245, 1246, and 1247,
which told about the protocol, its operational characteristics, and the testing
it went through (and by implication, the implementations done of it) on its way
to RFC-dom.
In 2013, I personally would accomplish this a little differently, however. A
section in an internet draft, which gets frozen when the draft is published, is
perhaps useful for the working group and IESG review processes. On the other
hand, it requires implementers to communicate with the draft author and the
draft author to update the draft in response to their input, which can be a
logistical mess. It ceases being useful once the draft is published. If a new
implementation is done, there is no report. If and old one is abandoned, nobody
knows. It is dated information, potentially true at a point in time but largely
irrelevant two minutes later.
I would think we want something associated with the data tracker page - another web page, perhaps
implemented as a wiki - that enables an implementer to identify himself and indicate the current
status of the implementation. Ideally, that might be coupled with a ticket system in which issues
are raised and closed, and comments are discussed. Ideally, this would continue into the life of an
RFC, with implementations being identified ("The protocol in RFC 12345 is implemented in Andy
Systems releases 22.70 and later") and associated with errata ("but we really wish that
the parameter FOO had been specified").
_______________________________________________
Tools-discuss mailing list
Tools-discuss(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/tools-discuss