Inline > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of > Harald Tveit Alvestrand > Sent: Monday, January 24, 2005 18:42 > To: ietf@ietf.org > Subject: Edits - #819 - Elwyn's editorials > > > There has apparently been no comments on these.... I thought > I'd make a > pass... > > > Some thoughts: > > S1, para 3: s/Such support includes/The support for current work includes/ > > this works either way for me - "current" seems to say "the next sentences > describe what is currently done, and the future may be different". > Suggest that we accept the edit. >
I can certainly make the change. But in my ears, the current text sounds much better. In fact I am not sure that we mean just "current" but also possible "future" work. > > S1, Para 3: > >> The IASA is also ultimately responsible for the financial > >> activities associated with IETF administrative support such as > >> collecting IETF meeting fees, paying invoices, managing budgets and > >> financial accounts, and so forth. > > > > Given that IETF/IASA is operating as some sort of subsidiary of ISOC, I'm > > not sure that IASA can be ultimately responsible for > > anything. s/ultimately/day-to-day/ or some such? > > I'd go for just deleting "ultimately". The work may be contracted out, so > it's not day-to-day, but "ultimately" is just trouble. > I remember that when we discussed this, the idea we wanted to express is that the IAD does the day-to-day work (or outsources it) but that IASA has the ultimate responsibility. That is, IASA must make sure things happen, but can outsource or assign to a specific person. So again... I am not sure we want to make any change. > > S1, para 4: 'and met well' ? Nice thought but what does it *actually* > > mean? > > That we (the IETF) like the result? > I would like this to stay, undefined as it is. > I like it to stay the way it is too > > S2.2: I know that US data protection laws and practices are not as well > > developed as European ones, but I think there ought to be some duty to > > protect the data and generate a suitable privacy policy, as well as keep > > it available. (Item 7). > > I think there should be - but don't see a good way of capturing it here. > I'd let it go for now and try to instruct the IASA later.... > Per Brians and Haralds email exchange I now have text for that (see my other email). > > S2.2: Should the IASA be responsible for ensuring that the IETF > > (especially if it is run as a subsidiary) fulfils its legal and > > regulatory > > responsibilities? It certainly needs to maintain any records that might > > be needed for such purposes beyond just financial matters. I am not > > expert in US company law but I am sure there must be *some* things they > > would need to do. > > Hm. Yes. It needs to deal with subpoenas and other irritations, for > instance. > But this is a bit like saying "you are responsible for > staying wet while in > water"..... I can't think of text at the moment.... > > > S3.1, para 3: This para states that signing powers will be > delegated to > > the IAD up to some specified limit. Who has signing powers > beyond this? > > This is just part of a much wider point about the actual > powers of the > > IETF/IAOC and the relationship with ISOC which I will > discuss at the end > > of these notes. > > The text at the moment doesn't say exactly that - it says > that "we'll work > it out"...... I don't know what more it CAN say.... > > > S3.1: I think this whole section should be much clearer > about exactly > > what powers are delegated to the IAD to make commitments, > as opposed to > > just negotiating: ISOC executes the contracts but the IAD > will want to > > know that ISOC is a rubber stamp/back stop for this > process and is not > > going to start second guessing him if he operates within > the parameters > > set for him. This is related to the long discussion on > Issue 739. There > > is also the potential for dispute between IAOC and > IAD/ISOC which is not > > really addressed. > > Not sure what to add here, if anything - this will have to be > worked out in > practical terms, and the IAOC will have to work out the details in > cooperation with the ISOC President. > Should there be specific language? > > > s3.4: It would be nice to see a requirement that minutes > were published > > in a set period or at least in a timely fashion after > meetings, rather > > than just regularly. > > Suggest s/regularly/in a timely fashion/. Easy change.... Makes sense. Change applied to my edit buffer > > > s4: > >> While there are no hard rules regarding how the IAB and the IESG > >> should select members of the IAOC, such appointees need not be > >> current IAB or IESG members (and probably should not be, if only to > >> avoid overloading the existing leadership). The IAB and IESG should > >> choose people with some knowledge of contracts and financial > >> procedures, who are familiar with the administrative support needs of > >> the IAB, the IESG, or the IETF standards process. The IAB and IESG > >> should follow a fairly open process for these selections, perhaps > >> with an open call for nominations or a period of public comment on > >> the candidates. The procedure for IAB selection of ISOC Board of > >> Trustees [RFC3677] might be a good model for how this could work. > >> After the IETF gains some experience with IAOC selection, these > >> selection mechanisms should be documented more formally. > > > > Given the comments in S3, para 1, should the appointees by 'regular > > members' of the IETF (i.e., people with a good track record of attending > > IETF meetings) as with NomCom members are their appointees? > > Actually previous discussion indicates that we do NOT want to > impose such a > requirement - the people who know how to supervise a business > construct > like IASA are not the same people who know how to design an efficient > transport protocol. So we want to have this open for "getting > the right > people", I think. > I agree with Harald, so I support a "no change" for this item Bert > Makes sense? > > Harald _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
