Re: draft-farrel-rtg-morality-requirements-00.txt
On Tue, 16 Nov 2004 15:57:37 -0800 Bob Hinden [EMAIL PROTECTED] wrote: We should be proactive and create a morality area in the IETF. The morality ADs can review and vote Discuss if the Morality Considerations section in drafts being reviewed by the IESG is not adequate. I nominate Bert! ;-) --Olaf ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: How the IPnG effort was started
Michel, I think you missed the point. As of today, IPv6 is in the same situation ISDN has always been: I Still Don't Need. ^ ^ ^ ^ You might explain that to the people who say they need IPv6. Brian ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: How the IPnG effort was started
From: Brian E Carpenter [EMAIL PROTECTED] You might explain that to the people who say they need IPv6. OK, I'll bite. Let's assume what many people now seem to concede, which is that a large part of the Internet is going to continue to be IPv4-only. So, what's the functional difference between: - A host which has an IPv6 only address, which it cannot use (without borrowing a global IPv4 address) to comunicate directly with IPv4-only hosts out on the global Internet. - A host which has an IPv4 local-only address, which it cannot use (without borrowing a global IPv4 address) to comunicate directly with other IPv4 hosts out on the global Internet. Noel ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
IASA BCP Section 5.3
I have some comments on Section 5.3 of the IASA BCP, Other ISOC Support. The first paragraph of this section says: Other ISOC support shall be based on the budget process as specified in Section 6. ISOC will deposit the yearly amount (as agreed to in approved budget) in equal portions. At a minimum such deposits will be made quarterly. This seems unnecessarily restrictive. Budgets are not always flat quarter-to-quarter. Since there are only three IETF meeting a year, there is a quarter in which no IETF meeting is held. Also, if there is a hiring plan for new staff and/or a particular project that begins or ends during the year, the funding needs of the IETF may differ from quarter to quarter. I would rather that the document say: Other ISOC support shall be based on the budget process as specified in Section 6. The amount of allocated funds and the dates on which funds will be transferred to the IASA account will be agreed as part of the budgeting process. The second paragraph in this section says: If ISOC directly funds any other IETF expenses, such as the IETF share of ISOC's liability insurance premium, this will be documented together with the other IASA accounts. I'm not really sure what this means... There are some complexities to this budgeting process that aren't captured in this document, and I don't think that they should be. However, calling out one particular point (such as insurance) really begs the question of why other things that fall into this category are not called out. I would prefer that we simply delete this paragraph from the BCP. It does seem likely to me that there will be a single ISOC DO insurance policy and that the costs of that policy will be allocated to the ISOC standards pillar as part of the overhead. But, I don't understand the point of calling out this particular expense as something special... There are other costs (such as paying a qualified accountant to figure these things out) that will also fall into this category. Margaret ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: How the IPnG effort was started
On Wed, 2004-11-17 at 06:55 -0500, Noel Chiappa wrote: From: Brian E Carpenter [EMAIL PROTECTED] You might explain that to the people who say they need IPv6. OK, I'll bite. Grawl back ;) Let's assume what many people now seem to concede, which is that a large part of the Internet is going to continue to be IPv4-only. So, what's the functional difference between: - A host which has an IPv6 only address, which it cannot use (without borrowing a global IPv4 address) to comunicate directly with IPv4-only hosts out on the global Internet. - A host which has an IPv4 local-only address, which it cannot use (without borrowing a global IPv4 address) to comunicate directly with other IPv4 hosts out on the global Internet. Difference is that the IPv6 host can actually communicate end-2-end globally and not only in it's local network. It is all about *global* communication, not about local communication, you can avoid IANA completely in those cases, simply use 1.2.3.4 as an IP at your convenience, you will have enough 32-bit space then, but you cannot talk to your sister on vacation on japan using VoIP who you really do not want to explain what a NAT box is and how she can get through it with a VoIP tunnel tool or other VPN tricks. Before you argue but there is no IPv6 global connectivity yet, then please check your local Abilene site, with that nice government funded Internet2 and you will find quite a lot of activity there. Asian and European regions are much further in deployment. Not to the doorstep of most houses yet in Europe as they do in Korea and Japan, but with the aid of TunnelBroker systems one can get a long way already and these are also available on your side of the pond of course ;) Greets, Jeroen signature.asc Description: This is a digitally signed message part ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: How the IPnG effort was started
Michel Py wrote: I think you missed the point. As of today, IPv6 is in the same situation ISDN has always been: I Still Don't Need. ^ ^ ^ ^ Comparisons to past successes or failures are fun, but not always good indications of future. There are several reasons behind why something takes or does not take off. These include customer needs, timing (can the SDO complete the specs before people deploy?), conformance to a dominating technology (why would I buy Beta if all movies are on Vhs?), problems working in all situations (does my VoIP call go through a NAT?), business case for all the parties that need to do something (can I charge you more if we start offering x?), ease of use (zero configuration for most of the network stuff is a requirement for success as far as I can see), immediate benefits (or do you have to wait before everyone else on the planet has it too before you can use it at all?) and so on. The trouble with looking at past failures is that they make you feel like nothing can ever change. Yet we do have examples of spectacular successes, even in cases where there has been obstacles in the way, significant complexity or existing, competing technology that provides some of the same functionality. Say, switch from analog to digital cellular technology. Many such successes occur in situations where the market is growing rapidly, which makes it easier to change technology. And I believe the Internet is growing rapidly. For instance, there are billions of people in Asia, hopefully most of whom will probably have Internet access in the next ten years. Or the cell phone users, looks like the trend is that everyone will also have IP (and IPv6!); that's over a billion users more than we have now in the Internet. Also, the comparisons may not be exact matches: I wonder what would have happened to ISDN if the numbering system in the analog system had run out of numbers, and everyone who got their phone after 1960, including all the Chinese subscribers, would only be able to make, not receive calls? --Jari ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: AdminRest: New version of IASA BCP document available
Harald, the first look of it seems to be comprehensive and balanced enough. But there is a problem you will have to address sooner or later which is the usage (whatever you name the technically competent users) representation. ISOC is supposed to include it. You can claim that them being involved, users are represented. But the more you split from the ISOC structure and formalize the things, the more you will need to introduce users/consumers representation. I know that ISOC has no real structure for that: this may be the occasion to lead that creation, and to keep it with IASA when it eventually probably split, some time in the future. Taking manufacturers/operators (labelled as market) as usage representatives is why IETF is not innovative. This works well to improve status quo. Not to move seriously ahead. We all know that at some stage IDNA, IPv6, etc. will be necessary/used. But experience shown that techies being convinced does not lead users moves, because they want more important reasons for investment, serious ROI opportunities and the really move when they cannot do otherwise. This is exactly what RFC 3869 says. IAB calls for Govs (which are organized and leading users) funding for RD, indentifying that pure operators/manufacturers (market) funding will not be enough. jfc At 07:22 17/11/2004, Harald Tveit Alvestrand wrote: and here's the draft name. --- A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Structure of the IETF Administrative Support Activity (IASA) Author(s) : R. Austein, B. Wijnen Filename: draft-ietf-iasa-bcp-00.txt Pages : 17 Date: 2004-11-16 This document describes the structure of the IETF Administrative Support Activity (IASA) as an IETF-controlled activity housed within the Internet Society (ISOC) legal umbrella. It defines the roles and responsibilities of the IETF Administrative Oversight Committee (IAOC), the IETF Administrative Director (IAD) and ISOC in the fiscal and administrative support of the IETF standards process. It also defines how the IAOC will be comprised and selected. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-iasa-bcp-00.txt ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: How the IPnG effort was started
--On 17. november 2004 06:55 -0500 Noel Chiappa [EMAIL PROTECTED] wrote: From: Brian E Carpenter [EMAIL PROTECTED] You might explain that to the people who say they need IPv6. OK, I'll bite. Let's assume what many people now seem to concede, which is that a large part of the Internet is going to continue to be IPv4-only. So, what's the functional difference between: - A host which has an IPv6 only address, which it cannot use (without borrowing a global IPv4 address) to comunicate directly with IPv4-only hosts out on the global Internet. - A host which has an IPv4 local-only address, which it cannot use (without borrowing a global IPv4 address) to comunicate directly with other IPv4 hosts out on the global Internet. that the former can communicate with all other nodes with globally reachable IPv6 addresses, without having to borrow a global IPv4 address to do so? I'll leave it as an exercise for the reader to figure out whether this is a *significant* functional difference - but it *is* a functional difference, and that was what you asked for, Noel ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: AdminRest: New version of IASA BCP document available
--On 17. november 2004 13:45 +0100 JFC (Jefsey) Morfin [EMAIL PROTECTED] wrote: Harald, the first look of it seems to be comprehensive and balanced enough. But there is a problem you will have to address sooner or later which is the usage (whatever you name the technically competent users) representation. ISOC is supposed to include it. You can claim that them being involved, users are represented. But the more you split from the ISOC structure and formalize the things, the more you will need to introduce users/consumers representation. Actually the users of the structure being discussed here are the participants in the IETF process, not the public at large. That's important to keep in mind. The IETF standards process is not supposed to be affected by this reorganization (except, hopefully, by having better support). I agree that the IETF standards process needs to have participation from users, but doing so through management of the support infrastructure would be *significantly* convoluted Harald ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: How the IPnG effort was started
On Wed, 17 Nov 2004, Harald Tveit Alvestrand wrote: The difference has been significant on my end. The advantage of end-to-end connectivity to/from hosts previously only behind a NAT is remarkable. So is ALL THE ADDRESS SPACE that I now have available, without extra charges from the local telco/cableco. I don't think that I am ready to give up on v6 deployment across the entire internet just yet... these things take time. Scott --On 17. november 2004 06:55 -0500 Noel Chiappa [EMAIL PROTECTED] wrote: From: Brian E Carpenter [EMAIL PROTECTED] You might explain that to the people who say they need IPv6. OK, I'll bite. Let's assume what many people now seem to concede, which is that a large part of the Internet is going to continue to be IPv4-only. So, what's the functional difference between: - A host which has an IPv6 only address, which it cannot use (without borrowing a global IPv4 address) to comunicate directly with IPv4-only hosts out on the global Internet. - A host which has an IPv4 local-only address, which it cannot use (without borrowing a global IPv4 address) to comunicate directly with other IPv4 hosts out on the global Internet. that the former can communicate with all other nodes with globally reachable IPv6 addresses, without having to borrow a global IPv4 address to do so? I'll leave it as an exercise for the reader to figure out whether this is a *significant* functional difference - but it *is* a functional difference, and that was what you asked for, Noel ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf sleekfreak pirate broadcast http://sleekfreak.ath.cx:81/ ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: draft-farrel-rtg-morality-requirements-00.txt
Hardly a moral model, I mean look at some of the stuff Bert engages in: http://bert.secret-wg.org/Kisses/index.html ...and that's the censored stuff. OK, OK, back to AdminRest or something equally sobering :-) Ole Ole J. Jacobsen Editor and Publisher, The Internet Protocol Journal Academic Research and Technology Initiatives, Cisco Systems Tel: +1 408-527-8972 GSM: +1 415-370-4628 E-mail: [EMAIL PROTECTED] URL: http://www.cisco.com/ipj On Wed, 17 Nov 2004, Olaf M. Kolkman wrote: On Tue, 16 Nov 2004 15:57:37 -0800 Bob Hinden [EMAIL PROTECTED] wrote: We should be proactive and create a morality area in the IETF. The morality ADs can review and vote Discuss if the Morality Considerations section in drafts being reviewed by the IESG is not adequate. I nominate Bert! ;-) --Olaf ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: AdminRest: New version of IASA BCP document available
On 14:14 17/11/2004, Harald Tveit Alvestrand said: The IETF standards process is not supposed to be affected by this reorganization (except, hopefully, by having better support). I agree that the IETF standards process needs to have participation from users, but doing so through management of the support infrastructure would be *significantly* convoluted This is not what I have in mind. What I have in mind is something equivalent to GAC in ICANN or IAB in the IETF structure. IAB has identified it needed the users money (Govs are the leading users), the same as ICANN has identified they needed Gov support (Stuarts call). The simplest and the least risky way is to suggest a usage forum (what ISOC should be/is?) that would have with the IETF the _only_ tie of a common secretariat. Any other way (at an higher political layer) implies risks of interference with the Internet standard process. Through a common administrative support (secretariat) they will be able to channel suggestions and comments but only in respecting the Internet standard process. IMHO this is our best protection against ITU creep. This calls for a non-committing paragraph to open the possibility of this administrative plug, and see if something develops. The problem you face otherwise is the way to interface and finance the interface of a global network user/consumer committee which could result from Tunis. In initiating the move, you better keep it under control. In being ready to plug a network usage advisory board with similar relations as to the IAB, you have modified nothing, and offered in you own terms what big users will ask for and obtain from others creating IETF a big pain. jfc ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: IASA BCP Section 5.3
The second paragraph in this section says: If ISOC directly funds any other IETF expenses, such as the IETF share of ISOC's liability insurance premium, this will be documented together with the other IASA accounts. I'm not really sure what this means... There are some complexities to this budgeting process that aren't captured in this document, and I don't think that they should be. However, calling out one particular point (such as insurance) really begs the question of why other things that fall into this category are not called out. I would prefer that we simply delete this paragraph from the BCP. Hi Margaret - I think the point here was not to single out insurance but to say that the IETF would like to see what is known in accounting circles as a full allocation. That means that some attempt is made in the books to allocate general expenses (such as insurance) among various programs. An alternative accounting model is simply to calculate overhead (e.g., unallocated expenses) and use some metric (e.g., total expenses by pillar or activity) to do the allocation. That's kind of what we have today (of $2m in revenues, $600k is lumped into the overhead category). I think what the paragraph in the bcp intended to say is the former not the latter. It does seem likely to me that there will be a single ISOC DO insurance policy and that the costs of that policy will be allocated to the ISOC standards pillar as part of the overhead. But, I don't understand the point of calling out this particular expense as something special... There are other costs (such as paying a qualified accountant to figure these things out) that will also fall into this category. Might it read better something like this? In the case of additional direct expenditures by ISOC which benefit the IETF and other activities, ISOC shall attempt to allocate such expenses by activity, allowing IASA to gain an accurate view of the true cost of support activities. And, to the accountants: don't lump all general expenses into a ga budget line: at least attempt to break stuff out by program if it makes sense to do such an allocation. Regards, Carl ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: IASA BCP Section 5.3
The second paragraph in this section says: If ISOC directly funds any other IETF expenses, such as the IETF share of ISOC's liability insurance premium, this will be documented together with the other IASA accounts. I'm not really sure what this means... There are some complexities to this budgeting process that aren't captured in this document, and I don't think that they should be. However, calling out one particular point (such as insurance) really begs the question of why other things that fall into this category are not called out. I would prefer that we simply delete this paragraph from the BCP. It does seem likely to me that there will be a single ISOC DO insurance policy and that the costs of that policy will be allocated to the ISOC standards pillar as part of the overhead. But, I don't understand the point of calling out this particular expense as something special... There are other costs (such as paying a qualified accountant to figure these things out) that will also fall into this category. This text is my fault. I agree - the insurance is only an example, but since it appears to be singled out, let's lose the example. Then it could read If ISOC pays any other IETF expenses directly, without transferring funds to the IASA, this will be documented as a footnote to the IASA accounts. And why specify this? For transparency. Otherwise we might slip back into the old regime of hidden expenditures and lack of a clear overview of the budget. Brian ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Key rollover and draft-delany-domainkeys-base-01.txt (fwd)
Good draft - got it to work quite easily; excelent examples in the draft, that does help. However.. ideally one would like the keys to be relatively short (i.e. ensure it easily fits in the UDP reply; along with other dns info; and in order to keep calculation times on todays HW resonable). This implies strongly that one wants to do key roll over. Would it be an idea to extend the proposal to - Allow multiple (or at least 2) DomainKey-Signature: blocks if needed along with something like: The signature of the email is stored in the DomainKey-Signature: header. This header contains all of the signature and key-fetching data. In order to allow for key rollover There MUST be at least one DomainKey-Signature but more MAY be present. If multiple DomainKey-Signature are present then the receiving MTA MUST verify each of them in the order received until one of them verifies correctly. Alternatively one could allow multiple TXT replies; but this makes it sure to violate the UDP size limit. Also - if the keys are 500 bits or so - roll over would be very frequent - hence easily leading to long periods in which this UDP limit would be violated. Cheers, Dw ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
RE: TCP bandwidth usage was: Yahoo is not using ESMTP
At 9:14 PM -0800 11/16/04, Michel Py wrote: And it's not such a big deal to run a big site, apparently: TorrentBits.org is situated on a dedicated server in the Netherlands. For the moment we have monthly running costs of approximately ¤ 213. Another popular music torrent site (not based in the US, of course) meticulously prohibits commercially-available music *and* only allows lossless encodings (which are about 5 times as large as typical MP3s, or about half the size of uncompressed music). It has 90,000 users, 20,000 of which are active at the moment, half of them seeding. The site is causing a distribution speed of 150 MB/sec. Their running costs so far are about US$5,000, and they have already been donated twice that much completely voluntarily. And, of course, the software they're using for all of this is open-source and free. Setting up a torrent site is about as difficult as setting up a BBS was 20 years ago, it just causes about 4 orders of magnitude more traffic. --Paul Hoffman, Director --VPN Consortium ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
RE: IASA BCP Section 5.3
Inline -Original Message- From: Margaret Wasserman [mailto:[EMAIL PROTECTED] Sent: Wednesday, November 17, 2004 08:11 To: Carl Malamud Cc: [EMAIL PROTECTED] Subject: Re: IASA BCP Section 5.3 At 7:40 AM -0800 11/17/04, Carl Malamud wrote: Might it read better something like this? In the case of additional direct expenditures by ISOC which benefit the IETF and other activities, ISOC shall attempt to allocate such expenses by activity, allowing IASA to gain an accurate view of the true cost of support activities. That sounds good, Carl. Brian's wording is also fine with me. It just read strangely to me to single out insurance. I will note that it was/is listed as such as... and so it was/is just an example. I can also live with the text of eitehr Carl or Brian. Bert Margaret ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
AdminRest: Finances and Accounting
A question for those maintaining the document There is a fair bit of change in section five, regarding IASA funding. In a nutshell, it now says: - IETF has three revenue streams: * IETF meeting fees * Donations of various kinds designated to the IETF * ISOC funding derived from other sources - the first two get deposited in the IASA checkbook - the third gets deposited in quarterly lump payments - there is an intent to have built up enough money for the IASA to run for six months without receiving a dime, over a period of three years. All that sounds good on the surface, but it differs rather markedly from current ISOC accounting practice, and it seems to over-constrain the problem and its solution. Someone who knows more about accounting than I do will mention the difference between a cash accounting scheme and an accrual accounting scheme, the latter being more usual in corporate accounting. IETF does indeed have these present revenue sources. CNRI/Foretec currently collects IETF meeting fees and uses them pursuant to IETF meetings, databases, and teleconferences. ISOC accepts donations designated to IETF-related activities. ISOC also uses funds from other revenue sources (other donors) to further IETF purposes. ISOC places donations to the IETF in accounts so designated. When the money is spent usually on the RFC Editor, which is our largest single IETF-related expense - the revenue is recognized, and the books show both the revenue and the expense. The effect of section 5, if I am reading it correctly, is to present ISOC with an always-on expense ISOC immediately transfers any such money to IASA. The money is therefore immediately recognized as both revenue and an expense in the ISOC ledger and as a net deposit in the IASA checkbook. ISOC current practice with regard to other IETF (and ISOC) expenses is to pay them as bills are presented. Bills are not presented on nice neat quarterly boundaries; the insurance bill is paid annually, IAB telechats are paid out of the monthly phone bill, meeting expenses and other payments from the IETF Chair's Discretionary Budget are paid episodically, and so on. The current issues in the RFC Editor's office (into which I will not delve in detail; due to an accounting error, they have suddenly needed an infusion of cash) result in ISOC paying an unplanned and unbudgeted lump sum payment. In short, like any other ISOC bill, IETF-related expenses are paid as valid bills are received, sometimes by surprise. A significant part of IETF expenses will be in deposits for future meetings. Generally, the most expensive way to plan and pay for an excursion in a hotel or conference center is at the last minute. As a result, most organizations that plan conferences have deposits on hotels and such at least a year out. A quick look at http://www.icann.org/meetings/, for example, shows meetings paid for through next summer, and on in development in December 2005. When the document talks about a six-month reserve, I therefore have to ask: which six months of the year? Does this cover one planned meeting fee, or two? On an accrual basis, that's not much of an issue, but on a cash basis, it is a big one. The effect of section 5, if I am reading it correctly, is to transfer these budgetary bumps and grinds to the IASA rather than allowing the ISOC to help out, making oops, we're low on cash something that has to be discussed as opposed to ISOC simply backstopping things as we have heretofore agreed. By treating them on a cash basis rather than an accrual basis, this section seems maximize the pain they cause. I wonder whether the IETF would consider talking with ISOC's accounting office to normalize these issues now, and whether the problem really needs to be this tightly constrained? Regards, Fred Baker /=/ | Fred Baker |1121 Via Del Rey | | Chairman, ISOC BoT |Santa Barbara, California | ++93117 USA | | Nothing will ever be attempted,| phone: +1-408-526-4257 | | if all possible objections must| fax: +1-413-473-2403 | | be first overcome. | mobile:+1-805-637-0529 | | Dr. Johnson, Rasselas, 1759| | /=/ ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Last Call Comments: draft-ietf-simple-filter-format
(Sorry if this is a duplicate; I sent an earlier copy from an address that isn't subscribed to the IETF list. Last I heard it was being held for moderation.) Last Call Comments: draft-ietf-simple-filter-format I have asked the XML Directorate to review this document. These comments are my own. The MIME type described in this document does not appear to have been submitted to the ietf-types list for review. That should happen before the IESG evaluates this document. The XML Schema includes several elements and attributes to allow extensions. There needs to be some text in the document describing the extensibility framework. There also needs to be some text added to the document to address versioning and/or what will need to be done in the future if the schema is changed and namespace conflicts need to be avoided. Section 4 appears to contain a small ABNF error, or at least something that may require clarification. The productions for element and elem-path are defined like this: expression = [ (elem-expr / attr-expr) 1*[oper (elem-expr / attr-expr)] ] elem-path = (element / *) 1*[/ / * / element] [* / element] My confusion is that a construct of the form [foo bar] describes optional items. 1* means that at least one instance is required. So when the spec says 1*[oper (elem-expr / attr-expr)] and 1*[/ / * / element], is it saying that the items are optional, or that at least one is required? Section 8.2 includes an XML instance that seems to be encapsulating information about the namespace registration request. As described in section 3.2 of RFC 3688, there really is no XML representation of a namespace identifier. While section 4 of RFC 3688 includes a field to register an XML instance, I don't believe that there's any XML to be registered when the template is being used to register a namespace URI. -Scott- ___ xml-dir mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/xml-dir ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
[Fwd: I-D ACTION:draft-farrel-rtg-morality-requirements-00.txt]
Not clear why this doesn't apply to all IETF protocols, not just routing protocols... Original Message Subject: I-D ACTION:draft-farrel-rtg-morality-requirements-00.txt Date: Tue, 16 Nov 2004 16:12:52 -0500 From: [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] To: [EMAIL PROTECTED] A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Requirements for Morality Sections in Routing Area Drafts Author(s) : A. Farrel Filename: draft-farrel-rtg-morality-requirements-00.txt Pages : 5 Date: 2004-11-16 It has often been the case that morality has not been given proper consideration in the design and specification of protocols produced within the Routing Area. This has led to a deline in the moral values within the Internet and attempts to retrofit a suitable moral code to implemented and deployed protocols has been shown to be sub-optimal. This document specifies the requirement for all new Routing Area Internet-Drafts to include a 'Morality Considerations' section, and gives guidance on what that section should contain. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-farrel-rtg-morality-requirements-00.txt To remove yourself from the I-D Announcement list, send a message to [EMAIL PROTECTED] with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username anonymous and a password of your e-mail address. After logging in, type cd internet-drafts and then get draft-farrel-rtg-morality-requirements-00.txt. A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: [EMAIL PROTECTED] In the body type: FILE /internet-drafts/draft-farrel-rtg-morality-requirements-00.txt. NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the mpack utility. To use this feature, insert the command ENCODING mime before the FILE command. To decode the response(s), you will need munpack or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with multipart MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. Message/External-body; name="draft-farrel-rtg-morality-requirements-00.txt": Unrecognized ___ I-D-Announce mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/i-d-announce ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Last Call Comments: draft-ietf-simple-filter-format
Last Call Comments: draft-ietf-simple-filter-format I have asked the XML Directorate to review this document. These comments are my own. The MIME type described in this document does not appear to have been submitted to the ietf-types list for review. That should happen before the IESG evaluates this document. The XML Schema includes several elements and attributes to allow extensions. There needs to be some text in the document describing the extensibility framework. There also needs to be some text added to the document to address versioning and/or what will need to be done in the future if the schema is changed and namespace conflicts need to be avoided. Section 4 appears to contain a small ABNF error, or at least something that may require clarification. The productions for element and elem-path are defined like this: expression = [ (elem-expr / attr-expr) 1*[oper (elem-expr / attr-expr)] ] elem-path = (element / *) 1*[/ / * / element] [* / element] My confusion is that a construct of the form [foo bar] describes optional items. 1* means that at least one instance is required. So when the spec says 1*[oper (elem-expr / attr-expr)] and 1*[/ / * / element], is it saying that the items are optional, or that at least one is required? Section 8.2 includes an XML instance that seems to be encapsulating information about the namespace registration request. As described in section 3.2 of RFC 3688, there really is no XML representation of a namespace identifier. While section 4 of RFC 3688 includes a field to register an XML instance, I don't believe that there's any XML to be registered when the template is being used to register a namespace URI. -Scott- ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: AdminRest: Finances and Accounting
From my read, there are several different aspects. The description of the sources of funds and the directing of deposits is probably over-constrained. I would hope that there is not a requirement specified by these documents for an actual IASA bank account. I doubt that the document needs to mandate quarterly transfers. At the same time, the IASA / IAD are intended to have reasonable discretion (with ISOC review and approval on a budgetary level) of how money is spent to support activities. If the funds are not earmarked at the ISOC level for IETF / IASA use, then it gets complicated to create the desired flexiblity. My guess is that we are indeed giving up the ability for ISOC to transparently cover bumps in exchange for greater control and visibility to the actual state of the funds. I would expect after a bit that this would actually help ISOC, as it would make explicit if the IASA / IAD are not doing a good job planning. Yours, Joel M. Halpern Not on of the document maintainers but someone trying to understand what it will turn out to mean. At 07:55 PM 11/17/2004, Fred Baker wrote: A question for those maintaining the document There is a fair bit of change in section five, regarding IASA funding. In a nutshell, it now says: - IETF has three revenue streams: * IETF meeting fees * Donations of various kinds designated to the IETF * ISOC funding derived from other sources - the first two get deposited in the IASA checkbook - the third gets deposited in quarterly lump payments - there is an intent to have built up enough money for the IASA to run for six months without receiving a dime, over a period of three years. All that sounds good on the surface, but it differs rather markedly from current ISOC accounting practice, and it seems to over-constrain the problem and its solution. Someone who knows more about accounting than I do will mention the difference between a cash accounting scheme and an accrual accounting scheme, the latter being more usual in corporate accounting. IETF does indeed have these present revenue sources. CNRI/Foretec currently collects IETF meeting fees and uses them pursuant to IETF meetings, databases, and teleconferences. ISOC accepts donations designated to IETF-related activities. ISOC also uses funds from other revenue sources (other donors) to further IETF purposes. ISOC places donations to the IETF in accounts so designated. When the money is spent usually on the RFC Editor, which is our largest single IETF-related expense - the revenue is recognized, and the books show both the revenue and the expense. The effect of section 5, if I am reading it correctly, is to present ISOC with an always-on expense ISOC immediately transfers any such money to IASA. The money is therefore immediately recognized as both revenue and an expense in the ISOC ledger and as a net deposit in the IASA checkbook. ISOC current practice with regard to other IETF (and ISOC) expenses is to pay them as bills are presented. Bills are not presented on nice neat quarterly boundaries; the insurance bill is paid annually, IAB telechats are paid out of the monthly phone bill, meeting expenses and other payments from the IETF Chair's Discretionary Budget are paid episodically, and so on. The current issues in the RFC Editor's office (into which I will not delve in detail; due to an accounting error, they have suddenly needed an infusion of cash) result in ISOC paying an unplanned and unbudgeted lump sum payment. In short, like any other ISOC bill, IETF-related expenses are paid as valid bills are received, sometimes by surprise. A significant part of IETF expenses will be in deposits for future meetings. Generally, the most expensive way to plan and pay for an excursion in a hotel or conference center is at the last minute. As a result, most organizations that plan conferences have deposits on hotels and such at least a year out. A quick look at http://www.icann.org/meetings/, for example, shows meetings paid for through next summer, and on in development in December 2005. When the document talks about a six-month reserve, I therefore have to ask: which six months of the year? Does this cover one planned meeting fee, or two? On an accrual basis, that's not much of an issue, but on a cash basis, it is a big one. The effect of section 5, if I am reading it correctly, is to transfer these budgetary bumps and grinds to the IASA rather than allowing the ISOC to help out, making oops, we're low on cash something that has to be discussed as opposed to ISOC simply backstopping things as we have heretofore agreed. By treating them on a cash basis rather than an accrual basis, this section seems maximize the pain they cause. I wonder whether the IETF would consider talking with ISOC's accounting office to normalize these issues now, and whether the problem really needs to be this tightly constrained? Regards,
Re: AdminRest: Finances and Accounting
Thanks for the followup, Fred! I think the number of changes in chapter 5 reflects quite a bit of uncertainty about what it should say... we (the IETF community, with ISOC) should work together on this to make sure it says neither too much nor too little. Some specifc points (my opinions): --On 17. november 2004 16:55 -0800 Fred Baker [EMAIL PROTECTED] wrote: A question for those maintaining the document? There is a fair bit of change in section five, regarding IASA funding. In a nutshell, it now says: - IETF has three revenue streams: * IETF meeting fees * Donations of various kinds designated to the IETF * ISOC funding derived from other sources - the first two get deposited in the IASA checkbook - the third gets deposited in quarterly lump payments - there is an intent to have built up enough money for the IASA to run for six months without receiving a dime, over a period of three years. [skipping description of how ISOC works] A significant part of IETF expenses will be in deposits for future meetings. Generally, the most expensive way to plan and pay for an excursion in a hotel or conference center is at the last minute. As a result, most organizations that plan conferences have deposits on hotels and such at least a year out. A quick look at http://www.icann.org/meetings/, for example, shows meetings paid for through next summer, and on in development in December 2005. When the document talks about a six-month reserve, I therefore have to ask: which six months of the year? Does this cover one planned meeting fee, or two? On an accrual basis, that's not much of an issue, but on a cash basis, it is a big one. Actually the words are: In normal operating circumstances, the IASA would look to have an operating reserve for its activities sufficient to cover 6-months of non-meeting operational expenses, plus twice the recent average for meeting contract guarantees. This is 6 months of the expenses that occur throughout the year (assuming, probably too blitely, that they are reasonably smooth) + some funds that allow us to schedule at least two more meetings, beyond the ones already committed - or that's how I read it, which may not be the intent of the writers (I would think that one meeting's guarantees would be enough). The effect of section 5, if I am reading it correctly, is to transfer these budgetary bumps and grinds to the IASA rather than allowing the ISOC to help out, making oops, we're low on cash something that has to be discussed as opposed to ISOC simply backstopping things as we have heretofore agreed. By treating them on a cash basis rather than an accrual basis, this section seems maximize the pain they cause. I think we need to find a reasonable way to budget expense stuff you sure make an accrual basis sound tempting, but we do have to have cash in hand too. One thing that I heard people say in commenting on budgeting was that the IETF needs to show budgetary responsibility too - we can't ask for the sky, and say it's ISOC's job to pay for it. The separation of accounts may also have been intended to show this - that the IETF, and IASA, has its own responsibility to behave responsibly wrt finances. But there may be better ways to express this than overconstraining our structure... I wonder whether the IETF would consider talking with ISOC's accounting office to normalize these issues now, and whether the problem really needs to be this tightly constrained? I think this is a very valuable piece of advice. I know that I don't know what I'm talking about when it comes to accounting methods I'd hoped that the transition team (once it's set up) could go into this - the IESG and IAB are hoping to finalize picking the transition team Monday of next week. ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: IASA BCP Section 5.3
At 11:04 PM 17/11/2004, Margaret Wasserman wrote: I have some comments on Section 5.3 of the IASA BCP, Other ISOC Support. The first paragraph of this section says: Other ISOC support shall be based on the budget process as specified in Section 6. ISOC will deposit the yearly amount (as agreed to in approved budget) in equal portions. At a minimum such deposits will be made quarterly. This seems unnecessarily restrictive. Not at all - it seems to me to be entirely necessary and appropriate in these circumstances. The IASA needs to operate like any other enterprise - it needs to manage its cash flow, and manage its overall financial position. Your depiction of the financial position makes this more and more like an operational department of ISOC with all funding management placed under the control of ISOC. Frankly this is not what I understand ISOC offered the IETF. The use of forward planning and timed periodic payments according to a documented schedule of such regular payments allows the IASA and ISOC to understand in advance the scale of commitments in terms of the budgetary process for the entire year, as well as being able to manage cash flow based once more on the foreknowledge of the points of money transfer from ISOC to IASA. The second paragraph in this section says: If ISOC directly funds any other IETF expenses, such as the IETF share of ISOC's liability insurance premium, this will be documented together with the other IASA accounts. I'm not really sure what this means... It means that there are single payments to an external entity that are for services provided to both ISOC and the IETF and in such case the document acknowledges that ISOC may undertake such payments (rather than the IASA) and in such cases the ISOC and IASA accounts would show the relevant apportionment of the payment. There are some complexities to this budgeting process that aren't captured in this document, and I don't think that they should be. However, calling out one particular point (such as insurance) really begs the question of why other things that fall into this category are not called out. I think that 'such as is a valid way of indicating this as an example of such a payment. I would see this as conventional use of the english language in this context. I would prefer that we simply delete this paragraph from the BCP. I believe that this is a valid point of documenting instances where the asset transfer to IASA is not explicit, the reason why, and the proposed accounting procedure to address this. Geoff ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: draft-farrel-rtg-morality-requirements-00.txt
At 08:15 PM 17/11/2004, Olaf M. Kolkman wrote: On Tue, 16 Nov 2004 15:57:37 -0800 Bob Hinden [EMAIL PROTECTED] wrote: We should be proactive and create a morality area in the IETF. The morality ADs can review and vote Discuss if the Morality Considerations section in drafts being reviewed by the IESG is not adequate. I nominate Bert! seconded. now to pass this to the nomcom. :-) Geoff ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
