Re: iasa-bcp-01 - Open Issues - Pre-nuptials

2004-12-02 Thread Scott Bradner
> It's kind of a good fences makes good neighbors kind of thing. but Frost was arguing just the reverse http://www.bartleby.com/118/2.html (in case anyone is confused - in pointing the above out I am not saying anything about the need for a Pre-nup agreement in this case - just showing I read

Re: Adminrest: created IPR

2004-12-02 Thread Scott Bradner
> I did postfix "whenever possible" and prefix "as a matter of > principle" ... this simply says if you're not going to do it > v another thing to appeal ? :-) Scott ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf

Re: Adminrest: created IPR

2004-12-02 Thread Carl Malamud
Scott - I did postfix "whenever possible" and prefix "as a matter of principle" ... this simply says if you're not going to do it that way, please have a reason. Regards, Carl > > Carl suggests: > > 2.2.6 currently reads: > > > The right to use any intellectual property rights created by a

Re: Adminrest: section 3.5b (appealability)

2004-12-02 Thread Joel M. Halpern
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

Re: Adminrest: created IPR

2004-12-02 Thread Scott Bradner
Carl suggests: > 2.2.6 currently reads: > The right to use any intellectual property rights created by any > IASA-related or IETF activity may not be withheld or limited in > any way by ISOC from the IETF. > > You could simply append: > > As a matter of principle the IAOC and IAD should ens

Re: Adminrest: created IPR

2004-12-02 Thread Carl Malamud
2.2.6 currently reads: The right to use any intellectual property rights created by any IASA-related or IETF activity may not be withheld or limited in any way by ISOC from the IETF. You could simply append: As a matter of principle the IAOC and IAD should ensure that any contracts for IAS

Re: Adminrest: IASA BCP: Separability

2004-12-02 Thread Geoff Huston
At 10:54 AM 2/12/2004, [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 document indicating accepta

Re: iasa-bcp-01 - Open Issues - Startup Phase

2004-12-02 Thread Scott Bradner
> BTW, are the ISOC minutes all public? yes - see http://www.isoc.org/isoc/general/trustees/documents.shtml as is the normal case, some issues (like personnel issues) that come up in BoT meetings are not made public but that is rare > And how long do they take to show up it varies, not as fas

Re: iasa-bcp-01 - Open Issues - Startup Phase

2004-12-02 Thread Scott Bradner
> It is a small thing, but on something this important, I would like to > see a formal statement of acceptance and not rely on minutes. I do not > understand why asking for a response document committing the ISOC BOT > to the BCP is a problem? I quite specifically did not comment on that sugge

Re: iasa-bcp-01 - Open Issues - Startup Phase

2004-12-02 Thread avri
On 2 dec 2004, at 23.00, Scott Bradner wrote: This leaves any minuted decision in limbo for another meeting interval. I do not understand - in all boards I've been a part of the decision is the decision, the minutes just report the decision - it does not matter when the minutes get approved, the de

RE: The gaps that NAT is filling

2004-12-02 Thread Michel Py
> Stephen Sprunk wrote: > Clearly, if IPv6 PI space spirals out of control like many > operators think will happen, we need to find a way to make > BGP (and possibly forwarding) performance not dependent on > the number of prefixes in the table. I agree 100%, but this is easier said than done: if

Re: iasa-bcp-01 - Open Issues - Pre-nuptials

2004-12-02 Thread Eric Rescorla
[EMAIL PROTECTED] writes: > I tend to think that we should go into this arrangement with an > attitude of trust. Certainly we should try to get the document as > specific and accurate as possible, and should leave open the process > for future updates to the BCP, but I do not think we need explos

Re: iasa-bcp-01 - Open Issues - Startup Phase

2004-12-02 Thread Scott Bradner
> This leaves any minuted decision in limbo for another > meeting interval. I do not understand - in all boards I've been a part of the decision is the decision, the minutes just report the decision - it does not matter when the minutes get approved, the decision was made when teh decision was m

Re: Adminrest: section 5

2004-12-02 Thread Carl Malamud
Works for me to. > Harald suggests > Suggested edit: Change > > > Note that the goal is to achieve and maintain a viable IETF support > > function based on meeting fees and designated donations. The IETF > > community expects the IAOC and ISOC to work together to attain that goal, > >

RE: Adminrest: more on sec 7

2004-12-02 Thread Wijnen, Bert (Bert)
W.r.t. > > I think a global s/deposited in/credited to/ will do the > right thing, given > Rob's explanation of "divisional accounting", and using > "account" in the sense of "what's accounted for". > This seems obvious, and I knew we had to re-check for consistency after we changed the text f

RE: Adminrest: section 3.4

2004-12-02 Thread Wijnen, Bert (Bert)
Can we have other peoples opinion on this topic as well? Bert > -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > Sent: Thursday, December 02, 2004 16:31 > To: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] > Subject: RE: Adminrest: section 3.4 > > > > So

