>>>>> "Olaf" == Olaf Kolkman writes:
Olaf> On Sep 8, 2009, at 6:09 PM, Sam Hartman wrote:
> Tim, I definitely agree with you that it should be the IETF community
>> that is last called. Normally, the IESG judges IETF consensus.
>> Howeve
Tim, I definitely agree with you that it should be the IETF community
that is last called.
Normally, the IESG judges IETF consensus.
However, if it makes the IAB more comfortable for the IAB chair to do the
consensus call, that's fine with me. If we do that we'd need to make
it clear how this inte
> "John" == John C Klensin writes:
John> However, if your concern is really to make sure that there
John> is a timely appeal path, I have a suggestion that might be
John> acceptable to everyone without causing unfortunate
John> side-effects. We simply require that, if the ISE
Russ, I think that it is absolutely critical that the IETF be able to
attach a note to an RFC and that this note not simply be a
recommendation.
We can believe all we want that the IETF stream is just one stream and
that all other streams are independent. However, the RFC process is
very tightly
Yes. Rather than going to IETF 75 I went to a Debian conference.
happened to bring my IETF 74 shirt, and it was quite popular. Several
people asked where they could get one.
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
I'd definitely like to continue to be able to use the ietf website
from text browsers. That's not an absolute requirement for me, but it
is very convenient.
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
> "Marshall" == Marshall Eubanks writes:
Marshall> Monte is Founder and Executive Contact, xiph.org, and is
Marshall> responsible (as much as any person) for Ogg / Vorbis. He
Marshall> was also one of my sources from before.
The message you quoted is entirely non-responsive to th
I find myself in complete agreement with John's message. I'll admit
that I probably don't have the time or desire to actually examine the
IAOC's actions if they were to be accountable to the community.
However, when I was involved in drafting BCP 101 it was my assumption
that the IAOC would be acc
I too do not believe that reducing the review period of TLP changes is
at all reasonable.
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
Thanks for bringing this to our attention.
Having reviewed the draft, I support publication of this document as a
BCP. I think it is a long-needed change. I understand that there are
important tradeoffs involved, and while I acknowledge that there are
disadvantages to this change, I think that i
> "Eric" == Eric Rosen writes:
Eric> I don't see that OPSAWG has any business imposing
Eric> requirements on work done by other WGs in other Areas.
Obviously I agree with this statement. However I do believe that the
ops area can propose and build consensus on requirements that we a
> "Eric" == Eric Rosen writes:
Eric> If we are going to talk about adding new hoops for folks to
Eric> jump through, we should first discuss whether any such hoops
Eric> are necessary. We should not start the discussion by
Eric> looking at the details of the particular propose
> "Dan" == Romascanu, Dan (Dan) writes:
Dan> Sam, Thank you for your review and opinions.
Dan> I would like to remind you and let many people that are not
Dan> aware about the history of the document know one fact that
Dan> may be important. This document is an outcome of the
I was assigned this document as a secdir review.
I'm not sure I have any comments in that capacity.
However, I do have significant comments on the last call of this document.
I appreciate the work that has gone into this document. People have
worked hard to find examples, cases and even pithy
sa
Keith, Melinda, I believe you are talking about an issue that is distinct from
what was discussed in the BOF.
My personal preference is to see work on what was discussed in the BOF.
However to respond to Jari, I do not have have concerns with the charter as
written.
_
>>>>> "David" == David W Hankins writes:
David> On Mon, Apr 20, 2009 at 06:08:40PM -0400, Sam Hartman wrote:
>> I'd actually appreciate focus on the multiple interfaces (or
>> multiple network providers) problem. I think that attacking
>>>>> "Fred" == Fred Baker writes:
Fred> On Apr 17, 2009, at 1:18 PM, Sam Hartman wrote:
> My question is whether treating tools.ietf.org aliases as IETF lists
>> is reasonable policy.
Fred> And I would say that yes, they are IETF lists.
Keith, I've considered your points and continue to disagree. I'm
mostly replying in the interest of judging consensus.
I believe that the primary use cases identified in the MIF BOF are use
cases that are not going to go away. I think that saying "avoid
multiple addresses" is likely to be the sa
> "Keith" == Keith Moore writes:
Keith> It seems to me that the general problem is not multiple
Keith> interfaces, but multiple addresses per host. It doesn't
Keith> matter (much) whether those addresses result from multiple
Keith> physical interfaces, a combination of physic
> On 2009-04-21 02:44, Dave CROCKER wrote:
>>
>
> Andrew Sullivan wrote:
>> On Fri, Apr 17, 2009 at 04:18:06PM -0400, Sam Hartman wrote:
>>
>>> My question is whether treating tools.ietf.org aliases as IETF
>> lists
>>>> is reasonable
> "Russ" == Russ Housley writes:
Russ, I'm failing to understand how your comments are responsive to
the points I made. One of the things I said is that I was not
specifically speaking to the questino of whether removing Dean from
the aliases was reasonable. However your entire response foc
> "Cullen" == Cullen Jennings writes:
>> As these alias lists are effective within the ietf.org domain,
>> the relevant IETF policies on spam and posting-rights actions
>> must be considered to apply to them, as they do to ietf mailing
>> lists in general.
I find the above sta
I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the
IESG. These comments were written primarily for the benefit of the
security area directors. Document editors and WG chairs should treat
these comments just like a
Sorry, I didn't notice the upper case terms in the second paragraph.
I definitely agree they should be removed.
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
> "Robin" == Robin Whittle writes:
Robin> Short version: I support Dimitri's suggested changes about
Robin> the roles of Locators and Identifiers.
Robin> The current draft still contains an
Robin> erroneous inference that the one address could be used as
> "Michael" == Michael Menth writes:
Michael> The sentence "who you are" is rather confusing to me
Michael> although its intention is certainly to be a simple and
Michael> catchy explanation. However, "you" - the user (?) is
Michael> probably not an edge interface designator.
I'd like to present the following revised charter to the community
(and with Jari's approval) to the IESG for review. This charter
represents discussion on the LISP list and in the LISP session at IETF
74.
The IAB's October 2006 workshop on Routing and Addressing Workshop (RFC
4984) rekindled
> "Kurt" == Kurt Zeilenga writes:
>>>
>> That's not what "IETF Consensus" means in the context of RFC
>> 2434:
>>
>> IETF Consensus - New values are assigned through the IETF
>> consensus process. Specifically, new assignments are made via
>> RFCs approved by the
> "John" == John Sullivan writes:
John> The Licensing Declaration starts out right:
>> RedPhone Security hereby asserts that the techniques for
>> sending and receiving authorizations defined in TLS
>> Authorizations Extensions (version
>> draft-housley-tls-authz-extns-0
> "Josh" == Josh Howlett writes:
Josh> I have a long list of applications, collected from within
Josh> this community, with which they would like to use SAML-based
Josh> authorisation; and it seems to me that the ability for
Josh> application protocols to share a common mechan
> "TSG" == TSG writes:
TSG> There is a serious concern that when individuals are
TSG> 'filtered out of IETF lists' whether by official or
TSG> unofficial means, that their voices are prevented from being
TSG> included into the IETF standards process.
I'd feel this issue was
> "Ken" == Ken Raeburn writes:
Ken> That might be an argument for restricting posting to
Ken> subscribers only. At least some mailing list management
Ken> software will let you put yourself on a list but flagged as
Ken> not to receive mail, if you already read it through some
This draft specifies the BNF varient used in RSVP and related
protocols. The authors correctly indicate that converting these BNF
specifications to use ABNF or some other already documented BNF form
would be a lot of work. So, I agree that we should document this BNF
varient.
However I believe
> "Dean" == Dean Anderson writes:
Dean> 3. --There have been reports of similar issues in recent
Dean> lawsuit where the plaintiff patent-holder acted similarly to
Dean> Housley/Brown/Polk et al and was found to have engaged in
Dean> "aggravated litigation abuse". In that case
I think a standard in this space is really needed. I would definitely
like to be able to include SAML assertions and other statements of
authorization as part of a TLS exchange.
In the appropriate environments I'd be willing to implement this spec
given the current IPR situation.
__
> "Eliot" == Eliot Lear writes:
Eliot> Dear all, I don't know about other companies, but mine has
Eliot> pretty tight travel restrictions right now. I do not yet
Eliot> know if I will make the San Francisco IETF or Stockholm. I
Eliot> suspect attendance at both will be way d
> "Keith" ==writes:
Keith> tell you what - if by some very small chance (probably less
Keith> than 1%) I'm still around 50 years from now and feel like
Keith> revising RFC 793 at that time, I'll trust that you've
Keith> already reconnected with Jon and gotten his permission
Why do we need to send these license forms in at all?
I thought the requirement was that the authors get the necessary
rights. Are you just conveniently keeping track for us?
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/iet
> "Dave" == Dave CROCKER writes:
Dave> Joel M. Halpern wrote:
>> Yes, having to get rights from folks is a pain.
Dave> When the person is not longer available, the effect is more
Dave> than discomfort.
Strictly speaking, that's not actually true. We're talking about
copyr
> "John" == John C Klensin writes:
>> We have a reality that the new IPR rules are fundamentally
>> problematic. Prior to their imposition, we had a functioning
>> system. Now we don't.
>>
>> And the only thing that changed was imposition of the new
>> rules. Nothi
> "Simon" == Simon Josefsson writes:
>> Question. It is my understanding/assumption that the ONLY
>> parties that one must clearance from are the actual listed
>> authors of the document. Specifically, one does NOT need to go
>> back to everyone who might have contributed tex
> "Keith" == Keith Moore <[EMAIL PROTECTED]> writes:
Keith> I understand. But in practice just knowing your external
Keith> address is often insufficient. You need an intermediate
Keith> server that will forward traffic as well as maintain the
Keith> bindings in both (nay, al
Keith, I find myself in complete agreement with your message. I
particularly like the fact that you took the time to go through a
complicated reasoning process in a slow, clear manner so that your
readers could determine whether they agree with your reasoning and if
not, where they disagree.
> "Pete" == Pete Resnick <[EMAIL PROTECTED]> writes:
Pete> http://tools.ietf.org/rfc/rfc4844.txt
Pete> http://tools.ietf.org/id/draft-irtf-rfcs-03.txt
Pete> We have (IMO) historically screwed up with regard to IRTF
Pete> and individual documents and not given them a proper str
> "Dave" == Dave CROCKER <[EMAIL PROTECTED]> writes:
Dave> Stephane Bortzmeyer wrote:
>> On Fri, Nov 07, 2008 at 02:18:21PM -, John Levine
>> <[EMAIL PROTECTED]> wrote
>>> All of these questions have come up before on the various
>>> lists where this draft was developed
I tend to agree with Vidyan's comments. I think that addressing her
comments regarding a service model instead of a server model is
critical. While I too am surprised to see a WG review rather than a
second bof, I would not personally object to the work if a reasonable
process is followed in conf
>>>>> "Michael" == Michael StJohns <[EMAIL PROTECTED]> writes:
Michael> At 03:30 PM 10/2/2008, Sam Hartman wrote:
>> You're proposing a huge complexity increase for the TCP stack
>> in order to get this covert channel protectio
> "Michael" == Michael StJohns <[EMAIL PROTECTED]> writes:
Michael> Hi Joe - A quick disclaimer - although I was complicit in
Michael> allowing this draft to be resurrected from 1992, I have
Michael> had very little to do with it on this cycle.
Michael> At 02:18 PM 10/2/2008,
> "Joe" == Joe Touch <[EMAIL PROTECTED]> writes:
Joe> I was wondering about that; it seems inconsistent to have
Joe> this document require something that is optional in RFC 4301.
I suspect you realize this, but some people following the discussion
may not. It's critical to this mech
> "Steven" == Steven M Bellovin <[EMAIL PROTECTED]> writes:
>>
>> You could potentially have both an end-to-end SA and a
>> hop-by-hop SA. That says that you trust intermediate systems
>> less than you do the endpoints, but somehow you're still
>> trusting them not to dis
>>>>> "Steven" == Steven M Bellovin <[EMAIL PROTECTED]> writes:
Steven> On Mon, 29 Sep 2008 15:20:23 -0400
Steven> Sam Hartman <[EMAIL PROTECTED]> wrote:
>> Section 8 proposes that AH is the mandatory-to-implement
>> securi
I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the
IESG. These comments were written primarily for the benefit of the
security area directors. Document editors and WG chairs should treat
these comments just like
> "Spencer" == Spencer Dawkins <[EMAIL PROTECTED]> writes:
Spencer> Out of the eleventy-seven flavors of DISCUSS, some ARE
Spencer> blocking. Others aren't intended to survive the first
Spencer> telechat ("process DISCUSS", or "discuss DISCUSS", and
Spencer> after sitting with
Simon, can I get you to analyze what position the IETF should take on
these issues--what form of consensus we're looking for.
For my part, it doesn't make sense to pursue this within the IETF
context--responding to feedback, trying to get a draft that everyone
is happy with--if the IETF is going t
> "Larry" == Larry Zhu <[EMAIL PROTECTED]> writes:
>> First, if I call gss_display_name on an anonymous principal in
>> an acceptor, what do I expect to get back?
Larry> Would section 2.1.1 of RFC1964 be sufficient for this
Larry> purpose?
not really. As Ken pointed out, the
> "Brian" == Brian E Carpenter <[EMAIL PROTECTED]> writes:
Brian> Also note that appeal and recall procedures for the IAOC
Brian> are defined in RFC 4071, and that clearly includes Trust
Brian> actions, since the Trustees are by definition the IAOC
Brian> members. So if the IE
> "LB" == LB <[EMAIL PROTECTED]> writes:
LB> Dear Russ, I am not sure what should be the "next step" and I
LB> wish that all is clear and transparent in the management of
LB> what I take for a censure for offence of opinion or
LB> nationality. I think like somebody else, I use
With one minor concern, I do believe this draft is ready for
publication as a proposed standard. However I think this draft is
fairly rough as proposed standards go; I expect that we will end up
needing a new revision of this spec at some future point that refines
some of the details based on im
>>>>> "Alexey" == Alexey Melnikov <[EMAIL PROTECTED]> writes:
Alexey> Hi Sam,
Alexey> Sam Hartman wrote:
>> I find the string "MUA" meaning anything that happens after
>> delivery confusing. I'd suggest anothe
I think there is a minor ambiguity in the naming draft:
>Consequently, unless otherwise
> specified, a well-known Kerberos realm name MUST NOT be present in
> transited encoding
Who enforces this requirement? That's an important question because
it controls who needs to support the specifi
o me how
John> much of your comments are major but...
John> --On Tuesday, 18 March, 2008 04:51 -0400 Sam Hartman
John> <[EMAIL PROTECTED]> wrote:
>> ... In particular I believe that the remote-host and remote-ip
>> variables are inappropriate and sh
>>>>> "Cyrus" == Cyrus Daboo <[EMAIL PROTECTED]> writes:
Cyrus> Hi Sam, --On March 18, 2008 4:51:42 AM -0400 Sam Hartman
Cyrus> <[EMAIL PROTECTED]> wrote:
>> This extension appears to conflate two unrelated things:
>> in
This extension appears to conflate two unrelated things: information
about the interpreter context and information about the message.
I don't think these two sets of information are similar enough that the same
interface should be used to get to both of them.
In particular I believe that the r
>>>>> "Dave" == Dave Crocker <[EMAIL PROTECTED]> writes:
Dave> Sam Hartman wrote:
>> Making it a BCP will make the interpretation problem worse not better.
Dave> How?
You can update an IESG statement mor easily than a BCP. As you find
a
>>>>> "Ted" == Ted Hardie <[EMAIL PROTECTED]> writes:
Ted> At 1:43 PM -0800 3/6/08, Sam Hartman wrote:
>> >
>> I know that I would treat a request to rethink whether a discuss I
>> held was consistent with the discuss
> "Ted" == Ted Hardie <[EMAIL PROTECTED]> writes:
Ted> Speaking again as someone who thinks this is general problem, the
Ted> issue I am raising is not that there are bad discusses. The issue I
Ted> am raising is that the document which describes what discusses
Ted> are or sho
> "Lakshminath" == Lakshminath Dondeti <[EMAIL PROTECTED]> writes:
Lakshminath> Sam,
Lakshminath> I fail to understand why this has to be a guessing game. I
also don't
Lakshminath> understand the argument about resolving DISCUSSes sequentially
(in
Lakshminath> reference to y
> "Lakshminath" == Lakshminath Dondeti <[EMAIL PROTECTED]> writes:
Lakshminath> Cullen,
Lakshminath> Thank you for your statement that you are keen to make sure
your
Lakshminath> DISCUSSes are within the parameters of the discuss criteria
ION. I
Lakshminath> appreciate it.
> "Ted" == Ted Hardie <[EMAIL PROTECTED]> writes:
Ted> I respect your work, but I believe the IESG has recently
Ted> relaxed the vigilance it once held toward adherence to these criteria.
Ted> I have seen at least two recent discusses that amounted to
Ted> "go satisfy that guy"
> "Cullen" == Cullen Jennings <[EMAIL PROTECTED]> writes:
Cullen> Ted,
Cullen> Speaking for myself here but I suspect that other ADs are in the
same
Cullen> boat ... I'm keen to make sure my Discusses are within the
parameters
Cullen> of the discuss criteria ION regardless o
> "Hallam-Baker," == Hallam-Baker, Phillip <[EMAIL PROTECTED]> writes:
Hallam-Baker,> The FSF copntinues to attempt to re-open this
Hallam-Baker,> decision.
Phil, I think the important point here can be made in a much more
neutral manner. The last call period is closed. Additional
d
> "john" == john loughney <[EMAIL PROTECTED]> writes:
john> Are we the Internet Standardization Development Task Force?
john> It seems by this thread, many of us are afraid to do any
john> engineering and just work on emails and paper.
I *knew* there was some reason I didn't lik
> "Tony" == Tony Hain <[EMAIL PROTECTED]> writes:
Tony> I am willing to conceded on the behave point because client
Tony> side actions really don't matter, but I want to see multiple
Tony> people running mta's and independent web servers on the
Tony> nat'd IETF network, with ac
> "Tony" == Tony Hain <[EMAIL PROTECTED]> writes:
Tony> Sam, While I understand the virtue in behave-compatible
Tony> nats, how realistic is it to believe that any service
Tony> provider is going to allow a consumer to directly signal
Tony> their infrastructure?
The behave do
> "Tony" == Tony Hain <[EMAIL PROTECTED]> writes:
Tony> Hallam-Baker, Phillip wrote:
>> The double NAT approach is much closer to what the actual
>> transition is going to look like. The only difference is that I
>> think we might just be able to work out a viable means of
> "Tony" == Tony Hain <[EMAIL PROTECTED]> writes:
Tony> the right experiment. It is not right because it does
Tony> nothing positive, other than the threat -maybe- spurring
Tony> some action. A more realistic experiment would be to run the
Tony> entire week with a double-nat fo
> "Norbert" == Norbert Bollow <[EMAIL PROTECTED]> writes:
Norbert> Iljitsch van Beijnum <[EMAIL PROTECTED]> wrote:
>> But what about transition mechanisms, or would that be unfair?
Norbert> IMO it would be unfair on IPv6 to do the test without
We should provide transition mechani
> "Paul" == Paul Hoffman <[EMAIL PROTECTED]> writes:
Paul> At 3:33 PM +0200 11/29/07, Jari Arkko wrote:
>> And we can move a document to historic,
Paul> Note that there are two different "no process change needed"
Paul> proposals on the table: obsoleting with NULL (or a bit of
>>>>> "John" == John C Klensin <[EMAIL PROTECTED]> writes:
John> --On Wednesday, 28 November, 2007 17:15 -0500 Sam Hartman
John> <[EMAIL PROTECTED]> wrote:
>>>>>>> "John" == John C Klensin <[EMAIL PROTECTED]
> "Paul" == Paul Hoffman <[EMAIL PROTECTED]> writes:
Paul> One easy solution to the problem is to not change anything
Paul> in the current IETF or RFC rules. If an RFC has been
Paul> published before the appeal is brought, and that appeal is
Paul> ultimately successful, a new R
>>>>> "Eric" == Eric Rescorla <[EMAIL PROTECTED]> writes:
Eric> At Wed, 28 Nov 2007 17:15:40 -0500,
Eric> Sam Hartman wrote:
>> >>>>> "John" == John C Klensin <[EMAIL PROTECTED]> writes:
>>
> "John" == John C Klensin <[EMAIL PROTECTED]> writes:
John> --On Thursday, 29 November, 2007 09:54 +1300 Brian E
John> Carpenter
John> <[EMAIL PROTECTED]> wrote:
John> I'd like to see something like the above combined with a
John> shorter window, maybe at two levels ("hol
> "David" == David Kessens <[EMAIL PROTECTED]> writes:
David> Iljitsch,
David> On Thu, Nov 15, 2007 at 10:37:03AM +0100, Iljitsch van
David> Beijnum wrote:
>> On 15 nov 2007, at 8:27, David Kessens wrote:
>>
>> >PS as my personal opinion on NAT-PT, as long as we defin
> "JORDI" == JORDI PALET MARTINEZ <[EMAIL PROTECTED]> writes:
JORDI> Last mile is not yet IPv6 enabled, but automatic transition
JORDI> mechanisms such as 6to4 and Teredo are playing very well,
JORDI> and there is a huge amount of non-native IPv6 traffic.
JORDI> So I can't agr
> "Joe" == Joe Touch <[EMAIL PROTECTED]> writes:
Joe> Hi, Steve,
Joe> Steven M. Bellovin wrote:
>> On Wed, 14 Nov 2007 15:39:50 -0500
>> Stephen Kent <[EMAIL PROTECTED]> wrote:
>>
>>> Joe,
>>>
>>> I disagree with your suggestion "The software performance of
I definitely think it is important that when using a URI or IRI in
another protocol to be able to follow the conventions of the URI or
IRI. Similarly, even if we find a convention that we don't like I
think it is valuable to be able to build on existing work rather than
introduce confusion.
--Sam
Personally I think I liked the original jabberid concept better, but
all of these concepts seem acceptable and the important thing in my
mind is for us to pick one and standardize it.
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/lis
>>>>> "Romascanu," == Romascanu, Dan (Dan) <[EMAIL PROTECTED]> writes:
>> -Original Message- From: Sam Hartman
>> [mailto:[EMAIL PROTECTED] Sent: Monday, October 29, 2007 10:24
>> PM To: Leslie Daigle Cc: IESG; ietf@ietf.or
I'd like to draw the attention of the IETF community to this document.
It seems hugely complex. I'd like to ask those not involved in the
xcon working group to take time to read it and to consider whether
this complexity is necessary.
I'd particularly like to ask people to consider section 9.
> "Leslie" == Leslie Daigle <[EMAIL PROTECTED]> writes:
I doubt I'll use the output in security protocols.
Leslie> Leslie.
Leslie> Original Message Subject: WG Review:
Leslie> Performance Metrics at Other Layers (pmol) Date: Mon, 22
Leslie> Oct 2007 14:1
Folks, while attempting to use draft-williams-on-channel-binding in
the SASL working group, we came across an ambiguity.
In response to IETF last call comments we added the concept of a
unique prefix and a registry of prefixes for channel binding type. We
added a requirement that applications m
> "Eric" == Eric Rosen <[EMAIL PROTECTED]> writes:
Eric> - I don't think the IETF considers "this document offends my
Eric> political point of view" to be a legitimate reason for
Eric> opposing the document. The degree of passion and/or
Eric> repetition with which the politica
> "Ben" == Ben Finney <[EMAIL PROTECTED]> writes:
Ben> To whom it may concern, I have been made aware that the
Ben> technology described in the 'draft-housley-tls-authz-extns'
Ben> proposal is encumbered by patents held by entities with a
Ben> history of patent enforcement.
I'
> "RJ" == RJ Atkinson <[EMAIL PROTECTED]> writes:
RJ> I support the idea that virtually any document ought to be
RJ> able to be published as an Informational RFC or Experimental
RJ> RFC. Technology that is useful will be adopted if
RJ> economically sensible, whether in an RFC
>>>>> "Simon" == Simon Josefsson <[EMAIL PROTECTED]> writes:
Simon> Sam Hartman <[EMAIL PROTECTED]> writes:
>>>>>>> "Simon" == Simon Josefsson <[EMAIL PROTECTED]> writes:
>>
Simon> "Fra
> "Hallam-Baker," == Hallam-Baker, Phillip <[EMAIL PROTECTED]> writes:
Hallam-Baker,> The two types of wiggle room that experience has
Hallam-Baker,> taught me to be highly undesirable are:
Hallam-Baker,> 1) Wiggle room of the form 'our terms are as good
Hallam-Baker,> as RAN
> "Ted" == Ted Hardie <[EMAIL PROTECTED]> writes:
>> It seems to me that in some sense that disclosing a patent
>> should not make us less willing to use something. This is
>> especially true when the disclosing party is not obligated to
>> make the disclosure. Disclosing a
>>>>> "Ted" == Ted Hardie <[EMAIL PROTECTED]> writes:
Ted> At 3:06 PM -0400 10/23/07, Sam Hartman wrote:
>> Let me suggest starting with a lesser goal. Try to build a
>> consensus that unless there is a good reason to do otherwise,
Phil, I understand what you're trying to do. I agree that more wiggle
room makes it harder.
However I think that to achieve consensus you're going to need to
allow working groups to choose to turn on the wiggle room.
I think that you could get somewhere with an opt-in proposal. For a
particular
> "Simon" == Simon Josefsson <[EMAIL PROTECTED]> writes:
Simon> "Frank Ellermann" <[EMAIL PROTECTED]> writes:
>> Simon Josefsson wrote:
>>> I would even consider a requirement that in order to move
>>> beyond Proposed Standard, a protocol needs to have a free
>>> implementa
201 - 300 of 782 matches
Mail list logo
