ietf
[Top] [All Lists]

Re: Running code, take 2

2012-12-14 05:25:24
----- Original Message -----
From: "Marc Blanchet" <marc(_dot_)blanchet(_at_)viagenie(_dot_)ca>
To: "Loa Andersson" <loa(_at_)pi(_dot_)nu>
Cc: <ietf(_at_)ietf(_dot_)org>
Sent: Thursday, December 13, 2012 3:39 PM
Le 2012-12-13 à 10:22, Loa Andersson a écrit :

Folks,

I agree that understanding the implementation status of a draft
sometimes is essential, but not for all drafts and not always.
Today wg chairs do this type of info collection at the shepherd
write-up.

Have anyone thought about how much work goes into compiling this type
of information. There are vendors that by policy decided not to
disclose
implementation information, before the implementation is done and the
document has become an RFC.

Most of the time it is possible to to get some understanding, with a
promise not to make the info public and only use it for a rather
cryptic statement in the shepherd write-up - "we know of existing or
intended implementations of this draft".

A second, rather new problem, is that for some drafts the IANA
assignment is the singular most important part of the ID. We have
heard
vendors say "We'll wait for the IANA assignment until we implement!"


right. but that does not preclude doing the proposal. What you are
saying is that maybe the info (in draft, wiki, tracker) may not be
complete since some may not disclose. But the available information
would be valuable.

<tp>
And could be very misleading, because it is incomplete and people will
draw unwarranted inferences from the information that has been made
public.  They will likely not understand the nuances of different
implementors having different policies about when to make such details
public, whether for commercial reasons, IPR reasons or whatever.  Nor
may they realise that an I-D is a work in progress, so an implementation
at an early stage may be really bad news if there is a later change to
the technical details (something of which happened with MPLS-TP OAM,
with an ITU-T approach predating an IETF one).

Tom Petch
</tp>
Marc.


/Loa


On 2012-12-13 16:10, Adrian Farrel wrote:
How about...

Start with Yaron's proposal to include in the I-D. This is easy as a
starting
point. Duplicate documentation in wiki may be useful and provide a
place to
track text for inclusion in the next revision.

When/if inclusion in the I-D gets messy, replace text in I-D with
pointer to
wiki.

When/if experiment looks like a success, replace all above with data
tracker
tool and allow it to persist for RFCs.

Adrian

-----Original Message-----
From: Marc Blanchet [mailto:marc(_dot_)blanchet(_at_)viagenie(_dot_)ca]
Sent: 13 December 2012 15:05
To: Yaron Sheffer
Cc: adrian(_at_)olddog(_dot_)co(_dot_)uk; ietf(_at_)ietf(_dot_)org; 
'Alessandro Vesely'
Subject: Re: Running code, take 2


Le 2012-12-13 à 10:00, Yaron Sheffer a écrit :

Hi Marc,

I think it's critical that a person reading a draft (e.g. going to

http://tools.ietf.org/html/draft-blanchet-iab-internetoverport443-01)
will
have a
direct way to check out on the implementation status.

This is trivial if it's a section in the document. It's simple if
it's
linked from the
Tools page. Otherwise, e.g. if you put it on the wiki, only IETF
insiders will
be
aware of it.


sure. Let me restart:
- I like Adrian proposal: instead of in RFC, put it online within
our site
- but you wrote: requires implementation effort.
- I replied: well, phase 1 (of put it online within our site) can be
done with
almost
zero implementation effort. phase 2 requires some work (I'd say not
that big)
for
implementation/tools.

Regards, Marc.

Thanks,
Yaron

On 12/13/2012 04:55 PM, Marc Blanchet wrote:

Le 2012-12-13 à 09:52, Yaron Sheffer a écrit :

Hi Adrian,

I would suggest to start with my proposal, because it requires
zero
implementation effort.

disagree. phase 1: use IETF wiki. phase 2: develop an widget
within data
tracker.

Marc.


If this catches on, I see a lot of value in your proposal.

Please also note that the "implementation status" section
(according to my
proposal) is not "frozen" when published as an RFC, rather it is
deleted. RFCs
are
forever, and I think a point-in-time implementation status is not
appropriate
in an
RFC.

Thanks,
Yaron

On 12/13/2012 04:16 PM, Adrian Farrel wrote:
I'm interested in this idea.

However, I note that an "implementation status" section of a
document is
frozen
in time when a document goes to RFC.

I wonder whether we could leverage our tools and do something
similar to
IPR
disclosures. That is, provide a semi-formal web page where
implementation
details could be recorded and updated. These would then be
searchable
and linked
to from the tools page for the I-D / RFC.

They could record the document version that has been
implemented, and
also allow
space for other notes.

Adrian (Just thinking aloud)

-----Original Message-----
From: ietf-bounces(_at_)ietf(_dot_)org 
[mailto:ietf-bounces(_at_)ietf(_dot_)org] On
Behalf Of
Alessandro Vesely
Sent: 13 December 2012 13:58
To: ietf(_at_)ietf(_dot_)org
Subject: Re: Running code, take 2

On Wed 12/Dec/2012 20:31:04 +0100 Yaron Sheffer wrote:

I have just published a draft that proposes an alternative to
Stephen's "fast track". My proposal simply allows authors to
document,
in a semi-standard way, whatever implementations exist for
their
protocol, as well as their interoperability.

http://www.ietf.org/id/draft-sheffer-running-code-00.txt

[...]

I am looking forward to comments and discussion on this list.

As an occasional I-D reader, I'd appreciate "Implementation
Status"
sections, including IPR info.  I don't think anything forbids
to add
such sections, if the authors wish.  I'd add a count of the
number of
I-Ds that actually have it among the experiment's success
criteria.




--


Loa Andersson                         email:
loa(_dot_)andersson(_at_)ericsson(_dot_)com
Sr Strategy and Standards Manager            loa(_at_)pi(_dot_)nu
Ericsson Inc                          phone: +46 10 717 52 13
                                            +46 767 72 92 13