RE: Adminrest: section 4 B

2004-12-02 Thread Wijnen, Bert (Bert)
Scott writes: > > 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

Re: Adminrest: IASA BCP: Separability

2004-12-02 Thread JFC (Jefsey) Morfin
At 09:11 02/12/2004, Brian E Carpenter wrote: Yes. I have a feeling that even with the BCP approved by the IESG and by an ISOC Board motion, we would still need a piece of paper with ink signatures - it might only say that the IETF and ISOC agree to the terms of the BCP - it might also contain term

Re: Adminrest: created IPR

2004-12-02 Thread Henrik Levkowetz
on 2004-12-02 9:58 am Brian E Carpenter said the following: > Scott Bradner wrote: >> 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 -

Re: Adminrest: IASA BCP: Separability

2004-12-02 Thread Carl Malamud
> Yes. I have a feeling that even with the BCP approved by the IESG > and by an ISOC Board motion, we would still need a piece of paper with > ink signatures - it might only say that the IETF and ISOC agree to the > terms of the BCP - it might also contain termination clauses about > money and IPR,

Re: Adminrest: section 5

2004-12-02 Thread Lynn St.Amour
Harald, Scott, This is much better and gives a good degree of flexibility. Regards, Lynn At 11:31 AM +0100 12/2/04, Harald Tveit Alvestrand wrote: I don't think there is any principle in 2.2 that forms a basis for saying that we need to aim towards limiting IETF support to meeting fees and design

Re: Adminrest: more on sec 7

2004-12-02 Thread Lynn St.Amour
Harald, yes, that would read much better and is closer to what I believe our combined intent was/is. Regards, Lynn At 11:23 AM +0100 12/2/04, Harald Tveit Alvestrand wrote: I think a global s/deposited in/credited to/ will do the right thing, given Rob's explanation of "divisional accounting",

RE: Adminrest: section 5

2004-12-02 Thread Scott Bradner
> Would it not be nice if ISOC could sort of designate a yearly > amount to go to IETF instead of having to just cough up whatever > budget gap we seem to have? yes but that is unrelated to my comment which only delt with the fact that the text seems to rule out ISOC support from sources other th

RE: Adminrest: section 4

2004-12-02 Thread Scott Bradner
> I also am thinking to change text (a little bit futher down) > from >The two NomCom-selected IAOC members > into >The two NomCom-appointed IAOC members good catch Scott ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/li

RE: Adminrest: section 3.4

2004-12-02 Thread Scott Bradner
> So in light of this, would you still suggest your change of text? yes - I read the text as a specific instruction to the IAOC to implement the begining of the paragraph - i.e. its not enough that the IESG & IAB are OK with the support they are getting they have to consider the support the whole

RE: Adminrest: section 4

