It is perhaps implicit, but I would rather it were explicit,
that there are
other types of code than those listed in both questions;
The wording has
overtones for me that this is an exclusive list. 'XML
Schema' sort of
implies the W3C schema but (I keep being told) RelaxNG is
much simpler and
widely used in the Transport Area and then there is XML
itself, while security
documents are littered with ASN.1 that will never see the
inside of a MIB. I
know we debated earlier what is code and I cannot see a
resolution of that and,
as I say, the question sort of implies that this is what
code is, period.
Tom Petch
----- Original Message -----
From: "Harald Tveit Alvestrand" <harald alvestrand.no>
To: <ipr-wgietf.org>
Sent: Tuesday, December 05, 2006 8:54 AM
Subject: #1400 Opinion poll - question draft
> This issue is now #1400 in the tracker.
>
> And I think it's time for one of my (in)famous opinion
polls.
>
> First - let's see if I can get the question right. If
it's OK, we'll go on
> to state opinions. So please do NOT spend bandwidth on
stating your opinion
> now - this is about whether the question is right.
>
> Question formulation follows.
>
------------------------------------------------------------
--------
> We have two alternative formulations suggested for
section 5.3 of the draft:
>
> 1) Original:
>
> IETF contributions often include components intended
to be directly
> processed by a computer. These may be ABNF
definitions, XML Schemas
> or DTDs, MIBs, or even classical programming code.
These are include
> for clarity and precision in specification. It is
clearly
> beneficial, when such items are included in IETF
contributions, to
> permit the inclusion of such code fragments in
products which
> implement the contribution. It has been pointed out
that in several
> important contexts, use of such code requires the
ability to modify
> the code. One common example of this is simply the
need to adapt
> code for use in specific contexts (languages,
compilers, tool
> systems, etc.) Such use frequently requires some
changes to the text
> of the code from the IETF contribution. Another
example is that code
> included in open source products is frequently
licensed to permit any
> and all of the code to be modified. Since we want
this code included
> in such products, it follows that we need to permit
such
> modification. While there has been discussion of
restricting the
> rights to make such modifications in some way, the
rough consensus is
> that such restrictions are likely a bad idea, and
are certainly very
> complex to define.
>
> As such, the rough consensus is that code components
of IETF
> contributions can be extracted, modified, and used
by anyone in any
> way desired.
>
> 2) Reformulation:
>
> IETF contributions often include components intended
to be directly
> processed by a computer. These may be ABNF
definitions, XML Schemas
> or DTDs, MIBs, or even classical programming code.
These are include
> for clarity and precision in specification. It is
clearly
> beneficial, when such items are included in IETF
contributions, to
> permit the inclusion of such code fragments in
products which
> implement the contribution. It has been pointed out
that in several
> important contexts, use of such code requires the
ability to modify
> the code. One common example of this is simply the
need to adapt
> code for use in specific contexts (languages,
compilers, tool
> systems, etc.) Such use frequently requires some
changes to the text
> of the code from the IETF contribution. Another
example is that code
> included in open source products is frequently
licensed to permit any
> and all of the code to be modified. Since we want
this code included
> in such products, it follows that we need to permit
such
> modification. While there has been discussion of
restricting the
> rights to make such modifications in some way, the
rough consensus is
> that such restrictions are likely a bad idea, and
are certainly very
> complex to define.
>
> As such, the rough consensus is that code components
of IETF
> contributions can be extracted, modified, and used.
>
> Draft authors or editors MAY state that substantial
> modifications based on the published code have to be
> "shared alike", i.e. published with a
similar proviso.
>
> There were 14 people who stated at the San Diego
meeting that they were
> part of a consensus for the first version. While the
second alternative was
> not explicitly put on the table in San Diego, I think
the debate has been
> circling around the issue long enough that it's
reasonable to consider
> these 14 as not supporting the second - but it's better
to ask than to
> blindly assume that. So I'll give more than two
alternatives:
>
> A) I stated a preference in San Diego, and prefer
version 1
> B) I stated a preference in San Diego, but prefer
version 2
> C) I did not state a preference in San Diego, and
prefer version 1
> D) I did not state a preference in San Diego, and
prefer version 2
> E) I have another opinion, which is...
>
>
----------------------------------------------------------
> Remember: I AM NOT ASKING FOR PEOPLE TO STATE AN
OPINION NOW.
> I am asking on whether the question formulation is
"good enough".
>
> When trying to evalate responses, I intend to look at
the number of people
> who choose A and B, and see how they match up with the
14:0 distribution of
> people who stated an opinion in San Diego. If they all
choose A, I'll count
> the 14 people in San Diego as preferring version 1; if
they spread out,
> I'll evaluate it differently - if A:B has the same
distribution as C ,
> I'll just forget about reading anything into the San
Diego poll and
> continue just based on the email poll.
>
> But this is the IETF, so it's NOT a vote; the purpose
of the exercise is to
> figure out whether there is a rough consensus present,
or whether there is
> a sizeable group of participants who agree that version
2 is better than
> version 1.
>
> A 51:49 outcome will decide nothing.
>
> Harald
>
>
> _______________________________________________
> Ipr-wg mailing list
> Ipr-wgietf.org
> https:/
/www1.ietf.org/mailman/listinfo/ipr-wg
_______________________________________________
Ipr-wg mailing list
Ipr-wgietf.org
https:/
/www1.ietf.org/mailman/listinfo/ipr-wg
|