Re: Sample code (was: Fwd: DISCUSS: draft-ietf-rmt-bb-fec-ldpc)

["Tom Petch" <nwnetworks at dial.pipex.com>]

My apologies, I should have been paying closer attention.

What was the conclusion about code in a non-normative appendix?

I am looking at
 draft-ietf-ipfix-info-15
which is in the RFC Editor's Queue, so everyone is happy with it:-)  It has code
in a non-normative appendix, the text generated from it being normative.  It is
a (sort of) 'MIB Module' defining objects in XML, which will obviously be
extracted and used in various processors.  Unlike a MIB Module, there is no
RFC4181 statement in the XML module, no IP statement at all.

Does this appendix still have the same IP rights and releases that code in a
normative part of the document, eg a MIB module, would have?  As far as I can
tell, the whole document is the contribution of the same set of authors,
although a non author turned the XML into the text.

Tom Petch


----- Original Message -----
From: "Frank Ellermann" <nobody at xyzzy.claranet.de>
To: <ipr-wg at ietf.org>
Sent: Saturday, December 01, 2007 6:27 PM
Subject: Sample code (was: Fwd: DISCUSS: draft-ietf-rmt-bb-fec-ldpc)


Harald Alvestrand wrote:

> I think the WG has concluded that it's unacceptable to publish source
> code in an RFC that, if copied from the RFC and modified by a reader,
> would place a GPL (or any other copyright-based) requirement on that
> reader.

Sounds familiar...

> And I think that's a sensible conclusion to come to.

...but the outcome is horrible, as explained by Simon.  It's possible
to use sample code for educational purposes, and then create your own
version, if that's an issue.  In the case of APR1 (some MD5 password
madness) the "beerware" license is actually live-threatening for the
original author, therefore I didn't copy it to a REXX MD5 test suite.

And I checked it with three other implementations (because I couldn't
believe it).  I'd add credits in an Internet Draft, but I'd likely
add my own code as sample, without mentioning the "beerware" license.

[ Don't panic, the SASL WG is supposed to propose a better mechanism,
 if they end up with documenting APR1 something went seriously wrong ]

Likewise the sample code in the lottery RFC (NOMCOM) is essential to
"deploy" it at all.  Simon's B64 RFC really needed sample code, the
valid test vectors are nice, but sometimes folks create "truncated"
(at first glance ambiguous) B64 encodings, and implementors might
have a hard time to reverse engineer a better fallback than "throw
error and give up".  IIRC two of three serious bugs in the mentioned
MD5 test suite were B64 issues :-(

 Frank


_______________________________________________
Ipr-wg mailing list
Ipr-wg at ietf.org
https://www1.ietf.org/mailman/listinfo/ipr-wg


_______________________________________________
Ipr-wg mailing list
Ipr-wg at ietf.org
https://www1.ietf.org/mailman/listinfo/ipr-wg