The open source community definitely wants to be able to guarantee to
its users the ability to take text or code from an IETF standard and
use that text or code in derivatives of that standard. Parts of the
open source community want to be able to claim that that standard is
the real unmodified
Hi Patrice,
I noticed the Internet-Draft that you posted regarding IETF
Administrative Restructuring, and I have a few comments on it,
speaking as one interested member of the IETF community to another.
For those who have not seen Patrice's draft, it can be found at:
Not to pick on Eliot in particular... This message is really
addressed to everyone who has said I trust the leadership to decide:
At 2:30 PM +0200 9/28/04, Eliot Lear wrote:
Just to be clear, I trust the leadership to decide better than I
can. I don't know about the rest of you, but I have a
Hi Bert,
Both you and Ted have posted preferences for Scenario C that, to me,
seem to say We will eventually have to go to Scenario C, anyway, so
we should undertake that effort today rather than leaving it for
later. This might be a compelling argument if it were clear to me
that we will
Hi Tony,
Great feedback. Thanks! A few comments in-line:
At 1:08 AM -0700 9/23/04, Tony Hain wrote:
2.1.4 - 6 months for the reserve is a funny number for an organization where
the nominal income period is 4 months. Wouldn't it make more sense to spell
out a reserve that covered a disaster case
Hi Joel,
At 10:35 AM -0400 9/23/04, Joel M. Halpern wrote:
Two minor comments:
1) The references to the IASF bank account should probably be
relaxed to IASF fund accounts or IASF accounts. As written, it
presumes that there is exactly one bank account, and that separation
of funds is by bank
Hi Harald,
At 12:04 PM +0200 9/21/04, Harald Tveit Alvestrand wrote:
I've seen some argument that Scenario C, being more well-defined, is
actually less complex than Scenario O.
I share Brian's belief that Scenario C is more complex. The document
for Scenario C currently focuses on the mechanics
Hi Harald,
As you say below, clarity is good. So, before I respond to this
post, I would like to better understand what you are asking...
RFC 3716 includes the following section:
4.3. Who Can Decide
The AdvComm believes that the IETF leadership, acting with the advice
and consent of the
In my previous response, I think I missed one important implied
questions in your message:
3 - The community has accepted the problem description and
principles laid out in RFC 3716.
I'll interpret this statement as a question:
As a member of the community, do I personally agree with the
Hi Scott,
At 5:06 PM -0400 9/11/04, scott bradner wrote:
imo it would least disruptive to follow option #3 (combo path)
and try to negotiate a sole source contract with Foretec/CNRI for
what Carl called the clerk function and maybe some other functions
(imo it would be better to outsorce the
Hi Pete,
At 6:17 PM -0400 9/8/04, Margaret Wasserman wrote:
To date, there has been no proposal, in Carl's document or
otherwise as far as I know, for *the IETF* to incorporate as a
separate entity. There have been proposals to incorporate a body to
deal with IETF administrative functions (like
I believe that the difference between what Avri is discussing and
what is discussed in Carl's draft is that Avri is talking about
incorporating the IETF (the standards function), either as part of
ISOC or as an independent entity, not just the administrative support
function. Carl's draft
Putting an MoU-like agreement on the table could shift the center
of gravity of the responsibility for the future of the administrative
activity further from the centre of the ISOC organization. The
further out it gets, the less sense it makes to undertake
(anything like) the other mechanisms in
Hi Graham,
I'd like to make a couple of comments on your post -- not to argue
with you (because I think we are in basic agreement), but just to
clarify my earlier comments.
At 12:31 PM +0100 9/6/04, [EMAIL PROTECTED] wrote:
4. However, Margaret has written about problems with existing
Hi Harald,
At 9:32 AM +0200 9/6/04, Harald Tveit Alvestrand wrote:
These BCPs are the IETF's expectations on IETF behaviour. They
cannot constrain the behaviour of ISOC, unless ISOC makes an explict
commitment by Board resolution to do so, as it has done for its
roles in the standards process,
Hi All,
Like most people who have been involved in these discussions over the
past couple of years, I have my own personal views on the core
problems facing the IETF's administrative support functions and what
we should do to resolve them.
As we have worked through these issues, it has become
and a technical Security Tutorial.
All of these sessions are open to any IETF participant. So, if you
will be in San Diego on Sunday afternoon, I hope you will attend!
Thanks,
Margaret
---
Sunday, August 1, 2004
===
1300-1400 Newcomer's Training -- Grande Ballroom A (Margaret Wasserman
editor, and includes advice on
producing a high-quality IETF specification.
1300-1500 Intro WG Chairs Training -- Location?? (Margaret Wasserman)
Introductory training for new or aspiring WG
chairs. Covers the role and responsibilities of
a WG chair
I'm not sure when we started doing it, but we've been doing
a security tutorial on Sunday afternoon for a good number of IETFs..
Just to make sure of maximum access to machines on the temporary
ops.ietf.org network;) Make sure to use telnet and pop3 so cleartext
passwords are passed
In fact, if you go back to the archives of the 1992
discussions, it was perceived then that the previous
structure did not scale. For example, the IAB was in
charge of reviewing every RFC before it could be
published, and as the number of WG increased that
became a bottleneck. A lot of
Excuse me, but could you please constrain this
conversation to fewer than 9 (nine!) e-mail lists?
The BOF description lists [EMAIL PROTECTED] as the
discussion list, but this discussion is being
cc:ed to [EMAIL PROTECTED] I'd suggest that you
move this discussion to whichever of those lists
is
Hi Bill,
Are these RSVP meetings ?
Can I forward this to my WG mailing list and suggest participation to
people that are interested ??? (ie. How big is the room you are
reserving ?)
No RSVPs are required.
All of the rooms will hold 100 or more people. Given previous
attendance at
Hi Scott,
Similarly for almost all of the rest. What's the point? Are you
reiterating the problem-statement work? They're doing all right,
although perhaps you could help push the work to completion. It would
be much more useful for you to reaffirm the fundamental
principles that are
Hi Scott,
But, for what it's worth, I do not think that there was sufficient
discussion of the option of deprecating SL addresses before
the consensus check was made. So, in a way, I think the consensus
was wrongly reached, even if I agree that consensus was reached.
If the San Francisco
Hi Fred,
So in the general case I don't see a problem with deprecating
things under the right circumstances, but I do have a problem with
removing them outright. Deprecation doesn't prevent people from using
them, but outright removal can be dangerous. And in this case, the
assertion
Hi Scott,
Speaking only for myself, I would like to address a couple of the
points that you have made.
It is my opinion that there is a difference between a working group
deciding to adopt a technology and a working group deciding
to delete a technology from an existing IETF
The second is the side point I raised with Margaret: in the
general case of things in specifications, removing something
from a specification does not mean that someone can still use
it. Deprecation protects such a usage, but removal does not.
Scott's posting made a distinction between
included editor training, programs to help non-North Americans
become acclimated to the IETF, and mentoring programs for new
attendees.
The second half of the meeting focused on how to organize and
manage our internal educational efforts moving forward.
Margaret Wasserman presented a proposal
Hi John,
But suppose we really do have enough address space (independent of routing
issues). In that context, is site local just a shortcut to avoid dealing
with a more general problem? Should we have a address allocation policy
that updates the policies of the 70s but ignores the
Which actually poses an interesting question: when should an application
just give up? IMHO, there is only one clear-cut case, i.e. when the
application actually contacted the peer and obtained an explicit
statement that the planned exchange should not take place -- the
equivalent of a 4XX or
Hi Tony,
At 11:51 AM 3/31/2003 -0800, Tony Hain wrote:
Margaret Wasserman wrote:
Of course, in the case of site-local addresses, you don't
know for sure that you reached the _correct_ peer, unless you
know for sure that the node you want to reach is in your
site.
Since the address block
At 03:49 PM 3/27/2003 -0800, Tony Hain wrote:
Margaret Wasserman wrote:
No active IPv6 WG participant (whether or not he attends IETF
meetings) could credibly claim that he was unaware that this
discussion was taking place,
The discussion has been about potential usage limitation, or BCP's
,
and each of the four options had some support in that WG meeting.
And in Atlanta we all agreed to take elimination off the list, and it
has not been discussed since. The agenda for SF was:
Site-Local Addressing
Impact of site-local addressing -- Margaret Wasserman (20 min)
http://www.ietf.org
Hi Harald,
At 09:10 PM 3/14/2003 +0100, you wrote:
On Wednesday at the IESG plenary, I'm doing a presentation about IETF
financials.
I have a few questions and comments on this presentation.
Do we have a real budget for 2003? Or are the numbers for
2003 based on the projection information (from
What about South America and India. I've heard that both are
substantially less expensive than the US/Europe/Japan for
vacation accomodations. Does the same hold for convention costs?
Margaret
At 11:57 AM 3/16/2003 +0100, Tomson Eric \(Yahoo.fr\) wrote:
Brussels is the less expensive major
Thanks to Jim Galvin:
ftp://ftp.tislabs.com/pub/lists/poised
I can't access this URL (apparent permissions problem),
do others experience the same problem?
Margaret
Some comments on the process...
I have specific comments on the document, but I will send them
separately.
At 04:10 PM 3/7/2003 +0100, Harald Tveit Alvestrand wrote:
in December, I published an internet-draft called
draft-iesg-charter-00.txt, containing a proposed text for an IESG charter.
A
Hi All,
We have a proposal available for a new configuration protocol
that may be of interest to folks on these lists. The proposal
has been published an an I-D, and can be found at:
http://www.ietf.org/internet-drafts/draft-enns-xmlconf-spec-00.txt
We believe that this proposal addresses
There will be a BOF on the subject of XML network configuration held
at IETF54 in Yokohama. A more detailed description is attached below.
Margaret
XML Configuration BOF [xmlconf]
===
Chair: Margaret Wasserman [EMAIL PROTECTED]
Description
Hi All,
A mailing list has been set-up to discuss topics related to the XML
Configuration BOF that will be held in Yokohama. Please subscribe
to this list if you are interested.
Mailing List: [EMAIL PROTECTED]
Archive URL: http://ops.ietf.org/lists/xmlconf/
To subscribe, send mail to
Sorry that I wasn't more specific. I wasn't objecting to
the idea of work being done in a bar...
I think that we need to be careful about the assumption
that everyone we haven't seen before, or that doesn't
speak at a meeting, is a "tourist". If we want to have
an open organization, we
Not to pick on Jon specifically, but how is this common IETF
attitude consistent with the IETF's stated commitment to
open process?
At 06:52 AM 3/23/01 , Jon Crowcroft wrote:
also,the wireless access fro mthe pub was inspired! we got really
serious bar bof work done without tourists
201 - 242 of 242 matches
Mail list logo
