Re: Last Call: 'Progressive Posting Rights Supsensions' to ...
I agree with John K lets purge 2418, 3683 etc of any language that appears to limit enforcement options and work things out on a case by case basis Scott ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: I understand that there is an ISO MOU with the IETF- ...
see RFC 3563 for one agreement Scott ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Newtrk and ISDs (was: Re: Facts, please not handwaving ...
to expand on John's ps for those of you who were not involved or who have forgotten the details the note the IESG sent about their review of the ISD idea can be found at http://darkwing.uoregon.edu/~llynch/newtrk/msg01076.html but the feeling that the WG got from the IESG review is better viewed at: http://darkwing.uoregon.edu/~llynch/newtrk/msg01067.html where an IESG member said The IESG is not at all sure that the ISD proposal is a good idea. We'd think it reasonable if newtrk decided not to follow it any more. the IESG member then goes on to say that if the WG decided to continue it would be a hard row to hoe It's not hard to see why the newtrk chair (me) decided that newtrk had no real future unless we happend to come up with something that the IESG liked (without the IESG members providing much help figuring out what they might like) in all the newtrk experience was not the highpoint of my IETF experience (I'm sure that some of the IESG members at the time would agree but for quite different reasons) Scott ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Now there seems to be lack of communicaiton here...
(1) Andrew's decision stands. Under RFC 3777, the only recourse available to anyone who disagrees with that decision would be to ask Andrew to reconsider or to file a dispute with the ISOC President. The former has already been done, and so far no reversal has been announced. we have not heard from Andrew since this discussion began - maybe he is off the net - lets not make any assumptions on what he has decided to do until he tells us my preference is to take note of the text in RFC 3797 pointed to by Donald and keep the already selected nomcom but it would not be the end of the world if Andrew decides to respin the selection in any case, this event does indicate that fixing RFC 3777 to follow the guidance in RFC 3797 is needed Scott ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Now there seems to be lack of communicaiton here...
PS - I do think its fully in Andrew's remit to make this decisison and I do not think it would be good for the IETF for anyone to appeal his decision Scott ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Comments on draft-iab-rfc-editor: IETF control
this summary is right on E.g. the IAB should keep its hands off the independent submission process at least with this channel so is the rest of Mike's message Scott ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Comments on draft-iab-rfc-editor: IETF control
the level of independence and discretion granted to the RFC Editor to edit and publish documents that are not the outcome of the IETF's peer review process is, I believe, a central matter in any version of an RFC Editor Charter. how could be any other way? Scott ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [EMAIL PROTECTED]: PI addressing in IPv6 advances in ARIN]
Jason had the chair ask how many folks in the room were in the Default Free Zone, and 20 people raised their hands. So from that I conclude at the very least that 14 of those 20 did not oppose the PI proposal. its a bit harder to say than that - the 2nd question (how many from default free ISPs) was done asking only one person per default free ISP to rase their hand - the hands showed that there were one or more reps from 20 default free ISPs in the room. Since a number of organizations sent more than one person the 14 Thomas mentions is the low end of the number of the 60 that were from default free ISPs since there was no one-hand-per-isp limit on the 1st show of hands. in fact - most of the people in the room were from ISPs of one size or another Scott ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: [EMAIL PROTECTED]: PI addressing in IPv6 advances in ARIN]
Michel sed breaking news The ARIN Advisory Council (AC), acting under the provisions of the ARIN Internet Resource Policy Evaluation Process (IRPEP), has reviewed policy proposal 2005-8: Proposal to amend ARIN IPv6 assignment and utilisation requirement and has determined that there is community consensus in favor of the proposal to move it to last call. The AC made this determination at their meeting at the conclusion of the ARIN Public Policy meeting on April 11, 2006. The results of the AC meeting were reported by the Chair of the AC at the member meeting. This report can be found at http://www.arin.net/meetings/minutes/ARIN_XVII/mem.html note the move it to last call teh last call (very much like teh IETF last call) will be on the ARIN ppml - see http://www.arin.net/policy/index.html for information on the policy process and instructons on how to subscribe to the mailing list if you have an interest in this topic please do join the list and the discussions - silence is seen as agreement Scott ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: [EMAIL PROTECTED]: PI addressing in IPv6 advances in ARIN]
now is the time to comment if you want to - a lack of comment means agreement from ARIN Member Services The ARIN Advisory Council (AC), acting under the provisions of the ARIN Internet Resource Policy Evaluation Process (IRPEP), has reviewed Policy Proposal 2005-1: Provider-independent IPv6 Assignments for End Sites and has determined that there is community consensus in favor of the proposal, as edited below, to move it to last call. The AC added the final sentence to section 6.5.8.2. as shown below. The AC made this determination at their meeting at the conclusion of the ARIN Public Policy meeting on April 11, 2006. The results of the AC meeting were reported by the Chair of the AC at the member meeting. This report can be found at http://www.arin.net/meetings/minutes/ARIN_XVII/mem.html The policy proposal text is provided below and is also available at http://www.arin.net/policy/proposals/2005_1.html Comments are encouraged. All comments should be provided to [EMAIL PROTECTED] This last call will expire at 12:00 Noon, Eastern Time, April 28, 2006. The ARIN Internet Resource Policy Evaluation Process can be found at http://www.arin.net/policy/irpep.html Regards, Member Services American Registry for Internet Numbers (ARIN) ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: the iab net neutrality
maybe I can summerize John's note by asking if this IAB has the will to write a RFC 1984 about net neutrality Scott ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: STRAW PROPOSAL RFC Editor charter
I think that was your point Scott? I just wanted to be sure the list of RFC types was complete Scott ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: STRAW PROPOSAL RFC Editor charter
I think they are independent submissions (not generally written by teh RFC Editor staff) Scott ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: STRAW PROPOSAL RFC Editor charter
The other publication tracks in the above is meant to be for -- IAB, IRTF, independent submissions, whatever comes next. and 1 april RFCs? ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Alternative formats for IDs
Dave sed: Nroff has no current industry penetration. fwiw - Nroff is on every Mac OSX shipped it is a shell procedure that fronts groff Scott ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Question about the Neustar logo on www.ietf.org
Brian sed It's traditional, and I think fair. fwiw - it took a bit of adjusting when the ISOC logo was 1st put on the home page (as I recall) - I also think its fine but should be about the same scale as the ISOC one Scott ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last call IETF experiments
Sam sez: It's certainly current IESG procedure that we can last call informationals and experimentals. I don't know that 2026 does or needs to say anything about it. Unless it is forbidden it seems like a reasonable decision making tool for the IESG to apply in some cases. imo - its quite reasonable for the IESG to specifically ask the IETF community for its views on whatever topic the IESG would like to know the community's opinion about (and a Last-Call is a tool for the IESG to use to find out the community's opinion) Scott ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Any Final Comments on the IETF Trust
I think that further tweaking with this document is not going to make it much better I think its more than good enough now - so lets sign it and get it behind us Scott ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Update: IETF Trust Consensus Call
I would like to extend the Consensus Call on the IETF Trust for one additional week until December 2nd. fwiw - I think that the IPR trust is basically the right path to take considering the circumstances but I would like to see answers to John's issues before proceeding and join John in requesting that the IETF get a commitment that the trust documents will not be signed until those answers have been posted and the community has had a chance to comment on them - thus, while it is good to extend the last call, I'd like to see it extended to a week after clarifications Lucy notes in her posting have been sent to the IETF list. Scott -- All - I would like to extend the Consensus Call on the IETF Trust for one additional week until December 2nd. Feedback to the IETF list has been sparse, but there has been some traffic on the IPR-WG list and a few comments directed to the IAOC. Additional clarification has been requested on several points related to future Licensing of IPR held by the IETF Trust and on the exact nature and disposition of both Current and Historical data as defined in Schedule A. The combination of IETF 64, WSIS related travel, and the coming US holiday has made it hard for all three parties to the IETF Trust (CNRI/ISOC/IAOC) to coordinate our responses on these two issues. We hope to have clarifying text on the Licensing issue and updates for the FAQ shortly, and will publish before 12/2/05. Watch this space: http://koi.uoregon.edu/~iaoc/ Thanks to all who have made comments, and we will keep you posted. Lucy E. Lynch Academic User Services Computing CenterUniversity of Oregon llynch @darkwing.uoregon.edu (541) 346-1774 ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: UN plans to take over our job!
Noel sez: If some WSIS-blessed bureacracy decides to make IP addresses portable (like phone numbers in a number of jurisdictions), fyi/a - an example of this thinking can be found in the aug 7 1997 amendment to the ARIN articles of incorporation - put there under the insistance of part of the US regulatory establishment see http://www.arin.net/about_us/corp_docs/artic_incorp.html added paragraph (7) to encourage allocation policy changes for Internet Service Providers in order to enhanse comperition by providing mobility of Internet Service Providers among upstream Internet Service Providers when it is generally agreed that the technology is available for portable addressing. Scott ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Cost vs. Benefit of Real-Time Applications and Infrastucture Area
One David opines - we need two more people out of the community who are going to spend a lot of their time on the administrative side of our organization instead of producing real work for the IETF. ADs do not have to stop doing useful work - many ADs (and even a chair or two) have done useful technical work while doing teh AD role - IETF documents will receive more scrutiny in the IESG. While this could be considered a good thing, there has been a significant amount of backlash in the community that enough is enough. I for one believe that we currently already provide enough review, and possibly already too much. I assume you mean 2 more people looking at things I'm not sure this will make a significant difference to the flow through the IESG which I always found to be more dependent on the pickyest AD not the number of ADs - Management research has shown that optimal group sizes are in general quite a bit smaller than the current IESG. In fact, I see already significant strains within the IESG due to our group size. imo - the size of the IESG has been more than some would consider ideal for quite a while, I do not think that adding two more ADs will do additional harm to its functionality - I think the more important issue is how the IESG operates reviews things - maybe things have changed since I was on the IESG but in those days there were only a few ADs that were consistently active on the mailing list when we were discussing big issues - a few more active folk would actually have helped in those days An IESG that doesn't operate efficiently is not in the benefit of the IETF. agreed, but imo, that problem is already there and is quite independent of the number of ADs I believe it is very dangerous to add an area before addressing the issues associated with a larger IESG fwiw, I disagree with this because I think that the proposal will add people who can dedicate more attention to this set of WGs and I think that is a good thing - see above, I think the optimal size may have been exceeded a while back but I think that adding two additional folk would produce more positives than negatives at this point Another approach could be to do serious surgery on how the IESG operates to make it a more scalable group. I think this should be done (and have proposed some ideas in the past) but I expect it to take quite a while and I'd like to get focused attention on this (conceptionial) area in the meantime Another David opines If we applied much more strict quality, relevance and timeliness measures to the existing IETF load, we would probably get rid of 1/3 to 1/2 of our current activities. And possibly more. that is an option, but I expect that the level of IETF work would not change much, the work would just be distributed among fewer WGs (but I do not doubt that some number of existing WGs should be closed for one reason or another) Scott ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: I-D ACTION:draft-narten-iana-considerations-rfc2434bis-02.txt
In which case, what you last call is not the document itself but what the IETF intends to say about it, and do about the related IANA action. just so Scott ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Port numbers and IPv6 (was: I-D ACTION:draft-klensin-iana-reg-policy-00.txt)
I was surprised that TCP-over-IPv6 and UDP-over-IPv6 didn't increase the port number space. I know it's off-topic here, but anyone know why they didn't? It surely must have been considered. That was considered to be part of TCPng, and as best I recall was explicitly out of scope. correct Scott ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: I-D ACTION:draft-narten-iana-considerations-rfc2434bis-02.txt
imo this update is much needed - there has been considerable confusion about some of the processes in RFC 2434 and it would be good to clear up the confusion one specific area of confusion was what used to be called IETF Consensus - renaming it to IETF Review may help but I'm not sure I think there should be a IANA evaluation process that includes a required IETF-wide Last-Call and evaluatiopn of the results of that Last-Call by the IESG - the current text for IETF Review does not make a Last-Call manditory (this is seperate from IETF Standards action because it should not require a standards-track RFC - an info or exp RFC should be fine) it would be my suggestion to use a very specific term such as IETF Last-Call Consensus for a process that includes the following requires a public document (not limited to IDs RFCs) requires an IETF-wide Last-Call includes IESG evaluation of results of Last-Call IESG permitted to do own evaluation but if results differ from results of Last-Call then IESG has to specifically justify difference in public message to IETF list also concerning the IESG Approval process I'm fine with having such a process but considering the mess we have been going through I would like to add a step to the IESG Approval process if the IESG decides to turn down a request it must document the reason(s) for the reject in a message to the IETF list and run a Last-Call like request for opinions on the proposed IESG rejection - if the responses to the comment requested process clearly do not support the proposed IESG rejection the IESG must withdraw its proposed rejection. The IESG can publish a RFC listing its issues with the proposed use but can not block the assignment if the responses to the comment requested process do not clearly object to the proposed IESG rejection then the IESG recommendation for rejection can be forwarded to the IANA Scott ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: I-D ACTION:draft-narten-iana-considerations-rfc2434bis-02.txt
works for me (assuming that you include non-IETF documents when you say IETF review documents) Scott From [EMAIL PROTECTED] Thu Jul 14 18:12:46 2005 X-Original-To: [EMAIL PROTECTED] Delivered-To: [EMAIL PROTECTED] To: [EMAIL PROTECTED] (Scott Bradner) Cc: ietf@ietf.org Subject: Re: I-D ACTION:draft-narten-iana-considerations-rfc2434bis-02.txt References: [EMAIL PROTECTED] From: Sam Hartman [EMAIL PROTECTED] Date: Thu, 14 Jul 2005 18:12:40 -0400 In-Reply-To: [EMAIL PROTECTED] (Scott Bradner's message of Thu, 14 Jul 2005 12:52:38 -0400 (EDT)) User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii would it be reasonable to just say that we are going to always last call IETF review documents? Personally I'd approve of this option unless people think it is too restrictive. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: When to DISCUSS?
Sam asks: how about just waiting to see if we have a problem before designing new process? we have running code that there have been problems in the past maybe this new process will help avoid some of them maybe the IESG will be more ready to push back on ADs that do not follow these much clearer guidelines - I hope so It seems likely that if there is internal conflict within the IESG, the IESG will find a way to resolve that conflict. If you don't feel that you can leave these sorts of details to the IESG, then you shouldn't be trusting the IESG at all. That's a valid position, but it is not resolved by creating enforcement mechanisms. humm - I thought this was a document from the IESG not someone from outside trying to impose process on the IESG so I'm not sure if a resolurtion process shoudl be called an enforcement mechanism in any case I do hope that the IESG will think about what to do before its confronted with a specific case even if its not willing to give the public any hints Scott ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: When to DISCUSS?
re draft-iesg-discuss-criteria-00.txt I think this is a very helpful document - if followed by the IESG it should reduce the number of what appears to be blocking actions by ADs but I did not see any enforcement mechanism - i.e. if an AD enters a DISCUSS over a section 3.2 reason how does the IESG tell that AD to back off? It seems like the alternate voting process is not needed to have the IESG look at a DISCUSS comments and reach a consensus that it is not (or is) a legit DISCUSS area maybe somthing like a 'review of comment' process that gets kicked off by another AD or a WG chair after an AD files their DISCUSS comment. The process just involving a requirement for all ADs to review the comment in question and discuss the issue on the next IESG call ending in a vote - if there is not majority support that the comment is a blocking type then the DISCUSS is changed to a non-blocking comment Scott ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IANA Action: Assignment of an IPV6 Hop-by-hop Option
Yakov asks: What was the reason(s) the request was made for an assignment that required IESG Approval, rather than either Specification Required or First Come First Serve ? it semed to be the right thing at the time it seemed to be too lose to have the IETF out of the loop when changing one of the core IETF protocols in a way that could require changes to deployed software and hardware but it seemed a bit much to require that all such options have to go through a full IETF development process ( because there could be options the IETF did not have much interest or concern about and such a lack of interest should not be an automatic block) i.e. a middle ground Scott ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: RFC 2434 term IESG approval (Re: IANA Action: Assignment of an IPV6 Hop-by-hop Option)
Margaret sed: Personally, I think that if the IETF doesn't want to give the IESG the right to approve (and refuse to approve) the allocation of IP options, then the IETF should update RFC 2780. for what it's worth (speaking as an IETFer, forment IESGer co-author of RFC2780) - to me its not a question of the IESG having the right to approve (and refuse to approve) the allocation of IP options - its a question of process - specifically *how* should the IESG refuse to approve an assignment - thus its not a question of changing 2780 to remove that right but maybe it is a question of establishing an understanding of what process the IESG should follow (e.g. make a statement and subject it to a process along the line of a Last-Call) this is not that new a concept - ADs have done this in the past (see for example, Randy's request for input about PIBs and the process that was followed to see if the IETF should continue to work on CR-LDP) - I see no reason that the IESG could not do the same sort of thing note that I think that any assertion that one can not do a last-call wiithout an ID misses the point - the point being that the IESG should attempt to get an understanding of the IETF community's opinion on the IESG's conclusion - calling it a Last-Call is just using a common IETF term as a way to describe a process so that people can easily understand the concept Scott (also see draft-klensin-iana-reg-policy-00.txt) ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: RFC 2434 term IESG approval (Re: IANA Action: Assignment of an IPV6 Hop-by-hop Option)
I agree that this would be a reasonable process, but wouldn't that be IETF Consensus (an entirely separate choice in RFC 2434 from IESG Approval)? see RFC 2434 IETF Consensus - New values are assigned through the IETF consensus process. Specifically, new assignments are made via RFCs approved by the IESG. note that IETF Consensus specifically requires an RFC approval on the other hand IESG Approval specifically does not require a RFC IESG Approval - New assignments must be approved by the IESG, but there is no requirement that the request be documented in an RFC so a process by which the IESG determines if the IETF community agrees with a decision to reject an assignment request which is not done by ID/RFC is not the same thing as IETF Consensus in RFC 2434 fwiw - saying that the IESG should check with the community should be a simple concept to understand - but maybe I'm wrong Scott ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: RFC 2434 term IESG approval (Re: IANA Action: Assignment of an IP
It's not a hard concept. It just isn't mentioned or implied in RFC 2780. neither is not drinking gasoline but I trust that will not change your desire to not do so Scott ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Appeal of decision to standardize Mapping Between the Multimedia Messaging Service (MMS) and Internet Mail
I don't see that text either. I suspect it was omitted because of the possibility of denial of service attacks on getting standards out (Scott Bradner, a comment on this might be helpful). I do not recall any discussion on this particular question but tere was a general assumption that common sense would be used so as to not render any appeal moot before it was processed - note that just because someing is not specifically enabled in RFC 2026 should not be read to mean that teh action is specificaly disabled - that can be the case if 2026 says 'you MUST do X but I see no reason to extend 2026 to automatically block actions the WG (or editor) did not think about unless 2026 dictates a particular path to follow in this case I see nothing in 2026 that says that publication can not or should not be held up Scott ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IENs: 127, 117, 93
I am looking for Internet Experimental Notes 127, 117 and 93. Any idea where these can be found. ftp://ftp.isi.edu/in-notes/ien/ien127.txt for example Scott ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IENs: 127, 117, 93
ps - you will also find those IENs under RFC # 762, 758 and 755 Scott ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: 'Requirements for IETF Draft Submission Toolset' to ...
I use nroff Scott ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Voting Idea? (Was: Last Call: 'Requirements for IETF Draft Submission Toolset' to Informational RFC)
But we *often* take straw polls in f2f meetings, but we do not count hands - we look to see if there is a clear difference between hands one way and or the other Scott ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: What problems does the draft cut-off solve? ...
At this point, less than one week before the meeting, only 14 WGs (not counting BOFs) have agendas posted. humm - maybe there is another explanation for part of that I sent an agenda (including ID names) in almost a month ago but its not on the WG BOF agenda page forwarded message= From sob Mon Feb 7 21:09:58 2005 To: [EMAIL PROTECTED] Subject: agenda for newtrk newtrk working group agenda intro status - chair 10 report and discussion on the anti-cruft effort 40 background reading: draft-ietf-newtrk-cruft-00.txt discussion of ISD proposal 60 background reading: draft-ietf-newtrk-repurposing-isd-01.txt draft-ietf-newtrk-sample-isd-00.txt draft-ietf-newtrk-sd-00.txt draft-ietf-newtrk-sample-isd-stdproc-00.txt wrapup - chair 10 ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Perhaps clarify: #825 - IASA responsibilities regarding IPR
Harld admits and thinks: I'm sure Jorge could phrase it better. but I think the meaning is clear. works for me Scott ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Suggested resolution - #826: Section 4 - Removal of the IAOC Chair
Harald asks: is using the term 5/8 of the voting members an acceptable phrase? it's just what I was asking for (i.e, to answer your question - yes) Scott ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Suggested resolution - #826: Section 4 - Removal of the IAOC Chair
Harald suggests The Chair serves at the pleasure of the IAOC, and may be removed from that position at any time by a vote of five of the IAOC voting members. I don't think its a good idea to use absolute numbers - its better to use fractions '4/5ths of the voting members' for example - in case you have a situation where some IAOC members have dropped off for some reason - using absolute numbers can get into a situation where the action can not be taken even though all existing members of the IAOC want to do so Scott ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
BCP sec 4 - end of term
not a showstopper but it woudl eb good to be clear the text curently says: Subject to paragraph 2 of Section 4.1, appointed members of the IAOC serve two year terms. IAOC terms normally end at the first IETF meeting of a year, just as as IAB and IESG terms do. I suggest changing this to say Subject to paragraph 2 of Section 4.1, appointed members of the IAOC serve two year terms. IAOC terms normally end at the end of the first IETF meeting of a year. its good to be specific as to when during the meeting Scott ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Resolution? #787 terminology - in particular ISOC Standards Pillar
I have left the change to General Ledger Accounts out for the time being, because I am not sure we have consensus on that yet (even though ISOC prefers that terminology). I would think it is a generally good idea to use the legal terms to reduce confusion so I see no justification to not use General Ledger Accounts Scot ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Resolution? #787 terminology and issue 794 - naming of accouts
Bert suggests: section title=Cost Center Accounting anchor=cc-accounting t As discussed with ISOC, funds managed by IASA shall be accounted for in a separate set of general ledger accounts within the Cost Center IASA. In the remainder of this document, these general ledger accounts are termed IASA accounts. A periodic summary of the IASA accounts shall be reported in the form of standard financial statements that reflect the income, expenses, assets, and liabilities of the IASA cost center. /t t IAOC and ISOC shall agree upon and publish procedures for reporting and auditing of these accounts. /t t Note that the ISOC in consultation with IAOC can determine to tructure the IASA accounting differently in the future within the constraints outlined in xref target=isoc-responsibilities/. /t /section OK by me Scott ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: FW: Resolution? #787 terminology and issue 794 - naming of accounts
Bert resuggests: 5.1 Cost Center Accounting Funds managed by the IASA shall be accounted for in a separate set of general ledger accounts within the IASA Cost Center. In the remainder of this document, these general ledger accounts are termed IASA accounts. A periodic summary of the IASA accounts shall be reported in the form of standard financial statements that reflect the income, expenses, assets, and liabilities of the IASA cost center. The IAOC and ISOC shall agree upon and publish procedures for reporting and auditing of these accounts. Note that ISOC in consultation with the IAOC can decide to structure the IASA accounting differently in the future within the constraints outlined in Section 7. still OK by me Scott ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
NeuStar consensus (was Re: Progress report......)
Harald sez: - We will *share* with the community our opinion that this effort could help achieve a transition with less conflict and uncertainty than going straight from a CNRI-provided secretariat to an open RFP process would. is there any particular consensus determination mechanism envisioned? i.e., how will who (IASA, IAD, IESG, IAB, all of the above) figure out of the IETF community thinks that its a good idea for the IETF to agree to N years (where N seems to be an unknown value) of NeuStar before issuing an RFP? Scott (ps - my personal feeling is that the general idea is a good one but, like John, I think there are a lot of questions that need to be answered before IETF community should be asked if it supports the arrangement so that NeuStar can find out, as they say they want to know, if the IETF community supports their initiative) ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
NeuStar as a unit (was Re: Progress report......)
Harald mentions in passing: for instance, the transition team has briefly considered the option of making permanent institutional memory in the form of archives a separate task that is carried out outside the present secretariat framework - since Carl's reports indicate that this task may need a different skillset, and different resources, than the secretariat currently has. is there a requirement for the IETF to agrre that NeuStar take over all of the current Foretec funstions? It seems to me that providing mailing list services (along with the archives of them) is a quite separable function - there are a number of companies in that business. I'd like to see a RFP be developed for the mailing list function and that bids be solicited for it - NeuStar could bid on the RFC if they felt that they have the expertise but I see no reason to think that they would automatically be the best choice. In the long run I'd like the IETF to move away from having a single vendor for all of our support services (ignoring for the moment the RFC Editor and IANA which are already seperate) - it puts too much dependency in one place and assumes that expertise in, for example, meeting managment automatically translates into expertise in other areas such as mailing list management. Scott ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
a full time IAD (was Detailed Neustar answers)
Harald quotes John and says Or, more generally, if the IAD is expected to act merely as a conduit for information between the IETF leadership and Neustar/Foretec, is the job description correct (at least for the duration of the Neustar arrangement) and does the job really require a full-time person. I believe the IAD should be negotiating those contracts, and that these contracts should have adequate controls. And I believe that this can EASILY consume a full-time employee. I can immagine that it might take a full time employee to negotiate a contract with NeuStar (not sure what other contracts you mean) but I can not immagine that the full time work would last any longer than it takes to negotiate the contract(s) after which I would think the IAD would be at most a 1/3 time task (unless NeuStar turns out to be real bad and takes a lot of oversight) - it seems to me that the IAD will be idle most of the time - not condusive to retaining good people. Scott ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Comment on draft-ietf-iasa-bcp-04
Russ sez: We want to keep it simple. However, a recall is serious. At a minimum, we need to require that 2/3rd of the voters are present for the vote. If we say that at least 2/3rd of those present must vote for removal, then an 'abstain' is essentially a vote to keep the chair in office. I agree except that I'd like to not tie this to a physical (or teleconference) meeting - why not email in which case it can be 2/3 of the members other than the chair is required to zap the chair Scott ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Progressing Re: Progress report......
All we need to do is that as soon as we have IASA in place (we still need to approve the BCP first) that IASA then starts to prepare for RFPs and such and then the process can start. the prepare for RFPs seems futile (or at least *very* premature) if NeuStar is to get a N-year agreement/contract I agree with John that we need to figure out if the BCP as-is is all that useful in the face of what appears to be a done deal Scott ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Discussion: #822 legal review 3: Legal advice
Harald suggests teh following The IAD negotiates service contracts, with input, as appropriate, from other bodies, including legal advice, and with review, as appropriate, by the IAOC. The IAOC should establish guidelines for what level of review is expected based on contract type, size, cost, or duration. ISOC executes contracts on behalf of the IASA, after whatever review ISOC requires to ensure that the contracts meet ISOC's legal and financial requirements. works for me Harald also asks The other point raised is whether the legal advice for IASA needs to be independent from ISOC's legal advice. Consideration so far seems to be that sometimes this would be good, sometimes this would be indifferent or extra overhead - hard to codify in this BCP. Should we leave that as no change proposed? also works for me Scott ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Edits - #819 - Elwyn's editorials
Harald suggests The IAD shall ensure that personal data collected for legitimate purposes of the IASA are protected appropriately, and at least satisfactorily according to relevant legislation. Place it just after paragraph 5 of section 3.1, the one that starts out talking about contracts giving the IETF rights in data - it seems appropriate. OK? yup Scott ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: A little more feedback? #818 Hiring and firing the IAD
I prefer NEW(2) Although the IAD is an ISOC employee, he or she works under the direction of the IAOC. A committee of the IAOC is responsible for hiring and firing of the IAD, for reviewing the performance and for setting the compensation of the IAD. The members of this committee are appointed by the IAOC, and consist at minimum of the ISOC President, the IETF Chair and one IAOC member that has been selected by the Nomcom. Scott ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Rough consensus? #425 3.5
I agree that postmortems can be useful but I'm not sure that doing such on a decision to hire Bill instead of Fred is one of those cases where it woudl be useful, feasiable (due to confidential info including recommendations) or produce any useful results (unless teh reason to hire Bill was that he was the IAD's dad) the same thing with reviewing the decision to hire company A rather than company B - I can see reviewing the process by which the decision was made but I do not think (for teh same reasons above) that the reviewing the decision itself would be all that easy or useful Scott From [EMAIL PROTECTED] Sun Jan 23 15:17:14 2005 X-Original-To: [EMAIL PROTECTED] Delivered-To: [EMAIL PROTECTED] To: [EMAIL PROTECTED] (Scott Bradner) Cc: ietf@ietf.org, [EMAIL PROTECTED] Subject: Re: Rough consensus? #425 3.5 References: [EMAIL PROTECTED] From: Sam Hartman [EMAIL PROTECTED] Date: Sun, 23 Jan 2005 15:17:16 -0500 In-Reply-To: [EMAIL PROTECTED] (Scott Bradner's message of Fri, 21 Jan 2005 09:17:25 -0500 (EST)) User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Scott == Scott Bradner [EMAIL PROTECTED] writes: Scott ps - I'm not sure that its all that useful to be able to Scott appeal/review awards if they can not be overturned - Scott apealing or reviewing the process that was followed is fine Scott but appealling the actual award seems broken I disagree. Reviewing a specific decision in an operational context to determine whether the right decision was made can be a useful feedback step in a control loop of a system. I've found this to be true whether systems are technical or manigerial. --Sam ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Re: Rough consensus? #425 3.5
Brian clarifies: Reviewing procedures is fine. Reviewing specific awards isn't, IMHO, which is all I intended my words to exclude. I agree with Brian - allowing the review of specific awards could easily cause the DoS attack that I've been warning against Scott ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Re: Rough consensus? #425 3.5
Margaret sez: None of the versions of the text that we are looking at (the current BCP, Harald's, mine, Scott Brim's...) indicate that a request for review of an IAD or IAOC decision could result in: (1) reversing a ... if all of the proposed text actually said (as the -04 text does) that awards can not be overturned then there is not a DoS threat - but Harald's suggested wording does not do that Scott ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Re: Rough consensus? #425 3.5
ps - I'm not sure that its all that useful to be able to appeal/review awards if they can not be overturned - apealing or reviewing the process that was followed is fine but appealling the actual award seems broken this may seem like a wording nit but I think it would properly set expectations Scott ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Consensus? #789: Section 5.6 - Financial reserves
Harald suggests: The IASA expects ISOC to build and provide that operational reserve, through whatever mechanisms ISOC deems appropriate. looks good to me Scott ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: No change needed? #790: Section 2.2 - In-kind donations
Harald points out and suggests The question was what the purpose of the last line was. The discussion seems to have revealed that this is good business practice (don't accept gifts of white elephants), and there's no real need to change the text. agree (he says agreeing to his own words :-) ) Scott ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Minor issue, no change? #791: Section 2.2 - Editorial
I agree with Harald - lets leave it as-is Margaret wrote: 8. The IASA, in cooperation with ISOC, shall ensure that sufficient s/shall ensure/shall attempt to ensure/ ?? reserves exist to keep the IETF operational in the case of unexpected events such as income shortfalls. I think this should remain as-is. There are other principles in the list where it's possible to imagine that one could fail (7 on IPR, for instance). But I won't lose any sleep over it either way. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
re: Minor resolution: #793: Section 7 - transition of funds
Harald suggests To the extent allowed by law, any balance in the IASA accounts, any IETF-specific intellectual property rights, and any IETF-specific data and tools shall also transition to the new entity. Other terms shall be negotiated between the IETF and ISOC. works for me Scott ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Rough consensus? #425 3.5
Harald suggests: -- 3.5 Decision review In the case where someone questions a decision of the IAD or the IAOC, he or she may ask for a formal review of the decision. The request for review is addressed to the person or body that made the decision. It is up to that body to decide to make a response, and on the form of a response. The IAD is required to respond to requests for a review from the IAOC, and the IAOC is required to respond to requests for a review of a decision from the IAB or from the IESG. If members of the community feel that they are unjustly denied a response to a request for review, they may ask the IAB or the IESG to make the request on their behalf. Answered requests for review and their responses are made public. --- why not make public all requests (i.e. remove Answered from the last line) I still feel that this leaves things too open (specifically it does not set expectations about the possible results of a review ) to a DoS attack but as I said before I can live with this as-is. Scott ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Rough consensus? #425 3.5
Margaret notes It seems strange, IMO, to be so worried about DoS attacks through the appeal process we've been using this process for several years for IESG and WG decisions and haven't experienced that sort of problem... the current appeals process does not apply to commercial decisions such as the awarding of a contract so whatever experience we already have is not relevent to what we might experience under the new process (imo) Scott ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Rough consensus? #425 3.5
Harald explains Answered requests for review and their responses are made public. --- why not make public all requests (i.e. remove Answered from the last line) because: 1) some requests are an embarassment to the sender, and the sender doesn't really want an answer not sure that giving someone an additional way to embarrass themselves (in addition to the existing public mailing lists) is all that much of a negative in the face of a general desire for openness 2) anything that's got a requirement to do something is a DoS vector, even if trivial - so I bent over backwards to prevent that. you seem to be more bendable than I am :-) - I don't see that a public archive for the request submission list would be all that big a deal to do Harald (again) asks I still don't understand how not setting expectations opens to a DoS attack - setting expectations would be such an opening. Want to try to explain? (again) for example, if the looser in a RFP process feels that they can get the decision overturned and a particular IASA does not have a strong assumption that this is outside the scope the IASA could think it could put the decision on hold (and block the delevery of a service such as getting ready to provide networking at an IETF meeting) until the review is done but I repeate - I can live with the text as Harald proposes it Scott ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Rough consensus? #739 Assuring ISOC commitment to AdminRest
Harald asks: 2.5 Effective Date for Commencement of IASA The procedures in this document shall become operational after this document has been approved by the process defined in BCP 9 [RFC2026] , including its acceptance as an IETF process BCP by the ISOC Board of Trustees, and the ISOC Board of Trustees has confirmed its acceptance of ISOC's responsibilities under the terms herein described. Is that something we can live with? I can Scott ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Consensus? #746 IAOC decision making
harald suggets The IAOC attempts to reach consensus on all decisions. If the IAOC cannot achieve a consensus decision, then the IAOC may decide by voting. looks good to me Scott ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: iasa-bcp-04: unanimity in section 3.4
Bert sez: NEW: t The IAOC attempts to reach consensus on all decisions. If the IAOC cannot achieve a consensus decision, then the IAOC decides by voting. /t I thought the other point was that the text should read If the IAOC cannot achieve a consensus decision, then the IAOC can decide by voting i. not mandate voting - leave it up to them Scott ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call Comments on draft-iasa-bcp-04.txt
Margaret asks ISSUE #5: 6. There shall be a detailed public accounting to separately identify all funds available to and all expenditures relating to the IETF and to the IASA, including any donations, of funds or in-kind, received by ISOC for IETF-related activities. In-kind donations shall only be accepted at the direction of the IAD and IAOC. What is the purpose of the last line? Is there some fear that someone would accept inapproprite in-kind donations? What happens if they do? I intended that last line to make it clear that its the IETF (though the IAD and IAOC) that decides if an in-kind donations is actually something that the IETF wants and is comfortable with any conditions - for example someone might be concerned if the ISOC accepted an offer from Bill' bait sushi shop to sponsor lunches at IETF with the minor requirement that an add for BBSS be appened to all RFCs Scott ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
re: iasa-bcp-04: unanimity in section 3.4
John K sez: Proposed change: Get rid of unanimous (both times), replacing it with consensus and appropriate editorial smoothing. I fully agree Scott ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: No communication: #746 IAOC decision making
So - Scott, can you confirm that you think quorum rules should be in the BCP? Rob, can you confirm that you think they should not be? imo - if rules for voting are in the document then quorum rules should be but I'm fine with the idea that the document say 1/ general method is consensus 2/ the IAOC will develop and publish quorum and voting rules and publish them for the cases where consensus can not be found Scott ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Consensus search: #725 3.4b Appealing decisions
harald proposes: 3.5 Decision review In the case where someone questions a decision of the IAD or the IAOC, he or she may ask for a formal review of the decision. The request for review is addressed to the person or body that made the decision. It is up to that body to decide to make a response, and on the form of a response. The IAD is required to respond to requests for a review from the IAOC, and the IAOC is required to respond to requests for a review of a decision from the IAB or from the IESG. If members of the community feel that they are unjustly denied a response to a request for review, they may ask the IAB or the IESG to make the request on their behalf. Answered requests for review and their responses are made public. I am still worried about the possibility of a DoS attack and the messy situation where the looser in a bid wants the bid award overturned so would be happier with some language that says that its real hard or impossible to overturn signed contracts but that said I can live with what Harald suggests if no one else shares my worries Scott ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Consensus search: #725 3.4b Appealing decisions
I think you have to explain more why you are worried before I'm able to share them. I have in detail in the past Scott ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Consensus search: #725 3.4b Appealing decisions
-On torsdag, januar 13, 2005 07:20:22 -0600 Spencer Dawkins [EMAIL PROTECTED] wrote: Harald, So the IAD and IAOC don't have to respond to individual requests for review unless IAB or IESG make the request on behalf of an individual, but we all get to see requests and responses and make our own NOMCOM inputs? Exactly. oh - I did not parse that - in that case I'm OK with the proposed text Scott ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Consensus? #746 3.4 IAOC decision making
Harald further suggests: 3.4 IAOC Decision Making The IAOC attempts to reach all decisions unanimously. If unanimity cannot be achieved, some decisions may be made by voting. The IAOC decides the details about its decision-making rules, including its rules for quorum, conflict of interest and breaking of ties. These rules will be made public. All IAOC decisions shall be recorded in the IAOC minutes and published regularly. works for me Scott ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Suggest no change: #739 Assuring ISOC commitment to AdminRest
note that in the resolutions that accepted the IETF process BCPs (2026 for example) also had text that said that the ISOC aggreed to undertake the role described in the document for the ISOC i.e. I would expect that both would be in a single motion Scott ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Consensus? #733 Outsourcing principle
harald asks We have to adjust the second sentence (referring to such contracts would become ambiguous), so the total paragraph becomes: In principle, IETF administrative functions should be outsourced. Decisions to perform specific functions in-house should be explicitly justified by the IAOC and restricted to the minimum staff required, with these decisions and staffing reviewed by the IAOC on a regular basis and against a zero base assumption. The IAD is responsible for negotiating and maintaining outsourcing contracts, as well as providing any coordination necessary to make sure the IETF administrative support functions are covered properly. The IAOC is accountable for the structure of the IASA and thus decides which functions are to be outsourced. All outsourcing must be via well-defined contracts or equivalent instruments. Both outsourced and in-house functions must be clearly specified and documented with well-defined deliverables, service level agreements, and transparent accounting for the cost of such functions. Is that OK with everyone? Case closed? ok by me Scott ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Minor word tweak: #718 Transparency - Decisions and Reports
haralald's Suggested revision: All IAOC decisions shall be recorded in IAOC minutes, and IAOC minutes shall be published regularly. looks fine to me Scott ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: V2 Consensus? #770 Compensation for IAOC members
Harald suggets: so I'll switch to proposing that we adopt the text by (at last count) John Klensin and Mike St. Johns at the end of section 4.0: - The IAOC members shall not receive any compensation for their services as members of the IAOC. The IAOC shall set and publish rules covering reimbursement of expenses, and such reimbursement shall generally be for exceptional cases only. I think this captures the intent of *all* the posters so far. End of thread? works for me Scott ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IASA Finances - an attempt at some uplevelling
Specific suggestion for text changes from harald Reserves Section 2.2 bullet 7, current: 8. The IASA shall establish a target for a reserve fund to cover normal operating expenses and meeting expenses in accordance with prudent planning, and ISOC shall work with the IASA to build up and maintain the reserve. Under the principle of state principles, not mechanisms, change to: 8. The IASA, in cooperation with ISOC, shall ensure that sufficient reserves exist to keep the IETF operational in the case of unexpected events such as income shortfalls. looks good to me All other details should be in section 5.6. In section 5.6, change: Rather than having the IASA attempt to build that reserve in its separate accounts, the IASA looks to ISOC to build and provide that operational reserve, through whatever mechanisms ISOC deems appropriate: line of credit, financial reserves, meeting cancellation insurance, and so forth. Such reserves do not appear instantaneously; the goal is to reach this level of reserves within 3 years after the creation of the IASA. Such funds shall be held in reserve for use by IASA for use in the event of IETF meeting cancellation or other unexpected fiscal emergencies. These reserves shall only be spent on IETF support functions. to: The IASA expects ISOC to build and provide that operational reserve, through whatever mechanisms ISOC deems appropriate: line of credit, financial reserves, meeting cancellation insurance, and so forth. Long term, financial reserves are preferred; it should be a goal for ISOC to reach this level of reserves within 3 years after the creation of the IASA. If the IASA account accumulates a surplus, ISOC may count that as part of the reserve. also OK by me modulo changing account to accounts in the last sentence IASA accounts - In section 7 (Removability), change: Any accrued funds, any IETF-specific intellectual property rights, and any IETF-specific data and tools shall also transition to the new entity. to Any IASA account balance, any IETF-specific intellectual property rights, and any IETF-specific data and tools shall also transition to the new entity. Other terms of removal shall be negotiated between the non-ISOC members of the IAOC and ISOC. I agree with John's concern maybe fix by saying non ISOC-appointed members Scott ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Adminrest: BCP -03: Compensation for IAOC members
Jonne asks: would x.x Compensation for IOAC members The IOAC members shall not receive any compensation (apart from reimbursement of expenses) for their services as members of the IOAC. do the trick then? works for me ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Adminrest: BCP -03: Compensation for IAOC members
bert asks: The current text in section 3, 1st para states The IAOC consists of volunteers, does that not say enough? I'd say no - volunteers can get paid in some cases Scott ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Excellent choice for summer meeting location!
Glen rants: Are you then claiming that there is _nowhere_ in France that a) is capable of hosting a meeting with the IETF's requirements and b) the weather is more pleasant? =20 how about Paris? http://www.paris.org/Accueil/Climate/gifs/paris.climate.temp.html seems like the news story about extraordinary is also rare average max temp in Paris in july looks like 24 C and a bit lower in aug cooler than boston http://www.thisistravel.co.uk/travel/weather/location.html?in_location_id=205in_page_id=1 average max temp in july 27 C now if you are coming from Seattle I can see that both might be considered deadly :-) see 4th paragraph of http://news.bbc.co.uk/1/hi/programmes/letter_from_america/3102625.stm Scott ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Issue #727: Section 2.2, 4, 7 - Miscellaneous editorial
brian asks Perhaps we do indeed need to explicitly limit the IAOC Chair to chairing the IAOC. But we almost do - the following paragraph says: The chair of the IAOC shall have the authority to manage the activities and meetings of the IAOC. The IAOC Chair has no formal duty to represent the IAOC, except as directed by IAOC consensus. Isn't this enough? maybe the 2nd sentence change to The IAOC Chair does not represent the IAOC (unless directed to do so by IAOC consensus) and does not represent the IETF. no formal duty leaves the IAOC chair to do so anyway and it would be good, in the same place, to say that the IAOC chair does not represent the IETF Scott ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Adminrest: BCP -03: Compensation for IAOC members
Personally, I don't understand why we would have a different reimbursement policy for IAOC members than for IESG and IAB members. just being willing to pay travel expenses might make it possible for someone to be able to do the IAOC job (since I think it can be done in non-day-job time) - that is not the case for IAB or IESG members Scott ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Adminrest: BCP -03: Compensation for IAOC members
just being willing to pay travel expenses might make it possible for someone to be able to do the IAOC job (since I think it can be done in non-day-job time) - that is not the case for IAB or IESG members To be honest, I don't quite follow this logic. What would be the major difference here on the reimbursement? the key difference is if the job can be done while holding down a full time day-job (so the employer does not have to donate significant time) - since an AD job is at least half time it can not be done without significant employer support (or by someone with their own money) - if the IAOC job can be done on someone's own time then they do not need employer support for their time and, if the expenses for the few trips needed are covered, support for travel (outside of normal IETF travel) Scott ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Adminrest: BCP -03: Compensation for IAOC members
However, people from outside US have to pay for the long distance fee to call those numbers. the services that teh IESG used when I was an AD called out to non-US folk (or to folk that were in those %%(*$%$ hotels that charge per minute for toll free calls longer than some time) Scott ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Adminrest: BCP -03: Compensation for IAOC members
thanks to Jonne for bringing this up - I agree that some text about this should be in the document but I disagree on what it should say. imo - the IAOC members should not be compensated for their time but I think its reasonable for them to be reimbursed for expenses for travel to meetings not held in the same place and time as IETF meetings (or just before or after an IETF at the same location) - since I would hope that almost all of the work of the IAOC shoudl be done over the net or by phone I would not think this would come up that often but it might during startup (revaluating RFP responses for example) - doing this enables peopel who do not have strong money support to still be able to be on the IAOC Scott ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Adminrest: BCP -03: Compensation for IAOC members
I admit that I maybe have too much a view point of someone working for a relatively large company. not everyone does I try to approach this from a position where the IAOC itself does not become a significant cost for IASA. I agree - see my note - I do not think that face to face meetings are all that needed but might happen for special things However, as these are the people that are responsible for setting the budget and supervising the finances of the IASA and there is no real owner to control the expenses it would be clearer to have the IAOC members being responsible for their own expenses. that limits who can be on the IAOC to people who can afford it not to those who would do the best job If we would decide to reimburse traveling I think we cannot make the distinction between meetings co-located with IETF or not. There will always be people to argue that they wouldn't or couldn't come to the IETF and travel to IAOC meetings during the IETF should also be reimbursed. I disagree - I do not think we should easily have people who do not come to the IETF on the IAOC deciding what is good for the IETF Scott ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Adminrest: BCP -03: Compensation for IAOC members
please do not read more into what I said than I said - I *only* meant what I said - nothing more (I have a hard time understanding how anyone could have misread what I said) I did not suggest any change to the non-reimbursment of IESG IAB expanses - nor did I intend to I expect the job of being an IAOC member will take little time and almost no travel (after maybe a startup phase) - someting that someone who was willing to put non-day-job time in could do - thus I'd like the maximum flexability in being able to get the right people and if that means paying expenses for one or two face to face meetings a year (if the IAOC feels that it must meet face to face other thna at an IETF meeting) it seems like a small price to pay Scott ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Issue #723: Section 3 - Requirements for Outsourced Activities
accounting transparency is mentioned in a number of places already it seems overly redundent to mention it here yet again - but its not a big deal to me Scott - Kurtis comments on text suggested by Bernard: On 2004-12-09, at 17.02, Bernard Aboba wrote: Suggest this be rewritten to: The IAOC is accountable for the structure of the IASA and thus decides which functions are to be outsourced. All outsourcing must be via well-defined contracts or equivalent instruments. Both outsourced and in-house functions must be clearly specified and documented with well-defined deliverables, service level agreements, and transparent accounting for the cost of such functions. I think this is overkill. It is up to the IAD/IAOC to decide how to account for costs of outsourced contracts, so I would put a period after service level agreements. I have seen support for Bernard's statement (on email I believe by Margaret) and I like Bernard's text myself as well. I have not seen anyone agree with Kurtis yet. So for now I am believing we seem to have more agreement on the complete text suggested by Bernard. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: No change needed? #723 - Outsourcing as a principle
Harald concludes: I believe that these are valid reasons to keep the mention of the outsourcing principle in section 3, so I suggest we close #723 with no changes needed. I agree Scott ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: #732: Section 5 - Fund raising cost allocated to IASA?
clearly fund raising expenses must be accounted for but, imo, there is nothing special about fund raising expenses - there will also be other overhead costs that will have to be seen as being in the IASA budget (Bert mentions credit card fees, there is also office space, legal support for contract negotiation, etc, etc) - I do not see a particular need to call out fund raising expenses in a special way. Bert proposes: So my proposal is: no change needed I agree Scott ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Issue: #749: Section 6 - Budget process
Bert sez: As a result of the discussion I have updated the text and it currently looks as follows in my edit buffer: section title=IASA Budget Process anchor=iasa-budget-process t While the IASA sets a budget for the IETF's administrative needs, its budget process clearly needs to be closely coordinated with ISOC's. The specific timeline shall be established each year by IASA and ISOC. As an example, a general annual timeline for budgeting is: /t list style=hanging t hangText=July 1: The IAD presents a budget proposal (prepared in consultation with ISOC staff) for the following fiscal year, with 3 year projections, to the IAOC. /t more text as in rev 02 t The dates described above are examples and subject to change. They will most likely be modified each year based on the dates of the second and third IETF meetings of that year. They also need to be synchronised with the ISOC budgeting process. /t I think that closes the issue. it does for me - tnx Scott ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Issue #740: Section 2.2 5.6 - IASA BCP -02 Reserves
Bert quotes lynn and then says Maybe replace the last two sentences with some variation of Access to these reserves would expect to follow normal IAOC and ISOC approval processes for any budget overruns. I believe that the current text was quite extensively discussed in the past. I am not sure I can just go ahaead and make changes based on one person bringing it up. So I'd like to see more support on the list first. I support Lynn's suggestion Scott ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: No change needed? #723 - Outsourcing as a principle
I like John's formulation reason In principle, IETF administrative functions should be outsourced. Decisions to perform specific functions in-house should be explicitly justified by the IAOC and restricted to the minimum staff required, with these decisions and staffing reviewed by the IAOC on a regular basis and against a zero base assumption. Scott ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Issue #745: Section 3.1 - ISOC involvment in budget
Scoot, I believe that we have also resolved that issue implicitly by resolving issue749. Do you agree? not being someone who memorizes issue numbers I had to look these up but I think you are correct Scott ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Consensus? Minor issue #743: Defining the IETF
works for me --- From [EMAIL PROTECTED] Wed Dec 22 04:42:35 2004 X-Original-To: [EMAIL PROTECTED] Delivered-To: [EMAIL PROTECTED] Date: Wed, 22 Dec 2004 10:20:15 +0100 From: Harald Tveit Alvestrand [EMAIL PROTECTED] To: ietf@ietf.org X-Mailer: Mulberry/3.1.5 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Virus-Scanned: by amavisd-new at alvestrand.no X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edec89 Content-Transfer-Encoding: 7bit Subject: Consensus? Minor issue #743: Defining the IETF X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion ietf.ietf.org List-Unsubscribe: https://www1.ietf.org/mailman/listinfo/ietf, mailto:[EMAIL PROTECTED] List-Post: mailto:ietf@ietf.org List-Help: mailto:[EMAIL PROTECTED] List-Subscribe: https://www1.ietf.org/mailman/listinfo/ietf, mailto:[EMAIL PROTECTED] Sender: [EMAIL PROTECTED] Errors-To: [EMAIL PROTECTED] I'm trying to go through the list of open issues and resolve those that appear easy, and this one caught my eye: maybe define the IETF - maybe point to RFC 3233 Suggested resolution: Add to section 2.1 Alphabet Soup: IETF: Internet Engineering Task Force (see [RFC3233]) ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Consensus? Minor issue #743: Defining the IETF
OK by me --- From [EMAIL PROTECTED] Wed Dec 22 05:00:02 2004 X-Original-To: [EMAIL PROTECTED] Delivered-To: [EMAIL PROTECTED] Date: Wed, 22 Dec 2004 10:49:09 +0100 From: Harald Tveit Alvestrand [EMAIL PROTECTED] To: ietf@ietf.org X-Mailer: Mulberry/3.1.5 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Virus-Scanned: by amavisd-new at alvestrand.no X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Content-Transfer-Encoding: 7bit Subject: Consensus? Minor issue #730: Section 2.2 - Authority over standards development X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion ietf.ietf.org List-Unsubscribe: https://www1.ietf.org/mailman/listinfo/ietf, mailto:[EMAIL PROTECTED] List-Post: mailto:ietf@ietf.org List-Help: mailto:[EMAIL PROTECTED] List-Subscribe: https://www1.ietf.org/mailman/listinfo/ietf, mailto:[EMAIL PROTECTED] Sender: [EMAIL PROTECTED] Errors-To: [EMAIL PROTECTED] Old text: 2. The IAD, IAOC and ISOC shall not have any authority over the IETF standards development activities. Issue: ISOC already has a role in IETF standards development activities. Suggested new text: 2. The IAD and IAC shall not have any authority over the IETF standards development activities, and this document does not confer any new authority or responsibilities to ISOC regarding IETF standards development. Resolution: Slight modification of the suggested text: 2. The IAD and IAOC shall not have any authority over the IETF standards development activities. This document does not modify ISOC's other roles related to the IETF standars process. (Reason: This doc neither expands nor contracts the existing responsbilities) OK? Harald ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: No change needed? #724 IAD Job description
ok --- From [EMAIL PROTECTED] Wed Dec 22 06:47:13 2004 X-Original-To: [EMAIL PROTECTED] Delivered-To: [EMAIL PROTECTED] Date: Wed, 22 Dec 2004 12:11:57 +0100 From: Harald Tveit Alvestrand [EMAIL PROTECTED] To: ietf@ietf.org X-Mailer: Mulberry/3.1.5 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Virus-Scanned: by amavisd-new at alvestrand.no X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Content-Transfer-Encoding: 7bit Subject: No change needed? #724 IAD Job description X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion ietf.ietf.org List-Unsubscribe: https://www1.ietf.org/mailman/listinfo/ietf, mailto:[EMAIL PROTECTED] List-Post: mailto:ietf@ietf.org List-Help: mailto:[EMAIL PROTECTED] List-Subscribe: https://www1.ietf.org/mailman/listinfo/ietf, mailto:[EMAIL PROTECTED] Sender: [EMAIL PROTECTED] Errors-To: [EMAIL PROTECTED] Bernard said: Section 3.1 As has been stated by others, I think we want the IAOC to be able to rewrite the IAD's job description if and when circumstances warrant it. So I think we need to be clear about what are essential IAD duties prescribed by this document (which require another BCP to change) and what elements of the IAD's job description may be modified/added by the IAOC as it sees fit. Section 6 The IAD shall provide monthly accountings of expenses, and shall update expenditures forecasts every quarter. This may require adjustment of the IASA budget: if so, the revised budget will need to be approved by the IAOC, the ISOC President/CEO and, if necessary, the ISOC Board of Trustees. Doesn't this belong in Section 3.1? As I read the document, the only thing that is stated as this is not part of the instruction is the timeline in section 6, so moving this text will not change anything. I suggest that we close the ticket with no text change. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Consensus? Issue #744: Section 3 - Backup mechanism for IAD
harald suggest: If there is no IAD or the IAD is unavailable, the IAOC may temporarily assign the IAD's duties to individual members of the IAOC. looks good Scott ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Consensus? #746 Section 3.4 - IAOC decision making
harald asks My reading of the discussion is that there is no support for making such a requirement (too many corner cases with absent members), and that writing detailed rules on IAOC decision making into the BCP is a Bad Idea. However, the idea of IAOC *having* such decision rules seems good. Suggested resolution: Add after the first section of 3.4: The IAOC decides further details about its decision-making rules. These rules will be made public. OK? I think the added statement is fine I do not like this resolution - I think it would be very bad to have a situation where a bare majority of the IAOC (5) can hold a face to face (or conference call) meeting and then have a bare majority (3) of those present make a binding decision (to approve a contractor for example) - this would wind up with a minority of the IAOC making such a decision. That minority (or even the discussion) might not include the IETF or IAB chair, the ISOC prez etc - that seems like a very bad situation. it seems to me to be a no brainer to require that decisions be only binding if the majority of the IAOC agree one way of another (in person or via email) (the situation of one member being (literally) in the woods does not make any difference -- if 4 members were in the woods such that one cound not get a majority of the 8-member IAOC then maybe the decision should wait anyway) Scott ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
