Re: Definitions, names, and confusion
--On tirsdag, januar 11, 2005 20:01:37 -0500 Bruce Lilly [EMAIL PROTECTED] wrote: In recent discussion of a proposed replacement of a BCP RFC, a couple of problems have reappeared: 1. There seems to be a fairly wide misunderstanding of what BCP RFCs are supposed to cover. Part of the problem is that Best Current Practice isn't a terribly good name for the sort of administrative procedures and policies that BCPs actually address. Many individuals apparently believe that discussions of how to administer user accounts and the like are suitable for BCP. It is clear from the RFC 2026 discussion that that isn't what BCP RFCs are about -- for those who bother to read 2026. Reinforcing the misinterpretation are comments referring to Next-Best Current Practice and/or Worst Current Practice. I suspect that there would be some resistance to changing the term BCP itself, so the only solution to this problem seems to lie in better education w.r.t. the true purpose and scope of BCP. actually the BCP label has multiple, largely disjunct areas of coverage. I once (many years back) suggested splitting the categories into Recommended Internet Practices and Directives for Oversight and Administration, but the acronyms didn't survive the laugh test ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Timeline for further work on IASA BCP
At the moment, there are 19 open tickets in the issue tracker. Some of these are overlapping. Of these, I think only issue #740 has been raised by people who speak for ISOC; I am not sure whether it means that ISOC is otherwise OK with the text or that ISOC has not sent comments yet. Lynn Duval (ISOC) has reviewed the document from a financial perspective, and sent comments. The editors have scheduled a meeting with her next week to check the current wording. Jorge Contreras (the IETF lawyer) is reviewing the document from a legal perspective. More review is, of course, welcome! My current plan for this week is: - Today: Attempt to send Consensus? messages on the remaining 19 issues, if I think that's possible - Friday morning, US-ET: Submit a revised draft (-04) to the internet-drafts editor. - Friday afternoon, once I-D is published: Send out a note on this list asking 2 questions: - Is the draft now good enough? - Do we need to reissue, lengthen or restart the Last Call? The next two steps are contingent on a no answer on the last question: - Thursday, Jan 20: Put the document before the IESG for IESG review and possible approval. If the discussion indicates that IETF community members require more time for review, I will place a DISCUSS vote on the document that will remain in force until I conclude that the community says that it has had enough time to review. I think it unlikely that it can be passed on this date, but it is good to have the formal IESG review done. - The next IESG telechat is on Thursday, Feb 3. Given that the document is discussed at one IESG telechat, it is possible to have it approved between telechats, if community consensus indicates that this is the Right Thing. Otherwise, we discuss it again here. Seems like a plan? Harald ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Consensus? #733 Outsourcing principle
Section 3 of draft-ietf-iasa-bcp-03 says, in part: In principle, IETF administrative functions should be outsourced. The IAD is responsible for negotiating and maintaining such 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. John Klensin suggested the following text for the first sentence, and Scott Bradner supported the idea: 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. 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? Harald ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Minor word tweak: #718 Transparency - Decisions and Reports
The following text was added to -03 as a result of this ticket: All IAOC decisions shall be minuted, and IAOC minutes shall be published regularly. Sam Hartman said: I was complaining about style, not grammar. I'd argue that the verb form of minute has low familiarity compared to the plural noun form. Suggested revision: All IAOC decisions shall be recorded in IAOC minutes, and IAOC minutes shall be published regularly. OK? ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Timeline for further work on IASA BCP
Title: Converted from Rich Text Harald, This sounds reasonable to me. How long do you are you planning to give us to review the updated draft? I've put off doing a thorough review of the draft (mostly just lurking on the discussions here) as it has been difficult to keep up with changes. John --- Original message --- Subject: Timeline for further work on IASA BCP From: "Harald Tveit Alvestrand" [EMAIL PROTECTED] Time: 01/12/2005 11:07 am At the moment, there are 19 open tickets in the issue tracker. Some of these are overlapping. Of these, I think only issue #740 has been raised by people who speak for ISOC; I am not sure whether it means that ISOC is otherwise OK with the text or that ISOC has not sent comments yet. Lynn Duval (ISOC) has reviewed the document from a financial perspective, and sent comments. The editors have scheduled a meeting with her next week to check the current wording.Jorge Contreras (the IETF lawyer) is reviewing the document from a legal perspective. More review is, of course, welcome! My current plan for this week is: - Today: Attempt to send "Consensus?" messages on the remaining 19 issues, if I think that's possible - Friday morning, US-ET: Submit a revised draft (-04) to the internet-drafts editor. - Friday afternoon, once I-D is published: Send out a note on this list asking 2 questions: - Is the draft now good enough? - Do we need to reissue, lengthen or restart the Last Call? The next two steps are contingent on a "no" answer on the last question: - Thursday, Jan 20: Put the document before the IESG for IESG review and possible approval. If the discussion indicates that IETF community members require more time for review, I will place a DISCUSS vote on the document that will remain in force until I conclude that the community says that it has had enough time to review. I think it unlikely that it can be passed on this date, but it is good to have the formal IESG review done. - The next IESG telechat is on Thursday, Feb 3. Given that the document is discussed at one IESG telechat, it is possible to have it approved between telechats, if community consensus indicates that this is the Right Thing. Otherwise, we discuss it again here. Seems like a plan? Harald ___Ietf mailing listIetf@ietf.orghttps://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Consensus? #733 Outsourcing principle
Harald Tveit Alvestrand wrote: John Klensin suggested the following text for the first sentence, and Scott Bradner supported the idea: 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. 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? Works for me. --Jari ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Consensus? #721 5.1 Finances and Audit
On reviewing the discussion, I find two things worthy of note: - IASA financial reporting should include a balance sheet and a Profit/Loss statement - If IAOC is not happy with the transparency of ISOC's accounting/audit, it should be able to do something about it. Also from the discussion: - The Generally Accepted Accounting Principles are a Good Thing, but ISOC is already legally obliged to adhere to them, so we don't need to say that in this document - Independent auditing of ISOC accounts is already a fact. What questions the auditor asks is not entirely clear - it's likely that it doesn't include are IASA accounts clearly separable. Current text from section 5.1: 5.1 Divisional Accounting For bookkeeping purposes, funds managed by IASA should be accounted for in a separate set of accounts which can be rolled-up periodically to the equivalent of a balance sheet and a profit and loss statement for IASA alone after taking into account the effect of common items paid for or received by ISOC as a whole. In the spirit of state the prinicples, let IAOC work out the details, I suggest: 5.1 Divisional Accounting Funds managed by IASA will be accounted for in a separate set of accounts. Separate financial reports, including a balance sheet and a profit and loss statement for IASA alone, will be produced as directed by IAOC. IAOC and ISOC will agree upon and publish procedures for reporting and auditing of these accounts. Does this make sense? Harald ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Other change needed? #722 - 5.4 - ISOC off-account payment for expenses
Bernard Aboba said, and it seems nobody commented: Section 5.4 Other ISOC support shall be based on the budget process as specified in Section 6IASA Budget Process. ISOC shall credit the appropriate IASA accounts at least quarterly. If ISOC pays any other IETF expenses directly, without transferring funds to the IASA, this shall be documented as a footnote to the IASA accounts. I think we want to state explicitly that any such other ISOC support shall be considered to be an irrevocable donation to the IASA, rather than a debt to ISOC, if and when the Removability clause of Section 7 is invoked. I think this is too much detail for the BCP, but want to restructure this - the footnote paragraph is too much detail too. I suggest that 5.4 be rephrased as: 5.4 Other ISOC Support Other ISOC support shall be based on the budget process as specified in Section 6, which includes deciding when ISOC monetary support is to be credited to the IASA accounts. All ISOC support, no matter how it is delivered, shall be reported in the IASA financial reports. Note that this removed the rather stilted language of ISOC shall periodically credit... - as I mentioned in the general finances message, this will in practice only affects the reporting; the money stays in the same set of bank accounts. What do people think? Harald ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Timeline for further work on IASA BCP
Good plan! Bert -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Harald Tveit Alvestrand Sent: Wednesday, January 12, 2005 11:07 To: ietf@ietf.org Subject: Timeline for further work on IASA BCP At the moment, there are 19 open tickets in the issue tracker. Some of these are overlapping. Of these, I think only issue #740 has been raised by people who speak for ISOC; I am not sure whether it means that ISOC is otherwise OK with the text or that ISOC has not sent comments yet. Lynn Duval (ISOC) has reviewed the document from a financial perspective, and sent comments. The editors have scheduled a meeting with her next week to check the current wording. Jorge Contreras (the IETF lawyer) is reviewing the document from a legal perspective. More review is, of course, welcome! My current plan for this week is: - Today: Attempt to send Consensus? messages on the remaining 19 issues, if I think that's possible - Friday morning, US-ET: Submit a revised draft (-04) to the internet-drafts editor. - Friday afternoon, once I-D is published: Send out a note on this list asking 2 questions: - Is the draft now good enough? - Do we need to reissue, lengthen or restart the Last Call? The next two steps are contingent on a no answer on the last question: - Thursday, Jan 20: Put the document before the IESG for IESG review and possible approval. If the discussion indicates that IETF community members require more time for review, I will place a DISCUSS vote on the document that will remain in force until I conclude that the community says that it has had enough time to review. I think it unlikely that it can be passed on this date, but it is good to have the formal IESG review done. - The next IESG telechat is on Thursday, Feb 3. Given that the document is discussed at one IESG telechat, it is possible to have it approved between telechats, if community consensus indicates that this is the Right Thing. Otherwise, we discuss it again here. Seems like a plan? 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
addressing WG/BCP/tags issue [was: The process/WG/BCP/langtags mess...]
Dear Bruce, I changed the subject as the referred case only shown different network architecture confusions. Positively addressing this confusions will help more the solution of the case at hand than anything else. On 01:42 12/01/2005, Bruce Lilly said: The language-tag reviewer has also recently noted his displeasure with the general discussion. Again, setting up an IETF WG with its own mailing list would address that problem well as the ones noted above. Obviously a formal WG with a formal Charter approved by the IESG and reviewed by the IAB (I detail so John Klensin is happy) is the best (I would say only if there must be relations with W3C) solution. The organization of such a WG is to follow the BCP 025 rules (RFC 2418). This means that your mail starts on the general list the debate on a new WG. But we are to be careful in not proposing an inadequate WG which would increase confusion. The [EMAIL PROTECTED] list has for several years carried well a job in a WG like fashion. Since the competence of the authors cannot be questioned, the mess probably shows that the problem was with its charter and in the resulting pattern of aggregated competences (see below). In a private mail copied to the Application Area Directors I have suggested a WG which would scale the particular langtag problem to the general issue of consistent a tagging in protocols, procedures, services and applications, to a WG-Tags. This would not remove [EMAIL PROTECTED] the custody of the RFC 3066 (bis) langtags they shown they know to govern well. My rationales are that: 1. we are in a typical case described by RFC 2418 Part 2.3 first paragraph (Proposed working groups often comprise technically competent participants who are not familiar with the history of Internet architecture or IETF processes. This can, unfortunately, lead to good working group consensus about a bad design.). IMHO the WG set-up process should be enough to make authors feeling the minor (yet blocking) points to correct. 2. the real blocking factor is that the proposed solution does not scale (it is OK for a user to chose in a menu, not for independent web services negotiating a common interinteligibility through commonly identified identical language dictionary, semantic, locale, defaults, etc.). IMHO this both will be the same in other areas than languages, and comes from the lack of a generalized tagging concept, semantic, filtering language, multilingualization rules and tools, libraries, tables, icons, etc. Once such a WG starts working langtags could be taken as a first example and benefit from a more generalized and innovative support, rather then being challenged (at everyone cost and delay) by a universal cultural ontology including a language (arts, music, publishing, icon, soundex, period, authors, etc.) tagging semantic. jfc ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Consensus? #733 Outsourcing principle
Title: Converted from Rich Text This seems reasonable to me. John L. John Klensin suggested the following text for the first sentence, and Scott Bradner supported the idea: 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. 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? ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Other change needed? #722 - 5.4 - ISOC off-account payment for expenses
Title: Converted from Rich Text I think your text is reasonable. John L. --- Original message --- Subject: Other change needed? #722 - 5.4 - ISOC off-account payment for expenses From: "Harald Tveit Alvestrand" [EMAIL PROTECTED] Time: 01/12/2005 12:10 pm Bernard Aboba said, and it seems nobody commented: Section 5.4 " Other ISOC support shall be based on the budget process as specified in Section 6IASA Budget Process. ISOC shall credit the appropriate IASA accounts at least quarterly. If ISOC pays any other IETF expenses directly, without transferring funds to the IASA, this shall be documented as a footnote to the IASA accounts." I think we want to state explicitly that any such other ISOC support shall be considered to be an irrevocable donation to the IASA, rather than a debt to ISOC, if and when the Removability clause of Section 7 is invoked. I think this is too much detail for the BCP, but want to restructure this - the "footnote" paragraph is too much detail too. I suggest that 5.4 be rephrased as: 5.4 Other ISOC Support Other ISOC support shall be based on the budget process as specified in Section 6, which includes deciding when ISOC monetary support is to be credited to the IASA accounts. All ISOC support, no matter how it is delivered, shall be reported in the IASA financial reports. Note that this removed the rather stilted language of "ISOC shall periodically credit..." - as I mentioned in the "general finances" message, this will in practice only affects the reporting; the money stays in the same set of bank accounts. What do people think? Harald ___Ietf mailing listIetf@ietf.orghttps://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Consensus? #733 Outsourcing principle
On 1/12/2005 04:51, Harald Tveit Alvestrand allegedly wrote: 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. Minimum staff required is a little difficult. One can do anything with existing staff if quality and timeliness don't matter. The IAOC has to determine those parameters as part of deciding staffing levels. I suggest minimum staff required to perform the functions satisfactorily as determined by the IAOC, or something along those lines. Scott ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Consensus? #733 Outsourcing principle
--On onsdag, januar 12, 2005 07:29:27 -0500 Scott W Brim sbrim@cisco.com wrote: On 1/12/2005 04:51, Harald Tveit Alvestrand allegedly wrote: 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. Minimum staff required is a little difficult. One can do anything with existing staff if quality and timeliness don't matter. The IAOC has to determine those parameters as part of deciding staffing levels. I suggest minimum staff required to perform the functions satisfactorily as determined by the IAOC, or something along those lines. I thought that was implied by required.. if we don't like required, I think we should drop the subsentence, leaving us with: In principle, IETF administrative functions should be outsourced. Decisions to perform specific functions in-house should be explicitly justified by the IAOC, with these decisions and staffing reviewed by the IAOC on a regular basis and against a zero base assumption. Less is more ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Consensus? #737 Section 5.3 Designated donations
The section on donations in version -03 says (skipping the editors' notes): 5.3 Designated Donations, Monetary and In-Kind Donations are an essential component of funding. The IASA undertakes no direct fund-raising activities. This establishes a practice of separating IETF administrative and standards activities from fund-raising activities, and helps ensure that no undue influence may be ascribed to those from whom funds are raised. ISOC shall create and maintain appropriate structures and programs to coordinate donations intended to support the work of the IETF, and these will include mechanisms for both in-kind and direct contributions to the work supported by IASA. Since ISOC will be the sole entity through whom donations may be made to the work of the IETF, ISOC shall ensure that those programs are not unduly restrictive. For the benefit of individuals, smaller organizations and countries with developing economies, ISOC shall maintain programs that allow for designated donations to the IETF. In-kind resources are owned by the ISOC on behalf of the IETF and shall be reported and accounted for in a manner that identifies them as such. Designated monetary donations shall be credited to the appropriate IASA accounts. In the discussion on this subject, Lynn St. Amour raised the issue that the words on designated donations were, in her words, unnecessarily restrictive and too proscriptive; and will significantly reduce needed flexibility. This was interpreted by some as saying there should be no donations that are designated solely for IETF support. There has been strong pushback against this from other people; people have pointed out that one such program already exists (the platinum membership). I also went over this in some detail in my finances note. The discussion made clear that people are not strongly wedded to any particular *size* limit for the designated donations; people have said that the 100K/year commitment level is very high, but fully accept that any such program will have to be able to pay for its own overhead. I think there is IETF consensus that we want designated donations to exist, as they do today. This principle needs to go in - and indeed, it is touched upon in other places in the BCP. But I do not see the need to put much restriction on the way it is set up. Suggested modification to the middle paragraph: ISOC shall create and maintain appropriate structures and programs to coordinate donations intended to support the work of the IETF, and these will include mechanisms for both in-kind and direct contributions to the work supported by IASA. Since ISOC will be the sole entity through whom donations may be made to the work of the IETF, ISOC shall ensure that those programs are not unduly restrictive. ISOC shall maintain programs that allow for designated donations to support the work of the IETF. The not unduly restrictive part should take care of the I want to give ten dollars issue. And I reworded the last sentence to make it match the first one, and not cause red herrings about whether the IETF exists as someone who can hold money (it doesn't). Does this make sense to people? Harald ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Consensus? #733 Outsourcing principle
On 1/12/2005 07:44, Harald Tveit Alvestrand allegedly wrote: --On onsdag, januar 12, 2005 07:29:27 -0500 Scott W Brim sbrim@cisco.com wrote: On 1/12/2005 04:51, Harald Tveit Alvestrand allegedly wrote: 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. Minimum staff required is a little difficult. One can do anything with existing staff if quality and timeliness don't matter. The IAOC has to determine those parameters as part of deciding staffing levels. I suggest minimum staff required to perform the functions satisfactorily as determined by the IAOC, or something along those lines. I thought that was implied by required.. if we don't like required, I think we should drop the subsentence, leaving us with: In principle, IETF administrative functions should be outsourced. Decisions to perform specific functions in-house should be explicitly justified by the IAOC, with these decisions and staffing reviewed by the IAOC on a regular basis and against a zero base assumption. OK Less is more Apparently so. ___ 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: Consensus? #733 Outsourcing principle
I thought that was implied by required.. if we don't like required, I think we should drop the subsentence, leaving us with: In principle, IETF administrative functions should be outsourced. Decisions to perform specific functions in-house should be explicitly justified by the IAOC, with these decisions and staffing reviewed by the IAOC on a regular basis and against a zero base assumption. Isn't the zero base assumption the critical thing? If so, the decision to outsource/in-house is a consequence, not a principle... Maybe In principle, the decision to perform IETF administrative functions in-house should be explicitly justified by the IAOC, with these decisions and staffing reviewed by the IAOC on a regular basis and against a zero base assumption. Spencer, who isn't sure we can outsource something that's never been in-sourced anyway ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Consensus? #721 5.1 Finances and Audit
Harald Tveit Alvestrand wrote: On reviewing the discussion, I find two things worthy of note: - IASA financial reporting should include a balance sheet and a Profit/Loss statement - If IAOC is not happy with the transparency of ISOC's accounting/audit, it should be able to do something about it. Also from the discussion: - The Generally Accepted Accounting Principles are a Good Thing, but ISOC is already legally obliged to adhere to them, so we don't need to say that in this document - Independent auditing of ISOC accounts is already a fact. What questions the auditor asks is not entirely clear - it's likely that it doesn't include are IASA accounts clearly separable. Current text from section 5.1: 5.1 Divisional Accounting For bookkeeping purposes, funds managed by IASA should be accounted for in a separate set of accounts which can be rolled-up periodically to the equivalent of a balance sheet and a profit and loss statement for IASA alone after taking into account the effect of common items paid for or received by ISOC as a whole. In the spirit of state the prinicples, let IAOC work out the details, I suggest: 5.1 Divisional Accounting Funds managed by IASA will be accounted for in a separate set of accounts. Separate financial reports, including a balance sheet and a profit and loss statement for IASA alone, will be produced as directed by IAOC. IAOC and ISOC will agree upon and publish procedures for reporting and auditing of these accounts. Does this make sense? yes Brian ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Consensus? #733 Outsourcing principle
Me too Brian John Loughney wrote: This seems reasonable to me. John L. John Klensin suggested the following text for the first sentence, and Scott Bradner supported the idea: 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. 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? ___ 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: Other change needed? #722 - 5.4 - ISOC off-account payment for expenses
Agreed. Having originated the footnote sentence, I'm quite happy with your replacement. I will be looking for the footnotes, of course ;-) Brian John Loughney wrote: I think your text is reasonable. John L. --- Original message --- Subject: Other change needed? #722 - 5.4 - ISOC off-account payment for expenses From: Harald Tveit Alvestrand [EMAIL PROTECTED] Time: 01/12/2005 12:10 pm Bernard Aboba said, and it seems nobody commented: Section 5.4 Other ISOC support shall be based on the budget process as specified in Section 6IASA Budget Process. ISOC shall credit the appropriate IASA accounts at least quarterly. If ISOC pays any other IETF expenses directly, without transferring funds to the IASA, this shall be documented as a footnote to the IASA accounts. I think we want to state explicitly that any such other ISOC support shall be considered to be an irrevocable donation to the IASA, rather than a debt to ISOC, if and when the Removability clause of Section 7 is invoked. I think this is too much detail for the BCP, but want to restructure this - the footnote paragraph is too much detail too. I suggest that 5.4 be rephrased as: 5.4 Other ISOC Support Other ISOC support shall be based on the budget process as specified in Section 6, which includes deciding when ISOC monetary support is to be credited to the IASA accounts. All ISOC support, no matter how it is delivered, shall be reported in the IASA financial reports. Note that this removed the rather stilted language of ISOC shall periodically credit... - as I mentioned in the general finances message, this will in practice only affects the reporting; the money stays in the same set of bank accounts. What do people think? 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 ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Consensus? #733 Outsourcing principle
Title: Converted from Rich Text "Minimum staff required" seems uncomfortably worded to me. I am not sure we need to go into this detail, for the reason Scott listed. If we do need to have this leel of detail, could we say 'sufficient staff' or something along those lines? John L --- Original message --- Subject: Re: Consensus? #733 Outsourcing principle From: "Scott W Brim" sbrim@cisco.com Time: 01/12/2005 7:29 am On 1/12/2005 04:51, Harald Tveit Alvestrand allegedly wrote: 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."Minimum staff required" is a little difficult. One can do anything with existing staff if quality and timeliness don't matter. The IAOC has to determine those parameters as part of deciding staffing levels. I suggest "minimum staff required to perform the functions satisfactorily as determined by the IAOC", or something along those lines. Scott ___Ietf mailing listIetf@ietf.orghttps://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: individual submission Last Call -- default yes/no.
Bruce Lilly wrote: [lines re-wrapped and annotated with authors' initials] mw My understanding of the purpose of the IETF/W3C Liaison group mw is, precisely, liaison over issues of importance to both the mw IETF and the W3C. bl Since the draft-philips-... effort isn't an IETF effort, bl exactly who would represent the IETF, on what basis, and bl for what purpose? A first step could be to compare the two standards bodies' requirements for language tagging, to establish whether they are compatible. Further steps could follow, depending on the outcome. Note that while HTTP, for example, is an IETF standard, the Web relies on it. Currently, the same language tagging standard is used by HTTP, HTML's meta element, HTML's lang attribute and XML's xml:lang attribute. It would be very highly desirable to maintain this alignment. I don't know who would represent the IETF, or on what basis. mw I don't know mw what is the prevailing IETF position, but quite a few of the mw contributors to the langtags discussion have treated longevity mw of data and metadata as being of no importance (cf the debate mw over how to handle changes to ISO 3166 Codes for the Names of mw Countries). bl I believe that (being of no importance) is a gross bl mischaracterization which does not represent what bl *anybody* involved in the discussion since the December bl New Last Call has said, much less the claimed quite a few. The contributions I refer to (which are in the mail archive) appear to take a profoundly negative position regarding a principal goal of the draft, namely the stability of metadata. vs Then there was the awesome list of authorities that the IETF vs list members is ignoring at its peril. vs See http://www1.ietf.org/mail-archive/web/ietf/current/msg33563.html mw Ignoring at its peril? I was simply demonstrating that mw standards bodies and individuals with long and respected track mw records have been involved for some years in the langtags work. bl You specifically stated that the draft-philips-... work has bl been carried out as an informal IETF/W3C/Unicode collaboration, bl and proceeded to list 3 W3C participants, 1 Unicode Consortium bl participant, mentioned a W3C WG and a Unicode Consortium bl project, but *no* IETF participation and of course no IETF bl WG. That remarkable comment -- IETF [...] collaboration bl with no IETF participation -- occurred after considerable bl discussion of the process. It also occurred two days after bl the close of the New Last Call, so I have until this latest bl reference back to that peculiar statement declined to comment bl on it. As has been stated before, the process followed with this draft appears to be precisely the same as that followed with RFC 3066 (BCP 47). Are you arguing that RFC 3066 too lacked IETF participation? Or are you saying that some aspect of the process caused that effort to include IETF participation but was lacking in the case of the current draft? bl Something is gravely wrong when an ad-hoc group believes bl that it is in collaboration with the IETF by ignoring bl published (RFC 2418) IETF procedures and protocols and by bl failing to advise or consult with established IETF groups bl likely to have an interest in the IETF standard which the bl ad-hoc group proposes to replace. See above. bl When a public gross mischaracterization of New Last Call bl discussion is piled on top of such claims of collaboration, bl we've gone well beyond gravely wrong. I'm dumbfounded bl and can't find a term to adequately portray my shock and bl horror at such outrageous remarks. I apologise for causing you such discomfort. -- Misha Wolf Standards Manager Chief Architecture Office Reuters -- -- Visit our Internet site at http://www.reuters.com Get closer to the financial markets with Reuters Messaging - for more information and to register, visit http://www.reuters.com/messaging Any views expressed in this message are those of the individual sender, except where the sender specifically states them to be the views of Reuters Ltd. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: individual submission Last Call -- default yes/no.
At 14:37 12/01/2005, Misha Wolf wrote: A first step could be to compare the two standards bodies' requirements for language tagging, to establish whether they are compatible. Further steps could follow, depending on the outcome. Note that while HTTP, for example, is an IETF standard, the Web relies on it. Currently, the same language tagging standard is used by HTTP, HTML's meta element, HTML's lang attribute and XML's xml:lang attribute. Sorry to come back on the particulars of the langtags debate. I do this only to illustrate the real source of the problem (described in RFC 2418 part 2.3. Misha documents very well the source of the problem: the HTML lang attribute is acceptable for the Web (IMHO not for Semantic Web) and the xml:lang attribute is not scalable. One first reason (lack of scripting) has been identified. But this is not the only one. Another problem is obviously the declaration MUST which cannot scale and creates a problem. If I am correct the W3C documentation concerning xmls:lang is http://www.w3.org/TR/2004/REC-xml-20040204/ paragraph 2.12 language definition. This document says: A special attribute named xml:lang MAY be inserted in documents to specify the language used in the contents and attribute values of any element in an XML document. In valid documents, this attribute, like any other, MUST be declared if it is used. The values of the attribute are language identifiers as defined by [IETF RFC 3066], Tags for the Identification of Languages, or its successor; in addition, the empty string MAY be specified. This definition does not permit end to end interinteligibility (hence interoperability for web services, content filtering, etc.) except in closed customer groups sharing the same language dictionary, grammar, semantic, etc. for an ISO 639 language. If the intent is a universal unique multilanguage, by one single provider, this works. Otherwise it does not. This is why in addition to adding the scripting one needs at list a type of usage/function and an authoritative source information. jfc jfc ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Consensus? #733 Outsourcing principle
I like this resolution. I think the review against a zero base assumption captures the essential goal, and the minimum staff was a weak restatement. Yours, Joel At 07:44 AM 1/12/2005, Harald Tveit Alvestrand wrote: --On onsdag, januar 12, 2005 07:29:27 -0500 Scott W Brim sbrim@cisco.com wrote: On 1/12/2005 04:51, Harald Tveit Alvestrand allegedly wrote: 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. Minimum staff required is a little difficult. One can do anything with existing staff if quality and timeliness don't matter. The IAOC has to determine those parameters as part of deciding staffing levels. I suggest minimum staff required to perform the functions satisfactorily as determined by the IAOC, or something along those lines. I thought that was implied by required.. if we don't like required, I think we should drop the subsentence, leaving us with: In principle, IETF administrative functions should be outsourced. Decisions to perform specific functions in-house should be explicitly justified by the IAOC, with these decisions and staffing reviewed by the IAOC on a regular basis and against a zero base assumption. Less is more ___ 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? #733 Outsourcing principle
Harald Tveit Alvestrand [EMAIL PROTECTED] writes: John Klensin suggested the following text for the first sentence, and Scott Bradner supported the idea: 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. 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? Sorry to be difficult, but no. I'd like people to explain why they think that the BCP should impose a bias towards outsourcing as opposed towards doing things in the most efficient way possible. -Ekr ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
No communication: #746 IAOC decision making
In the -03 version of the document, the following text occurs: 3.4 IAOC Decision Making The IAOC attempts to reach all decisions unanimously. If unanimity cannot be achieved, the IAOC chair may conduct informal polls to determine the consensus of the group. In cases where it is necessary, some decisions may be made by voting. For the purpose of judging consensus or voting, only the voting members (as defined in Section 4) shall be counted. If voting results in a tie, then IAOC chair decides how to proceed with the decision process. IAOC decisions are taken by a majority of the non-conflicted IAOC members who are available to vote, whether in person or via other reasonable means determined to be suitable by the members of the IAOC. The IAOC decides further details about its decision-making rules. These rules will be made public. The IAOC shall establish and publish rules to handle conflict of interest situations. All IAOC decisions shall be minuted, and IAOC minutes shall be published regularly. Scott Bradner raised the issue that he thought this section should include quorum rules. This debate forked: - Rob Austein and I argued strongly that the IAOC should set those detailed rules, and that the BCP was not the right place to put them; Brian Carpenter and Bert Wijnen spoke out in support of that. - Scott Bradner, John Klensin, Avri Doria, Brian Carpenter and Spencer Dawkins made (good) suggestions on what the quorum rules should be, including interesting topics like emergency powers, appropriate technologies for voting, the interaction between rules for conflict of interest and quorum rules and so on - but apart from the comments from Brian early in the discussion (not needed) and Scott's (which I interpreted as saying it needed to be in the BCP), I did not see any explicit statement in their comments on whether the quorum rules needed to be in the BCP or not. My personal opinion is that the debate has given compelling evidence that quorum rules are NOT easy to get right, which also leads me to believe that we will need to change them on a shorter timescale than the expected rate of change of the BCP - thus that they should NOT be in the BCP; the BCP should just require that they are public. (a rule that says two people in a closet is probably a short road to the recall process...) But this process is not about my opinion, but the IETF's opinion. 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? Brian, John, Avri and Spencer: Can you state if you have an opinion about whether or not the quorum rules should be in the document or not? Let's get this point settled before we dig into what the quorum rules should be - if they don't go into the BCP, the whole text of #746 gets passed as advice from the IETF community to the IAOC. Harald ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Items where I think there is already a consensus, or which are covered by other tickets
I think the following relations hold: - Three of the financial tickets are covered by the text changes proposed in #778 (the Finances message I sent a few days ago). They are: - #740: Reserves - #748: Quarterly deposits - #772: term Accruied funds In addition: - #770 (Compensation for IAOC members) has consensus on text - #771 (Powers of IAOC chair) has consensus on text - #778 (Finances) has consensus on the text, as modified by #779 - #779 (IAOC role in separation ISOC/IETF) has consensus on text - #752 (ISOC bolt blowing) has not made the case for change, and can be closed with no change to text. Unless someone insists, I won't recapitulate those. OK? Harald ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Items where I think there is already a consensus, or which are covered by other tickets
Harald, et al, It looks like the BCP process is moving along nicely. Meanwhile, within ISOC, we're studying the draft and focusing on how best to provide the right procedures and support for the IETF. Some ISOC folks have offered up suggestions already. We will try to provide a more comprehensive set of comments shortly. In broad terms, the IETF runs the standards process and completely controls its procedures. The administrative processes should be supportive of the volunteers in the IETF to help make the IETF efficient, effective and fulfilling. ISOC's primary responsibility in this area is to raise the funds and provide the business support. ISOC has been funding the IETF and providing business support for many years, so the current restructuring of the administrative processes is, from our perspective, an evolution of the existing relationship as opposed to the creation of a wholly new relation. Steve Harald Tveit Alvestrand wrote: I think the following relations hold: - Three of the financial tickets are covered by the text changes proposed in #778 (the Finances message I sent a few days ago). They are: - #740: Reserves - #748: Quarterly deposits - #772: term Accruied funds In addition: - #770 (Compensation for IAOC members) has consensus on text - #771 (Powers of IAOC chair) has consensus on text - #778 (Finances) has consensus on the text, as modified by #779 - #779 (IAOC role in separation ISOC/IETF) has consensus on text - #752 (ISOC bolt blowing) has not made the case for change, and can be closed with no change to text. Unless someone insists, I won't recapitulate those. 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 communication: #746 IAOC decision making
Harald, My personal, generic, preference is to put as little specific text into the BCP as possible. Broad principles, yes. But anything very specific, especially anything that is likely to need tuning, should be in the BCP only if there are really strong reasons why that is necessary. So I'd be quite happy with text directing the IAOC to establish voting rules and to publish them or, better yet, to propose such rules for comment to the IETF community and then establish and publish them (the difference between the two is not a showstopper for me). An extension of that point of view would argue that the present (-03) text is excessive and could reasonably be further trimmed. For example, I doubt that it is really necessary to walk through the unanimity/ consensus-and-polls / voting/ ties model in this much detail. Perhaps it would be preferable to just say that the IAOC may vote when necessary, with only the voting members voting (see how silly that sounds) and the chair figuring out how to make decisions in the event of deadlock, but that the IAOC should have a strong preference for unanimity or strong consensus over close votes (and then insert the conflict of interest statement). But, again, not a showstopper -- I think we are close enough and that anything in this range would be ok with me. john --On Wednesday, 12 January, 2005 22:22 +0100 Harald Tveit Alvestrand [EMAIL PROTECTED] wrote: In the -03 version of the document, the following text occurs: 3.4 IAOC Decision Making The IAOC attempts to reach all decisions unanimously. If unanimity cannot be achieved, the IAOC chair may conduct informal polls to determine the consensus of the group. In cases where it is necessary, some decisions may be made by voting. For the purpose of judging consensus or voting, only the voting members (as defined in Section 4) shall be counted. If voting results in a tie, then IAOC chair decides how to proceed with the decision process. IAOC decisions are taken by a majority of the non-conflicted IAOC members who are available to vote, whether in person or via other reasonable means determined to be suitable by the members of the IAOC. The IAOC decides further details about its decision-making rules. These rules will be made public. The IAOC shall establish and publish rules to handle conflict of interest situations. All IAOC decisions shall be minuted, and IAOC minutes shall be published regularly. Scott Bradner raised the issue that he thought this section should include quorum rules. This debate forked: - Rob Austein and I argued strongly that the IAOC should set those detailed rules, and that the BCP was not the right place to put them; Brian Carpenter and Bert Wijnen spoke out in support of that. - Scott Bradner, John Klensin, Avri Doria, Brian Carpenter and Spencer Dawkins made (good) suggestions on what the quorum rules should be, including interesting topics like emergency powers, appropriate technologies for voting, the interaction between rules for conflict of interest and quorum rules and so on - but apart from the comments from Brian early in the discussion (not needed) and Scott's (which I interpreted as saying it needed to be in the BCP), I did not see any explicit statement in their comments on whether the quorum rules needed to be in the BCP or not. My personal opinion is that the debate has given compelling evidence that quorum rules are NOT easy to get right, which also leads me to believe that we will need to change them on a shorter timescale than the expected rate of change of the BCP - thus that they should NOT be in the BCP; the BCP should just require that they are public. (a rule that says two people in a closet is probably a short road to the recall process...) But this process is not about my opinion, but the IETF's opinion. 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? Brian, John, Avri and Spencer: Can you state if you have an opinion about whether or not the quorum rules should be in the document or not? Let's get this point settled before we dig into what the quorum rules should be - if they don't go into the BCP, the whole text of #746 gets passed as advice from the IETF community to the IAOC. 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 communication: #746 IAOC decision making
Brian, John, Avri and Spencer: Can you state if you have an opinion about whether or not the quorum rules should be in the document or not? Let's get this point settled before we dig into what the quorum rules should be - if they don't go into the BCP, the whole text of #746 gets passed as advice from the IETF community to the IAOC. I'm fine with passing as advice. I'd like the quorum definition to be public information, but don't think it has to be in this document to be public. Spencer ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
WG Action: Path Computation Element (pce)
A new IETF working group has been formed in the Routing Area. For additional information, please contact the Area Directors or the WG Chairs. Path Computation Element (pce) Current Status: Active Working Group Chair(s): Adrian Farrel [EMAIL PROTECTED] JP Vasseur [EMAIL PROTECTED] Routing Area Director(s): Bill Fenner fenner@research.att.com Alex Zinin [EMAIL PROTECTED] Routing Area Advisor: Alex Zinin [EMAIL PROTECTED] Mailing Lists: General Discussion: [EMAIL PROTECTED] To Subscribe: [EMAIL PROTECTED] In Body: subscribe pce Archive: http://www.ietf.org/mail-archive/web/pce/ Description of Working Group: The PCE Working Group is chartered to specify a Path Computation Element (PCE) based architecture for the computation of paths for MPLS and GMPLS Traffic Engineering LSPs. In this architecture path computation does not occur on the head-end (ingress) LSR, but on some other path computation entity that may physically not be located on the head-end LSR. The PCE WG will work on application of this model within a single domain or within a small group of domains (where a domain is a layer, IGP area or Autonomous System with limited visibility from the head-end LSR). At this time, applying this model to large groups of domains such as the Internet is not thought to be possible, and the PCE WG will not spend energy on that topic. The WG will specify a protocol for communication between LSRs (termed Path Computation Clients - PCCs) and PCEs, and between cooperating PCEs. This protocol will be capable of representing requests for path computation including a full set of constraints, will be able to return multiple paths, and will include security mechanisms such as authentication and confidentiality. The WG will determine requirements for extensions to existing routing and signaling protocols in support of PCE discovery and signaling of inter-domain paths. Candidate protocols for extensions are RSVP-TE, OSPF-TE, ISIS-TE and BGP. Any necessary extensions will be produced in collaboration with the Working Groups responsible for the protocols. The Working Group will also work on the definition of metrics to evaluate path quality, scalability, responsiveness and robustness of path computation models. Work Items: - Functional specification of MPLS and GMPLS Traffic Engineered LSP path computation models involving Path Computation Element(s). This includes the case of computing the paths of intra and inter-domain TE LSPs. Such path computation includes the generation of primary, protection and recovery paths, as well as computations for (local/global) reoptimization and load balancing. The WG will address the inter-area (single IGP domain) scenario first. WG progress will be evaluated before inter-AS related work is started. - Specification of the PCE-based architecture. - Specification of requirements and protocol extensions related to the policy, and security aspects of PCE-based path computation involving PCEs of multiple administrative entities. - In cooperation with protocol specific Working Group (OSPF, ISIS, IDR, MPLS, CCAMP), development of routing (OSPF, ISIS, BGP) and LSP signaling (RSVP-TE) extensions required to support PCE-based path computation models. - Specification of techniques in support of PCE discovery within and across domains. Where such techniques result in the extensions of existing protocols (e.g., OSPF, ISIS or BGP), this work will be done in conjunction with the appropriate WGs. - Specification of a new communication protocol for use between a PCC and a PCE, and between PCEs. A single protocol will be selected from among candidates that include the existing protocols defined in other WGs. - Definition of objective metrics to evaluate various criteria such as the measurement of path quality, response time, robustness and scalability of path computation models. Review of the document Requirements for path computation element in GMPLS inter-domain networks produced by the CCAMP WG. Goals and Milestones: Feb 05: Submit first draft of PCE architecture document Feb 05: Submit first draft of PCE discovery requirements and protocol extensions documents Apr 05: Submit first draft of the PCE communication protocol requirements May 05: Submit first draft of the definition of objective metrics Jul 05: Submit first draft of the PCE communication protocol specification Aug 05: Submit PCE architecture specification to the IESG to be considered as Informational RFC Nov 05: Submit first draft of applicability statement (describing the processes and procedures for the use of the PCE architecture, protocols and protocol extensions for inter-area MPLS and GMPLS Traffic Engineering) Nov 05: Submit first draft of the MIB module for the PCE protocol Dec 05: Submit PCE communication protocol requirements to the IESG to be considered as an Informational RFC Dec 05: Submit PCE discovery protocol extensions specifications to the IESG to be considered
