Subject: Opinions please: draft-sheffer-running-code-01.txt

From: "Adrian Farrel" <[email-masked]>
Date: Sun, 16 Dec 2012 22:25:54 -0000

What do you think? Is this the sort of thing you'd like to look at in the
Routing Area?

Thanks,
Adrian

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> On Behalf Of [email-masked]
> Sent: 16 December 2012 22:20
> To: [email-masked]
> Subject: I-D Action: draft-sheffer-running-code-01.txt
> 
> 
> A New Internet-Draft is available from the on-line Internet-Drafts
directories.
> 
> 
> 	Title           : Improving "Rough Consensus" with Running Code
> 	Author(s)       : Yaron Sheffer
>                           Adrian Farrel
> 	Filename        : draft-sheffer-running-code-01.txt
> 	Pages           : 8
> 	Date            : 2012-12-16
> 
> Abstract:
>    This document describes a simple process that allows authors of
>    Internet-Drafts to record the status of known implementations.  This
>    will allow reviewers and working groups to assign due consideration
>    to documents that have the benefit of running code and potentially
>    reward the documented protocols by treating the documents with
>    implementations preferentially.
> 
>    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.
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-sheffer-running-code
> 
> There's also a htmlized version available at:
> http://tools.ietf.org/html/draft-sheffer-running-code-01
> 
> A diff from the previous version is available at:
> http://www.ietf.org/rfcdiff?url2=draft-sheffer-running-code-01
> 
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> _______________________________________________
> I-D-Announce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

---

From: "Joel M. Halpern" <[email-masked]>
Date: Sun, 16 Dec 2012 18:25:37 -0500

this seems simple and useful.  I would not want to require it.  But it 
seems people do not even realize this would be useful information.  So 
telling them we would like it seems sensible.

Yours,
Joel

On 12/16/2012 5:25 PM, Adrian Farrel wrote:
> routing-discussion mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/routing-discussion
>

---

From: Tony Li <[email-masked]>
Date: Sun, 16 Dec 2012 16:55:10 -0800

+1 

Tony

On Dec 16, 2012, at 3:25 PM, "Joel M. Halpern" <[email-masked]> wrote:

> this seems simple and useful.  I would not want to require it.  But it seems people do not even realize this would be useful information.  So telling them we would like it seems sensible.
> 
> Yours,
> Joel
>

---

From: <[email-masked]>
Date: Mon, 17 Dec 2012 08:20:32 +0000

Looks lightweight and useful.

>    o  Coverage: which parts of the protocol specification are implemented and which versions of the Internet-Draft were implemented.

+1

> Later, the IETF Tools may support this functionality, e.g. by including such a link from the HTMLized draft version, similarly to the IPR link.

+1

IMO, such info would also be useful after RFC publication, e.g. during the deployment phase.

Thanks.
Bruno

>From: [email-masked] [mailto:routing-discussion-
>[email-masked]] On Behalf Of Adrian Farrel
>Sent: Sunday, December 16, 2012 11:26 PM
>To: [email-masked]
>Cc: 'Yaron Sheffer'
>Subject: Opinions please: draft-sheffer-running-code-01.txt
>

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
France Telecom - Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, France Telecom - Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: <[email-masked]>
Date: Mon, 17 Dec 2012 09:05:34 +0000

Hi Yaron,

>From: Yaron Sheffer [mailto:[email-masked]] >Sent: Monday, December 17, 2012 9:53 AM
>
>Hi Bruno,
>
>the information is certainly useful after the RFC had been published.
>But wikis have a tendency to become outdated. Until publication, at
>least the authors are motivated to keep the information current;
>afterwards, I don't know a way to do it.

If we find this information useful and the IETF provides a way to record it:
- implementers/vendors could include this in their process. It's a small cost only one per RFC (when implemented)
- SP could ask this to their vendor (e.g. during a RFP, we assume that the list of RFC implemented is available on the IETF site). At least for RPF process, looks to me this could save time to both vendors and SP.