2004-12-02 Thread Wijnen, Bert (Bert)
Makes a lot of sense to me. Consider it done. I also am thinking to change text (a little bit futher down) from The two NomCom-selected IAOC members into The two NomCom-appointed IAOC members Bert (speaking as editor) > -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PR

RE: Adminrest: section 5

2004-12-02 Thread Wijnen, Bert (Bert)
Personal opinion. Would it not be nice if ISOC could sort of designate a yearly amount to go to IETF instead of having to just cough up whatever budget gap we seem to have? Bert > -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of > [EMAIL PROTECTED] > Sent:

RE: Adminrest: section 3.5

2004-12-02 Thread Wijnen, Bert (Bert)
Scott writes: > > 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 m

iasa-bcp-01 - Open Issues - Pre-nuptials

2004-12-02 Thread avri
I tend to think that we should go into this arrangement with an attitude of trust. Certainly we should try to get the document as specific and accurate as possible, and should leave open the process for future updates to the BCP, but I do not think we need explosive bolts or any other prearran

iasa-bcp-01 - Open Issues - Startup Phase

2004-12-02 Thread avri
Not sure if this refers to what I said in an earlier not about indicating when the process goes into effect. Harald indicated that process BCP approval is indicated by an indication in the ISOC BoT minutes that the BCP was acceptable. I have a slight problem with minutes as the criteria. In b

RE: Adminrest: section 3.4

2004-12-02 Thread Wijnen, Bert (Bert)
Scott writes: > > 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

iasa-bcp-01 - Open Issues - Separate bank accounts

2004-12-02 Thread avri
In thinking about this, I think about the fungibility of funds. By having a common account, cash flow issues that might be an issue at various points of the year can be dealt with more easily. For example if funds are earmarked for meeting fees, but collections have not come in time for the yea

Re: Adminrest: section 3.5b (appealability)

2004-12-02 Thread avri
I tend to feel that both the decisions of the IAD and of the IAOC should be appealable. My thinking tends toward thinking that anyone should be able to appeal the decision, or any practice including the accounting practices, of the IAD. I believe we are defining high standards of transparency,

Re: AdminRest: section 5.3 B

2004-12-02 Thread Sam Hartman
> "Scott" == Scott Bradner <[EMAIL PROTECTED]> writes: Scott> section 5.3 goes on to say Designated monetary donations Scott> will be credited to the appropriate IASA account. Scott> a left over reference to a seperate account To me this doesn't imply bank accounts; internal acco

Re: The gaps that NAT is filling

2004-12-02 Thread Mark Thompson
On Dec 02, 2004, at 11:11, Mark Miller wrote: Using BitTorrent and the growing popularity of VoIP comes to mind. (A shame that Asterisk does not currently support IPv6 though.) Asterisk community is seeing some effort (particularly from someone quite familiar to the IETF: Marc Blanchet), and folk

Re: Adminrest: section 3.5b

2004-12-02 Thread Spencer Dawkins
Brian suggests: Maybe we need a much more restricted right of appeal. Strawperson: Decisions of the IAOC are subject to appeal exclusively on the grounds that they have materially damaged correct execution of the IETF standards process [RFC2026]. They follow the appeals process applicable to

Re: Adminrest: section 3.5

2004-12-02 Thread Sam Hartman
> "Scott" == Scott Bradner <[EMAIL PROTECTED]> writes: Scott> but as I said before - I expect we will be close to failure Scott> if the IAD proceeds on the basis of a close vote in the Scott> IAOC. I'd rather that mininum vote required to proceed (in Scott> those cases where a

Re: Adminrest: section 5

2004-12-02 Thread Scott Bradner
Harald suggests Suggested edit: Change > Note that the goal is to achieve and maintain a viable IETF support > function based on meeting fees and designated donations. The IETF > community expects the IAOC and ISOC to work together to attain that goal, > and recognizes that doing so wi

Re: Adminrest: more on sec 7

