Re: Last Call: draft-farrell-ft-03.txt (A Fast-Track way to RFC with Running Code) to Experimental RFC
Full agreement with Stephan. Lars On Jan 11, 2013, at 22:02, Stephan Wenger st...@stewe.org wrote: Hi, Sorry for replying to this advise to secretariat thread and not to the ietf-announce thread--I'm not subscribed to ietf-announce. I have three comments, and regret that I have not followed all of the discussions regarding this draft before, so please advise if those comments have already been raised and/or resolved. First, I'm glad that the direct preferences of open source implementations over implementations compliant with other business models are mostly gone. Still, there is one reference that worries me, and that is the reference to GPLv3 code as an extreme in section 2.1. Yes, the GPL (and similar copyleft licenses) is an extreme, at least in terms of open source licensing models. However, it is not an extreme of openness or accessibility of the source code for review by WG chair, AD, and community. I would hope that we are all aware that many (most?) commercial software developers, by company policy or common sense, avoid looking at GPL-ed code, out of fear of contamination of their own closed source code. GPL-ed code is, therefore, inaccessible for verification by a large part of the IETF community, and does not serve as a good example for openness, which is how I interpret the spectrum laid out in section 2.1. A better example would be source code that is almost universally accessible. The extreme here would be source code in the public domain. Somewhat less convincing but perhaps a bit more realistically, source code under a BSD-style license like the one the IETF Trust is using. Second, the draft suggest that the existence of an implementation of the specification should serve as a shortcut towards RFC, presumably because such an implementation speak favorably to the implementability of the specification. That, however, is not universally true. Specifically, if implementer and spec writer are the same person (or part of the same team), it is quite likely that the spec takes certain assumptions made by the implementers for granted, and does not document it. That would be a bad spec, accessible implementation or not. The solution to this issue is IMO not, as the draft appears to be to suggest, to put burden on WG chairs and ADs to ensure that the spec and the implementation match. Both WG chairs and ADs have enough to do, and the incentive for rubber-stamping is quite high. A more sensible solution may be to require that the implementer is unaffiliated with the spec author; in other words, the implementation is derived from the spec + IETF discussion context. A third comment would be that, if you interpret the draft strictly, it is highly unlikely that the experiment would ever be exercised, as the implementation needs to match the draft to be advanced, and that would mean that the implementation has to follow in lockstep with the draft development up until the final version. With respect to the core subject matter of a draft, that may be fine. However, many of the final edits in a draft come as input from IETF wide community review; things like security, congestion control, and the like. Those are often trivial to write down, but can have a major implementation impact. To cure this, it would IMO be acceptable if the implementation would be required to match the latest or a reasonably young, i.e. a few months old version of the draft. Please consider this. Thanks, Stephan On 1.11.2013 08:21 , Adrian Farrel adr...@olddog.co.uk wrote: Hi Alexa, Please be aware of this document that has just entered a four-week IETF last call. The document describes a proposed IETF process experiment under the rules of RFC 3933. The proposed experiment calls on the IETF Secretariat to take specific actions under certain circumstances in corner cases of the experiment. Could you please have someone in the Secretariat look at the draft and comment on the practicalities of the actions. Note that, at this stage, no changes to the tools are proposed so any actions would require manual intervention (if the experiment were successful and resulted in permanent changes to IETF process we might make changes to the tools at some future time). Thanks, Adrian -Original Message- From: ietf-announce-boun...@ietf.org [mailto:ietf-announce- boun...@ietf.org] On Behalf Of The IESG Sent: 11 January 2013 15:15 To: IETF-Announce Subject: Last Call: draft-farrell-ft-03.txt (A Fast-Track way to RFC with Running Code) to Experimental RFC The IESG has received a request from an individual submitter to consider the following document: - 'A Fast-Track way to RFC with Running Code' draft-farrell-ft-03.txt as Experimental RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by
Re: I-D Action: draft-moonesamy-rfc2050-historic-00.txt
I object to making RFC 2050 historic without retaining at least the content of its Section 1 as an IETF BCP. While the IETF did formally hand over details of address allocation policy to IANA, we did so knowing that the RIRs themselves, and IANA, considered themselves bound by RFC 2050 (see the list of authors of that document). An update of RFC 2050, within the scope set by the IETF-IANA MoU, would be reasonable. Abrogation is not reasonable. Regards Brian Carpenter (speaking only for myself) On 12/01/2013 08:51, internet-dra...@ietf.org wrote: A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Reclassifying Internet Registry Allocation Guidelines to Historic Author(s) : S. Moonesamy Filename: draft-moonesamy-rfc2050-historic-00.txt Pages : 4 Date: 2013-01-12 Abstract: RFC 2050 describes the registry system for the distribution of globally unique Internet address space and registry operations. It also discusses about policy issues which are outside the scope of the IETF. This document reclassifies RFC 2050 as Historic. It also reclassifies RFC 1366 and RFC 1466 as Historic. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-moonesamy-rfc2050-historic There's also a htmlized version available at: http://tools.ietf.org/html/draft-moonesamy-rfc2050-historic-00 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ ___ I-D-Announce mailing list i-d-annou...@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
Re: I-D Action: draft-moonesamy-rfc2050-historic-00.txt
Hi Moonesamy, I also think similar with Carpenter, why reclassify to historic. rfc2050 is still valid, and why limiting the ietf? AB
draft-moonesamy-mail-list-protocol-00
Hi Moonesamy, I like the draft, and suggest that you add that the WG chair SHOULD contribute to the WG list. Also that any question in the list SHOULD be answered by the responsible (e.g. author of the ID discussed). However, I have many suggestions to make the ID valuable. Thanks for the input :) AB
Re: I-D Action: draft-moonesamy-rfc2050-historic-00.txt
At 01:36 12-01-2013, Brian E Carpenter wrote: I object to making RFC 2050 historic without retaining at least the content of its Section 1 as an IETF BCP. From Section 1 of RFC 2050: Currently there are three regional IRs established; InterNIC serving North America, RIPE NCC serving Europe, and APNIC serving the Asian Pacific region. The above information is outdated. While the IETF did formally hand over details of address allocation policy to IANA, we did so knowing that the RIRs themselves, and IANA, considered themselves bound by RFC 2050 (see the list of authors of that document). That was in 1996. The question is whether BCP 12 reflects current practices. An update of RFC 2050, within the scope set by the IETF-IANA MoU, would be reasonable. Abrogation is not reasonable. Noted. At 03:44 12-01-2013, Abdussalam Baryun wrote: I also think similar with Carpenter, why reclassify to historic. rfc2050 is still valid, and why limiting the ietf? IETF participants have not decided about policies regarding IP address allocation since well over 10 years. Such matters are determined within other communities. It would only be limiting to the IETF if it is a matter directly related to IETF protocols. Regards, S. Moonesamy
Re: Last Call: draft-farrell-ft-03.txt (A Fast-Track way to RFC with Running Code) to Experimental RFC
Hiya, On 01/11/2013 09:02 PM, Stephan Wenger wrote: Hi, Sorry for replying to this advise to secretariat thread and not to the ietf-announce thread--I'm not subscribed to ietf-announce. I have three comments, and regret that I have not followed all of the discussions regarding this draft before, so please advise if those comments have already been raised and/or resolved. First, I'm glad that the direct preferences of open source implementations over implementations compliant with other business models are mostly gone. FWIW, I'm not at all glad about that personally but the text we have probably does represent a consensus. Note, there are others like me who'd prefer to favour open-source here, as well as some, presumably including you, that would prefer something like the opposite. Still, there is one reference that worries me, and that is the reference to GPLv3 code as an extreme in section 2.1. Yes, the GPL (and similar copyleft licenses) is an extreme, at least in terms of open source licensing models. However, it is not an extreme of openness or accessibility of the source code for review by WG chair, AD, and community. I would hope that we are all aware that many (most?) commercial software developers, by company policy or common sense, avoid looking at GPL-ed code, out of fear of contamination of their own closed source code. rant I am aware that lawyers and others do encourage ignorance in such ways. Its an incredibly stupid way to behave IMO even if understandable in a horrendously short-sighted kind of way. Thankfully I don't work in a place that has to deal with such anti-scientific idiocy. (Being a university we have our own idiocies:-) And there are even many commercial companies that have yet to adopt such silliness. So there's hope for us all yet. /rant GPL-ed code is, therefore, inaccessible for verification by a large part of the IETF community, and does not serve as a good example for openness, which is how I interpret the spectrum laid out in section 2.1. A better example would be source code that is almost universally accessible. The extreme here would be source code in the public domain. Somewhat less convincing but perhaps a bit more realistically, source code under a BSD-style license like the one the IETF Trust is using. I'm not at all sure what concrete suggestion you're making, other than disparaging GPL. If your suggestion is s/GPLv3/BSD license/ then that could be done but would make no difference at all to this draft, so I plan to leave this as-is. Second, the draft suggest that the existence of an implementation of the specification should serve as a shortcut towards RFC, presumably because such an implementation speak favorably to the implementability of the specification. That, however, is not universally true. Very few things in the IETF are universally true;-) Specifically, if implementer and spec writer are the same person (or part of the same team), it is quite likely that the spec takes certain assumptions made by the implementers for granted, and does not document it. That would be a bad spec, accessible implementation or not. The solution to this issue is IMO not, as the draft appears to be to suggest, to put burden on WG chairs and ADs to ensure that the spec and the implementation match. Both WG chairs and ADs have enough to do, and the incentive for rubber-stamping is quite high. A more sensible solution may be to require that the implementer is unaffiliated with the spec author; in other words, the implementation is derived from the spec + IETF discussion context. That's a fair point but, a) we don't consider affiliations like that in the IETF, at least not in a written-rules kind of way, and b) there's nothing in principle wrong with the editor writing code. While it is better if the code is written independent of the editor and even better if someone who hasn't been involved in the WG has done the coding, that'd be too high a burden to require IMO, especially given that this is an experiment. I'd have no problem adding text that encouraged some form of independence though, if you'd like to provide some. A third comment would be that, if you interpret the draft strictly, it is highly unlikely that the experiment would ever be exercised, as the implementation needs to match the draft to be advanced, and that would mean that the implementation has to follow in lockstep with the draft development up until the final version. With respect to the core subject matter of a draft, that may be fine. However, many of the final edits in a draft come as input from IETF wide community review; things like security, congestion control, and the like. Those are often trivial to write down, but can have a major implementation impact. To cure this, it would IMO be acceptable if the implementation would be required to match the latest or a reasonably young, i.e. a few months old version of the
Re: I-D Action: draft-moonesamy-rfc2050-historic-00.txt
Brian, On Jan 12, 2013, at 1:36 AM, Brian E Carpenter brian.e.carpen...@gmail.com wrote: I object to making RFC 2050 historic without retaining at least the content of its Section 1 as an IETF BCP. Which part of section 1 do you think has any relevance to the IETF as a BCP? While the IETF did formally hand over details of address allocation policy to IANA, we did so knowing that the RIRs themselves, and IANA, considered themselves bound by RFC 2050 (see the list of authors of that document). As one of those authors, I will state that I believe that RFC 2050 should be moved to historic (actually should have been moved quite some time ago). - RFC 2050 was an attempt to document the _then current_ policies and processes of the RIRs. An RFC was chosen because there was no other viable publication mechanism that would reach the relevant communities. The Internet has changed a bit since 1996. RFC 2050 documents the Best Current Practice of the then Internet registries for a very brief window -- RIR policies had already changed from what was documented in RFC 2050 by the time it had gotten through the IESG gauntlet. - RFC 2050 explicitly discusses allocation policy of IPv4. IPv4 allocation is largely over. The vast majority of RFC 2050 is not particularly relevant to IPv6. Address allocation policies are and have been defined within the address consuming communities which have (reasonably) robust, open, and transparent mechanisms by which anyone can contribute. The IPv6 allocation framework has been defined in other RFCs. - RFC 2050 discusses allocating IPv4 addresses to RIRs, ISPs, and end users for operational purposes and is unrelated to meeting the technical protocol standardization needs of the IETF. An update of RFC 2050, within the scope set by the IETF-IANA MoU, would be reasonable. No, since addressing is _explicitly_ declared out of scope of that MoU, see section 4.3 of RFC 2860: Two particular assigned spaces present policy issues in addition to the technical considerations specified by the IETF: the assignment of domain names, and the assignment of IP address blocks. These policy issues are outside the scope of this MOU. I don't think it is particularly useful or helpful to try to assert that the IETF did formally hand over address allocation to IANA since, as you know, there are lots of folks who have, do, and will claim address allocation, as an operational matter, was never the IETF's to hand over. What might be useful/helpful is to try to identify the portions of RFC 2050 that have any relevance to the IETF and verify that those portions are covered elsewhere. Regards, -drc
Re: Last Call: draft-farrell-ft-03.txt (A Fast-Track way to RFC with Running Code) to Experimental RFC
Hiya, So I think the actions arising are: - consider whether to have a not before IETF meetings restriction and make this an 18 month experiment - maybe remove the text about -bis RFCs. (I slightly prefer it as-is fwiw, but let's see if we get more input) Let me know if that's wrong. Cheers, S. On 01/11/2013 09:34 PM, SM wrote: Hi Stephen, At 12:36 11-01-2013, Stephen Farrell wrote: You mean rough consensus of the IETF I guess? Good question. No, I mean consensus as that's also part what is gauged during a Last Call. First, WG rough consensus is formally unaffected. As is IESG review. And if IETF LC comments are received that do meet the IESG discuss criteria then those should be handled as now. I am not concerned about the WG rough consensus angle (for the experiment) as it is a subset of a Last Call. So I guess we're left with cases where there's a lack of rough consensus during IETF LC but where the meat of the disagreement is something that doesn't qualify for an IESG discuss ballot. Hmm, you mentioned rough consensus on an IETF Last Call. The IETF Last Call is about consensus. I may have misunderstood the experiment as I did not read it as rough consensus and running code. To say it differently, there isn't any change to the IETF Last Call; this is more about fast-tracking the WGLC and the IETF Last Call. I'd say that'd be quite likely to allow the responsible AD to say that there had been so much debate during IETF LC that this experiment ought not be used. Ok. So, I don't think this experiment has any major effect there really but maybe has a subtle one. I'll be interested in seeing if this happens if we do the experiment. Let's see how the experiment works out. I don't get what you mean. Can you explain? (I get that you don't want to mention -bis cases, but I don't get why.) What the experiment can do is make it easier to move from unpublished specification to RFC. The -bis draft is from a previous RFC. If you try to cover it the experiment can turn into a significant process change. I prefer to leave that unspecified and see how the experiment works out instead of telling people to use it for -bis drafts. In a -bis document is in good shape it should not be a significant problem to get it through the process. Not a bad idea. Something like fast-track must be started at least one month (longer?) before an IETF meeting starts ? The fast-track process cannot be initiated within two weeks of an IETF meeting. You lose five weeks, two before, one for the meeting, and two after. I guess the only problem I'd have with that is that for an experiment that'd run for one year, that takes out about 4 months (3 meetings and the year-end holidays) which is a lot. Ok, make it one week then (see my previous comment). If we extended the experiment to 18 months duration I'd have no problem with something like that though. Or with leaving it as-is. It can be left out as an implementation detail if it is easier to keep the experiment to 12 months. Can be. If a WG participant says the decision you made on that draft is broken: I appeal then they first send that to the WG chair. Ok. I don't see any text change being suggested there. Correct me if I'm wrong. You're not wrong. Regards, -sm
Re: I-D Action: draft-moonesamy-rfc2050-historic-00.txt
--On Saturday, January 12, 2013 11:36 -0800 David Conrad d...@virtualized.org wrote: ... No, since addressing is _explicitly_ declared out of scope of that MoU, see section 4.3 of RFC 2860: Two particular assigned spaces present policy issues in additionto the technical considerations specified by the IETF: the assignmentof domain names, and the assignment of IP address blocks. Thesepolicy issues are outside the scope of this MOU. I don't think it is particularly useful or helpful to try to assert that the IETF did formally hand over address allocation to IANA since, as you know, there are lots of folks who have, do, and will claim address allocation, as an operational matter, was never the IETF's to hand over. What might be useful/helpful is to try to identify the portions of RFC 2050 that have any relevance to the IETF and verify that those portions are covered elsewhere. David (and Brian and Subramanian), There are cans of poisonous, vicious vipers (only superficially resembling cans of worms) that are, IMO, best not opened and this is, IMO, one of them. The reasons for that are probably as obvious to you as they are to me and I certainly agree with most of your last paragraph above. However, I don't think the section of 2860 that you cite helps very much because there is another way to read it. That alternate reading, which I believe is actually the correct one, says that the addressing issues (and the domain ones) consist of two parts technical considerations which are specified by the IETF and policy issues that are someone else's problem. Indeed, it says policy issues in addition to..., which I think recognizes that those technical considerations may have policy implications and that it is within scope for the IETF to specify those too. The exclusion is for policy issues that are _not_ part of the technical considerations. With the understanding that the boundary that posits is very fuzzy, I don't think that basic principle has changed significantly since the MOU and probably not much since RFC 2050. The IETF still has responsibility for the technical specification of addresses and the policies that narrowly implies; other policy issues, including the models for allocations of addresses to those who will use them, belong to others. I think it unwise try to define the boundary more precisely than that. You may recall that an attempt was made to do so more or less unilaterally at the time the NRO was formed; in my opinion, that didn't work out especially well for the Internet (YMMD). If Jon were participating in this conversation today, I'm quite sure that he would be saying that it is much more important for the RIRs and the IETF to work together to get the best result for the Internet rather than putting energy into trying to legislate or enforce a boundary (whether that effort started in the IETF or in the RIRs). best, john
RE: Last Call: draft-farrell-ft-03.txt (A Fast-Track way to RFC with Running Code) to Experimental RFC
+1 [IAB Chair hat off]. Date: Fri, 11 Jan 2013 22:25:38 +0100 Subject: Re: Last Call: draft-farrell-ft-03.txt (A Fast-Track way to RFC with Running Code) to Experimental RFC From: abdussalambar...@gmail.com To: s...@resistor.net CC: ietf@ietf.org; i...@ietf.org Hi SM, I totally agree with your comments and suggestions, the draft SHOULD mention the important clarifications and the answers to SM's questions. This is an important draft and SHUOLD be clear about such important details in sections, why it ignores them without refering to informative procedure items to link things for understanding. How do authors write these drafts are they done with following procedure, AB In Section 1: Additionally, the experiment will only require issues raised during these three stages to be addressed if they meet the IESG's Discuss criteria. Does this mean that a document does not have to represent consensus? In contrast, a -bis RFC that aims for Proposed Standard or Experimental is likely to be a fine candidate. I read what the document proposes as lowering the barrier of entry for first publication. My preference is to say nothing about -bis RFCs (see quoted text). Some of the -bis drafts I have come across (note that this is not related to a draft being discussed currently) are not well-written even though there is running code. The running code might be due to author intervention instead of a blind test of the specification. In Section 2: Implementations developed during the production of an Internet-draft can indicate that a working group has had the opportunity to get early confirmation of its engineering choices. Agreed. In Section 3: Any Working Group Last Call (WGLC) or Area Director (AD) review (which are routinely done, though not part of the formal [BCP9] process) will run in parallel with the two-week IETF Last Call (IETF-LC) period. I am not suggesting changing the two weeks. It can cause logistical problems. I'll take the risk of trying this experiment. Only comments that would be DISCUSS-worthy according to the IESG Discuss Criteria [DCRIT] need be handled during last call. Other comments can be handled or not, at the authors/editors discretion. See my previous comment about this criteria. In Section 4: The fast-track process can be used for bis RFCs and might well be quite suitable for those. I suggest removing this. If the timers (IETF LC or the two-weeks after IETF LC for fixing things) co-incide with a major holiday period or IETF meeting then the responsible AD can add a week or two as appropriate. I suggest not using the Fast-Track if it is less than two weeks before or after an IETF meeting. Some people only do IETF work during that period and that results in a spike. I don't think that it is a good idea for this experiment to encourage work during the meeting phase instead of the mailing list. In Section 5: An AD who wishes to do her review in parallel with Last Call is always free to make that choice. his or a gender neutral term. This memo itself has no impact on appeal processes. However, in considering an appeal that relates to a document that has been fast-track processed, the relevant judge (WG chair, AD, IESG or IAB as appropriate) should consider the requirements posited here. The WG Chair is not a judge in such cases as it would be his/her decision being appealed. Some people are discouraged from bringing work into the IETF because of the long debates (which I likely contributed to). Big companies have an incentive to do work within the IETF. There is a perception in open source circles than there isn't much to gain in having a specification published as a RFC. The young, free and wild will not listen to the fogies. The better approach, in my opinion, is not to act as a gatekeeper or encourage a wall-garden attitude. Regards, -sm
Re: I-D Action: draft-moonesamy-rfc2050-historic-00.txt
If Jon were participating in this conversation today, I'm quite sure that he would be saying that it is much more important for the RIRs and the IETF to work together to get the best result for the Internet rather than putting energy into trying to legislate or enforce a boundary (whether that effort started in the IETF or in the RIRs). can't speak for dr postel. but this seems a responsible position. randy
Re: I-D Action: draft-moonesamy-rfc2050-historic-00.txt
John, On Jan 12, 2013, at 2:21 PM, John C Klensin john-i...@jck.com wrote: However, I don't think the section of 2860 that you cite helps very much because there is another way to read it. As you know, there are many in both high and low places who choose the interpretation of 2860 that best fits their particular interests, regardless of the intent of that document (or, from personal experience, efforts to try to explain history or reality). As such, I'll repeat: I do not believe it useful or helpful to go down that particular rat hole. The more relevant bit: The IETF still has responsibility for the technical specification of addresses and the policies that narrowly implies; other policy issues, including the models for allocations of addresses to those who will use them, belong to others. I believe RFC 2050 does (and did) _not_ address technical specifications of addresses, but rather documented (past tense) the then best current practice of policies associated with the operational deployment of those addresses for a short period around 1995 or so. The Internet has moved on. The IETF still has the responsibility to define address technical specifications (e.g., an IPv6 address is 128 bits long), however I do not believe the IETF now has the responsibility to define operational deployment policy or processes (if it ever did). As such, I think it perfectly appropriate to move RFC 2050 to historic since, in fact, it actually is. If Jon were participating in this conversation today, I'm quite sure that he would be saying that it is much more important for the RIRs and the IETF to work together to get the best result for the Internet rather than putting energy into trying to legislate or enforce a boundary I doubt anyone rational would disagree with this, but I don't think that's the topic of discussion. The issue, as I understand it, is that RFC 2050 is outdated and historic and its status should be made to reflect that truth. Regards, -drc
Re: I-D Action: draft-moonesamy-rfc2050-historic-00.txt
On 1/12/2013 4:19 PM, David Conrad wrote: I believe RFC 2050 does (and did) _not_ address technical specifications of addresses, but rather documented (past tense) the then best current practice of policies associated with the operational deployment of those addresses for a short period around 1995 or so. The Internet has moved on. The IETF still has the responsibility to define address technical specifications (e.g., an IPv6 address is 128 bits long), however I do not believe the IETF now has the responsibility to define operational deployment policy or processes (if it ever did). As such, I think it perfectly appropriate to move RFC 2050 to historic since, in fact, it actually is. The document's abstract declares the document's purposes to be: This document describes the registry system for the distribution of globally unique Internet address space and registry operations. ... This document describes the IP assignment policies currently used by the Regional Registries to implement the guidelines developed by the IANA. The guidelines and these policies are subject to revision at the direction of the IANA. Unless I'm misunderstanding something, there's a simple issue here that should be resolved through a simple question: Does the document still satisfy either of these purposes sufficiently and accurately. My understanding from this thread (and elsewhere) is that the answer is no. By definition, the document's role is therefore Historic and it only makes sense to make this official. If there is content in the document that happens to still be useful, it should be extracted and published separately, so that no reader will suffer confusion and think that the remainder of the document remains applicable. d/ ps. A replacement document that /is/ sufficient to the current Internet would be a service to the community. -- Dave Crocker Brandenburg InternetWorking bbiw.net
Re: I-D Action: draft-moonesamy-rfc2050-historic-00.txt
vituperation I believe RFC 2050 does (and did) _not_ address technical specifications of addresses, but rather documented (past tense) the then best current practice of policies associated with the operational deployment of those addresses for a short period around 1995 or so. from this ops pov, the danvers meeting was where the ops and the irs met to agree on the critical issue of sean's ags+s falling over, agree that we would not filter on shorter than a /19 outside of swamp, and that the irs would allocate no longer than /19. that the ir folk then took it and made a massive layer nine out of it was on your own heads. the american idiom is that chickens come home to roost. RFC 2050 is outdated and historic and its status should be made to reflect that truth. made your bed, sleep in it. maybe learn not to do it again? nope. the irs keep on making massive and complex policy. there were and are alternatives http://www.apnic.net/policy/proposals/prop-103 we need bookkeepers. we get wannabe regulators. now we have wannabe regulators who want to write the regulations completely outside of coordination with the rest of the community. oh goodie. randy
Re: I-D Action: draft-moonesamy-rfc2050-historic-00.txt
On Jan 12, 2013, at 7:14 PM, Randy Bush ra...@psg.com wrote: RFC 2050 is outdated and historic and its status should be made to reflect that truth. made your bed, sleep in it. Mea culpa, but it's time to get out of bed. maybe learn not to do it again? nope. To be clear, I think RFC 2050 was helpful when it was published, however as I said, the Internet has moved on and I believe there are better venues in which operational policies for addresses can be developed. I figure it's called best _current_ practice for a reason. we need bookkeepers. we get wannabe regulators. +1 now we have wannabe regulators who want to write the regulations completely outside of coordination with the rest of the community. oh goodie. I don't believe moving RFC 2050 to historic implies the operational community efforts to develop policy is completely outside coordination with the rest of the community. I would, in fact, be quite supportive of (and would even contribute to (if it would be helpful)) IETF input to ICANN/IANA on a replacement for RFC 2050. Regards, -drc
Re: I-D Action: draft-moonesamy-rfc2050-historic-00.txt
more vituperation we need bookkeepers. we get wannabe regulators. +1 and, as a friend pointed out, in sidr, we are arming them. i try hard to ameliorate this. but that's another subject. I don't believe moving RFC 2050 to historic implies the operational community efforts to develop policy is completely outside coordination with the rest of the community. fwiw, i do not consider the irs to represent the operational community, though they claim very loudly to do so. they have coopted the space, but, imiho, represent the interests of self-perpetuating organizational fiefdoms far more than operators. itu-t wannabes. I would, in fact, be quite supportive of (and would even contribute to (if it would be helpful)) IETF input to ICANN/IANA on a replacement for RFC 2050. at russ's request (i did warn him of the poolpah), i tried to start a 2870 (dns root ops) bis with only one sentence added. 2.7 Root servers SHOULD fully support queries and make corresponding responses with either IPv4 or IPv6. the root ops private fiefdom rose up in objetion and non-cooperation which has become their hallmark. fighting fiefdoms is a waste of time. the answer is to shut them the hell down. randy
digressive rant on internet fiefdoms
fighting fiefdoms is a waste of time. the answer is to shut them the hell down. a friend asked (to put it politely:-) me to clarify. [ first, mea multi culpea, i helped start and/or served on the board (or equivalent) of a number of the organizations against which i rail. consider me the loyal opposition. but i try, as we say, to work for the internet. ] when people's livelihoods depend on an organization's existence, self- interest is inevitable. no blame, we're all just funny monkeys. there are no evil players here, just humans. it's not their fault, it is ours for creating and allowing it. yes, we need the ir function fulfilled. but i have become more and more sceptical that we need six organizations doing it. and organizations with large staff. we have built a privileged regulatory class. when you have a large building, half a dozen 'coffee ladies' on staff, or a bunch of lawyers, then it's time for a revolution. the ietf and nanog outsource out all services in arms' length contracts. this has responsibility and accountability built in [0]. yes, all organizations are self perpetuating, but i prefer the model where no one is paid (directly [1]). and i much prefer the ietf's nomcom model, which ameliorates the board election game of the irs, nanog, etc, which are beauty contests and do not serve the community well. imiho, the beauty contests, the paid fiefdoms, and the lawyers have led us from the bookkeeping model to the regulatory. randy -- [0] - Accountability is something that is left when responsibility has been subtracted. -- Pasi Sahlberg [1] - http://archive.psg.com/051000.ccr-ivtf.pdf
