Subject: RE: Ipr-wg digest, Vol 1 #103 - 22 msgs

From: [email-masked]
Date: Thu, 20 Feb 2003 12:30:19 -0000

"The problem with RAND is that it doesn't work for open source
	implementors.  Look at the way the IETF has gotten multiple
	interoperating implementations in the past: they've all been open
	source implementations.  Every major protocol has been implemented
in
	the open source world.  Allowing RAND breaks that history."

The conclusion here isn't logical.  To summarise the premises of the
apparent argument:

RAND doesn't work for open source implementors;
In the past ALL IETF multiple interoperating implementations have been open
source;
Every major protocol has been implemented in the open source world.

Therefore IETF can't ( always ) be using RAND, can it ?  How does this prove
that something is broken ?

	Regards,

	Graham Travers

	International Standards Manager
	BTexact Technologies

	e-mail:   [email-masked]
	tel:          +44(0) 1359 235086
	mobile:  +44(0) 7808 502536
	fax:          +44(0) 1359 235087

	HWB279, PO Box 200,London, N18 1ZF, UK

	BTexact Technologies is a trademark of British Telecommunications
plc
	Registered office: 81 Newgate Street London EC1A 7AJ
	Registered in England no. 1800000

	This electronic message contains information from British
Telecommunications plc which may be privileged or confidential. The
information is intended to be for the use of the individual(s) or entity
named above. If you are not the intended recipient be aware that any
disclosure, copying, distribution or use of the contents of this information
is prohibited. If you have received this electronic message in error, please
notify us by telephone or email (to the numbers or address above)
immediately.

_______________________________________________
Ipr-wg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ipr-wg

---

From: Russell Nelson <[email-masked]>
Date: Thu, 20 Feb 2003 10:13:08 -0500

> that something is broken ?

Keith Moore has pointed out that RF is the usual practice.  Why not
make it the standard practice?  As a general rule, the IETF doesn't
create practice, it blesses practice.  Okay, so let's bless the
practice of requiring RF or IPR-free standards.

Scott says that requiring RF doesn't make sense when the standard
requires expensive hardware.  To that I say "so what?"  That doesn't
rule out open source implementations.  Look at GNU Radio.  Open Source
software that requires a $1000 DSP card.

Brian has said that we're trying to solve a non-problem, and besides
which, the proposed method won't work anyway.  I guess ... that we're
thinking that the IETF solution isn't going to work in the future, and
that the best way to deal with that is by establishing a policy now.

-- 
-russ nelson              http://russnelson.com | A government does enough
Crynwr sells support for free software  | PGPok | wrong to offset what it
521 Pleasant Valley Rd. | +1 315 268 1925 voice | does right.  Better that
Potsdam, NY 13676-3213  | +1 315 268 9201 FAX   | it should do less.
_______________________________________________
Ipr-wg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ipr-wg

---

From: Keith Moore <[email-masked]>
Date: Thu, 20 Feb 2003 10:18:48 -0500

> make it the standard practice? 

reasons have been given already.  have you read them?

> As a general rule, the IETF doesn't
> create practice, it blesses practice. 

yet another widespread misconception.

> that the best way to deal with that is by establishing a policy now.

what you fail to recognize is that you're not saying anything new.
the current policy resulted from a careful consideration of these issues.
there is no reason to change it.

Keith

---

From: Keith Moore <[email-masked]>
Date: Thu, 20 Feb 2003 10:47:27 -0500

> Feel free to point me to TFM.

you're making a generalization about IETF practice.  you need only to look
at the actual practice to find numerous counterexamples.

> Excuse me, Keith, but I just said "Brian has said that we're trying to
> solve a non-problem."  That sounds to ME like a recognition.  What
> does it sound like to YOU?

depends on what you define as the problem.   we certainly recognize that
IPR is an impediment to having the Internet work well.  we have a policy that
we believe deals with that problem in a fairly optimal way given the
conditions forced upon us by IPR law. the policy that you seem to be
advocating has been considered before and rejected as considerably worse than
what was adopted.

the non-problem that Brian referred to is the one of IETF approving standards
that use encumbered technology.  IETF essentially never does this in such a
way as to harm interoperability with open source software. 

Keith

---

From: Russell Nelson <[email-masked]>
Date: Thu, 20 Feb 2003 11:11:57 -0500

> at the actual practice to find numerous counterexamples.

Like what?  RFC2822?  That just blesses the community's interpretation
of RFC822.  Or zeroconf?  That just blesses Apple's implementation in
Jaguar.  Or SLIP?  Romkey just wrote down what everybody knew.  PPP,
on the other hand, was created de novo.  The IETF requires multiple
interoperating implementations before something is standardized.
Isn't THAT blessing practice?  Feel free to cite these numerous
counterexamples to my experience.

 > depends on what you define as the problem.  we certainly recognize
 > that IPR is an impediment to having the Internet work well.  we
 > have a policy that we believe deals with that problem in a fairly
 > optimal way given the conditions forced upon us by IPR law. the
 > policy that you seem to be advocating has been considered before
 > and rejected as considerably worse than what was adopted.

