Re: call for ideas: tail-heavy IETF process
On 05/16/2013 01:44 AM, John C Klensin wrote: --On Thursday, May 16, 2013 00:55 -0400 Keith Moore mo...@network-heretics.com wrote: Which is to say, if there is only a single AD blocking a document, that block is essentially a 2 week affair if you are willing to push the point. No need for negotiating; if the WG decides that the AD is totally off base, tell your sponsoring AD that you're waiting the two weeks. People (unfortunately IMO) don't push the point nearly enough. I think it's very unfortunate that IESG has adopted rules that work this way. Part of IESG's job is to provide independent review of WG output. It that review can be circumvented merely by waiting two weeks, that's a bug in the process. And if an AD raises a DISCUSS about a matter of technical or document quality (or for that matter, about a process violation), and the WG isn't even willing to discuss the point, but instead relies on the two week timeout, I think that's grounds for appeal to the IAB. Keith, I generally agree with Pete although I share your low opinion of a lot of current IETF work, but your comment above seems to call for comment from someone, like myself, who has often been critical of the IESG. I don't think the current rules are ideal, but the effect of the ones that you and Pete cite isn't really that a WG can circumvent a review by waiting two weeks. First, the dissenting AD has those same two weeks to convince others on the IESG that his or her position is reasonable or at least needs more extensive consideration. If that is possible, then there is no longer a single AD objecting and the two week rule does not apply. If it is not possible, then there is either something wrong with the objection or the AD making it and probably it is reasonable for the process to move forward. I don't think I agree. I do agree that a single AD shouldn't be able to indefinitely delay a WG's output, and that you want IESG to be able resolve such issues internally in the vast majority of cases (because appeals to IAB are very time- and resource-consuming). But I don't think two weeks is long enough in general to get other ADs to thoroughly review a document. Two months would be much better. Now it might be the case that IESG members will help each other out, and collaborate to log multiple DISCUSS votes to give everybody more time to review a document. People of good will acting in good faith can usually find ways to work around buggy processes to make the right thing happen, at least in the most important cases. But it's not ideal, and it relies on ADs getting along with each other - which creates incentives for ADs to not do an adequate job of reviewing some documents, so that they'll be able to call in favors from other ADs when they need them. So overall I think the balloting process that IESG currently follows is seriously flawed. Conversely, a WG that decides to avoid actually engaging on an issue in the hope of letting the two-week clock run out is putting itself at considerable risk. The IESG still have the ability to fire WG leadership and even to close WGs. In theory, yes. But that hardly seems like a good tool for resolving issues in a single document, especially when the WG has other ongoing work that might turn out to be useful.Also, at least when I was on IESG all of us seemed to be aware that though we did have the authority and responsibility to push back on poor work, we also had to be mindful of the potential for the community to mutiny. Under any reasonable circumstances, I assume that the IESG would respond very strongly if an AD pointed out the a WG had ignored an effort to discuss a substantive issue even if the rest of the IESG disagreed with that particular AD about that issue. I'd hope so. But I also think that the process should work even for an objection raised by an AD who was unpopular with the rest of IESG. Of course I hope that ADs get along well with one another and work together to make a better Internet. But I also know from experience that some ADs tend to have more clout than others, and that the ones with the most clout aren't always the ones with the best technical judgment. Keith
Re: Gather Profiles/Resumes [was Re: call for ideas: tail-heavy IETF process]
On 05/15/2013 12:25 PM, Thomas Narten wrote: I don't think the IETF needs to be in the profile/resume business. There are plenty of other places that do a fine job already. What I do think the IETF should do is *require* that participants identify themselves. That means knowing who they are (a name and email contact) and an affiliation. I have mixed feelings about this. On one hand I would like to know who (if anyone) is paying someone to do IETF work, because there's always some potential for inappropriate bias even among people with a high degree of integrity - and of course not everyone has such integrity. On the other hand I don't think that a contributor's affiliation should mean anything at all when evaluating that contributor's input to IETF. If people treat contributors from major companies as having more weight than other contributors, it makes a joke out of the whole notion of consensus-based decision making. (And we all know that people do this sometimes.) I also don't think that anyone should automatically presume that a contributor's input is representing his employer's interests. On balance, I do sometimes find it helpful when IETF contributors disclose their employers. But I don't think it should be required. And if everybody stopped disclosing their employers in the context of IETF conversations, it might be a good thing. Keith
Re: article on innovation and open standards
Without wishing to be nasty, I will point out that we have way more vendors than operators participating in our standards development. Into the Future with the Internet Vendor Task Force A very Curmudgeonly View or Testing Spaghetti - a Wall's Point of View as published in ACM SIGCOMM Computer Communication Review Volume 35, Number 5, October 2005 http://archive.psg.com/051000.ccr-ivtf.html
Re: call for ideas: tail-heavy IETF process
I must say that I have enjoyed reading the discussion between the three of you, and think it is immensely valuable in explaining what the IESG ought to be doing. You three should write it up.
Re: Is this an elephant? [Was: call for ideas: tail-heavy IETF process]
On May 15, 2013, at 4:30 PM, Adrian Farrel adrian at olddog.co.uk wrote: The claim (or one of the claims) is that some ADs may place Discusses that are intended to raise a discussion with the authors/WG that could equally have been raised with a Comment or through direct email. This, it is claimed, may unnecessarily delay the document from completing the publication process. Discussions should have a time limit (can be one week), like we have in meetings (2hours), if there is time we can know when things are needed to respond to, I usually ignore when there is no milestones or planing-time. Does IESG have milestones for documents processing/discussions? Now the dangerous bit, Suppose the AD raised her concern by writing a Comment or sending an email and balloting No Objection. That would mean that the I-D would be approved for publication. At this point either: - the discussion goes on, but the document becomes an RFC anyway or - the responsible AD holds the document pending satisfactory completion of the discussion. That AD SHOULD not hold for unlimited time, also should discuss the issue with the WG related in limited time. I suggest that the former is a bad result. Not that the authors/WG will ignore the discussion, but if they disagree on something the AD considers very important, the authors/WG have no incentive to participate in the discussion. Only community rough concensus will decide the final result, Of course, all participants in this thread so far would never behave like that, but there is a possibility that this will happen for some authors. Yes only if there is no time limits for work that should be done, I also suggest that the latter introduces exactly the same amount of delay as the Discuss. There is always possibility of large delay in systems that have no time limits for processing or responds. Our time/work used is important for IETF, IMO, no one should hold work/time only if able to decide/notify/plan when/how to leave it go for all reaction possibilities. AB
Re: Is this an elephant? [Was: call for ideas: tail-heavy IETF process]
On 2013-05-16 14:38, Abdussalam Baryun wrote: Discussions should have a time limit (can be one week), I totally disagree, DISCUSSES are our friends, they need to be discussed until we have rough consensus; it seems to be a manifestly bad idea to draw a deadline after seven days, if someone come up with a satisfactory solution on the eighth. 99,9% of the DISCUSSES improve our documents or the understanding of them. /Loa like we have in meetings (2hours), if there is time we can know when things are needed to respond to, I usually ignore when there is no milestones or planing-time. Does IESG have milestones for documents processing/discussions? -- Loa Anderssonemail: l...@mail01.huawei.com Senior MPLS Expert l...@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64
Re: Is this an elephant? [Was: call for ideas: tail-heavy IETF process]
Please distinguish between (1) making the system efficient and (2) making individual documents go through it quickly. If you put time limits on parts of the process, you're not allowing them to function correctly. Putting arbitrary time limits on will hurry things up but it will not produce higher quality results.
Re: Is this an elephant? [Was: call for ideas: tail-heavy IETF process]
Hi Loa, I agree with you discussions are our friend. I was focusing on processing time, not document quality. No dought if you stay longer time you will get better quality, but what about progress. So I mean call for discussions is for a time limit, as if no discussion happends then the call matures and the holding of the work stops as well. If DISCUSS is continue I never like to close it as long as it is continuous, but not delayed. In practice I never seen that DISCUSS of ADs with the WGs are having much continuous communication, it is delay with no time schedule. 99,9% of the DISCUSSES improve our documents or the understanding of them. I know that DISCUSSES with WGs improves our documents (don't forget that WGs are following milestones and WGLC periods), but DISCUSSES that have no time limit makes more delays. I hope we see similar times of WG into the IESG, so the communication can improve the processing time. AB On 5/16/13, Loa Andersson l...@pi.nu wrote: On 2013-05-16 14:38, Abdussalam Baryun wrote: Discussions should have a time limit (can be one week), I totally disagree, DISCUSSES are our friends, they need to be discussed until we have rough consensus; it seems to be a manifestly bad idea to draw a deadline after seven days, if someone come up with a satisfactory solution on the eighth. 99,9% of the DISCUSSES improve our documents or the understanding of them. /Loa like we have in meetings (2hours), if there is time we can know when things are needed to respond to, I usually ignore when there is no milestones or planing-time. Does IESG have milestones for documents processing/discussions? -- Loa Anderssonemail: l...@mail01.huawei.com Senior MPLS Expert l...@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64
Re: Is this an elephant? [Was: call for ideas: tail-heavy IETF process]
On 5/16/13, Scott Brim scott.b...@gmail.com wrote: Please distinguish between (1) making the system efficient and (2) making individual documents go through it quickly. If you put time limits on parts of the process, you're not allowing them to function correctly. Putting arbitrary time limits on will hurry things up but it will not produce higher quality results. Ok, so do you agree, that if who holds the work, at least should tell us HOW long he is holding or what is the time PLAN. Do you think working without plan is efficient and gives good quality. AB
Re: Is this an elephant? [Was: call for ideas: tail-heavy IETF process]
Putting arbitrary time limits on will hurry things up but it will not produce higher quality results. Ok, so do you agree, that if who holds the work, at least should tell us HOW long he is holding or what is the time PLAN. Do you think working without plan is efficient and gives good quality. We generally rely on judgment in this regard, not on time limits and deadlines. We do sometimes set deadlines (milestones in charters, timeouts on last calls, fixed telechat dates, alerts when things take too long), but we also give leeway (we know how solid charter milestones aren't, and no one will ignore important, useful input just because it came in after last call). Someone is always responsible for determining when a discussion is no longer productive (shepherds, chairs, responsible ADs), and someone is responsible for moving things forward. Reminders to those who are responsible, telling them that things seem to be dragging, are fine. Strict time limits are generally not how we prefer to work. Barry
Re: Gather Profiles/Resumes [was Re: call for ideas: tail-heavy IETF process]
From: Thomas Narten nar...@us.ibm.com What I do think the IETF should do is *require* that participants identify themselves. That means knowing who they are (a name and email contact) and an affiliation. For 80% of the participants, this info is not very hard to figure out (see below). But we also have participants that use obscure email handles that don't correlate to anything obvious, whether a real person or to a name in the list of registered attendees, etc. I suspect these folk are *not* intenending to be anonymous participants, but in practice they are. And yes, knowing who someone is, their background and who they work for is important to me in figuring out how to guage their input. E.g., I would likely pay more attention to an operator's comments on a proposed use case than from someone else. I believe that this is a less good idea than first appears. One objection is that the concept of affiliation is less simple than it appears. People normally expect it to mean Who is your employer? As John mentions, it can mean What is the organization whose interests you are promoting? But in regard to your observation about use cases, it can also mean What area of technology do you have experience in? In many cases, affiliation is related to Who is paying for your attendance? But there are situations where your employer may be willing to pay for your attendance but doesn't want you to be seen as officially representing them. And (at least in common-law countries) one can simply invent an (unincorporated!) company name and claim it as your affiliation. In practice, the way we deal with these problems is that we consider everyone to be individuals, rather than as the representative of company XYZ, and it takes time to build a reputation. One is thus unwilling to sacrifice that expensive reputation to advocate a poor solution because one's employer favors it. 3) Google names, look at authorship info in RFCs, linked in, etc. Works in a lot of cases, but is sometimes more work than seems appropriate. If you can't find any information about them, they have no reputation. Dale
Re: Is this an elephant? [Was: call for ideas: tail-heavy IETF process]
On 5/15/2013 1:30 PM, Adrian Farrel wrote: Suppose the AD raised her concern by writing a Comment or sending an email and balloting No Objection. That would mean that the I-D would be approved for publication. At this point either: - the discussion goes on, but the document becomes an RFC anyway or - the responsible AD holds the document pending satisfactory completion of the discussion. I suggest that the former is a bad result. Personally (but this may reflect my Discusses) I find that an active engagement by the authors and the Discussing AD on the issue and the potential resolution, always leads to speedy progression of the document either with the AD feeling stupid, or the document improved. Both are adequate results. Adrian, I suggest we all take a look at the original text of the Subject field. The problem here is that basic reviewing is being done by the ADs too late in the process. We are making the mistake of having ADs be exempt from IETF Last Call, and allowing them to be unprepared for the IESG vote. So we are combining education with voting. That's a paradigm error. By the time the IESG schedules the vote, ADs need to already have educated themselves about the document. Of course, the IESG discussion during the voting process well might uncover an actual, serious issue with the document; this should be exceptional and it should be an issue that the /IESG/ agrees needs to be resolved and it means that voting should not take place until it is. But that is quite different from the usual let's talk about it kind of Discuss imposed by individual ADs. So here's a simple proposal that pays attention to AD workload and includes a simple efficiency hack: When the IETF Last Call is issued, wait a few days, to see whether any serious issues are raised by the community. The really serious ones usually are raised quickly. If there are none, it's pretty certain the document will advance to an IESG vote. That leaves 7-10 days of IETF Last Call for ADs to get educated and ask questions, just like everyone else. Jari has expressed the goal of having AD concerns be raised more publicly. Moving AD review and comment to the IETF Last Call venue nicely accomplishes this, too. On 5/15/2013 8:55 AM, Thomas Narten wrote: 1) Discuss criteria should be principles, not rigid rules. The details of the issue at hand always matter, and it will sometimes come down to judgement calls where reasonable individuals just might disagree. We've been doing protocol specification for 40 years. If we can't codify the major concerns that warrant blocking advancement of a protocol, we're just being lazy. Really. That a given situation might cause the IESG to decide to enhance the list does not mean that the list shouldn't seek to be complete and precise and that ADs be held to it. At every turn, the approach we've taken to the IESG review and approval process is to limit actual accountability to the community. Everyone is well-intentioned, but really this makes the process a matter of personalities and not the rigor of serious professionalism. The IESG's process is far, far better than it was 10-15 years ago, but it still lacks meaningful predictability and serious accountability; it is not reasonable for the process to require that authors and chairs take the initiative of complaining when an AD is being problematic. In terms of quality assurance, the idea that we have a process that relies on the sudden insight of a single AD, at the end of a many-month process, is broken. It's fine if that person sees something that everyone else has missed until then, but that is quite different from designing a process that is claimed to rely on it. And of course, the reality is that we allow bad specs out the door all the time; we just allow fewer of them than many/most other standards bodies... d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net
RE: Is this an elephant? [Was: call for ideas: tail-heavy IETF process]
That's a good question Dave. The community might like to comment. On the whole, I am told that if an AD weighs in with her comments during working group last call, her fearsome personality may overwhelm some of the WG participants and she may dominate the WG consensus. Is it possible that the same would happen in IETF last call? I know, of course, that a number of you have a robust ability to defend your opinions, but how would you (the community, not Dave) feel if ADs (speaking as ADs, not speaking as individual contributors) made their review comments during IETF last call? I agree that this would bring the tail forward a little (not a lot). I don't believe it would reduce AD work-load (which is another issue entirely). I have mixed feelings about whether it would change the processing time for a draft. That might depend on how the review is handled in IETF last call. Lastly, I think I disagree with you about really serious IETF last call comments coming in the first few days. It seems to me that we also get an number of late comments of substance resulting from people who are not familiar with the document reviewing it (such as directorate reviews and people who didn't notice the I-D sneaking through). Still thinking, Adrian -Original Message- From: Dave Crocker [mailto:d...@dcrocker.net] Sent: 16 May 2013 17:23 To: adr...@olddog.co.uk Cc: ietf@ietf.org Subject: Re: Is this an elephant? [Was: call for ideas: tail-heavy IETF process] On 5/15/2013 1:30 PM, Adrian Farrel wrote: Suppose the AD raised her concern by writing a Comment or sending an email and balloting No Objection. That would mean that the I-D would be approved for publication. At this point either: - the discussion goes on, but the document becomes an RFC anyway or - the responsible AD holds the document pending satisfactory completion of the discussion. I suggest that the former is a bad result. Personally (but this may reflect my Discusses) I find that an active engagement by the authors and the Discussing AD on the issue and the potential resolution, always leads to speedy progression of the document either with the AD feeling stupid, or the document improved. Both are adequate results. Adrian, I suggest we all take a look at the original text of the Subject field. The problem here is that basic reviewing is being done by the ADs too late in the process. We are making the mistake of having ADs be exempt from IETF Last Call, and allowing them to be unprepared for the IESG vote. So we are combining education with voting. That's a paradigm error. By the time the IESG schedules the vote, ADs need to already have educated themselves about the document. Of course, the IESG discussion during the voting process well might uncover an actual, serious issue with the document; this should be exceptional and it should be an issue that the /IESG/ agrees needs to be resolved and it means that voting should not take place until it is. But that is quite different from the usual let's talk about it kind of Discuss imposed by individual ADs. So here's a simple proposal that pays attention to AD workload and includes a simple efficiency hack: When the IETF Last Call is issued, wait a few days, to see whether any serious issues are raised by the community. The really serious ones usually are raised quickly. If there are none, it's pretty certain the document will advance to an IESG vote. That leaves 7-10 days of IETF Last Call for ADs to get educated and ask questions, just like everyone else. Jari has expressed the goal of having AD concerns be raised more publicly. Moving AD review and comment to the IETF Last Call venue nicely accomplishes this, too. On 5/15/2013 8:55 AM, Thomas Narten wrote: 1) Discuss criteria should be principles, not rigid rules. The details of the issue at hand always matter, and it will sometimes come down to judgement calls where reasonable individuals just might disagree. We've been doing protocol specification for 40 years. If we can't codify the major concerns that warrant blocking advancement of a protocol, we're just being lazy. Really. That a given situation might cause the IESG to decide to enhance the list does not mean that the list shouldn't seek to be complete and precise and that ADs be held to it. At every turn, the approach we've taken to the IESG review and approval process is to limit actual accountability to the community. Everyone is well-intentioned, but really this makes the process a matter of personalities and not the rigor of serious professionalism. The IESG's process is far, far better than it was 10-15 years ago, but it still lacks meaningful predictability and serious accountability; it is not reasonable for the process to require that authors and chairs take the initiative of complaining when an AD is being problematic. In terms of quality
Re: Is this an elephant? [Was: call for ideas: tail-heavy IETF process]
On 5/16/2013 9:40 AM, Adrian Farrel wrote: That's a good question Dave. The community might like to comment. On the whole, I am told that if an AD weighs in with her comments during working group last call, her fearsome personality may overwhelm some of the WG participants and she may dominate the WG consensus. Only women ADs? [1] But seriously... Is it possible that the same would happen in IETF last call? I think that the public sway of ADs on the IETF list is less of a risk than on wg mailing lists. And note that my suggestion has ADs waiting to weigh in until community-generated active disagreement with the spec, or its passive agreement, has been established. In any event, the current reality of having an AD weigh in with a a process-blocking Discuss is not exactly /under-/whelming... Simply put: We are starting with the reality that an AD is going to be expressing their opinions. The question is when and how. It's not going to be /less/ intimidating to have it done as a Discuss. Contrary to some of the mythology that has been expressed about this, the frequent reality is that the typical wg goal is to clear the Discuss, not really to engage in debate with an AD who is blocking document progress. (I've watched this reality many times over the years.) That is far less healthy than having the AD's concern become part of the /public/ review process. I agree that this would bring the tail forward a little (not a lot). I don't believe it would reduce AD work-load (which is another issue entirely). Yes, the timing change is small. But the context change is enormous. Lastly, I think I disagree with you about really serious IETF last call comments coming in the first few days. It seems to me that we also get an number Some, sure. But I said it was an efficiency hack. The goal isn't for it to be perfect, just helpful. d/ [1] The question of proper referential language is a continuing surprise to me, given that the currently-popular conventions create more problems than they solve -- and it's even a question on a PSAT preparatory example that I saw yesterday. There's a pretty straightforward alternative that works nearly all the time: http://dcrocker.net/#gender -- Dave Crocker Brandenburg InternetWorking bbiw.net
Re: Is this an elephant? [Was: call for ideas: tail-heavy IETF process]
On May 16, 2013, at 1:01 PM, Dave Crocker d...@dcrocker.net wrote: http://dcrocker.net/#gender That's what I do. It gets a bit awkward with verb agreement and constructs like themself, which elicits the dreaded red snake underline of doom. But I find it more comfortable than just subverting the sexist paradigm with a differently sexist paradigm.
Re: Is this an elephant? [Was: call for ideas: tail-heavy IETF process]
Dave Crocker wrote: And of course, the reality is that we allow bad specs out the door all the time; we just allow fewer of them than many/most other standards bodies... But different to (at least some) other standards bodies, we lack an official means to publish defect reports (aka errata) to document defects in a _timely_(!!) fashion. (Timely = can be found where the RFC says that it can be found, and within at most a few weeks after the defect/omission has been found by an implementor). In theory, we have the errata process, and recent RFC even include a direct URL pointer to the RFC-Editors errata page on the title page: Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc. ( containing the real number of the RFC on which this appears). However, the Errata process is currently working poorly, primarily because a number of folks (including some IETF leadership) currently thinks that posting something a trivial as a missing vital one-line clarification to a published RFC as a substantial change that can only be performed by publishing a whole new RFC. -Martin
Re: Is this an elephant? [Was: call for ideas: tail-heavy IETF process]
On Thursday, May 16, 2013, Dave Crocker wrote: By the time the IESG schedules the vote, ADs need to already have educated themselves about the document. Oh, so you're suggesting adding another phase to the process: IESG education. OK. So here's a simple proposal that pays attention to AD workload and includes a simple efficiency hack: When the IETF Last Call is issued, wait a few days, to see whether any serious issues are raised by the community. The really serious ones usually are raised quickly. If there are none, it's pretty certain the document will advance to an IESG vote. That leaves 7-10 days of IETF Last Call for ADs to get educated and ask questions, just like everyone else. Placing a time limit on some phase of the process doesn't produce quality. The process should take as long as it must in order to produce a good outcome. The question shouldn't be how long the process takes (that's just a cheap shortcut), it should be how to make it more efficient in doing well. I have an idea: let's place a time limit on working groups: they need to finish drafts in six weeks or there will be penalties. Why not? Scott
Re: Is this an elephant? [Was: call for ideas: tail-heavy IETF process]
On 5/16/13 10:01 AM, Dave Crocker wrote: On 5/16/2013 9:40 AM, Adrian Farrel wrote: That's a good question Dave. The community might like to comment. On the whole, I am told that if an AD weighs in with her comments during working group last call, her fearsome personality may overwhelm some of the WG participants and she may dominate the WG consensus. Only women ADs? [1] But seriously... If Tiresias prophet of Thebes is in your wg, I'd listen. Is it possible that the same would happen in IETF last call? I think that the public sway of ADs on the IETF list is less of a risk than on wg mailing lists. And note that my suggestion has ADs waiting to weigh in until community-generated active disagreement with the spec, or its passive agreement, has been established. Early participation AD's weighing in on draft's generally takes the form of just another participant unless you're asking for an opinion on a process point. wearing different hats on the course of the lifecycle is normal imho. opinion at the mic or on the list is not iesg review. The sponsoring AD (who is presumably the most involved) is not likely the one with the discuss later in the process since they had to do the initial review, put it through the ietf last call and then ballot it, so fundamentally they should have a document they can live with when it gets to that stage. In any event, the current reality of having an AD weigh in with a a process-blocking Discuss is not exactly /under-/whelming... Simply put: We are starting with the reality that an AD is going to be expressing their opinions. The question is when and how. It's not going to be /less/ intimidating to have it done as a Discuss. Contrary to some of the mythology that has been expressed about this, the frequent reality is that the typical wg goal is to clear the Discuss, not really to engage in debate with an AD who is blocking document progress. (I've watched this reality many times over the years.) That is far less healthy than having the AD's concern become part of the /public/ review process. I agree that this would bring the tail forward a little (not a lot). I don't believe it would reduce AD work-load (which is another issue entirely). Yes, the timing change is small. But the context change is enormous. Lastly, I think I disagree with you about really serious IETF last call comments coming in the first few days. It seems to me that we also get an number Some, sure. But I said it was an efficiency hack. The goal isn't for it to be perfect, just helpful. d/ [1] The question of proper referential language is a continuing surprise to me, given that the currently-popular conventions create more problems than they solve -- and it's even a question on a PSAT preparatory example that I saw yesterday. There's a pretty straightforward alternative that works nearly all the time: http://dcrocker.net/#gender
Re: Is this an elephant? [Was: call for ideas: tail-heavy IETF process]
On May 16, 2013, at 9:08 PM, Scott Brim scott.b...@gmail.commailto:scott.b...@gmail.com wrote: On Thursday, May 16, 2013, Dave Crocker wrote: By the time the IESG schedules the vote, ADs need to already have educated themselves about the document. Oh, so you're suggesting adding another phase to the process: IESG education. OK. I don't speak for Dave, but it makes sense that when a document reaches the IESG telechat, the questions to be asked are (1) Did this get sufficient review by sufficiently capable people, and (2) Has the process been followed, including have all issues been addressed. The time for asking whether the group has considered making this field fixed length instead of variable, or whether RFC 2119 language is used in an appropriate way, or whether the protocol is extensible enough is at IETF last call. This is true of any participants, and ADs can do this too, regardless of whether their presence might intimidate the crowd. It could even be that if ADs voice their concerns at that time, others might join in, making the LC time more useful and less about just waiting two or four weeks. There is a problem, though, that this will increase the load on ADs. Other concerns raised during IETF LC may lead to revised I-Ds, which the ADs will need to re-read (or at least look at the diff). I don't know how significant this extra work would be, but it would come at a time that we're thinking of ways to reduce AD workload. It might also require prolonging the LC time, because there would be actual discussion in it. Yoav
Re: Is this an elephant? [Was: call for ideas: tail-heavy IETF process]
I think Dave's idea is worth looking at, but have one comment: On 05/16/2013 09:46 PM, Yoav Nir wrote: There is a problem, though, that this will increase the load on ADs. There is that. But don't forget that ADs mostly read everything in IESG review and often comment. Even leaving aside DISCUSSes, if every IETF LC draft got a bunch of AD review comments, then the IETF LC would be much busier than now. And its in the nature of IETFers to chime in. So this would I suspect increase everyone's load, if it works, and not just ADs. Still worth a look though. S.
APPSDIR review of draft-housley-rfc2050bis-01
Hi, I have been selected as the Applications Area Directorate reviewer for this draft (for background on appsdir, please see http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate ). Please resolve these comments along with any other Last Call comments you may receive. Please wait for direction from your document shepherd or AD before posting a new version of the draft. Document: draft-housley-rfc2050bis-01 Title: The Internet Numbers Registry System Reviewer: Tobias Gondrom Review Date: May-16 Status: Informational Summary: I believe the draft is ready for publication. Review: 0. The document is well written and I very much like that the document is short and concise. Comments: 1. One of two key sentences I took from the document is that its self-described scope is only documenting the status quo. See Section 1: does not propose any changes, but it does provide information about the current... system. When reading this, one question the reader might consider is whether to agree with this scope-self-limitation. For my review, I followed this set scope, so the question is then only does the ID reflect reality and provide sufficient information. My answer to that is yes. 2. And the second key sentence is from section 5: ... specified in the IETF/IAB/ICANN MOU [RFC2860], discussions regarding the evolution of the Internet Numbers Registry System structure, policy, and processes are to take place within the ICANN framework and will respect ICANN's core values [ICANNBL]. So basically fully delegating that responsibility to ICANN. Personally IMHO, I would like to encourage the editors and the IETF to actually take a more strategic and pro-active approach and consider also whether any guided changes beyond status quo could improve the situation. Are our assumptions for the current system still true? Can we reflect about why certain aspects are as they are and whether we can learn from the past about any improvements we should actively explore or consider? A pro-active review of the overall situation including #1 and #2 might be useful? Best regards, Tobias
Re: Is this an elephant? [Was: call for ideas: tail-heavy IETF process]
On May 16, 2013, at 9:40 AM, Adrian Farrel adr...@olddog.co.uk wrote: On the whole, I am told that if an AD weighs in with her comments during working group last call, her fearsome personality may overwhelm some of the WG participants and she may dominate the WG consensus. There may be places where that happens, but I would be surprised if it happened in my working group. I think it is fair to say that the AD (or an IAB member, or someone who has recognized expertise on the topic) is likely to be listened to more carefully than some others might. Heck, I'm careful when I make a technical comment on a document in my working group, flagging it with /chair to ensure that it is seen as intended - a comment by a competent practitioner of the art, not a process remark or an attempt to trump some other view. Speaking personally, I would prefer to see those comments in the WGLC, not IETF Last Call, if we can make that happen. For example, I'd like to get directorate reviews done (gen-art, security directorate, etc) in the timeframe of WGLC.
Re: Is this an elephant? [Was: call for ideas: tail-heavy IETF process]
Dave, On 17/05/2013 04:23, Dave Crocker wrote: ... The problem here is that basic reviewing is being done by the ADs too late in the process. You are making a lot of assumptions in that sentence. At least these: 1. Basic reviewing means 2. At some stage before approval, ADs should perform basic reviewing. 3. Doing basic reviewing after the document has completed IETF LC is too late. Now, if basic reviewing means (A) looking for fundamental flaws that is one thing. If it means (B) getting a general understanding of the topic it's another. I'm really not sure which you mean. We are making the mistake of having ADs be exempt from IETF Last Call, and allowing them to be unprepared for the IESG vote. So we are combining education with voting. That's a paradigm error. By the time the IESG schedules the vote, ADs need to already have educated themselves about the document. Ah, maybe you mean basic (B). Well, I think this is a totally unrealistic expectation. There are too many drafts on too diverse a range of subjects for ADs to educate themselves at the time of IETF LC, which may be weeks or months before a draft hits the agenda. (I'm not talking about the sponsoring AD or her co-AD, of course: they are presumed to be aware of what's going on in their area.) Busy people are deadline driven, and the IESG agenda is an imminent deadline for ADs in a way that an IETF LC in another Area isn't. Of course, the IESG discussion during the voting process well might uncover an actual, serious issue with the document; And that's basic (B). I think we all agree that it's unfortunate if a basic flaw shows up during the IESG ballot phase, but please don't blame the IESG for that. Blame the WG and the IETF as a whole for failing to pick it up during WG LC and IETF LC. Thank the IESG for finding it. this should be exceptional and it should be an issue that the /IESG/ agrees needs to be resolved and it means that voting should not take place until it is. But that is quite different from the usual let's talk about it kind of Discuss imposed by individual ADs. I'm not quite sure what you're saying here, but I think you're saying that the majority of clarity and cross-area issues should be picked up earlier. I couldn't agree more, but don't expect the over-worked IESG to fix that. The rest of us need to fix that. So here's a simple proposal that pays attention to AD workload and includes a simple efficiency hack: When the IETF Last Call is issued, wait a few days, to see whether any serious issues are raised by the community. The really serious ones usually are raised quickly. If there are none, it's pretty certain the document will advance to an IESG vote. That leaves 7-10 days of IETF Last Call for ADs to get educated and ask questions, just like everyone else. Which, as I said above, is a totally unrealistic expectation. Jari has expressed the goal of having AD concerns be raised more publicly. Moving AD review and comment to the IETF Last Call venue nicely accomplishes this, too. Thanks but no thanks. My mail is full enough with discussion of drafts I will never read as it is. AD reviews should certainly go to the WG list unless they are only nits, but isn't that what everybody does anyway? On 5/15/2013 8:55 AM, Thomas Narten wrote: 1) Discuss criteria should be principles, not rigid rules. The details of the issue at hand always matter, and it will sometimes come down to judgement calls where reasonable individuals just might disagree. We've been doing protocol specification for 40 years. If we can't codify the major concerns that warrant blocking advancement of a protocol, we're just being lazy. Really. That a given situation might cause the IESG to decide to enhance the list does not mean that the list shouldn't seek to be complete and precise and that ADs be held to it. I agree with Thomas. We need to be able to apply common sense. Rules and targets are the enemy of common sense. At every turn, the approach we've taken to the IESG review and approval process is to limit actual accountability to the community. Everyone is well-intentioned, but really this makes the process a matter of personalities and not the rigor of serious professionalism. The IESG's process is far, far better than it was 10-15 years ago, but it still lacks meaningful predictability and serious accountability; it I find that the tracker in its present state has substantially improved both visibility and predictability. is not reasonable for the process to require that authors and chairs take the initiative of complaining when an AD is being problematic. Huh? Who else will complain? In terms of quality assurance, the idea that we have a process that relies on the sudden insight of a single AD, at the end of a many-month process, is broken. It's fine if that person sees something that everyone else has missed until then, but that is quite
Re: APPSDIR review of draft-housley-rfc2050bis-01
Tobias: Thanks for the review. Really, the delegation id to the RIRs. which in turn use the ICANN ASO to establish global policy. Thanks again, Russ On May 16, 2013, at 4:56 PM, Tobias Gondrom wrote: Hi, I have been selected as the Applications Area Directorate reviewer for this draft (for background on appsdir, please see http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate ). Please resolve these comments along with any other Last Call comments you may receive. Please wait for direction from your document shepherd or AD before posting a new version of the draft. Document: draft-housley-rfc2050bis-01 Title: The Internet Numbers Registry System Reviewer: Tobias Gondrom Review Date: May-16 Status: Informational Summary: I believe the draft is ready for publication. Review: 0. The document is well written and I very much like that the document is short and concise. Comments: 1. One of two key sentences I took from the document is that its self-described scope is only documenting the status quo. See Section 1: does not propose any changes, but it does provide information about the current... system. When reading this, one question the reader might consider is whether to agree with this scope-self-limitation. For my review, I followed this set scope, so the question is then only does the ID reflect reality and provide sufficient information. My answer to that is yes. 2. And the second key sentence is from section 5: ... specified in the IETF/IAB/ICANN MOU [RFC2860], discussions regarding the evolution of the Internet Numbers Registry System structure, policy, and processes are to take place within the ICANN framework and will respect ICANN's core values [ICANNBL]. So basically fully delegating that responsibility to ICANN. Personally IMHO, I would like to encourage the editors and the IETF to actually take a more strategic and pro-active approach and consider also whether any guided changes beyond status quo could improve the situation. Are our assumptions for the current system still true? Can we reflect about why certain aspects are as they are and whether we can learn from the past about any improvements we should actively explore or consider? A pro-active review of the overall situation including #1 and #2 might be useful? Best regards, Tobias
Re: Is this an elephant? [Was: call for ideas: tail-heavy IETF process]
On May 16, 2013, at 5:00 PM 5/16/13, Fred Baker (fred) f...@cisco.com wrote: On May 16, 2013, at 9:40 AM, Adrian Farrel adr...@olddog.co.uk wrote: On the whole, I am told that if an AD weighs in with her comments during working group last call, her fearsome personality may overwhelm some of the WG participants and she may dominate the WG consensus. There may be places where that happens, but I would be surprised if it happened in my working group. I think it is fair to say that the AD (or an IAB member, or someone who has recognized expertise on the topic) is likely to be listened to more carefully than some others might. Heck, I'm careful when I make a technical comment on a document in my working group, flagging it with /chair to ensure that it is seen as intended - a comment by a competent practitioner of the art, not a process remark or an attempt to trump some other view. Speaking personally, I would prefer to see those comments in the WGLC, not IETF Last Call, if we can make that happen. For example, I'd like to get directorate reviews done (gen-art, security directorate, etc) in the timeframe of WGLC. I think Fred is returning to an earlier theme here, when he asks for earlier review. Perhaps, as has been already suggested in this thread, we should think about SIRSbis? First, from draft-carpenter-icar-sirs-01: The procedure described in this document is intended to solve, or palliate, a number of related problems that have been observed in the IETF process [PROBLEM]: *submission of documents to the IESG that still have significant problems (leading to delay) *failure to detect fundamental problems and Internet- wide issues at an early stage Particularly because of the second point, it is impossible to resolve these problems simply by giving additional responsibility to working groups themselves. An additional procedure is needed. In my opinion, it's important to assign responsibility (and accountability) to all WGs for producing publication-ready documents. I agree that some additional work is needed before WGs send documents to the IESG. Perhaps we can accomplish these goals through reorganizing the work we are I suggest we might want to combine the need for more responsibility with the discussion of a new really close to being ready document state. However, rather than a new document state, suppose we codify the expectation that a document that has passed WG last call is essentially ready-to-publish? Correspondingly, any significant problems found in a document after WG last call would be considered a serious defect. Discussion: I realize that, elsewhere in this thread, it has been asserted (or at least implied), that WGs already have this responsibility and DISCUSSes on document are usually unnecessary. In practice, while there may still be unnecessary DISCUSSes, my experience as AD was that most DISCUSSes were appropriate and each one referred to a problem that the WG had missed. Let's get all the expert review possible - directorate, AD, cross-area - in the WG last call review. What pops out *should* be ready for publication. Any issues raised by these reviews in WG last call will be exposed to and can be discussed by the WG at large, rather than being buried in the noise of IETF last call discussions or being fixed in more focused discussions among the IESG and the document authors. This procedure diverges some from draft-carpenter-icar-sirs-01, in that it doesn't add a new form of review process. Instead, it reschedules reviews that were going to take place anyway earlier in the process, so there is little or no new work added to the document publication process. Perhaps the WG chairs would want to assign document shepherds earlier in the process, as well, investing the document shepherds with the responsibility of getting the right reviews and advising the WG chairs as to the readiness of the document for advancement. Any WGs willing to volunteer as experimental subjects? There is really no new process to invent ... it's mostly a matter of realigning expectations and responsibilities out to - Ralph
Re: Is this an elephant? [Was: call for ideas: tail-heavy IETF process]
On 05/16/2013 04:46 PM, Yoav Nir wrote: The time for asking whether the group has considered making this field fixed length instead of variable, or whether RFC 2119 language is used in an appropriate way, or whether the protocol is extensible enough is at IETF last call. Actually the time for asking these questions is long before IETF-wide Last Call. We need widespread review of proposals for standards-track documents long before a WG thinks it's finished with those documents. It's a gaping hole in our process. Fix that problem, and most of the conflicts between IESG and WGs that surround DISCUSS votes will go away. Keith
Re: Is this an elephant? [Was: call for ideas: tail-heavy IETF process]
Dave - I hope you'll indulge my selective quoting as I have a couple of specific points to address. My apologies if I end up quoting you out of context... On May 16, 2013, at 12:23 PM 5/16/13, Dave Crocker d...@dcrocker.net wrote: [...] So here's a simple proposal that pays attention to AD workload and includes a simple efficiency hack: When the IETF Last Call is issued, wait a few days, to see whether any serious issues are raised by the community. The really serious ones usually are raised quickly. If there are none, it's pretty certain the document will advance to an IESG vote. That leaves 7-10 days of IETF Last Call for ADs to get educated and ask questions, just like everyone else. Jari has expressed the goal of having AD concerns be raised more publicly. Moving AD review and comment to the IETF Last Call venue nicely accomplishes this, too. I just posted elsewhere a suggestion to move this review even earlier, to WG last call. Accomplishes most of the same ends, while putting the discussion in front of the IETF participants who are, presumably, most invested in the resulting document. [...] In terms of quality assurance, the idea that we have a process that relies on the sudden insight of a single AD, at the end of a many-month process, is broken. It's fine if that person sees something that everyone else has missed until then, but that is quite different from designing a process that is claimed to rely on it. As you and I have discussed in person, I am 100% in agreement with this comment. As much as I liked to think of myself, when I was an AD, as a rock-god Network Expert with complete and in-depth insight into every document I reviewed, I know the reality was that any problems I might have found were related to the old observation that even a blind squirrel finds an acorn occasionally. And of course, the reality is that we allow bad specs out the door all the time; we just allow fewer of them than many/most other standards bodies... You're such an optimist. - Ralph d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net
Re: Is this an elephant? [Was: call for ideas: tail-heavy IETF process]
On May 16, 2013, at 5:58 PM 5/16/13, Keith Moore mo...@network-heretics.com wrote: On 05/16/2013 04:46 PM, Yoav Nir wrote: The time for asking whether the group has considered making this field fixed length instead of variable, or whether RFC 2119 language is used in an appropriate way, or whether the protocol is extensible enough is at IETF last call. Actually the time for asking these questions is long before IETF-wide Last Call. We need widespread review of proposals for standards-track documents long before a WG thinks it's finished with those documents. It's a gaping hole in our process. Hear, hear. Fix that problem, and most of the conflicts between IESG and WGs that surround DISCUSS votes will go away. Well, you might be a little optimistic here, but I agree in theory. Keith - Ralph
Re: Is this an elephant? [Was: call for ideas: tail-heavy IETF process]
On 5/16/13 2:58 PM, Keith Moore wrote: On 05/16/2013 04:46 PM, Yoav Nir wrote: The time for asking whether the group has considered making this field fixed length instead of variable, or whether RFC 2119 language is used in an appropriate way, or whether the protocol is extensible enough is at IETF last call. Actually the time for asking these questions is long before IETF-wide Last Call. We need widespread review of proposals for standards-track documents long before a WG thinks it's finished with those documents. It's a gaping hole in our process. As a Chair and as an AD I have asked for external and cross area reviews of some documents before they were considered for WG acceptance. this doesn't apply to all work we processed but it does apply to those where we were clear that such input was going to be useful. One case you can see for that today is with capwap extensions that are potentially in opsawg. Fix that problem, and most of the conflicts between IESG and WGs that surround DISCUSS votes will go away. Maybe but I wouldn't take that as an article of faith. You're going to get pressure for more changes when fresh eyes review something. Keith
Re: Is this an elephant? [Was: call for ideas: tail-heavy IETF process]
On 5/16/13 4:07 PM, Ralph Droms wrote: On May 16, 2013, at 5:58 PM 5/16/13, Keith Moore mo...@network-heretics.com wrote: On 05/16/2013 04:46 PM, Yoav Nir wrote: The time for asking whether the group has considered making this field fixed length instead of variable, or whether RFC 2119 language is used in an appropriate way, or whether the protocol is extensible enough is at IETF last call. Actually the time for asking these questions is long before IETF-wide Last Call. We need widespread review of proposals for standards-track documents long before a WG thinks it's finished with those documents. It's a gaping hole in our process. Hear, hear. One suggestion I've heard several times is a kind of cross-area buddy system (e.g., ask or assign someone with clue in Area X to help WG Y in Area Z early and often with regard to specific issues that are often addressed in Area X). Unfortunately, this suffers from the same problem that too many WGs suffer from on their own: participant burnout. But I still think it's a good idea... Peter -- Peter Saint-Andre https://stpeter.im/
Re: Is this an elephant? [Was: call for ideas: tail-heavy IETF process]
On May 16, 2013, at 1:46 PM, Yoav Nir y...@checkpoint.com wrote: There is a problem, though, that this will increase the load on ADs. Other concerns raised during IETF LC may lead to revised I-Ds, which the ADs will need to re-read (or at least look at the diff). I don't know how significant this extra work would be, but it would come at a time that we're thinking of ways to reduce AD workload. It might also require prolonging the LC time, because there would be actual discussion in it. If they raise the issue later in a discuss, will they not have to do this anyway? How does this relate to the timing of the comment or the vehicle by which it is conveyed? The ignorance of how to use new knowledge stockpiles exponentially. - Marshall McLuhan
Re: Gen-ART LC Review of draft-ietf-forces-interop-07
Hi Ben, Thank you very much for the review comments. Please see inline responses from authors of the document on the comments. Hi Sherpherd and AD, we will update a version very soon. thanks a lot. Weiming - Original Message - From: Ben Campbell b...@nostrum.com I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq. Please resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-forces-interop-07 Reviewer: Ben Campbell Review Date: 2013-05-13 IETF LC End Date: 2013-05-13 IESG Telechat date: Summary: This draft is almost ready for publication as an informational RFC. I have a few minor questions and editorial comments that may be worth considering prior to publication. *** Major issues: None. *** Minor issues: -- The draft mentions a couple of instances of tests that failed because of an incorrect implementation or differing encapsulation formats. Does this suggest that the specifications should be clarified? In particular, in the case of encapsulation format mismatch, should the specs include stronger requirements to be able to receive all encapsulation formats? Or should the number of options be reduced? [Re. by ΕΗ] The protocol provides a number of different approaches [Re. by Weiming] The key issue is still from the deep understanding of the protocol from implementations. I still have not seen need for any urgent change for the protocol. -- I have a mild concern that the use of origin country names for each implementation could confuse readers into thinking that the countries themselves officially participated, rather than organizations from each country. [Re by EH]Makes sense. We should possibly change this. In the beginning of section 2.2.1 where it says: The University of Patras implementation joined remotely from Greece Change to: The University of Patras (UoP) implementation joined remotely from Greece And then use UoP after that for us. [Re. by Weiming] I agree with Evangelos on this. If possible (key issue might be the text space for some figures) we may change the G to UoP, the J to NTT, the C to ZJSU ? Other authors, please show your views. Thanks. -- section 4.4, last paragraph: The text says that since the mentioned failures were likely the result of bugs, it doesn't indicate an interoperability problem in the specs. I have to point out that, it also doesn't prove interoperability in both directions for the particular test. It would also be worth commenting on whether the probably bugs were programming errors rather than misunderstandings of the specification. [Re. by Weiming] to change the whole paragraph to: t The two test items failed. Note that Test #7 and #8 were identical to the tests, only with CE and FE implementers were exchanged. Moreover, test #12 and #13 showed that the redirect channel worked well. Therefore, it can be reasonably inferred that the problem caused the failure was from the implementations, rather than from the ForCES protocol itself or from misunderstanding of implementations on the protocol specification. Although the failure made the OSPF interoperability test incomplete, it did not show interoperability problem. More test work is needed to verify the OSPF interoperability./t *** Nits/editorial comments: -- The draft uses inconsistent verb tense throughout. I found this a bit confusing, as I assume the draft talks entirely about tests that have already occurred. [Re. by ΕΗ] We will stick with the past tense. -- IDNits points out that you have several references without explicit citations. I see that you called the references out by name in the text, but it would be better to include the citations. [Re. by Weiming]We will try to fix this as much as possible. -- Section 1, paragraph 6: Please expand abbreviations on first mention. [Re. by Weiming] Yes. -- Section 1.1: Please expand FE on first mention. [Re. by Weiming] Yes. -- section 2.2.2, paragraph 1: ... from China and Japan implementations... Missing the. Is it possible to add a reference for details on the Smartbits testing machine? -- Figure 2: Do you really want to publish the IP addresses used in an RFC? RFCs live forever... -- Section 2.2.2, paragraph after figure 2: First sentence does not parse. [Re. by Weiming] In Figure 2, changed the '124.90.146.218 (ADSL)' to ' (ADSL)'. In Figure 3, changed the '150.140.254.110(VPN)' to '(VPN)' to avoid personal IP address in public. Section 2.2.2, paragraph after figure 2, first sentence is changed to: tCE and FE from the Greece implementation were located within the University of Patras, Greece, and were connected together using LAN as shown in xref target=Figure-3/. Connetion to the Internet was via a VPN channel. /t [/Re] -- Figure 3: The figure has some formatting issues, at least in the PDF version. Also, is it
Re: Is this an elephant? [Was: call for ideas: tail-heavy IETF process]
On 05/16/2013 06:09 PM, joel jaeggli wrote: Fix that problem, and most of the conflicts between IESG and WGs that surround DISCUSS votes will go away. Maybe but I wouldn't take that as an article of faith. You're going to get pressure for more changes when fresh eyes review something. Yeah, every new set of eyes that looks at a document is going to have some new ideas for what the document should be. The trick is to get those eyes to look at the document earlier in the process, when it's easier to fix problems. Maybe if we did the early review well enough, the scope of Last Call comments could be limited in some way. Keith
Weekly posting summary for ietf@ietf.org
Total of 151 messages in the last 7 days. script run at: Fri May 17 00:53:02 EDT 2013 Messages | Bytes| Who +--++--+ 9.27% | 14 | 9.58% | 113593 | mo...@network-heretics.com 9.27% | 14 | 7.82% |92650 | to...@isi.edu 7.28% | 11 | 6.76% |80173 | ted.le...@nominum.com 3.97% |6 | 6.47% |76736 | d...@dcrocker.net 3.31% |5 | 3.67% |43481 | s...@resistor.net 3.31% |5 | 3.63% |43035 | nar...@us.ibm.com 3.31% |5 | 3.34% |39531 | rdroms.i...@gmail.com 3.31% |5 | 3.00% |35548 | abdussalambar...@gmail.com 3.31% |5 | 2.98% |35297 | j...@joelhalpern.com 3.31% |5 | 2.72% |32293 | jari.ar...@piuha.net 2.65% |4 | 3.17% |37539 | brian.e.carpen...@gmail.com 2.65% |4 | 2.09% |24748 | stephen.farr...@cs.tcd.ie 2.65% |4 | 1.96% |23226 | wor...@ariadne.com 1.99% |3 | 2.20% |26128 | john-i...@jck.com 1.99% |3 | 1.73% |20523 | doug.mtv...@gmail.com 1.32% |2 | 2.05% |24243 | wmwang2...@hotmail.com 1.99% |3 | 1.36% |16166 | swm...@swm.pp.se 1.32% |2 | 1.92% |22726 | a...@yumaworks.com 1.32% |2 | 1.68% |19888 | flu...@cisco.com 1.32% |2 | 1.48% |17563 | far...@umn.edu 1.32% |2 | 1.41% |16770 | tv...@eyeconomics.com 1.32% |2 | 1.41% |16659 | adr...@olddog.co.uk 1.32% |2 | 1.36% |16115 | y...@checkpoint.com 1.32% |2 | 1.22% |14478 | scott.b...@gmail.com 1.32% |2 | 1.21% |14343 | joe...@bogus.com 1.32% |2 | 1.21% |14321 | f...@cisco.com 1.32% |2 | 1.15% |13634 | d...@virtualized.org 1.32% |2 | 1.10% |13000 | bcla...@cisco.com 1.32% |2 | 1.01% |11932 | l...@cisco.com 1.32% |2 | 0.89% |10500 | a...@anvilwalrusden.com 0.66% |1 | 1.15% |13606 | t...@ecs.soton.ac.uk 0.66% |1 | 1.07% |12720 | leo.liub...@huawei.com 0.66% |1 | 1.00% |11897 | presn...@qti.qualcomm.com 0.66% |1 | 0.97% |11460 | cb.li...@gmail.com 0.66% |1 | 0.95% |11263 | rjspa...@nostrum.com 0.66% |1 | 0.95% |11228 | hous...@vigilsec.com 0.66% |1 | 0.90% |10616 | tobias.gond...@gondrom.org 0.66% |1 | 0.86% |10205 | agma...@gmail.com 0.66% |1 | 0.74% | 8787 | superu...@gmail.com 0.66% |1 | 0.74% | 8716 | j.schoenwael...@jacobs-university.de 0.66% |1 | 0.68% | 8105 | b...@nostrum.com 0.66% |1 | 0.64% | 7568 | daedu...@btconnect.com 0.66% |1 | 0.62% | 7387 | aeop...@gmail.com 0.66% |1 | 0.62% | 7308 | carlosm3...@gmail.com 0.66% |1 | 0.60% | 7137 | elw...@dial.pipex.com 0.66% |1 | 0.60% | 7108 | l.w...@surrey.ac.uk 0.66% |1 | 0.55% | 6518 | barryle...@computer.org 0.66% |1 | 0.52% | 6160 | s...@cisco.com 0.66% |1 | 0.52% | 6119 | hartmans-i...@mit.edu 0.66% |1 | 0.51% | 6090 | stpe...@stpeter.im 0.66% |1 | 0.51% | 6020 | thierry.mor...@connotech.com 0.66% |1 | 0.48% | 5682 | m...@sap.com 0.66% |1 | 0.48% | 5650 | pe...@akayla.com 0.66% |1 | 0.47% | 5562 | l...@pi.nu 0.66% |1 | 0.46% | 5476 | d...@ewellic.org 0.66% |1 | 0.43% | 5041 | ra...@psg.com 0.66% |1 | 0.41% | 4902 | malcolm.be...@zte.com.cn +--++--+ 100.00% | 151 |100.00% | 1185170 | Total
Protocol Action: 'Universal Plug and Play (UPnP) Internet Gateway Device (IGD)-Port Control Protocol (PCP) Interworking Function' to Proposed Standard (draft-ietf-pcp-upnp-igd-interworking-10.txt)
The IESG has approved the following document: - 'Universal Plug and Play (UPnP) Internet Gateway Device (IGD)-Port Control Protocol (PCP) Interworking Function' (draft-ietf-pcp-upnp-igd-interworking-10.txt) as Proposed Standard This document is the product of the Port Control Protocol Working Group. The IESG contact persons are Ted Lemon and Brian Haberman. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-pcp-upnp-igd-interworking/ Technical Summary This document specifies the behavior of the UPnP IGD (Internet Gateway Device)/PCP Interworking Function. A UPnP IGD-PCP Interworking Function (IGD-PCP IWF) is required to be embedded in CP (Customer Premises) routers to allow for transparent NAT control in environments where UPnP IGD is used on the LAN side and PCP on the external side of the CP router. Working Group Summary Nothing unusual. Document Quality A public implementation is available at http://sourceforge.net/projects/pcpclient/?source=directory. The authors are also aware of other implementations from some CPE vendors that are not yet disclosed publically. The PCP WG has a policy to not send a document until the WG has consensus and there are at least 5 people who have reviewed and ok'ed the document. Many others were involved in reviews of earlier versions, but the WGLC oks came from: Xiaohong Deng dxhb...@gmail.com Dave Thaler dtha...@microsoft.com Reinaldo Penno repe...@cisco.com Tiru Reddy tire...@cisco.com Paul Selkirk pselk...@isc.org The above reviewers collectively represent multiple implementations or potential future implementations. Personnel Dave Thaler dtha...@microsoft.com is the document shepherd; Ted Lemon ted.le...@nominum.com is the responsible AD.
Last Call: draft-ietf-dhc-dhcpv6-radius-opt-11.txt (RADIUS Option for DHCPv6 Relay Agent) to Proposed Standard
The IESG has received a request from the Dynamic Host Configuration WG (dhc) to consider the following document: - 'RADIUS Option for DHCPv6 Relay Agent' draft-ietf-dhc-dhcpv6-radius-opt-11.txt as Proposed Standard 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 i...@ietf.org mailing lists by 2013-05-30. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract The DHCPv6 RADIUS option provides a mechanism to exchange authorization and identification information between the DHCPv6 relay agent and the DHCPv6 server. This mechanism is meant for the centralized DHCPv6 server to select the right configuration for the requesting DHCPv6 client based on the authorization information received from the RADIUS server, which is not co-located with the DHCPv6 server. The Network Access Server (NAS) acts as DHCPv6 relay agent and RADIUS client simultaneously in this document. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-dhc-dhcpv6-radius-opt/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-dhc-dhcpv6-radius-opt/ballot/ The following IPR Declarations may be related to this I-D: http://datatracker.ietf.org/ipr/2052/