But I agree that's a second step, after this experiment.

Thanks again for this initiative,
Bruno

>Thanks,
>	Yaron
>
>On 12/17/2012 10:20 AM, [email-masked] wrote:
>>>     o  Coverage: which parts of the protocol specification are implemented
>and which versions of the Internet-Draft were implemented.
>>
>> +1
>>
>>> Later, the IETF Tools may support this functionality, e.g. by including such
>a link from the HTMLized draft version, similarly to the IPR link.
>>
>> +1
>>
>>
>_______________________________________________________________________________
>__________________________________________
>>
>> Ce message et ses pieces jointes peuvent contenir des informations
>confidentielles ou privilegiees et ne doivent donc
>> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu
>ce message par erreur, veuillez le signaler
>> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages
>electroniques etant susceptibles d'alteration,
>> This message and its attachments may contain confidential or privileged
>information that may be protected by law;
>> As emails may be altered, France Telecom - Orange is not liable for messages
>that have been modified, changed or falsified.
>> Thank you.
>>

---

From: Yaron Sheffer <[email-masked]>
Date: Mon, 17 Dec 2012 10:53:08 +0200

Hi Bruno,

Thanks,
	Yaron

---

From: Abdussalam Baryun <[email-masked]>
Date: Mon, 17 Dec 2012 16:21:11 +0100

+1

AB

---

From: Joe Macker <[email-masked]>
Date: Mon, 17 Dec 2012 12:27:37 -0500

+1

Seems simple and good to encourage people to discuss/include this information somewhere.

-joe

---

From: Brian Weis <[email-masked]>
Date: Mon, 17 Dec 2012 10:39:34 -0800

An informal record of implementation claims during the development of the standard could be valuable for a number of purposes, so I support this. The information is less valuable after publication (implementations change but claims in an RFC are static) so I agree with the guidance to remove it before publishing. 

In the context of the information being short-lived and volatile, I don't see the value of discussing licensing in the Implementation Status section.

Thanks,
Brian

---

From: Christian Hopps <[email-masked]>
Date: Tue, 18 Dec 2012 06:47:19 -0500

This seems useful to me.

Thanks,
Chris.

---

From: Toerless Eckert <[email-masked]>
Date: Tue, 18 Dec 2012 05:36:38 -0800

+1

I would definitely like to see focus on tooling the IETF wiki
to track his information. Putting it in the drafts is IMHO just
useful as long as there is no such web tooling. 

-- 
---
Toerless Eckert, [email-masked]
Cisco NSSTG Systems & Technology Architecture
SDN: Let me play with the network, mommy!

---

From: t.petch <[email-masked]>
Date: Mon, 24 Dec 2012 12:28:11 +0000

I think that this I-D is a bad idea but find it hard to articulate why.

The idea that running code matters to the IETF is well known, and you
cannot participate for long in the IETF without becoming aware of it, so
promoting it further seems unnecessary.   I am often amazed by how much
implementation there is early in the life of a draft when major changes
can and do happen; which is a tribute to the power of the idea.

Offering a bribe to encourage running code seems unnecesary.  I often
see WG Chairs solicit information about implementations at adoption, WG
Last Call, advancement to the IESG and so on, mostly with the proviso
that there is no need to make the information public on the list.

I think this last significant.  There are those who are only to glad to
make their implementations known, to get the publicity thereof, and I
suspect that this is the category that most open source implementations
will come under.

My own experience of code comes from large, commercial organisations,
whose existence depends on getting a return on the investment they put
into code development - and, critically, maintenance - which then places
constraints on what can be announced and when.  It seems unlikely that
the erratic, but invariably late, progress of an IETF I-D can help with
when to make that announcement.

It seems then that any formalisation of this matter will promote open
source and its afficionados - I am reminded on the 'DoS attack' on the
IETF main list a while back - at the expense of the commercial
developpers.

