RE: The Purpose of WG participants Review (was Re: Purpose of IESG Review)
Yoav, Yes, Saratoga started as a draft in the DTNRG (draft-wood-tsvwg-saratoga). We carried the first bundles from space in 2008, and used our experience to analyse failings in the bundle protocol. (See our "A bundle of problems" paper.) Unfortunately, DTNRG wasn't chartered to do DTN research. It was chartered to do only development of the bundle protocol as the one true solution to DTNs, whick it wasn't. In any case, IRTF groups can't standardise anything, just produce experimental RFCs (though CCSDS was pushing for standardising bundling for itself last I looked.) Lloyd Wood http://sat-net.com/L.Wood/dtn From: Yoav Nir [y...@checkpoint.com] Sent: 22 April 2013 16:15 To: Wood L Dr (Electronic Eng) Cc: ; Subject: Re: The Purpose of WG participants Review (was Re: Purpose of IESG Review) Well, there isn't a delay tolerant networks working group, but the IRTF has a DTNRG ( http://irtf.org/dtnrg ). At least one of the chairs is a "goer". If you really wanted to standardize this, wouldn't you be able to find 1-2 people on the DTNRG list who would be willing to "do the BoF thing"? I'm not saying this is definitely what you should do. There are plenty of reasons to bring something to the IETF and to not bring it. I'm only saying that it is possible. Yoav On Apr 22, 2013, at 3:12 PM, l.w...@surrey.ac.uk wrote: > And the technology that my team is pushing would be Saratoga: > http://saratoga.sf.net > which has interoperable implementations that can do 50Mbps in perl, a decade > of operational experience in its application domain, and mature drafts. > > But this is in the transport area, and TSV has somewhat limited resources, so > it's outside the span of attention from a wg. But still worth documenting as > experimental. > > Lloyd Wood > http://sat-net.com/L.Wood/ > > > > From: Yoav Nir [y...@checkpoint.com] > Sent: 19 April 2013 10:02 > To: Wood L Dr (Electronic Eng) > Cc: ; > Subject: Re: The Purpose of WG participants Review (was Re: Purpose of IESG > Review) > > Only that you know enough people so that you could push a new technology even > without attending, although you would need to collaborate with some people > who do go. But pushing a new technology requires team building anyway. > > The same should apply to other non-attenders who have gained some reputation. > > > On Apr 19, 2013, at 11:23 AM, l.w...@surrey.ac.uk wrote: > >> >> and the point of your ad-hominem argument is what, exactly? >> >> Lloyd Wood >> http://sat-net.com/L.Wood/publications/internet-drafts >> >> >> >> From: Yoav Nir [y...@checkpoint.com] >> Sent: 18 April 2013 15:18 >> To: Wood L Dr (Electronic Eng) >> Cc: wor...@ariadne.com; ietf@ietf.org >> Subject: RE: The Purpose of WG participants Review (was Re: Purpose of IESG >>Review) >> >> Looking in Jari's statistics site, you have three RFCs. One of those has >> several co-authors that I recognize as current "goers". You also have a >> current draft with several co-authors, but I have no idea whether they're >> "goers" or not. Anyway, you are not a hermit. Through the RFCs and drafts >> that you have co-authored, you know people who do attend. > > > Email secured by Check Point
Re: The Purpose of WG participants Review (was Re: Purpose of IESG Review)
On 4/19/2013 2:02 AM, Yoav Nir wrote: Only that you know enough people so that you could push a new technology even without attending, IETF work officially happens on IETF lists, not at in-person meetings. As per the Tao of the IETF: "Any decision made at a face-to-face meeting must also gain consensus on the WG mailing list." Team-building is also useful, but not necessary, and also can happen off-list and at other non-IETF meetings. Joe
Re: The Purpose of WG participants Review (was Re: Purpose of IESG Review)
Well, there isn't a delay tolerant networks working group, but the IRTF has a DTNRG ( http://irtf.org/dtnrg ). At least one of the chairs is a "goer". If you really wanted to standardize this, wouldn't you be able to find 1-2 people on the DTNRG list who would be willing to "do the BoF thing"? I'm not saying this is definitely what you should do. There are plenty of reasons to bring something to the IETF and to not bring it. I'm only saying that it is possible. Yoav On Apr 22, 2013, at 3:12 PM, l.w...@surrey.ac.uk wrote: > And the technology that my team is pushing would be Saratoga: > http://saratoga.sf.net > which has interoperable implementations that can do 50Mbps in perl, a decade > of operational experience in its application domain, and mature drafts. > > But this is in the transport area, and TSV has somewhat limited resources, so > it's outside the span of attention from a wg. But still worth documenting as > experimental. > > Lloyd Wood > http://sat-net.com/L.Wood/ > > > > From: Yoav Nir [y...@checkpoint.com] > Sent: 19 April 2013 10:02 > To: Wood L Dr (Electronic Eng) > Cc: ; > Subject: Re: The Purpose of WG participants Review (was Re: Purpose of IESG > Review) > > Only that you know enough people so that you could push a new technology even > without attending, although you would need to collaborate with some people > who do go. But pushing a new technology requires team building anyway. > > The same should apply to other non-attenders who have gained some reputation. > > > On Apr 19, 2013, at 11:23 AM, l.w...@surrey.ac.uk wrote: > >> >> and the point of your ad-hominem argument is what, exactly? >> >> Lloyd Wood >> http://sat-net.com/L.Wood/publications/internet-drafts >> >> >> >> From: Yoav Nir [y...@checkpoint.com] >> Sent: 18 April 2013 15:18 >> To: Wood L Dr (Electronic Eng) >> Cc: wor...@ariadne.com; ietf@ietf.org >> Subject: RE: The Purpose of WG participants Review (was Re: Purpose of IESG >>Review) >> >> Looking in Jari's statistics site, you have three RFCs. One of those has >> several co-authors that I recognize as current "goers". You also have a >> current draft with several co-authors, but I have no idea whether they're >> "goers" or not. Anyway, you are not a hermit. Through the RFCs and drafts >> that you have co-authored, you know people who do attend. > > > Email secured by Check Point
RE: The Purpose of WG participants Review (was Re: Purpose of IESG Review)
And the technology that my team is pushing would be Saratoga: http://saratoga.sf.net which has interoperable implementations that can do 50Mbps in perl, a decade of operational experience in its application domain, and mature drafts. But this is in the transport area, and TSV has somewhat limited resources, so it's outside the span of attention from a wg. But still worth documenting as experimental. Lloyd Wood http://sat-net.com/L.Wood/ From: Yoav Nir [y...@checkpoint.com] Sent: 19 April 2013 10:02 To: Wood L Dr (Electronic Eng) Cc: ; Subject: Re: The Purpose of WG participants Review (was Re: Purpose of IESG Review) Only that you know enough people so that you could push a new technology even without attending, although you would need to collaborate with some people who do go. But pushing a new technology requires team building anyway. The same should apply to other non-attenders who have gained some reputation. On Apr 19, 2013, at 11:23 AM, l.w...@surrey.ac.uk wrote: > > and the point of your ad-hominem argument is what, exactly? > > Lloyd Wood > http://sat-net.com/L.Wood/publications/internet-drafts > > > > From: Yoav Nir [y...@checkpoint.com] > Sent: 18 April 2013 15:18 > To: Wood L Dr (Electronic Eng) > Cc: wor...@ariadne.com; ietf@ietf.org > Subject: RE: The Purpose of WG participants Review (was Re: Purpose of IESG > Review) > > Looking in Jari's statistics site, you have three RFCs. One of those has > several co-authors that I recognize as current "goers". You also have a > current draft with several co-authors, but I have no idea whether they're > "goers" or not. Anyway, you are not a hermit. Through the RFCs and drafts > that you have co-authored, you know people who do attend.
Re: The Purpose of WG participants Review (was Re: Purpose of IESG Review)
Only that you know enough people so that you could push a new technology even without attending, although you would need to collaborate with some people who do go. But pushing a new technology requires team building anyway. The same should apply to other non-attenders who have gained some reputation. On Apr 19, 2013, at 11:23 AM, l.w...@surrey.ac.uk wrote: > > and the point of your ad-hominem argument is what, exactly? > > Lloyd Wood > http://sat-net.com/L.Wood/publications/internet-drafts > > > > From: Yoav Nir [y...@checkpoint.com] > Sent: 18 April 2013 15:18 > To: Wood L Dr (Electronic Eng) > Cc: wor...@ariadne.com; ietf@ietf.org > Subject: RE: The Purpose of WG participants Review (was Re: Purpose of IESG > Review) > > Looking in Jari's statistics site, you have three RFCs. One of those has > several co-authors that I recognize as current "goers". You also have a > current draft with several co-authors, but I have no idea whether they're > "goers" or not. Anyway, you are not a hermit. Through the RFCs and drafts > that you have co-authored, you know people who do attend.
RE: The Purpose of WG participants Review (was Re: Purpose of IESG Review)
and the point of your ad-hominem argument is what, exactly? Lloyd Wood http://sat-net.com/L.Wood/publications/internet-drafts From: Yoav Nir [y...@checkpoint.com] Sent: 18 April 2013 15:18 To: Wood L Dr (Electronic Eng) Cc: wor...@ariadne.com; ietf@ietf.org Subject: RE: The Purpose of WG participants Review (was Re: Purpose of IESG Review) Looking in Jari's statistics site, you have three RFCs. One of those has several co-authors that I recognize as current "goers". You also have a current draft with several co-authors, but I have no idea whether they're "goers" or not. Anyway, you are not a hermit. Through the RFCs and drafts that you have co-authored, you know people who do attend.
Re: The Purpose of WG participants Review (was Re: Purpose of IESG Review)
On Apr 18, 2013, at 5:02 AM, Yoav Nir wrote: > but you can become "prominent" in the sense that people might say "this > document hasn't had enough review. Let's ask so-and-so to read it" Yes, it's worth noting that working group chairs are often desperate for people about whom they can say this, so whether you attend in person or not, if you are active on the mailing list and give good reviews and do good work, you will get asked for this kind of help, and that does mean that you have high status. I agree with Lloyd's criticism that you can't get everything this way, though, because we don't give off-site non-attendees an easy turn at the mic. We do try, but it's not the same if you aren't there in person.
RE: The Purpose of WG participants Review (was Re: Purpose of IESG Review)
Looking in Jari's statistics site, you have three RFCs. One of those has several co-authors that I recognize as current "goers". You also have a current draft with several co-authors, but I have no idea whether they're "goers" or not. Anyway, you are not a hermit. Through the RFCs and drafts that you have co-authored, you know people who do attend. You anyway can't get a really new technical direction all by yourself. You always need to form a group, whether that group is a "bar BoF" or a formal IETF mailing list, or whatever. I don't think you can get a new thing into the IETF without a group of 4-7 people, regardless of whether you attend the meeting. The only advantage in attending is that it makes it easy to socialize your idea and "assemble the avengers", but I've seen it done outside a meeting. As long as you have a "goer" in your team, you can move things forward. Yes, I attend because I think that makes me more effective. If for any reason I were no longer able to attend, I think I would still participate meaningfully. -Original Message- From: l.w...@surrey.ac.uk [mailto:l.w...@surrey.ac.uk] Sent: Thursday, April 18, 2013 1:12 PM To: Yoav Nir Cc: wor...@ariadne.com; ietf@ietf.org Subject: RE: The Purpose of WG participants Review (was Re: Purpose of IESG Review) I've written RFCs without attending meetings; easy to do if the work is a aligned with a workgroup. That's fine if you're happy to be a technical resource with skills to be drawn upon for problems set by others. However, if you're sufficiently technical that you can set new technical directions that are outside the scope of existing wgs -- well, the political enters the technical, and you need to fake being a goer to build interest and support for the direction, eg by holding a bof. Many existing "managers" have run wgs, but have they even attempted to establish new technical directions? If not, they're just bureaucrats. Safe pairs of hands. And probably not that technical. Lloyd Wood http://sat-net.com/L.Wood/ From: Yoav Nir [y...@checkpoint.com] Sent: 18 April 2013 10:02 To: Wood L Dr (Electronic Eng) Cc: ; Subject: Re: The Purpose of WG participants Review (was Re: Purpose of IESG Review) Not entirely true. It is true that getting "management positions" (chairs, AD, NomCom) requires meeting attendance. But a non-attender can get recognition for quality technical points, and can even progress technical work. RFC 4478 was published long before I attended my first meeting. My own working group (WebSec) has document authors who never attend meetings. In other areas there are frequent and prolific contributors, who either never attended a meeting or have quit attending them years ago. Even the directorates have such people. So no, you probably can't get a dot for your badge without actually having one, but you can become "prominent" in the sense that people might say "this document hasn't had enough review. Let's ask so-and-so to read it", or "I'm putting together a design team for foo. Let's see if we can get so-and-so to join" Yoav On Apr 18, 2013, at 11:31 AM, l.w...@surrey.ac.uk wrote: > > Not sure about the recognition for technical work. > > To progress technical work, you have to go to meetings. To progress in the > IETF (chair, AD, IESG) you have to go to meetings. > > Keep turning up and don't be too obviously completely abysmal technically, > and you can get a status dot on your badge. > > The IETF is run by goers, and goers like goers. > > Lloyd Wood > http://sat-net.com/L.Wood/ > > > ________ > From: ietf-boun...@ietf.org [ietf-boun...@ietf.org] On Behalf Of Dale > R. Worley [wor...@ariadne.com] > Sent: 17 April 2013 21:38 > To: ietf@ietf.org > Subject: Re: The Purpose of WG participants Review (was Re: Purpose of IESG > Review) > >> From: Ted Lemon >> >> On Apr 16, 2013, at 11:51 AM, Dale R. Worley wrote: >>> I've advocated the equivalent of the following opinion before >>> (http://www.ietf.org/mail-archive/web/ietf/current/msg77479.html), >>> but in the current context it bears repeating: Here in the IETF we >>> accept that low-status people may argue regarding technical matters, >>> but reserve for high-status people having opinions about our procedures. >> >> I thought your original message (the one you cite above) was very >> good, but I'm not sure I like the terms "low-status" and >> "high-status," simply because tey could be easily taken to mean >> something other than what I think you intend them to mean.
RE: The Purpose of WG participants Review (was Re: Purpose of IESG Review)
I've written RFCs without attending meetings; easy to do if the work is a aligned with a workgroup. That's fine if you're happy to be a technical resource with skills to be drawn upon for problems set by others. However, if you're sufficiently technical that you can set new technical directions that are outside the scope of existing wgs -- well, the political enters the technical, and you need to fake being a goer to build interest and support for the direction, eg by holding a bof. Many existing "managers" have run wgs, but have they even attempted to establish new technical directions? If not, they're just bureaucrats. Safe pairs of hands. And probably not that technical. Lloyd Wood http://sat-net.com/L.Wood/ From: Yoav Nir [y...@checkpoint.com] Sent: 18 April 2013 10:02 To: Wood L Dr (Electronic Eng) Cc: ; Subject: Re: The Purpose of WG participants Review (was Re: Purpose of IESG Review) Not entirely true. It is true that getting "management positions" (chairs, AD, NomCom) requires meeting attendance. But a non-attender can get recognition for quality technical points, and can even progress technical work. RFC 4478 was published long before I attended my first meeting. My own working group (WebSec) has document authors who never attend meetings. In other areas there are frequent and prolific contributors, who either never attended a meeting or have quit attending them years ago. Even the directorates have such people. So no, you probably can't get a dot for your badge without actually having one, but you can become "prominent" in the sense that people might say "this document hasn't had enough review. Let's ask so-and-so to read it", or "I'm putting together a design team for foo. Let's see if we can get so-and-so to join" Yoav On Apr 18, 2013, at 11:31 AM, l.w...@surrey.ac.uk wrote: > > Not sure about the recognition for technical work. > > To progress technical work, you have to go to meetings. To progress in the > IETF (chair, AD, IESG) you have to go to meetings. > > Keep turning up and don't be too obviously completely abysmal technically, > and you can get a status dot on your badge. > > The IETF is run by goers, and goers like goers. > > Lloyd Wood > http://sat-net.com/L.Wood/ > > > > From: ietf-boun...@ietf.org [ietf-boun...@ietf.org] On Behalf Of Dale R. > Worley [wor...@ariadne.com] > Sent: 17 April 2013 21:38 > To: ietf@ietf.org > Subject: Re: The Purpose of WG participants Review (was Re: Purpose of IESG > Review) > >> From: Ted Lemon >> >> On Apr 16, 2013, at 11:51 AM, Dale R. Worley wrote: >>> I've advocated the equivalent of the following opinion before >>> (http://www.ietf.org/mail-archive/web/ietf/current/msg77479.html), but >>> in the current context it bears repeating: Here in the IETF we accept >>> that low-status people may argue regarding technical matters, but >>> reserve for high-status people having opinions about our procedures. >> >> I thought your original message (the one you cite above) was very >> good, but I'm not sure I like the terms "low-status" and >> "high-status," simply because tey could be easily taken to mean >> something other than what I think you intend them to mean. > > We do have a status system within the IETF and generally one gains > status within that system by recognized technical work. And on > certain sorts of issues, particularly changes in processes, we don't > listen well to people who don't have high status within that system. > In that regard, the IETF is far from egalitarian. > > In regard to diversity issues, it is important to ask whether position > in the status system is directly affected by factors other than just > technical contribution. > > Probably more important for diversity issues is that factors in a > person's life other than their outright technical ability can strongly > affect their ability to contribute to our technical work, and thus > achieve the status needed to be influential. > > A more subtle problem is whether technical contribution correlates > well the skills needed for leadership positions -- does being a > quality technical contributor demonstrate the skills needed to be an > effective IAB member? Although given the discussion around "IESG > review", it seems that the reward for gaining the leadership position > of IESG membership is becoming an extremely busy technical reviewer of > standards... > > Dale > > Email secured by Check Point
Re: The Purpose of WG participants Review (was Re: Purpose of IESG Review)
Not entirely true. It is true that getting "management positions" (chairs, AD, NomCom) requires meeting attendance. But a non-attender can get recognition for quality technical points, and can even progress technical work. RFC 4478 was published long before I attended my first meeting. My own working group (WebSec) has document authors who never attend meetings. In other areas there are frequent and prolific contributors, who either never attended a meeting or have quit attending them years ago. Even the directorates have such people. So no, you probably can't get a dot for your badge without actually having one, but you can become "prominent" in the sense that people might say "this document hasn't had enough review. Let's ask so-and-so to read it", or "I'm putting together a design team for foo. Let's see if we can get so-and-so to join" Yoav On Apr 18, 2013, at 11:31 AM, l.w...@surrey.ac.uk wrote: > > Not sure about the recognition for technical work. > > To progress technical work, you have to go to meetings. To progress in the > IETF (chair, AD, IESG) you have to go to meetings. > > Keep turning up and don't be too obviously completely abysmal technically, > and you can get a status dot on your badge. > > The IETF is run by goers, and goers like goers. > > Lloyd Wood > http://sat-net.com/L.Wood/ > > > > From: ietf-boun...@ietf.org [ietf-boun...@ietf.org] On Behalf Of Dale R. > Worley [wor...@ariadne.com] > Sent: 17 April 2013 21:38 > To: ietf@ietf.org > Subject: Re: The Purpose of WG participants Review (was Re: Purpose of IESG > Review) > >> From: Ted Lemon >> >> On Apr 16, 2013, at 11:51 AM, Dale R. Worley wrote: >>> I've advocated the equivalent of the following opinion before >>> (http://www.ietf.org/mail-archive/web/ietf/current/msg77479.html), but >>> in the current context it bears repeating: Here in the IETF we accept >>> that low-status people may argue regarding technical matters, but >>> reserve for high-status people having opinions about our procedures. >> >> I thought your original message (the one you cite above) was very >> good, but I'm not sure I like the terms "low-status" and >> "high-status," simply because tey could be easily taken to mean >> something other than what I think you intend them to mean. > > We do have a status system within the IETF and generally one gains > status within that system by recognized technical work. And on > certain sorts of issues, particularly changes in processes, we don't > listen well to people who don't have high status within that system. > In that regard, the IETF is far from egalitarian. > > In regard to diversity issues, it is important to ask whether position > in the status system is directly affected by factors other than just > technical contribution. > > Probably more important for diversity issues is that factors in a > person's life other than their outright technical ability can strongly > affect their ability to contribute to our technical work, and thus > achieve the status needed to be influential. > > A more subtle problem is whether technical contribution correlates > well the skills needed for leadership positions -- does being a > quality technical contributor demonstrate the skills needed to be an > effective IAB member? Although given the discussion around "IESG > review", it seems that the reward for gaining the leadership position > of IESG membership is becoming an extremely busy technical reviewer of > standards... > > Dale > > Email secured by Check Point
RE: The Purpose of WG participants Review (was Re: Purpose of IESG Review)
Not sure about the recognition for technical work. To progress technical work, you have to go to meetings. To progress in the IETF (chair, AD, IESG) you have to go to meetings. Keep turning up and don't be too obviously completely abysmal technically, and you can get a status dot on your badge. The IETF is run by goers, and goers like goers. Lloyd Wood http://sat-net.com/L.Wood/ From: ietf-boun...@ietf.org [ietf-boun...@ietf.org] On Behalf Of Dale R. Worley [wor...@ariadne.com] Sent: 17 April 2013 21:38 To: ietf@ietf.org Subject: Re: The Purpose of WG participants Review (was Re: Purpose of IESG Review) > From: Ted Lemon > > On Apr 16, 2013, at 11:51 AM, Dale R. Worley wrote: > > I've advocated the equivalent of the following opinion before > > (http://www.ietf.org/mail-archive/web/ietf/current/msg77479.html), but > > in the current context it bears repeating: Here in the IETF we accept > > that low-status people may argue regarding technical matters, but > > reserve for high-status people having opinions about our procedures. > > I thought your original message (the one you cite above) was very > good, but I'm not sure I like the terms "low-status" and > "high-status," simply because tey could be easily taken to mean > something other than what I think you intend them to mean. We do have a status system within the IETF and generally one gains status within that system by recognized technical work. And on certain sorts of issues, particularly changes in processes, we don't listen well to people who don't have high status within that system. In that regard, the IETF is far from egalitarian. In regard to diversity issues, it is important to ask whether position in the status system is directly affected by factors other than just technical contribution. Probably more important for diversity issues is that factors in a person's life other than their outright technical ability can strongly affect their ability to contribute to our technical work, and thus achieve the status needed to be influential. A more subtle problem is whether technical contribution correlates well the skills needed for leadership positions -- does being a quality technical contributor demonstrate the skills needed to be an effective IAB member? Although given the discussion around "IESG review", it seems that the reward for gaining the leadership position of IESG membership is becoming an extremely busy technical reviewer of standards... Dale
Re: The Purpose of WG participants Review (was Re: Purpose of IESG Review)
> From: Ted Lemon > > On Apr 16, 2013, at 11:51 AM, Dale R. Worley wrote: > > I've advocated the equivalent of the following opinion before > > (http://www.ietf.org/mail-archive/web/ietf/current/msg77479.html), but > > in the current context it bears repeating: Here in the IETF we accept > > that low-status people may argue regarding technical matters, but > > reserve for high-status people having opinions about our procedures. > > I thought your original message (the one you cite above) was very > good, but I'm not sure I like the terms "low-status" and > "high-status," simply because tey could be easily taken to mean > something other than what I think you intend them to mean. We do have a status system within the IETF and generally one gains status within that system by recognized technical work. And on certain sorts of issues, particularly changes in processes, we don't listen well to people who don't have high status within that system. In that regard, the IETF is far from egalitarian. In regard to diversity issues, it is important to ask whether position in the status system is directly affected by factors other than just technical contribution. Probably more important for diversity issues is that factors in a person's life other than their outright technical ability can strongly affect their ability to contribute to our technical work, and thus achieve the status needed to be influential. A more subtle problem is whether technical contribution correlates well the skills needed for leadership positions -- does being a quality technical contributor demonstrate the skills needed to be an effective IAB member? Although given the discussion around "IESG review", it seems that the reward for gaining the leadership position of IESG membership is becoming an extremely busy technical reviewer of standards... Dale
Re: The Purpose of WG participants Review (was Re: Purpose of IESG Review)
On Apr 16, 2013, at 11:51 AM, Dale R. Worley wrote: > I've advocated the equivalent of the following opinion before > (http://www.ietf.org/mail-archive/web/ietf/current/msg77479.html), but > in the current context it bears repeating: Here in the IETF we accept > that low-status people may argue regarding technical matters, but > reserve for high-status people having opinions about our procedures. I thought your original message (the one you cite above) was very good, but I'm not sure I like the terms "low-status" and "high-status," simply because tey could be easily taken to mean something other than what I think you intend them to mean.
Re: The Purpose of WG participants Review (was Re: Purpose of IESG Review)
> > How can a memebr of staff in a company argue with the manager > > about the manager's decisions or performance? > > It is IMO the *obligation* of a professional to call his manager on > wrong decisions or performance. I've advocated the equivalent of the following opinion before (http://www.ietf.org/mail-archive/web/ietf/current/msg77479.html), but in the current context it bears repeating: Here in the IETF we accept that low-status people may argue regarding technical matters, but reserve for high-status people having opinions about our procedures. Dale
Re: Purpose of IESG Review
On 04/15/2013 05:26 PM, Joe Touch wrote: > We can continue to appoint groups with additional rounds of review, but IMO, > they are scoped (and the IESG review guidance appears to back up that point). I think Joe is correct there. Another data point is that we asked secdir (who currently have an 80% review rate for documents) if they could see a way to get more done earlier and thus reduce the review-all requirement for ADs. There were a significant number of secdir folks who thought that increasing the expectations on them might well mean getting far less than 80% of documents reviewed - basically, they're also very busy folks and our current 20% dropped-review rate might just shoot up if we ask for too much. I do wish there were a good way to reduce the AD review burden and am happy to chat on or offlist with anyone who has ideas, but I for one am not seeing anything obvious. S.
Re: Purpose of IESG Review
On Apr 15, 2013, at 12:23 PM, Michael Richardson wrote: > Maybe we should have an IETF first call (for objections), rather than > last call. I think that would look a lot like a DoS attack on the IETF, but it would be nice if there were a way to make it work.
Re: Purpose of IESG Review
On Apr 15, 2013, at 9:09 AM, Ted Lemon wrote: > On Apr 15, 2013, at 11:36 AM, Joe Touch wrote: >> It gives the IESG an exemption to participating in WG and IESG last call >> processes, which then frustrates the rest of the community that does not >> have this opportunity. > > You could equally say that the IETF last call frustrates the WG process, > since a document can fail IETF last call, and this can be extremely > frustrating for working groups. Witness the fiasco in the MIF working group > when they tried to advance a DHCP route option, for example. IETF LC does not come with a list of constraints of what is in and not in scope. > The IETF last call process is important, but it's not a panacea. Too many > documents come through the last call process for each one to get thorough > review by every IETF participant. The IESG are effectively the sacrificial > lambs of the IETF who have to read every single document on the IETF track > that makes it through last call. If docs get out of WG LC with no review, then there's a failure of IETF process. Every such doc should be read at least by a few independent reviewers, by the WG chairs, and by the ADs in that area. The same failure can - and does - happen at the IESG level. We can continue to appoint groups with additional rounds of review, but IMO, they are scoped (and the IESG review guidance appears to back up that point). Joe
Re: Purpose of IESG Review
> "Ted" == Ted Lemon writes: Ted> You could equally say that the IETF last call frustrates the WG Ted> process, since a document can fail IETF last call, and this can Ted> be extremely frustrating for working groups. Witness the Ted> fiasco in the MIF working group when they tried to advance a Ted> DHCP route option, for example. Maybe we should have an IETF first call (for objections), rather than last call. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works| network architect [ ] m...@sandelman.ca http://www.sandelman.ca/| ruby on rails[ pgpwtWAVHlvWK.pgp Description: PGP signature
Re: Purpose of IESG Review
On 15/04/13 15:45, Brian E Carpenter wrote: On 15/04/2013 15:23, Ted Lemon wrote: ... So in practice, although I feel great sympathy for this position, I think it's mistaken. I want the other ADs to comment on anything that they notice that looks like a problem. There's an important class of problem that can only be found by someone who is *not* a specialist - that is to say wording that's perfectly clear and unambiguous to someone very familiar with the topic, but is quite unclear to someone who isn't. This matters because we (presumably) want our specifications to be useful to people who are implementing or deploying them without already being members of the inner circle. Just to be specific, here is a piece of text that came out of a WG not so long ago. I have bowdlerised it: "The Foobar standards [RFCxxx], [RFCyyy] provide useful generic functionality like blah, blah and blah for reducing the overhead in Boofar networks. This functionality can be partly applied to Bleep." That was it - a third party implementing Bleep was apparently supposed to guess which bits of those RFCs applied where. This led to a DISCUSS and seven months of delay before that "partly" was disambiguated. Was that inappropriate out-of-area review? Brian On 15/04/13 14:09, Jari Arkko wrote: [Responding to Dave Crocker] But what is tiring about this line of justification is its continuing failure to balance the analysis by looking at the costs and problems that come with it. Does it provide regular and sufficient benefit to justify its considerable costs? Agreed. I would say it usually does justify its costs - skimping on the QA is almost always a bad idea. Speaking also from a gen-art perspective, getting a level of clarity and ease of use into a document may take a little while for a number of reviewers and authors, but the costs and benefits need to include the effort of implementers, testers and future users who will not appreciate getting a product that doesn't interoperate because the spec was unclear or they missed a point that might have been 'obvious' to the original authors. The size of the affected population is much bigger after publication (at least if anybody actually cares about the RFC). I have to say that in my experience the seven months of delay that Brian cites is rather unusual. For the vast majority of documents, the sorts of clarification needed can be sorted out in a couple of rounds of email, and the results are unlikely to require recycling back to the WG. That being said, there certainly are documents where I wonder why anybody seriously thought the document was ready for publication; trying to fix the process 'tail heaviness' (as Jari describes it) would help if we could find a way. It could be argued that the tail process is just too polite. Once a document embarks on the publication process we seemingly inevitably send it through all those reviews resulting in multitudinous politely phrased DISCUSSes and comments when what it really needs is a blunt refusal followed by some competent editing. /Elwyn
Re: Purpose of IESG Review
On Apr 15, 2013, at 11:36 AM, Joe Touch wrote: > It gives the IESG an exemption to participating in WG and IESG last call > processes, which then frustrates the rest of the community that does not have > this opportunity. You could equally say that the IETF last call frustrates the WG process, since a document can fail IETF last call, and this can be extremely frustrating for working groups. Witness the fiasco in the MIF working group when they tried to advance a DHCP route option, for example. The IETF last call process is important, but it's not a panacea. Too many documents come through the last call process for each one to get thorough review by every IETF participant. The IESG are effectively the sacrificial lambs of the IETF who have to read every single document on the IETF track that makes it through last call. When you say that the IESG should not get special treatment, I think you are misunderstanding what is special about the treatment the IESG gets. What is special is that we are expected to review every document. We could impose that requirement on the IETF as a whole. If all IETF participants were willing to do that, then IETF review might well be effective enough to eliminate the need for the IESG. But I don't think that's a realistic expectation, and I do not mean that as a criticism. What you would have accomplished if you did this would be to have turned every IETF participant into an AD, working 35 hours a week on document review.
Re: Purpose of IESG Review
On 4/15/2013 7:23 AM, Ted Lemon wrote: So it's hard to see the harm in [late non-area input by the IESG], It gives the IESG an exemption to participating in WG and IESG last call processes, which then frustrates the rest of the community that does not have this opportunity. It says that the opinion of the IESG is more important than that of the WG; we should be judging ideas on their own merit, not their origin. Joe
Re: Purpose of IESG Review
On Apr 15, 2013, at 7:45 AM, Brian E Carpenter wrote: > On 15/04/2013 15:23, Ted Lemon wrote: > > ... >> So in practice, although I feel great sympathy for this position, I think >> it's mistaken. I want the other ADs to comment on anything that they >> notice that looks like a problem. > > There's an important class of problem that can only be found by someone > who is *not* a specialist - that is to say wording that's perfectly > clear and unambiguous to someone very familiar with the topic, but is > quite unclear to someone who isn't. This matters because we (presumably) > want our specifications to be useful to people who are implementing or > deploying them without already being members of the inner circle. > > Just to be specific, here is a piece of text that came out of a WG > not so long ago. I have bowdlerized it: > > "The Foobar standards [RFCxxx], [RFCyyy] provide useful generic > functionality like blah, blah and blah for reducing the overhead in > Boofar networks. This functionality can be partly applied to Bleep." > > That was it - a third party implementing Bleep was apparently supposed > to guess which bits of those RFCs applied where. > > This led to a DISCUSS and seven months of delay before that "partly" > was disambiguated. Was that inappropriate out-of-area review? No, it was not. But I would argue that "seven months" in an IESG review was too long. At some point, the responsible AD should have written a set of questions and sent it back to whatever working group it came from with "don't send it back until you have answered those questions". The ADs shouldn't have spent their time trying to have the conversation; they should only have ensured that they were OK with the result. >From the working group side, it would *also* have been helpful to have the AD >that raised the question get involved in the WG discussion, if only to ensure >that s/he was OK with the outcome when it came.
Re: Purpose of IESG Review
On 15/04/2013 15:23, Ted Lemon wrote: ... > So in practice, although I feel great sympathy for this position, I think > it's mistaken. I want the other ADs to comment on anything that they notice > that looks like a problem. There's an important class of problem that can only be found by someone who is *not* a specialist - that is to say wording that's perfectly clear and unambiguous to someone very familiar with the topic, but is quite unclear to someone who isn't. This matters because we (presumably) want our specifications to be useful to people who are implementing or deploying them without already being members of the inner circle. Just to be specific, here is a piece of text that came out of a WG not so long ago. I have bowdlerised it: "The Foobar standards [RFCxxx], [RFCyyy] provide useful generic functionality like blah, blah and blah for reducing the overhead in Boofar networks. This functionality can be partly applied to Bleep." That was it - a third party implementing Bleep was apparently supposed to guess which bits of those RFCs applied where. This led to a DISCUSS and seven months of delay before that "partly" was disambiguated. Was that inappropriate out-of-area review? Brian
Re: Purpose of IESG Review
On Apr 12, 2013, at 10:47 PM, Andy Bierman wrote: > During IESG review, the ADs from other areas should > restrict their comments to issues related to their area. > The final review should avoid changes made > which are feature redesigns or feature enhancements, > and limit changes to bug fixes only. I have some sympathy for this argument, since most of the comments I've made about drafts since I started reviewing them as an AD, where I felt the most unsure I should be making the comment, have indeed been out-of-area or process comments. At the same time, I have expertise in quite a few protocols that aren't in my area, and I don't claim to be a perfect expert on every protocol that's being worked on by a working group for which I am responsible AD. So in practice, although I feel great sympathy for this position, I think it's mistaken. I want the other ADs to comment on anything that they notice that looks like a problem. Then we can have a conversation about it. What I've seen in the past two formal telechats, which are the only two I've been on as an AD, as opposed to a guest, is that out-of-area DISCUSSes and comments do get raised, and they get discussed, which is the whole point. Typically either some adjustment is made to the spec to make it clearer (this has been the case for nearly all of my DISCUSSes), or the AD who raised the DISCUSS is satisfied by the discussion and clears the DISCUSS without any change being made to the document. So it's hard to see the harm in this, although I know it's stressful for the authors and working group chairs who have to answer the questions. I've been there, and I know what it's like, and I'm very conscious of that when I write a DISCUSS or a comment. On the other hand, sometimes a document attracts a great deal of comment. Sometimes someone raises a point that is impossible to refute, and that clearly matters. I want that point to be raised whether the AD raising it is responsible for that area or not. Reviewing documents as an AD is really hard work. We had an easy telechat last Thursday—I think we had less than 150 pages of protocol specs to read for the telechat. It would not surprise me if the number of careful reviews of those documents doubled last week, for most of the documents. I think it's absurd to suggest that such a review won't catch any issues, and it's unreasonable to suggest that a reviewer keep silent on an issue he or she sees simply because it's "not their area."
Re: The Purpose of WG participants Review (was Re: Purpose of IESG Review)
> > On Fri, Apr 12, 2013 at 8:24 PM, Abdussalam Baryun > wrote: > How can a memebr of staff in a company argue with the manager about the > manager's decisions or performance? Only Owners/shareholders can question > managers and staff. IMO, the meeting/list discussions on any issue without an > I-D written is the staff talking/working. ??? Not in the country I live in or the company I work for. It is IMO the *obligation* of a professional to call his manager on wrong decisions or performance. I think you have a strange view on IETF leadership, I for one, as a chair of a WG regard myself as the *servant* of the WG rather than the *boss*. We decide based on consensus, not on hierarchy. Klaas
Re: Purpose of IESG Review
On Thu, Apr 11, 2013 at 5:27 PM, Fred Baker (fred) wrote: > In my opinion, some individual ADs seem to, from their behavior, feel that > they have not done their jobs unless they have raised a "discuss". The one > that took the cake for me personally was a "discuss" raised by a particular > AD (who shall remain nameless) that in essence wondered what he should raise > a "discuss" about in my document. There were a couple of errors in that; he > told me later that what he had done was opened the comment tool and typed > that question, and subsequently accidentally hit the equivalent of "send" - > the question wasn't intended to go out. But the question itself is telling: > the issue was not "does the document meet the requirements of BCP 9", it was > "what comment shall I raise"? > > Also, in my opinion, IESG review that raises a certain number of issues > should not result in the document sitting in the IESG's queue for a few > months while the authors go back and forth with the AD or the GEN-ART > reviewer pounding the document into someone's idea of "shape" without working > group involvement. I personally would prefer that simple matters get sorted > out between the ADs and the author, but complex changes or additional content > requested by the AD should result in the document being sent back to the > working group. Many of us can change the acronyms and describe a similar experience. I would say "We don't have the authority to make that decision without asking the WG" a lot. But this is a 2nd order problem. The real issue is the way the IESG manages WGs. Good management doesn't fall out for free. It is yet another continuous integration progress. The IESG is the overworked bottleneck in the system and the review process is the main reason. The ADs that own a WG should be the main IESG members that get involved at the details for any possible issue, and hopefully make these comments/changes as early in the WG process as possible. During IESG review, the ADs from other areas should restrict their comments to issues related to their area. The final review should avoid changes made which are feature redesigns or feature enhancements, and limit changes to bug fixes only. Andy
Re: Purpose of IESG Review
Responding to various people in one e-mail. To summarise, we have procedures that say what kinds of Discusses are appropriate, and personal engineering preferences are not. Legitimate issues should be raised, however, and in the case of most big issues, the right approach would be to send a document back to the working group for revision. But overall, my perception is that the ADs take their task very seriously, and try to do the right thing when performing their IESG reviews. I think they make a significant contribution to the quality of our documents. That being said, a couple of other things are also obvious. First, we have a very tail-heavy process. I get a lot of comments about that, and you all know it too. Moving more of the problem finding to earlier parts of the process is necessary (but also not easy). Secondly, I know from personal experience that feedback on what kinds of things get raised in the IESG review is very useful. Even if we are trying to do the right thing, we make mistake, and perhaps more importantly, our understanding of what kinds of discusses are useful keeps evolving. Please tell us when you think we are doing the wrong thing (be it not raising an issue or raising it in the wrong category). Finally, today too many big revisions are handled as a discussion between the authors and ADs. Big discussions should be done publicly in the working group, and in some cases the right action is for a document to be sent to the working group so that it can be reprocesses and returned. And then to the specific responses. Fred: > In my opinion, some individual ADs seem to, from their behavior, feel that > they have not done their jobs unless they have raised a "discuss". The one > that took the cake for me personally was a "discuss" raised by a particular > AD (who shall remain nameless) that in essence wondered what he should raise > a "discuss" about in my document. There were a couple of errors in that; he > told me later that what he had done was opened the comment tool and typed > that question, and subsequently accidentally hit the equivalent of "send" - > the question wasn't intended to go out. But the question itself is telling: > the issue was not "does the document meet the requirements of BCP 9", it was > "what comment shall I raise"? And this is of course completely against our rules in the Discuss criteria document. But accidents do happen. If there were an intentional "I owe you" Discuss, that is obviously something that should go away, and authors and other ADs should complain about it. > Also, in my opinion, IESG review that raises a certain number of issues > should not result in the document sitting in the IESG's queue for a few > months while the authors go back and forth with the AD or the GEN-ART > reviewer pounding the document into someone's idea of "shape" without working > group involvement. I personally would prefer that simple matters get sorted > out between the ADs and the author, but complex changes or additional content > requested by the AD should result in the document being sent back to the > working group. > I'm not saying it doesn't serve a purpose. I'm saying that I know of drafts > that have been nearly rewritten during such back-and-forth, so what popped > out was largely unrelated to what went in. In such cases, I think the > document should have been returned to the working group with comments, not > worked on privately. I agree 100% with this. Adrian: > Examples are useful because they give the IESG something to chew on. If you > don't call us when we do "bad stuff" we might never know. Indeed. For what it is worth, my own idea of what kinds of things I should as an AD complain about has evolved quite a bit. As a new AD I was overly eager, ready to defend the Internet against… bad documents. In some cases filing Discusses that in retrospect I probably should have filed as Comments. Over the years I've come to the realisation that most things are additional Comments for the authors to take into account, but that real brokenness should still cause a Discuss to be raised. But for such development to occur, you need to gain some perspective. Part of that process is getting feedback. > I believe that the clue is in the word "Discuss" and I hope that I (at least) > am > willing to listen when the response is "we thought about it, it's not a big > problem." +1 Brian: > Seeing randomly selected drafts as a Gen-ART reviewer, I can > say that serious defects quite often survive WG review and > sometimes survive IETF Last Call review, so the final review > by the IESG does serve a purpose. This is one of the big issues. I think we all agree that our process is tail-heavy. More review and more problem discoveries occur at the end. This is trivial to see, but the crux is how that could be changed. Dave: > the tendency of ADs to inject spontaneous, late-stage personal engineering > preference
Re: Purpose of IESG Review
- Original Message - From: To: ; ; Sent: Saturday, April 13, 2013 3:46 AM If you think security and congestion are arcane, you have... problems. This was an actual ietf working geoup, and not some e.g. W3c thing? Lloyd Yes, e.g. in Operations and Management. I track ICCRG (and have some familiarity with congestive collapse, having had to trouble shoot it) but I also track some transport groups and see pressure to allow traffic to build up faster, coming I think from a major 'vendor'. I do not think that there is agreement on whether or not we should speed up networks (e.g. initial window = 10) thereby increasing the risk of congestion. Equally, I track SSH and TLS and continue, even after many years, to be surprised at the hostile actions that are devised against networks and the measures that get taken to counter them. In both areas, I find the IESG to be cautious (and wonder if they are being too cautious); but I am no expert in those fields and continue to be surprised by the IESG. I think that for many outside Security or Transport Areas, these topics are still arcane. Tom Petch p.s. the last response I made to Lloyd got a reply to the effect that Lloyd was no longer at the University of Surrey, so I do not know if this will reach you/him. Lloyd Wood http://sat-net.com/L.Wood/ From: ietf-boun...@ietf.org [ietf-boun...@ietf.org] On Behalf Of t.p. [daedu...@btconnect.com] Sent: 12 April 2013 21:52 To: Arturo Servin; ietf@ietf.org Subject: Re: Purpose of IESG Review - Original Message - From: "Arturo Servin" To: Sent: Friday, April 12, 2013 8:28 PM > > Not answering any particular post. Just a comment. > > The IESG should be there to attest that the IETF procedure was followed > and the document reached consensus in the WG and in the IETF LC and it > was successfully reviewed by the Gen-ART. If it wasn't then this > particular process should be reviewed and take actions accordingly (e.g. > returning the document to the wg). > > But if a single individual of the IESG can technically challenge and > change the work of a whole WG and the IETF, then we have something wrong > in our process because that means that the document had a serious > problem and we didn't spot it in the process or an IESG member is using > its power to change a document according to its personal beliefs. My experience has been the former, where the IESG has raised concerns about arcane topics, such as security and congestion, of which the WG had limited expertise. This might be caught by a directorate review, but those seem patchy; it might be caught by IETF Last Call, but if you are an expert at an arcane topic then you are probably too busy to follow them. So I do see the IESG DISCUSSing, when it would have been lovely to have had, but it is hard to see quite how, it resolved earlier. We just do not have the breadth of knowledge of arcane topics. Tom Petch > Just a thought, > as > > On 4/11/13 2:54 PM, Joe Touch wrote: > > Hi, all, > > > > As an author who has had (and has) multiple documents in IESG review, > > I've noticed an increasing trend of this step to go beyond (IMO) its > > documented and original intent (BCP 9, currently RFC 2026): > > > >The IESG shall determine whether or not a specification submitted to > >it according to section 6.1.1 satisfies the applicable criteria for > >the recommended action (see sections 4.1 and 4.2), and shall in > >addition determine whether or not the technical quality and clarity > >of the specification is consistent with that expected for the > >maturity level to which the specification is recommended. > > > > Although I appreciate that IESG members are often overloaded, and the > > IESG Review step is often the first time many see these documents, I > > believe they should be expected to more clearly differentiate their > > "IESG Review" (based on the above criteria) - and its accompanying > > Position ballot, with their personal review. > > > > My concern is that by conflating their IESG position with their personal > > review, the document process is inappropriately delayed and that > > documents are modified to appease a small community that does not > > justify its position as representative. > > > > How do others feel about this? > > > > Joe >
Re: Purpose of IESG Review
Hi Murray, I don't want me, you or anyother volunteer to leave, but also don't want IESG memebrs to leave. I don't disagree with the concept of discussing with managers or in the IETF to discuss with IESG (against indirect methods of doing that). Please don't ignore that the first message and all thread (related to subject) was not sent to IESG address (or even copied). Speaking directly to the problem or to the one making an error in performance is always the right thing to do. We all work together in a friendly environment, by solving all problems by direct effective efforts. Thanking you, AB On 4/14/13, Murray S. Kucherawy wrote: > On Fri, Apr 12, 2013 at 12:24 PM, Abdussalam Baryun < > abdussalambar...@gmail.com> wrote: > >> How can a memebr of staff in a company argue with the manager about the >> manager's decisions or performance? Only Owners/shareholders can question >> managers and staff. IMO, the meeting/list discussions on any issue >> without an I-D written is the staff talking/working. >> > > That is, as John said, completely wrong for any organization that wants to > be successful. That goes for the IETF as well. If I thought the IETF > operated in the restricted way you're describing, I'd have walked away long > ago. The same goes for any serious job I've ever had. > > In my experience here, there's always room to ask for justification for a > decision, and push back on things with which you disagree, be they > technical or procedural. Different personalities respond to those > challenges differently, of course, but that doesn't change the point. > > >> I hope that when I review and comment on an I-D, it should be considered >> as one owner is talking, but seems like editors think they are the only >> owners. When IESG comment on the I-D it is managers/excutives talking. >> All >> parts are important to the best of output. >> > > The role of a document editor is to record consensus. If you comment on > something and nobody supports your perspective and the editor doesn't adopt > your suggestions, then the editor may seem like she or he is ignoring you > but has actually done the job properly. > > -MSK >
Re: Purpose of IESG Review
On Fri, Apr 12, 2013 at 12:24 PM, Abdussalam Baryun < abdussalambar...@gmail.com> wrote: > How can a memebr of staff in a company argue with the manager about the > manager's decisions or performance? Only Owners/shareholders can question > managers and staff. IMO, the meeting/list discussions on any issue > without an I-D written is the staff talking/working. > That is, as John said, completely wrong for any organization that wants to be successful. That goes for the IETF as well. If I thought the IETF operated in the restricted way you're describing, I'd have walked away long ago. The same goes for any serious job I've ever had. In my experience here, there's always room to ask for justification for a decision, and push back on things with which you disagree, be they technical or procedural. Different personalities respond to those challenges differently, of course, but that doesn't change the point. > I hope that when I review and comment on an I-D, it should be considered > as one owner is talking, but seems like editors think they are the only > owners. When IESG comment on the I-D it is managers/excutives talking. All > parts are important to the best of output. > The role of a document editor is to record consensus. If you comment on something and nobody supports your perspective and the editor doesn't adopt your suggestions, then the editor may seem like she or he is ignoring you but has actually done the job properly. -MSK
RE: Purpose of IESG Review
--On Friday, April 12, 2013 23:50 + Pat Thaler wrote: > +1 on for John's response. > > I will argue with my manager if I think they are wrong and > I've gotten positive results from giving managers feedback on > their performance. Of course, disagreeing with management > won't always get the decision changed, but I've never felt I > lost anything by raising the discussion. I should probably have added that, for some specific classes of issues and for those who are members of ACM, IEEE, and several other professional societies, failure to do so is a violation of the standards of professional ethics to which they have agreed. Then again, so is discriminatory behavior. See, e.g., http://www.acm.org/about/code-of-ethics and http://www.ieee.org/about/corporate/governance/p7-8.html . > I've also seen some bad decisions made when someone had good > reasons why a decision was wrong but didn't surface them > because they didn't feel they could argue with management. Yep. I didn't say it always worked out well or that all managers are competent and secure enough to tolerate feedback. > IETF participant to IETF leadership isn't the same as employee > to manager of course. We are all volunteers collaborating to > get good results and if we feel there is a process problem we > can discuss it. IETF formalizes this by having open mike > sessions for example. And appeal procedures as an integral part of the decision-making process. I've said this before, but I believe we don't use those enough for "normal" situations where issues and tradeoffs have not been considered properly. That lack of use has led to an impression that appeals were the tools and refuge of crazies and trolls, which was certainly never the intent. > A thread on whether there is a problem with the IESG review > process is appropriate, IMO. Oh, indeed. And, at a slightly more indirect level, I believe that the ways in which carefully thought-out constructive discussion and suggestions have sometimes been belittled and suppressed lies at the root of some of our larger problems. Unfortunately, noise from crazies, people who strongly push suggestions or comments without bothering to try to understand the actual situations or history, a few people who think that making IETF more like some other body would automatically make it better, fear of change by those in leadership positions, and miscellaneous trolls has made those more constructive conversations difficult as well. john
Re: Purpose of IESG Review
AB Have you considered that the key thing to remember in the IETF is that: "Foo is broken because of (carefully reasoned) Bar" always trumps "Foo is OK because of who I am" ... and of course vise versa. Thus in the IETF influence is a function of the ability to carefully construct a well reasoned technical argument rather than organizational position. Of course you have to accept that no matter how carefully reasoned your case for Bar is, your reasoning may be flawed, and if that is the case you will normally be told so, sometimes fairly bluntly, and that the NULL argument will likely be ignored as noise. - Stewart On 12/04/2013 20:24, Abdussalam Baryun wrote: How can a memebr of staff in a company argue with the manager about the manager's decisions or performance? Only Owners/shareholders can question managers and staff. IMO, the meeting/list discussions on any issue without an I-D written is the staff talking/working. If you write an I-D and to update the procedure related to the subject, you should consider many issues and I think will need many years of discussions, but then better effort result. IMHO, writing an I-D and getting back up by community discussion (with rough consensus) is in the top level and is the owner talking. I hope that when I review and comment on an I-D, it should be considered as one owner is talking, but seems like editors think they are the only owners. When IESG comment on the I-D it is managers/excutives talking. All parts are important to the best of output. AB
Re: Purpose of IESG Review
On 12/04/2013 14:17, Fred Baker (fred) wrote: On Apr 12, 2013, at 12:13 AM, Brian E Carpenter wrote: Seeing randomly selected drafts as a Gen-ART reviewer, I can say that serious defects quite often survive WG review and sometimes survive IETF Last Call review, so the final review by the IESG does serve a purpose. I'm not saying it doesn't serve a purpose. I'm saying that I know of drafts that have been nearly rewritten during such back-and-forth, so what popped out was largely unrelated to what went in. In such cases, I think the document should have been returned to the working group with comments, not worked on privately. Fred The Discusses and Comments are public, all versions of the draft are public, the authors and chairs (who are usually the shepherds) see all the review emails. Now maybe the IESG need to be more pro-active in sending drafts back to the WG, although that may also be unpopular, but if an author, shepherd or chair made that request I can think of few circumstances where an AD that would likely refuse. - Stewart
Re: Purpose of IESG Review
On 13/04/2013 03:46, l.w...@surrey.ac.uk wrote: > If you think security and congestion are arcane, you have... problems. I think this may be the point that Diana Raft was making in draft-draft-draft about 12 days ago. Brian > > This was an actual ietf working geoup, and not some e.g. W3c thing? > > Lloyd Wood > http://sat-net.com/L.Wood/ > > > > From: ietf-boun...@ietf.org [ietf-boun...@ietf.org] On Behalf Of t.p. > [daedu...@btconnect.com] > Sent: 12 April 2013 21:52 > To: Arturo Servin; ietf@ietf.org > Subject: Re: Purpose of IESG Review > > - Original Message - > From: "Arturo Servin" > To: > Sent: Friday, April 12, 2013 8:28 PM >> Not answering any particular post. Just a comment. >> >> The IESG should be there to attest that the IETF procedure was > followed >> and the document reached consensus in the WG and in the IETF LC and it >> was successfully reviewed by the Gen-ART. If it wasn't then this >> particular process should be reviewed and take actions accordingly > (e.g. >> returning the document to the wg). >> >> But if a single individual of the IESG can technically challenge and >> change the work of a whole WG and the IETF, then we have something > wrong >> in our process because that means that the document had a serious >> problem and we didn't spot it in the process or an IESG member is > using >> its power to change a document according to its personal beliefs. > > My experience has been the former, where the IESG has raised concerns > about arcane topics, such as security and congestion, of which the WG > had limited expertise. This might be caught by a directorate review, > but those seem patchy; it might be caught by IETF Last Call, but if you > are an expert at an arcane topic then you are probably too busy to > follow them. > > So I do see the IESG DISCUSSing, when it would have been lovely to have > had, but it is hard to see quite how, it resolved earlier. We just do > not have the breadth of knowledge of arcane topics. > > Tom Petch > >> Just a thought, >> as >> >> On 4/11/13 2:54 PM, Joe Touch wrote: >>> Hi, all, >>> >>> As an author who has had (and has) multiple documents in IESG > review, >>> I've noticed an increasing trend of this step to go beyond (IMO) its >>> documented and original intent (BCP 9, currently RFC 2026): >>> >>>The IESG shall determine whether or not a specification submitted > to >>>it according to section 6.1.1 satisfies the applicable criteria > for >>>the recommended action (see sections 4.1 and 4.2), and shall in >>>addition determine whether or not the technical quality and > clarity >>>of the specification is consistent with that expected for the >>>maturity level to which the specification is recommended. >>> >>> Although I appreciate that IESG members are often overloaded, and > the >>> IESG Review step is often the first time many see these documents, I >>> believe they should be expected to more clearly differentiate their >>> "IESG Review" (based on the above criteria) - and its accompanying >>> Position ballot, with their personal review. >>> >>> My concern is that by conflating their IESG position with their > personal >>> review, the document process is inappropriately delayed and that >>> documents are modified to appease a small community that does not >>> justify its position as representative. >>> >>> How do others feel about this? >>> >>> Joe > > >
Re: Purpose of IESG Review
Do you raise a discussion saying the below? I believe you should be expected to more clearly differentiate your *Review* (based on the such procedure criteria) - and its accompanying Position ballot, with your personal review. (Modified from the first message of thread) Refering to first message: I believe they should be expected to more clearly differentiate their "IESG Review" (based on the above criteria) - and its accompanying Position ballot, with their personal review. We need manager's personal review and experience, I think the business needs manager's personal views as well. AB On 4/13/13, Pat Thaler wrote: > +1 on for John's response. > > I will argue with my manager if I think they are wrong and I've gotten > positive results from giving managers feedback on their performance. Of > course, disagreeing with management won't always get the decision changed, > but I've never felt I lost anything by raising the discussion. > > I've also seen some bad decisions made when someone had good reasons why a > decision was wrong but didn't surface them because they didn't feel they > could argue with management. > > IETF participant to IETF leadership isn't the same as employee to manager of > course. We are all volunteers collaborating to get good results and if we > feel there is a process problem we can discuss it. IETF formalizes this by > having open mike sessions for example. > > A thread on whether there is a problem with the IESG review process is > appropriate, IMO. > > -Original Message- > From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of John > C Klensin > Sent: Friday, April 12, 2013 3:19 PM > To: Abdussalam Baryun; ietf > Subject: Re: Purpose of IESG Review > > > > --On Friday, April 12, 2013 20:24 +0100 Abdussalam Baryun > wrote: > >> How can a memebr of staff in a company argue with the manager >> about the manager's decisions or performance? > > In most successful companies, yes. > >> Only >> Owners/shareholders can question managers and staff. > > And companies that behave that way don't last very long in > rapidly evolving fields... at least unless the managers are > endowed with perfect wisdom. It is not an accident that most > management schools teach would-be managers that listening > --especially to the people on the front lines-- is a very > important skill. > > So, at the risk of generalizing too much... What on earth are > you talking about and what experience do you have and use to > justify it? > > john > > > >
Re: The Purpose of WG participants Review (was Re: Purpose of IESG Review)
Hi Arturo, and all, (sorry that this message is long but I want to make this my last post on the subject) The reason of this message/subject is that I want to avoid some group working together to achieve their purpose (while they may be fogetting the IETF purpose) within a WG. If I am a company and interested to publish a standard in IETF, I may think to find interest in my market place (i.e. interest usually in my local country or city which depends on relations), when that is gained then the purpose is to publish it in IETF while there already gauranteed sort of back up in that country/city. I name that a *group purpose* not the *WG purpose*. Group purpose is good but may lack technical experience, which needs following WG purpose. Any group (usually authors+ WhoInterestedToPublish) needs to convence the WG by technical discussions. Consensus and running code, may work for the group purpose more than the WG purpose if the WG are not reactive to inputs. I recommend that WG chairs are already aware of this and try to find independent reviewers from the WG to put some effort before it is submitted to the IESG. Usually WG participants are bussy and may not be interested to argue with a group (one reviewer may get many replies with arguments that he/she has no much time to DISCUSS, or reply). That is why the IESG's DISCUSS position is strong and important to make the group answer to purpose, and that position is weak in WGs. Groups always don't like delays in process, but WGs don't like changing their IETF purpose or their IETF vision. I recommend that WG chairs try to do their best to have two independent WG participants to review (not authors and not from the same company of authors or same state/city). If you send me a reply I will reply privately so I don't disturb, because the subject may not be important for others, thanking you, AB We need diversity :-) --- On 4/12/13, Arturo Servin wrote: > > > On 4/12/13 4:58 PM, Abdussalam Baryun wrote: >> I just change the subject because I still beleive the problem with >> review is in the WG not IESG. Some WGs have few reviews on each WG >> document, that may not be bad, but I think having only one review or >> comment (excluding authors) within a WGLC is wrong in a WG review >> process. I think WG chair can find two participants to do it. > > It seems plausible. > >> >> I recommend WG's process to change their purpose so we have to get *two >> participants* which are not authors to review the work and comment >> within WGLC (even small text comment is ok). I recommend WG chairs to >> think about this proposal, if not then I will try write an I-D for this >> and communicate with community. > > Possible we would need any how an I+D to change the process and mandate > this new review. > > I haven't made my mind but it seems like a good idea. > >> >> AB > > Regards > as >
RE: Purpose of IESG Review
If you think security and congestion are arcane, you have... problems. This was an actual ietf working geoup, and not some e.g. W3c thing? Lloyd Wood http://sat-net.com/L.Wood/ From: ietf-boun...@ietf.org [ietf-boun...@ietf.org] On Behalf Of t.p. [daedu...@btconnect.com] Sent: 12 April 2013 21:52 To: Arturo Servin; ietf@ietf.org Subject: Re: Purpose of IESG Review - Original Message - From: "Arturo Servin" To: Sent: Friday, April 12, 2013 8:28 PM > > Not answering any particular post. Just a comment. > > The IESG should be there to attest that the IETF procedure was followed > and the document reached consensus in the WG and in the IETF LC and it > was successfully reviewed by the Gen-ART. If it wasn't then this > particular process should be reviewed and take actions accordingly (e.g. > returning the document to the wg). > > But if a single individual of the IESG can technically challenge and > change the work of a whole WG and the IETF, then we have something wrong > in our process because that means that the document had a serious > problem and we didn't spot it in the process or an IESG member is using > its power to change a document according to its personal beliefs. My experience has been the former, where the IESG has raised concerns about arcane topics, such as security and congestion, of which the WG had limited expertise. This might be caught by a directorate review, but those seem patchy; it might be caught by IETF Last Call, but if you are an expert at an arcane topic then you are probably too busy to follow them. So I do see the IESG DISCUSSing, when it would have been lovely to have had, but it is hard to see quite how, it resolved earlier. We just do not have the breadth of knowledge of arcane topics. Tom Petch > Just a thought, > as > > On 4/11/13 2:54 PM, Joe Touch wrote: > > Hi, all, > > > > As an author who has had (and has) multiple documents in IESG review, > > I've noticed an increasing trend of this step to go beyond (IMO) its > > documented and original intent (BCP 9, currently RFC 2026): > > > >The IESG shall determine whether or not a specification submitted to > >it according to section 6.1.1 satisfies the applicable criteria for > >the recommended action (see sections 4.1 and 4.2), and shall in > >addition determine whether or not the technical quality and clarity > >of the specification is consistent with that expected for the > >maturity level to which the specification is recommended. > > > > Although I appreciate that IESG members are often overloaded, and the > > IESG Review step is often the first time many see these documents, I > > believe they should be expected to more clearly differentiate their > > "IESG Review" (based on the above criteria) - and its accompanying > > Position ballot, with their personal review. > > > > My concern is that by conflating their IESG position with their personal > > review, the document process is inappropriately delayed and that > > documents are modified to appease a small community that does not > > justify its position as representative. > > > > How do others feel about this? > > > > Joe >
RE: Purpose of IESG Review
+1 on for John's response. I will argue with my manager if I think they are wrong and I've gotten positive results from giving managers feedback on their performance. Of course, disagreeing with management won't always get the decision changed, but I've never felt I lost anything by raising the discussion. I've also seen some bad decisions made when someone had good reasons why a decision was wrong but didn't surface them because they didn't feel they could argue with management. IETF participant to IETF leadership isn't the same as employee to manager of course. We are all volunteers collaborating to get good results and if we feel there is a process problem we can discuss it. IETF formalizes this by having open mike sessions for example. A thread on whether there is a problem with the IESG review process is appropriate, IMO. -Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of John C Klensin Sent: Friday, April 12, 2013 3:19 PM To: Abdussalam Baryun; ietf Subject: Re: Purpose of IESG Review --On Friday, April 12, 2013 20:24 +0100 Abdussalam Baryun wrote: > How can a memebr of staff in a company argue with the manager > about the manager's decisions or performance? In most successful companies, yes. > Only > Owners/shareholders can question managers and staff. And companies that behave that way don't last very long in rapidly evolving fields... at least unless the managers are endowed with perfect wisdom. It is not an accident that most management schools teach would-be managers that listening --especially to the people on the front lines-- is a very important skill. So, at the risk of generalizing too much... What on earth are you talking about and what experience do you have and use to justify it? john
Re: Purpose of IESG Review
--On Friday, April 12, 2013 20:24 +0100 Abdussalam Baryun wrote: > How can a memebr of staff in a company argue with the manager > about the manager's decisions or performance? In most successful companies, yes. > Only > Owners/shareholders can question managers and staff. And companies that behave that way don't last very long in rapidly evolving fields... at least unless the managers are endowed with perfect wisdom. It is not an accident that most management schools teach would-be managers that listening --especially to the people on the front lines-- is a very important skill. So, at the risk of generalizing too much... What on earth are you talking about and what experience do you have and use to justify it? john
Re: Purpose of IESG Review
On 4/12/13 5:52 PM, t.p. wrote: > - Original Message - > From: "Arturo Servin" > To: > Sent: Friday, April 12, 2013 8:28 PM >> >> Not answering any particular post. Just a comment. >> >> The IESG should be there to attest that the IETF procedure was > followed >> and the document reached consensus in the WG and in the IETF LC and it >> was successfully reviewed by the Gen-ART. If it wasn't then this >> particular process should be reviewed and take actions accordingly > (e.g. >> returning the document to the wg). >> >> But if a single individual of the IESG can technically challenge and >> change the work of a whole WG and the IETF, then we have something > wrong >> in our process because that means that the document had a serious >> problem and we didn't spot it in the process or an IESG member is > using >> its power to change a document according to its personal beliefs. > > My experience has been the former, where the IESG has raised concerns > about arcane topics, such as security and congestion, of which the WG > had limited expertise. This might be caught by a directorate review, > but those seem patchy; it might be caught by IETF Last Call, but if you > are an expert at an arcane topic then you are probably too busy to > follow them. > > So I do see the IESG DISCUSSing, when it would have been lovely to have > had, but it is hard to see quite how, it resolved earlier. We just do > not have the breadth of knowledge of arcane topics. Perhaps we need an "arcane topic reviewer" before the LC. .as > > Tom Petch > >> Just a thought, >> as >> >> On 4/11/13 2:54 PM, Joe Touch wrote: >>> Hi, all, >>> >>> As an author who has had (and has) multiple documents in IESG > review, >>> I've noticed an increasing trend of this step to go beyond (IMO) its >>> documented and original intent (BCP 9, currently RFC 2026): >>> >>>The IESG shall determine whether or not a specification submitted > to >>>it according to section 6.1.1 satisfies the applicable criteria > for >>>the recommended action (see sections 4.1 and 4.2), and shall in >>>addition determine whether or not the technical quality and > clarity >>>of the specification is consistent with that expected for the >>>maturity level to which the specification is recommended. >>> >>> Although I appreciate that IESG members are often overloaded, and > the >>> IESG Review step is often the first time many see these documents, I >>> believe they should be expected to more clearly differentiate their >>> "IESG Review" (based on the above criteria) - and its accompanying >>> Position ballot, with their personal review. >>> >>> My concern is that by conflating their IESG position with their > personal >>> review, the document process is inappropriately delayed and that >>> documents are modified to appease a small community that does not >>> justify its position as representative. >>> >>> How do others feel about this? >>> >>> Joe >> >
Re: Purpose of IESG Review
- Original Message - From: "Arturo Servin" To: Sent: Friday, April 12, 2013 8:28 PM > > Not answering any particular post. Just a comment. > > The IESG should be there to attest that the IETF procedure was followed > and the document reached consensus in the WG and in the IETF LC and it > was successfully reviewed by the Gen-ART. If it wasn't then this > particular process should be reviewed and take actions accordingly (e.g. > returning the document to the wg). > > But if a single individual of the IESG can technically challenge and > change the work of a whole WG and the IETF, then we have something wrong > in our process because that means that the document had a serious > problem and we didn't spot it in the process or an IESG member is using > its power to change a document according to its personal beliefs. My experience has been the former, where the IESG has raised concerns about arcane topics, such as security and congestion, of which the WG had limited expertise. This might be caught by a directorate review, but those seem patchy; it might be caught by IETF Last Call, but if you are an expert at an arcane topic then you are probably too busy to follow them. So I do see the IESG DISCUSSing, when it would have been lovely to have had, but it is hard to see quite how, it resolved earlier. We just do not have the breadth of knowledge of arcane topics. Tom Petch > Just a thought, > as > > On 4/11/13 2:54 PM, Joe Touch wrote: > > Hi, all, > > > > As an author who has had (and has) multiple documents in IESG review, > > I've noticed an increasing trend of this step to go beyond (IMO) its > > documented and original intent (BCP 9, currently RFC 2026): > > > >The IESG shall determine whether or not a specification submitted to > >it according to section 6.1.1 satisfies the applicable criteria for > >the recommended action (see sections 4.1 and 4.2), and shall in > >addition determine whether or not the technical quality and clarity > >of the specification is consistent with that expected for the > >maturity level to which the specification is recommended. > > > > Although I appreciate that IESG members are often overloaded, and the > > IESG Review step is often the first time many see these documents, I > > believe they should be expected to more clearly differentiate their > > "IESG Review" (based on the above criteria) - and its accompanying > > Position ballot, with their personal review. > > > > My concern is that by conflating their IESG position with their personal > > review, the document process is inappropriately delayed and that > > documents are modified to appease a small community that does not > > justify its position as representative. > > > > How do others feel about this? > > > > Joe >
Re: The Purpose of WG participants Review (was Re: Purpose of IESG Review)
On 4/12/13 4:58 PM, Abdussalam Baryun wrote: > I just change the subject because I still beleive the problem with > review is in the WG not IESG. Some WGs have few reviews on each WG > document, that may not be bad, but I think having only one review or > comment (excluding authors) within a WGLC is wrong in a WG review > process. I think WG chair can find two participants to do it. It seems plausible. > > I recommend WG's process to change their purpose so we have to get *two > participants* which are not authors to review the work and comment > within WGLC (even small text comment is ok). I recommend WG chairs to > think about this proposal, if not then I will try write an I-D for this > and communicate with community. Possible we would need any how an I+D to change the process and mandate this new review. I haven't made my mind but it seems like a good idea. > > AB Regards as
Re: Purpose of IESG Review
On 4/12/13 4:32 PM, Melinda Shore wrote: > On 4/12/2013 11:28 AM, Arturo Servin wrote: >> But if a single individual of the IESG can technically challenge and >> change the work of a whole WG and the IETF, then we have something wrong >> in our process because that means that the document had a serious >> problem and we didn't spot it in the process or an IESG member is using >> its power to change a document according to its personal beliefs. > > We've had that happen in a working group I chair and I do > think that it was the result of process failure in the > working group. That said, there seemed to be broad > agreement across the IESG that the document had certain > specific flaws I think that exemplifies well what the IESG should do. - I do think there's a problem if a single > IESG member can reject working group consensus and hold > up a document - it seems as if there should be wider > agreement that the document is too flawed to progress. > > Melinda > Yes. Best wishes, as
The Purpose of WG participants Review (was Re: Purpose of IESG Review)
I just change the subject because I still beleive the problem with review is in the WG not IESG. Some WGs have few reviews on each WG document, that may not be bad, but I think having only one review or comment (excluding authors) within a WGLC is wrong in a WG review process. I think WG chair can find two participants to do it. I recommend WG's process to change their purpose so we have to get *two participants* which are not authors to review the work and comment within WGLC (even small text comment is ok). I recommend WG chairs to think about this proposal, if not then I will try write an I-D for this and communicate with community. AB On Fri, Apr 12, 2013 at 8:24 PM, Abdussalam Baryun < abdussalambar...@gmail.com> wrote: > How can a memebr of staff in a company argue with the manager about the > manager's decisions or performance? Only Owners/shareholders can question > managers and staff. IMO, the meeting/list discussions on any issue > without an I-D written is the staff talking/working. > > If you write an I-D and to update the procedure related to the subject, > you should consider many issues and I think will need many years of > discussions, but then better effort result. IMHO, writing an I-D and > getting back up by community discussion (with rough consensus) is in the > top level and is the owner talking. > > I hope that when I review and comment on an I-D, it should be considered > as one owner is talking, but seems like editors think they are the only > owners. When IESG comment on the I-D it is managers/excutives talking. All > parts are important to the best of output. > > AB > > > On Fri, Apr 12, 2013 at 10:33 AM, Abdussalam Baryun < > abdussalambar...@gmail.com> wrote: > >> Reply to below message >> The subject SHOULD be: Evaluating Review Process Performance >> I prefer the Subject is: Evaluating WG input, the WG review process, >> and the WG output, NOT IESG review. >> >> >> >> Hi Joe, >> >> My comments mostly is on your message, but I comment also on I-Ds or >> RFCs related to IETF (including joky RFCs). >> >> I don't think it is write to evaluate the review of an IESG as long as >> when we created the I-D and adopted it into IETF SYSTEM, it is already >> agreeing on the methods of process that I-D is going through. So the >> problem is to evaluate three things not one: 1) the input, 2) the >> process review, 3) the output. >> >> We may make different input methods that go to another body than IESG, >> but if you decided to make I-D under IETF current procedure, it will >> have to go to IESG. >> >> I think the IESG are doing an excellent job, but it is best them to >> evaluate their performance not the community. Or it is better to find >> a body that evaluates the IESG performance not on this list. >> >> I consider your input on the list as a complain about the process, so >> I ask you to notice that your input has an error that needs evaluation >> befor going to process evaluation. You may evaluate output, but I >> remind you to evaluate input of WGs and inputs of individuals. >> >> I think the BIG problem of delay in I-Ds or RFC, is the cause of the >> WG not the IESG, if you do an excellent WG processes you will get >> quick results at IESG. >> >> AB >> + >> Hi, all, >> >> >> As an author who has had (and has) multiple documents in IESG review, >> I've noticed an increasing trend of this step to go beyond (IMO) its >> documented and original intent (BCP 9, currently RFC 2026): >>The IESG shall determine whether or not a specification submitted to >>it according to section 6.1.1 satisfies the applicable criteria for >>the recommended action (see sections 4.1 and 4.2), and shall in >>addition determine whether or not the technical quality and clarity >>of the specification is consistent with that expected for the >>maturity level to which the specification is recommended. >> >> >> Although I appreciate that IESG members are often overloaded, and the >> IESG Review step is often the first time many see these documents, I >> believe they should be expected to more clearly differentiate their >> "IESG Review" (based on the above criteria) - and its accompanying >> Position ballot, with their personal review. >> >> My concern is that by conflating their IESG position with their >> personal review, the document process is inappropriately delayed and >> that documents are modified to appease a small community that does not >> justify its position as representative. >> How do others feel about this? >> >> Joe >> > >
Re: Purpose of IESG Review
On 4/12/2013 11:28 AM, Arturo Servin wrote: > But if a single individual of the IESG can technically challenge and > change the work of a whole WG and the IETF, then we have something wrong > in our process because that means that the document had a serious > problem and we didn't spot it in the process or an IESG member is using > its power to change a document according to its personal beliefs. We've had that happen in a working group I chair and I do think that it was the result of process failure in the working group. That said, there seemed to be broad agreement across the IESG that the document had certain specific flaws - I do think there's a problem if a single IESG member can reject working group consensus and hold up a document - it seems as if there should be wider agreement that the document is too flawed to progress. Melinda
Re: Purpose of IESG Review
Not answering any particular post. Just a comment. The IESG should be there to attest that the IETF procedure was followed and the document reached consensus in the WG and in the IETF LC and it was successfully reviewed by the Gen-ART. If it wasn't then this particular process should be reviewed and take actions accordingly (e.g. returning the document to the wg). But if a single individual of the IESG can technically challenge and change the work of a whole WG and the IETF, then we have something wrong in our process because that means that the document had a serious problem and we didn't spot it in the process or an IESG member is using its power to change a document according to its personal beliefs. Just a thought, as On 4/11/13 2:54 PM, Joe Touch wrote: > Hi, all, > > As an author who has had (and has) multiple documents in IESG review, > I've noticed an increasing trend of this step to go beyond (IMO) its > documented and original intent (BCP 9, currently RFC 2026): > >The IESG shall determine whether or not a specification submitted to >it according to section 6.1.1 satisfies the applicable criteria for >the recommended action (see sections 4.1 and 4.2), and shall in >addition determine whether or not the technical quality and clarity >of the specification is consistent with that expected for the >maturity level to which the specification is recommended. > > Although I appreciate that IESG members are often overloaded, and the > IESG Review step is often the first time many see these documents, I > believe they should be expected to more clearly differentiate their > "IESG Review" (based on the above criteria) - and its accompanying > Position ballot, with their personal review. > > My concern is that by conflating their IESG position with their personal > review, the document process is inappropriately delayed and that > documents are modified to appease a small community that does not > justify its position as representative. > > How do others feel about this? > > Joe
Re: Purpose of IESG Review
How can a memebr of staff in a company argue with the manager about the manager's decisions or performance? Only Owners/shareholders can question managers and staff. IMO, the meeting/list discussions on any issue without an I-D written is the staff talking/working. If you write an I-D and to update the procedure related to the subject, you should consider many issues and I think will need many years of discussions, but then better effort result. IMHO, writing an I-D and getting back up by community discussion (with rough consensus) is in the top level and is the owner talking. I hope that when I review and comment on an I-D, it should be considered as one owner is talking, but seems like editors think they are the only owners. When IESG comment on the I-D it is managers/excutives talking. All parts are important to the best of output. AB On Fri, Apr 12, 2013 at 10:33 AM, Abdussalam Baryun < abdussalambar...@gmail.com> wrote: > Reply to below message > The subject SHOULD be: Evaluating Review Process Performance > I prefer the Subject is: Evaluating WG input, the WG review process, > and the WG output, NOT IESG review. > > > > Hi Joe, > > My comments mostly is on your message, but I comment also on I-Ds or > RFCs related to IETF (including joky RFCs). > > I don't think it is write to evaluate the review of an IESG as long as > when we created the I-D and adopted it into IETF SYSTEM, it is already > agreeing on the methods of process that I-D is going through. So the > problem is to evaluate three things not one: 1) the input, 2) the > process review, 3) the output. > > We may make different input methods that go to another body than IESG, > but if you decided to make I-D under IETF current procedure, it will > have to go to IESG. > > I think the IESG are doing an excellent job, but it is best them to > evaluate their performance not the community. Or it is better to find > a body that evaluates the IESG performance not on this list. > > I consider your input on the list as a complain about the process, so > I ask you to notice that your input has an error that needs evaluation > befor going to process evaluation. You may evaluate output, but I > remind you to evaluate input of WGs and inputs of individuals. > > I think the BIG problem of delay in I-Ds or RFC, is the cause of the > WG not the IESG, if you do an excellent WG processes you will get > quick results at IESG. > > AB > + > Hi, all, > > > As an author who has had (and has) multiple documents in IESG review, > I've noticed an increasing trend of this step to go beyond (IMO) its > documented and original intent (BCP 9, currently RFC 2026): >The IESG shall determine whether or not a specification submitted to >it according to section 6.1.1 satisfies the applicable criteria for >the recommended action (see sections 4.1 and 4.2), and shall in >addition determine whether or not the technical quality and clarity >of the specification is consistent with that expected for the >maturity level to which the specification is recommended. > > > Although I appreciate that IESG members are often overloaded, and the > IESG Review step is often the first time many see these documents, I > believe they should be expected to more clearly differentiate their > "IESG Review" (based on the above criteria) - and its accompanying > Position ballot, with their personal review. > > My concern is that by conflating their IESG position with their > personal review, the document process is inappropriately delayed and > that documents are modified to appease a small community that does not > justify its position as representative. > How do others feel about this? > > Joe >
Re: Purpose of IESG Review
Brian E Carpenter wrote: > > I have no interest in or knowledge of the technical details, > but there is a pretty complicated DISCUSS against this draft, > which doesn't look like rubber-stamping to me: > https://datatracker.ietf.org/doc/draft-ietf-pkix-rfc2560bis/ballot/ > > I assume you've already let the IESG know about the defects you're > concerned about. The concern I originally raised durint LC is primarily a defect of rfc5019 that rfc2560bis does not properly deal with, and is in theory fairly trivial to fix. A much more concerning defect has just recently been uncovered: http://www.ietf.org/mail-archive/web/pkix/current/msg32635.html the complete absence of requirements to allow OCSP response caching (and OCSP response cache updating), which is going to become important for the two work items that are currently active in TLS: - a TLS extension for multiple OCSP response stapling - a TLS caching extension and I strongly believe that PKIX needs to fix that defect/omission and clarify the OCSP response caching semantics in rfc2560bis (and document requirements for "thisUpdate"), or this will result in unexpected and undesirable behaviour (aka interop problems). I have no implementation experience with OCSP, so a number of problems will not be directly apparent to me. But I'm really wondering why noone who has implemented OCSP response caching so far (and I believe there are implementations) has ever brought up this issue against rfc2560 so far. This is close to impossible to miss _for_an_implementor_. -Martin
Re: Purpose of IESG Review
On Apr 12, 2013, at 11:26 AM, Martin Rex wrote: > I'm currently seeing a document with some serious defects in > IETF Last Call (rfc2560bis) and an apparent desire to have > it Rubberstamped by the IESG (recycling at Proposed Standard). FWIW, I raised the same question during IESG review. It didn't seem like a "serious defect" to me, but it did seem like a strange design choice. I ultimately withdrew my objection after we walked through the problem. If we were doing a clean slate design, fixing the problem as you proposed would be a net win. Given that there are substantial existing deployments, it doesn't look like a net win to me. I think this is really a matter of judgment, not a matter of fact, so while I sympathize that it didn't come out your way, I don't agree with you that the wrong thing happened.
Re: Purpose of IESG Review
I have no interest in or knowledge of the technical details, but there is a pretty complicated DISCUSS against this draft, which doesn't look like rubber-stamping to me: https://datatracker.ietf.org/doc/draft-ietf-pkix-rfc2560bis/ballot/ I assume you've already let the IESG know about the defects you're concerned about. Brian On 12/04/2013 16:26, Martin Rex wrote: > Brian E Carpenter wrote: >> Seeing randomly selected drafts as a Gen-ART reviewer, I can >> say that serious defects quite often survive WG review and >> sometimes survive IETF Last Call review, so the final review >> by the IESG does serve a purpose. > > I'm currently seeing a document with some serious defects in > IETF Last Call (rfc2560bis) and an apparent desire to have > it Rubberstamped by the IESG (recycling at Proposed Standard). > > While that seems procedurally permitted for the IESG to do such > rubberstamping (aka "waive") for a proposed standard > (rfc2026, last paragraph on page 12): > >http://tools.ietf.org/html/rfc2026#page-12 > >A Proposed Standard should have no known technical omissions with >respect to the requirements placed upon it. However, the IESG may >waive this requirement in order to allow a specification to advance >to the Proposed Standard state when it is considered to be useful and >necessary (and timely) even with known technical omissions. > > one should really consider the consequences of such a decision, > especially for -bis and -ter documents. > > The original draft (and now full) standard requires that such defects > are removed _before_ the document is advanced. So when "waiving" known > defects/omissions (in particular obvious and formally provable ones), > this means that there will have to be a ter document produced where > this defects are fixed and this document be recycled at Proposed > one more time before the standard can progress on the maturity level. > > It turns out that for a non-negligible amount of the defects there > is a constituency that want the defect to be retained rather than > fixed, and they expect the IESG to waive defects on -bis, -ter etc. > documents whenever it was previously accepted for Proposed with > that defect. > > >> IMHO, if the IESG members sticks to their own criteria at >> http://www.ietf.org/iesg/statement/discuss-criteria.html, >> i.e. do not DISCUSS a document for spurious reasons, they >> are doing just fine. If they don't stick to those criteria, >> complaint is justified. >> >> Of course this will always be a matter of judgment. >> >> Regards >>Brian >> >> On 11/04/2013 18:54, Joe Touch wrote: >>> My concern is that by conflating their IESG position with their personal >>> review, the document process is inappropriately delayed and that >>> documents are modified to appease a small community that does not >>> justify its position as representative. > > What do you want to see the IESG do instead? > > Simply Rubberstamp WG consensus? That would turn the whole IESG > diversity discussion into an absurd waste of time... > > -Martin >
Re: Purpose of IESG Review
Brian E Carpenter wrote: > > Seeing randomly selected drafts as a Gen-ART reviewer, I can > say that serious defects quite often survive WG review and > sometimes survive IETF Last Call review, so the final review > by the IESG does serve a purpose. I'm currently seeing a document with some serious defects in IETF Last Call (rfc2560bis) and an apparent desire to have it Rubberstamped by the IESG (recycling at Proposed Standard). While that seems procedurally permitted for the IESG to do such rubberstamping (aka "waive") for a proposed standard (rfc2026, last paragraph on page 12): http://tools.ietf.org/html/rfc2026#page-12 A Proposed Standard should have no known technical omissions with respect to the requirements placed upon it. However, the IESG may waive this requirement in order to allow a specification to advance to the Proposed Standard state when it is considered to be useful and necessary (and timely) even with known technical omissions. one should really consider the consequences of such a decision, especially for -bis and -ter documents. The original draft (and now full) standard requires that such defects are removed _before_ the document is advanced. So when "waiving" known defects/omissions (in particular obvious and formally provable ones), this means that there will have to be a ter document produced where this defects are fixed and this document be recycled at Proposed one more time before the standard can progress on the maturity level. It turns out that for a non-negligible amount of the defects there is a constituency that want the defect to be retained rather than fixed, and they expect the IESG to waive defects on -bis, -ter etc. documents whenever it was previously accepted for Proposed with that defect. > > IMHO, if the IESG members sticks to their own criteria at > http://www.ietf.org/iesg/statement/discuss-criteria.html, > i.e. do not DISCUSS a document for spurious reasons, they > are doing just fine. If they don't stick to those criteria, > complaint is justified. > > Of course this will always be a matter of judgment. > > Regards >Brian > > On 11/04/2013 18:54, Joe Touch wrote: > > > > My concern is that by conflating their IESG position with their personal > > review, the document process is inappropriately delayed and that > > documents are modified to appease a small community that does not > > justify its position as representative. What do you want to see the IESG do instead? Simply Rubberstamp WG consensus? That would turn the whole IESG diversity discussion into an absurd waste of time... -Martin
Re: Purpose of IESG Review
On 12/04/2013 14:17, Fred Baker (fred) wrote: > On Apr 12, 2013, at 12:13 AM, Brian E Carpenter > wrote: > >> Seeing randomly selected drafts as a Gen-ART reviewer, I can >> say that serious defects quite often survive WG review and >> sometimes survive IETF Last Call review, so the final review >> by the IESG does serve a purpose. > > I'm not saying it doesn't serve a purpose. I'm saying that I know of drafts > that have been nearly rewritten during such back-and-forth, so what popped > out was largely unrelated to what went in. In such cases, I think the > document should have been returned to the working group with comments, not > worked on privately. I agree. That should be standard operating procedure. Brian
Re: Purpose of IESG Review
On Apr 12, 2013, at 12:13 AM, Brian E Carpenter wrote: > Seeing randomly selected drafts as a Gen-ART reviewer, I can > say that serious defects quite often survive WG review and > sometimes survive IETF Last Call review, so the final review > by the IESG does serve a purpose. I'm not saying it doesn't serve a purpose. I'm saying that I know of drafts that have been nearly rewritten during such back-and-forth, so what popped out was largely unrelated to what went in. In such cases, I think the document should have been returned to the working group with comments, not worked on privately.
Re: Purpose of IESG Review
On 4/12/2013 12:13 AM, Brian E Carpenter wrote: Seeing randomly selected drafts as a Gen-ART reviewer, I can say that serious defects quite often survive WG review and sometimes survive IETF Last Call review, so the final review by the IESG does serve a purpose. Brian, Of course it "serves" a purpose. The lack of perfection in the specifications that reach the IESG has always been the justification for the current review model. But what is tiring about this line of justification is its continuing failure to balance the analysis by looking at the costs and problems that come with it. Does it provide regular and sufficient benefit to justify its considerable costs? First, it is a phenomenally expensive step, with a very damaging organizational cost: the time and effort burden put on ADs makes the pool of available ADs tiny, including dramatically reducing the range of companies that can afford to donate senior (strategic) staff to it. Along with this is the general issue that has triggered Joe's query: the tendency of ADs to inject spontaneous, late-stage personal engineering preferences, which might have been reasonable to add to the original working group discussion but realistically have no place in a final review. It's not that the preferences are necessarily inappropriate, it's that they typically are not essential to the success of the spec. But in terms of the specific logic you've used, the presumption of the "it catches errors sometimes" language is that the final output that is the result is somehow perfect. Of course, that's a silly assumption. But as soon as one acknowledges this, we are left with a model that must class this as merely one more review in an imperfect sequence, with the likelihood that an every new review will find more problems. Or we are left with the view that pragmatics dictate accepting imperfections because each step of the quality assurance model -- of which this is a part -- really does need a strict cost/benefit analysis. This needs to be done in terms of trade-offs, rather than an isolated approach that counts the detection of an occasional problem as somehow an inherent and controlling good. An essential component to such a trade-off based model is recognizing that the ultimate quality assurance step always has been, and remains, the market. No amount of IETF q/a guarantees success. We have lots of failures and we won't ever get to zero. If the IESG review step really is essential, then we should show a consistent pattern of its finding /essential/ errors that would have caused failure in the field. But if we can find that -- which I believe we cannot -- we have deeper problems, of course, because that sort of shit needs to be found mch, much sooner. At base, the IESG review seeks to compensate for seriously inadequate quality control during the development process... d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net
Re: Purpose of IESG Review
Reply to below message The subject SHOULD be: Evaluating Review Process Performance I prefer the Subject is: Evaluating WG input, the WG review process, and the WG output, NOT IESG review. Hi Joe, My comments mostly is on your message, but I comment also on I-Ds or RFCs related to IETF (including joky RFCs). I don't think it is write to evaluate the review of an IESG as long as when we created the I-D and adopted it into IETF SYSTEM, it is already agreeing on the methods of process that I-D is going through. So the problem is to evaluate three things not one: 1) the input, 2) the process review, 3) the output. We may make different input methods that go to another body than IESG, but if you decided to make I-D under IETF current procedure, it will have to go to IESG. I think the IESG are doing an excellent job, but it is best them to evaluate their performance not the community. Or it is better to find a body that evaluates the IESG performance not on this list. I consider your input on the list as a complain about the process, so I ask you to notice that your input has an error that needs evaluation befor going to process evaluation. You may evaluate output, but I remind you to evaluate input of WGs and inputs of individuals. I think the BIG problem of delay in I-Ds or RFC, is the cause of the WG not the IESG, if you do an excellent WG processes you will get quick results at IESG. AB + Hi, all, As an author who has had (and has) multiple documents in IESG review, I've noticed an increasing trend of this step to go beyond (IMO) its documented and original intent (BCP 9, currently RFC 2026): The IESG shall determine whether or not a specification submitted to it according to section 6.1.1 satisfies the applicable criteria for the recommended action (see sections 4.1 and 4.2), and shall in addition determine whether or not the technical quality and clarity of the specification is consistent with that expected for the maturity level to which the specification is recommended. Although I appreciate that IESG members are often overloaded, and the IESG Review step is often the first time many see these documents, I believe they should be expected to more clearly differentiate their "IESG Review" (based on the above criteria) - and its accompanying Position ballot, with their personal review. My concern is that by conflating their IESG position with their personal review, the document process is inappropriately delayed and that documents are modified to appease a small community that does not justify its position as representative. How do others feel about this? Joe
Re: Purpose of IESG Review
Seeing randomly selected drafts as a Gen-ART reviewer, I can say that serious defects quite often survive WG review and sometimes survive IETF Last Call review, so the final review by the IESG does serve a purpose. IMHO, if the IESG members sticks to their own criteria at http://www.ietf.org/iesg/statement/discuss-criteria.html, i.e. do not DISCUSS a document for spurious reasons, they are doing just fine. If they don't stick to those criteria, complaint is justified. Of course this will always be a matter of judgment. Regards Brian On 11/04/2013 18:54, Joe Touch wrote: > Hi, all, > > As an author who has had (and has) multiple documents in IESG review, > I've noticed an increasing trend of this step to go beyond (IMO) its > documented and original intent (BCP 9, currently RFC 2026): > >The IESG shall determine whether or not a specification submitted to >it according to section 6.1.1 satisfies the applicable criteria for >the recommended action (see sections 4.1 and 4.2), and shall in >addition determine whether or not the technical quality and clarity >of the specification is consistent with that expected for the >maturity level to which the specification is recommended. > > Although I appreciate that IESG members are often overloaded, and the > IESG Review step is often the first time many see these documents, I > believe they should be expected to more clearly differentiate their > "IESG Review" (based on the above criteria) - and its accompanying > Position ballot, with their personal review. > > My concern is that by conflating their IESG position with their personal > review, the document process is inappropriately delayed and that > documents are modified to appease a small community that does not > justify its position as representative. > > How do others feel about this? > > Joe >
Re: Purpose of IESG Review
Fred Baker (fred) wrote: > > Also, in my opinion, IESG review that raises a certain number of issues > should not result in the document sitting in the IESG's queue for a > few months while the authors go back and forth with the AD or the > GEN-ART reviewer pounding the document into someone's idea of "shape" > without working group involvement. I personally would prefer that > simple matters get sorted out between the ADs and the author, but > complex changes or additional content requested by the AD should > result in the document being sent back to the working group. This is pretty much the call of Working Group Chairs, so perhaps you should ask WGCs what they intend to do -- I don't think an IETF-wide policy would work well here. Note also that when this is done, it seems to reinforce the attitude that "We should humor the IESG!" (Even so, I personally prefer to hear about such changes. ;^) -- John Leslie
Re: Purpose of IESG Review
In my opinion, some individual ADs seem to, from their behavior, feel that they have not done their jobs unless they have raised a "discuss". The one that took the cake for me personally was a "discuss" raised by a particular AD (who shall remain nameless) that in essence wondered what he should raise a "discuss" about in my document. There were a couple of errors in that; he told me later that what he had done was opened the comment tool and typed that question, and subsequently accidentally hit the equivalent of "send" - the question wasn't intended to go out. But the question itself is telling: the issue was not "does the document meet the requirements of BCP 9", it was "what comment shall I raise"? Also, in my opinion, IESG review that raises a certain number of issues should not result in the document sitting in the IESG's queue for a few months while the authors go back and forth with the AD or the GEN-ART reviewer pounding the document into someone's idea of "shape" without working group involvement. I personally would prefer that simple matters get sorted out between the ADs and the author, but complex changes or additional content requested by the AD should result in the document being sent back to the working group.
Re: Purpose of IESG Review
On 4/11/2013 11:55 AM, Paul Hoffman wrote: On Apr 11, 2013, at 10:54 AM, Joe Touch wrote: As an author who has had (and has) multiple documents in IESG review, I've noticed an increasing trend of this step to go beyond (IMO) its documented and original intent (BCP 9, currently RFC 2026): The IESG shall determine whether or not a specification submitted to it according to section 6.1.1 satisfies the applicable criteria for the recommended action (see sections 4.1 and 4.2), and shall in addition determine whether or not the technical quality and clarity of the specification is consistent with that expected for the maturity level to which the specification is recommended. Although I appreciate that IESG members are often overloaded, and the IESG Review step is often the first time many see these documents, I believe they should be expected to more clearly differentiate their "IESG Review" (based on the above criteria) - and its accompanying Position ballot, with their personal review. My concern is that by conflating their IESG position with their personal review, the document process is inappropriately delayed and that documents are modified to appease a small community that does not justify its position as representative. How do others feel about this? That it is too vague to comment on? Please point to specific examples where you feel an IESG member's review went beyond determining the technical quality or clarity of the specification. That would help make the sure-to-be ensuing flamefest more light-filled. I've already done that within the IESG; the point of the message wasn't to have dozens of opinions of whether my feedback was beyond scope, but whether others were getting that feeling as well. At least first... Joe
RE: Purpose of IESG Review
And that should, of course, have read "Hi Lloyd" Sorry about that, Lloyd. The rest of the message still stands. Adrian > -Original Message- > From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Adrian > Farrel > Sent: 11 April 2013 22:18 > To: l.w...@surrey.ac.uk > Cc: ietf@ietf.org > Subject: RE: Purpose of IESG Review > > Hi Ian, > > Examples are useful because they give the IESG something to chew on. If you > don't call us when we do "bad stuff" we might never know. > > Examples can be dangerous because we can rat-hole into the specific rather than > the general, but i would like to use your example as data point to get some more > information that can possibly be generalised. > > > Example: the existence of the extensibility bit in multipath tcp, which i > > understand came out of a review by the iesg member responsible for security. > > In that context, that would be outside the scope of any security review, and > the > > comments weren't raised in a personal capacity years earlier on the relevant > > mailing list. > > Do people believe that the extensibility bit should not have been added? > I.e., is it a dumb or unnecessary thing that was forced on the community by the > IESG? > Maybe it is "harmless" so everyone said yes to get the document published. > Maybe the IESG had some "insight" suggesting that it was important to > future-proof the protocol even though the community didn't think it important. > Maybe it was a really cool idea that everyone missed. > > I'm not asking in order to have a fight about whether the AD was right or wrong. > But I would like to understand more about the impact of this type of "blocking" > Discuss. > > My point here is that sometimes it happens that ADs spot holes in protocols. In > those cases, I think we could live with publishing the RFCs and fixing them > later, but it is on the whole better to fix the issues at the time they are > spotted rather than later. The problem comes that an AD (especially out of > expertise) cannot tell between "I think there might be a problem here" and "I > know this is a serious bug". > > I believe that the clue is in the word "Discuss" and I hope that I (at least) am > willing to listen when the response is "we thought about it, it's not a big > problem." Perhaps people will tell me I am not so good at listening! I know > other ADs also strive to that as an ideal, so perhaps we have something of a > communications breakdown... > > Discuss is not meant to mean "and you shall not move unless you do exactly what > I say." It should mean "Please help me to be happy about publishing this > document because what I really want is you to publish the best possible > document > as quickly as possible." > > Thanks, > Adrian > > > > > > > > > > Sure, getting past iesg only cost multipath tcp a bit. But iesg members > exceeding > > their bounds as reviewers and leaving a personal mark seems commonplace. > iesg > > members are there for expertise in their area and to provide that expertise in > > focused reviews, not to block until a protocol is redesigned to suit their > personal > > tastes. (That transport expertise is lacking on iesg last I looked and > everyone > > believes they're an expert in transport - 'hey, why can't we just turn off > udp > > checksums for sctp over udp? It's faster!' - another iesg redesign attempt > > overriding considered expertise of a workgroup - isn't helping here.) > > > > There are two examples I know of, off the top of my head, telated to transport > > because that's my area of interest. Can others provide further examples? > > > > Lloyd Wood > > http://sat-net.com/L.Wood/ > > > > > > > > From: ietf-boun...@ietf.org [ietf-boun...@ietf.org] On Behalf Of Paul > Hoffman > > [paul.hoff...@vpnc.org] > > Sent: 11 April 2013 19:55 > > To: Joe Touch > > Cc: IETF discussion list > > Subject: Re: Purpose of IESG Review > > > > On Apr 11, 2013, at 10:54 AM, Joe Touch wrote: > > > > > As an author who has had (and has) multiple documents in IESG review, I've > > noticed an increasing trend of this step to go beyond (IMO) its documented and > > original intent (BCP 9, currently RFC 2026): > > > > > > The IESG shall determine whether or not a specification submitted to > > > it according to section 6.1.1 satisfies the applicable cri
Re: Purpose of IESG Review
l.w...@surrey.ac.uk wrote: > > +1 to Joe's comment. > > Example: the existence of the extensibility bit in multipath tcp, > which i understand came out of a review by the iesg member responsible > for security. I assume you're talking RFC 6824. I recommend reading the Narrative Minutes of September 13th: http://www.ietf.org/iesg/minutes/2012/narrative-minutes-2012-09-13.html There were DISCUSSes from Stephen Farrell (Security), Barry Leiba (Applications), Robert Sparks (RAI), and Sean Turner (Security). Stephen Farrell did complain about a negotiation scheme that only allowed seven security algorithms; and asked "how you could practically extend this design for stronger cryptographic security". > In that context, that would be outside the scope of any security > review, Hardly! Those are exactly what I would hope for in a Security review. > and the comments weren't raised in a personal capacity years earlier > on the relevant mailing list. I'm not going to research that; but it seems hardly relevant... > Sure, getting past iesg only cost multipath tcp a bit. (which, BTW, I strongly endorse!) > But iesg members exceeding their bounds as reviewers and leaving a > personal mark seems commonplace. Perception is easily mistaken for reality. :^( But if you look at the datatracker history: http://datatracker.ietf.org/doc/draft-ietf-mptcp-multiaddressed/history/ you'll see that all four DISCUSSes were cleared by October 22. Considering that this document started life in June of 2010, and was a major enhancement of TCP, 40 days doesn't seem excessive, IMHO. > iesg members are there for expertise in their area and to provide that > expertise in focused reviews, Note that there's really a lot of overlap between areas: so "focused" may not be the right criterion. > not to block until a protocol is redesigned to suit their personal > tastes. I am told this used to happen. I have not experienced it in the five years I have been scribing. I really don't know how to change the perception -- but I strongly recommend referring to the Narrative Minutes. Hopefully that history will be preserved "forever". -- John Leslie
RE: Purpose of IESG Review
Hi Ian, Examples are useful because they give the IESG something to chew on. If you don't call us when we do "bad stuff" we might never know. Examples can be dangerous because we can rat-hole into the specific rather than the general, but i would like to use your example as data point to get some more information that can possibly be generalised. > Example: the existence of the extensibility bit in multipath tcp, which i > understand came out of a review by the iesg member responsible for security. > In that context, that would be outside the scope of any security review, and the > comments weren't raised in a personal capacity years earlier on the relevant > mailing list. Do people believe that the extensibility bit should not have been added? I.e., is it a dumb or unnecessary thing that was forced on the community by the IESG? Maybe it is "harmless" so everyone said yes to get the document published. Maybe the IESG had some "insight" suggesting that it was important to future-proof the protocol even though the community didn't think it important. Maybe it was a really cool idea that everyone missed. I'm not asking in order to have a fight about whether the AD was right or wrong. But I would like to understand more about the impact of this type of "blocking" Discuss. My point here is that sometimes it happens that ADs spot holes in protocols. In those cases, I think we could live with publishing the RFCs and fixing them later, but it is on the whole better to fix the issues at the time they are spotted rather than later. The problem comes that an AD (especially out of expertise) cannot tell between "I think there might be a problem here" and "I know this is a serious bug". I believe that the clue is in the word "Discuss" and I hope that I (at least) am willing to listen when the response is "we thought about it, it's not a big problem." Perhaps people will tell me I am not so good at listening! I know other ADs also strive to that as an ideal, so perhaps we have something of a communications breakdown... Discuss is not meant to mean "and you shall not move unless you do exactly what I say." It should mean "Please help me to be happy about publishing this document because what I really want is you to publish the best possible document as quickly as possible." Thanks, Adrian > > Sure, getting past iesg only cost multipath tcp a bit. But iesg members exceeding > their bounds as reviewers and leaving a personal mark seems commonplace. iesg > members are there for expertise in their area and to provide that expertise in > focused reviews, not to block until a protocol is redesigned to suit their personal > tastes. (That transport expertise is lacking on iesg last I looked and everyone > believes they're an expert in transport - 'hey, why can't we just turn off udp > checksums for sctp over udp? It's faster!' - another iesg redesign attempt > overriding considered expertise of a workgroup - isn't helping here.) > > There are two examples I know of, off the top of my head, telated to transport > because that's my area of interest. Can others provide further examples? > > Lloyd Wood > http://sat-net.com/L.Wood/ > > > ____________ > From: ietf-boun...@ietf.org [ietf-boun...@ietf.org] On Behalf Of Paul Hoffman > [paul.hoff...@vpnc.org] > Sent: 11 April 2013 19:55 > To: Joe Touch > Cc: IETF discussion list > Subject: Re: Purpose of IESG Review > > On Apr 11, 2013, at 10:54 AM, Joe Touch wrote: > > > As an author who has had (and has) multiple documents in IESG review, I've > noticed an increasing trend of this step to go beyond (IMO) its documented and > original intent (BCP 9, currently RFC 2026): > > > > The IESG shall determine whether or not a specification submitted to > > it according to section 6.1.1 satisfies the applicable criteria for > > the recommended action (see sections 4.1 and 4.2), and shall in > > addition determine whether or not the technical quality and clarity > > of the specification is consistent with that expected for the > > maturity level to which the specification is recommended. > > > > Although I appreciate that IESG members are often overloaded, and the IESG > Review step is often the first time many see these documents, I believe they > should be expected to more clearly differentiate their "IESG Review" (based on > the above criteria) - and its accompanying Position ballot, with their personal > review. > > > > My concern is that by conflating their IESG position with their personal review, > the document process is inappropriately delayed and that documents a
RE: Purpose of IESG Review
+1 to Joe's comment. Example: the existence of the extensibility bit in multipath tcp, which i understand came out of a review by the iesg member responsible for security. In that context, that would be outside the scope of any security review, and the comments weren't raised in a personal capacity years earlier on the relevant mailing list. Sure, getting past iesg only cost multipath tcp a bit. But iesg members exceeding their bounds as reviewers and leaving a personal mark seems commonplace. iesg members are there for expertise in their area and to provide that expertise in focused reviews, not to block until a protocol is redesigned to suit their personal tastes. (That transport expertise is lacking on iesg last I looked and everyone believes they're an expert in transport - 'hey, why can't we just turn off udp checksums for sctp over udp? It's faster!' - another iesg redesign attempt overriding considered expertise of a workgroup - isn't helping here.) There are two examples I know of, off the top of my head, telated to transport because that's my area of interest. Can others provide further examples? Lloyd Wood http://sat-net.com/L.Wood/ From: ietf-boun...@ietf.org [ietf-boun...@ietf.org] On Behalf Of Paul Hoffman [paul.hoff...@vpnc.org] Sent: 11 April 2013 19:55 To: Joe Touch Cc: IETF discussion list Subject: Re: Purpose of IESG Review On Apr 11, 2013, at 10:54 AM, Joe Touch wrote: > As an author who has had (and has) multiple documents in IESG review, I've > noticed an increasing trend of this step to go beyond (IMO) its documented > and original intent (BCP 9, currently RFC 2026): > > The IESG shall determine whether or not a specification submitted to > it according to section 6.1.1 satisfies the applicable criteria for > the recommended action (see sections 4.1 and 4.2), and shall in > addition determine whether or not the technical quality and clarity > of the specification is consistent with that expected for the > maturity level to which the specification is recommended. > > Although I appreciate that IESG members are often overloaded, and the IESG > Review step is often the first time many see these documents, I believe they > should be expected to more clearly differentiate their "IESG Review" (based > on the above criteria) - and its accompanying Position ballot, with their > personal review. > > My concern is that by conflating their IESG position with their personal > review, the document process is inappropriately delayed and that documents > are modified to appease a small community that does not justify its position > as representative. > > How do others feel about this? That it is too vague to comment on? Please point to specific examples where you feel an IESG member's review went beyond determining the technical quality or clarity of the specification. That would help make the sure-to-be ensuing flamefest more light-filled. --Paul Hoffman
Re: Purpose of IESG Review
On Apr 11, 2013, at 10:54 AM, Joe Touch wrote: > As an author who has had (and has) multiple documents in IESG review, I've > noticed an increasing trend of this step to go beyond (IMO) its documented > and original intent (BCP 9, currently RFC 2026): > > The IESG shall determine whether or not a specification submitted to > it according to section 6.1.1 satisfies the applicable criteria for > the recommended action (see sections 4.1 and 4.2), and shall in > addition determine whether or not the technical quality and clarity > of the specification is consistent with that expected for the > maturity level to which the specification is recommended. > > Although I appreciate that IESG members are often overloaded, and the IESG > Review step is often the first time many see these documents, I believe they > should be expected to more clearly differentiate their "IESG Review" (based > on the above criteria) - and its accompanying Position ballot, with their > personal review. > > My concern is that by conflating their IESG position with their personal > review, the document process is inappropriately delayed and that documents > are modified to appease a small community that does not justify its position > as representative. > > How do others feel about this? That it is too vague to comment on? Please point to specific examples where you feel an IESG member's review went beyond determining the technical quality or clarity of the specification. That would help make the sure-to-be ensuing flamefest more light-filled. --Paul Hoffman
Purpose of IESG Review
Hi, all, As an author who has had (and has) multiple documents in IESG review, I've noticed an increasing trend of this step to go beyond (IMO) its documented and original intent (BCP 9, currently RFC 2026): The IESG shall determine whether or not a specification submitted to it according to section 6.1.1 satisfies the applicable criteria for the recommended action (see sections 4.1 and 4.2), and shall in addition determine whether or not the technical quality and clarity of the specification is consistent with that expected for the maturity level to which the specification is recommended. Although I appreciate that IESG members are often overloaded, and the IESG Review step is often the first time many see these documents, I believe they should be expected to more clearly differentiate their "IESG Review" (based on the above criteria) - and its accompanying Position ballot, with their personal review. My concern is that by conflating their IESG position with their personal review, the document process is inappropriately delayed and that documents are modified to appease a small community that does not justify its position as representative. How do others feel about this? Joe
