Re: draft-bradner-rfc-extracts-00.txt

On Thu, 2005-02-10 at 19:18, Scott Bradner wrote:
> I've just published draft-bradner-rfc-extracts-00.txt 

there are many sorts of reasons to change a code extract, creating
a derivative work, which have no impact on standards or interoperability.

I seem to recall at least one incident involving allegedly uncompilable 
MIBs found in IETF documents.  If i'm not in a position to fix my mib 
compiler I may still be able to fix the source to cause my implementation
to produce the correct behavior...

I have this vague memory of running into an ASN.1-driven code generator
which allowed you to mix code fragments with ASN.1 (much as parser 
generators such as yacc let you mix code fragments with a grammar 
description).  I'd imagine that you could do the same with a MIB as well.

On several occasions I've extracted the MD5 code from RFC1321 and made 
it run faster while still computing the same function.

Other things I'd like to be able to do:

 - code changes to make RFC-derived code pass various static or dynamic 
checkers (lint, purify, gcc -Wall, ...)

 - changes to make it match local conventions for indentation, identifier 
naming, header file naming, etc.,

 - changes to eliminate global variables, add locking for multithread 
safety, or allow for localized messages.

 - Translations into other programming languages or to cope with the
evolution of the programming language (e.g., the K&R C to standard C 
transition).

in -rfc-extracts you wrote: "I do not see that the open source community
requires the ability to create a modified and incompatible version of 
ATM signaling".

Hmm.  What about RFC1953/1954/1987?  The way it's worded makes me think
it's not cleanly layered atop ATM but rather involves discarding and 
replacing some of the upper layers of ATM...

						- Bill

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