Which is enough of a reason for me to think that this is a bad idea.
But as I said, I am more convinced that this is a bad idea than I can
yet articulate.

Tom Petch

----- Original Message -----
From: <[email-masked]>
To: "Yaron Sheffer" <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>
Sent: Monday, December 17, 2012 9:05 AM

> - implementers/vendors could include this in their process. It's a
small cost only one per RFC (when implemented)
> - SP could ask this to their vendor (e.g. during a RFP, we assume that
the list of RFC implemented is available on the IETF site). At least for
RPF process, looks to me this could save time to both vendors and SP.
> >> IMO, such info would also be useful after RFC publication, e.g.
during the
> >deployment phase.
> >> France Telecom - Orange decline toute responsabilite si ce message
a ete
> >altere, deforme ou falsifie. Merci.
> >>
> >> If you have received this email in error, please notify the sender
and delete
> >this message and its attachments.
________________________________________________________________________
_________________________________________________
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez
recu ce message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les
messages electroniques etant susceptibles d'alteration,
> This message and its attachments may contain confidential or
privileged information that may be protected by law;
> As emails may be altered, France Telecom - Orange is not liable for
messages that have been modified, changed or falsified.

---

From: Yaron Sheffer <[email-masked]>
Date: Mon, 24 Dec 2012 14:52:47 +0200

Hi Tom,

We are not offering a bribe to encourage running code, or at most, a 
very small bribe. We merely make it more acceptable to advertise one's 
implementation inside an I-D, which authors could have done anyway.

The draft does not make any distinction between closed source and open 
source implementations. I agree that by the nature of software 
development, it does give some edge to open source. But this was not our 
goal, and IMO it's just a minor side effect.

Many companies develop prototype implementations of protocols before 
getting them into the real product and making an announcement. Such 
early implementations can certainly improve the quality of the protocol, 
by weeding out bugs etc. And I expect at least some authors will find it 
useful to mention that they have an internal, alpha quality 
implementation of protocol X in such cases.

Thanks,
	Yaron

---

From: Abdussalam Baryun <[email-masked]>
Date: Thu, 27 Dec 2012 13:11:29 +0100

Hi,
we can ask why the ID? or why not the ID? the answers will be always to
make IETF more interesting,

> I think that this I-D is a bad idea but find it hard to articulate why.
I agree that many companies will not want that ID, but they have to live
with IETF (the world's Internet organisation),

> But as I said, I am more convinced that this is a bad idea than I can
bad idea documents to some are good ideas to others, so many bad idea
products have customers, but in the world's market only volunteers win and
their work become history if represented with consensus in the world's
organisations.

AB

---

From: Jeffrey Haas <[email-masked]>
Date: Mon, 31 Dec 2012 10:42:07 -0500

> What do you think? Is this the sort of thing you'd like to look at in the

I don't object to seeing an implementation status optional section in the
RFCs.  What I find a more useful idea is that the implementation status
becomes another bit of meta-data tied to the documents in a way that
integrates with the tools.

At a coarse level, being able to click on a link in the tools for a given
document and getting a list of supported implementations is good for early
documents.  However, once we've gotten a significant number of
implementations, such a page becomes noise.  (Admittedly, noise that can be
filtered with smarter tools.  E.g. "Do you support RFC 793?")

Tying into the "What do we do with the next-generation RFCs" thread,
implementation is effectively a form of satisfying requirements and good
RFCs are, often, requirements documents.  Picture a bit of meta-data in the
document that can be used as a checkbox in a tools-managed implementation
report.  It'd mean that as a WG chair, the tools work does much of what I
need for gathering implementation reports.  It'd also mean something a
company can register much of the information required in RFPs.

In summary, I think it's useful meta-data but requires a lot more discussion
tools-wise before it makes sense to adopt longer term.

-- Jeff