[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: #1400 Opinion poll - question draft
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 at alvestrand.no>
To: <ipr-wg at ietf.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:D,
> 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-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