sumes facts not in evidence.
Yours,
Joel M. Halpern
___
Ietf mailing list
[EMAIL PROTECTED]
https://www1.ietf.org/mailman/listinfo/ietf
age-
> From: Joel M. Halpern [mailto:[EMAIL PROTECTED]
> Sent: Thursday, September 23, 2004 16:35
> To: [EMAIL PROTECTED]
> Subject: Re: Scenario O Re: Upcoming: further thoughts on where from
> here
>
>
> I think that this (scenario 0) is the right approach to
> follow.
Actually, as far as I can tell the accountability is about the same in both
cases, and in neither case as "direct" as one would philosophically like
(but probably as direct as one can get in practice.) Similarly, the
"change control" appears to be equally in the IETF hands.
Yours,
Joel
At 10:3
advancing such views.
Yours,
Joel M. Halpern
At 10:59 AM 10/21/2004 -0400, Eric S. Raymond wrote:
Brian E Carpenter <[EMAIL PROTECTED]>:
> I don't think we can require the IESG to negotiate anything. There are
> all kinds of legal issues there. To my knowledge, both WGs and the IESG
>
OC, as it would make explicit if the IASA / IAD are
not doing a good job planning.
Yours,
Joel M. Halpern
Not on of the document maintainers
but someone trying to understand what it will turn out to mean.
At 07:55 PM 11/17/2004, Fred Baker wrote:
A question for those maintaining the documentÂ…
Th
managing the
contract with the infastructure provider.
Yours,
Joel M. Halpern
At 10:27 AM 11/26/2004, Wijnen, Bert (Bert) wrote:
In draft-ietf-iasa-bcp-00.txt it states at the end of sect 3.1:
Unless explicitly delegated with the consent of the IAOC, the IAD
will also fill the role of the IETF
x27;s job to award that contract.
One would hope that the IESG had review over the person who they had to
work with that closely. But such review is VERY different from getting to
choose the person.
Just my reading of the documents,
Joel M. Halpern
At 04:40 PM 11/26/2004, Sam Hartman
On what kinds of grounds should such things be appealable?
For WG decisions, there can be appeals based on technical grounds or
procedural grounds.
The ISOC however may only here pure procedural appeals.
I would hate to see someone "appeal" an IAD decision because they happened
to disagree with
Internet. Even the "definition" of the IETF
in the document is primarily for context rather than as an effort to
actually "define" the IETF.
Yours,
Joel M. Halpern
At 07:26 AM 12/8/2004, JFC (Jefsey) Morfin wrote:
If we want to get WSIS support and subsequent R&D publ
,
Joel M. Halpern
At 05:23 PM 12/19/2004, Scott Bradner wrote:
jck sed:
> Personally, I think I'd be happier with a
> professionally-conducted search, but YMMD (and probably does).
I agree (fwiw)
I suggested directly to the IASA TT but did not get a positive respose so
I'll suggest
I think that there is a different side of this.
Suppose that a budget was worked out (as below), with a plan for a certain
expected coverage from ISOC general funds, meeting fees, and directed
donations.
Lets presume the budget includes the plan for building the reserves.
If meeting fees run high
This is a good question.
We probably ought to say something.
This may be too strong (but I am not sure.)
At a minimum, I would expect an IAOC member with such a conflict of
interest to recuse themselves from any discussion of the situation.
But, as written, this has odd implications. For exampl
t 10:25 AM 12/22/2004, Brian E Carpenter wrote:
Joel,
Joel M. Halpern wrote:
I think that there is a different side of this.
Suppose that a budget was worked out (as below), with a plan for a
certain expected coverage from ISOC general funds, meeting fees, and
directed donations.
Lets presume
I like this resolution. I think the "review against a zero base
assumption" captures the essential goal, and the minimum staff was a weak
restatement.
Yours,
Joel
At 07:44 AM 1/12/2005, Harald Tveit Alvestrand wrote:
--On onsdag, januar 12, 2005 07:29:27 -0500 Scott W Brim
wrote:
On 1/12/20
Maybe I am naive, but the discussion I have seen on the list is not
actually about something the IETF can or should "approve". Reportedly,
ForeTec, CNRI, and Neustar are in negotiations. The IETF has no say in
such negotiations.
Reportedly, what has been asked is "will the IETF react badly to
does
not belong in this document at all.
With regard to Harald's original question, I believe this document is
"good enough". We can refine it from now till doomsday.
Yours,
Joel M. Halpern
At 06:06 PM 2/2/2005, JFC (Jefsey) Morfin wrote:
If the question is only that
ucts les useful, and reduce actual
interoperability in the field.
Yours,
Joel M. Halpern
At 05:36 AM 3/11/2005, shogunx wrote:
On Thu, 10 Mar 2005, Erik Nordmark wrote:
> Tony Hain wrote:
>
> >>Why are we wasting effort in every WG and research area on NAT traversal
> >>crap
You raise two questions about making the candidate list public.
You raise the question of whether we can afford the loss of candidates from
those people not willing to be seen as losing. I will admit to not being
sure I understand the driver for people who both have that concern and
could do th
in a significant increase.
Yours,
Joel M. Halpern
At 01:33 PM 5/8/2005, Geoff Huston wrote:
And there is some risk (small, I think) of people pushing others to
endorse them. This would seem easier with a public list, because the
nomcom is not left wondering why they got the supportive email.
A
Actually, based on experience in effective and ineffective working groups,
I don't think the 1 week (or even two weeks) suggested below is a
reasonable measure of activity.
When I was a WG chair, there were often multi-week periods when I did not
post anything to the list. Sometimes this was
the policy as written in the RFC requires that the IESG review the
proposal. Such a review clearly implies technical review, not just a check
for document completeness. The IESG did what the RFC tells them to do.
Yours,
Joel M. Halpern
At 07:04 PM 6/28/2005, Brian E Carpenter wrote:
John
domains where people can and
should be encouraged to experiment. But not all spaces have that
property. We have enough trouble with junk in spaces like DNS without
agreeing to register any type code / meaning that someone wants to write up.
Yours,
Joel M. Halpern
At 12:11 AM 7/1/2005, Spe
evere risk of backing ourselves into a
corner.
Yours,
Joel M. Halpern
At 08:42 AM 7/27/2005, Spencer Dawkins wrote:
I too like this draft and agree that having most IESG members serve for
two terms is ideal and making it more the exception that people serve
for three or four terms. I also lik
.
Yours,
Joel M. Halpern
At 06:09 AM 8/4/2005, John C Klensin wrote:
See my note posted a short time ago (which was written before seeing
yours). But, yes.This is exactly the thing I was commenting about in
that note. It is, at some level, a detail. It can be tuned in any of a
number of ways
erspective.
Yours,
Joel M. Halpern
At 06:00 AM 8/6/2005, Keith Moore wrote:
I actually think IETF might function better if nobody's badge had his
company's name on it, and nobody used a company email address. People
place way too much importance on someone's employer. Yes, so
I really hate lists with "reply-to" pointing to the list.
I know when I want to reply to the list, and when I want to reply
individually to the sender. When reply-to points to the list, it is
extremely difficult with most mailers to send a reply to the originator.
Yours,
Joel
At 11:49 AM 8/2
This document defines structure and meaning for labels, as well as the
procedure for registering parts of that structure.
As such, the structure is "bits on the wire" and is subject to
interoperability concerns.
Yours,
Joel M. Halpern
At 03:14 PM 9/6/2005, Sam Hartman wrote:
John,
Two observations:
1) Having been an active participant in the Nomcom working group, it is
amaxing it actually worked. The process took an absurdly long time to
converge on a very small set of changes. Having tried to drive ICAR, which
many people said was important, I again conclude that WGs
There is an aspect of the deadline that is helpful for me, even when the
deadline is not rigidly enforced.
The presence of the deadline means that the bulk of I-Ds are in by the
deadline, and are out by not too long after the deadline. This means that
I can collect announcements for I-Ds of int
ularly the distinction between a transport session and the
identifying characteristics of a transport session.)
Yours,
Joel M. Halpern
Paul Aitken wrote:
> Joel,
>
> Apologies for not responding sooner to your review, as it came right
> ahead of the -00 and -nn cutoffs.
>
> Plea
As I understand the gist of the comments, the document in question was
driven by the observation that folks were having trobule achieving
interoperability. Trying to fix that is clearly sensible and very much
in the IETF and working group interest.
Have you looked at things like the SIP tortur
e said that the IAB was
going to see the questionnaires in full. While I have heard the
argument that the nomcom can extend the confidentiality umbrella as far
as they want, it seems to me that extending it that far would be a mistake.
Yours,
Joel M. Halpern
Michael StJohns wrote:
> At
for the Derivation of Root Keys from an Extended
Master Session Key (EMSK)
Reviewer: Joel M. Halpern
Review Date: 17-March-2008
IETF LC End Date: 17-March-2008?
IESG Telechat date: N/A
Summary: This document appears ready for publication.
Comments:
While there has been much
Thank you. Comment following your clarification.
Joel
Lakshminath Dondeti wrote:
...
>> The one thing that bothers me a little is the intended status of
>> this document. Given that the EMSK is entirely inside a system, and
>> that therefore the actual generation process is internal to th
The inner comment, does not match my memory of the discussions.
Theodore Tso wrote:
> Attributed to Fred Baker:
>> I have heard it said that the IETF, in the most recent discussion
>> that failed up update that portion of what we now call 3777, had a
>> 90/10 consensus and didn't come to a per
se, if the community concludes that the trustees actions
aren't what we want, we can either replace the trustees or write another
IETF RFC. Trying to work that out in this draft did not seem productive.
>
> Peter
Yours,
Joel M. Halpern
___
IETF mailing list
IETF@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
ts is simple. The
> modified BSD license meets those requirements, as does a number of other
> methods, including releasing the work into the public domain.
My concern is not complexity. Referencing the specific documents is
more restrictive than what the working group recommended
nts
etc.
Remember, the state approach is for this document to state our goal, and
for the trust to achieve what we ask. The goal is not for us to
shoehorn legal text into the outbound document.
Yours,
Joel
Peter Saint-Andre wrote:
> Joel M. Halpern wrote:
>> I do not understand t
But adding references to example licenses, even if we were sure they
matched our goals, will not help anyone understand the agreed goals.
The existing statement is quite clear English.
Yours,
Joel M. Halpern
Simon Josefsson wrote:
> Paul Hoffman <[EMAIL PROTECTED]> writes:
>
>&
ting and assume that things flow.
Sometimes they don't Working groups make the same mistakes sometimes.)
Yours,
Joel M. Halpern
Ted Hardie wrote:
> At 3:04 PM -0700 5/29/08, Suresh Krishnan wrote:
>> Hi Folks,
>> We have written a draft describing some guidelines for authors a
Comment inline, with most of the discussion elided. I believe that one
particular question gets to the heart of what is bothering me.
Ted Hardie wrote:
> At 4:08 PM -0700 5/30/08, Joel M. Halpern wrote:
...
>> On design decisions, there is an even more complex tradeoff. I have
&g
ld mean one of three different
things. Should the reviewer have to provide text for all three
alternative meanings? After all "clarify the text" while clear is not
very specific as to what action is needed. There are also other cases
that come up where it may be impractical to requir
Of course, we also get complaints whenever anyone raises an issue
without providing text. So, by a strict reading of the argument, the AD
is hanged if he provides text (directing the working group) and hanged
if he does not provide text (you didn't make clear what your problem is,
and how to f
-capwap-protocol-binding-ieee80211-07.txt
CAPWAP Protocol Binding for IEEE 802.11
Reviewer: Joel M. Halpern
Review Date: August 2, 2008
IETF LC End Date: Any day now
IESG Telechat date: N/A
Summary: This document is almost ready for publication as a Proposed
Standard.
Question:
The
Thank you. Those changes address my concerns very well.
Please work with your document shepherd to determine when a new draft
should be produced with those changes.
I appreciate your prompt response,
Joel
Pat Calhoun (pacalhou) wrote:
Thanks for your review, Joel. Please see my comments below
Well, I personally would not recommend that $30 investment.
My machine speaks B and G (I don't think it speaks N, although the site
monitor can detect that.) I had repeatedly awful connectivity. When
rooms were sparse, (i.e. away from Convention 1, 2, &3 or before morning
start) things worked
including confirming what was historically relied on, having available
information if a working group returns to an item, and other issues.
Adding annotations, and organizing information for simplicity and
clarity are fine. Removing information is not fine.
Yours,
Joel
I have not had time to look carefully, but at least some (and I hope
almost all) of the MUSTs are constraints on documents which use the
schema to define additional library elements. This is not the protocol
document, so the MUST clauses (almost?) never refer to the protocol.
Given that these
Thanks Richard.
It is heartening that someone from another aspect of the community can
read and understand the document.
I will await instructions from the ADs as to whether some text on the
degree of control a lying FE can exercise while misleading the CE
(almost unlimited) is a helpful thing
rating the problems. The NAT solution, as I
understand it, does not make this problem worses. That is about all one
can ask of the NAT side of the equation.
Yours,
Joel M. Halpern
TJ wrote:
FWIW - I wholeheartedly agree with
"If we're going to standardize NATs of any kind, they need to
eemed to
me to be a case of the trust contravening the stated intention of the
IETF, as captured in the RFCs.
Yours,
Joel M. Halpern
PS: TO be quite clear, the question of whether the enforcement date is
December 12 2008, February 29, 2009, or April 1, 2009 is not a matter of
meeting the
t. The community is certainly free to decide
that it doesn't want to do that.
While some folks who were there say that they feel not enough attention
was paid to this issue, it is the case that we did discuss at least some
of the impact, and none of what turned out to be neede
Based on the discussion I have seen, an escape mechanism for old text
that really can not be processed otherwise is probably reasonable.
However, if we are making an effort to retain the work that was done, my
personal take is that the barrier to that escape mechanism has to be
high enough that
My own take has been that the code reuse problem is the dominant
problem. Document transfer outside the IETF is sufficiently rare that I
would agree with Fred that not solving that is fine.
This also means that from my personal perspective, a solution that says
(loosely based on a suggestion
Let's be quite clear here.
Your stated requirement for doing this was that authors had to be able
to take and modify any text from anywhere in an RFC.
The Working Group concluded that while that was reasonable relative to
code (and we tried to give the open source community that ability
relativ
M. Halpern
At 04:01 AM 1/22/2006, Brian E Carpenter wrote:
> Meetings should not be held in countries where some
> attendees could
> be disallowed entry or where freedom of speech is not
> guaranteed for all participants.
This is a very important issue as we consider visiti
that
necessary authority in the light of Mr. Morfin's exhibited and asserted
behavior.
Yours,
Joel M. Halpern
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
This experiment is a good idea.
Joel M. Halpern
At 06:50 PM 1/24/2006, you wrote:
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : Experimental Procedure for LongTerm
Suspensions from Mailing Lists
Author(s) : S
ve posting rights to that IETF mailing list"
for a period of time not to exceed the remaining period of the suspension
from any other IETF list?)
Thanks,
Spencer
This experiment is a good idea.
Joel M. Halpern
___
Ietf mailing list
Ietf
important.
Yours,
Joel M. Halpern
At 11:29 AM 1/31/2006, Ash, Gerald R \(Jerry\), ALABS wrote:
Hi All,
As a follow-up to our recent discussion, please review the draft at
http://www.ietf.org/internet-drafts/draft-ash-alt-formats-01.txt,
.pdf version available at
http://www.ietf.org/internet
Actually, the copyright notice covers more than just the boilerplate.
The authors retain their copyrights (there is no "transfer" of rights
as confuses some folks sometimes.)
However, the IETF needs a right to copy (a copyright) so as to
distribute, and work on, the Internet-Drafts and RFCs.
Th
issue I know of to manage with the "collection" of BCPs.
Yours,
Joel M. Halpern
At 12:37 PM 3/14/2006, todd glassey wrote:
Not that you folks take suggestions from me - but there would be a
tremendous value in creating a specific BCP WG that was a permanent part of
the IETF to
I would not that starting dynamic ports above 1024 or even above 4096
is not sufficient. There are already services with assigned ports
higher than that. And it keeps growing. The IANA list of well-known
ports is quite long.
If we could go back and start over, something like dynamic DNS and
While in general I would like to see this approach taken, this
particular case is a perfect example of where I think one can not
reasonably do that. The protocol is for the purpose of configuring a
router. The router that needs to be configured could easily be
between the network engineer and
.)
Yours,
Joel M. Halpern
At 12:56 PM 3/25/2006, Andy Bierman wrote:
Edward Lewis wrote:
At 15:51 +0100 3/25/06, Brian E Carpenter wrote:
If somebody comes to the IETF for a two hour meeting and wastes
the opportunity of another 30+ hours of learning about what other
WGs and BOFs are up to, that would
If we are willing to accept arbitrarily long paths to get from point
A to point B, there are techniques which allow topologically
insensitive packet handling. The Home-Register (aka HLR lookup) is
one way. (The routing reserachers have described this topic as
"stretch > 1" routing. There are
widespread (either because the barriers will still be high or because
the demand for BGP based multi-homing is small, or maybe for some
other reason.) If that assumption is correct, then the comparison
with NAT is irrelevant.
Yours,
Joel M. Halpern
At 06:57 PM 4/17/2006, Terry Gray wrote:
On
n listed (Formal Reviewing) does not, as far
as I know, currently occur during those phases. The formal reviewing
occurs after IETF LC ends, during IESG deliberations.
Yours,
Joel M. Halpern
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
I can live with that.
And I hope so can those who want to be restrictive as to what editing
takes place.
Yours,
Joel
At 09:27 PM 5/25/2006, Stephen Hayes (TX/EUS) wrote:
After some consideration, I can understand how the current text in
mankin-pub-req would be discouraging to the technical pu
the lines and start to guess. But the
document is quite unclear. The appendix about DSL is not helpful in
that regard.
Yours,
Joel M. Halpern
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
Yours,
Joel M. Halpern
At 11:34 AM 5/26/2006, Dave Crocker wrote:
Joel M. Halpern wrote:
EAP over IP (or UDP, or link) is about authenticating the user. If
a media independent technique better than just using a browser is
needed, then solve that problem. Personally, I would find the work
far mor
ime reading the framework document and
sending your feedback. Please see my response below.
On Fri, May 26, 2006 at 08:27:29AM -0400, Joel M. Halpern wrote:
> In reading the PANA Framework document, what I read seemed to me to
> be more of a "system" or "solution" docume
n listed (Formal Reviewing) does not, as far
as I know, currently occur during those phases. The formal reviewing
occurs after IETF LC ends, during IESG deliberations.
Yours,
Joel M. Halpern
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
tell it is not fatal.
Yours,
Joel M. Halpern
At 07:47 AM 6/7/2006, Spencer Dawkins wrote:
Perhaps I lead a sheltered life, but on two of these points...
> - Appendix A - some names seem to be missing. I could quote a small
> score of them?
I do not know if there are written rules about
uing about what goes in which contract, or whose pocket
the money comes from.
Please.
Yours,
Joel M. Halpern
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
rding in the charter to reflect what we have
agreed we want.
Yours,
Joel M. Halpern
At 12:40 PM 6/11/2006, Margaret Wasserman wrote:
Hi Joel,
I don't think that the document that Mike and I have been discussing is the
same one that you're talking about...
The one we've been dis
current procedures in a sensible fashion.
Yours,
Joel M. Halpern
At 06:20 AM 6/12/2006, Brian E Carpenter wrote:
C. M. Heard wrote:
On Thu, 1 Jun 2006, Eric Rosen wrote:
There are also other reasons why I find this proposed experiment
disheartening.
For one thing, it really
idea? How do we fix it?
Yours,
Joel M. Halpern
At 10:56 AM 6/14/2006, The IESG wrote:
The IESG has received a request from an individual submitter to consider the
following document:
- 'Proposed Experiment: Normative Format in Addition to ASCII Text '
as an Experimental RFC
.)
Yours,
Joel M. Halpern
At 09:44 AM 6/15/2006, Ash, Gerald R \(Jerry\), ALABS wrote:
> As Joel mentions, this experiment will have a negative impact on
> RFC Editor throughput. Shouldn't the IAB and perhaps the IAD
> have some part in this?
.pdf is allowed now for drafts and RF
cuss.
Sure, I hate producing ASCII art. But then, I hate producing
document art in any form. The problem is not ASCII. It is finding a
good, clean, understandable, way to express ones ideas.
Yours,
Joel M. Halpern
___
Ietf mailing list
Ietf@i
attempting
to draw a conclusion about the evidence suggested for evaluating the
experiment. I found the suggested evaluation criteria awkward. And
when I asked myself what would constitute reasonable criteria, it
seemed to me that the existing evidence was relevant.
Yours,
Joel M. Halpern
At 08:53
there is one useful aspect of our DS contortions. When we do the
work, we actually figure out which features turn out not to be used,
and get them out of the spec.
OSPF had ToS routing in its PS specification. It turned out that
there was only one implementation.
So when the protocol was read
meetings where we have
active participants makes good sense.
And folks can actively participate by email / I-D writing without
attending meetings.
Yours,
Joel M. Halpern
At 11:00 AM 7/15/2006, Patrick Vande Walle wrote:
Fred Baker said the following on 13/07/2006 13:38:
> My point is that it
In one session, I provided jabber note taking.
Participants indicated that my real-time efforts to create concise
statements of what was being discussed where helpful even with the
audio feed. (I asked because I was not sure I was adding value.)
Yours,
Joel
At 10:51 AM 7/17/2006, Iljitsch va
process.
Yours,
Joel M. Halpern
At 08:04 PM 7/22/2006, Dave Crocker wrote:
What I HAVE said is that the process of getting and demonstrating sufficient
community support should include requiring acceptable writing of the
specifications. If an effort is not able to recruit sufficient resources for
I agree that this seems to be the best course available.
Yours,
Joel M. Halpern
At 09:08 PM 8/31/2006, Theodore Tso wrote:
On Thu, Aug 31, 2006 at 05:55:25PM -0400, Jeffrey Hutzelman wrote:
> Therefore, I propose the following:
>
> (1) Andrew's decision stands. Under RFC
e can find.
Yours,
Joel M. Halpern
At 08:09 PM 9/14/2006, Hallam-Baker, Phillip wrote:
There is no need to define the concept of membership. The term
'membership' is essentially a legal term and the courts will define
it according to their convenience. One can be a member without
having a
At 09:28 PM 9/14/2006, Hallam-Baker, Phillip wrote:
> From: Joel M. Halpern [mailto:[EMAIL PROTECTED]
> I doubt that in the brief consideration based on your note I
> have found all of the problems.
Obviously. As Winston Churchill once remarked, "Democracy is the
worst poss
lable. Hypothetically,
there might be some better alternative, so I am not coupling my
response to the two questions.
Yours,
Joel M. Halpern
At 04:33 PM 10/19/2006, Sam Hartman wrote:
Hi, folks.
david filed the following discuss on Brian's draft to rescind 3683.
David is concerned that the IETF
o be re-written from scratch by someone who spoke English
(First second, or third language, but English.) They were simply too
badly written to tell if they were accurate.
Yours,
Joel M. Halpern
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.
at, we can have a useful debate on what changes
we would like to see in what the IESG does.
Yours,
Joel M. Halpern
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
e document or any portion of it."
Yours,
Joel M. Halpern
At 05:21 AM 1/13/2007, Simon Josefsson wrote:
Hi! These documents contains normative ASN.1 modules which, if I
understand the documents correctly, is typically included in
implementations of this standard. Is that correct?
The modul
maybe there would be
a problem.
Frankly, the ADs did their job. The chairs should now determine if
the conclusions reached in Prague are teh agreement of the WG on the
WG email list.
Yours,
Joel M. Halpern
At 07:08 PM 4/18/2007, Sam Hartman wrote:
It's reasonably common that I will t
Maybe I have misread the exchange.
But I do expect chairs to receive private comments about the state of things.
And to try to respond helpful to those comments when they can.
And I expect them to make use of that exchange to help the public conversation.
To use a current example, the chair of on
hould be open to hearing responses which may
change their view. But that does not change the fact that they are
expect to exercise judgement.
Yours,
Joel M. Halpern
At 03:17 PM 6/12/2007, Lakshminath Dondeti wrote:
Folks,
If you want the history of this thread, please see the SAAG mailing
r a BoF or two, we should expect an understandable explanation.
(BoF sponsorship is harder, but still refusal ought to be explained.)
Yours,
Joel M. Halpern
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
Clarification below.
At 06:16 AM 6/18/2007, Dave Cridland wrote:
On Mon Jun 18 08:30:00 2007, Simon Josefsson wrote:
> If you do believe the ABNF needs special licensing in
> this case, I am sorry to say that your remedy is not sufficient.
This
> document imports ABNF from other documents
Since the FAQ specifically says that code extracts can be modified,
and since RFC 3978 specifically gives us the right to modify code for
any purpose (explicitly not limited to the standards process) it
seems that we are already covered on this, and no extra or special
license is required.
(Se
working group was that there
was not a need to revisit the existing IETF patent policy. So the
chairs did not ask the IESG to consider making such a change.
Yours,
Joel M. Halpern
At 06:45 PM 10/19/2007, Lawrence Rosen wrote:
Ted Hardie wrote:
> Ah, I see why you appear to have changed y
r the registration needs that go with this document, I
strongly support publication.
Yours,
Joel M. Halpern
At 02:04 PM 10/26/2007, Randy Presuhn wrote:
Hi -
The existence of IPR claims potentially relevant to the implementation
of a specification has never been sufficient grounds to bloc
1 - 100 of 224 matches
Mail list logo