2004-12-02 Thread Scott Bradner
Harald suggestes: > I think a global s/deposited in/credited to/ will do the right thing, I woke up this am having decided in my sleep (not a good sign in and of itself) to suggest the same thing Scott ___ Ietf mailing list [EMAIL PROTECTED] https://ww

Re: Adminrest: section 3.5b

2004-12-02 Thread Scott Bradner
Brian suggests: Maybe we need a much more restricted right of appeal. Strawperson: Decisions of the IAOC are subject to appeal exclusively on the grounds that they have materially damaged correct execution of the IETF standards process [RFC2026]. They follow the appeals process applicabl

AdminRest: Timeline status

2004-12-02 Thread Harald Tveit Alvestrand
At the plenary, we showed the following dates for further work: - Revised BCP document: December 1 - Last Call: December 1 to December 28 - IESG approval: January 6 As many probably have noted, December 1 was yesterday - we got a new version, but it has enough of a list of open issues that it seem

Re: The gaps that NAT is filling

2004-12-02 Thread Mark Miller
On Mon, 29 Nov 2004 14:04:05 +0100, Lars-Erik Jonsson (LU/EAB) <[EMAIL PROTECTED]> wrote: > > > The average Internet user (home user or enterprise administrator) > > > does not care about the end-to-end principle or the architectural > > > purity of the Internet. > > > > Maybe not the average user

Re: Adminrest: IASA BCP: Separability

2004-12-02 Thread Harald Tveit Alvestrand
--On torsdag, desember 02, 2004 09:11:27 +0100 Brian E Carpenter <[EMAIL PROTECTED]> wrote: I should also note that the current IASA BCP is quite vague about how the ISOC is to assist the IASA in reaching the desired level of working capital. One could interpret this as being purely an IASA ope

Re: Adminrest: section 5

2004-12-02 Thread Harald Tveit Alvestrand
I don't think there is any principle in 2.2 that forms a basis for saying that we need to aim towards limiting IETF support to meeting fees and designated donations. The situation we have now is (I think) that a lot of people support ISOC because they want to support the IETF, but do not requir

Re: Adminrest: section 3.5b (appealability)

2004-12-02 Thread Harald Tveit Alvestrand
The awarding of a contract to a vendor is an IAD decision, and as written, IAD decisions are not appealable. The decision that could be appealed is the IAOC's approval of the IAD decision - a subtle difference, but an important one; the appeal would have to be based on arguing that the IAOC did

Re: Adminrest: more on sec 7

2004-12-02 Thread Harald Tveit Alvestrand
I think a global s/deposited in/credited to/ will do the right thing, given Rob's explanation of "divisional accounting", and using "account" in the sense of "what's accounted for". We do have consensus that the IASA has to account for the money that it handles to the community. I think 5.1, w

Re: Adminrest: ExDir

2004-12-02 Thread Harald Tveit Alvestrand
I'd like the word "other" kept in (the reference is to the set of process documents, of which this document is one member, but one that has no requirements on the ExDir role). But I can live with either too :-) A nit: since this paragraph now describes a responsibility of the IAOC, not the IAD,

Re: Adminrest: section 3.5b

2004-12-02 Thread Brian E Carpenter
Scott Bradner wrote: 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 th

Re: Adminrest: section 3.5

2004-12-02 Thread Brian E Carpenter
Scott Bradner wrote: 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

Re: Adminrest: created IPR

2004-12-02 Thread Brian E Carpenter
Scott Bradner wrote: 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 Sub

Re: The gaps that NAT is filling

2004-12-02 Thread Simon Leinen
Iljitsch van Beijnum writes: > But all of this is only delaying the inevitable (not that that can't > be useful sometimes): at some point, we need to move away from the > premise that all default-free routers must know about all reachable > prefixes. But isn't this the *definition* of a default-fr

Re: Adminrest: IASA BCP: Separability

2004-12-02 Thread Brian E Carpenter
Bernard Aboba wrote: 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