Re: S stands for Steering [Re: Should the IESG rule or not?]
Date:Fri, 01 Jul 2005 03:25:25 +0200 From:Brian E Carpenter <[EMAIL PROTECTED]> Message-ID: <[EMAIL PROTECTED]> | As I said in the plenary in Minneapolis, my goal is for the IESG to be | able to *steer*. Not to rule. Steering means finding the narrow line | between too far to the left and too far to the right. Also remember that the IESG, including the "steering" existed long before the IESG got to approve almost anything. Steering relates to managing the progress of the working groups, or that's where it came from. The IESG is intended to drive (or steer) the working groups so that overall progress is made. | It also means | being decisive, and it means listening to the community as a whole, | not just to individuals who post a lot of mail. That's true. But when there is a diversity of opinion, you cannot assume that everyone who says nothing is agreeing with you. They're just as likely agreeing with those opposed to you, but have nothing new to add. In general it is best to assume that the split of those who say nothing is generally the same as those who do comment. If everyone (or almost everyone) who comments is in general agreement, it is fair to assume that those who don't comment agree. If there's a bit debate among a group of people, the reasonable conclusion is that the same debate would exist among everyone else. If there's one or two people opposed to many others, you can generally assume that most of those who don't comment will agree with the majority who do. | We'll discuss this in plenary at the next IETF. That's fine. But do remember it is the mailing list(s) that make the decisions, not the meetings. Also remember that "no consensus" in an issue like this, really needs to mean "no authority" - if you cannot get at least most of the community to agree with the IESG position, then the IESG cannot just claim the authority and say "there is no consensus that we should not have it". kre ps: while I am sure that you want to believe that you have general community support, that isn't the way I see it - rather, most of the support I've seen for the IESG position looks to be coming from current or former IESG members, whereas the opposition looks to be from everywhere, including former IESG/IAB members, and people who have never been in a "management" role. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: S stands for Steering [Re: Should the IESG rule or not?]
If I may plead for a moment of silence ... There is an Internet Draft that is intended to give the community a chance to provide comments on what the IETF vision of option registration might be - or, might not be. If we could discuss this draft, and say things like "I agree", "I disagree", "goes too far", "doesn't go far enough", it seems to me that we might actually be able to come closer to closure in this thread (and its predecessors), one way or the other. That URL, again, is http://www.ietf.org/internet-drafts/draft-klensin-iana-reg-policy-00.txt. And I apologize for having nothing whatsoever to say about spamops, killfiles, or steering. Thanks, Spencer ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: S stands for Steering [Re: Should the IESG rule or not?]
> From: Brian E Carpenter > > I'm supposed to be on vacation so this will be brief, but I don't > think that your assertion about what "the community" has said is > backed up by postings from a sufficient number of people to be a > community view. Most people in the community haven't posted one way > or the other. I haven't counted, but in the recent discussions about > the hop by hop option, I've seen a number of messages agreeing with > the IESG's decision, contrasted with a large number of critical > postings from just a few people. My view is that your impression of the reaction is incorrect. in taking the position that respondents can be classified as either: a) being satisfied with the IESG *decision*, b) dissatisfied or uncomfortable with the decision, or c) could not be clearly determined by the content of their response, I came up with the following list. Dissatisfied Satisfied Other - - Robert Elz Thomas Narten Barbara Roseman John Leslie Sam HartmanYakov Rekhter Ken Carlberg Bob Hinden Scott Brim Ralph Droms Brian CarpenterSpencer Dawkins Steve Silverman Allison Mankin Thomas Hruska Jefsey MorfinHarald Alvestrand Randy Presuhn John Klensin Keith MooreScott Bradner Nick Staff Bill Sommerfeld Lawrence Roberts Eliot Lear Vint CerfJoel Halpern Dave Crocker Margaret Wasserman Ned FreedJeffrey Hutzelman Grenville Armitage Hans Kruse I listed names so that people could object to my interpretation, and I'm sure I made a mistake or two. But at best, it seems the reaction is split, and not to be viewed as objections coming from simply a few but persistant people. -ken ps, I hope your vacation is going well :) ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: S stands for Steering [Re: Should the IESG rule or not?]
As a general statement, I think this document goes too far. Several issues occur to me reading it. A sampling follow. 1) As written, the document seems to say that all small allocation spaces should be "repaired". This does not always follow. Making the IP version space bigger does not seem a desirable approach to interoperability, for example. 2) There are issues of appropriateness that are complex, and need to be considered. For example, there is an ongoing debate in the routing area as to how much information, and of what kinds, ought to be carried in the routing protocols. (The problem exists for both BGP and our intra-domain link state routing protocols.) It would really complicate such a discussion if the working groups did not have the ability to say "no, there are uses of these fields which are wrong, and we will not encourage them be registering them." 3) No matter how much we claim that registration is not endorsement, it will frequently be seen as endorsement. 4) Allowing arbitrary values in fields which need to be understood for interoperability can make life very difficult. It turns out that even when the protocol has planned well for unknown values, the negotiations and exchanges can get very tricky. And the more extensive the set of options, the harder it gets. 5) There are sometimes subtleties about who is appropriate to provide the definitions for some values. Particularly if the meaning relates to proprietary activities. Just having clear documentation is not always sufficient. 6) For some purposes it is important that the document actually be right, not just clear. To use a historical case, there was a request for registration of a number space at one time which was accompanied by I-Ds, etc. It was however mathematical falsehood. It would not work. Registering it would have been a disservice to the community. In that particular case, the problem was clear. But other cases may not be so clear. 6') We are usually fairly careful about registering cryptographic algorithms, and we try to make sure that our experts think the algorithms make sense. This document would seem to do away with such checks. (I believe this is an example of one way that a document may be extant, and readable, but subtly harmful or false.) 7) There are clearly spaces / applications / domains where people can and should be encouraged to experiment. But not all spaces have that property. We have enough trouble with junk in spaces like DNS without agreeing to register any type code / meaning that someone wants to write up. Yours, Joel M. Halpern At 12:11 AM 7/1/2005, Spencer Dawkins wrote: If I may plead for a moment of silence ... There is an Internet Draft that is intended to give the community a chance to provide comments on what the IETF vision of option registration might be - or, might not be. If we could discuss this draft, and say things like "I agree", "I disagree", "goes too far", "doesn't go far enough", it seems to me that we might actually be able to come closer to closure in this thread (and its predecessors), one way or the other. That URL, again, is http://www.ietf.org/internet-drafts/draft-klensin-iana-reg-policy-00.txt. And I apologize for having nothing whatsoever to say about spamops, killfiles, or steering. Thanks, Spencer ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: S stands for Steering [Re: Should the IESG rule or not?]
On 07/01/2005 13:02 PM, Ken Carlberg allegedly wrote: > My view is that your impression of the reaction is incorrect. in > taking the position that respondents can be classified as either: > a) being satisfied with the IESG *decision*, b) dissatisfied or > uncomfortable with the decision, or c) could not be clearly > determined by the content of their response, I came up with the > following list. You can add me to the "satisfied" column. The IESG is asked to take positions and to lead (despite what a few think). That's risky -- no matter what they do they get criticism from somewhere. Maybe they didn't *phrase* the announcement perfectly, but the decision is correct. Something like this must have a serious, long-term IETF review. We need to take the overall design of the Internet into account and not just be administrators. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: S stands for Steering [Re: Should the IESG rule or not?]
Scott W Brim wrote: On 07/01/2005 13:02 PM, Ken Carlberg allegedly wrote: My view is that your impression of the reaction is incorrect. in taking the position that respondents can be classified as either: a) being satisfied with the IESG *decision*, b) dissatisfied or uncomfortable with the decision, or c) could not be clearly determined by the content of their response, I came up with the following list. You can add me to the "satisfied" column. The IESG is asked to take positions and to lead (despite what a few think). That's risky -- no matter what they do they get criticism from somewhere. Maybe they didn't *phrase* the announcement perfectly, but the decision is correct. Something like this must have a serious, long-term IETF review. We need to take the overall design of the Internet into account and not just be administrators. Count me in too. The IESG might have been more polite in their answer, but yes, "IESG Review" in an IANA considerations text means just that, and its not the same as "FCFS". --Jari ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: S stands for Steering [Re: Should the IESG rule or not?]
And I apologize for having nothing whatsoever to say about spamops, killfiles, or steering. as well you should. "we" will let it slide this time, Mr. Dawkins. but don't let it happen again. -- d/ Dave Crocker Brandenburg InternetWorking +1.408.246.8253 dcrocker a t ... WE'VE MOVED to: www.bbiw.net ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: S stands for Steering [Re: Should the IESG rule or not?]
On Fri, 1 Jul 2005, Scott W Brim wrote: You can add me to the "satisfied" column. The IESG is asked to take positions and to lead (despite what a few think). That's risky -- no matter what they do they get criticism from somewhere. Maybe they didn't *phrase* the announcement perfectly, but the decision is correct. Something like this must have a serious, long-term IETF review. We need to take the overall design of the Internet into account and not just be administrators. FWIW, I haven't said anything on the thread but I'm largely satisfied with the IESG action, though I can understand the arguments why documenting the proposed use could be useful. However, I believe there is a significant difference between "proposed use" and "actual use". I'm hoping that most of the people who come asking for these code points, but don't get one, will change their designs (so a code point is not needed) or engage in a dialogue (instead just picking a code point and getting it implemented). I'd certainly hope that mainstream vendors wouldn't just add unregistered/rejected codepoints in their products, and if the use is restricted to a minor vendor or a very specific environment, I doubt many care too much one way or the other. If we want to enable any kind of protocol to get any kind of code point (instead of just stealing one), I'd think it might make sense to split a few codepoints from the registries to be allocated using a more relaxed process (RFC3692/BCP82 may or may not be a partial solution here), so that the vendors could more easily just ignore those options. However, I think an important benefit of a sufficiently strict allocation procedure is that those people who have a genuine desire to design a protocol that's at least halfway sensible need to initiate the community in a technical dialogue. In the process maybe the community is swayed, or the protocol designer sees that a different approach may be much better. We can always hope so. No matter what we do, there are always going to be people who try to push their own protocols, not caring to hear any feedback or input, and the process (for the most cherished IANA resources) should be strict enough to limit the damage those could inflict. Or maybe there is a need for a short document explaining that if you want to build FOO protocol, it might make good sense to design it using TCP/UDP and FCFS assignments, instead of using more scarce or more tightly controlled resources, especially if you have a tight market DL and/or don't want to engage in a technical dialogue in the IETF.. In the particular case of hop-by-hop options, maybe the best approach could be to assign a couple of experimental code points per RFC3692. If folks want to deploy (in small scale) or test their ideas, they could always use those codepoints, and everyone else could put code in their products to ignore them. -- Pekka Savola "You each name yourselves king, yet the Netcore Oykingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: S stands for Steering [Re: Should the IESG rule or not?]
Date:Fri, 01 Jul 2005 14:11:47 +0800 From:Scott W Brim Message-ID: <[EMAIL PROTECTED]> Scot, | Something like this must have a serious, long-term IETF review. | We need to take the overall design of the Internet into | account and not just be administrators. How do you propose we enforce that? In more common circumstances the way that happens is that the IETF refuses to publish a proposal, which is generally effective, as what most people (seem to) want is an RFC number that can use as a badge on their product. Here, no-one, as best I can tell, ever wanted an RFC number. There has been some opinion recently (from what I can tell, I certainly have not read all of the messages) that they really should want an RFC number. Nonsense. While the IETF makes standards for use on the internet, and with the internet protocols, nothing gives it the exclusive right to make such standards, or to invent internet protocols. Anyone can do that. W3C certainly does that. So can anyone else. When they do it, they don't automatically get an RFC number to bandy about, which many might see as a disadvantage, but if they don't need that, then they just go ahead. Whether anyone, and if there is anyone who they are that, uses the protocol that's been designed is the ultimate judge of it, not whether or not it has IETF blessing, or anyone else's blessing, or an RFC number. The other tool we (pretend to) have is to refuse to allocate numbers in the parameter registries, where a number is needed to make a protocol work. We can certainly do that. But what effect do you expect that will have? That is, what would you do, if you were denied a parameter registration for your protocol? Or, to make that query more specific, cisco designed (long ago) a routing protocol (igrp, now eigrp), which I assume needs a port number, or an IP protocol number, or a multicast address, or something like that. What do you think would have happened, had the IETF (or IANA) replied to a request for that parameter to be allcoated with a response like: "Sorry, routing protocols are fundamental to the operation of the network, we will not allocate a parameter for your protocol unless you have it reviewed in the IETF, and the community agrees that your protocol is a good one, What's more, we are already doing work defining routing protocols, we don't believe that yours has any chance of success, so please go away and don't come back." Really, what would have happened? Do you really believe that cisco would simply have dropped igrp and said "oh well, we lost" or something? I certainly don't, and I cannot think of any reason why they should have, nor why Dr Roberts' group should in this case. Allocating a number for yourself is trivial. If you can't get one assigned, then you self-assign. Anyone would. If you don't care about the RFC number badge, then denying a paramater registration is about as effective in actually preventing the protocol being used as being flogged with (wet) spagetti would be (probably less so)... Do you, or does anyone, really believe that we're better off with data on the network, whose purpose we don't understand, for which we have no idea what it is about, or how to find out more information about it, than not having such data? That's what the IANA registry is really all about - it is to make sure that information about what exists is available, and we can discover what is there, and manage to avoid conflicting with it. Attempting to use it as an enforcement tool is highly counter-productive. kre ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: S stands for Steering [Re: Should the IESG rule or not?]
Date:Fri, 1 Jul 2005 09:36:30 +0300 (EEST) From:Pekka Savola <[EMAIL PROTECTED]> Message-ID: <[EMAIL PROTECTED]> | though I can understand the arguments why | documenting the proposed use could be useful. I believe it is documented (though I haven't read the documentation and see no need to do that). What it isn't, is documented as an RFC (or even an I-D). Whether the documentation is adequate or not is a reasonable question to ask, and is the question the IESG should have investigated. | I'm hoping that most of the people who come | asking for these code points, but don't get one, will change their | designs (so a code point is not needed) or engage in a dialogue | (instead just picking a code point and getting it implemented). And why would you expect that to be the case? Some might be persuaded by arguments that show a better alternative, a very few might be persuaded by arguments that say "that's no good" without suggesting anything better, or at least demonstrating a problem (in the IETF we tend to tell people who make those kind of arguments to go away). Others? | I'd certainly hope that mainstream vendors wouldn't just add | unregistered/rejected codepoints in their products, Personally I'd expect that decision to be based upon how many $'s they expect implementing the option/feature to be able to make for them, compared to the costs of doing it. If you believe that vendors have never implemented features in advance of IETF approval, or even discussion, you're deluding yourself. (Just consider what happened to the IPv4 TOS byte, and how that was actually done). | and if the use is | restricted to a minor vendor or a very specific environment, I doubt | many care too much one way or the other. Here, I absolutely disagree. Features that start out being restricted to specific environments have a tendency to escape into wider uses. In this, I think I am in agreement with those who agree with the IESG's action, because they have looked at the protocol, don't like what they see, and are afraid of it (or perhaps something similar in the future) escaping into the network and doing harm. I certainly agree that is possible. Where we disagree, is that I cannot see (as apparently you can't either, though you "hope") that it is possible to prevent this by refusing parameter registrations. I prefer to know what is there, to be able to identify it, and to locate the identifying documentation or responsible person. Others seem to prefer to pretend that if it isn't registered in the IANA registry, then it cannot possibly exist (the ostrich syndrome). | If we want to enable any kind of protocol to get any kind of code | point (instead of just stealing one), I'd think it might make sense to | split a few codepoints from the registries to be allocated using a | more relaxed process No, that kind of thing has been tried in the past, and it simply does not work. The "experimental" code points, if they succeed, get embedded into products, and cease being experimental. And that happens before anyone realises, and well after the point where it would be practical to move to a different number. | No matter what we do, there are always going to be people who try to | push their own protocols, not caring to hear any feedback or input, | and the process (for the most cherished IANA resources) should be | strict enough to limit the damage those could inflict. Exactly. This is the point. Do we push them underground, or do we be honest with ourselves, recognise that this is going to happen, and at least allow it to happen in a way where the harm to the rest of us is minimised? We can't stop this, but we can at least observe it. | Or maybe there is a need for a short document explaining that if you | want to build FOO protocol, it might make good sense to design it | using TCP/UDP and FCFS assignments, instead of using more scarce or | more tightly controlled resources, especially if you have a tight | market DL and/or don't want to engage in a technical dialogue in the | IETF.. That may be true, but couldn't possibly help here. From what I have seen, the proponents of the protocol in question are convinced that the only way for it to work is by using hop by hop options. That is, they are expecting that everything above the IP layer is going to be (and must be) encrypted, and they need to send information that the routers along the path can examine. That they cannot do by embedding anything in UDP or TCP - then all of the data would be hidden from the routers. Or at least, that is my understanding (purely from the e-mail on this topic that I have read, not all of it public). [I have no idea what data they need the routers to see, or why.] | In the particular case of hop-by-hop options, maybe the best approach | could be to assign a couple of experimental code points per RFC3692.
Re: S stands for Steering [Re: Should the IESG rule or not?]
Apologies for missing the second 't' in your name in the message I sent to the list - I must have been asleep... kre ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: S stands for Steering [Re: Should the IESG rule or not?]
Scott W Brim wrote: On 07/01/2005 13:02 PM, Ken Carlberg allegedly wrote: My view is that your impression of the reaction is incorrect. in taking the position that respondents can be classified as either: a) being satisfied with the IESG *decision*, b) dissatisfied or uncomfortable with the decision, or c) could not be clearly determined by the content of their response, I came up with the following list. You can add me to the "satisfied" column. The IESG is asked to take positions and to lead (despite what a few think). That's risky -- no matter what they do they get criticism from somewhere. Maybe they didn't *phrase* the announcement perfectly, but the decision is correct. Something like this must have a serious, long-term IETF review. We need to take the overall design of the Internet into account and not just be administrators. Add me to the "satisfied" column as well. Much of the objection expressed on this list seems to have been not to the decision itself, but that the way the decision was expressed by the IESG appeared to preempt what the result of an IETF consensus process would be. My opinion on this is that: - the IESG is entitled to hold positions about the suitability of particular proposals, and to express those positions publically and forcefully. They should not be prevented or discouraged from doing so by politics. - if there are substantive objections to the grounds on which the IESG approved or did not approve a request in any particular case, that is what the appeals process is for. - expressing the position that Dr. Robert's proposal would be unlikely to reach IETF consensus *as part of the decision not to approve the request* was arguably unwise. Some people appear to want to use this case as a stepping-off point for a campaign to liberalise the policies for allocation of code points in all or most code spaces. This would effectively result in the prior decisions of working groups and others as to what level of review is required in any particular code space to be altered, without consulting those groups. The idea that in general, allocating code points based only on availability of documentation and not technical review must be harmless as long as extension/option mechanisms are designed correctly, is dangerously naive. As several posters have pointed out, the problem here is with extensions/ options that *are* implemented, not those that are ignored. A policy of (essentially) rubber-stamping code point allocations would, in practice, lead to more options with a marginal or poor usefulness/complexity trade-off, that would nevertheless have to be implemented to ensure interoperability. If the description of what IESG Approval should involve is unclear, then that option, and that option only, should be clarified in an update to RFC 2434. There are no grounds for any radical rethink of allocation policies in general. -- David Hopwood <[EMAIL PROTECTED]> ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: S stands for Steering [Re: Should the IESG rule or not?]
On Fri, Jul 01, 2005 at 01:02:29AM -0400, Ken Carlberg wrote: > My view is that your impression of the reaction is incorrect. in > taking the position that respondents can be classified as either: > a) being satisfied with the IESG *decision*, b) dissatisfied or > uncomfortable with the decision, or c) could not be clearly > determined by the content of their response, I came up with the > following list. You can add me into the "Satisified" column". Note that sampling messages posted to ietf@ietf.org on this list will almost certainly be biased, since it is the people who are disasstified which are likely going to be the ones complaining aobut it. - Ted ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: S stands for Steering [Re: Should the IESG rule or not?]
I agree that no noise usually means agreement, but once a counterpoint has been raised I don't know how to tell which side the silent people are agreeing with. I'm not saying I see all angles to this but it seems like Robert really has some strong logic behind him - If assigning the registration doesn't give anything that could have been taken without it then all we are ensuring by giving the assignment is documentation on record, an easy way to ignore the implementation (by reference of the assigned number), and an avoidance of future conflicts with options we might find of much more import. I don't see the benefit of flying blind only because I don't know how that helps us achieve the goal of preventing this implementation. If that could be explained then I would change my tune. Best regards, Nick Staff -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Theodore Ts'o Sent: Friday, July 01, 2005 7:52 AM To: Ken Carlberg Cc: ietf@ietf.org Subject: Re: S stands for Steering [Re: Should the IESG rule or not?] On Fri, Jul 01, 2005 at 01:02:29AM -0400, Ken Carlberg wrote: > My view is that your impression of the reaction is incorrect. in > taking the position that respondents can be classified as either: > a) being satisfied with the IESG *decision*, b) dissatisfied or > uncomfortable with the decision, or c) could not be clearly determined > by the content of their response, I came up with the following list. You can add me into the "Satisified" column". Note that sampling messages posted to ietf@ietf.org on this list will almost certainly be biased, since it is the people who are disasstified which are likely going to be the ones complaining aobut it. - Ted ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: S stands for Steering [Re: Should the IESG rule or not?]
Brian, Let me add three observations to Ken's rather interesting tabulation (without having read all of the traffic since then -- if someone else has said this, I apologize)... --On Friday, July 01, 2005 1:02 AM -0400 Ken Carlberg <[EMAIL PROTECTED]> wrote: From: Brian E Carpenter I'm supposed to be on vacation so this will be brief, but I don't think that your assertion about what "the community" has said is backed up by postings from a sufficient number of people to be a community view. Most people in the community haven't posted one way or the other. I haven't counted, but in the recent discussions about the hop by hop option, I've seen a number of messages agreeing with the IESG's decision, contrasted with a large number of critical postings from just a few people. My view is that your impression of the reaction is incorrect. in taking the position that respondents can be classified as either: a) being satisfied with the IESG *decision*, b) dissatisfied or uncomfortable with the decision, or c) could not be clearly determined by the content of their response, I came up with the following list. Dissatisfied Satisfied Other - - Robert Elz Thomas Narten Barbara Roseman John Leslie Sam HartmanYakov Rekhter Ken Carlberg Bob Hinden Scott Brim Ralph Droms Brian CarpenterSpencer Dawkins Steve Silverman Allison Mankin Thomas Hruska Jefsey MorfinHarald Alvestrand Randy Presuhn John Klensin Keith MooreScott Bradner Nick Staff Bill Sommerfeld Lawrence Roberts Eliot Lear Vint CerfJoel Halpern Dave Crocker Margaret Wasserman Ned FreedJeffrey Hutzelman Grenville Armitage Hans Kruse I listed names so that people could object to my interpretation, and I'm sure I made a mistake or two. But at best, it seems the reaction is split, and not to be viewed as objections coming from simply a few but persistant people. (i) Of the people in the left-hand column, there are at least a few who believe either that the proposed protocol is a dubious idea or even that the registration request should, in the last analysis, be rejected. Their objection is to the process the IESG followed, the assumptions about authority the IESG made in following it, and/or the way in which the IESG explained its decision. In that regard, there may be some overlap with some members of the "other" group: some of the "other" group might reasonable be classified with the "dissatisfied" or vice versa. Certainly few of the "others" are completely happy at this point. (ii) It is interesting to note that there are present or former ADs in all three groups, but that, of the 12 people in the "satisfied" group, fully half are current, or immediately past, ADs. By contrast, there are zero people in either of the other two lists who are now ADs or who have served as ADs since March 2003. One could probably interpret that factoid in several ways, but one cannot help but notice that, if one excluded IESG members defending either a recent IESG action or general IESG perceptions of its role from the second group, it would be the shortest of the three lists. (iii) By my rough and subjective count (I, too, am supposedly on vacation and hence suffering from impeded connectivity), the "few people" making a "large number of postings" are distributed among the first two groups, with neither group having a monopoly on that particular distinction. john ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: S stands for Steering [Re: Should the IESG rule or not?]
The list of "satisfied" is of ne real interest. The list of "disatistied" seem important enough to say there is no consensus. At 16:51 01/07/2005, Theodore Ts'o wrote: On Fri, Jul 01, 2005 at 01:02:29AM -0400, Ken Carlberg wrote: > My view is that your impression of the reaction is incorrect. in > taking the position that respondents can be classified as either: > a) being satisfied with the IESG *decision*, b) dissatisfied or > uncomfortable with the decision, or c) could not be clearly > determined by the content of their response, I came up with the > following list. You can add me into the "Satisified" column". Note that sampling messages posted to ietf@ietf.org on this list will almost certainly be biased, since it is the people who are disasstified which are likely going to be the ones complaining aobut it. - Ted ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: S stands for Steering [Re: Should the IESG rule or not?]
On Fri, Jul 01, 2005 at 11:07:47PM +0200, JFC (Jefsey) Morfin wrote: > The list of "satisfied" is of ne real interest. The list of "disatistied" > seem important enough to say there is no consensus. No IETF consensus is required to accept or deny a registration for the registry in question under the current rules; instead IESG approval is required instead. And if there is no consensus, then there is also no consensus to change RFC 2780, under which auspices the IESG acted - Ted ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: S stands for Steering [Re: Should the IESG rule or not?]
I agree with all of Joel's points, below, and add the following comments. The fundamental philosophical assumption made by draft-klensin-iana-reg-policy-00.txt goes too far is that registration of code points is always a good thing, and it is never bad thing to reserve a code point in the interests of interoperability and to avoid problems caused by code point collision. I disagree with this assumption; as Joel points out, "as much as we claim registration is not endorsement, it will frequently be seen as endorsement". The validity of this principle has been accepted by the IETF community and its general practice, when in RFC 2026 (BCP 9), section 4.2.3, we allow the suppression of experimental RFC's that are submitted with the intent to subvert the standards process, by diverting them to the relevant working group. Why do we allow this, despite our belief that just because it is an RFC does not give any text any special standing. While the IETF cognescenti may know this to be true, most people do not, and automatically give text with the "RFC" label force of a standard. (Given that most of us still refer to standards via their RFC number rather than by its STD or BCP number, we help perpetuate this problem, but that's a debate for another day.) Beyond the endorsement issue, it can be very valuable to be able to promote interoperability by trying to elimiate duplicate or near-duplicate code point registrations. If someone wants to register a different encoding scheme which is almost --- but not quite --- identical to base-64 encoding, instead of allowing the registration and permitting (and perhaps endorsing) this alternate encoding standard, it can be valuable if someone can explore with the registrant whether or not the code point is really needed, and whether there is a technical justification for having this alternate encoding scheme in the first place. In the past, my understanding is that the original IANA would perform such functions, and I think this is a good thing. Converting the IANA into something that can be implemented using an LDAP server may make the process more streamlined, but throwing out technical judgement to help improve some potentially bad ideas seem to be an vey, very unfortunate side-effect. I am also very troubled by the provision stating that no registration could be denied based on scarcity unless a potentially heavyweight process is initiated to either (a) eliminate the scarcity, or (b) justify that it cannot be so eliminated. Does this mean that every single time some kook^H^H^H^H^H, ah, "enthuastic experimenter" wants to register a new IP header version, or TOS value, or one of many, many bit-encoded, restricted fields in the lowest levels of our protocol stack, we need to create a working group to write an RFC justifying why expanding the IP version field in the IP header beyond 4 bits would be a Bad Thing? The argument could be made that "common sense" would not require such an effort, but the whole point of draft-klensin-iana-reg-policy-00.txt seems to be to eliminate any ambiguity by spelling out exactly what should happen, and the way it is currently worded, an implementation of this registration policy without the application of common sense could fairly easily result in a DOS attack against the IETF. - Ted On Fri, Jul 01, 2005 at 01:03:07AM -0400, Joel M. Halpern wrote: > As a general statement, I think this document goes too far. > Several issues occur to me reading it. A sampling follow. > > 1) As written, the document seems to say that all small allocation spaces > should be "repaired". This does not always follow. Making the IP version > space bigger does not seem a desirable approach to interoperability, for > example. > > 2) There are issues of appropriateness that are complex, and need to be > considered. For example, there is an ongoing debate in the routing area > as to how much information, and of what kinds, ought to be carried in the > routing protocols. (The problem exists for both BGP and our intra-domain > link state routing protocols.) It would really complicate such a > discussion if the working groups did not have the ability to say "no, there > are uses of these fields which are wrong, and we will not encourage them be > registering them." > > 3) No matter how much we claim that registration is not endorsement, it > will frequently be seen as endorsement. > > 4) Allowing arbitrary values in fields which need to be understood for > interoperability can make life very difficult. It turns out that even when > the protocol has planned well for unknown values, the negotiations and > exchanges can get very tricky. And the more extensive the set of options, > the harder it gets. > > 5) There are sometimes subtleties about who is appropriate to provide the > definitions for some values. Particularly if the meaning relates to > proprietary activities. Just
Re: S stands for Steering [Re: Should the IESG rule or not?]
At 01:43 02/07/2005, Theodore Ts'o wrote: On Fri, Jul 01, 2005 at 11:07:47PM +0200, JFC (Jefsey) Morfin wrote: > The list of "satisfied" is of ne real interest. The list of "disatistied" > seem important enough to say there is no consensus. No IETF consensus is required to accept or deny a registration for the registry in question under the current rules; instead IESG approval is required instead. Agreed. But the question is now "does IETF think IESG was right". There is no consensus. We should therefore stop arguing on HPH and get a more peacefull and general debate. I prefer the "we have a generic problem" approach to "you are dumb stupid to have (not) adopted that, because of RFC n1 to nx". ... And if there is no consensus, then there is also no consensus to change RFC 2780, under which auspices the IESG acted It seems it is a second problem which could be addressed after the general one. all the best. jfc ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: S stands for Steering [Re: Should the IESG rule or not?]
Robert Elz wrote: ... Also remember that "no consensus" in an issue like this, really needs to mean "no authority" - if you cannot get at least most of the community to agree with the IESG position, then the IESG cannot just claim the authority and say "there is no consensus that we should not have it". I don't believe that is true in this case, as long as RFC 2780 is in force. Especially since there is a clear path for Larry Roberts to ask for IETF consensus, which by definition would overrule the IESG. Brian ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: S stands for Steering [Re: Should the IESG rule or not?]
Thanks Ken (and those who have followed up). I don't think there's any need to repeat the count - we can safely say that opinions are divided. Brian Ken Carlberg wrote: From: Brian E Carpenter I'm supposed to be on vacation so this will be brief, but I don't think that your assertion about what "the community" has said is backed up by postings from a sufficient number of people to be a community view. Most people in the community haven't posted one way or the other. I haven't counted, but in the recent discussions about the hop by hop option, I've seen a number of messages agreeing with the IESG's decision, contrasted with a large number of critical postings from just a few people. My view is that your impression of the reaction is incorrect. in taking the position that respondents can be classified as either: a) being satisfied with the IESG *decision*, b) dissatisfied or uncomfortable with the decision, or c) could not be clearly determined by the content of their response, I came up with the following list. Dissatisfied Satisfied Other - - Robert Elz Thomas Narten Barbara Roseman John Leslie Sam HartmanYakov Rekhter Ken Carlberg Bob Hinden Scott Brim Ralph Droms Brian CarpenterSpencer Dawkins Steve Silverman Allison Mankin Thomas Hruska Jefsey MorfinHarald Alvestrand Randy Presuhn John Klensin Keith MooreScott Bradner Nick Staff Bill Sommerfeld Lawrence Roberts Eliot Lear Vint CerfJoel Halpern Dave Crocker Margaret Wasserman Ned FreedJeffrey Hutzelman Grenville Armitage Hans Kruse I listed names so that people could object to my interpretation, and I'm sure I made a mistake or two. But at best, it seems the reaction is split, and not to be viewed as objections coming from simply a few but persistant people. -ken ps, I hope your vacation is going well :) ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: S stands for Steering [Re: Should the IESG rule or not?]
On Jul 5, 2005, at 2:32, Brian E Carpenter wrote: Robert Elz wrote: ... Also remember that "no consensus" in an issue like this, really needs to mean "no authority" - if you cannot get at least most of the community to agree with the IESG position, then the IESG cannot just claim the authority and say "there is no consensus that we should not have it". I don't believe that is true in this case, as long as RFC 2780 is in force. Especially since there is a clear path for Larry Roberts to ask for IETF consensus, which by definition would overrule the IESG. Brian just for my edification, how is IETF consensus determined, esp. when there is a need to "overrule the IESG"? in other contexts, this type of thing is done by a vote of the membership, but last i checked, there are no members of the IETF. --bill ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: S stands for Steering [Re: Should the IESG rule or not?]
--On Tuesday, 05 July, 2005 08:47 -0700 Bill Manning <[EMAIL PROTECTED]> wrote: >> I don't believe that is true in this case, as long as RFC >> 2780 is in force. >> Especially since there is a clear path for Larry Roberts to >> ask for IETF consensus, which by definition would overrule >> the IESG. >> >> Brian >> >> > just for my edification, how is IETF consensus determined, > esp. when there is a need to "overrule the IESG"? in other > contexts, this type of thing is done by a vote of the > membership, > but last i checked, there are no members of the IETF. As far as I can tell, there are only two ways: (i) We ask the IESG if they think they have been overruled. In the nasty and impolite old days, the question was often stated at open plenaries, with at least the possibility of [real or virtual] over-ripe fruit moving through the air in the IESG's direction. Today, when a larger percentage of the community seems either inclined to suffer in silence or disinclined to speak up, the message from the community probably needs to be much more clear, and the consensus stronger, for the IESG to reach that conclusion. (ii) Someone appeals, essentially asking the IAB whether the IESG has been overruled. The problem with this path is that, in the last decade, the IAB has tended to be deferential to the IESG's determinations about community consensus. That determination is often hard to make, the various procedural documents appear to assign the job of making it to the IESG, and the IAB has tended to want to look at procedural issues on appeals and to not review the IESG's judgment calls. Perhaps, in both cases, that is how we want it. If it is not, perhaps this is the time to start making procedural changes. But, in either case, the difficulties implied by the above are the greatest part of what makes statements such as the last clause in the IESG's rejection of the Roberts registration request particularly troubling: if the IESG has already concluded the community consensus is sufficiently unlikely that they recommend against trying to obtain it, the amount of consensus, and ways of demonstrating it, that would be needed to get them to decide their conclusion was incorrect and they had been overruled may set an impossibly high barrier. john ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: S stands for Steering [Re: Should the IESG rule or not?]
John C Klensin wrote: --On Tuesday, 05 July, 2005 08:47 -0700 Bill Manning <[EMAIL PROTECTED]> wrote: I don't believe that is true in this case, as long as RFC 2780 is in force. Especially since there is a clear path for Larry Roberts to ask for IETF consensus, which by definition would overrule the IESG. Brian just for my edification, how is IETF consensus determined, esp. when there is a need to "overrule the IESG"? in other contexts, this type of thing is done by a vote of the membership, but last i checked, there are no members of the IETF. As far as I can tell, there are only two ways: Middle posting: I think John and Bill are missing the primary mechanism which is *trusting* the relevant AD to call the IETF consensus honestly, even if s/he doesn't agree with it. That shouldn't be hard to accept, since we extend the same trust to every WG Chair. If the AD makes the wrong call, then complaints, appeals and even recalls are available. Brian (i) We ask the IESG if they think they have been overruled. In the nasty and impolite old days, the question was often stated at open plenaries, with at least the possibility of [real or virtual] over-ripe fruit moving through the air in the IESG's direction. Today, when a larger percentage of the community seems either inclined to suffer in silence or disinclined to speak up, the message from the community probably needs to be much more clear, and the consensus stronger, for the IESG to reach that conclusion. (ii) Someone appeals, essentially asking the IAB whether the IESG has been overruled. The problem with this path is that, in the last decade, the IAB has tended to be deferential to the IESG's determinations about community consensus. That determination is often hard to make, the various procedural documents appear to assign the job of making it to the IESG, and the IAB has tended to want to look at procedural issues on appeals and to not review the IESG's judgment calls. Perhaps, in both cases, that is how we want it. If it is not, perhaps this is the time to start making procedural changes. But, in either case, the difficulties implied by the above are the greatest part of what makes statements such as the last clause in the IESG's rejection of the Roberts registration request particularly troubling: if the IESG has already concluded the community consensus is sufficiently unlikely that they recommend against trying to obtain it, the amount of consensus, and ways of demonstrating it, that would be needed to get them to decide their conclusion was incorrect and they had been overruled may set an impossibly high barrier. john ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: S stands for Steering [Re: Should the IESG rule or not?]
On Wed, Jul 06, 2005 at 05:24:40PM +0200, Brian E Carpenter wrote: > John C Klensin wrote: > > > >--On Tuesday, 05 July, 2005 08:47 -0700 Bill Manning > ><[EMAIL PROTECTED]> wrote: > > > > > >>>I don't believe that is true in this case, as long as RFC > >>>2780 is in force. > >>>Especially since there is a clear path for Larry Roberts to > >>>ask for IETF consensus, which by definition would overrule > >>>the IESG. > >>> > >>> Brian > >>> > >>> > >> > >>just for my edification, how is IETF consensus determined, > >>esp. when there is a need to "overrule the IESG"? in other > >>contexts, this type of thing is done by a vote of the > >>membership, > >>but last i checked, there are no members of the IETF. > > > > > >As far as I can tell, there are only two ways: > > Middle posting: I think John and Bill are missing the > primary mechanism which is *trusting* the relevant AD to > call the IETF consensus honestly, even if s/he doesn't > agree with it. That shouldn't be hard to accept, since > we extend the same trust to every WG Chair. > > If the AD makes the wrong call, then complaints, appeals and even > recalls are available. if John is correct, and your statements are correct, then IETF consensus kind of depends on IESG tacit approval... and why would the IESG approve something that would "second-guess" or "overrule" a choice they already made? Me thinks that we have a -VERY- high threshold to challange an IESG fiat. And this may be bad for the continued health/relevence of the IETF. Or not... development can and does occur in other fora. The IETF may not see the work until it is cooked. --bill > >Brian > > > > > (i) We ask the IESG if they think they have been > > overruled. In the nasty and impolite old days, the > > question was often stated at open plenaries, with at > > least the possibility of [real or virtual] over-ripe > > fruit moving through the air in the IESG's direction. > > Today, when a larger percentage of the community seems > > either inclined to suffer in silence or disinclined to > > speak up, the message from the community probably needs > > to be much more clear, and the consensus stronger, for > > the IESG to reach that conclusion. > > > > (ii) Someone appeals, essentially asking the IAB whether > > the IESG has been overruled. The problem with this path > > is that, in the last decade, the IAB has tended to be > > deferential to the IESG's determinations about community > > consensus. That determination is often hard to make, > > the various procedural documents appear to assign the > > job of making it to the IESG, and the IAB has tended to > > want to look at procedural issues on appeals and to not > > review the IESG's judgment calls. > > > >Perhaps, in both cases, that is how we want it. If it is not, > >perhaps this is the time to start making procedural changes. > >But, in either case, the difficulties implied by the above are > >the greatest part of what makes statements such as the last > >clause in the IESG's rejection of the Roberts registration > >request particularly troubling: if the IESG has already > >concluded the community consensus is sufficiently unlikely that > >they recommend against trying to obtain it, the amount of > >consensus, and ways of demonstrating it, that would be needed to > >get them to decide their conclusion was incorrect and they had > >been overruled may set an impossibly high barrier. > > > > john > > > > > > > > > > ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: S stands for Steering [Re: Should the IESG rule or not?]
Date:Tue, 05 Jul 2005 11:32:12 +0200 From:Brian E Carpenter <[EMAIL PROTECTED]> Message-ID: <[EMAIL PROTECTED]> | > Also remember that "no consensus" in an issue like this, really needs to | > mean "no authority" - if you cannot get at least most of the community to | > agree with the IESG position, then the IESG cannot just claim the | > authority and say "there is no consensus that we should not have it". | | I don't believe that is true in this case, as long as RFC 2780 is in force. | Especially since there is a clear path for Larry Roberts to ask for | IETF consensus, which by definition would overrule the IESG. 2780 has nothing to do with it. No-one is disputing what 2780 says. The question is what the words in 2434 (to which 2780 refers) actually mean. To me, and apparently to some others, it is clear that 2434 is all about what amount of documentation is required to get IANA to register an option, and who gets to judge that documentation. There's no suggestion in 2434 that anything else should be subject to scrutiny. Read the whole doc, not just the two sentences that directly apply in isolation. kre ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
