Re: BCP-02: Financial statements and Audits
Margaret Wasserman wrote: "ISOC's finances are already audited by an independent auditing firm on a yearly basis." Yes -- but the yearly audit typically isn't focused on validating whether the restrictions described in this BCP are being carried out. If you're looking to certify the validity of the divisional accounting and the BCP restrictions, that would require additional work by the auditor. Kurt Erik Lindquist said: "Also, if you will need an audit, I don't expect you/us to want ISOC to conduct it." The ISOC yearly audit is conducted by an independent auditing firm, not by ISOC. ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: draft-ietf-iasa-bcp-02: section 3
--On 12. desember 2004 20:16 -0500 Scott Bradner <[EMAIL PROTECTED]> wrote: open from last version question - what is the backup mechanism for the IAD? (if the IAD were to get truck fade for example) I replied (Nov 22): Hire a new one no hot spare. I think IAOC has to be used for institutional memory in that case. I think the complexity/cost of a hot spare solution is rather high. Don't know if you consider this answered and addressed, or there is language you want to suggest. ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: draft-ietf-iasa-bcp-02: section 3.1 - ISOC involvement in bugdet
--On 12. desember 2004 20:33 -0500 Scott Bradner <[EMAIL PROTECTED]> wrote: open from last version This does not seem to admit to the possibility that the ISOC board might say 'wait a minute - you are asking for twice as much money as you got last year - we need to work with you to figure out a funding level that the ISOC can support' - i.e. it is not reasonable to assume that the ISOC BoT can carry out the above mentioned fiduciary responsibility without being able to engage in a dialogue over budget amounts. An open question in my mind is the degree of detail and itemization that the ISOC BoT needs to have to carry out the fiduciary responsibility i.e. it seems like the ISOC might have a hard time with its auditors if what it approved is just a line item for the IETF expenditures with no breakdown. But on the other hand we do not want the ISOC BoT to be arguing over how many copies of the newcomer's presentation handouts get made. We need to figure out a reasonable process that permits the ISOC to understand what the money is going for, be able to suggest alternatives if they might be more efficient, and have an ability to have input to the review of RFP responses without limiting the ability and authority of the IAD/IAHC to make the final decisions (as long as they stay within a budget) basically - no discussion between the ISOC and the IAD is called for in putting the budget together - that seems to be an error (if the assumption is that the ISOC reps on the IASA will be the dhisussion path then it would be good to state that - it is better to be clear than to have people in the future assume that the ISOC BoT just gets to approve a proposed IETF budget rather than think about it and teh implications for ISOC's overall budget I replied on November 22 (same reply as last message): I don't understand your comment - given that the timeline shown in the BCP has the ISOC BoT working with the IAD over the budget for 4-5 months (July to November/December), how can you think that there will not be a dialogue over that period of time? This applies to multiple places in your comments - you seem to have read "dialogue is not explicitly mentioned" as "no dialogue is allowed to take place", and I simply can't understand how you came to that reading. Remember also that the ISOC President is part of the IAOC. There will ALWAYS be channels for making suggestions. Harald ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: draft-ietf-iasa-bcp-02: section 7 - Removability - BCP
--On 12. desember 2004 21:08 -0500 Scott Bradner <[EMAIL PROTECTED]> wrote: open from last version I'd change "BCP publication" to "using its normal consensus processes" (BCP is no magic term and may not survive the newtrk process) I did not see anyone speak up to support the use of the term "BCP" yet the term (the meaning of which may change in the future) is still used I support it. We don't have a better formal term at the moment for "procedure document where formal assertion of IETF consensus is required". ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: draft-ietf-iasa-bcp-02: section 3.4 - meeting fees
--On 12. desember 2004 20:53 -0500 Scott Bradner <[EMAIL PROTECTED]> wrote: suggest changing "appropriate IASA account" to "appropriate IASA accounts" already raised by Fred and accepted by the editors. ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: draft-ietf-iasa-bcp-02: section 6 - budget process
--On 12. desember 2004 20:58 -0500 Scott Bradner <[EMAIL PROTECTED]> wrote: open from last version this document assumes a budget cycle of ISOC which does not match reality - I would suggest that this document needs to key of off the ISOC budget cycle and say that the various IAOC & IAD milestones must be at least X days before the ISOC budget approval time Scott I think that's what the current document's dates tries to say, using ISOC input as to when their budget approval times are. We may have misunderstood ISOC's input here. This points out to me that the section may need more flexibility - as experience grows with the budget process, the IAOC may want to change it - and I think they should - using the BCP text as a guideline, not a straitjacket. Harald ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: notes on draft-ietf-iasa-bcp-02
I have attempted to reply to most of the issues where I do not understand the comment, think it has been addressed before, or think that there is a consensus pointing in another direction. The sheer number of messages looks daunting - but as Scott says, this simplifies tracking them. Apologies if this overloads people's mailboxes a bit. Harald --On 12. desember 2004 20:10 -0500 Scott Bradner <[EMAIL PROTECTED]> wrote: I'm about to send a series of notes abmut draft-ietf-iasa-bcp-02 some of these are left over from comments I made on teh earlier version but have not been addressed in -02 others are new comments/suggestions I'll put them in seperat messages to be easier to track Scott ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: draft-ietf-iasa-bcp-02: section 3.4 - appeals
Reminder: current text of appeals is this: If someone believes that the IAOC has violated the IAOC rules and procedures, he or she can ask the IETF leadership to investigate the matter, using the same procedure as is used for appeals of procedural issues in the IETF, starting with the IESG. If the IESG, IAB or the ISOC Board of Trustees find that procedures have been violated, they may advise the IAOC, but do not have authority to overturn or change a decision of the IAOC. The IAOC plays no role in appeals of WG Chair, IESG, or IAB decisions. This is considerably restricted from version -01, based in part on your previoius comments on that version. I don't see how to interpret your current comments in relation to this text, since: - IAD decisions cannot be appealed - Only procedure violations can be appealed - The bodies appealed to can only advise the IAOC, they cannot (for instance) overturn a contract. Indeed, I wonder if we have gone too far in limiting the power of appeal in this version (see others' comments). Could you please help me understand whether you think the current text *still* allows too many frivolous appeals and too much power to the appealant? Harald --On 12. desember 2004 20:50 -0500 Scott Bradner <[EMAIL PROTECTED]> wrote: open from last version I think that the text on appeals is still not clear enough (based on other messages to the list, other people agree) I am very leary of any unlimited ability for IAD (or IAOC) decisions to be appealed - anything like that would be a too easy DoS vector I am most worried about any ability to appeal a decision to award a contract (for a function, for consulting, or for equipment) - I do not think I should be able to appeal if the IAD decided buy a Windows computer just because I happen to think that Macs are better/safer - I do not think that the looser in a bidding process should be able to appeal the IAD selecting someone other than the lowest cost bidder (because, for example the lowest cost bidder is a deadbeat) during the discussion I have come to the conclusion that we need something more than the ability to racal the members of the IAOC - maybe the ability to appeal with a claim that a published evaluaion process was not followed - but I'd not like any such appeal to be able to easily (or at all) cancel a signed contract (there might be significant liabilities if that were possible) I do not now have any suggestion as to wording but I do not see that this issue is closed Scott ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: draft-ietf-iasa-bcp-02: section 3.4 - IAOC Decision Making
--On 12. desember 2004 20:38 -0500 Scott Bradner <[EMAIL PROTECTED]> wrote: open from last version I think it must be made clear that all IAOC decision making involves all IAOC members then in office - not just a subset that might show up at a meeting or on a phone call maybe add: "All IAOC decision making includes all IAOC members then in office." I cannot find a previous message from you with the word "subset" in it, but you may have used some other phrase - but I disagree with your proposal; I don't think the IAOC should be completely paralyzed by one member being on holiday, ill or for other reasons unable to participate. This is usually handled by quorum rules. I think the IAOC should set those (and publish them). Harald ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: draft-ietf-iasa-bcp-02: section 7 - Removability
--On 12. desember 2004 21:11 -0500 Scott Bradner <[EMAIL PROTECTED]> wrote: how about adding text that says the ISOC can blow the bolts with the same kind of notice? Does ISOC want that, or need it? (see Pete Resnick's thread). (I'd be happy to add it if requested by ISOC, but I don't feel competent to speak on ISOC's behalf) ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: BCP-02: Financial statements and Audits
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2004-12-13, at 08.41, Bernard Aboba wrote: > Margaret Wasserman wrote: > > "ISOC's finances are already audited by an independent auditing firm > on a > yearly basis." > > Yes -- but the yearly audit typically isn't focused on validating > whether > the restrictions described in this BCP are being carried out. If > you're > looking to certify the validity of the divisional accounting and the > BCP > restrictions, that would require additional work by the auditor. > > Kurt Erik Lindquist said: > > "Also, if you will need an audit, I don't expect you/us to want ISOC to > conduct it." > > The ISOC yearly audit is conducted by an independent auditing firm, > not by ISOC. Yes. I think I meant the same as above. However that can be part of the ISOC audit, or not. I think that is up to IAOC to decide as they would be receiving the audit. - - kurtis - -BEGIN PGP SIGNATURE- Version: PGP 8.1 iQA/AwUBQb16jqarNKXTPFCVEQIVUgCghKJHOXJz5imvdyg2jiIHpUd6AE0AoPBu w3N+3ZE/JeD7/7eHWzcpt5Vl =eBgu -END PGP SIGNATURE- ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: draft-ietf-iasa-bcp-02: section 3
add something like this to section 3 The IASA consists initially of a single full-time ISOC employee, the IETF Administrative Director (IAD), an officer entitled to act on behalf of the IASA at the direction of the IAOC. The IASA temporally may act as the IAD if there is no IAD or the IAD is unavailable. ... Scott --- >From [EMAIL PROTECTED] Mon Dec 13 02:55:30 2004 X-Original-To: [EMAIL PROTECTED] Delivered-To: [EMAIL PROTECTED] Date: Mon, 13 Dec 2004 05:42:18 +0100 From: Harald Tveit Alvestrand <[EMAIL PROTECTED]> To: Scott Bradner <[EMAIL PROTECTED]>, [EMAIL PROTECTED] Subject: Re: draft-ietf-iasa-bcp-02: section 3 In-Reply-To: <[EMAIL PROTECTED]> References: <[EMAIL PROTECTED]> X-Mailer: Mulberry/3.1.5 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Virus-Scanned: by amavisd-new at alvestrand.no --On 12. desember 2004 20:16 -0500 Scott Bradner <[EMAIL PROTECTED]> wrote: > > open from last version > >> question - what is the backup mechanism for the IAD? (if the IAD were >> to get truck fade for example) > I replied (Nov 22): > Hire a new one no hot spare. I think IAOC has to be used for > institutional memory in that case. I think the complexity/cost of a hot spare solution is rather high. Don't know if you consider this answered and addressed, or there is language you want to suggest. ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: draft-ietf-iasa-bcp-02: section 7 - Removability
> Does ISOC want that, or need it? I do not know but symmetry seems to be a good thing Scott --- Date: Mon, 13 Dec 2004 06:41:19 +0100 From: Harald Tveit Alvestrand <[EMAIL PROTECTED]> To: Scott Bradner <[EMAIL PROTECTED]>, [EMAIL PROTECTED] Subject: Re: draft-ietf-iasa-bcp-02: section 7 - Removability --On 12. desember 2004 21:11 -0500 Scott Bradner <[EMAIL PROTECTED]> wrote: > > how about adding text that says the ISOC can blow the bolts > with the same kind of notice? Does ISOC want that, or need it? (see Pete Resnick's thread). (I'd be happy to add it if requested by ISOC, but I don't feel competent to speak on ISOC's behalf) ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: draft-ietf-iasa-bcp-02: section 7 - Removability - BCP
Harald sez: > We don't have a better formal term at the moment for "procedure document > where formal assertion of IETF consensus is required". why not just say that? Removability: While there is no current plan to transfer the legal and financial home of the IASA to another corporation, the IASA shall be structured to enable a clean transition in the event that the IETF community decides, through the publication of a procedure document where a formal assertion of IETF consensus is required. (currently called BCP) ... Scott --- Date: Mon, 13 Dec 2004 06:39:37 +0100 From: Harald Tveit Alvestrand <[EMAIL PROTECTED]> To: Scott Bradner <[EMAIL PROTECTED]>, [EMAIL PROTECTED] Subject: Re: draft-ietf-iasa-bcp-02: section 7 - Removability - BCP --On 12. desember 2004 21:08 -0500 Scott Bradner <[EMAIL PROTECTED]> wrote: > > open from last version > >> I'd change "BCP publication" to "using its normal consensus processes" >> (BCP is no magic term and may not survive the newtrk process) > > > I did not see anyone speak up to support the use of the term "BCP" > yet the term (the meaning of which may change in the future) is still > used I support it. We don't have a better formal term at the moment for "procedure document where formal assertion of IETF consensus is required". ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: draft-ietf-iasa-bcp-02: section 3.4 - appeals
I don't see how to interpret your current comments in relation to this text, since: - IAD decisions cannot be appealed - Only procedure violations can be appealed - The bodies appealed to can only advise the IAOC, they cannot (for instance) overturn a contract. Indeed, I wonder if we have gone too far in limiting the power of appeal in this version (see others' comments). I personally think that we have gone too far. I don't think that we want to set-up a situation where the only way the community can speak forcefully if it doesn't like an IAOC decision is to recall people... That is too high a bar of entry for expressing community disagreement with the decisions/conduct of a (set of) individual(s) regarding a single incident. Personally, I think that the concern about DoS attacks is unfounded. We don't require multiple signatures for appeal of WG decisions, and that hasn't resulted in DoS attacks... I hope that more IETF folks will continue to feel passionately about the standards process than about administrative decisions. And, I think that we could say something to address the concern about contract signing, etc. Maybe: In cases where appeals concern legally-binding actions of the IAOC (hiring, signed contracts, etc.), the bodies handling the appeal may advise the IAOC, but are not authorized to make or unmake any legally binding agreements on the part of IASA. This is similar to the wording that doesn't allow the IAB to approve a document as part of an appeal response. Margaret ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: draft-ietf-iasa-bcp-02: section 6 - runaway budgets
Scott Bradner wrote: open from last version the document says: August 1: The IAOC approves the budget proposal for IETF purposes, after any appropriate revisions. As the ISOC President is part of the IAOC, the IAOC should have a preliminary indication of how the budget will fit with ISOC's own budgetary expectations. The budget proposal is passed to the ISOC Board of Trustees for review in accordance with their fiduciary duty. this section also implies that the ISOC President/CEO and BoT have no say in the size of the IETF budget which would not let the ISOC BoT exercise its fiduciary responsibilities (i.e. just saying that the ISOC prez will get a hint about a runaway budget is not enough - the budgets have to fit within economic reality - it will do no one any good if the budget that gets to the ISOC BoT gets turned down because it would bankrupt ISOC) budget development MUST be a cooperative procepss between the ISOC and the IAD/IAOC it can not be dictated by either party alone That is certainly true in the real world. The draft could be read to suggest that the IETF will order up a budget of arbitrary size, which we all know is not how the real world works. But do we really need to spell out the iterative process of budget development? Brian ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: draft-ietf-iasa-bcp-02: section 3
Margaret corrects: > s/The IASA temporarily/The IAOC temporarily ? opps - too many random character strings :-) > Or perhaps you meant the IAOC chair? I did not, but that would be fine - I just do not want to see an inability to act Scott ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: draft-ietf-iasa-bcp-02: section 5.4 - oher ISOC support
Scott Bradner wrote: open from last version this is far to proscriptive - I do not think that the authors of this document or the general IETF community are accounts - lets establish the requirement that funds be available when needed but not try to dictate the best way for that to be done - let the accountants figure that out a simple point is that the document asks for quarterly deposits for a process that has peak funding needs 3 times a year - that does not mesh I did not see anyone speak up in favor of mandating quarterly deposits for an effort that not a quarterly effort yet this sillyness is still in the document I've gone various ways on this, but I think that imposing a duty of regular payment on ISOC is appropriate - so that paying the IETF late doesn't become a tempting cash-flow management tool. I would be happy with a phrasing that asks for at least 3 payments per year. Brian ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: Assuring ISOC commitment to AdminRest
Pete Resnick <[EMAIL PROTECTED]> writes: > On 12/12/04 at 9:06 PM +0100, Bert (Bert) Wijnen wrote: > >> This debate between John and Pete seems to be at such an abstract >> meta level to me, that I have difficulty to try and see what it >> means for the IAS BCP doc that I thinkwe are trying to get consensus >> on. >> >> As I said, it could be just me, but I seem unable to map it to any >> issue(s) with the curremt text in rev 02 of the doc. > > Ignoring John's caricature of my position: I think I am suggesting an > addition to the current BCP which more or less says: > > "This BCP will take effect upon adoption of the BCP by the IESG and > the concurrent < interesting way the adoption of the relationship by ISOC>>" > > I also suggested to insert for the part in <<>>: > > "adoption of an ISOC by-law signifying the adoption of the principles > laid out in this BCP." > > That's it. I think that language like this is a pretty important part of the equation. We've had a lot of discussion about how ISOC agrees to something with an organization that doesn't formally exist, and this seems to be exactly the right kind of answer... -Ekr ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: draft-ietf-iasa-bcp-02: section 5.4 - oher ISOC support
Brian sez: > I've gone various ways on this, but I think that imposing a duty of > regular payment on ISOC is appropriate - so that paying the IETF > late doesn't become a tempting cash-flow management tool. I would > be happy with a phrasing that asks for at least 3 payments per > year. I agree about imposing a duty for regular payments - and if it has to be made more specific then "at least 3 times per year" is the least bad way to do so Scott ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: draft-ietf-iasa-bcp-02: section 3.1 - ISOC involvement in bugdet
and I'd like it *very* clear that a dialogue is part of the process i.e. I'd like to see it written down so that no one has any misunderstanding now or in the future that a dialogue is part of teh process Scott -- Date: Mon, 13 Dec 2004 05:47:00 +0100 From: Harald Tveit Alvestrand <[EMAIL PROTECTED]> To: Scott Bradner <[EMAIL PROTECTED]>, [EMAIL PROTECTED] Subject: Re: draft-ietf-iasa-bcp-02: section 3.1 - ISOC involvement in bugdet --On 12. desember 2004 20:33 -0500 Scott Bradner <[EMAIL PROTECTED]> wrote: > > open from last version > >> This does not seem to admit to the possibility that the ISOC board might >> say 'wait a minute - you are asking for twice as much money as you got >> last year - we need to work with you to figure out a funding level that >> the ISOC can support' - i.e. it is not reasonable to assume that the >> ISOC BoT can carry out the above mentioned fiduciary responsibility >> without being able to engage in a dialogue over budget amounts. >> >> An open question in my mind is the degree of detail and itemization that >> the ISOC BoT needs to have to carry out the fiduciary responsibility >> i.e. it seems like the ISOC might have a hard time with its auditors if >> what it approved is just a line item for the IETF expenditures with no >> breakdown. But on the other hand we do not want the ISOC BoT to be >> arguing over how many copies of the newcomer's presentation handouts get >> made. We need to figure out a reasonable process that permits the ISOC >> to understand what the money is going for, be able to suggest >> alternatives if they might be more efficient, and have an ability to >> have input to the review of RFP responses without limiting the ability >> and authority of the IAD/IAHC to make the final decisions (as long as >> they stay within a budget) > > basically - no discussion between the ISOC and the IAD is called > for in putting the budget together - that seems to be an error (if > the assumption is that the ISOC reps on the IASA will be the > dhisussion path then it would be good to state that - it is > better to be clear than to have people in the future assume that > the ISOC BoT just gets to approve a proposed IETF budget rather than > think about it and teh implications for ISOC's overall budget I replied on November 22 (same reply as last message): > I don't understand your comment - given that the timeline shown in the > BCP has the ISOC BoT working with the IAD over the budget for 4-5 months > (July to November/December), how can you think that there will not be a > dialogue over that period of time? > > This applies to multiple places in your comments - you seem to have read > "dialogue is not explicitly mentioned" as "no dialogue is allowed to take > place", and I simply can't understand how you came to that reading. > > Remember also that the ISOC President is part of the IAOC. There will > ALWAYS be channels for making suggestions. Harald ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: draft-ietf-iasa-bcp-02: section 6 - runaway budgets
Brian asks: > That is certainly true in the real world. The draft could be read to > suggest that the IETF will order up a budget of arbitrary size, which we > all know is not how the real world works. But do we really need to spell > out the iterative process of budget development? I hope not, but I think it would be good to mention that teh budget devlopment process involves a cooperative process boetween the ISOC and the IAD/IAOC. maybe a small change in section 2.2 would do the trick 3. The IAD and IAOC, in cooperation with the ISOC President/CEO and staff, shall develop an annual budget for the IASA. The budget must clearly identify all expected direct and indirect expenditures related to the IASA. ISOC, through its normal procedures, shall evaluate and adopt the IASA budget as part of ISOC's own budget process and commit to ensuring funds to support the approved budget. Scott ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: draft-ietf-iasa-bcp-02: section 5.4 - oher ISOC support
At 2:41 PM +0100 12/13/04, Brian E Carpenter wrote: I've gone various ways on this, but I think that imposing a duty of regular payment on ISOC is appropriate - so that paying the IETF late doesn't become a tempting cash-flow management tool. I would be happy with a phrasing that asks for at least 3 payments per year. Brian Brian, what can we pay late? We have to pay salaries, RFC Editor, meeting contracts, outsourcing contracts, insurance, etc. on time. This makes it sound like a deposit model rather than paying for expenses? Lynn ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: draft-ietf-iasa-bcp-02: section 5.4 - oher ISOC support
At 2:41 PM +0100 12/13/04, Brian E Carpenter wrote: Scott Bradner wrote: I've gone various ways on this, but I think that imposing a duty of regular payment on ISOC is appropriate - so that paying the IETF late doesn't become a tempting cash-flow management tool. I would be happy with a phrasing that asks for at least 3 payments per year. Instead of specifying a number of "payments" per year perhaps we could say something like: "ISOC will credit additional funds to the IASA accounts, as necessary to cover the approved budget."? Elsewhere it says that meeting fees and designated donations will be credited to the IASA account when they are received, so it seem as though these additional "payments" (credits?) would only be necessary if the IASA budget for the given period has not been covered by meeting fees and designated donations. Right? Margaret ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: draft-ietf-iasa-bcp-02: section 3
add something like this to section 3 The IASA consists initially of a single full-time ISOC employee, the IETF Administrative Director (IAD), an officer entitled to act on behalf of the IASA at the direction of the IAOC. The IASA temporally may act as the IAD if there is no IAD or the IAD is unavailable. ... s/The IASA temporarily/The IAOC temporarily ? Or perhaps you meant the IAOC chair? Margaret ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: draft-ietf-iasa-bcp-02: section 5.4 - oher ISOC support
Margaret suggests: > Instead of specifying a number of "payments" per year perhaps we > could say something like: "ISOC will credit additional funds to the > IASA accounts, as necessary to cover the approved budget."? > > Elsewhere it says that meeting fees and designated donations will be > credited to the IASA account when they are received, so it seem as > though these additional "payments" (credits?) would only be > necessary if the IASA budget for the given period has not been > covered by meeting fees and designated donations. Right? works for me ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: draft-ietf-iasa-bcp-02: section 3.4 - appeals
Margaret Wasserman wrote: Indeed, I wonder if we have gone too far in limiting the power of appeal in this version (see others' comments). I personally think that we have gone too far. I don't think that we want to set-up a situation where the only way the community can speak forcefully if it doesn't like an IAOC decision is to recall people... That is too high a bar of entry for expressing community disagreement with the decisions/conduct of a (set of) individual(s) regarding a single incident. Personally, I think that the concern about DoS attacks is unfounded. We don't require multiple signatures for appeal of WG decisions, and that hasn't resulted in DoS attacks... I hope that more IETF folks will continue to feel passionately about the standards process than about administrative decisions. I think that we need both some attention to the "DoS attack" as well as appeals process without having to recall people. And, I think that we could say something to address the concern about contract signing, etc. Maybe: In cases where appeals concern legally-binding actions of the IAOC (hiring, signed contracts, etc.), the bodies handling the appeal may advise the IAOC, but are not authorized to make or unmake any legally binding agreements on the part of IASA. This is similar to the wording that doesn't allow the IAB to approve a document as part of an appeal response. This text looks good, and solves both concerns. --Jari ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: IASA BCP -02 Designated Donations - section 5.3
> "JFC" == JFC (Jefsey) Morfin <[EMAIL PROTECTED]> writes: JFC> Tax aspects on donations will, most probaly in many JFC> countries, call for donations to a legally incorporated JFC> entity. What is the IETF legal entity I am to write on the JFC> check and then claim for resulting tax benefits for JFC> supporting research. No tax controller will buy that ISOC is JFC> an R&D lab. jfc The IETF is an engineering organization, not a research lab. Most of the funding will not go to activities that would traditionally be described as research. --Sam ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: IASA BCP -02 Designated Donations - section 5.3
At 5:46 AM -0800 12/13/04, Eric Rescorla wrote: As I read this section, the intention is to ensure that donors who wish their funds to be used by IASA can do so easily, rather than being forced to donate them to ISOC in general. I don't think this is actually an instance in which our interests are all entirely aligned, If we look at this as a partnership, I don't understand why not. If one looks at ISOC as only a funding mechanism for the IETF, this might seem to be the case. Our interests should be more aligned than simply financially. since it would obviously be more convenient for ISOC to have full discretion over the dispersal of funds, though it would provide fewer guarantees to IASA in terms of revenue flow. Could you explain a little further what flexibility this language removes? over 80% of ISOC's org. members donate less than $10K annually and managing these in a 'restricted accounting manner' requires more effort and overhead. Also, organizations/donors expect recognition appropriate to their contribution and that implies differing levels of value and distinction. And, language such as that in the BCP would require changes to our membership programs (reducing our flexibility wrt future program development) and consistent with other decisions to remove operational detail from the BCP, it seems as though this language should be removed as well. Finally, revamping membership/funding programs should not be done in a piecemeal manner and with the model proposed we risk drawing fairly arbitrary lines re designating support to the IETF vs. support to other ISOC/IETF (technical) education and policy programs. Lynn ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: draft-ietf-iasa-bcp-02: section 3
--On 13. desember 2004 07:47 -0500 Scott Bradner <[EMAIL PROTECTED]> wrote: add something like this to section 3 The IASA consists initially of a single full-time ISOC employee, the IETF Administrative Director (IAD), an officer entitled to act on behalf of the IASA at the direction of the IAOC. The IASA temporally may act as the IAD if there is no IAD or the IAD is unavailable. ... I'd perhaps suggest "the IASA may designate one of its members as an acting IAD if there is no IAD or the IAD is unavailable" - the IAD role is designed to be filled by a person, not a committee, and having a committee act in the role that it's overseeing conflates the levels. But I can certainly see any single IAOC member being unwilling or unable to take on the task, so perhaps it's better to name the committee as a whole. thoughts, folks? Harald ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: draft-ietf-iasa-bcp-02: section 3.1 - ISOC involvement in bugdet
--On 13. desember 2004 08:14 -0500 Scott Bradner <[EMAIL PROTECTED]> wrote: and I'd like it *very* clear that a dialogue is part of the process i.e. I'd like to see it written down so that no one has any misunderstanding now or in the future that a dialogue is part of teh process send text. I think it's unnecessary, but should do no harm. ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: draft-ietf-iasa-bcp-02: section 5.4 - oher ISOC support
--On 13. desember 2004 14:41 +0100 Brian E Carpenter <[EMAIL PROTECTED]> wrote: I did not see anyone speak up in favor of mandating quarterly deposits for an effort that not a quarterly effort yet this sillyness is still in the document I've gone various ways on this, but I think that imposing a duty of regular payment on ISOC is appropriate - so that paying the IETF late doesn't become a tempting cash-flow management tool. I would be happy with a phrasing that asks for at least 3 payments per year. I'd suggest some variant of "as budgeted". Harald ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
RE: Assuring ISOC commitment to AdminRest
At 03:08 PM 12/12/04 -0600, Pete Resnick wrote: "This BCP will take effect upon adoption of the BCP by the IESG and the concurrent <>" The usual way this is done, by ISOC, is by resolution; note that the statement you proposed is in the form of a resolution. For examples, you might review 96-11 and 96-12 in http://www.isoc.org/isoc/general/trustees/resltn-complete.shtml. 96-11 has been updated several times as the IETF has updated the relevant documents; 96-12 remains a fundamental guiding principle. The most recent was this past summer: ISOC accepted its responsibilities wrt RFC 3777 in an email ballot closing on 23 August. RESOLVED: The ISOC BoT accepts and approves of the IETF process entitled "IAB and IESG Selection, Confirmation, and Recall Process: Operation of the Nominating and Recall Committees" and set forth in RFC 3777, and accepts its responsibilities as described in that document. A few weeks later, the ISOC CEO named the new chair of the IETF nominating committee, which is operating on that basis. The way resolutions - or bylaw changes - come to pass is this: those who want them (in the case of what you are proposing, the IETF) formulates the resolution required, and engages in dialog with the ISOC Board, usually in person at a board meeting. Having convinced the ISOC Board that this is good for the IETF, good for ISOC, and good for all of ISOC's constituencies, someone calls the question and we vote. See http://www.isoc.org/isoc/general/trustees/bylaws.shtml. ISOC is very interested in having the IETF restructuring effort succeed. Its history suggests that if necessary it will scale back everything else it does, and risk upsetting all of its other communities, and conduct major fund-raising activities to meet the IETF's needs. I guess the discussion I have heard concerning doomsday scenarios is baffling to me for this reason if none other - there is no historical basis, and there is quite a bit of real history including places where divergence of interests might have been predicted. If a resolution reaffirming 96-12 is needed to calm IETF insecurities, we will have a board meeting following the March IETF meeting. The necessary dialog can take place and such a resolution can happen if the IETF requests it and participates in it. ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: IASA BCP -02 Designated Donations - section 5.3
At 16:38 13/12/2004, Sam Hartman wrote: > "JFC" == JFC (Jefsey) Morfin <[EMAIL PROTECTED]> writes: JFC> Tax aspects on donations will, most probaly in many JFC> countries, call for donations to a legally incorporated JFC> entity. What is the IETF legal entity I am to write on the JFC> check and then claim for resulting tax benefits for JFC> supporting research. No tax controller will buy that ISOC is JFC> an R&D lab. jfc The IETF is an engineering organization, not a research lab. Most of the funding will not go to activities that would traditionally be described as research. I am afraid this is not exact for two reasons. (1) I target by what is not covered by the "most" (2) this is US nexus, each country has its own laws. The point is not to dispute the international environment but to know the name on the check. jfc --Sam ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: Copying conditions
Simon Josefsson wrote: 1. Everyone is free to copy and distribute the official specification for an open standard under an open source license. I would include "modify" in this clause, or clarify exactly which license you are talking about (e.g., GNU Free Documentation License). The GFDL is not an open-source or free software licence. http://people.debian.org/~srivasta/Position_Statement.xhtml http://www.opensource.org/licenses/index.html ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: draft-ietf-iasa-bcp-02: section 3
Brian suggests: > Committees generally do a lousy job as managers. How about "the IAOC may > temporarily assign the IAD's duties to individual members of the IAOC" ? that would work for me Scott ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: draft-ietf-iasa-bcp-02: section 3
Harald Tveit Alvestrand wrote: --On 13. desember 2004 07:47 -0500 Scott Bradner <[EMAIL PROTECTED]> wrote: add something like this to section 3 The IASA consists initially of a single full-time ISOC employee, the IETF Administrative Director (IAD), an officer entitled to act on behalf of the IASA at the direction of the IAOC. The IASA temporally may act as the IAD if there is no IAD or the IAD is unavailable. ... I'd perhaps suggest "the IASA may designate one of its members as an acting IAD if there is no IAD or the IAD is unavailable" - the IAD role is designed to be filled by a person, not a committee, and having a committee act in the role that it's overseeing conflates the levels. But I can certainly see any single IAOC member being unwilling or unable to take on the task, so perhaps it's better to name the committee as a whole. thoughts, folks? Committees generally do a lousy job as managers. How about "the IAOC may temporarily assign the IAD's duties to individual members of the IAOC" ? Brian ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Fw: New Last Call: 'Tags for Identifying Languages' to BCP
> So, I think Bruce has identified a valid issue here. I personally would
> not have characterized it as greatly exacerbating, though, as the issue
> was present in RFC 3066: private-use tags did not need to be registered
> in RFC 3066, so there was no way in implementation could be written with
> certain knowledge that tags beyond some given length would not be
> encountered.
As you say, the situation is no different now than in RFC 3066 in terms of
the possible length. I am somewhat sympathetic to the idea of having some
total limit (except for the late date for the proposed change). However, we
got considerable pushback on having RFC 3066bis make any previously valid
RFC3066 tag be invalid, and any length restriction would do that.
âMark
- Original Message -
From: "Peter Constable" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Friday, December 10, 2004 17:03
Subject: RE: New Last Call: 'Tags for Identifying Languages' to BCP
Resuming my comments:
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:ietf-languages-
> [EMAIL PROTECTED] On Behalf Of Bruce Lilly
[snip]
> Specifically, the draft allows, and RFC 3066 disallows:
>subtags more than 8 octets in length
>hyphens which do not separate subtags
>zero-length subtags
>primary tags which are not purely alphabetic
> Curiously, all of those are permitted by the draft ABNF
> production "grandfathered"...
The "grandfathered" production in the current draft is
grandfathered = ALPHA *(alphanum / "-")
which does permit the sequences claimed by Bruce (except for
not-purely-alphabetic primary sub-tags), syntactically; but the set of
tags available for use is constrained by more than the ABNF syntax
alone: the acceptable productions for each sub-tag must either be taken
from one of the source standards or be registered. This is no different
from RFC 3066, so it is no more of a problem in this specification than
it was in RFC 3066.
It might be that the wording in 2.2 could be tightened up to eliminate
any possible question regarding the source for "grandfathered"
productions. Maybe it's not as obvious to someone coming to this cold as
it for us who have been discussing it for the past year.
Alternately, there's no reason why the "grandfathered" production
shouldn't be composed exactly to match what was used in RFC 3066:
grandfathered = 1*8ALPHA *("-" 1*8alphanum)
So, perhaps there is room for technical improvement, but there are not
any serious problems IMO -- certainly nothing as serious as the tone of
Bruce's conveyed.
> I see no reason for the ABNF to permit such content as is
> forbidden by RFC 3066; the actual ABNF for what RFC 3066
> permits is contained within 3066, and could have been directly
> incorporated rather than producing a "grandfathered"
> production which opens up several cans of worms.
This vastly overstates the problem. There is no can of worms unless it
exists in tags currently available under RFC 3066.
> One defect related to tag length in RFC 3066 is not remedied
> by the draft; indeed the problem is greatly exacerbated...
> Unfortunately, a language- tag's length is unlimited by
> the ABNF in RFC 3066 (due to an unlimited number of subtags)
> and in the draft...
> In particular, tags other than private-use tags with more than
> two subtags require registration under RFC 3066 rules, and it
> is a trivial matter to determine the longest registered tag.
> The draft, however, encourages use of more subtags as well as
> removal of the subtag length upper bound; moreover, it permits
> infinite numbers of subtags without requiring registration of
> the resulting complete tag.
Bruce states incorrectly that there is no upper bound on the length of
sub-tags. His other concern, on the overall length of complete tags, is
valid, however: in terms of the ABNF syntax for both RFC 3066 and RFC
3066bis, infinite-length productions are possible, but RFC 3066 would
require registration of complete non-private-use tags while RFC 3066bis
does not.
There are three open doors for infinite-length productions in the ABNF
of the current draft:
- unlimited extlang sub-tags
- unlimited variant sub-tags
- the number of possible extensions is limited to 25, but the length of
extensions is unlimited
We could impose some upper limits on these things; e.g.
Language-Tag = ... *8("-" extlang) ... *8("-" variant) ... 1*25("-"
extension)
...
extension = singleton 1*8("-" 2*8alphanum)
If we also imposed limits on the length of private-use tags and defined
the grandfathered production in a way that made clear there was an upper
limit for those, then we could end up eliminating an issue that had
existed in RFC 3066.
So, I think Bruce has identified a valid issue here. I personally would
not have characterized it as greatly exacerbating, though, as the issue
was present in RFC 3066: private-use tags did not need to be registered
in RFC 3066, so there was no way in implementation could b
Re: New Last Call: 'Tags for Identifying Languages' to BCP
> The ABNF is an expression of the grammar that
describes the set of all valid tags.
No, this is simply incorrect. You cannot expect that any implementation that
simply does the ABNF is conformant. There are a great many constraints on
the tags that are not in the ABNF grammar, that are clearly required in any
reading of the text. Most of these *cannot* be encompassed in any ABNF
grammar. There are a few that could be expressed in the ABNF; some at little
cost, some with a great deal of complication. This is not a technical
problem for the draft.
> as reasonable as the current worst-case of 11 octets.
Also simply untrue. You seem not to be reading all the messages on this
subject. Look at the ABNF for RFC 3066. There is *no* limit in the ABNF
there!
"
The syntax of this tag in ABNF [RFC 2234] is:
Language-Tag = Primary-subtag *( "-" Subtag )
Primary-subtag = 1*8ALPHA
Subtag = 1*8(ALPHA / DIGIT)
"
-- http://www.ietf.org/rfc/rfc3066.txt?number=3066
âMark
- Original Message -
From: "Bruce Lilly" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Friday, December 10, 2004 20:39
Subject: Re: New Last Call: 'Tags for Identifying Languages' to BCP
> RE: New Last Call: 'Tags for Identifying Languages' to BCP
> Date: 2004-12-10 20:03
> From: "Peter Constable" <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED]
> CC: [EMAIL PROTECTED]
>
> Resuming my comments:
> > Specifically, the draft allows, and RFC 3066 disallows:
> > subtags more than 8 octets in length
> > hyphens which do not separate subtags
> > zero-length subtags
> > primary tags which are not purely alphabetic
> > Curiously, all of those are permitted by the draft ABNF
> > production "grandfathered"...
>
> The "grandfathered" production in the current draft is
>
> grandfathered = ALPHA *(alphanum / "-")
>
> which does permit the sequences claimed by Bruce (except for
> not-purely-alphabetic primary sub-tags),
No exception. "alphanum" is ALPHA / DIGIT. In plain
English, "grandfathered" as defined in the draft is a letter
followed by any number of letters, digits, and/or hyphens, in
any order. And that includes "a123-xyz" as I initially stated,
and clearly 1, 2, and 3 are digits.
> syntactically; but the set of
> tags available for use is constrained by more than the ABNF syntax
> alone: the acceptable productions for each sub-tag must either be taken
> from one of the source standards or be registered.
So what? The ABNF is an expression of the grammar that
describes the set of all valid tags. If the grammar permits
"y-", "a123-xyz", etc. (and it does) then a parser
claiming to parse language tags as defined by that ABNF
must be able to parse such tags. That is, the ABNF-
specified grammar imposes requirements on parsers. If
one doesn't intend to impose such requirements, the
ABNF specifying the grammar should be changed
accordingly.
> This is no different
> from RFC 3066, so it is no more of a problem in this specification than
> it was in RFC 3066.
It is a very different grammar from RFC 3066, imposing
very different requirements on parsers.
> It might be that the wording in 2.2 could be tightened up to eliminate
> any possible question regarding the source for "grandfathered"
> productions.
It's not a matter of wording; the problem is with the ABNF.
> Alternately, there's no reason why the "grandfathered" production
> shouldn't be composed exactly to match what was used in RFC 3066:
>
> grandfathered = 1*8ALPHA *("-" 1*8alphanum)
I believe I said as much (though one then needs to look
at reduce/reduce conflicts implied by the revised grammar):
> > I see no reason for the ABNF to permit such content as is
> > forbidden by RFC 3066; the actual ABNF for what RFC 3066
> > permits is contained within 3066, and could have been directly
> > incorporated rather than producing a "grandfathered"
> > production which opens up several cans of worms.
>
> This vastly overstates the problem. There is no can of worms unless it
> exists in tags currently available under RFC 3066.
I referred to the additional requirements imposed on
parsers, as well as the unlimited tag length permitted.
> > One defect related to tag length in RFC 3066 is not remedied
> > by the draft; indeed the problem is greatly exacerbated...
>
> > Unfortunately, a language- tag's length is unlimited by
> > the ABNF in RFC 3066 (due to an unlimited number of subtags)
> > and in the draft...
>
> > In particular, tags other than private-use tags with more than
> > two subtags require registration under RFC 3066 rules, and it
> > is a trivial matter to determine the longest registered tag.
> > The draft, however, encourages use of more subtags as well as
> > removal of the subtag length upper bound; moreover, it permits
> > infinite numbers of subtags without requiring registration of
> > the resulting complete tag.
>
> Bruce states incorrectly that there is no upper bound on the length of
> sub-tags.
Look again at the draft
Re: draft-ietf-iasa-bcp-02: section 5.4 - oher ISOC support
Lynn St.Amour wrote: At 2:41 PM +0100 12/13/04, Brian E Carpenter wrote: I've gone various ways on this, but I think that imposing a duty of regular payment on ISOC is appropriate - so that paying the IETF late doesn't become a tempting cash-flow management tool. I would be happy with a phrasing that asks for at least 3 payments per year. Brian Brian, what can we pay late? We have to pay salaries, RFC Editor, meeting contracts, outsourcing contracts, insurance, etc. on time. This makes it sound like a deposit model rather than paying for expenses? Well, I actually don't know - I am thinking in the abstract about what might go wrong at some unknown point in the future. Brian ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: Ietf-languages Digest, Vol 24, Issue 5
Bruce Lilly scripsit: > It's not clear to me that the proposal will provide protection > against the whims of politicians. If the definition of "CS" as > a country code changes again under the proposed scheme, > how is one to determine specifically what some archived > language-tag referred to at some point in time? I'm not > particularly concerned about that problem, as I am resigned > to instability associated with anything specified by politicians > (and that includes the UN region codes). The U.N. Statistics Division are only "politicians" in the sense that IETF WG members are. They are, in fact, statisticians. Their track record for stability is considerably longer than the IETF's. > But if the proposed new registry's description of "CS" says > "foo" and the ISO standard code list says "bar", what's > an implementor supposed to present to a user as *the* > description associated with "CS"? The former. That's the whole point of having a registry. > One possibility would be two description fields. Why two? There are 6000 languages spoken on Earth, of which perhaps 600 have a standard written form. What is supposed to be privileged about English and French? > Eliminating bilingual descriptions for the language, > country (and UN region) codes leaves implementors > in a quandary. Only for those implementers to whom English and French, but no other language, is essential. > ABNF from the draft: You're technically right, but your underlying claim (that RFC 3066 tags are bounded in length) is false, as has been shown, and the "grandfathered" production is only used to match certain existing registered RFC 3066 tags as they appear in the registry. -- "Do I contradict myself?John Cowan Very well then, I contradict myself.[EMAIL PROTECTED] I am large, I contain multitudes. http://www.ccil.org/~cowan --Walt Whitman, Leaves of Grass http://www.reutershealth.com ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: draft-ietf-iasa-bcp-02: section 5.4 - oher ISOC support
Scott Bradner wrote: Margaret suggests: Instead of specifying a number of "payments" per year perhaps we could say something like: "ISOC will credit additional funds to the IASA accounts, as necessary to cover the approved budget."? Elsewhere it says that meeting fees and designated donations will be credited to the IASA account when they are received, so it seem as though these additional "payments" (credits?) would only be necessary if the IASA budget for the given period has not been covered by meeting fees and designated donations. Right? works for me I can live with this Brian ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: New Last Call: 'Tags for Identifying Languages' to BCP
Bruce Lilly scripsit: > Moreover, the point is that countries do change, and that use > of country codes (as provided for in RFC 3066 and in the > proposed draft) carries with it the inherent instability > which is characteristic of politics. A quest for "stability" > of countries seems Quixotic and oxymoronic. Of course countries change, and then the numeric country codes change as well. The point is that the alpha codes change for political reasons when there has been *no* change in the underlying country: Romania's 3-alpha code changed from ROM to ROU without any change in Romania at all. The CS case is particularly gratuitous, as its denotation changed from "Czechoslovakia" (a no longer existent country) to "Serbia and Montenegro" (a newly created country). > A related problem with the use of country codes in language > tags is that there is not necessarily an inherent relationship > between language and country borders. Of course not. But for the most part, variations in orthography do tend to follow national boundaries, since orthography in many languages is either de jure or de facto a national matter. > As far as I can tell, > the draft doesn't really deal with the issue of changing borders > or changing country names -- it merely pretends that these > things don't happen by attempting to declare a snapshot of the > status at some point in time as being valid for all time. No, it attempts to freeze the code-to-country mapping at a single point. New countries or changes in old countries should involve only the additions of codes, not the reuse of old codes. > Where is the implementor supposed to get the *official* > translation for display? I don't know. Where is the implementor supposed to get the official German, or Catalan, or Mandarin translations? Not in the ISO registry, for sure. To say nothing of the cases where no official translations exist. > > There are 6000 languages spoken on Earth, of which > > perhaps 600 have a standard written form. > > ISO 639 lists about 650, not precisely 6000. ISO 639-2 is deliberately incomplete. The current draft of ISO 639-3, which is not yet an IS, lists over 7000 languages. > It might be worthwhile considering the differences in the > way languages tags are used, by whom they are used, and for > what purpose. There may well be a substantial difference > between use of a tag to represent an obscure dialect of a > dead language in a research paper vs. tagging a piece of > text in one of the core Internet protocols such as SMTP. That count does not include dead languages. Whether it includes dialects is a matter of terminology. -- Deshil Holles eamus. Deshil Holles eamus. Deshil Holles eamus. Send us, bright one, light one, Horhorn, quickening, and wombfruit. (3x) Hoopsa, boyaboy, hoopsa! Hoopsa, boyaboy, hoopsa! Hoopsa, boyaboy, hoopsa! -- Joyce, Ulysses, "Oxen of the Sun" [EMAIL PROTECTED] ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
RE: New Last Call: 'Tags for Identifying Languages' to BCP
Resuming my comments:
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:ietf-languages-
> [EMAIL PROTECTED] On Behalf Of Bruce Lilly
[snip]
> Specifically, the draft allows, and RFC 3066 disallows:
>subtags more than 8 octets in length
>hyphens which do not separate subtags
>zero-length subtags
>primary tags which are not purely alphabetic
> Curiously, all of those are permitted by the draft ABNF
> production "grandfathered"...
The "grandfathered" production in the current draft is
grandfathered = ALPHA *(alphanum / "-")
which does permit the sequences claimed by Bruce (except for
not-purely-alphabetic primary sub-tags), syntactically; but the set of
tags available for use is constrained by more than the ABNF syntax
alone: the acceptable productions for each sub-tag must either be taken
from one of the source standards or be registered. This is no different
from RFC 3066, so it is no more of a problem in this specification than
it was in RFC 3066.
It might be that the wording in 2.2 could be tightened up to eliminate
any possible question regarding the source for "grandfathered"
productions. Maybe it's not as obvious to someone coming to this cold as
it for us who have been discussing it for the past year.
Alternately, there's no reason why the "grandfathered" production
shouldn't be composed exactly to match what was used in RFC 3066:
grandfathered = 1*8ALPHA *("-" 1*8alphanum)
So, perhaps there is room for technical improvement, but there are not
any serious problems IMO -- certainly nothing as serious as the tone of
Bruce's conveyed.
> I see no reason for the ABNF to permit such content as is
> forbidden by RFC 3066; the actual ABNF for what RFC 3066
> permits is contained within 3066, and could have been directly
> incorporated rather than producing a "grandfathered"
> production which opens up several cans of worms.
This vastly overstates the problem. There is no can of worms unless it
exists in tags currently available under RFC 3066.
> One defect related to tag length in RFC 3066 is not remedied
> by the draft; indeed the problem is greatly exacerbated...
> Unfortunately, a language- tag's length is unlimited by
> the ABNF in RFC 3066 (due to an unlimited number of subtags)
> and in the draft...
> In particular, tags other than private-use tags with more than
> two subtags require registration under RFC 3066 rules, and it
> is a trivial matter to determine the longest registered tag.
> The draft, however, encourages use of more subtags as well as
> removal of the subtag length upper bound; moreover, it permits
> infinite numbers of subtags without requiring registration of
> the resulting complete tag.
Bruce states incorrectly that there is no upper bound on the length of
sub-tags. His other concern, on the overall length of complete tags, is
valid, however: in terms of the ABNF syntax for both RFC 3066 and RFC
3066bis, infinite-length productions are possible, but RFC 3066 would
require registration of complete non-private-use tags while RFC 3066bis
does not.
There are three open doors for infinite-length productions in the ABNF
of the current draft:
- unlimited extlang sub-tags
- unlimited variant sub-tags
- the number of possible extensions is limited to 25, but the length of
extensions is unlimited
We could impose some upper limits on these things; e.g.
Language-Tag = ... *8("-" extlang) ... *8("-" variant) ... 1*25("-"
extension)
...
extension = singleton 1*8("-" 2*8alphanum)
If we also imposed limits on the length of private-use tags and defined
the grandfathered production in a way that made clear there was an upper
limit for those, then we could end up eliminating an issue that had
existed in RFC 3066.
So, I think Bruce has identified a valid issue here. I personally would
not have characterized it as greatly exacerbating, though, as the issue
was present in RFC 3066: private-use tags did not need to be registered
in RFC 3066, so there was no way in implementation could be written with
certain knowledge that tags beyond some given length would not be
encountered.
> > The new registry provides a complete,
> > easily parseable file which provides the precise the contents of
valid tags for
> > any point in time.
>
> That is the first time I have ever heard ISO 8601 date
> format described as "easily parseable". Perhaps the draft
> authors meant to say that a specific subset of the tortuously
> complex ISO 8601 date format is used, but that is not what
> the draft states...
It seems very clear that the authors intended only a specific subset:
-MM-DD. This is a minor technical issue that the authors can very
easily remedy.
> I am absolutely shocked that a draft dealing with language
> lacks an "Internationalization considerations" section as
> recommended by RFC 2277 (a.k.a. BCP 18).
No more or less shocking than for RFC 3066, regarding which I'm not
aware of any complaints.
I don't quite understand what the critique is here:
RE: Copying conditions
Sam Hartman wrote: > Speaking as an individual, *not* as an AD, I'd love to see the free > software community get together and give input to the IETF (possibly > in the form of an informational RFC) on the following issues: > > 1) Extracting tables and code from IETF standards for use in free/open- > source software. > > 2) What patent holders who would like to license software should do if >they want to create a license that open-source/free software >authors can use when licensing technology in Internet standards. I addressed your two items in the Open Standards Principles I emailed to this list earlier this week. These principles describe the licenses that must apply to copyrighted and patented IP in IETF specifications in order to make them compatible with free and open source software. With respect to copyrighted works (your item #1) contained in IETF specifications to be used in free/open source software: 1. Everyone is free to copy and distribute the official specification for an open standard under an open source license. With respect to patent claims (your item #2) necessary to implement IETF specifications in free/open source software: 2. Everyone is free to make or use embodiments of an open standard under unconditional licenses to patent claims necessary to practice that standard. 3. Everyone is free to distribute externally, sell, offer for sale, have made or import embodiments of an open standard under patent licenses that may be conditioned only on reciprocal licenses to any of licensees' patent claims necessary to practice that standard. 4. A patent license for an open standard may be terminated as to any licensee who sues the licensor or any other licensee for infringement of patent claims necessary to practice that standard. 5. All patent licenses necessary to practice an open standard are worldwide, royalty-free, non-exclusive, perpetual and sublicenseable. If you think it would be useful to submit these five Open Standards Principles as an informational RFC, certainly I can do that. But perhaps they can be discussed here first in their current form without that formality. I welcome comments and suggestions. /Larry Rosen Lawrence Rosen Rosenlaw & Einschlag, technology law offices (www.rosenlaw.com) 3001 King Ranch Road, Ukiah, CA 95482 707-485-1242 * fax: 707-485-1243 email: [EMAIL PROTECTED] > -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf > Of Sam Hartman > Sent: Friday, December 10, 2004 2:07 AM > To: [EMAIL PROTECTED] > Cc: [EMAIL PROTECTED] > Subject: Re: Copying conditions > > > "Simon" == Simon Josefsson <[EMAIL PROTECTED]> writes: > > Simon> [EMAIL PROTECTED] (scott bradner) writes: > >> For IDN, I want to be able to extract the tables from RFC 3454 > >> and use them in my implementation. > >> > >> For Kerberos, I want to be able to use the ASN.1 schema in my > >> implementation, and copy the terminology section into my > >> manual. > >> > >> For SASL, I want to incorporate portions of the introduction > >> section from the RFC into my manual, to make sure some > >> terminology is explained correctly. > >> > >> For GSS-API, I want to be able to copy the C header file with > >> function prototypes into my implementation. > >> > >> just so there is no misunderstanding - the intent of RFC 3668 > >> was to permit such extractions and there was (and is) no desire > >> to restrict such extractions > >> > >> I, as editor, state publicly that I think that RFC 3667 permits > >> such extractions, we (or maybe I) may have not made that clear > >> enough in RFC 3667, but I think that RFC 3667 supports these > >> uses > > Simon> I have received preliminary feedback from IPR specialists > Simon> that seem to indicate to me that neither the old RFC > Simon> copying conditions, nor the new copying conditions in RFC > Simon> 3667, would permit all of the above extractions into free > Simon> software. > > Simon> I am working on getting them to explain their reasoning on > Simon> the Free Software Foundation's web pages (presumably at > Simon> [1]), which I believe would be useful input for the IPR > Simon> working group, but the process has been slow. I hope I'm > Simon> not putting words in their mouth by stating that my > Simon> interpretation of what they said is that there is a > Simon> problem. > > Simon> Do the IETF care about free software enough to work on > Simon> modifying the copying conditions of future RFCs? > > Speaking as an individual, *not* as an AD, I'd love to see the free > software community get together and give input to the IETF (possibly > in the form of an informational RFC) on the following issues: > > 1) Extracting tables and code from IETF standards for use in free/op
RE: Ietf-languages Digest, Vol 24, Issue 5
> -Original Message- > From: [EMAIL PROTECTED] [mailto:ietf-languages- > [EMAIL PROTECTED] On Behalf Of Bruce Lilly > > I agree with Bruce, that accessibility of ISO 639 and ISO 3166 has not > > been the issue. Unfortunately, his comments do not indicate what the > > real issues were. > > My comments are in response to the "New Last Call" made on > the ietf-announce list. They are in response to the text which > accompanied that new last call and the text of > draft-phillips-langtags-08.txt dated November 2002. The > specific claim that accessibility has been a problem was made in > the text accompanying the new last call I don't know where the statement accompanying the announcement came from, but given the impression you came away from it with, I don't think it reflects the rationale for the proposed spec as best it could. If you read section 6 of the draft, it clearly indicates that the goals of the revision are to address issues of compatibility, stability, validity and extensibility. Nowhere does it even mention accessibility. You singled out that one point to comment on as though it were the main factor. Accessibility was not the only reason listed in the announcement, and was not the first reason listed. And, as I've pointed out, was not a reason given in the draft itself. > > RFC 3066 made reference to ISO 639-1, ISO 639-2 and ISO 3166-1; the > > proposed replacement adds ISO 15924. I would count that as four ISO > > standards. Up-to-date code tables for all four are readily available. > > For the purpose of implementation of validation of language-tags, > the ISO 639 list includes both the 2- and 3-character codes in a > single document. The claim (again from text accompanying the > new last call) states that there is some difference in the draft > proposal from 3066 in that 3066 (the text alleges) requires > "lists of codes from five separate external standards" -- in fact > two lists suffice for 3066 implementations. Again, I don't know who wrote the text of the announcement, but again it is bringing up an accessibility issue, and mistakes the general intent and also a specific detail: RFC 3066 did not reference five source standards; it only referenced three (which you percieve as two). > > I think this is a serious misrepresentation of the intent of the > > proposal: the draft nowhere suggests, let alone declares, that the > > source ISO standards are irrelevant. > > A poor choice of words on my part. The text and draft suggests > that only the proposed new registry should be consulted, and > the draft clearly specifies that the description of all subtags is > to be provide in English (only). It is certainly the case that only it should be consulted for determining what sub-tags are valid with what denotation, which was the intent. > > Rather, the intent of the > > comprehensive registry is to ensure stability... > It's not clear to me that the proposal will provide protection > against the whims of politicians. If the definition of "CS" as > a country code changes again under the proposed scheme, > how is one to determine specifically what some archived > language-tag referred to at some point in time? By looking in the sub-tag registry. If ISO changed the meaning of "US" to something other than what it is now, its meaning for purposes of use in an IETF language tag would not change, because it would remain stable in the sub-tag registry. You would be fairly well protected against the whim of politicians. > > and as Bruce quite clearly pointed out, those > > source standards are readily accessible. So the suggestion that > > implementers will no longer have access to French-language names from > > the source ISO standards simply is vacuous. > > But if the proposed new registry's description of "CS" says > "foo" and the ISO standard code list says "bar", what's > an implementor supposed to present to a user as *the* > description associated with "CS"? The *meaning* of the sub-tag is determined by the sub-tag registry. If you want human-readable descriptors, you already have to look beyond the ISO standards for anything more than English and French; it would not be new that you have to look beyond the registry itself to decide what human-readable descriptors you should provide in a product. > > As for concerns of Anglo-centricity, I'm sure that the authors had no > > anti-French motive, and would be open to suggestions as to how that > > could be addressed. > > One possibility would be two description fields. But the > registry would need a charset closer to ISO-8859-1 than > to ANSI X3.4 as currently specified. Or an encoding > scheme. Personally, I don't see the value in something like that. Given the intent to have a registry that can be machine-readable, changing its charset from ANSI X3.4 in order to gain descriptors in just one more language is not worth it IMO. Speaking at least for Microsoft, we're interested in having de
Notice - DHCPv4 options 128-223 soon to be IANA assignable (RFC 3942)
Hi: A new RFC has just been issued, RFC 3942 (http://www.ietf.org/rfc/rfc3942.txt): "Reclassifying DHCPv4 Options". The document is a product of the IETF DHC WG and expands the range of DHCPv4 option numbers that are in the IETF/IANA assignable range. The expanded public range reduces the site-specific options range that was originally defined in RFC 2132.. Old rangesNew ranges IETF/IANA assignable: 1-127 1-223 Site-specific: 128-254 224-254 So, why might you care about this? Many vendors have used "site-specific" options in the range 128-254 for vendor-specific purposes in shipping products. And, now that IANA can assign options numbers in the range 128-223 to future Internet Standard options, we need your assistance to prevent potential conflicts in the use of option codes in the newly expanded range. RFC 3942 has a mechanism whereby IANA will not assign any option codes in the newly expanded range, 128-223, for 6 months (this period will end in May 2005). During this 6 month period, vendors using options in the 128-223 range should come forward to let IANA and the DHC WG know of their use. IANA can be contacted at mailto:[EMAIL PROTECTED] and the IETF DHC WG can be contacted at mailto:[EMAIL PROTECTED] The vendor will also need to write an Internet Draft documenting that usage and advance that draft to an RFC. The Internet Draft can either be written by the vendor or by the vendor providing the material for documenting their usage to Bernie Volz (mailto:[EMAIL PROTECTED]) for inclusion in a general draft documenting several options. Once the Internet Draft has been published, it will be, at the vendor's discretion, published as an Informational RFC or entered into standards track for publication as an Internet Standard RFC. Therefore, please pass this email on as appropriate and contact Bernie Volz for more information. - Bernie Volz ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: Last-Call comments on 'The Standard Hexdump Format '
Hi Jacob, I believe all issues you raised in connection to Internet Draft draft-strombergson-shf-03 have been addressed in draft-strombergson-shf-04. Notably the endianess issue has been resolved by strictly enforcing big endian words. For the authors, Linus Walleij ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: New Last Call: 'Tags for Identifying Languages' to BCP
> Show me a general-use RFC > 3066 language tag which is too long to fit on an RFC > 2822/3282 Content-Language header field line. Your claim was that RFC 3066bis (the informal name we've been using for the new draft) permits language tags that are longer than those permitted by RFC 3066. That is clearly false, as many people have pointed out. Any subsequent niggling that particular *types* of language tags can be longer or not is not relevant to the conformance implications of the two documents for language tags. The new draft neither extends nor contracts the maximum length of language tags conformant to RFC 3066. Your claim that the RFC 3066 ABNF itself has a restriction in length is also clearly false. I will quote that again since you seem somehow not to have seen it: " The syntax of this tag in ABNF [RFC 2234] is: Language-Tag = Primary-subtag *( "-" Subtag ) Primary-subtag = 1*8ALPHA Subtag = 1*8(ALPHA / DIGIT) " Both documents establish many further limitations on the contents of language tags in the text of each document. Ignoring those stated limitations will, in both documents, result in nonconformant language tags. âMark - Original Message - From: "Bruce Lilly" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Sunday, December 12, 2004 09:16 Subject: Re: New Last Call: 'Tags for Identifying Languages' to BCP > > Date: 2004-12-11 00:52 > > From: "Mark Davis" <[EMAIL PROTECTED]> > > To: [EMAIL PROTECTED], [EMAIL PROTECTED] > > CC: [EMAIL PROTECTED] > > > > > The ABNF is an expression of the grammar that > > describes the set of all valid tags. > > > > No, this is simply incorrect. You cannot expect that any implementation that > > simply does the ABNF is conformant. > > I made no such claim. I do claim that if the ABNF > contradicts the normative text, as is the case in > your draft w.r.t. acceptance of several constructs > not permitted by RFC 3066 ABNF, that there is an > error in either the normative text or the ABNF. > > > There are a great many constraints on > > the tags that are not in the ABNF grammar, that are clearly required in any > > reading of the text. Most of these *cannot* be encompassed in any ABNF > > grammar. > > If your claim is that the ABNF cannot express a > grammar consistent with the RFC 3066 ABNF, that > is clearly false. > > > There are a few that could be expressed in the ABNF; some at little > > cost, some with a great deal of complication. > > Are you claiming that it is unduly difficult to > make the ABNF match RFC 3066's? > > > This is not a technical > > problem for the draft. > > It is a problem due to the conflict between the > ABNF and the text. It is a problem because it > opens a loophole for future revisions to formalize > content which is incompatible with RFC 3066 > implementations. > > > > as reasonable as the current worst-case of 11 octets. > > Also simply untrue. You seem not to be reading all the messages on this > > subject. Look at the ABNF for RFC 3066. There is *no* limit in the ABNF > > there! > > The draft proposes closing RFC 3066-style registrations. > Show me a registered RFC 3066 language tag longer than > 11 octets. Show me a general-use (i.e. not private-use) > RFC 3066 language tag which is too long to be used in an > RFC 2047/2231 encoded-word. Show me a general-use RFC > 3066 language tag which is too long to fit on an RFC > 2822/3282 Content-Language header field line. > ___ > Ietf-languages mailing list > [EMAIL PROTECTED] > http://www.alvestrand.no/mailman/listinfo/ietf-languages > ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
RE: New Last Call: 'Tags for Identifying Languages' to BCP
> From: [EMAIL PROTECTED] [mailto:ietf-languages- > [EMAIL PROTECTED] On Behalf Of Bruce Lilly > The point is that under RFC 3066, > the bilingual ISO language and country code lists are > considered definitive. That is nowhere stated or even suggested in RFC 3066. Peter Constable Microsoft Corporation ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: New Last Call: 'Tags for Identifying Languages' to BCP
On Mon, Dec 13, 2004 at 01:37:04AM -0800, Mark Crispin wrote: > > When I retrieve a file via FTP, HTTP, etc. the time stamp of that file on > my computer is the date/time of retrieval, not the date/time of the file > on the source. > > Unless, of course, both systems are running TOPS-20 and thus use that > wonderful XTP mode that copies file metadata. Now, if you want to mandate > that all UNIX and Windows systems be replaced with TOPS-20, I might > support that... :-) Actually some ftp and http transfer programs, incl wget and ncftp keep the original date stamp. With Xmas greetings Keld ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
RE: New Last Call: 'Tags for Identifying Languages' to BCP
> From: [EMAIL PROTECTED] [mailto:ietf-languages- > [EMAIL PROTECTED] On Behalf Of Bruce Lilly > Moreover, the point is that countries do change, and that use > of country codes (as provided for in RFC 3066 and in the > proposed draft) carries with it the inherent instability > which is characteristic of politics. A quest for "stability" > of countries seems Quixotic and oxymoronic. According to the > principle of stability as that term is used in defense of the > draft, I suppose we're all intended to refer to Malawi as > "Rhodesia" because that's what it (in part) was called 50 years > ago, or that we're supposed to ignore the breakup of the USSR, > Yugoslavia, etc., the reunification of Germany, etc. That is not at all the aim here wrt stability; rather, the aim is that a symbolic identifier used for metadata in IT systems not change because some government on a whim says, "We would now prefer to use 'yz' rather than 'xy' to designate our country." Sure, there will be changes that we need to deal with; but there's no reason to subject all implementations, users and data to changes that are purely cosmetic changes to things that are not designed to be read by humans. > A related problem with the use of country codes in language > tags is that there is not necessarily an inherent relationship > between language and country borders. That is not what country IDs within a language tag is intended to suggest. In fact, if there were inherent relationships, we probably would never have needed to use country IDs in a language tag. > The borders of Germany > have changed many, many times. If one is referring to the > German language as spoken by inhabitants of Alsace, using > country codes would imply that that same language spoken by > the same people would have been tagged at various times as > de-DE and de-FR according to where the France-Germany border > happened to have been determined by politicians of the time. > That strikes me as being a rather silly way to tag language, > but that's the precedent set by RFC 1766. I agree that that's a silly way to tag that language; I disagree that RFC 1766 suggests I should tag it that way. > As far as I can tell, > the draft doesn't really deal with the issue of changing borders > or changing country names -- it merely pretends that these > things don't happen by attempting to declare a snapshot of the > status at some point in time as being valid for all time. That may be your reading of the situation, but it is not how it is seen by those of us who have been working on this spec and examining these issues closely. > But the user has indicated that he speaks French, and the > proposed registry contains a description in English only. > Where is the implementor supposed to get the *official* > translation for display? N.B. under the current (RFC 3066) > situation, the definitive ISO lists provide an official > description in French. Neither RFC 1766 or RFC 3066 has ever presented "official" translations; this is no different for RFC 3066bis. Under RFC 3066, one is pointed to ISO 639-1 and ISO 639-2 to get the alpha-2 and alpha-3 IDs, but it does not anywhere state that implementors should use the English and French language names in those ISO standards; exactly the same situation holds for RFC 3066bis. (Note, btw, that the names listed by ISO 639-1/-2 have no particular "official" status; they are normative in those standards to the extent that the indicate what language variety a given ID denotes, but they do not claim that the particular form of the language names have any particular status.) > > > One possibility would be two description fields. > > > > Why two? > > There are now two in the ISO lists (and, as noted, in the > UN list). I have no objection to more, but I object to > a reduction. If anything, I am inclined to object to two: to avoid an Anglo-Franco colonial bias, either there is one name that is simply a reference name, or the registry be designed so that it could accommodate names in as many languages as may be available. Note that the RFC 3066 specifies a registry that does not include French language names. I suggest that this issue should be dropped. > I have an implementation which (in accordance with RFC 3066) > uses the official ISO lists. It has provision for displaying > ISO 639 language tags with their descriptions in either of the > two languages supported by the official 639 lists, and likewise > for the ISO 3166 country codes. RFC 3066 *does not at any point* suggest let alone state that implementations should use ISO 639 language names or ISO 3166 country names for UI purposes. IMO, you are creating an issue where none exists. > The specification of the > draft is *NOT* compatible with that existing implementation > because it removes the existing functionality of official > descriptions in French of language and country codes. As a > result of that incompatibility, the newly proposed > specificati
Re: Copying conditions
On Mon, 2004-12-13 at 20:16, Simon Josefsson wrote: > I would include "modify" in this clause, or clarify exactly which > license you are talking about (e.g., GNU Free Documentation License). IMHO, if "modify" is allowed, the license must require that modified versions are clearly distinguished from the official spec and thereby not-the-standard-you-were-looking-for. - Bill ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: New Last Call: 'Tags for Identifying Languages' to BCP
Bruce Lilly scripsit: > Feh. Whatever. The human-readable stuff that corresponds > to the code which you say shouldn't be read. The stuff > without which codes are meaningless. The stuff without > which two communicating parties cannot agree on the meaning > of "XX". Two communicating parties can unquestionably agree on the meaning of "XX" without both English and French definitions. Either will suffice. Indeed, if either definition provided a nuance not available to the other, they would not be interchangeable, and one would have to be the authentic definition and the other a mere aide-memoire. -- [W]hen I wrote it I was more than a little John Cowan febrile with foodpoisoning from an antique carrot [EMAIL PROTECTED] that I foolishly ate out of an illjudged faith www.ccil.org/~cowan in the benignancy of vegetables. --And Rosta www.reutershealth.com ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: New Last Call: 'Tags for Identifying Languages' to BCP
> Are you claiming that > > sr-CS-891-boont-gaulish-guoyu-boont-gaulish-guoyu-boont-gaulish-guoyu > is nonconformant per some specification in the draft > proposal? Clearly not. But x-sr-CS-891-boont-gaulish-guoyu-boont-gaulish-guoyu-boont-gaulish-guoyu is already absolutely conformant with the current RFC 3066. And the current RFC 3066 clearly permits the registration of something as long as sr-CS-891-boont-gaulish-guoyu-boont-gaulish-guoyu-boont-gaulish-guoyu (although of course this particular combination would certainly never get in). Inutile d'aller plu loin... There is no use to trying to declare a difference in conformant lengths between these two documents when one doesn't exist. If you want to do something productive, you should make a practical suggestion for a change in the current text of the new draft. If the new draft is to backward compatible, then it has to be worded carefully. I haven't thought it through at length, but would need to be something like: - A conformant implementation need not support the storage of language tags which exceed a specified length. However, such a limitation must be clearly documented, including the disposition of any longer tags (for example, whether an error value is generated or the language tag is truncated -- and if so, how it is to be truncated). âMark - Original Message - From: "Bruce Lilly" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Sunday, December 12, 2004 12:20 Subject: Re: New Last Call: 'Tags for Identifying Languages' to BCP > > Date: 2004-12-12 13:00 > > From: "Mark Davis" <[EMAIL PROTECTED]> > > To: [EMAIL PROTECTED], [EMAIL PROTECTED] > > CC: [EMAIL PROTECTED] > > > Your claim that the RFC 3066 ABNF itself has a restriction in length is also > > clearly false. I will quote that again since you seem somehow not to have > > seen it: > > I made no such claim; indeed it was I who pointed out > that RFC 3066 *theoretically* permits an infinite- > length tag. On that basis alone (even if you missed > the fact that I am an implementor of RFC 3066 > language tags) you can be sure that I am well aware > of the RFC 3066 ABNF. > > > Both documents establish many further limitations on the contents of > > language tags in the text of each document. Ignoring those stated > > limitations will, in both documents, result in nonconformant language tags. > > Are you claiming that > > sr-CS-891-boont-gaulish-guoyu-boont-gaulish-guoyu-boont-gaulish-guoyu > > is nonconformant per some specification in the draft > proposal? It is certainly too long to be used in an > RFC 2047/2231 encoded-word. It is much longer than > any registered RFC 3066 language tag, and the draft > proposes removing full tag registration procedure > restrictions as well as decoupling use from registration > that would combine to permit such an abomination. > ___ > Ietf-languages mailing list > [EMAIL PROTECTED] > http://www.alvestrand.no/mailman/listinfo/ietf-languages > ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
RE: New Last Call: 'Tags for Identifying Languages' to BCP
> From: [EMAIL PROTECTED] [mailto:ietf-languages- > [EMAIL PROTECTED] On Behalf Of Bruce Lilly > > What is silly is saying that every language tag has to have a date/time > > attribute associated with it so that computer software managing that > text > > knows the language of that text. > > In the specific cases of the core Internet protocols that > I have mentioned, there *is* a date/time attribute in the > form of an RFC [2]822 Date field. If we're talking about > some file stored on some machine, every OS that I know of > has a date/time stamp associated with that file. If you > have something else in mind, a concrete description and/ > or example might help. That is not sufficient for many other implementations of RFC 3066. For instance, an XML document may well be stored in a file system that has date/time stamps associated with the file; it might also be stored in a content manangement system that does not report creation dates when returning content. And elements from within that XML document may be returned as the result of an X-Path query or a call into a DOM API, and those surely cannot be assumed to have creation date/time stamps, though one certain must assume that they can have RFC 3066 tags as xml:lang attributes. > I'm not "eager to abolish" "uniqueness". There never was > any guarantee that codes would never change. Both RFCs > 1766 and 3066 specifically mention changes as a fact of > life. Some of us consider that fact and the instability particularly of ISO 3166 to be a serious problem. That (not accessibility) was one of the key reasons for this revision. > > > SO where are the French definitions? > > > > Ask a person who is bilingual in English and French to provide one. > > That would lack definitiveness which characterizes the > ISO lists. You started out this thread by talking about display names, not definitions; hence Mark's suggestion. Now you have switched to talking about definitions. The draft clearly indicates where one finds the definitions: " o All 2-character language subtags were defined in the IANA registry according to the assignments found in the standard ISO 639..." I.e. the definition is provided in the registry on the basis of what is defined in ISO 639; hence if what is indicated in the registry is for any reason insufficient for your purposes, you consult the definitive source, the ISO standard. Peter Constable Microsoft Corporation ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
RE: New Last Call: 'Tags for Identifying Languages' to BCP
> From: [EMAIL PROTECTED] [mailto:ietf-languages-
> [EMAIL PROTECTED] On Behalf Of Bruce Lilly
> > The "grandfathered" production in the current draft is
> >
> > grandfathered = ALPHA *(alphanum / "-")
> >
> > which does permit the sequences claimed by Bruce (except for
> > not-purely-alphabetic primary sub-tags),
>
> No exception. "alphanum" is ALPHA / DIGIT.
My mistake; again, I had on my mind constaints beyond the ABNF.
> > syntactically; but the set of
> > tags available for use is constrained by more than the ABNF syntax
> > alone: the acceptable productions for each sub-tag must either be taken
> > from one of the source standards or be registered.
>
> So what? The ABNF is an expression of the grammar that
> describes the set of all valid tags.
It is *part* of the expression of the grammar. Even in RFC 3066 this is the
case: you know that t-abc is not valid under RFC 3066, but not because that is
constrained by the ABNF of RFC 3066.
I will accept that the ABNF of draft should be changed to better reflect what
the form of grandfathered productions can be, which, as I stated in my previous
message, would be the equivalent of the ABNF of RFC 3066:
grandfathered = 1*8ALPHA *("-" 1*8alphanum)
I think that's an improvement, though technically I don't think it changes
anything.
> If
> one doesn't intend to impose such requirements, the
> ABNF specifying the grammar should be changed
> accordingly.
>
> > This is no different
> > from RFC 3066, so it is no more of a problem in this specification than
> > it was in RFC 3066.
>
> It is a very different grammar from RFC 3066, imposing
> very different requirements on parsers.
Our disagreement amounts to a basic question of whether parsers should be
written based on the ABNF alone, or based on the ABNF plus other constraints
provided in the spec. Clearly, I think anyone writing a parser should consider
other constraints as well.
> > > In particular, tags other than private-use tags with more than
> > > two subtags require registration under RFC 3066 rules, and it
> > > is a trivial matter to determine the longest registered tag.
> > > The draft, however, encourages use of more subtags as well as
> > > removal of the subtag length upper bound; moreover, it permits
> > > infinite numbers of subtags without requiring registration of
> > > the resulting complete tag.
> >
> > Bruce states incorrectly that there is no upper bound on the length of
> > sub-tags.
>
> Look again at the draft definition of "grandfathered" -- now
> show me where there's a limit in that production on subtag
> length.
As mentioned, the limit is imposed by other tight constraints on
'grandfathered'; you have already identified that the longest registered tag
under RFC 3066 is 11 octets in length, therefore a 'grandfathered' tag can be
at most 11 octets in length.
> > There are three open doors for infinite-length productions in the ABNF
> > of the current draft:
> >
> > - unlimited extlang sub-tags
> > - unlimited variant sub-tags
> > - the number of possible extensions is limited to 25
...
> > , but the length of
> > extensions is unlimited
>
> You have missed several others:
>
> 1. "privateuse" length is unlimited (either tacked on
> after "lang" etc., or directly as an alternative in
> "Language-Tag")
I disregarded this since it is identical to the case for RFC 3066, and you
were, after all, charging that the draft creates problems that were worse than
for RFC 3066.
> 2. "grandfathered", which as already discussed
> permits unlimited length.
But as already stated is very tightly constrained, with a de-facto upper limit
of 11 (subject to change if new tags are registered before the proposed spec is
accepted).
> > We could impose some upper limits on these things...
> That leaves the extension portions' length at up to
> 25 * (1 + 1 + 8 * 9) = 1850 octets, not taking any other parts
> of a tag into account! That's way too long (the RFC 2047
> limit for an encoded-word is 75 octets, including charset tag,
> some text, and some syntactic glue in addition to the language
> tag).
The problem already exists in RFC 3066. Even apart from private-use tags,
tomorrow someone could request a registration for a tag that's 87 octets long,
and there's nothing in RFC 3066 that would prohibit acceptance.
> > So, I think Bruce has identified a valid issue here. I personally would
> > not have characterized it as greatly exacerbating, though,
>
> IMO, an increase from 11 octets worst-case, which is tolerable
> for constructing RFC 2047/2231 encoded-words, to >> 1850
> octets, which exceeds by a large margin what can be handled
> in a Content-Language or Accept-Language message header
> field, constitutes "greatly exacerbated".
Repeating my previous point, RFC 3066 doesn't stop a registered tag from being
10^100 octets in length. Of course, all of us know that such a tag wouldn't be
useful. At some point, we have to engage common sense, ev
Re: New Last Call: 'Tags for Identifying Languages' to BCP
Peter Constable scripsit: > My suggestions, then, in response to Bruce Lilley's comments are: I heartily support all of this, despite the extra burden it imposes on our esteemed editors, and hope that none of it is in any way controversial. -- John Cowan www.reutershealth.com www.ccil.org/~cowan [EMAIL PROTECTED] Arise, you prisoners of Windows / Arise, you slaves of Redmond, Wash, The day and hour soon are coming / When all the IT folks say "Gosh!" It isn't from a clever lawsuit / That Windowsland will finally fall, But thousands writing open source code / Like mice who nibble through a wall. --The Linux-nationale by Greg Baker ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: New Last Call: 'Tags for Identifying Languages' to BCP
Peter Constable scripsit: > The ISO 3166 MA maintains that standard in accordance with the > identifiers specified by the UN Statistics Division; a change by the UN > is all the convincing that is required. Umm, not quite. The UNSD defines what a "country" is, and assigns it a 3-digit code (normative) and a name (informative); the ISO 3166 MA then specifies 2-letter and 3-letter codes for that name. > This scenario is not hypothetical; it actually occurred in the case of > CS. The change was solely under the control of the UN Statistics > Division; it is not part of their process to consult with developers and > users of IT systems in general, and they were not consulted in this > case. They were completely powerless to influence the change, learning > about it only after the fact. UNSD had nothing to do with this. It assigned the hitherto-unused code 891 for the country now called "Serbia and Montenegro". (Yugoslavia had the code 890, Czechoslovakia the code 200). This was a reasonable judgment in the circumstances: the question of when a country has changed into another country is always fuzzy. It was the ISO 3166 MA and no one else who chose to assign the 2-letter code "CS" to the new country. UNSD historically has assigned new numerical codes when new "countries" come into existence, and has managed to avoid reusing any of its 3-digit identifiers, which is precisely why those identifiers are being used as trusted backups in RFC 3066bis for the unstable ISO 3166 identifiers. > This is a situation we do not intend to repeat. Agreed, but let's make sure not to blame the innocent. > It is not uncommon for users to confuse "JA" and "JP". *blush* I've done it myself, and in implementation, not merely in discussion. Fortunately, the evidence is now buried. -- John Cowan www.reutershealth.com www.ccil.org/~cowan [EMAIL PROTECTED] Arise, you prisoners of Windows / Arise, you slaves of Redmond, Wash, The day and hour soon are coming / When all the IT folks say "Gosh!" It isn't from a clever lawsuit / That Windowsland will finally fall, But thousands writing open source code / Like mice who nibble through a wall. --The Linux-nationale by Greg Baker ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
RE: New Last Call: 'Tags for Identifying Languages' to BCP
> From: [EMAIL PROTECTED] [mailto:ietf-languages- > [EMAIL PROTECTED] On Behalf Of Bruce Lilly > > That is not at all the aim here wrt stability; rather, the aim is that a > > symbolic identifier used for metadata in IT systems not change because > > some government on a whim says, "We would now prefer to use 'yz' rather > > than 'xy' to designate our country." > > If by international agreement, 'yz' becomes the designation > for that country, then it is rather silly to stick one's > fingers in one's ears and shout "NA-NA-NA-NA-NA I don't want > to hear you". That misses the point entirely. The point is that IDs used by political administrations may change for any number of reasons, and those admministrations may have no qualms with such changes; but in IT systems, we cannot afford changes that break existing implementations and data. If for whatever reason ISO and the UN decided that "US" should be used to designate the country of France, I doubt you'd expect every software vendor to update all of their deployed installations to use "fr-US" instead of "fr-FR", and for every user to go through every data repository they manage to make such changes in their data. The people that maintain time zone definitions may have their means for changing times; that's fine for them. They are not dealing with the same concerns as we are dealing with. The group here that has focused specifically on language-tagging issues for several years has evaluated issues that affect language tags and the impact of changes and has decided what is best practice for *this* domain, and it is to maintain stability of data rather than cater to whims of political administrations. > "Designed" or not, country codes *are* read by humans; they > appear in top-level domain names. Currently the ISO 639 > 2-letter codes mean the same thing as the last component of > a domain name I think you mean ISO 3166 2-letter codes. > and as the second component of a language-tag. > It's rather silly to change that correspondence simply because > a few people are piqued that international agreement has been > reached to change a few 2-letter codes. The usability flaw in treating ISO 639 and ISO 3166 as human-readable is evident in the confusion between ja and JP (or is it jp and JA?), and GB vs UK. As for what is silly, if the UN country ID for Canada changed to CN (and that for PRC changed to something else), I'm sure it would cause far greater problems for users to have to change the last two letters in domain names than for them to keep doing what they always did. In fact, I would have thought it would create a rather significant problem on the Internet if such a change were made. (URIs don't come with versioning dates for domain names, so how would a DNS server know what the "cn" meant?) > > Neither RFC 1766 or RFC 3066 has ever presented "official" translations; > > Both defer to the ISO lists for definitions (not "translations") > of the various codes. Definitions; not language names for display use. > > this is no different for RFC 3066bis. > > It is very different; under the proposed draft, there is only > an English definition, somebody wishing to provide a French > definition finds that he has none and must resort to an > unofficial translation. The more you press this, the more silly it seems. RFC 3066 does not anywhere discuss display names; localization data is beyond its scope. The registry it defines does not give provision for French language names. The source ISO standards are every bit as accessible as they ever were, and just as RFC 3066 gave the user no option but to refer to the source ISO standard, so users should and can continue to do so. After this response, I will not waste my time any further on this foolishness. > I'm willing to postpone the discussion > (other problems with the proposed registry format dictate > a broader solution which could easily have provision for > an arbitrary number of descriptions). I strongly object to the suggestion that progress on this draft be delayed to deal with this non issue that caters to implementation issues that are well beyond the scope of either RFC 3066 or its proposed replacement. > No, you are overlooking the fact that a set of codes with > no corresponding definitions is useless. RFC 3066 defers > the code/definition pairs to ISO, which provides multilingual > definitions. The proposed draft would remove that multilingual > characteristic. What if the registry provide no name, just the ID? Then people would have to refer to the source ISO standard as they did in the past, and we would be able specify which ISO IDs were or were not valid. That would achieve the goal that we had wrt stability while eliminating the concern that English-only annotations for some reason apparently create for you. Personally, I think the English annotation is helpful, but it seems that the real solution you're looking for is to remove any annotation whatsoever so that the situatio
RE: New Last Call: 'Tags for Identifying Languages' to BCP
> From: [EMAIL PROTECTED] [mailto:ietf-languages-
> [EMAIL PROTECTED] On Behalf Of Bruce Lilly
> > As mentioned, the limit is imposed by other tight constraints on
> 'grandfathered'; you have already identified that the longest
registered
> tag under RFC 3066 is 11 octets in length, therefore a 'grandfathered'
tag
> can be at most 11 octets in length.
>
> But the constraints probably aren't as tight as you
> believe; the draft specifically permits a future
> revision to allow a primary subtag longer than
> 8 octets, or not purely alphabetic, etc.
RFC 3066 does not impose any restrictions on what its replacements might
do. This is the case with any specification: a given technical
specification is not a specification of human behaviour and cannot keep
us from revising the spec or replacing it in any way we may choose.
> One would hope that under RFC 3066 rules, that the
> reviewer, a list subscriber, or an Applications Area
> Director would recognize the conflict with RFCs 2047/2231
> and would object.
You have mentioned conflict with RFCs 2047 and 2231. RFC 2047 does not
make reference to language tags. The ABNF of RFC 2231 does not impose
any limit on the length of language tags. RFC does contain an implicit
length issue in that it updates RFC 2047, allowing language tags within
encoded words, but it does not explicitly identify any upper bound on
the length of language tags. By reading both RFC 2047 and RFC 2231, one
finds that they assume that a language tag must be at most 64 characters
long:
- the maximum length for the encoded-word production is 75 characters
long (not stated in the ABNF of RFC 2047 but rather in the prose)
- encoded-word production of RFC 2047 includes 6 literal characters
- RFC 2231 adds one delimiting character "*" between the charset and
language tag
- the shortest charset names are 2 characters long (e.g. "IT")
- the shortest encoding length is 1 character long
- the minimum encoded-text length is 1 character long
An encoded-word must contain at least 11 characters that are not part of
the language tag and have a total length of no more than 75 characters.
Therefore, an upper bound on language tags that can be used in an RFC
2047/2231 encoded-word production is 64 characters. In many cases, where
the charset tag or encoding is longer, the upper bound on the length of
languages tags will be less, but the RFC gives no estimate or indication
of how much less.
This is a constraint on an application of RFC 3066; it is not a
constraint on RFC 3066 itself. It is possible that other applications of
RFC 3066 may impose limits that may be longer or shorter than that
imposed by RFC 2047/2231. I see no reason why limits must be added as a
constraint in a revision of RFC 3066. It would be a good idea, however,
to point out in section 2.1 of the draft that some applications of this
specification may impose limits on the length of accepted language tags,
and perhaps to cite RFC 2231 as an example.
My suggestions, then, in response to Bruce Lilley's comments are:
- that we add a note prominently in section 2.1 of the draft explaining
that some applications may impose limits on the lengths of language
tags, and cite RFC 2231 as an example
- that we revise the ABNF for the 'grandfathered' production rule to
grandfathered = 1*3ALPHA *("=" 1*8alphanum)
- that we add a note in the discussion of extensions stating that, when
a language tag instance is to be used in a specific, known protocol, it
is advisable that the language tag not include extensions not supported
by that protocol (text can be added pointing out the inadvisability of
including unrecognized extensions in the case of protocols that impose
upper limits on the length of strings that may contain a language tag)
- that recommendation 4 in section 2.4.2 be changed to say that
extensions should not be removed except in the case that the language
tag instance is to be inserted into a specific protocol known not to
support the extension
- that the language subtag registration form include an additional field
following #7 (recommended prefixes for variants) asking for a reasonable
estimate and examplar of the maximum length anticipated for language
tags using the requested varient
- that a requirement on extension RFCs be added in section 3.4 stating
that they must include some explicit discussion of concerns related to
upper bounds on length of language tags using the given extension
- that we do not attempt any other changes to the ABNF to impose an
upper bound on the length of language tags
- that we add a note in section 3.1 indicating that descriptions in
registry entries for ISO 639, ISO 3166 or ISO 15924 identifiers are
intended only to indicate the meaning of that identifier as defined in
the source ISO standard at the time it was added to the registry, and
that the descriptions are not replacements for content of the source
standards themselves
- that we do not need to change the proposed format of
Re: New Last Call: 'Tags for Identifying Languages' to BCP
On Sun, 12 Dec 2004, Bruce Lilly wrote: In the specific cases of the core Internet protocols that I have mentioned, there *is* a date/time attribute in the form of an RFC [2]822 Date field. If we're talking about some file stored on some machine, every OS that I know of has a date/time stamp associated with that file. If you have something else in mind, a concrete description and/ or example might help. When I retrieve a file via FTP, HTTP, etc. the time stamp of that file on my computer is the date/time of retrieval, not the date/time of the file on the source. Unless, of course, both systems are running TOPS-20 and thus use that wonderful XTP mode that copies file metadata. Now, if you want to mandate that all UNIX and Windows systems be replaced with TOPS-20, I might support that... :-) Silliness aside, the file may well have embedded language tags in the text of the file. Have you forgotten Plane 14? I'm not "eager to abolish" "uniqueness". There never was any guarantee that codes would never change. Both RFCs 1766 and 3066 specifically mention changes as a fact of life. That's what's now being fixed. French is an official language used by the ISO in its publications. Why is this vestige of colonialism important in the IETF context? SO where are the French definitions? Ask a person who is bilingual in English and French to provide one. That would lack definitiveness which characterizes the ISO lists. What magic attribute is there to French that provides "definitiveness" that is absent in English, or Mandarin, or Hindi, all of which are far more significant languages to the world? Why is it a problem? Why is it a defect? Because it unnecessarily reduces by 50% the information content currently available. A mandatory French translation to an English definition does not significantly increase the information content, and certainly does not double it. The only increase in the information content would be to those individuals who comprehend French but not English. This is a very small number of individuals. If there is to be a mandatory translation into a second language to increase information content, then that language should be Mandarin. Among individuals who do not comprehend English, far more comprehend Mandarin than comprehend French. If there is to be a mandatory translation into a third language, that would probably be Hindi. You have not explained how the code came to be "embedded within the text itself" -- surely the author didn't say (or write, or sign) "this text is in language QZ"; most likely the language was indicated by name, or by some proxy representing the name (such as a locale). Plane 14. HTML and other markups. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum. ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: New Last Call: 'Tags for Identifying Languages' to BCP
Bruce Lilly scripsit: > If by international agreement, 'yz' becomes the designation > for that country, then it is rather silly to stick one's > fingers in one's ears and shout "NA-NA-NA-NA-NA I don't want > to hear you". Actually, 'yz' doesn't designate the country in the ISO standard, as I explained yesterday. Rather, it designates the *name* of the country, which is of course subject to change *without* international agreement. In RFC 1766/3066, we attempt to use it to designate the country, which requires some straining of the concept. > As I have pointed out, politicians change the definitions of time > zones frequently, and those who have to deal with time zone issues > have found a way to cope with such change without trying to declare > international standardization organizations irrelevant. Ah, but you kick the ball through your own goalposts here. The Olsen time zone system is excellent -- but it becomes so only by totally ignoring the customary names of time zones and inventing its own! (Thus U.S. Eastern time is named "America/New_York", e.g.) The customary names are carried only as time zone abbreviations such as "EST", which are not unique, are English-only, and most of which are also made up. (Countries with a single time zone generally don't bother with an official name for it, with some obvious exceptions.) > It's rather silly to change that correspondence simply because > a few people are piqued that international agreement has been > reached to change a few 2-letter codes. Not much of an international agreement, really. -- Samuel Johnson on playing the violin: John Cowan "Difficult do you call it, Sir? [EMAIL PROTECTED] I wish it were impossible."http://www.ccil.org/~cowan ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
RE: New Last Call: 'Tags for Identifying Languages' to BCP
> From: [EMAIL PROTECTED] [mailto:ietf-languages- > [EMAIL PROTECTED] On Behalf Of Bruce Lilly > > That misses the point entirely. The point is that IDs used by political > > administrations may change for any number of reasons, and those > > admministrations may have no qualms with such changes; > > For such changes to become enshrined in an ISO standard > requires a bit more than a mere whim on the part of one > party; in the case of the particular ISO standards under > discussion, it requires convincing the duly appointed > maintenance authority to make the change. The ISO 3166 MA maintains that standard in accordance with the identifiers specified by the UN Statistics Division; a change by the UN is all the convincing that is required. > > If for whatever reason ISO and the UN decided that "US" should > > be used to designate the country of France, I doubt you'd expect every > > software vendor to update all of their deployed installations to use > > "fr-US" instead of "fr-FR", and for every user to go through every data > > repository they manage to make such changes in their data. > > The only way that would be likely to happen would be if > there were no longer a "US" *and* if the ISO and UN > representatives of France were to initiate a request for > such a change. One would presume that they would have > good reason to do so, and could explain said reasons in > order to convince their ISO and UN counterparts to agree > to the change. Under those hypothetical circumstances, I > can only assume that software vendors who care about such > matters would either agree with the hypothetical reasons > or would have acted to convince those in favor of the change > of reasons to avoid the change. This scenario is not hypothetical; it actually occurred in the case of CS. The change was solely under the control of the UN Statistics Division; it is not part of their process to consult with developers and users of IT systems in general, and they were not consulted in this case. They were completely powerless to influence the change, learning about it only after the fact. This is a situation we do not intend to repeat. > And while I would not > expect users to retroactively change documents any more than > I would expect coins and paper money to be reissued with old > dates but new designations of country name, I would expect > that as of the agreed-upon effective date of the change that > new documents would be prepared in accordance with the new > standard. It's difficult to be more precise about such a > wild hypothetical, but consider similar changes made to > time zones... I have no interest in considering time zones; I will leave that to people that solve problems related to time zones. Content cannot be assumed to have any language tags in its metadata tagged to indicate version, so versioning is not a general solution. There are ways that we can impose stability, and that is what we seek and intend to do. > > The usability flaw in treating ISO 639 and ISO 3166 as human-readable is > > evident in the confusion between ja and JP (or is it jp and JA?), and GB > > vs UK. > > Without looking I can easily tell that jp and uk are country > codes precisely *because* they are well-known as TLDs. It is not uncommon for users to confuse "JA" and "JP". "UK" is not an officially-assigned ISO 3166 country code; it's status is "exceptionally reserved". The alpha-2 ID listed in ISO 3166-1 for United Kingdom is "GB". > > As for what is silly, if the UN country ID for Canada changed to > > CN (and that for PRC changed to something else), I'm sure it would cause > > far greater problems for users to have to change the last two letters in > > domain names than for them to keep doing what they always did. > > And it is precisely because of such problems that it is > as unlikely to happen as your hypothetical FR->US change. Again, not hypothetical at all. > > > > Neither RFC 1766 or RFC 3066 has ever presented "official" > > translations; > > > > > > Both defer to the ISO lists for definitions (not "translations") > > > of the various codes. > > > > Definitions; not language names for display use. > > Feh. Whatever. The human-readable stuff that corresponds > to the code which you say shouldn't be read. The stuff > without which codes are meaningless. The stuff without > which two communicating parties cannot agree on the meaning > of "XX". The stuff that defines the meaning of "XX" where "XX" comes from an ISO standard is the ISO standard. That was the case in RFC 3066. This draft does not change that; it merely provides some info that may save you having to go look up the ISO standard, but that info is not the last word. > So, you're saying that the ISO definition of "CS" as > "Serbia and Montenegro" will continue to be valid, with > that meaning, in a language-tag? The meaning of an ID in the registry that came from an ISO standard is the meaning it had in the version of that ISO standar
Re: Procedural question on iasa-bcp-02 Last Call (was: Re: Consensus? Separate bank account)
just a small followup re timing I've said most of what I have to say on this issue --On 11. desember 2004 10:59 -0500 John C Klensin <[EMAIL PROTECTED]> wrote: I think getting this into wider community review, i.e. due to LC, is a good thing to do at this point, even while some of us, myself included, continue to argue on particular points we are uncomfortable with. I think we generally agree. I'm not opposed to doing it this way and can see some advantages; I just think it is important that we be extremely clear about what we are doing and that the final result really reflects community consensus. Seeing a note from Harald that seemed to explain why were weren't quite ready for a Last Call and then a Last Call announcement is, to me, the sort of thing that calls for comment. My thinking between the Wednesday note (which said "we can't send out the Last Call today") and the Thursday Last Call was that we had a proposed resolution of the issue that seemed to be accepted and was not (in my judgment) a significant change to the document - so I figured it was "close enough", and emitted the Last Call. The previous schedule had the Last Call being emitted on Wednesday. See Thursday's Last Call notice and my Saturday response to John in this thread for the rest of my thinking. Harald ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: draft-ietf-iasa-bcp-02: section 3.4 - appeals
1/ I am not alone in worrying about this section 2/ the text does not actiually say that decisions of the IAD can not be appealed (also as I understand other comments, some people would like to have that ability) 3/ the text does not catually say that only procedural issues can be appealed (it implies that but does not say that) 4/ there is no text saying what the limit of the investigation might be (for example - would the IAD have to turn over to the succession of appeal bodies confidential information about a particular contract awarding? I'd like to see an appeals section that says something like: If someone believes that the IAOC has violated the IAOC rules and procedures, he or she can ask the IETF leadership to investigate the matter, using the same procedure as is used for appeals of procedural issues in the IETF, starting with the IESG. Only IAOC processes can be appealed, actions and processes of the IAD cannot be appealed. Decisions themselves cannot be appealed. For example, the awarding of a contract to someone other than the lowest bidder can not be appealed. Appeals are limited to claims that published IAOC procedures have not been followed, for example that a pubished process that called for a 2 week public comment period only had a one week comment period in a particular case. If the IESG, IAB or the ISOC Board of Trustees find that procedures have been violated, they may advise the IAOC, but do not have authority to overturn or change a decision of the IAOC. The IAOC plays no role in appeals of WG Chair, IESG, or IAB decisions. I think that the added text makes clear what Harald said was the intent but I note that other commenters have said that the right of appeal was already too limited Scott ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: draft-ietf-iasa-bcp-02: section 6 - budget process
> I think that's what the current document's dates tries to say, using ISOC > input as to when their budget approval times are. We may have misunderstood > ISOC's input here. maybe that needs to be clearer Scott ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: Consensus? Separate bank account
John C Klensin wrote: Bert, I'm trying to catch up on all of this after nearly two weeks in which it was impossible to track these various threads. Now it is merely a hard untangling process. If you are going to use words equivalent to "irrevocable", in either this context, the ISOC payment one noted by Bernard, or elsewhere, the BCP must contain a plan about what happens if the IETF fizzles out with even a trivial balance left in IASC or IETF-designated funds. I'm not convinced. If we were writing corporate bylaws that would be true. But we aren't, so I would leave it open (the ISOC Articles of Incorporation do limit what would be possible). Brian See the more extended discussion just posted to the "RE: iasa-bcp-01 - Open Issues - Separate bank accounts" thread. john --On Thursday, 09 December, 2004 14:24 +0100 "Wijnen, Bert (Bert)" <[EMAIL PROTECTED]> wrote: Since I have seen quite a few agreement postings to below posting of Harald, I have made the change as suggested by Harald (in my working copy that is). Bert -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Harald Tveit Alvestrand Sent: Wednesday, December 08, 2004 17:11 To: [EMAIL PROTECTED] Subject: Consensus? Separate bank account After all this threading, it seems clear that it would be bad to send out the Last Call today as planned without settling this issue. (Not to mention that the secretariat still hasn't posted version -02) ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: draft-ietf-iasa-bcp-02: section 3.4 - IAOC Decision Making
Harald sez: > I don't think the IAOC should be completely paralyzed by one member being on > holiday, ill or for other reasons unable to participate. nor do I, and my suggestion does not cause that - my suggestion says that if you want a majority vote then the majority is of all current members of the IAOC not of some subset that happen to show up at a meeting > This is usually handled by quorum rules. I think the IAOC should set those > (and publish them). Bert asked about that and I think that having quorum rules is fine - but I'm assuming that most IAOC decisions will be made electonically rather than face to face so I do not think that establishing a quorum for face to face (or telephony) meetings changes the number that the determination of a majority vote works on - basically I'm saying that the IAOC should work on the same rules IETF WGs do and verify decisions on their mailing list (if one or more members miss a face to face or telephone meeting) Scott =- Date: Mon, 13 Dec 2004 05:50:09 +0100 From: Harald Tveit Alvestrand <[EMAIL PROTECTED]> To: Scott Bradner <[EMAIL PROTECTED]>, [EMAIL PROTECTED] Subject: Re: draft-ietf-iasa-bcp-02: section 3.4 - IAOC Decision Making --On 12. desember 2004 20:38 -0500 Scott Bradner <[EMAIL PROTECTED]> wrote: > > open from last version > > I think it must be made clear that all IAOC decision making involves > all IAOC members then in office - not just a subset that might show up > at a meeting or on a phone call > > maybe add: "All IAOC decision making includes all IAOC members then in > office." I cannot find a previous message from you with the word "subset" in it, but you may have used some other phrase - but I disagree with your proposal; I don't think the IAOC should be completely paralyzed by one member being on holiday, ill or for other reasons unable to participate. This is usually handled by quorum rules. I think the IAOC should set those (and publish them). Harald ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: IASA BCP -02 Designated Donations - section 5.3
"Lynn St.Amour" <[EMAIL PROTECTED]> writes: > Re: > >> 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." >> >> Editors' note: Some have suggested we need explicit IETF consensus >> on the above. So if you do not agree, please speak up ASAP. > > snip... > >> >> ISOC shall create appropriate administrative structures to >> coordinate such donations with the IASA. 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 >> account. > > > From ISOC's perspective, I would like to see the first paragraph > above stop after unduly restrictive. The last sentence is > unnecessarily restrictive and too proscriptive; and will > significantly reduce needed flexibility. This also seems to go > beyond the level of detail present in the rest of the document by > trying to define operational procedures for ISOC's "daily > business". This would also mean the first sentence in the following > paragraph beginning: "ISOC shall create... " should also be deleted. > > ISOC will, of course, work to ensure that all contributions are sought > out, are appropriately recognized, and that barriers to donations are > nonexistent. It is obviously in all our interests to do so. As I read this section, the intention is to ensure that donors who wish their funds to be used by IASA can do so easily, rather than being forced to donate them to ISOC in general. I don't think this is actually an instance in which our interests are all entirely aligned, since it would obviously be more convenient for ISOC to have full discretion over the dispersal of funds, though it would provide fewer guarantees to IASA in terms of revenue flow. Could you explain a little further what flexibility this language removes? -Ekr ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: IASA BCP -02 Designated Donations - section 5.3
Tax aspects on donations will, most probaly in many countries, call for donations to a legally incorporated entity. What is the IETF legal entity I am to write on the check and then claim for resulting tax benefits for supporting research. No tax controller will buy that ISOC is an R&D lab. jfc On 14:46 13/12/2004, Eric Rescorla said: "Lynn St.Amour" <[EMAIL PROTECTED]> writes: > Re: > >> 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." >> >> Editors' note: Some have suggested we need explicit IETF consensus >> on the above. So if you do not agree, please speak up ASAP. > > snip... > >> >> ISOC shall create appropriate administrative structures to >> coordinate such donations with the IASA. 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 >> account. > > > From ISOC's perspective, I would like to see the first paragraph > above stop after unduly restrictive. The last sentence is > unnecessarily restrictive and too proscriptive; and will > significantly reduce needed flexibility. This also seems to go > beyond the level of detail present in the rest of the document by > trying to define operational procedures for ISOC's "daily > business". This would also mean the first sentence in the following > paragraph beginning: "ISOC shall create... " should also be deleted. > > ISOC will, of course, work to ensure that all contributions are sought > out, are appropriately recognized, and that barriers to donations are > nonexistent. It is obviously in all our interests to do so. As I read this section, the intention is to ensure that donors who wish their funds to be used by IASA can do so easily, rather than being forced to donate them to ISOC in general. I don't think this is actually an instance in which our interests are all entirely aligned, since it would obviously be more convenient for ISOC to have full discretion over the dispersal of funds, though it would provide fewer guarantees to IASA in terms of revenue flow. Could you explain a little further what flexibility this language removes? -Ekr ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
unsubscribe
unsubscribe Atenciosamente / Kind regards / Mit freundlichen Grüssen Alexandre Placido de Carvalho Banco DaimlerChrysler S.A. Tecnologia da Informação Av. Maria Coelho Aguiar, 215 Bl-E 1º And São Paulo, SP, Brasil, 05804-900 Fone +55-11-3741-9565 Fax +55-11-3741-9740 Celular +55-11-9689-2225 mailto:[EMAIL PROTECTED] http://www.bancodaimlerchrysler.com.br___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: IASA BCP -02 Designated Donations - section 5.3
"Lynn St.Amour" <[EMAIL PROTECTED]> writes: > At 5:46 AM -0800 12/13/04, Eric Rescorla wrote: >> >>As I read this section, the intention is to ensure that donors >>who wish their funds to be used by IASA can do so easily, rather >>than being forced to donate them to ISOC in general. I don't >>think this is actually an instance in which our interests >>are all entirely aligned, > > If we look at this as a partnership, I don't understand why not. If > one looks at ISOC as only a funding mechanism for the IETF, this might > seem to be the case. Our interests should be more aligned than > simply financially. I agree with that, but that doesn't mean that our interests are entirely aligned. Indeed, partnerships are a situation in which it pays to take particular care to one's contracting arrangements because the respective point of alignment and disalignment are less obvious. >>since it would obviously be more >>convenient for ISOC to have full discretion over the dispersal >>of funds, though it would provide fewer guarantees to IASA >>in terms of revenue flow. >> >>Could you explain a little further what flexibility this language >>removes? > > over 80% of ISOC's org. members donate less than $10K annually and > managing these in a 'restricted accounting manner' requires more > effort and overhead. What fraction of the aggregate income comes from such donors? > And, language such as that in the BCP would require changes to our > membership programs (reducing our flexibility wrt future program > development) and consistent with other decisions to remove operational > detail from the BCP, it seems as though this language should be > removed as well. > > Finally, revamping membership/funding programs should not be done in a > piecemeal manner and with the model proposed we risk drawing fairly > arbitrary lines re designating support to the IETF vs. support to > other ISOC/IETF (technical) education and policy programs. Hmm... It's precisely those lines that I am concerned that we should draw. -Ekr ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
RE: Assuring ISOC commitment to AdminRest
At 01:40 PM 12/12/04 -0800, Dave Crocker wrote: Is the IETF making itself a wholly-owned subsidiary of ISOC, or is the IETF contracting with ISOC to do some services for the IETF. I don't see either happening, and perhaps this is part of the disconnect. The latter is clearly what Carl's document called "Scenario D", and the former could be Carl's Scenario C. As I understood the IETF consensus, neither is currently intended to become reality. At 11:36 PM 12/12/04 +0100, [EMAIL PROTECTED] wrote: are the IETF and ISOC agreeing on a partnership in the administration of the IETF? Yes. Scenario A in essence said that "we is both of us": IETF is, as its web page has proclaimed for quite a number of years, an "Organized Activity of ISOC", and a commitment to one implies a commitment to the other. Scenario O, the scenario I understand us to be working with, continues that case, but creates an organization (the IAOC) to act as an interface and give special direction to an office within ISOC (the IASA) that manages contracts and relationships on the part of the IETF. In Scenario O, the IAOC will advise the IASA on the needs of the IETF community and will discuss how to best get those needs met. This will involve a fair bit of give and take on the budget - when a new need is recognized, either there will be money and resources available to meet it, or someone (ISOC) will have to do some fundraising - which ISOC is already doing anyway, as there are already monetary needs and ISOC signed up to that a long time ago. There may need to be reallocation of resources, or a scheduling of activities to meet various needs. This is all standard management stuff, and is presumably done within the IASA. The IASA will be physically housed in and use various resources of ISOC including other staff on an allocation basis. ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: New Last Call: 'Tags for Identifying Languages' to BCP
Bruce Lilly has posted comments on the IETF list in response to the last-call announcement for a proposed revision to RFC 3066. His comments were generally negative, raising a number of concerns. I and others involved in preparation of the revision have discussed Bruce’s concerns with him, but they were not made available on the IETF list since those of us other than Bruce were not subscribed to this list. I wish to briefly summarize the outcome of that discussion for the benefit of people here. Some of Bruce’s comments were purely editorial (e.g. formatting of draft); I will not review those. Bruce’s substantive concerns were: - Accessibility of source ISO standards was referred to in the announcment as a major reason for the proposed revision, but accessibility has not been a problem in his experience. - RFC directed users to source ISO standards; the proposed revision would establish a registry that includes all ISO identifiers considered valid for use in language tags, but the documentation for those identifiers in this registry does not include both English and French language / country names. - The proposed revision makes referene to ISO 8601 time/date format being used in the registry, which is a complex and not-readily-available specification. - The ABNF used in the proposed draft permits many strings that do not conform with RFC 3066. - The proposed revision imposes no bounds on the length of tags (same as RFC 3066), and does not require registration of complete tags (different from RFC 3066). - The lack of an "Internationalization considerations" section as recommended by RFC 2277 (a.k.a. BCP 18). As a result of Bruce’s comments, those of us contributing to the development of this revision have suggested certain revisions to which the authors have indicated openness. As I will explain, these revisions would provide clarification on various matters, but would not constitute technical changes in the draft. 1. Re accessibility: it was pointed out that the draft itself does not identify accessibility of source ISO standards as one of the primary reasons for the revision. There are some minor accessibility concerns having to do with uncertainty of the on-going availability to the relevant ISO code tables, and to change histories for each of the relevant ISO standards. The proposed changes to the language-tag registry address these concerns, though there were bigger reasons for the proposed registry changes, particularly having to do with stability. 2. Re the lack of French descriptions in the registry: it was pointed out that the registry defined by RFC 3066 did not include French descriptions, and that the revised registry is not intended to replace the source ISO standards or make them irrelevant. The meaning of IDs would still be established from the ISO standards from which they were drawn, and the proposed revision would continue to make reference to them. As a result of Bruce’s comments, it was suggested that wording be revised in the draft to make this relationship clearer. 3. Re ISO 8601 time/date format: What is used in the registry is dates expressed in the format “-MM-DD”. It was agreed that it would be better to identify the format precisely rather than make the generic reference to ISO 8601. 4. Re the less restrictive ABNF: the one place that had less restrictive syntax was a production rule that was subject to additional strict constraints, namely that only certain pre-existing tags registered under RFC 3066 could fall under that production. A change to the ABNF has been suggested that would make the ABNF at that point consistent with the ABNF for RFC 3066. This does not constitute a change having any technical consequence as there is no resulting change in the set of valid tags. 5. Re upper bounds on length of tags: It was pointed out that private-use tags for both RFC 3066 and the proposed revision have no bounds on their length. The greater concern was for non-private-use tags. For these, it was pointed out that RFC 3066 also imposes no bounds on length. Admittedly, though, there is a difference because RFC 3066 requires registration of complete tags, so one can determine at any time what is the longest valid tag that may be encountered, whereas the proposed revision requires registration of sub-tags which can then be combined productively, and one cannot predict with certainty what combinations may be used. (This, IMO, is the most significant of the concerns Bruce raised.) While the proposed revision allows productive combinations of registered sub-tags, there are some limits on how combinations can be made, as specified by the ABNF. The ABNF does allow unlimited numbers of certain elements – specifically three. One of these (‘extlang’) is defined by the ABNF in anticipation of possible future extension of the language tag specification to incorpo
Re: New Last Call: 'Tags for Identifying Languages' to BCP
> From: "Peter Constable" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Cc: [EMAIL PROTECTED] > This is a multi-part message in MIME format. > > --===1521567419== > Content-class: urn:content-classes:message > Content-Type: multipart/alternative; > boundary="_=_NextPart_001_01C4E16C.40BF0707" > > This is a multi-part message in MIME format. > > --_=_NextPart_001_01C4E16C.40BF0707 > Content-Type: text/plain; > charset="us-ascii" > Content-Transfer-Encoding: quoted-printable > > Bruce Lilly has posted comments on the IETF list in response to the > last-call announcement for a proposed revision to RFC 3066. His comments > were generally negative, raising a number of concerns. I and others > involved in preparation of the revision have discussed Bruce's concerns > with him, but they were not made available on the IETF list since those > of us other than Bruce were not subscribed to this list. I wish to > briefly summarize the outcome of that discussion for the benefit of > people here. > > =20 > ... > In conclusion, I think that some of Bruce's concerns were valid, and > suggestions for changes have been presented to the authors accordingly. > I believe all of these changes can be considered to be for clarification > purposes, rather than technical changes. (No changes affecting the set > of valid tags have been made.) > ... > --_=_NextPart_001_01C4E16C.40BF0707 > Content-Type: text/html; > charset="us-ascii" > Content-Transfer-Encoding: quoted-printable > > > > > charset=3Dus-ascii"> > >
RE: Assuring ISOC commitment to AdminRest
Fred, I would certainly add my voice in support of the Internet Society adopting a specific resolution of adoption of this document (the IASA BCP, referenced, as Scott mentions, by its RFC number). This is clear demonstration of a level of organizational commitment that endures beyond the current collection of Trustees. By Law changes are certainly more challenging, and for organizations operating under the provisions of section 501 (c) (3) of the US IRS codes I am lead to understand that there is increasing scrutiny of such organizations and a prudent course of action these days may entail some external consultation to ensure that such changes remain entirely consistent with these provisions. I'm not sure that this would be entirely necessary in this case. A case could be made relating to amendments of the Society's Articles of Incorporation, but here again I personally am not convinced that it is something that the IETF should advocate, but more a matter for the ISOC Trustees to consider. Geoff At 08:51 AM 14/12/2004, Fred Baker wrote: At 03:08 PM 12/12/04 -0600, Pete Resnick wrote: "This BCP will take effect upon adoption of the BCP by the IESG and the concurrent <>" The usual way this is done, by ISOC, is by resolution; note that the statement you proposed is in the form of a resolution. For examples, you might review 96-11 and 96-12 in http://www.isoc.org/isoc/general/trustees/resltn-complete.shtml. 96-11 has been updated several times as the IETF has updated the relevant documents; 96-12 remains a fundamental guiding principle. The most recent was this past summer: ISOC accepted its responsibilities wrt RFC 3777 in an email ballot closing on 23 August. RESOLVED: The ISOC BoT accepts and approves of the IETF process entitled "IAB and IESG Selection, Confirmation, and Recall Process: Operation of the Nominating and Recall Committees" and set forth in RFC 3777, and accepts its responsibilities as described in that document. A few weeks later, the ISOC CEO named the new chair of the IETF nominating committee, which is operating on that basis. The way resolutions - or bylaw changes - come to pass is this: those who want them (in the case of what you are proposing, the IETF) formulates the resolution required, and engages in dialog with the ISOC Board, usually in person at a board meeting. Having convinced the ISOC Board that this is good for the IETF, good for ISOC, and good for all of ISOC's constituencies, someone calls the question and we vote. See http://www.isoc.org/isoc/general/trustees/bylaws.shtml. ISOC is very interested in having the IETF restructuring effort succeed. Its history suggests that if necessary it will scale back everything else it does, and risk upsetting all of its other communities, and conduct major fund-raising activities to meet the IETF's needs. I guess the discussion I have heard concerning doomsday scenarios is baffling to me for this reason if none other - there is no historical basis, and there is quite a bit of real history including places where divergence of interests might have been predicted. If a resolution reaffirming 96-12 is needed to calm IETF insecurities, we will have a board meeting following the March IETF meeting. The necessary dialog can take place and such a resolution can happen if the IETF requests it and participates in it. ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: Copying conditions
In general, I support your goal of permitting free software to fully use IETF standards. A few specific comments below, which should be taken as encouragement to continue and refine the terms, not criticism against the whole approach. "Lawrence Rosen" <[EMAIL PROTECTED]> writes: >1. Everyone is free to copy and distribute the official specification > for an open standard under an open source license. I would include "modify" in this clause, or clarify exactly which license you are talking about (e.g., GNU Free Documentation License). If I want to include portions of an RFC in my software manual (e.g., a terminology section), I want my users to have the right to modify that portion of the manual and re-distribute the derived work. I don't feel qualified to comment on the remaining patent related points. > If you think it would be useful to submit these five Open Standards > Principles as an informational RFC, certainly I can do that. But perhaps > they can be discussed here first in their current form without that > formality. I welcome comments and suggestions. If there is no broad discussion of these issues, perhaps publishing a discussion of them as an informational RFC is the right thing. I think the first goal here should be to make sure the IETF is aware of the problem wrt free software. Given the earlier discussion in this thread, some IPR WG participants appeared to not even be aware that there is a problem, which I found surprising if not disturbing. Thanks, Simon ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: New Last Call: 'Tags for Identifying Languages' to BCP
On 13 Dec 2004, at 18:34, Peter Constable wrote: 3. Re ISO 8601 time/date format: What is used in the registry is dates expressed in the format "-MM-DD". It was agreed that it would be better to identify the format precisely rather than make the generic reference to ISO 8601. Why not require dates to be formatted as per RFC 3339? In general, "-MM-DD" is ambiguous unless a timezone is specified. Joe ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
RE: Assuring ISOC commitment to AdminRest
Fred, I believe we strongly agree here. I did not think for a second that the ISOC Board would be asked to resolve to adopt a document over which it had, until that point, no opportunity to review, to offer substantive comment and to reach a position where it was comfortable with the obligations being asked of ISOC in this structure. There is a delicate piece of process management here that I personally hope will be happening sooner rather than later where the ISOC Board will be given that opportunity to provide its comments and perspectives on this document to the IETF prior to the IETF process signing off on this document for publication as a BCP. Regards, Geoff At 02:50 PM 14/12/2004, Fred Baker wrote: At 12:22 PM 12/14/04 +1100, Geoff Huston wrote: I would certainly add my voice in support of the Internet Society adopting a specific resolution of adoption of this document (the IASA BCP, referenced, as Scott mentions, by its RFC number). This is clear demonstration of a level of organizational commitment that endures beyond the current collection of Trustees. I'm certainly in favor of that after the IETF discusses the document and its provisions with the ISOC Board of Trustees and proposes such a resolution. Let me put it in terms of an analogy. draft-baker-tsvwg-vpn-signaled-preemption-01.txt was posted as an internet draft on the 25th of September. It has not been sent to the RFC Editor to be published. Of course, I also have not asked anyone to consider sending it there. So who is at fault for the fact? The IESG, for not having done what may be my will, or mine for not expressing such a will (if it exists) to the IESG? I think it is my problem - the process is documented, and I have not initiated it. Most of the documents that the ISOC BoT has received from the IETF place very little burden on ISOC - the IETF will do this and that, and there is perhaps a light duty placed on the CEO or a very improbable duty in the final event of an appeal. In this case, the IETF asks ISOC to hire people, construct budgets that roughly double its current annual investment in the IETF, and take on additional responsibilities of various kinds. The ISOC Board has had some discussion with the IETF during the process, but there is also discussion that has not happened. In terms of generating this BCP, it has been clearly stated that this is an IETF discussion, in which the IETF decides what it wants. If you were (still) on the ISOC Board, would you approve the document without a presentation of its provisions and discussion between the IETF leadership and the ISOC Board of the incorporated expectations? Hmm, thought not. That would not be consistent with a fiduciary responsibility. By the way, I requested that this dialog happen in the November board meeting in an email to [EMAIL PROTECTED] on 12 August. The reasons it did not happen should be obvious. That doesn't mean that it is not now needed. The ISOC BoT is, as I said before, very supportive and very willing. We are at this moment knee deep in generating the necessary budgets and so on. The process, just like the IETF's process for converting an I-D to an RFC, is publicly documented. But a finished document, a discussion of it with the ISOC Board, a proposed resolution, and a request to so resolve have not been received by the ISOC Board. The ball is, at this point, in the IETF's court. ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
RE: Assuring ISOC commitment to AdminRest
At 12:22 PM 12/14/04 +1100, Geoff Huston wrote: I would certainly add my voice in support of the Internet Society adopting a specific resolution of adoption of this document (the IASA BCP, referenced, as Scott mentions, by its RFC number). This is clear demonstration of a level of organizational commitment that endures beyond the current collection of Trustees. I'm certainly in favor of that after the IETF discusses the document and its provisions with the ISOC Board of Trustees and proposes such a resolution. Let me put it in terms of an analogy. draft-baker-tsvwg-vpn-signaled-preemption-01.txt was posted as an internet draft on the 25th of September. It has not been sent to the RFC Editor to be published. Of course, I also have not asked anyone to consider sending it there. So who is at fault for the fact? The IESG, for not having done what may be my will, or mine for not expressing such a will (if it exists) to the IESG? I think it is my problem - the process is documented, and I have not initiated it. Most of the documents that the ISOC BoT has received from the IETF place very little burden on ISOC - the IETF will do this and that, and there is perhaps a light duty placed on the CEO or a very improbable duty in the final event of an appeal. In this case, the IETF asks ISOC to hire people, construct budgets that roughly double its current annual investment in the IETF, and take on additional responsibilities of various kinds. The ISOC Board has had some discussion with the IETF during the process, but there is also discussion that has not happened. In terms of generating this BCP, it has been clearly stated that this is an IETF discussion, in which the IETF decides what it wants. If you were (still) on the ISOC Board, would you approve the document without a presentation of its provisions and discussion between the IETF leadership and the ISOC Board of the incorporated expectations? Hmm, thought not. That would not be consistent with a fiduciary responsibility. By the way, I requested that this dialog happen in the November board meeting in an email to [EMAIL PROTECTED] on 12 August. The reasons it did not happen should be obvious. That doesn't mean that it is not now needed. The ISOC BoT is, as I said before, very supportive and very willing. We are at this moment knee deep in generating the necessary budgets and so on. The process, just like the IETF's process for converting an I-D to an RFC, is publicly documented. But a finished document, a discussion of it with the ISOC Board, a proposed resolution, and a request to so resolve have not been received by the ISOC Board. The ball is, at this point, in the IETF's court. ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
RE: Assuring ISOC commitment to AdminRest
At 03:06 PM 12/14/04 +1100, Geoff Huston wrote: I believe we strongly agree here. Outstanding! ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: BCP-02: Financial statements and Audits
> Yes. I think I meant the same as above. However that can be part of the > ISOC audit, or not. I think that is up to IAOC to decide as they would > be receiving the audit. However, as I read the document, there is no mention that the IAOC has the right to request that the yearly ISOC audit include a check that the requirements of the BCP are being met. ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
