--On torsdag, desember 02, 2004 00:54:07 +0100 [EMAIL PROTECTED] wrote:
On 1 dec 2004, at 22.35, Sam Hartman wrote:
I had sort of assumed this BCP would be the MOU to the extent that one
existed.
I think that there has to be an equivalent document on the ISOC side as
indicated by Geoff, i.e. a doc
At Wed, 1 Dec 2004 23:44:35 -0500 (EST), Scott Bradner wrote:
>
> lots of left over references to a seperate account
Scott,
Thanks for all the notes.
Regarding all the places where you think we forgot to remove the word
"account": there's more than one kind of account, and I think you're
confu
Scott,
draft-ietf-iasa-bcp-01 section 3.5 goes on to say:
Decisions of IAOC members or the entire IAOC are subject to appeal
using the procedures described in RFC 2026 [RFC2026]. Appeals of
IAOC decisions go first to the IESG, then continue up the chain as
necessary to the IAB and the ISO
lots of left over referenmces to a seperate account
Scott
___
Ietf mailing list
[EMAIL PROTECTED]
https://www1.ietf.org/mailman/listinfo/ietf
section 7 says
IETF meeting fees shall be deposited
in a separate IETF-specific financial account
left over referenmce to seperate account
Scott
___
Ietf mailing list
[EMAIL PROTECTED]
https://www1.ietf.org/mailman/listinfo/ietf
should be in sync with Section 2.2(7)
Scott
___
Ietf mailing list
[EMAIL PROTECTED]
https://www1.ietf.org/mailman/listinfo/ietf
section 5.4 says
ISOC will credit the appropriate IASA accounts at
east quarterly.
1/ left over referenmce to seperate account
2/ dumb to put money in quarterly for a load that is 3 times per year
suggestion - remove
Scott
___
Ietf mailing list
section 5.3 goes on to say
Designated monetary
donations will be credited to the appropriate IASA account.
a left over reference to a seperate account
Scott
___
Ietf mailing list
[EMAIL PROTECTED]
https://www1.ietf.org/mailman/listinfo/ietf
section 5.3 says
In particular, it is important that
in-kind contributions be "useful".
note that this is addressed in section 2.2(5) - what it says there
should be here or just remove this and let section 2.2(5) rule
Scott
___
Ietf mailing lis
section 5 starts out saying
The IASA manages money from three sources:
1. IETF meeting revenues.
2. Designated donations to ISOC (both monetary and in-kind).
3. Other ISOC support.
then goes on to say
Note that the goal is to achieve and maintain a viable IETF suppo
draft-ietf-iasa-bcp-01 section 4 also says
The members of the IAOC choose their own chair each year using a
consensus mechanism of their choosing. Any appointed voting member
of the IAOC may serve as the IAOC Chair; the IETF Administrative
Director, the IETF Chair, the IAB Chair, the
draft-ietf-iasa-bcp-01 section 4 says
o 2 members chosen by the IETF Nominations Committee (NomCom)
o 1 member chosen by the IESG
o 1 member chosen by the IAB
o 1 member chosen by the ISOC Board of Trustees
later in section 4 it says:
Appointed members of the IAOC serve
draft-ietf-iasa-bcp-01 section 3.5 goes on to say:
Decisions of IAOC members or the entire IAOC are subject to appeal
using the procedures described in RFC 2026 [RFC2026]. Appeals of
IAOC decisions go first to the IESG, then continue up the chain as
necessary to the IAB and the ISOC B
draft-ietf-iasa-bcp-01 section 3.5 says
The IAOC attempts to reach all decisions unanimously. If unanimity
cannot be achieved, the IAOC chair may conduct informal polls to
determine the consensus of the group. In cases where it is
necessary, some decisions may be made by voting. For
> I'm also slightly surprised by this perspective (a distinct MoU). I had
> though that the process we were following was that this IASA BCP would be a
> document that was formally accepted by both the IETF (through the BCP
> publication process) and by ISOC (possibly through a formal resolution of
draft-ietf-iasa-bcp-01 asks:
The IAOC, in consultation with the IAB and the IESG, designates the
person or people who carry out the tasks which other IETF process
documents say are carried out by the IETF Executive Director.
Editors' note: The preceding paragraph has generated some
draft-ietf-iasa-bcp-01 section 3.4 says
3.4 Relationship of the IAOC to Existing IETF Leadership
The IAOC is directly accountable to the IETF community for the
performance of the IASA. However, the nature of the IAOC's work
involves treating the IESG and IAB as internal customers. Th
the new draft asks:
Do we need wording about the ownership of IETF tools and data? We
have some text (in Section 2.2) about IPR, but does that fully
cover tools and data?
fwiw - my intention in the text that is now 2.2(6) was to cover the
tools and data
Scott
__
On 1 dec 2004, at 22.35, Sam Hartman wrote:
I had sort of assumed this BCP would be the MOU to the extent that one
existed.
I think that there has to be an equivalent document on the ISOC side as
indicated by Geoff, i.e. a document indicating acceptance of the BCP as
governing the relationship.
> "Margaret" == Margaret Wasserman <[EMAIL PROTECTED]> writes:
Margaret> At 3:41 PM +0100 12/1/04, Brian E Carpenter wrote:
>> Yes, I've always assumed there will be an MOU between IETF and
>> ISOC, both to recognize the BCP when we have it, and to make
>> explicit some of thes
It's not yet hit the i-d-announce list, but it's in the repository:
draft-ietf-iasa-bcp-01 has been published.
The HTML version and two versions of diff files are available from the
adminrest homepage: http://www.alvestrand.no/ietf/adminrest/
Note: The document went through an extensive languag
At 04:34 AM 2/12/2004, Margaret Wasserman wrote:
At 3:41 PM +0100 12/1/04, Brian E Carpenter wrote:
Yes, I've always assumed there will be an MOU between IETF and ISOC,
both to recognize the BCP when we have it, and to make explicit some
of these boundary conditions.
This is interesting, because I
>
> At 3:41 PM +0100 12/1/04, Brian E Carpenter wrote:
> >Yes, I've always assumed there will be an MOU between IETF and ISOC,
> >both to recognize the BCP when we have it, and to make explicit some
> >of these boundary conditions.
>
> This is interesting, because I had not assumed that there wou
At 3:41 PM +0100 12/1/04, Brian E Carpenter wrote:
Yes, I've always assumed there will be an MOU between IETF and ISOC,
both to recognize the BCP when we have it, and to make explicit some
of these boundary conditions.
This is interesting, because I had not assumed that there would be a
separate M
Carl Malamud wrote:
Carl asks:
how about
The IETF is a consensus-based group and authority to act on behalf
of the community is an act that requires a high degree of consensus
and the continued consent of the community
After a careful process of deliberation, there is a broad-based
Bernard Aboba wrote:
Jon Peterson said:
"I think there is a concern in the community that the IETF needs some way
to ensure that it is not "locked in" to any solution we adopt at this
stage."
If this is the problem that we are attempting to address, then the
document needs to articulate the princip
Spot on, Rob. At this point I think the editors should be working
on what to remove from the document - it has far too much detail
for a process with which we have no experience. Spelling out
the organizational relationships and the high level principles
is hard enough. Can we hope to see a much sh
Catching up...
scott bradner wrote:
Carl suggests:
How about this instead:
Although the approval of the ISOC President/CEO or ISOC Board of
Trustees may be required for some contracts, in order to provide
a single point of focus in support of the IASA, primary responsibility
for the evaluation, re
On 1-dec-04, at 1:06, Stephen Sprunk wrote:
With v6 we have the ability to fix this; through some magic function,
users should be able to get a PA (at a minimum) subnet behind their
local router/modem/whatever and have a decent interface to configure
inbound filters, similar to how they can conf
On 1-dec-04, at 1:17, Stephen Sprunk wrote:
So _if_ IPv6 PI space is going to be a reality, we should do what we
can to limit the damage. The only way to do this is to make it
possible to filter out the PI prefixes at least in certain parts of
the network without getting in the way of reachabili
30 matches
Mail list logo