Here's a version of what the explosive bolts could look like.
Firstly, note that the IETF (*not* the ISOC) signed an MOU
with ICANN on March 1st 2000. Fred Baker signed it as IETF Chair,
I signed it as IAB Chair, and Mike Roberts signed it as ICANN
President. The IETF lawyer and the ICANN lawyer
[EMAIL PROTECTED] wrote:
On 6 sep 2004, at 07.31, [EMAIL PROTECTED] wrote:
2. I think that we shouldn't broaden the discussion at this time ( as
Avri suggested ), on the grounds of keeping things simple.
I understand the desire to keep thing simple and that Carl is attempting
a simple fix to a
Greetings,
on August 16, I sent out a call for volunteers for sergeants-at-arms for
the IETF mailing list.
I got a number of qualified volunteers (thank you all!), and from the
volunteers I have picked two:
- Theodore Ts'o [EMAIL PROTECTED]
- Jordi Palet Martinez [EMAIL PROTECTED]
(The fact
On 7 sep 2004, at 02.13, Brian E Carpenter wrote:
[EMAIL PROTECTED] wrote:
I'm very puzzled. I though those two extremes were exactly described
by scenarios A and D.
Perhaps I misread, but while I saw that A and D are the extremes of the
scenarios represented to date, I was suggesting is that
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
Hi. First I'd like to start off by saying that I think Carl's
document is a very good start for discussing these options.
I support the recommendations made in section 3. I believe they are
well justified and would be a great step in the right direction.
Section 3 talks about clarifying the
Scott et al.,
Pete makes a good point.
In his scenario, not only the Administrative Czar would need explosive
bolts, but also the RFC Editor and Secretariat, etc. That presumably
would mean restructuring the existing RFC Editor relationship ( which
works well ), as well as the Secretariat
With reference to:
http://www.ietf.org/internet-drafts/draft-malamud-consultant-report-00.txt
I found this to be an interesting read, conveying many points of which I
was not previously aware. At this stage, I feel able merely to comment on
some aspects of the document, not having
In his scenario, not only the Administrative Czar would need explosive
bolts, but also the RFC Editor and Secretariat, etc.
that depends on the contracts with those suppliers - if the contract
is signed by the IETF chair or the admin czar for the IETF (rather than
for the ISOC) I would not
Exopounding on your last thought. I think it is very important that we come
up with a central portal for this network of organizations that can provide
a roadmap and point lay persons in the right direction. Even a unified
search engine which comvers all of the sites would be useful. I think the
[Sorry if you see this announcement more than once.]
Folks-
The ICAR WG is soliciting reviewers for an early, cross-area review
experiment within the IETF. The goal of this effort is to get solid
review from a number of angles (security, internationalization,
transport, MIB know-how, etc.)
[EMAIL PROTECTED] (Brian E Carpenter) writes:
...
Firstly, note that the IETF (*not* the ISOC) signed an MOU with ICANN on
March 1st 2000. Fred Baker signed it as IETF Chair, I signed it as IAB
Chair, and Mike Roberts signed it as ICANN President. The IETF lawyer
and the ICANN lawyer were
Greetings. Susan Harris and I have begun another round of work on
The Tao of the IETF, RFC 3160. The new version is at
http://www.ietf.org/internet-drafts/draft-hoffman-taobis-00.txt.
We would like to get comments and suggestions on how to make this
document as useful as possible for newcomers
like many things outside the core technical field, these things are hard,
and harder than they look, and hard enough that you need a better lawyer.
as long as IETF remains an unincorporated association, i think you need
every new IESG and IAB member to add their signature to all current MoU's
On Sep 5, 2004, at 4:15 PM, Sam Hartman wrote:
I do not think that recommendation 7 in scenario B is a good idea. I
believe that plenary time is full enough without crowding it more.
What about a 'business meeting' that is scheduled in wg slot or even on
Sunday?
I understand that there may be
Aaron == Aaron Falk [EMAIL PROTECTED] writes:
Aaron On Sep 5, 2004, at 4:15 PM, Sam Hartman wrote:
I do not think that recommendation 7 in scenario B is a good
idea. I believe that plenary time is full enough without
crowding it more.
Aaron What about a 'business
I think a doc like this should certainly be prominently featured somewhere,
maybe even under the title, on our webpage. Whatever way anyone could come
up with to get someone to read background on the org before blindly
searching for an RFC or posting to a list would probably help A LOT of
people.
I'd like to provide one point of important clarification:
the ISOC trustees appointed by the IETF do *not* represent the IETF.
So, while I agree firmly that the IETF's relationship to ISOC is
closer than the IETF's relationship to any other organization,
I disagree strongly that the IETF has a
At 7:57 PM +0200 9/6/04, Harald Tveit Alvestrand wrote:
It seems to me that we are rapidly converging on one point of total IETF
consensus:
Putting the IETF administrative function under ISOC requires a documented
IETF-ISOC agreement (call it an MoU, a contract or something else - it IS
a
YeahI blew it.trying to do two things at once. I meant it in the
context of my comment earlier today:
Exopounding on your last thought. I think it is very important that we come
up with a central portal for this network of organizations that can provide
a roadmap and point lay persons in
Leslie,
Thanks. Your basic point is well taken, but I think there are two
important additional layers. As you said, the IETF's appointees to the
ISOC board function first and foremost as ISOC board members, not as
IETF's representatives. This is the same for all the board members.
The IETF
Putting the IETF administrative function under ISOC requires a
documented IETF-ISOC agreement (call it an MoU, a contract or
something else - it IS a document, it IS an agreement and it DOES
have two parties).
Its easy to identify the first party to this MoU - its ISOC, but, in a
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
leslie sez:
In my reading of Scenarios A B, the suggestion
is that ISOC takes on the administrative work more-or-less
directly.
takes on the admin work or contracts vendors to do the admin work
i.e., the difference between hiring people and paying vendors
it might make a difference if bolt
As many will remember from the IETF 58 plenary presentation, I'm
a big fan of functional differentiation. Though I try not to be
dogmatic in its application, I believe there are a lot of cases where
the creation of well-focused groups with limited goals is more
successful than the creation of
I'll add one point. Many of the ISOC's organizational members
(http://www.isoc.org/orgs/, http://www.isoc.org/orgs/orgsbytype.shtml) are
companies that employ IETF participants or are otherwise related to the
standards process. The IETF is near and dear to their hearts as well, often
very
Ted,
Let me try to briefly start from your assumptions and explain
why one might reach the opposite conclusion. Before I go on,
I'm assuming that your conclusion really implies organization
separate from ISOC rather than separate organization within
some ISOC framework. There are scenarios for
The IESG has approved the following document:
- 'IANA Registration for ENUMservices web and ft '
draft-ietf-enum-webft-01.txt as a Proposed Standard
This document is the product of the Telephone Number Mapping Working Group.
The IESG contact persons are Allison Mankin and Jon Peterson.
The IESG has approved the following document:
- 'Textual Conventions for Internet Network Addresses '
draft-ietf-ops-rfc3291bis-06.txt as a Proposed Standard
This document has been reviewed in the IETF but is not the product of an
IETF Working Group. This document obsoletes RFC 3291.
The
The IESG has approved the following document:
- 'T11 Network Address Authority (NAA) naming format for iSCSI Node Names '
draft-ietf-ips-iscsi-name-ext-05.txt as a Proposed Standard
This document is the product of the IP Storage Working Group.
The IESG contact persons are Allison Mankin and
30 matches
Mail list logo