I agree that it's pointless to rehash something if the facts of the
matter don't change.  Where was this considered before, and how might
I read the archives of the discussion?

 > the non-problem that Brian referred to is the one of IETF approving
 > standards that use encumbered technology.  IETF essentially never
 > does this in such a way as to harm interoperability with open
 > source software.

It sounds like the IETF has a policy of requiring RF-only.  What's
wrong with this group saying "The IETF has a policy of requiring
RF-only".

---

From: Russell Nelson <[email-masked]>
Date: Thu, 20 Feb 2003 10:33:13 -0500

> reasons have been given already.  have you read them?

Yes.  Did you read my reply?

Perhaps one of us has a reading problem.  I don't think it's me.

---

From: Keith Moore <[email-masked]>
Date: Thu, 20 Feb 2003 11:25:32 -0500

> of RFC822. 

that's not the same thing as blessing practice.  in fact, 2822 was an
attempt to raise the bar over existing practice.

> Or zeroconf?  That just blesses Apple's implementation in Jaguar. 

uh, no.  there's been substantial pushback against everything except
link-local addressing, and even that isn't finalized yet.

> Or SLIP?  Romkey just wrote down what everybody knew.

If memory serves, SLIP is not a standard, and the rfc-index.txt file
is incorrect in this respect. 

> The IETF requires multiple
> Isn't THAT blessing practice?  

no, because the specification comes first, and the purpose of 
having multiple implementations is to make sure that the specification
is unambiguous and sufficientlly well-specified to facilitate
interoperability.

> wrong with this group saying "The IETF has a policy of requiring

IETF does not have a policy of requiring RF-only.  but it's extremely
rare that the consensus of the IETF community will permit standardizing
a protocol that requires use of encumbered technology.  some things
are better off not being codified in policy.  the current 
policy allows individual participants to make a determination about 
whether a patent is valid and applicable to some technology.   this is
good because IETF clearly cannot do that.  
_______________________________________________
Ipr-wg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ipr-wg

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Fri, 21 Feb 2003 09:13:27 +0100

[apologies for continuing on a somewhat offtopic thread...]

--On torsdag, februar 20, 2003 11:11:57 -0500 Russell Nelson 
<[email-masked]> wrote:

>  > you're making a generalization about IETF practice.  you need only to
> look  > at the actual practice to find numerous counterexamples.
>

RFC 2822's restriction of the In-reply-to: field was not a preexisting 
community interpretation, but was adopted based on community-recognized 
problems with the freeform nature of the field.

> Or zeroconf?  That just blesses Apple's implementation in

I have had it claimed that zeroconf's link-local IPv4 addressing is not 
compatible with either Apple's or Microsoft's implementation (and that 
these two are not compatible with each other). I don't know, I don't much 
like link-local.
Zeroconf set out to do much more, but failed to come to consensus....

>  Or SLIP?  Romkey just wrote down what everybody knew.

I stand corrected; although the title of the document is "Nonstandard", it 
is in fact labelled "Standard", and has been since 1989; it never went 
through the 3-step IETF standardization process, but was "grandfathered".

>  PPP,

Before something is made Draft Standard, not at Proposed (unless it's a 
routing protocol with significant impact). And we've had lots of flak on 
being too strict on that too.

> counterexamples to my experience.

Starting from the end of my RFC index....

3454 Preparation of Internationalized Strings ("stringprep"). P.
     Hoffman, M. Blanchet. December 2002. (Format: TXT=138684 bytes)
     (Status: PROPOSED STANDARD)

3442 The Classless Static Route Option for Dynamic Host Configuration
     Protocol (DHCP) version 4. T. Lemon, S. Cheshire, B. Volz. December
     2002. (Format: TXT=19370 bytes) (Updates RFC2132) (Status: PROPOSED

3431 Sieve Extension: Relational Tests. W. Segmuller. December 2002.
     (Format: TXT=12849 bytes) (Status: PROPOSED STANDARD)

3428 Session Initiation Protocol (SIP) Extension for Instant
     Messaging. B. Campbell, Ed., J. Rosenberg, H. Schulzrinne, C.
     Huitema, D. Gurle. December 2002. (Format: TXT=41475 bytes) (Status:
     PROPOSED STANDARD)

3420 Internet Media Type message/sipfrag. R. Sparks. November 2002.
     (Format: TXT=14745 bytes) (Status: PROPOSED STANDARD)

3408 Zero-byte Support for Bidirectional Reliable Mode (R-mode) in
     Extended Link-Layer Assisted RObust Header Compression (ROHC)
     Profile. Z. Liu, K. Le. December 2002. (Format: TXT=14805 bytes)
     (Status: PROPOSED STANDARD)

you recognize the pattern... I only included the ones where I'm fairly sure 
about there not being a widely deployed practice that the IETF could bless.

Of course, if there isn't an existing practice by the time we want to 
advance to Draft, something's seriously wrong with the standard.....

                   Harald