I think Harald's suggestion makes sense and should be implemented.
Joel
Contreras, Jorge wrote:
Ok. So is the point then just not to have to issue a new RFC if the
Trust decides they want a different license? I.e. is that the
future-proofing that the proposed change is supposed to
XML2RFC normative and
mandatory. If they can figure out how to automatically and accurate
convert the other mechanisms people use, then that can be considered.
Otherwise, mandating would be inappropriate, as some folks do indeed
find it difficult.
Yours,
Joel M. Halpern
Iljitsch van Beijnum
Just so it does not get completely overlooked, I will point out that the
page numbers are also useful for the table of contents. And the ToC is
very helpful to me when I need to find something in the document. (Yes,
hyperlinks would help in many cases. But not all.) the ToC is also
helpful
There is an explicit list of what is automatically covered as code.
After discussion, that list does not (did not, the last time I checked)
include pseudo-code.
Document authors are free to mark their pseudo-code using the code
marker if they want it treated as code.
The problem, as far as I
it
would need to be quite general, not specific about nominees opinions on
any one dimension. And certainly not a list of thing on which the
nominee is not expressing an opinion in public.
Yours,
Joel M. Halpern
Stewart Bryant wrote:
Stephen Farrell wrote:
Something like: This is the list of those
While philosophically I agree with Brian, practically I have to disagree.
My reasoning is that while we don't want that sort of thing to happen,
the only enforcement mechanism is what the nomcom chooses to do. And
while I would hope that they would consider such misbehavior a negative,
I
to be
operable.
This does not mean we have to simply accept what they (OSP) say. But it
does mean we should give it a fair review, looking at the details,
rather than objecting on principle.
Yours,
Joel M. Halpern
Sam Hartman wrote:
Eric == Eric Rosen ero...@cisco.com writes:
Eric I don't
The changes described in your other note (copied after your text to
preserve context) are reasonable in the abstract. However, the devil is
in the details.
As I understand it, the reason for calling the extra note exceptional
is that the IESG has in the past sometimes used that note to place
I disagree Simon.
Free Software authors (for any variety of free software I know of) are
free to submit I-Ds describing protocols that they define.
They can not take their licensed code, with license restrictions, and
put it in the RFC.
The primary reason for this restriction, in my view, is
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
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
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
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 needed surprised me.
Yours,
Joel M. Halpern
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 IETF
. 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 be defined in
such a way
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
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 M. Halpern
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
-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
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
as a volunteer,
Joel M. Halpern
Once again, the IETF nominating process has begun, and the community
(and I) need your help. The IETF Nominating Committee appoints folks to
fill the open slots on the IAOC, the IAB, and the IESG. The people who
do that are 10 folks selected randomly from the pool
,
Joel M. Halpern
[EMAIL PROTECTED]
[EMAIL PROTECTED]
___
IETF-Announce mailing list
IETF-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-announce
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
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 require actionable comments.
Yours,
Joel M. Halpern
Ted Hardie wrote:
At 5:12 PM
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 and
reviewers of internet drafts. We would really appreciate it if you can
spend some time to go
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
reviewed several
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:
At 7:30 PM +0200 3/30/08, Simon
. Referencing the specific documents is
more restrictive than what the working group recommended. I don't see
why that would help anything.
Yours,
Joel M. Halpern
___
IETF mailing list
IETF@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
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 the problem you want addressed. The way
said it wants.
In the worst case, 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
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 perfect
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 that
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
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 07:18 PM 3/16/2008, Dave
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.
Please see some responses inline.
I
for IP Flow Information eXport (IPFIX) Testing
Reviewer: Joel M. Halpern
Review Date: 15-Feb-2008
IETF LC End Date: 26-Feb-2008
IESG Telechat date: N/A
Summary: This document needs some additional work before publication as
an informational RFC.
I would particularly recommend considering addressing
is near the forwarding element. I am not worried about
there being a NAT between those. So SCTP or DCCP over IP is very relevant.
Yours,
Joel M. Halpern
Jonathan Rosenberg wrote:
I wrote this because of a discussion that happened during behave at the
last IETF meeting in Vancouver
the advice remains the same. There is no drawback
to having it over UDP to start with - it works when there are no NAT,
and it can work when there are NAT.
-Jonathan R.
Joel M. Halpern wrote:
However, I would really like to reinforce the point from another note.
There are quite a few
My assertion wasn't that we can not implement (or even can not define)
such a thing, but that we had not done so. Thats why the constraint do
not design any new transports was an important part of the puzzle.
Dan Wing has pointed to an I-D that has started to fill that hole.
Yours,
Joel
Processing Application
Reviewer: Joel M. Halpern
Review Date: 6-January-2008
IETF LC End Date: 17-January-2008
IESG Telechat date: N/A
Summary: This document is nearly ready for publication as an information
RFC.
The first of the two comments below is probably primarily the IESG's
concern
I second John's note. When I saw Pasi's note, I had assumed that he
was referring to a link off of the tools page.
Replacing the tools page with an activity summary is quite surprising.
Joel
At 12:51 PM 11/2/2007, John C Klensin wrote:
--On Friday, 02 November, 2007 15:04 +0200 [EMAIL
, the page loading time is not an issue. But I think that it
is an issue for enough people that it at least should have been thought about.
Yours,
Joel
At 03:32 PM 11/2/2007, Henrik Levkowetz wrote:
Hi Joel,
On 2007-11-02 18:00 Joel M. Halpern said the following:
I second John's note. When I
for 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 block
of the 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 your
, 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.
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
list archive
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
, then 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 try
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 modules contain
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
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.org/mailman/listinfo
. 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 consensus
.
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 vote and can have
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 possible system
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 3777, the only recourse
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
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
by 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
are not.)
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 RFCs
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@ietf.org
https://www1.ietf.org
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 '
draft-ash-alt-formats-02.txt
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
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
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 discussing is draft-iab
,
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 the Acknowledgements
or Credits
ends, during IESG deliberations.
Yours,
Joel M. Halpern
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
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 document than a clean IETF
protocol framework.
I
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
somewhere (the framework document would seem the obvious
place) why there is a need for a new solution.
I am not claiming that the PANA protocol can't work. As was said
many years ago with sufficient thrust, pigs will fly. But that
does not make flying pigs a good thing.
Yours,
Joel M. Halpern
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
it will be
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
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
.)
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
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
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
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 manage the collection
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.
The
is 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
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@ietf.org
https
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
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 visiting countries we've
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
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
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, what does
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
.
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, sometimes
people break
.
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
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 like
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, Spencer Dawkins wrote:
If I may
.
But 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
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
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
, 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???
FWIW I'm also concerned that we are doing
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
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 sbrim@cisco.com
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
101 - 200 of 216 matches
Mail list logo
