From problem-statement-bounces@alvestrand.no Wed Oct 1 02:18:24 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA16983 for ; Wed, 1 Oct 2003 02:18:22 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 2D7F161BB3; Wed, 1 Oct 2003 08:17:56 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from psg.com (psg.com [147.28.0.62]) by eikenes.alvestrand.no (Postfix) with ESMTP id D384661BAE for ; Wed, 1 Oct 2003 08:17:53 +0200 (CEST) Received: from [147.28.0.62] (helo=acm.org) by psg.com with esmtp (Exim 4.22) id 1A4aJ5-0002eY-BF for problem-statement@alvestrand.no; Wed, 01 Oct 2003 06:17:52 +0000 Date: Wed, 1 Oct 2003 15:16:28 +0900 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Mime-Version: 1.0 (Apple Message framework v552) From: Avri Doria To: problem-statement@alvestrand.no Content-Transfer-Encoding: quoted-printable In-Reply-To: Message-Id: X-Mailer: Apple Mail (2.552) Subject: Re: An overview of where the IETF change process is currently at X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: quoted-printable On m=E5ndag, sep 29, 2003, at 00:46 Asia/Seoul, Melinda Shore wrote: > Avri and I need to talk some more > about how to break the logjam but one thing that concerns me a > great deal is how we're going to be able to come to consensus > when there's strong opposition to pretty much every option that's > been put forward. One thing we have discussed is that it may > be useful to identify the characteristics that the process itself > needs to have. As one of the proponents of one of the process proposals, I figured I=20 should take a first attempt at giving the reasoning I used while=20 participating in the creation of that proposal. Some of the discussion=20= about that proposal have concerned it being over-engineered. While I=20 cannot argue against that impression specifically, I do think that the=20= details of that proposal came from a concept of what was required in=20 such a process. I believe one deficiency in that proposal is that we=20 did not include an analysis of the requirements for the process. Note: this note is purely personal opinion and _not_ a WG co-chair=20 opinion. It also does not necessarily reflect the opinions of my two=20 co-authors who may have had different motivations. The proposal was a=20= compromise of our different points of view. This is mine. - transparency: (rapidly becoming an overused term) I think that any=20 process to respond to the issues in the problem statement especially in=20= the response could result in recommendations for structural change=20 should be done in a way that allows for intense community scrutiny. - public participation: I think that the community should not only be=20 allowed to watch the process, but should have the maximum possible=20 ability to contribute to that process. - public accountability: Those who presume to take the communities=20 opinions and mold them into a proposal should be accountable to that=20 community. The IETF should know who is making recommendations and who=20= is making decsions. And the future roles of those individuals within=20 the IETF should take the way they perform these tasks into account. - rapid movement toward resolution: I think that many in the IETF=20 community are running out of patience. Now that the problem=20 description is nearly complete, resolution should be rapid. This does=20= not mean it should be rushed, but there should be a reasonable schedule=20= that is adhered to strictly. - significant and balanced representation for those who currently have=20= the I* responsibility: I think it is important that those people who=20 have been chosen as the IETF's governing team should have a voice in=20 any recommendation. Not only does the IESG, and possibly the ISOC,=20 need to approve the decisions, the IESG and the IAB would be=20 responsible for carrying out any of the recommended changes that were=20 approved. Further, I think it would a serious problem if the I* was=20 caught by surprise by any of the recommendations. - majority representation for the community at large: I think it is=20 critical that the community at large have serious representation in the=20= process of making the recommendation. Thus I think that non officials=20= of the IETF community should be the majority of the group. - a fair selection procedure for choosing those from the community at=20 large needs to be chosen - non prejudicial method for choosing a chair: given the number of=20 different interests involved in making the recommendation, it seemed=20 reasonable that the participants in the process itself pick the person=20= they wanted to coordinate the functioning of the team. and if they are=20= not happy with that chair, they should be able to reassign it. - use of processes already understood: Instead of inventing new ways=20 of doing things, I felt that it would be best to borrow from techniques=20= already in use in the IETF. Therefore the proposal uses variants of=20 familiar methods, albeit it different combinations: -- the entire team makes a recommendation to the ADs similar to the way=20= directorates do -- the chair is chosen in the same way as the chair of the IAB -- the community representatives are chosen in a method similar to the=20= nomcom process. -- recommendations come in from the community and are distilled by a=20 smaller group similar to the way a design team functions. These=20 recommendations are reviewed by the IETF community at large before=20 being sent on to the IESG. Again similar to a working group, although=20= a very large one. - The final decision belongs to the IESG as the appointed=20 representatives of the community at large. The proposal was made in the spirit of trying to move the WG chartered=20= work along to completion. My assumption was that the quickest way to=20 resolve the issue was to have a proposal that could be discussed and=20 modified. And while it is true that the IESG is empowered to decide on=20= a process before this group reaches consensus, I felt that there was a=20= possibility that they might not (for any number of possible reasons),=20 or that if they did they might use some variant of this proposal or of=20= other proposals that might be discussed in the WG. I hope that a discussion of how people think the process should be run=20= can help us move away from the deadlock we are currently experiencing. thanks a. From problem-statement-bounces@alvestrand.no Wed Oct 1 11:18:17 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17590 for ; Wed, 1 Oct 2003 11:18:16 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id E80FD61BB5; Wed, 1 Oct 2003 17:17:50 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by eikenes.alvestrand.no (Postfix) with ESMTP id 202EA61B91 for ; Wed, 1 Oct 2003 17:17:49 +0200 (CEST) Message-ID: <005201c3882f$354635a0$956015ac@dclkempt40> From: "James Kempf" To: "Avri Doria" , References: Date: Wed, 1 Oct 2003 08:18:01 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Subject: Re: An overview of where the IETF change process is currently at X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 8bit Avri, You've fairly clearly articulated how you want to see community participants chosen, but you've suggested nothing about how I* participants might be chosen. Pursuing the analogy with NomCom, do you feel that the I* participants should be chosen and should view their roles as similar to the I* NomCom representatives? Or do you feel that they should be more active participants? jak ----- Original Message ----- From: "Avri Doria" To: Sent: Tuesday, September 30, 2003 11:16 PM Subject: Re: An overview of where the IETF change process is currently at > > On måndag, sep 29, 2003, at 00:46 Asia/Seoul, Melinda Shore wrote: > > > Avri and I need to talk some more > > about how to break the logjam but one thing that concerns me a > > great deal is how we're going to be able to come to consensus > > when there's strong opposition to pretty much every option that's > > been put forward. One thing we have discussed is that it may > > be useful to identify the characteristics that the process itself > > needs to have. > > As one of the proponents of one of the process proposals, I figured I > should take a first attempt at giving the reasoning I used while > participating in the creation of that proposal. Some of the discussion > about that proposal have concerned it being over-engineered. While I > cannot argue against that impression specifically, I do think that the > details of that proposal came from a concept of what was required in > such a process. I believe one deficiency in that proposal is that we > did not include an analysis of the requirements for the process. > > Note: this note is purely personal opinion and _not_ a WG co-chair > opinion. It also does not necessarily reflect the opinions of my two > co-authors who may have had different motivations. The proposal was a > compromise of our different points of view. This is mine. > > - transparency: (rapidly becoming an overused term) I think that any > process to respond to the issues in the problem statement especially in > the response could result in recommendations for structural change > should be done in a way that allows for intense community scrutiny. > > - public participation: I think that the community should not only be > allowed to watch the process, but should have the maximum possible > ability to contribute to that process. > > - public accountability: Those who presume to take the communities > opinions and mold them into a proposal should be accountable to that > community. The IETF should know who is making recommendations and who > is making decsions. And the future roles of those individuals within > the IETF should take the way they perform these tasks into account. > > - rapid movement toward resolution: I think that many in the IETF > community are running out of patience. Now that the problem > description is nearly complete, resolution should be rapid. This does > not mean it should be rushed, but there should be a reasonable schedule > that is adhered to strictly. > > - significant and balanced representation for those who currently have > the I* responsibility: I think it is important that those people who > have been chosen as the IETF's governing team should have a voice in > any recommendation. Not only does the IESG, and possibly the ISOC, > need to approve the decisions, the IESG and the IAB would be > responsible for carrying out any of the recommended changes that were > approved. Further, I think it would a serious problem if the I* was > caught by surprise by any of the recommendations. > > - majority representation for the community at large: I think it is > critical that the community at large have serious representation in the > process of making the recommendation. Thus I think that non officials > of the IETF community should be the majority of the group. > > - a fair selection procedure for choosing those from the community at > large needs to be chosen > > - non prejudicial method for choosing a chair: given the number of > different interests involved in making the recommendation, it seemed > reasonable that the participants in the process itself pick the person > they wanted to coordinate the functioning of the team. and if they are > not happy with that chair, they should be able to reassign it. > > - use of processes already understood: Instead of inventing new ways > of doing things, I felt that it would be best to borrow from techniques > already in use in the IETF. Therefore the proposal uses variants of > familiar methods, albeit it different combinations: > -- the entire team makes a recommendation to the ADs similar to the way > directorates do > -- the chair is chosen in the same way as the chair of the IAB > -- the community representatives are chosen in a method similar to the > nomcom process. > -- recommendations come in from the community and are distilled by a > smaller group similar to the way a design team functions. These > recommendations are reviewed by the IETF community at large before > being sent on to the IESG. Again similar to a working group, although > a very large one. > > - The final decision belongs to the IESG as the appointed > representatives of the community at large. > > The proposal was made in the spirit of trying to move the WG chartered > work along to completion. My assumption was that the quickest way to > resolve the issue was to have a proposal that could be discussed and > modified. And while it is true that the IESG is empowered to decide on > a process before this group reaches consensus, I felt that there was a > possibility that they might not (for any number of possible reasons), > or that if they did they might use some variant of this proposal or of > other proposals that might be discussed in the WG. > > I hope that a discussion of how people think the process should be run > can help us move away from the deadlock we are currently experiencing. > > thanks > a. > > > From problem-statement-bounces@alvestrand.no Wed Oct 1 11:31:12 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19225 for ; Wed, 1 Oct 2003 11:31:05 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 19C1061BB5; Wed, 1 Oct 2003 17:30:39 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from znsgs01r.nortelnetworks.com (h12s128a211n47.user.nortelnetworks.com [47.211.128.12]) by eikenes.alvestrand.no (Postfix) with ESMTP id A8F0461B91 for ; Wed, 1 Oct 2003 17:30:36 +0200 (CEST) Received: from zwcwc012.europe.nortel.com (zwcwc012.europe.nortel.com [47.160.46.124]) by znsgs01r.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h91FUM729949; Wed, 1 Oct 2003 16:30:22 +0100 (BST) Received: by zwcwc012.europe.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 1 Oct 2003 16:30:22 +0100 Message-ID: <4103264BC8D3D51180B7002048400C4501623827@zhard0jd.europe.nortel.com> From: "Elwyn Davies" To: "'James Kempf'" , Avri Doria , problem-statement@alvestrand.no Date: Wed, 1 Oct 2003 16:30:18 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C38830.EB69FB68" Subject: RE: An overview of where the IETF change process is currently at X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C38830.EB69FB68 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable When the authors of the proposal thought about this, the idea was that = the I* members would be full and active participants in the process (rether = than observers as in NomCom), and that they were to be delegated by the I* = from amongst their number. The relative sizes of the groups of participants was carefully chosen = to give full weight to the views of the I* members but without giving them = a dominant position, and without making the group too unwieldy (some = people think it is already too big). The document says nothing about whether = the I* would give any particular mandate to their representatives or allow = them free rein to exercise their best judgement. Regards, Elwyn > -----Original Message----- > From: James Kempf [mailto:kempf@docomolabs-usa.com]=20 > Sent: 01 October 2003 16:18 > To: Avri Doria; problem-statement@alvestrand.no > Subject: Re: An overview of where the IETF change process is=20 > currently at >=20 >=20 > Avri, >=20 > You've fairly clearly articulated how you want to see=20 > community participants > chosen, but you've suggested nothing about how I*=20 > participants might be > chosen. Pursuing the analogy with NomCom, do you feel that the I* > participants should be chosen and should view their roles as=20 > similar to the > I* NomCom representatives? Or do you feel that they should be=20 > more active > participants? >=20 > jak >=20 > ----- Original Message -----=20 > From: "Avri Doria" > To: > Sent: Tuesday, September 30, 2003 11:16 PM > Subject: Re: An overview of where the IETF change process is=20 > currently at >=20 >=20 > > > > On m=E5ndag, sep 29, 2003, at 00:46 Asia/Seoul, Melinda Shore = wrote: > > > > > Avri and I need to talk some more > > > about how to break the logjam but one thing that concerns me a > > > great deal is how we're going to be able to come to consensus > > > when there's strong opposition to pretty much every option that's > > > been put forward. One thing we have discussed is that it may > > > be useful to identify the characteristics that the process itself > > > needs to have. > > > > As one of the proponents of one of the process proposals, I=20 > figured I > > should take a first attempt at giving the reasoning I used while > > participating in the creation of that proposal. Some of=20 > the discussion > > about that proposal have concerned it being=20 > over-engineered. While I > > cannot argue against that impression specifically, I do=20 > think that the > > details of that proposal came from a concept of what was required = in > > such a process. I believe one deficiency in that proposal=20 > is that we > > did not include an analysis of the requirements for the process. > > > > Note: this note is purely personal opinion and _not_ a WG co-chair > > opinion. It also does not necessarily reflect the opinions=20 > of my two > > co-authors who may have had different motivations. The=20 > proposal was a > > compromise of our different points of view. This is mine. > > > > - transparency: (rapidly becoming an overused term) I think that = any > > process to respond to the issues in the problem statement=20 > especially in > > the response could result in recommendations for structural change > > should be done in a way that allows for intense community scrutiny. > > > > - public participation: I think that the community should=20 > not only be > > allowed to watch the process, but should have the maximum possible > > ability to contribute to that process. > > > > - public accountability: Those who presume to take the = communities > > opinions and mold them into a proposal should be accountable to = that > > community. The IETF should know who is making=20 > recommendations and who > > is making decsions. And the future roles of those=20 > individuals within > > the IETF should take the way they perform these tasks into account. > > > > - rapid movement toward resolution: I think that many in the IETF > > community are running out of patience. Now that the problem > > description is nearly complete, resolution should be rapid.=20 > This does > > not mean it should be rushed, but there should be a=20 > reasonable schedule > > that is adhered to strictly. > > > > - significant and balanced representation for those who=20 > currently have > > the I* responsibility: I think it is important that those=20 > people who > > have been chosen as the IETF's governing team should have a voice = in > > any recommendation. Not only does the IESG, and possibly the ISOC, > > need to approve the decisions, the IESG and the IAB would be > > responsible for carrying out any of the recommended changes=20 > that were > > approved. Further, I think it would a serious problem if the I* = was > > caught by surprise by any of the recommendations. > > > > - majority representation for the community at large: I think it = is > > critical that the community at large have serious=20 > representation in the > > process of making the recommendation. Thus I think that=20 > non officials > > of the IETF community should be the majority of the group. > > > > - a fair selection procedure for choosing those from the=20 > community at > > large needs to be chosen > > > > - non prejudicial method for choosing a chair: given the number of > > different interests involved in making the recommendation, it = seemed > > reasonable that the participants in the process itself pick=20 > the person > > they wanted to coordinate the functioning of the team. and=20 > if they are > > not happy with that chair, they should be able to reassign it. > > > > - use of processes already understood: Instead of=20 > inventing new ways > > of doing things, I felt that it would be best to borrow=20 > from techniques > > already in use in the IETF. Therefore the proposal uses variants = of > > familiar methods, albeit it different combinations: > > -- the entire team makes a recommendation to the ADs=20 > similar to the way > > directorates do > > -- the chair is chosen in the same way as the chair of the IAB > > -- the community representatives are chosen in a method=20 > similar to the > > nomcom process. > > -- recommendations come in from the community and are distilled by = a > > smaller group similar to the way a design team functions. These > > recommendations are reviewed by the IETF community at large before > > being sent on to the IESG. Again similar to a working=20 > group, although > > a very large one. > > > > - The final decision belongs to the IESG as the appointed > > representatives of the community at large. > > > > The proposal was made in the spirit of trying to move the=20 > WG chartered > > work along to completion. My assumption was that the=20 > quickest way to > > resolve the issue was to have a proposal that could be discussed = and > > modified. And while it is true that the IESG is empowered=20 > to decide on > > a process before this group reaches consensus, I felt that=20 > there was a > > possibility that they might not (for any number of possible=20 > reasons), > > or that if they did they might use some variant of this=20 > proposal or of > > other proposals that might be discussed in the WG. > > > > I hope that a discussion of how people think the process=20 > should be run > > can help us move away from the deadlock we are currently=20 > experiencing. > > > > thanks > > a. > > > > > > >=20 >=20 ------_=_NextPart_001_01C38830.EB69FB68 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable RE: An overview of where the IETF change process is currently = at

When the authors of the proposal thought about this, = the idea was that the I* members would be full and active participants = in the process (rether than observers as in NomCom), and that they were = to be delegated by the I* from amongst their number.

The relative sizes of the groups of participants was = carefully chosen to give full weight to the views of the I* members but = without giving them a dominant position, and without making the group = too unwieldy (some people think it is already too big).  The = document says nothing about whether the I* would give any particular = mandate to their representatives or allow them free rein to exercise = their best judgement.

Regards,
Elwyn

> -----Original Message-----
> From: James Kempf [mailto:kempf@docomolabs-usa.com= ]
> Sent: 01 October 2003 16:18
> To: Avri Doria; = problem-statement@alvestrand.no
> Subject: Re: An overview of where the IETF = change process is
> currently at
>
>
> Avri,
>
> You've fairly clearly articulated how you want = to see
> community participants
> chosen, but you've suggested nothing about how = I*
> participants might be
> chosen. Pursuing the analogy with NomCom, do = you feel that the I*
> participants should be chosen and should view = their roles as
> similar to the
> I* NomCom representatives? Or do you feel that = they should be
> more active
> participants?
>
>          = ;   jak
>
> ----- Original Message -----
> From: "Avri Doria" = <avri@acm.org>
> To: = <problem-statement@alvestrand.no>
> Sent: Tuesday, September 30, 2003 11:16 = PM
> Subject: Re: An overview of where the IETF = change process is
> currently at
>
>
> >
> > On m=E5ndag, sep 29, 2003, at 00:46 = Asia/Seoul, Melinda Shore wrote:
> >
> > > Avri and I need to talk some = more
> > > about how to break the logjam but one = thing that concerns me a
> > > great deal is how we're going to be = able to come to consensus
> > > when there's strong opposition to = pretty much every option that's
> > > been put forward.  One thing we = have discussed is that it may
> > > be useful to identify the = characteristics that the process itself
> > > needs to have.
> >
> > As one of the proponents of one of the = process proposals, I
> figured I
> > should take a first attempt at giving the = reasoning I used while
> > participating in the creation of that = proposal.  Some of
> the discussion
> > about that proposal have concerned it = being
> over-engineered.  While I
> > cannot argue against that impression = specifically, I do
> think that the
> > details of that proposal came from a = concept of what was required in
> > such a process.  I believe one = deficiency in that proposal
> is that we
> > did not include an analysis of the = requirements for the process.
> >
> > Note: this note is purely personal opinion = and _not_ a WG co-chair
> > opinion.  It also does not = necessarily reflect the opinions
> of my two
> > co-authors who may have had different = motivations.  The
> proposal was a
> > compromise of our different points of = view.   This is mine.
> >
> > - transparency: (rapidly becoming an = overused term) I think that any
> > process to respond to the issues in the = problem statement
> especially in
> > the response could result in = recommendations for structural change
> > should be done in a way that allows for = intense community scrutiny.
> >
> > - public participation: I think that the = community should
> not only be
> > allowed to watch the process, but should = have the maximum possible
> > ability to contribute to that = process.
> >
> > - public accountability:   Those = who presume to take the communities
> > opinions and mold them into a proposal = should be accountable to that
> > community.  The IETF should know who = is making
> recommendations and who
> > is making decsions.  And the future = roles of those
> individuals within
> > the IETF should take the way they perform = these tasks into account.
> >
> > - rapid movement toward resolution:  = I think that many in the IETF
> > community are running out of = patience.  Now that the problem
> > description is nearly complete, resolution = should be rapid.
>  This does
> > not mean it should be rushed, but there = should be a
> reasonable schedule
> > that is adhered to strictly.
> >
> > - significant and balanced representation = for those who
> currently have
> > the I* responsibility:  I think it is = important that those
> people who
> > have been chosen as the IETF's governing = team should have a voice in
> > any recommendation.  Not only does = the IESG, and possibly the ISOC,
> > need to approve the decisions,  the = IESG and the IAB would be
> > responsible for carrying out any of the = recommended changes
> that were
> > approved.  Further, I think it would = a serious problem if the I* was
> > caught by surprise by any of the = recommendations.
> >
> > - majority representation for the = community at large:  I think it is
> > critical that the community at large have = serious
> representation in the
> > process of making the = recommendation.  Thus I think that
> non officials
> > of the IETF community should be the = majority of the group.
> >
> > - a fair selection procedure for choosing = those from the
> community at
> > large needs to be chosen
> >
> > - non prejudicial method for choosing a = chair: given the number of
> > different interests involved in making the = recommendation, it seemed
> > reasonable that the participants in the = process itself pick
> the person
> > they wanted to coordinate the functioning = of the team.  and
> if they are
> > not happy with that chair, they should be = able to reassign it.
> >
> > - use of processes already = understood:  Instead of
> inventing new ways
> > of doing things, I felt that it would be = best to borrow
> from techniques
> > already in use in the IETF.  = Therefore the proposal uses variants of
> > familiar methods, albeit it different = combinations:
> > -- the entire team makes a recommendation = to the ADs
> similar to the way
> > directorates do
> > -- the chair is chosen in the same way as = the chair of the IAB
> > -- the community representatives are = chosen in a method
> similar to the
> > nomcom process.
> > -- recommendations come in from the = community and are distilled by a
> > smaller group similar to the way a design = team functions.  These
> > recommendations are reviewed by the IETF = community at large before
> > being sent on to the IESG.  Again = similar to a working
> group, although
> > a very large one.
> >
> > - The final decision belongs to the IESG = as the appointed
> > representatives of the community at = large.
> >
> > The proposal was made in the spirit of = trying to move the
> WG chartered
> > work along to completion.  My = assumption was that the
> quickest way to
> > resolve the issue was to have a proposal = that could be discussed and
> > modified.  And while it is true that = the IESG is empowered
> to decide on
> > a process before this group reaches = consensus, I felt that
> there was a
> > possibility that they might not (for any = number of possible
> reasons),
> > or that if they did they might use some = variant of this
> proposal or of
> > other proposals that might be discussed in = the WG.
> >
> > I hope that a discussion of how people = think the process
> should be run
> > can help us move away from the deadlock we = are currently
> experiencing.
> >
> > thanks
> > a.
> >
> >
> >
>
>

------_=_NextPart_001_01C38830.EB69FB68-- From problem-statement-bounces@alvestrand.no Wed Oct 1 11:35:45 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19687 for ; Wed, 1 Oct 2003 11:35:44 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 5EAC961BB5; Wed, 1 Oct 2003 17:35:19 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from psg.com (psg.com [147.28.0.62]) by eikenes.alvestrand.no (Postfix) with ESMTP id 196BC61B8D for ; Wed, 1 Oct 2003 17:35:18 +0200 (CEST) Received: from [147.28.0.62] (helo=acm.org) by psg.com with esmtp (Exim 4.22) id 1A4j0W-000KMa-PN for problem-statement@alvestrand.no; Wed, 01 Oct 2003 15:35:17 +0000 Date: Thu, 2 Oct 2003 00:34:40 +0900 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) From: Avri Doria To: problem-statement@alvestrand.no Content-Transfer-Encoding: 7bit In-Reply-To: <005201c3882f$354635a0$956015ac@dclkempt40> Message-Id: X-Mailer: Apple Mail (2.552) Subject: Re: An overview of where the IETF change process is currently at X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit On torsdag, okt 2, 2003, at 00:18 Asia/Seoul, James Kempf wrote: > Avri, > > You've fairly clearly articulated how you want to see community > participants > chosen, but you've suggested nothing about how I* participants might be > chosen. Pursuing the analogy with NomCom, do you feel that the I* > participants should be chosen and should view their roles as similar > to the > I* NomCom representatives? Or do you feel that they should be more > active > participants? > > jak > > I tend to think of them as full and equal participants though they also would represent their respective group's interests. in terms of picking them, i think that would best be left to the bodies they are members of. a. From problem-statement-bounces@alvestrand.no Wed Oct 1 11:48:44 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20272 for ; Wed, 1 Oct 2003 11:48:43 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id D13B561BDF; Wed, 1 Oct 2003 17:48:18 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by eikenes.alvestrand.no (Postfix) with ESMTP id ED58061BDC for ; Wed, 1 Oct 2003 17:48:16 +0200 (CEST) Message-ID: <012501c38833$76ec8eb0$956015ac@dclkempt40> From: "James Kempf" To: "Elwyn Davies" , "Avri Doria" , References: <4103264BC8D3D51180B7002048400C4501623827@zhard0jd.europe.nortel.com> Date: Wed, 1 Oct 2003 08:48:30 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Subject: Re: An overview of where the IETF change process is currently at X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 8bit Typically, the IAB doesn't make an official "IAB" statement unless there is concensus among its members, and I assume the IESG does the same. So any representatives from the IAB to the group would not be empowered to speak for the entire IAB. They would, as for any IETF participant, be speaking as individuals when giving an opinion in real time. Given that, I'm not sure how active an I* presence you are likely to get in the process unless all of the I* are involved, which just isn't practical. I think a more practical scenario is to view any I* participants as somewhat more active than the NomCom liasons, but not representing any I* opinion in real time. That is, they would have to go back to their respective I* and discuss any matter that might come up where an I* opinion might be desirable or necessary, then bring it back to the group. What I am trying to say is that any I* participant would not be empowered to represent the I* as a whole, at least, if the I* continue with present practice. Present practice could, of course, be changed, but requiring concensus is a very strong custom and I think it would be difficult to change (in addition to any changes having their own downsides). I hope any other I* (especially IESG) will speak up if they feel I've missed something here. jak ----- Original Message ----- From: "Elwyn Davies" To: "'James Kempf'" ; "Avri Doria" ; Sent: Wednesday, October 01, 2003 8:30 AM Subject: RE: An overview of where the IETF change process is currently at When the authors of the proposal thought about this, the idea was that the I* members would be full and active participants in the process (rether than observers as in NomCom), and that they were to be delegated by the I* from amongst their number. The relative sizes of the groups of participants was carefully chosen to give full weight to the views of the I* members but without giving them a dominant position, and without making the group too unwieldy (some people think it is already too big). The document says nothing about whether the I* would give any particular mandate to their representatives or allow them free rein to exercise their best judgement. Regards, Elwyn > -----Original Message----- > From: James Kempf [mailto:kempf@docomolabs-usa.com] > Sent: 01 October 2003 16:18 > To: Avri Doria; problem-statement@alvestrand.no > Subject: Re: An overview of where the IETF change process is > currently at > > > Avri, > > You've fairly clearly articulated how you want to see > community participants > chosen, but you've suggested nothing about how I* > participants might be > chosen. Pursuing the analogy with NomCom, do you feel that the I* > participants should be chosen and should view their roles as > similar to the > I* NomCom representatives? Or do you feel that they should be > more active > participants? > > jak > > ----- Original Message ----- > From: "Avri Doria" > To: > Sent: Tuesday, September 30, 2003 11:16 PM > Subject: Re: An overview of where the IETF change process is > currently at > > > > > > On måndag, sep 29, 2003, at 00:46 Asia/Seoul, Melinda Shore wrote: > > > > > Avri and I need to talk some more > > > about how to break the logjam but one thing that concerns me a > > > great deal is how we're going to be able to come to consensus > > > when there's strong opposition to pretty much every option that's > > > been put forward. One thing we have discussed is that it may > > > be useful to identify the characteristics that the process itself > > > needs to have. > > > > As one of the proponents of one of the process proposals, I > figured I > > should take a first attempt at giving the reasoning I used while > > participating in the creation of that proposal. Some of > the discussion > > about that proposal have concerned it being > over-engineered. While I > > cannot argue against that impression specifically, I do > think that the > > details of that proposal came from a concept of what was required in > > such a process. I believe one deficiency in that proposal > is that we > > did not include an analysis of the requirements for the process. > > > > Note: this note is purely personal opinion and _not_ a WG co-chair > > opinion. It also does not necessarily reflect the opinions > of my two > > co-authors who may have had different motivations. The > proposal was a > > compromise of our different points of view. This is mine. > > > > - transparency: (rapidly becoming an overused term) I think that any > > process to respond to the issues in the problem statement > especially in > > the response could result in recommendations for structural change > > should be done in a way that allows for intense community scrutiny. > > > > - public participation: I think that the community should > not only be > > allowed to watch the process, but should have the maximum possible > > ability to contribute to that process. > > > > - public accountability: Those who presume to take the communities > > opinions and mold them into a proposal should be accountable to that > > community. The IETF should know who is making > recommendations and who > > is making decsions. And the future roles of those > individuals within > > the IETF should take the way they perform these tasks into account. > > > > - rapid movement toward resolution: I think that many in the IETF > > community are running out of patience. Now that the problem > > description is nearly complete, resolution should be rapid. > This does > > not mean it should be rushed, but there should be a > reasonable schedule > > that is adhered to strictly. > > > > - significant and balanced representation for those who > currently have > > the I* responsibility: I think it is important that those > people who > > have been chosen as the IETF's governing team should have a voice in > > any recommendation. Not only does the IESG, and possibly the ISOC, > > need to approve the decisions, the IESG and the IAB would be > > responsible for carrying out any of the recommended changes > that were > > approved. Further, I think it would a serious problem if the I* was > > caught by surprise by any of the recommendations. > > > > - majority representation for the community at large: I think it is > > critical that the community at large have serious > representation in the > > process of making the recommendation. Thus I think that > non officials > > of the IETF community should be the majority of the group. > > > > - a fair selection procedure for choosing those from the > community at > > large needs to be chosen > > > > - non prejudicial method for choosing a chair: given the number of > > different interests involved in making the recommendation, it seemed > > reasonable that the participants in the process itself pick > the person > > they wanted to coordinate the functioning of the team. and > if they are > > not happy with that chair, they should be able to reassign it. > > > > - use of processes already understood: Instead of > inventing new ways > > of doing things, I felt that it would be best to borrow > from techniques > > already in use in the IETF. Therefore the proposal uses variants of > > familiar methods, albeit it different combinations: > > -- the entire team makes a recommendation to the ADs > similar to the way > > directorates do > > -- the chair is chosen in the same way as the chair of the IAB > > -- the community representatives are chosen in a method > similar to the > > nomcom process. > > -- recommendations come in from the community and are distilled by a > > smaller group similar to the way a design team functions. These > > recommendations are reviewed by the IETF community at large before > > being sent on to the IESG. Again similar to a working > group, although > > a very large one. > > > > - The final decision belongs to the IESG as the appointed > > representatives of the community at large. > > > > The proposal was made in the spirit of trying to move the > WG chartered > > work along to completion. My assumption was that the > quickest way to > > resolve the issue was to have a proposal that could be discussed and > > modified. And while it is true that the IESG is empowered > to decide on > > a process before this group reaches consensus, I felt that > there was a > > possibility that they might not (for any number of possible > reasons), > > or that if they did they might use some variant of this > proposal or of > > other proposals that might be discussed in the WG. > > > > I hope that a discussion of how people think the process > should be run > > can help us move away from the deadlock we are currently > experiencing. > > > > thanks > > a. > > > > > > > > From problem-statement-bounces@alvestrand.no Wed Oct 1 12:09:54 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21351 for ; Wed, 1 Oct 2003 12:09:52 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id B730561BB5; Wed, 1 Oct 2003 18:09:26 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from znsgs01r.nortelnetworks.com (h12s128a211n47.user.nortelnetworks.com [47.211.128.12]) by eikenes.alvestrand.no (Postfix) with ESMTP id DAFFE61B91 for ; Wed, 1 Oct 2003 18:09:24 +0200 (CEST) Received: from zwcwc012.europe.nortel.com (zwcwc012.europe.nortel.com [47.160.46.124]) by znsgs01r.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h91G9B712277; Wed, 1 Oct 2003 17:09:11 +0100 (BST) Received: by zwcwc012.europe.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 1 Oct 2003 17:09:11 +0100 Message-ID: <4103264BC8D3D51180B7002048400C4501623829@zhard0jd.europe.nortel.com> From: "Elwyn Davies" To: "'James Kempf'" , Avri Doria , problem-statement@alvestrand.no Date: Wed, 1 Oct 2003 17:09:08 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C38836.583626C2" Subject: RE: An overview of where the IETF change process is currently at X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C38836.583626C2 Content-Type: text/plain; charset="ISO-8859-1" I think the important thing is for the whole I* to feel involved in the process without dominating it. One would expect any I* participants to have an I* perspective on the matters under consideration and to bring with them a feeling of the attitude of the other members to what is going on. Clearly mandating a particular attitude is contrary to normal IETF practice and would probably not go down well with the normal free thinking attitude of most IETF members. However, the I* do endeavour to adhere to certain general principles and might expect their representatives to uphold these views unless really good arguments were advanced to change them (as happens in technical matters today), if only because the IESG in particular has got to implement the results and getting an outright rejection of a proposed solution would probably provoke a major crisis in the IETF. regards, Elwyn > -----Original Message----- > From: James Kempf [mailto:kempf@docomolabs-usa.com] > Sent: 01 October 2003 16:49 > To: Davies, Elwyn [HAL02:0S00:EXCH]; Avri Doria; > problem-statement@alvestrand.no > Subject: Re: An overview of where the IETF change process is > currently at > > > Typically, the IAB doesn't make an official "IAB" statement > unless there is > concensus among its members, and I assume the IESG does the > same. So any > representatives from the IAB to the group would not be > empowered to speak > for the entire IAB. They would, as for any IETF participant, > be speaking as > individuals when giving an opinion in real time. > > Given that, I'm not sure how active an I* presence you are > likely to get in > the process unless all of the I* are involved, which just > isn't practical. I > think a more practical scenario is to view any I* > participants as somewhat > more active than the NomCom liasons, but not representing any > I* opinion in > real time. That is, they would have to go back to their > respective I* and > discuss any matter that might come up where an I* opinion > might be desirable > or necessary, then bring it back to the group. What I am > trying to say is > that any I* participant would not be empowered to represent > the I* as a > whole, at least, if the I* continue with present practice. > Present practice > could, of course, be changed, but requiring concensus is a very strong > custom and I think it would be difficult to change (in addition to any > changes having their own downsides). > > I hope any other I* (especially IESG) will speak up if they > feel I've missed > something here. > > jak > > ----- Original Message ----- > From: "Elwyn Davies" > To: "'James Kempf'" ; "Avri Doria" > ; > > Sent: Wednesday, October 01, 2003 8:30 AM > Subject: RE: An overview of where the IETF change process is > currently at > > > When the authors of the proposal thought about this, the idea > was that the > I* members would be full and active participants in the > process (rether than > observers as in NomCom), and that they were to be delegated > by the I* from > amongst their number. > > The relative sizes of the groups of participants was > carefully chosen to > give full weight to the views of the I* members but without > giving them a > dominant position, and without making the group too unwieldy > (some people > think it is already too big). The document says nothing > about whether the > I* would give any particular mandate to their representatives > or allow them > free rein to exercise their best judgement. > > Regards, > Elwyn > > > -----Original Message----- > > From: James Kempf [mailto:kempf@docomolabs-usa.com] > > Sent: 01 October 2003 16:18 > > To: Avri Doria; problem-statement@alvestrand.no > > Subject: Re: An overview of where the IETF change process is > > currently at > > > > > > Avri, > > > > You've fairly clearly articulated how you want to see > > community participants > > chosen, but you've suggested nothing about how I* > > participants might be > > chosen. Pursuing the analogy with NomCom, do you feel that the I* > > participants should be chosen and should view their roles as > > similar to the > > I* NomCom representatives? Or do you feel that they should be > > more active > > participants? > > > > jak > > > > ----- Original Message ----- > > From: "Avri Doria" > > To: > > Sent: Tuesday, September 30, 2003 11:16 PM > > Subject: Re: An overview of where the IETF change process is > > currently at > > > > > > > > > > On måndag, sep 29, 2003, at 00:46 Asia/Seoul, Melinda Shore wrote: > > > > > > > Avri and I need to talk some more > > > > about how to break the logjam but one thing that concerns me a > > > > great deal is how we're going to be able to come to consensus > > > > when there's strong opposition to pretty much every > option that's > > > > been put forward. One thing we have discussed is that it may > > > > be useful to identify the characteristics that the > process itself > > > > needs to have. > > > > > > As one of the proponents of one of the process proposals, I > > figured I > > > should take a first attempt at giving the reasoning I used while > > > participating in the creation of that proposal. Some of > > the discussion > > > about that proposal have concerned it being > > over-engineered. While I > > > cannot argue against that impression specifically, I do > > think that the > > > details of that proposal came from a concept of what was > required in > > > such a process. I believe one deficiency in that proposal > > is that we > > > did not include an analysis of the requirements for the process. > > > > > > Note: this note is purely personal opinion and _not_ a WG co-chair > > > opinion. It also does not necessarily reflect the opinions > > of my two > > > co-authors who may have had different motivations. The > > proposal was a > > > compromise of our different points of view. This is mine. > > > > > > - transparency: (rapidly becoming an overused term) I > think that any > > > process to respond to the issues in the problem statement > > especially in > > > the response could result in recommendations for structural change > > > should be done in a way that allows for intense community > scrutiny. > > > > > > - public participation: I think that the community should > > not only be > > > allowed to watch the process, but should have the maximum possible > > > ability to contribute to that process. > > > > > > - public accountability: Those who presume to take the > communities > > > opinions and mold them into a proposal should be > accountable to that > > > community. The IETF should know who is making > > recommendations and who > > > is making decsions. And the future roles of those > > individuals within > > > the IETF should take the way they perform these tasks > into account. > > > > > > - rapid movement toward resolution: I think that many in the IETF > > > community are running out of patience. Now that the problem > > > description is nearly complete, resolution should be rapid. > > This does > > > not mean it should be rushed, but there should be a > > reasonable schedule > > > that is adhered to strictly. > > > > > > - significant and balanced representation for those who > > currently have > > > the I* responsibility: I think it is important that those > > people who > > > have been chosen as the IETF's governing team should have > a voice in > > > any recommendation. Not only does the IESG, and possibly > the ISOC, > > > need to approve the decisions, the IESG and the IAB would be > > > responsible for carrying out any of the recommended changes > > that were > > > approved. Further, I think it would a serious problem if > the I* was > > > caught by surprise by any of the recommendations. > > > > > > - majority representation for the community at large: I > think it is > > > critical that the community at large have serious > > representation in the > > > process of making the recommendation. Thus I think that > > non officials > > > of the IETF community should be the majority of the group. > > > > > > - a fair selection procedure for choosing those from the > > community at > > > large needs to be chosen > > > > > > - non prejudicial method for choosing a chair: given the number of > > > different interests involved in making the > recommendation, it seemed > > > reasonable that the participants in the process itself pick > > the person > > > they wanted to coordinate the functioning of the team. and > > if they are > > > not happy with that chair, they should be able to reassign it. > > > > > > - use of processes already understood: Instead of > > inventing new ways > > > of doing things, I felt that it would be best to borrow > > from techniques > > > already in use in the IETF. Therefore the proposal uses > variants of > > > familiar methods, albeit it different combinations: > > > -- the entire team makes a recommendation to the ADs > > similar to the way > > > directorates do > > > -- the chair is chosen in the same way as the chair of the IAB > > > -- the community representatives are chosen in a method > > similar to the > > > nomcom process. > > > -- recommendations come in from the community and are > distilled by a > > > smaller group similar to the way a design team functions. These > > > recommendations are reviewed by the IETF community at large before > > > being sent on to the IESG. Again similar to a working > > group, although > > > a very large one. > > > > > > - The final decision belongs to the IESG as the appointed > > > representatives of the community at large. > > > > > > The proposal was made in the spirit of trying to move the > > WG chartered > > > work along to completion. My assumption was that the > > quickest way to > > > resolve the issue was to have a proposal that could be > discussed and > > > modified. And while it is true that the IESG is empowered > > to decide on > > > a process before this group reaches consensus, I felt that > > there was a > > > possibility that they might not (for any number of possible > > reasons), > > > or that if they did they might use some variant of this > > proposal or of > > > other proposals that might be discussed in the WG. > > > > > > I hope that a discussion of how people think the process > > should be run > > > can help us move away from the deadlock we are currently > > experiencing. > > > > > > thanks > > > a. > > > > > > > > > > > > > > > ------_=_NextPart_001_01C38836.583626C2 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable RE: An overview of where the IETF change process is currently = at

I think the important thing is for the whole I* to = feel involved in the process without dominating it.
One would expect any I* participants to have an I* = perspective on the matters under consideration and to bring with them a = feeling of the attitude of the other members to what is going on.  = Clearly mandating a particular attitude is contrary to normal IETF = practice and would probably not go down well with the normal free = thinking attitude of most IETF members. However, the I* do endeavour to = adhere to certain general principles and might expect their = representatives to uphold these views unless really good arguments were = advanced to change them (as happens in technical matters today), if = only because the IESG in particular has got to implement the results = and getting an outright rejection of a proposed solution would probably = provoke a major crisis in the IETF.

regards,
Elwyn

> -----Original Message-----
> From: James Kempf [mailto:kempf@docomolabs-usa.com= ]
> Sent: 01 October 2003 16:49
> To: Davies, Elwyn [HAL02:0S00:EXCH]; Avri = Doria;
> problem-statement@alvestrand.no
> Subject: Re: An overview of where the IETF = change process is
> currently at
>
>
> Typically, the IAB doesn't make an official = "IAB" statement
> unless there is
> concensus among its members, and I assume the = IESG does the
> same. So any
> representatives from the IAB to the group would = not be
> empowered to speak
> for the entire IAB. They would, as for any IETF = participant,
> be speaking as
> individuals when giving an opinion in real = time.
>
> Given that, I'm not sure how active an I* = presence you are
> likely to get in
> the process unless all of the I* are involved, = which just
> isn't practical. I
> think a more practical scenario is to view any = I*
> participants as somewhat
> more active than the NomCom liasons, but not = representing any
> I* opinion in
> real time. That is, they would have to go back = to their
> respective I* and
> discuss any matter that might come up where an = I* opinion
> might be desirable
> or necessary, then bring it back to the group. = What I am
> trying to say is
> that any I* participant would not be empowered = to represent
> the I* as a
> whole, at least, if the I* continue with = present practice.
> Present practice
> could, of course, be changed, but requiring = concensus is a very strong
> custom and I think it would be difficult to = change (in addition to any
> changes having their own downsides).
>
> I hope any other I* (especially IESG) will = speak up if they
> feel I've missed
> something here.
>
>          = ;   jak
>
> ----- Original Message -----
> From: "Elwyn Davies" = <elwynd@nortelnetworks.com>
> To: "'James Kempf'" = <kempf@docomolabs-usa.com>; "Avri Doria"
> <avri@acm.org>;
> <problem-statement@alvestrand.no>
> Sent: Wednesday, October 01, 2003 8:30 = AM
> Subject: RE: An overview of where the IETF = change process is
> currently at
>
>
> When the authors of the proposal thought about = this, the idea
> was that the
> I* members would be full and active = participants in the
> process (rether than
> observers as in NomCom), and that they were to = be delegated
> by the I* from
> amongst their number.
>
> The relative sizes of the groups of = participants was
> carefully chosen to
> give full weight to the views of the I* members = but without
> giving them a
> dominant position, and without making the group = too unwieldy
> (some people
> think it is already too big).  The = document says nothing
> about whether the
> I* would give any particular mandate to their = representatives
> or allow them
> free rein to exercise their best = judgement.
>
> Regards,
> Elwyn
>
> > -----Original Message-----
> > From: James Kempf [mailto:kempf@docomolabs-usa.com= ]
> > Sent: 01 October 2003 16:18
> > To: Avri Doria; = problem-statement@alvestrand.no
> > Subject: Re: An overview of where the IETF = change process is
> > currently at
> >
> >
> > Avri,
> >
> > You've fairly clearly articulated how you = want to see
> > community participants
> > chosen, but you've suggested nothing about = how I*
> > participants might be
> > chosen. Pursuing the analogy with NomCom, = do you feel that the I*
> > participants should be chosen and should = view their roles as
> > similar to the
> > I* NomCom representatives? Or do you feel = that they should be
> > more active
> > participants?
> >
> >       &n= bsp;     jak
> >
> > ----- Original Message -----
> > From: "Avri Doria" = <avri@acm.org>
> > To: = <problem-statement@alvestrand.no>
> > Sent: Tuesday, September 30, 2003 11:16 = PM
> > Subject: Re: An overview of where the IETF = change process is
> > currently at
> >
> >
> > >
> > > On m=E5ndag, sep 29, 2003, at 00:46 = Asia/Seoul, Melinda Shore wrote:
> > >
> > > > Avri and I need to talk some = more
> > > > about how to break the logjam = but one thing that concerns me a
> > > > great deal is how we're going to = be able to come to consensus
> > > > when there's strong opposition = to pretty much every
> option that's
> > > > been put forward.  One = thing we have discussed is that it may
> > > > be useful to identify the = characteristics that the
> process itself
> > > > needs to have.
> > >
> > > As one of the proponents of one of = the process proposals, I
> > figured I
> > > should take a first attempt at giving = the reasoning I used while
> > > participating in the creation of that = proposal.  Some of
> > the discussion
> > > about that proposal have concerned it = being
> > over-engineered.  While I
> > > cannot argue against that impression = specifically, I do
> > think that the
> > > details of that proposal came from a = concept of what was
> required in
> > > such a process.  I believe one = deficiency in that proposal
> > is that we
> > > did not include an analysis of the = requirements for the process.
> > >
> > > Note: this note is purely personal = opinion and _not_ a WG co-chair
> > > opinion.  It also does not = necessarily reflect the opinions
> > of my two
> > > co-authors who may have had different = motivations.  The
> > proposal was a
> > > compromise of our different points of = view.   This is mine.
> > >
> > > - transparency: (rapidly becoming an = overused term) I
> think that any
> > > process to respond to the issues in = the problem statement
> > especially in
> > > the response could result in = recommendations for structural change
> > > should be done in a way that allows = for intense community
> scrutiny.
> > >
> > > - public participation: I think that = the community should
> > not only be
> > > allowed to watch the process, but = should have the maximum possible
> > > ability to contribute to that = process.
> > >
> > > - public accountability:   = Those who presume to take the
> communities
> > > opinions and mold them into a = proposal should be
> accountable to that
> > > community.  The IETF should know = who is making
> > recommendations and who
> > > is making decsions.  And the = future roles of those
> > individuals within
> > > the IETF should take the way they = perform these tasks
> into account.
> > >
> > > - rapid movement toward = resolution:  I think that many in the IETF
> > > community are running out of = patience.  Now that the problem
> > > description is nearly complete, = resolution should be rapid.
> >  This does
> > > not mean it should be rushed, but = there should be a
> > reasonable schedule
> > > that is adhered to strictly.
> > >
> > > - significant and balanced = representation for those who
> > currently have
> > > the I* responsibility:  I think = it is important that those
> > people who
> > > have been chosen as the IETF's = governing team should have
> a voice in
> > > any recommendation.  Not only = does the IESG, and possibly
> the ISOC,
> > > need to approve the decisions,  = the IESG and the IAB would be
> > > responsible for carrying out any of = the recommended changes
> > that were
> > > approved.  Further, I think it = would a serious problem if
> the I* was
> > > caught by surprise by any of the = recommendations.
> > >
> > > - majority representation for the = community at large:  I
> think it is
> > > critical that the community at large = have serious
> > representation in the
> > > process of making the = recommendation.  Thus I think that
> > non officials
> > > of the IETF community should be the = majority of the group.
> > >
> > > - a fair selection procedure for = choosing those from the
> > community at
> > > large needs to be chosen
> > >
> > > - non prejudicial method for choosing = a chair: given the number of
> > > different interests involved in = making the
> recommendation, it seemed
> > > reasonable that the participants in = the process itself pick
> > the person
> > > they wanted to coordinate the = functioning of the team.  and
> > if they are
> > > not happy with that chair, they = should be able to reassign it.
> > >
> > > - use of processes already = understood:  Instead of
> > inventing new ways
> > > of doing things, I felt that it would = be best to borrow
> > from techniques
> > > already in use in the IETF.  = Therefore the proposal uses
> variants of
> > > familiar methods, albeit it different = combinations:
> > > -- the entire team makes a = recommendation to the ADs
> > similar to the way
> > > directorates do
> > > -- the chair is chosen in the same = way as the chair of the IAB
> > > -- the community representatives are = chosen in a method
> > similar to the
> > > nomcom process.
> > > -- recommendations come in from the = community and are
> distilled by a
> > > smaller group similar to the way a = design team functions.  These
> > > recommendations are reviewed by the = IETF community at large before
> > > being sent on to the IESG.  = Again similar to a working
> > group, although
> > > a very large one.
> > >
> > > - The final decision belongs to the = IESG as the appointed
> > > representatives of the community at = large.
> > >
> > > The proposal was made in the spirit = of trying to move the
> > WG chartered
> > > work along to completion.  My = assumption was that the
> > quickest way to
> > > resolve the issue was to have a = proposal that could be
> discussed and
> > > modified.  And while it is true = that the IESG is empowered
> > to decide on
> > > a process before this group reaches = consensus, I felt that
> > there was a
> > > possibility that they might not (for = any number of possible
> > reasons),
> > > or that if they did they might use = some variant of this
> > proposal or of
> > > other proposals that might be = discussed in the WG.
> > >
> > > I hope that a discussion of how = people think the process
> > should be run
> > > can help us move away from the = deadlock we are currently
> > experiencing.
> > >
> > > thanks
> > > a.
> > >
> > >
> > >
> >
> >
>
>

------_=_NextPart_001_01C38836.583626C2-- From problem-statement-bounces@alvestrand.no Wed Oct 1 12:18:59 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21658 for ; Wed, 1 Oct 2003 12:18:58 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 64FC661B91; Wed, 1 Oct 2003 18:18:34 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by eikenes.alvestrand.no (Postfix) with ESMTP id B62C961B8D for ; Wed, 1 Oct 2003 18:18:31 +0200 (CEST) Message-ID: <017501c38837$b0a889c0$956015ac@dclkempt40> From: "James Kempf" To: "Elwyn Davies" , "Avri Doria" , References: <4103264BC8D3D51180B7002048400C4501623829@zhard0jd.europe.nortel.com> Date: Wed, 1 Oct 2003 09:18:45 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Subject: Re: An overview of where the IETF change process is currently at X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 8bit Elwyn, The problem is that any I* participants won't be "representatives" in the sense that I think you mean, that is, I don't think they will be empowered by their colleagues to represent a joint I* opinion unless that opinion has been discussed and concensus has been achieved. The I* just doesn't work that way currently, it works like the rest of the IETF, where things are discussed until concensus has been reached. Now, it's possible that the I* could empower individuals to represent an I* opinion without that kind of concensus discussion, but it would be a change from current practice. I think a more realistic expectation, given current practice, would be that the I* representatives would, in fact, work more like the NomCom liasons, if, of course, the resolution process follows the path described in the email Avri sent. jak ----- Original Message ----- From: "Elwyn Davies" To: "'James Kempf'" ; "Avri Doria" ; Sent: Wednesday, October 01, 2003 9:09 AM Subject: RE: An overview of where the IETF change process is currently at > I think the important thing is for the whole I* to feel involved in the > process without dominating it. > One would expect any I* participants to have an I* perspective on the > matters under consideration and to bring with them a feeling of the attitude > of the other members to what is going on. Clearly mandating a particular > attitude is contrary to normal IETF practice and would probably not go down > well with the normal free thinking attitude of most IETF members. However, > the I* do endeavour to adhere to certain general principles and might expect > their representatives to uphold these views unless really good arguments > were advanced to change them (as happens in technical matters today), if > only because the IESG in particular has got to implement the results and > getting an outright rejection of a proposed solution would probably provoke > a major crisis in the IETF. > > regards, > Elwyn > > > -----Original Message----- > > From: James Kempf [mailto:kempf@docomolabs-usa.com] > > Sent: 01 October 2003 16:49 > > To: Davies, Elwyn [HAL02:0S00:EXCH]; Avri Doria; > > problem-statement@alvestrand.no > > Subject: Re: An overview of where the IETF change process is > > currently at > > > > > > Typically, the IAB doesn't make an official "IAB" statement > > unless there is > > concensus among its members, and I assume the IESG does the > > same. So any > > representatives from the IAB to the group would not be > > empowered to speak > > for the entire IAB. They would, as for any IETF participant, > > be speaking as > > individuals when giving an opinion in real time. > > > > Given that, I'm not sure how active an I* presence you are > > likely to get in > > the process unless all of the I* are involved, which just > > isn't practical. I > > think a more practical scenario is to view any I* > > participants as somewhat > > more active than the NomCom liasons, but not representing any > > I* opinion in > > real time. That is, they would have to go back to their > > respective I* and > > discuss any matter that might come up where an I* opinion > > might be desirable > > or necessary, then bring it back to the group. What I am > > trying to say is > > that any I* participant would not be empowered to represent > > the I* as a > > whole, at least, if the I* continue with present practice. > > Present practice > > could, of course, be changed, but requiring concensus is a very strong > > custom and I think it would be difficult to change (in addition to any > > changes having their own downsides). > > > > I hope any other I* (especially IESG) will speak up if they > > feel I've missed > > something here. > > > > jak > > > > ----- Original Message ----- > > From: "Elwyn Davies" > > To: "'James Kempf'" ; "Avri Doria" > > ; > > > > Sent: Wednesday, October 01, 2003 8:30 AM > > Subject: RE: An overview of where the IETF change process is > > currently at > > > > > > When the authors of the proposal thought about this, the idea > > was that the > > I* members would be full and active participants in the > > process (rether than > > observers as in NomCom), and that they were to be delegated > > by the I* from > > amongst their number. > > > > The relative sizes of the groups of participants was > > carefully chosen to > > give full weight to the views of the I* members but without > > giving them a > > dominant position, and without making the group too unwieldy > > (some people > > think it is already too big). The document says nothing > > about whether the > > I* would give any particular mandate to their representatives > > or allow them > > free rein to exercise their best judgement. > > > > Regards, > > Elwyn > > > > > -----Original Message----- > > > From: James Kempf [mailto:kempf@docomolabs-usa.com] > > > Sent: 01 October 2003 16:18 > > > To: Avri Doria; problem-statement@alvestrand.no > > > Subject: Re: An overview of where the IETF change process is > > > currently at > > > > > > > > > Avri, > > > > > > You've fairly clearly articulated how you want to see > > > community participants > > > chosen, but you've suggested nothing about how I* > > > participants might be > > > chosen. Pursuing the analogy with NomCom, do you feel that the I* > > > participants should be chosen and should view their roles as > > > similar to the > > > I* NomCom representatives? Or do you feel that they should be > > > more active > > > participants? > > > > > > jak > > > > > > ----- Original Message ----- > > > From: "Avri Doria" > > > To: > > > Sent: Tuesday, September 30, 2003 11:16 PM > > > Subject: Re: An overview of where the IETF change process is > > > currently at > > > > > > > > > > > > > > On måndag, sep 29, 2003, at 00:46 Asia/Seoul, Melinda Shore wrote: > > > > > > > > > Avri and I need to talk some more > > > > > about how to break the logjam but one thing that concerns me a > > > > > great deal is how we're going to be able to come to consensus > > > > > when there's strong opposition to pretty much every > > option that's > > > > > been put forward. One thing we have discussed is that it may > > > > > be useful to identify the characteristics that the > > process itself > > > > > needs to have. > > > > > > > > As one of the proponents of one of the process proposals, I > > > figured I > > > > should take a first attempt at giving the reasoning I used while > > > > participating in the creation of that proposal. Some of > > > the discussion > > > > about that proposal have concerned it being > > > over-engineered. While I > > > > cannot argue against that impression specifically, I do > > > think that the > > > > details of that proposal came from a concept of what was > > required in > > > > such a process. I believe one deficiency in that proposal > > > is that we > > > > did not include an analysis of the requirements for the process. > > > > > > > > Note: this note is purely personal opinion and _not_ a WG co-chair > > > > opinion. It also does not necessarily reflect the opinions > > > of my two > > > > co-authors who may have had different motivations. The > > > proposal was a > > > > compromise of our different points of view. This is mine. > > > > > > > > - transparency: (rapidly becoming an overused term) I > > think that any > > > > process to respond to the issues in the problem statement > > > especially in > > > > the response could result in recommendations for structural change > > > > should be done in a way that allows for intense community > > scrutiny. > > > > > > > > - public participation: I think that the community should > > > not only be > > > > allowed to watch the process, but should have the maximum possible > > > > ability to contribute to that process. > > > > > > > > - public accountability: Those who presume to take the > > communities > > > > opinions and mold them into a proposal should be > > accountable to that > > > > community. The IETF should know who is making > > > recommendations and who > > > > is making decsions. And the future roles of those > > > individuals within > > > > the IETF should take the way they perform these tasks > > into account. > > > > > > > > - rapid movement toward resolution: I think that many in the IETF > > > > community are running out of patience. Now that the problem > > > > description is nearly complete, resolution should be rapid. > > > This does > > > > not mean it should be rushed, but there should be a > > > reasonable schedule > > > > that is adhered to strictly. > > > > > > > > - significant and balanced representation for those who > > > currently have > > > > the I* responsibility: I think it is important that those > > > people who > > > > have been chosen as the IETF's governing team should have > > a voice in > > > > any recommendation. Not only does the IESG, and possibly > > the ISOC, > > > > need to approve the decisions, the IESG and the IAB would be > > > > responsible for carrying out any of the recommended changes > > > that were > > > > approved. Further, I think it would a serious problem if > > the I* was > > > > caught by surprise by any of the recommendations. > > > > > > > > - majority representation for the community at large: I > > think it is > > > > critical that the community at large have serious > > > representation in the > > > > process of making the recommendation. Thus I think that > > > non officials > > > > of the IETF community should be the majority of the group. > > > > > > > > - a fair selection procedure for choosing those from the > > > community at > > > > large needs to be chosen > > > > > > > > - non prejudicial method for choosing a chair: given the number of > > > > different interests involved in making the > > recommendation, it seemed > > > > reasonable that the participants in the process itself pick > > > the person > > > > they wanted to coordinate the functioning of the team. and > > > if they are > > > > not happy with that chair, they should be able to reassign it. > > > > > > > > - use of processes already understood: Instead of > > > inventing new ways > > > > of doing things, I felt that it would be best to borrow > > > from techniques > > > > already in use in the IETF. Therefore the proposal uses > > variants of > > > > familiar methods, albeit it different combinations: > > > > -- the entire team makes a recommendation to the ADs > > > similar to the way > > > > directorates do > > > > -- the chair is chosen in the same way as the chair of the IAB > > > > -- the community representatives are chosen in a method > > > similar to the > > > > nomcom process. > > > > -- recommendations come in from the community and are > > distilled by a > > > > smaller group similar to the way a design team functions. These > > > > recommendations are reviewed by the IETF community at large before > > > > being sent on to the IESG. Again similar to a working > > > group, although > > > > a very large one. > > > > > > > > - The final decision belongs to the IESG as the appointed > > > > representatives of the community at large. > > > > > > > > The proposal was made in the spirit of trying to move the > > > WG chartered > > > > work along to completion. My assumption was that the > > > quickest way to > > > > resolve the issue was to have a proposal that could be > > discussed and > > > > modified. And while it is true that the IESG is empowered > > > to decide on > > > > a process before this group reaches consensus, I felt that > > > there was a > > > > possibility that they might not (for any number of possible > > > reasons), > > > > or that if they did they might use some variant of this > > > proposal or of > > > > other proposals that might be discussed in the WG. > > > > > > > > I hope that a discussion of how people think the process > > > should be run > > > > can help us move away from the deadlock we are currently > > > experiencing. > > > > > > > > thanks > > > > a. > > > > > > > > > > > > > > > > > > > > > > > From problem-statement-bounces@alvestrand.no Wed Oct 1 12:20:35 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21759 for ; Wed, 1 Oct 2003 12:20:34 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id A490B61BE0; Wed, 1 Oct 2003 18:20:10 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from sccrmhc12.comcast.net (sccrmhc12.comcast.net [204.127.202.56]) by eikenes.alvestrand.no (Postfix) with ESMTP id 82B6961BE0 for ; Wed, 1 Oct 2003 18:20:08 +0200 (CEST) Received: from dfnjgl21 (12-237-229-250.client.attbi.com[12.237.229.250]) by comcast.net (sccrmhc12) with SMTP id <20031001162003012001oq2ee> (Authid: sdawkins@comcast.net); Wed, 1 Oct 2003 16:20:07 +0000 Message-ID: <04e501c38837$e209ae90$0400a8c0@DFNJGL21> From: "Spencer Dawkins" To: References: <4103264BC8D3D51180B7002048400C4501623827@zhard0jd.europe.nortel.com> <012501c38833$76ec8eb0$956015ac@dclkempt40> Date: Wed, 1 Oct 2003 11:20:05 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Subject: Re: An overview of where the IETF change process is currently at X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list Reply-To: Spencer Dawkins List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 8bit Dear James, I hear what you're saying here. I'm not one of the proposal authors, but I was at the sushi bar when they put the proposal together. So, speaking only for myself... I think the message in the proposal under discussion is "we're looking for help from 'inside', and reserving seats to try to make that possible". Avri/Elwyn/Jeanette - am I misspeaking here? Are we looking for an "official I* position", going in, or just some I* participants who seem (to the I*) reasonable? Spencer ----- Original Message ----- From: "James Kempf" To: "Elwyn Davies" ; "Avri Doria" ; Sent: Wednesday, October 01, 2003 10:48 AM Subject: Re: An overview of where the IETF change process is currently at > Typically, the IAB doesn't make an official "IAB" statement unless there is > concensus among its members, and I assume the IESG does the same. So any > representatives from the IAB to the group would not be empowered to speak > for the entire IAB. They would, as for any IETF participant, be speaking as > individuals when giving an opinion in real time. > > Given that, I'm not sure how active an I* presence you are likely to get in > the process unless all of the I* are involved, which just isn't practical. I > think a more practical scenario is to view any I* participants as somewhat > more active than the NomCom liasons, but not representing any I* opinion in > real time. That is, they would have to go back to their respective I* and > discuss any matter that might come up where an I* opinion might be desirable > or necessary, then bring it back to the group. What I am trying to say is > that any I* participant would not be empowered to represent the I* as a > whole, at least, if the I* continue with present practice. Present practice > could, of course, be changed, but requiring concensus is a very strong > custom and I think it would be difficult to change (in addition to any > changes having their own downsides). > > I hope any other I* (especially IESG) will speak up if they feel I've missed > something here. > > jak > > ----- Original Message ----- > From: "Elwyn Davies" > To: "'James Kempf'" ; "Avri Doria" ; > > Sent: Wednesday, October 01, 2003 8:30 AM > Subject: RE: An overview of where the IETF change process is currently at > > > When the authors of the proposal thought about this, the idea was that the > I* members would be full and active participants in the process (rether than > observers as in NomCom), and that they were to be delegated by the I* from > amongst their number. > > The relative sizes of the groups of participants was carefully chosen to > give full weight to the views of the I* members but without giving them a > dominant position, and without making the group too unwieldy (some people > think it is already too big). The document says nothing about whether the > I* would give any particular mandate to their representatives or allow them > free rein to exercise their best judgement. > > Regards, > Elwyn > > > -----Original Message----- > > From: James Kempf [mailto:kempf@docomolabs-usa.com] > > Sent: 01 October 2003 16:18 > > To: Avri Doria; problem-statement@alvestrand.no > > Subject: Re: An overview of where the IETF change process is > > currently at > > > > > > Avri, > > > > You've fairly clearly articulated how you want to see > > community participants > > chosen, but you've suggested nothing about how I* > > participants might be > > chosen. Pursuing the analogy with NomCom, do you feel that the I* > > participants should be chosen and should view their roles as > > similar to the > > I* NomCom representatives? Or do you feel that they should be > > more active > > participants? > > > > jak > > > > ----- Original Message ----- > > From: "Avri Doria" > > To: > > Sent: Tuesday, September 30, 2003 11:16 PM > > Subject: Re: An overview of where the IETF change process is > > currently at > > > > > > > > > > On måndag, sep 29, 2003, at 00:46 Asia/Seoul, Melinda Shore wrote: > > > > > > > Avri and I need to talk some more > > > > about how to break the logjam but one thing that concerns me a > > > > great deal is how we're going to be able to come to consensus > > > > when there's strong opposition to pretty much every option that's > > > > been put forward. One thing we have discussed is that it may > > > > be useful to identify the characteristics that the process itself > > > > needs to have. > > > > > > As one of the proponents of one of the process proposals, I > > figured I > > > should take a first attempt at giving the reasoning I used while > > > participating in the creation of that proposal. Some of > > the discussion > > > about that proposal have concerned it being > > over-engineered. While I > > > cannot argue against that impression specifically, I do > > think that the > > > details of that proposal came from a concept of what was required in > > > such a process. I believe one deficiency in that proposal > > is that we > > > did not include an analysis of the requirements for the process. > > > > > > Note: this note is purely personal opinion and _not_ a WG co-chair > > > opinion. It also does not necessarily reflect the opinions > > of my two > > > co-authors who may have had different motivations. The > > proposal was a > > > compromise of our different points of view. This is mine. > > > > > > - transparency: (rapidly becoming an overused term) I think that any > > > process to respond to the issues in the problem statement > > especially in > > > the response could result in recommendations for structural change > > > should be done in a way that allows for intense community scrutiny. > > > > > > - public participation: I think that the community should > > not only be > > > allowed to watch the process, but should have the maximum possible > > > ability to contribute to that process. > > > > > > - public accountability: Those who presume to take the communities > > > opinions and mold them into a proposal should be accountable to that > > > community. The IETF should know who is making > > recommendations and who > > > is making decsions. And the future roles of those > > individuals within > > > the IETF should take the way they perform these tasks into account. > > > > > > - rapid movement toward resolution: I think that many in the IETF > > > community are running out of patience. Now that the problem > > > description is nearly complete, resolution should be rapid. > > This does > > > not mean it should be rushed, but there should be a > > reasonable schedule > > > that is adhered to strictly. > > > > > > - significant and balanced representation for those who > > currently have > > > the I* responsibility: I think it is important that those > > people who > > > have been chosen as the IETF's governing team should have a voice in > > > any recommendation. Not only does the IESG, and possibly the ISOC, > > > need to approve the decisions, the IESG and the IAB would be > > > responsible for carrying out any of the recommended changes > > that were > > > approved. Further, I think it would a serious problem if the I* was > > > caught by surprise by any of the recommendations. > > > > > > - majority representation for the community at large: I think it is > > > critical that the community at large have serious > > representation in the > > > process of making the recommendation. Thus I think that > > non officials > > > of the IETF community should be the majority of the group. > > > > > > - a fair selection procedure for choosing those from the > > community at > > > large needs to be chosen > > > > > > - non prejudicial method for choosing a chair: given the number of > > > different interests involved in making the recommendation, it seemed > > > reasonable that the participants in the process itself pick > > the person > > > they wanted to coordinate the functioning of the team. and > > if they are > > > not happy with that chair, they should be able to reassign it. > > > > > > - use of processes already understood: Instead of > > inventing new ways > > > of doing things, I felt that it would be best to borrow > > from techniques > > > already in use in the IETF. Therefore the proposal uses variants of > > > familiar methods, albeit it different combinations: > > > -- the entire team makes a recommendation to the ADs > > similar to the way > > > directorates do > > > -- the chair is chosen in the same way as the chair of the IAB > > > -- the community representatives are chosen in a method > > similar to the > > > nomcom process. > > > -- recommendations come in from the community and are distilled by a > > > smaller group similar to the way a design team functions. These > > > recommendations are reviewed by the IETF community at large before > > > being sent on to the IESG. Again similar to a working > > group, although > > > a very large one. > > > > > > - The final decision belongs to the IESG as the appointed > > > representatives of the community at large. > > > > > > The proposal was made in the spirit of trying to move the > > WG chartered > > > work along to completion. My assumption was that the > > quickest way to > > > resolve the issue was to have a proposal that could be discussed and > > > modified. And while it is true that the IESG is empowered > > to decide on > > > a process before this group reaches consensus, I felt that > > there was a > > > possibility that they might not (for any number of possible > > reasons), > > > or that if they did they might use some variant of this > > proposal or of > > > other proposals that might be discussed in the WG. > > > > > > I hope that a discussion of how people think the process > > should be run > > > can help us move away from the deadlock we are currently > > experiencing. > > > > > > thanks > > > a. > > > > > > > > > > > > > > From problem-statement-bounces@alvestrand.no Wed Oct 1 16:54:30 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04202 for ; Wed, 1 Oct 2003 16:54:26 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 9BFC061B91; Wed, 1 Oct 2003 22:53:59 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from znsgs01r.nortelnetworks.com (h12s128a211n47.user.nortelnetworks.com [47.211.128.12]) by eikenes.alvestrand.no (Postfix) with ESMTP id 3A5E161B8D for ; Wed, 1 Oct 2003 22:53:57 +0200 (CEST) Received: from zwcwc012.europe.nortel.com (zwcwc012.europe.nortel.com [47.160.46.124]) by znsgs01r.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h91Krr703985; Wed, 1 Oct 2003 21:53:53 +0100 (BST) Received: by zwcwc012.europe.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 1 Oct 2003 21:53:54 +0100 Message-ID: <4103264BC8D3D51180B7002048400C450162382C@zhard0jd.europe.nortel.com> From: "Elwyn Davies" To: "'Spencer Dawkins'" , problem-statement@alvestrand.no Date: Wed, 1 Oct 2003 21:53:53 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3885E.1EDF9B60" Subject: RE: An overview of where the IETF change process is currently at X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C3885E.1EDF9B60 Content-Type: text/plain; charset="ISO-8859-1" I think Spencer has the correct story. To my mind, we really don't want preeconceived ideas in the form of an 'official I* position' in advance. It will be helpful if the SAP has people who have some idea what will be acceptable to the I* and who will indeed add the 'insiders' view to the pot. It will also help if the I* believes that anything that comes out has been handled by somebody who 'seem reasonable'. It also doesn't stop the I* discussing solutions in parallel. Regards, Elwyn > -----Original Message----- > From: Spencer Dawkins [mailto:spencer@mcsr-labs.org] > Sent: 01 October 2003 17:20 > To: problem-statement@alvestrand.no > Subject: Re: An overview of where the IETF change process is > currently at > > > Dear James, > > I hear what you're saying here. > > I'm not one of the proposal authors, but I was at the sushi bar when > they put the proposal together. So, speaking only for myself... > > I think the message in the proposal under discussion is "we're looking > for help from 'inside', and reserving seats to try to make that > possible". > > Avri/Elwyn/Jeanette - am I misspeaking here? Are we looking for an > "official I* position", going in, or just some I* participants who > seem (to the I*) reasonable? > > Spencer > > ----- Original Message ----- > From: "James Kempf" > To: "Elwyn Davies" ; "Avri Doria" > ; > Sent: Wednesday, October 01, 2003 10:48 AM > Subject: Re: An overview of where the IETF change process is currently > at > > > > Typically, the IAB doesn't make an official "IAB" statement unless > there is > > concensus among its members, and I assume the IESG does the same. So > any > > representatives from the IAB to the group would not be empowered to > speak > > for the entire IAB. They would, as for any IETF participant, be > speaking as > > individuals when giving an opinion in real time. > > > > Given that, I'm not sure how active an I* presence you are likely to > get in > > the process unless all of the I* are involved, which just isn't > practical. I > > think a more practical scenario is to view any I* participants as > somewhat > > more active than the NomCom liasons, but not representing any I* > opinion in > > real time. That is, they would have to go back to their respective > I* and > > discuss any matter that might come up where an I* opinion might be > desirable > > or necessary, then bring it back to the group. What I am trying to > say is > > that any I* participant would not be empowered to represent the I* > as a > > whole, at least, if the I* continue with present practice. Present > practice > > could, of course, be changed, but requiring concensus is a very > strong > > custom and I think it would be difficult to change (in addition to > any > > changes having their own downsides). > > > > I hope any other I* (especially IESG) will speak up if they feel > I've missed > > something here. > > > > jak > > > > ----- Original Message ----- > > From: "Elwyn Davies" > > To: "'James Kempf'" ; "Avri Doria" > ; > > > > Sent: Wednesday, October 01, 2003 8:30 AM > > Subject: RE: An overview of where the IETF change process is > currently at > > > > > > When the authors of the proposal thought about this, the idea was > that the > > I* members would be full and active participants in the process > (rether than > > observers as in NomCom), and that they were to be delegated by the > I* from > > amongst their number. > > > > The relative sizes of the groups of participants was carefully > chosen to > > give full weight to the views of the I* members but without giving > them a > > dominant position, and without making the group too unwieldy (some > people > > think it is already too big). The document says nothing about > whether the > > I* would give any particular mandate to their representatives or > allow them > > free rein to exercise their best judgement. > > > > Regards, > > Elwyn > > > > > -----Original Message----- > > > From: James Kempf [mailto:kempf@docomolabs-usa.com] > > > Sent: 01 October 2003 16:18 > > > To: Avri Doria; problem-statement@alvestrand.no > > > Subject: Re: An overview of where the IETF change process is > > > currently at > > > > > > > > > Avri, > > > > > > You've fairly clearly articulated how you want to see > > > community participants > > > chosen, but you've suggested nothing about how I* > > > participants might be > > > chosen. Pursuing the analogy with NomCom, do you feel that the I* > > > participants should be chosen and should view their roles as > > > similar to the > > > I* NomCom representatives? Or do you feel that they should be > > > more active > > > participants? > > > > > > jak > > > > > > ----- Original Message ----- > > > From: "Avri Doria" > > > To: > > > Sent: Tuesday, September 30, 2003 11:16 PM > > > Subject: Re: An overview of where the IETF change process is > > > currently at > > > > > > > > > > > > > > On måndag, sep 29, 2003, at 00:46 Asia/Seoul, Melinda Shore > wrote: > > > > > > > > > Avri and I need to talk some more > > > > > about how to break the logjam but one thing that concerns me a > > > > > great deal is how we're going to be able to come to consensus > > > > > when there's strong opposition to pretty much every option > that's > > > > > been put forward. One thing we have discussed is that it may > > > > > be useful to identify the characteristics that the process > itself > > > > > needs to have. > > > > > > > > As one of the proponents of one of the process proposals, I > > > figured I > > > > should take a first attempt at giving the reasoning I used while > > > > participating in the creation of that proposal. Some of > > > the discussion > > > > about that proposal have concerned it being > > > over-engineered. While I > > > > cannot argue against that impression specifically, I do > > > think that the > > > > details of that proposal came from a concept of what was > required in > > > > such a process. I believe one deficiency in that proposal > > > is that we > > > > did not include an analysis of the requirements for the process. > > > > > > > > Note: this note is purely personal opinion and _not_ a WG > co-chair > > > > opinion. It also does not necessarily reflect the opinions > > > of my two > > > > co-authors who may have had different motivations. The > > > proposal was a > > > > compromise of our different points of view. This is mine. > > > > > > > > - transparency: (rapidly becoming an overused term) I think that > any > > > > process to respond to the issues in the problem statement > > > especially in > > > > the response could result in recommendations for structural > change > > > > should be done in a way that allows for intense community > scrutiny. > > > > > > > > - public participation: I think that the community should > > > not only be > > > > allowed to watch the process, but should have the maximum > possible > > > > ability to contribute to that process. > > > > > > > > - public accountability: Those who presume to take the > communities > > > > opinions and mold them into a proposal should be accountable to > that > > > > community. The IETF should know who is making > > > recommendations and who > > > > is making decsions. And the future roles of those > > > individuals within > > > > the IETF should take the way they perform these tasks into > account. > > > > > > > > - rapid movement toward resolution: I think that many in the > IETF > > > > community are running out of patience. Now that the problem > > > > description is nearly complete, resolution should be rapid. > > > This does > > > > not mean it should be rushed, but there should be a > > > reasonable schedule > > > > that is adhered to strictly. > > > > > > > > - significant and balanced representation for those who > > > currently have > > > > the I* responsibility: I think it is important that those > > > people who > > > > have been chosen as the IETF's governing team should have a > voice in > > > > any recommendation. Not only does the IESG, and possibly the > ISOC, > > > > need to approve the decisions, the IESG and the IAB would be > > > > responsible for carrying out any of the recommended changes > > > that were > > > > approved. Further, I think it would a serious problem if the I* > was > > > > caught by surprise by any of the recommendations. > > > > > > > > - majority representation for the community at large: I think > it is > > > > critical that the community at large have serious > > > representation in the > > > > process of making the recommendation. Thus I think that > > > non officials > > > > of the IETF community should be the majority of the group. > > > > > > > > - a fair selection procedure for choosing those from the > > > community at > > > > large needs to be chosen > > > > > > > > - non prejudicial method for choosing a chair: given the number > of > > > > different interests involved in making the recommendation, it > seemed > > > > reasonable that the participants in the process itself pick > > > the person > > > > they wanted to coordinate the functioning of the team. and > > > if they are > > > > not happy with that chair, they should be able to reassign it. > > > > > > > > - use of processes already understood: Instead of > > > inventing new ways > > > > of doing things, I felt that it would be best to borrow > > > from techniques > > > > already in use in the IETF. Therefore the proposal uses > variants of > > > > familiar methods, albeit it different combinations: > > > > -- the entire team makes a recommendation to the ADs > > > similar to the way > > > > directorates do > > > > -- the chair is chosen in the same way as the chair of the IAB > > > > -- the community representatives are chosen in a method > > > similar to the > > > > nomcom process. > > > > -- recommendations come in from the community and are distilled > by a > > > > smaller group similar to the way a design team functions. These > > > > recommendations are reviewed by the IETF community at large > before > > > > being sent on to the IESG. Again similar to a working > > > group, although > > > > a very large one. > > > > > > > > - The final decision belongs to the IESG as the appointed > > > > representatives of the community at large. > > > > > > > > The proposal was made in the spirit of trying to move the > > > WG chartered > > > > work along to completion. My assumption was that the > > > quickest way to > > > > resolve the issue was to have a proposal that could be discussed > and > > > > modified. And while it is true that the IESG is empowered > > > to decide on > > > > a process before this group reaches consensus, I felt that > > > there was a > > > > possibility that they might not (for any number of possible > > > reasons), > > > > or that if they did they might use some variant of this > > > proposal or of > > > > other proposals that might be discussed in the WG. > > > > > > > > I hope that a discussion of how people think the process > > > should be run > > > > can help us move away from the deadlock we are currently > > > experiencing. > > > > > > > > thanks > > > > a. > > > > > > > > > > > > > > > > > > > > > > ------_=_NextPart_001_01C3885E.1EDF9B60 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable RE: An overview of where the IETF change process is currently = at

I think Spencer has the correct story.

To my mind, we really don't want preeconceived ideas = in the form of an 'official I* position' in advance.
It will be helpful if the SAP has people who have = some idea what will be acceptable to the I* and who will indeed add the = 'insiders' view to the pot.  It will also help if the I* believes = that anything that comes out has been handled by somebody who 'seem = reasonable'.  It also doesn't stop the I* discussing solutions in = parallel.

Regards,
Elwyn

> -----Original Message-----
> From: Spencer Dawkins [mailto:spencer@mcsr-labs.org] =
> Sent: 01 October 2003 17:20
> To: problem-statement@alvestrand.no
> Subject: Re: An overview of where the IETF = change process is
> currently at
>
>
> Dear James,
>
> I hear what you're saying here.
>
> I'm not one of the proposal authors, but I was = at the sushi bar when
> they put the proposal together. So, speaking = only for myself...
>
> I think the message in the proposal under = discussion is "we're looking
> for help from 'inside', and reserving seats to = try to make that
> possible".
>
> Avri/Elwyn/Jeanette - am I misspeaking here? = Are we looking for an
> "official I* position", going in, or = just some I* participants who
> seem (to the I*) reasonable?
>
> Spencer
>
> ----- Original Message -----
> From: "James Kempf" = <kempf@docomolabs-usa.com>
> To: "Elwyn Davies" = <elwynd@nortelnetworks.com>; "Avri Doria"
> <avri@acm.org>; = <problem-statement@alvestrand.no>
> Sent: Wednesday, October 01, 2003 10:48 = AM
> Subject: Re: An overview of where the IETF = change process is currently
> at
>
>
> > Typically, the IAB doesn't make an = official "IAB" statement unless
> there is
> > concensus among its members, and I assume = the IESG does the same. So
> any
> > representatives from the IAB to the group = would not be empowered to
> speak
> > for the entire IAB. They would, as for any = IETF participant, be
> speaking as
> > individuals when giving an opinion in real = time.
> >
> > Given that, I'm not sure how active an I* = presence you are likely to
> get in
> > the process unless all of the I* are = involved, which just isn't
> practical. I
> > think a more practical scenario is to view = any I* participants as
> somewhat
> > more active than the NomCom liasons, but = not representing any I*
> opinion in
> > real time. That is, they would have to go = back to their respective
> I* and
> > discuss any matter that might come up = where an I* opinion might be
> desirable
> > or necessary, then bring it back to the = group. What I am trying to
> say is
> > that any I* participant would not be = empowered to represent the I*
> as a
> > whole, at least, if the I* continue with = present practice. Present
> practice
> > could, of course, be changed, but = requiring concensus is a very
> strong
> > custom and I think it would be difficult = to change (in addition to
> any
> > changes having their own = downsides).
> >
> > I hope any other I* (especially IESG) will = speak up if they feel
> I've missed
> > something here.
> >
> = >           &n= bsp; jak
> >
> > ----- Original Message -----
> > From: "Elwyn Davies" = <elwynd@nortelnetworks.com>
> > To: "'James Kempf'" = <kempf@docomolabs-usa.com>; "Avri Doria"
> <avri@acm.org>;
> > = <problem-statement@alvestrand.no>
> > Sent: Wednesday, October 01, 2003 8:30 = AM
> > Subject: RE: An overview of where the IETF = change process is
> currently at
> >
> >
> > When the authors of the proposal thought = about this, the idea was
> that the
> > I* members would be full and active = participants in the process
> (rether than
> > observers as in NomCom), and that they = were to be delegated by the
> I* from
> > amongst their number.
> >
> > The relative sizes of the groups of = participants was carefully
> chosen to
> > give full weight to the views of the I* = members but without giving
> them a
> > dominant position, and without making the = group too unwieldy (some
> people
> > think it is already too big).  The = document says nothing about
> whether the
> > I* would give any particular mandate to = their representatives or
> allow them
> > free rein to exercise their best = judgement.
> >
> > Regards,
> > Elwyn
> >
> > > -----Original Message-----
> > > From: James Kempf [mailto:kempf@docomolabs-usa.com= ]
> > > Sent: 01 October 2003 16:18
> > > To: Avri Doria; = problem-statement@alvestrand.no
> > > Subject: Re: An overview of where the = IETF change process is
> > > currently at
> > >
> > >
> > > Avri,
> > >
> > > You've fairly clearly articulated how = you want to see
> > > community participants
> > > chosen, but you've suggested nothing = about how I*
> > > participants might be
> > > chosen. Pursuing the analogy with = NomCom, do you feel that the I*
> > > participants should be chosen and = should view their roles as
> > > similar to the
> > > I* NomCom representatives? Or do you = feel that they should be
> > > more active
> > > participants?
> > >
> > = >           &n= bsp; jak
> > >
> > > ----- Original Message -----
> > > From: "Avri Doria" = <avri@acm.org>
> > > To: = <problem-statement@alvestrand.no>
> > > Sent: Tuesday, September 30, 2003 = 11:16 PM
> > > Subject: Re: An overview of where the = IETF change process is
> > > currently at
> > >
> > >
> > > >
> > > > On m=E5ndag, sep 29, 2003, at = 00:46 Asia/Seoul, Melinda Shore
> wrote:
> > > >
> > > > > Avri and I need to talk = some more
> > > > > about how to break the = logjam but one thing that concerns me a
> > > > > great deal is how we're = going to be able to come to consensus
> > > > > when there's strong = opposition to pretty much every option
> that's
> > > > > been put forward.  One = thing we have discussed is that it may
> > > > > be useful to identify the = characteristics that the process
> itself
> > > > > needs to have.
> > > >
> > > > As one of the proponents of one = of the process proposals, I
> > > figured I
> > > > should take a first attempt at = giving the reasoning I used while
> > > > participating in the creation of = that proposal.  Some of
> > > the discussion
> > > > about that proposal have = concerned it being
> > > over-engineered.  While I
> > > > cannot argue against that = impression specifically, I do
> > > think that the
> > > > details of that proposal came = from a concept of what was
> required in
> > > > such a process.  I believe = one deficiency in that proposal
> > > is that we
> > > > did not include an analysis of = the requirements for the process.
> > > >
> > > > Note: this note is purely = personal opinion and _not_ a WG
> co-chair
> > > > opinion.  It also does not = necessarily reflect the opinions
> > > of my two
> > > > co-authors who may have had = different motivations.  The
> > > proposal was a
> > > > compromise of our different = points of view.   This is mine.
> > > >
> > > > - transparency: (rapidly = becoming an overused term) I think that
> any
> > > > process to respond to the issues = in the problem statement
> > > especially in
> > > > the response could result in = recommendations for structural
> change
> > > > should be done in a way that = allows for intense community
> scrutiny.
> > > >
> > > > - public participation: I think = that the community should
> > > not only be
> > > > allowed to watch the process, = but should have the maximum
> possible
> > > > ability to contribute to that = process.
> > > >
> > > > - public = accountability:   Those who presume to take the
> communities
> > > > opinions and mold them into a = proposal should be accountable to
> that
> > > > community.  The IETF should = know who is making
> > > recommendations and who
> > > > is making decsions.  And = the future roles of those
> > > individuals within
> > > > the IETF should take the way = they perform these tasks into
> account.
> > > >
> > > > - rapid movement toward = resolution:  I think that many in the
> IETF
> > > > community are running out of = patience.  Now that the problem
> > > > description is nearly complete, = resolution should be rapid.
> > >  This does
> > > > not mean it should be rushed, = but there should be a
> > > reasonable schedule
> > > > that is adhered to = strictly.
> > > >
> > > > - significant and balanced = representation for those who
> > > currently have
> > > > the I* responsibility:  I = think it is important that those
> > > people who
> > > > have been chosen as the IETF's = governing team should have a
> voice in
> > > > any recommendation.  Not = only does the IESG, and possibly the
> ISOC,
> > > > need to approve the = decisions,  the IESG and the IAB would be
> > > > responsible for carrying out any = of the recommended changes
> > > that were
> > > > approved.  Further, I think = it would a serious problem if the I*
> was
> > > > caught by surprise by any of the = recommendations.
> > > >
> > > > - majority representation for = the community at large:  I think
> it is
> > > > critical that the community at = large have serious
> > > representation in the
> > > > process of making the = recommendation.  Thus I think that
> > > non officials
> > > > of the IETF community should be = the majority of the group.
> > > >
> > > > - a fair selection procedure for = choosing those from the
> > > community at
> > > > large needs to be chosen
> > > >
> > > > - non prejudicial method for = choosing a chair: given the number
> of
> > > > different interests involved in = making the recommendation, it
> seemed
> > > > reasonable that the participants = in the process itself pick
> > > the person
> > > > they wanted to coordinate the = functioning of the team.  and
> > > if they are
> > > > not happy with that chair, they = should be able to reassign it.
> > > >
> > > > - use of processes already = understood:  Instead of
> > > inventing new ways
> > > > of doing things, I felt that it = would be best to borrow
> > > from techniques
> > > > already in use in the = IETF.  Therefore the proposal uses
> variants of
> > > > familiar methods, albeit it = different combinations:
> > > > -- the entire team makes a = recommendation to the ADs
> > > similar to the way
> > > > directorates do
> > > > -- the chair is chosen in the = same way as the chair of the IAB
> > > > -- the community representatives = are chosen in a method
> > > similar to the
> > > > nomcom process.
> > > > -- recommendations come in from = the community and are distilled
> by a
> > > > smaller group similar to the way = a design team functions.  These
> > > > recommendations are reviewed by = the IETF community at large
> before
> > > > being sent on to the IESG.  = Again similar to a working
> > > group, although
> > > > a very large one.
> > > >
> > > > - The final decision belongs to = the IESG as the appointed
> > > > representatives of the community = at large.
> > > >
> > > > The proposal was made in the = spirit of trying to move the
> > > WG chartered
> > > > work along to completion.  = My assumption was that the
> > > quickest way to
> > > > resolve the issue was to have a = proposal that could be discussed
> and
> > > > modified.  And while it is = true that the IESG is empowered
> > > to decide on
> > > > a process before this group = reaches consensus, I felt that
> > > there was a
> > > > possibility that they might not = (for any number of possible
> > > reasons),
> > > > or that if they did they might = use some variant of this
> > > proposal or of
> > > > other proposals that might be = discussed in the WG.
> > > >
> > > > I hope that a discussion of how = people think the process
> > > should be run
> > > > can help us move away from the = deadlock we are currently
> > > experiencing.
> > > >
> > > > thanks
> > > > a.
> > > >
> > > >
> > > >
> > >
> > >
> >
>
>

------_=_NextPart_001_01C3885E.1EDF9B60-- From problem-statement-bounces@alvestrand.no Mon Oct 6 19:45:40 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA28367 for ; Mon, 6 Oct 2003 19:45:39 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 32DA161C13; Tue, 7 Oct 2003 01:45:16 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by eikenes.alvestrand.no (Postfix) with ESMTP id 69B9561C0A for ; Tue, 7 Oct 2003 01:45:13 +0200 (CEST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h96NjCI32016 for ; Mon, 6 Oct 2003 16:45:12 -0700 X-mProtect: <200310062345> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (10.241.55.53, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdLqWJGf; Mon, 06 Oct 2003 16:45:10 PDT Message-ID: <3F81FE6D.3000703@iprg.nokia.com> Date: Mon, 06 Oct 2003 16:44:45 -0700 From: Charlie Perkins Organization: Nokia User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: problem-statement@alvestrand.no References: <4103264BC8D3D51180B7002048400C450162382C@zhard0jd.europe.nortel.com> In-Reply-To: <4103264BC8D3D51180B7002048400C450162382C@zhard0jd.europe.nortel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Comments on the Problem Statement draft: Document structure X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit Hello folks, I have some comments on the draft. I'll break it down into three different e-mail messages, because otherwise I am afraid that many points might be lost. I believe that the document structure causes the document to lose effectiveness. It can be improved by some pretty basic reorganization: - The "Changes" sections should be moved into an appendix (or multiple appendices) - The "Acknowledgement" section (currently 1.4) should be moved to be the last section before the normative references. - In Section (2), the first part of the section should itemize the list of root causes, e.g.: = Unclear Mission = Poor Use of Effective Engineering Practice = Standards Process Abuse = Workload exceeds available staffing levels = Unsuitable Management Structure = Poor WG dynamics = Inadequate Staff Preparation This text should be placed before section 2.1. I know that the IETF participants are "Staff", because I have two IETF t-shirts that say so. Also I would strongly encourage _short_ formulations for the "root causes", because long rambling formulations just don't get the point across anywhere near as well. A statement is made that the "Unclear Mission" root cause is the "fundamental" cause. I don't believe it. I think it's much more a case of arbitrary procedures applied selectively according to circumstance and personal preference. When I discuss with people at the IETF, I may often hear a point of view that I don't agree with. But I rarely would characterize it as not having a clue about mission. Without formulating a proposed "mission statement" to try to prove my point, I would at least like to strongly suggest that the characterization in section 2., preceding section 2.1, is wrong. If I had to pick out a more fundamental root cause, it would be "Unsuitable Management Structure", at least from the current formulation for the set of root causes. Thus, I would suggest demoting section 2.2 to be placed _much_ later in section 2. More in another e-mail coming shortly. Regards, Charlie P. From problem-statement-bounces@alvestrand.no Mon Oct 6 22:10:10 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA01961 for ; Mon, 6 Oct 2003 22:10:09 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 765DD61C15; Tue, 7 Oct 2003 04:09:46 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by eikenes.alvestrand.no (Postfix) with ESMTP id F2DE661C04 for ; Tue, 7 Oct 2003 04:09:36 +0200 (CEST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h9729Z831984 for ; Mon, 6 Oct 2003 19:09:35 -0700 X-mProtect: <200310070209> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (10.241.55.53, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdOFxQOG; Mon, 06 Oct 2003 19:09:33 PDT Message-ID: <3F822045.7040208@iprg.nokia.com> Date: Mon, 06 Oct 2003 19:09:09 -0700 From: Charlie Perkins Organization: Nokia User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Problem Statement Working Group Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: More detailed comments on the Problem Statement document X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit Hello again folks, In general, the document is quite verbose. A spell checker should be employed, and ways should be found to eliminate redundancy. Here are some more detailed comments on the draft. In section 2.1, I do not like the following sentence: > o The misty vision has inhibited the development of roadmaps that > would inform the IETF's stakeholders of our longer term > intentions, In the first place, I don't think the IETF has many longer term intentions, except perhaps "saving the Internet". Such intentions don't necessarily need "roadmaps". I think the IETF is much more reactive than would be understood from the above sentence, and I think it's a good thing for the IETF to be that way. This is not to say that the IETF can only solve problems after they occur. I do think think that the IETF should try to prevent problems, as far in advance as we reasonably can. But the IETF actions are happening in response to identified problems, not (in general!) according to some over-arching roadmap, architecture, plan, or vision. In section 2.2, on page six, there is the following text: > o Failure to identify and articulate engineering trade-offs that may > be needed to meet the deadlines that the WG has set without > inappropriately reducing the 'fitness for purpose' for the > intended customers. > > o Continued refinement of the solution beyond the point at which it > is adequate to meet the requirements placed on it by the intended > purpose. I am concerned that listing these as bullets needing attention is counterproductive. For one thing, most engineers are aware that these problems need to be avoided. On the general assumption that most WG staff (i.e., the ones that do the work and that care) are engineers, there isn't much need to restate the obvious, and most people will not derive much useful content from these bullets -- i.e., it's the negative equivalent of "motherhood and apple pie". I don't remember when anyone consciously acted in the above bad ways. In the next list: > o Poorly defined success criteria for WGs and individual documents. I'm not sure this is really worth calling out as a specific problem. For one thing, the success criteria are the charter items. For another thing, if there is a poorly defined criterion, it stems more from the problem with the standards track than anything else, and that's not going to get fixed by rewhacking WG processes. To the point: > o Lack of review, especially early review, by reviewers who are not > directly interested mebers of the WG, and by subject matter > experts for topics related to, but not necessarily the immediate > focus of the document. I would like to suggest that we not view this as a "problem", because there might not be a good solution. Good external reviewers don't grow on trees, and if they did anyway we would find the trees are already completely plucked for other reasons. I don't see how we can expect to get so many good external reviewers that they could spend time reading early drafts that aren't even implemented by WG members yet. I'd much rather see such a valuable resource be put to use after some initial validation within the working group itself. Another way to attack this deficiency, as I have tried to suggest before, is that as time goes on, we amass a body of documentation by subject matter experts that explain how to avoid certain cross-working-group problems. It's a lot more scalable to ask engineers to try to find relevant documents that have been written about a relevant area of cross-expertise interactions, than it is for them to find an expert to explain it for the millionth time on the expert's personal timeline. So, I'd replace that bullet by something like: o Lack of documentation about likely problem areas that might arise due to interactions with other popular IETF protocols. The point, on page 12 > o Absence of documented debriefing sessions to assess and record the > successes and failures of WGs (and other processes) so that the > positive and negative lessons learned can be used to facilitate > future work and improve the processes. is essentially the same as the previous point, and both could be expressed more succinctly as: o Lack of a WG "post mortem" procedure to drive the improvement of the standards development process. The following point: > o Lack of criteria for determining when a piece of work is > overrunning and/or is unlikely to be concluded successfully either > at all or within an acceptable time frame: Lack of process for > either extending the time frame, adjusting the scope or > terminating the work item or the whole Working Group. is debatable, because the process should be "amending the charter", and the criteria should be "according to the charter". On a positive note, I wholeheartedly agree with the following point, and I suggest that current efforts towards improvement be encouraged and extended: > o Automated tools to support the engineering process are minimal. Regarding the next bullet item, I would suggest that no change is needed to current IETF processes: > o Despite its commitment to 'running code', the IETF is not > proactive in providing ways for developers to verify their > implementations of IETF standards. So far as I can tell, the developers are quite adept at making this happen regardless of whether the IETF helps or not. Or, as they say, "If it's not broke, don't fix it". Also on page 12, the following bullets are redundant and could beneficially be deleted to avoid numbing repetition: > o Project entry, goal setting, dependency identification, > coordination and tracking processes are all either missing or > implemented less effectively than the norm for commercial > organizations in related activities. Dependencies and coordination > should cover both other WGs within the IETF and any outside SDO > with which the IETF is collaborating. > > o Charters regularly fail to set sufficiently granular milestones at > which progress of WGs, individuals and documents can be evaluated. > Also WGs often do not make more detailed work plans to refine the > charter plans. > > o The acceptable deadlines for finishing a piece of work, and the > criteria used to determine them, are rarely, if ever, documented. > Also the estimates of the time required to complete the work often > ....... Unless I am missing something, all of these ideas have already appeared earlier in the section. On the next page, I disagree with the following statement: > One problem which the IETF does not appear to suffer from is > excessive bureaucracy, in the sense that transfer of information is > generally kept to the minimum necessary to accomplish the task. For one thing, I might suggest that the current "rfc-editor" processing is quite bureaucratic, regardless of its value. Also, the evaluation of criteria for advancement along the standards track, the submission process for Internet Drafts, the BOF approval, and other examples can be viewed as more or less bureaucratic. Maybe it's not as bureaucratic as other organizations. Maybe. Another problem is that one person's "minimality" may well be another person's "insufficiency". Typically, bureaucracy creates procedure based on historical problem solving episodes. I can think about the IANA considerations in exactly this way -- a little bit along the way towards how mortgage agreements are structured. Of course, one wants to avoid ALL systemic problems in permanent transactions. So, I'd reduce the amount of self-congratulation on this point. The best you can say is that the IETF bureaucracy is younger than some of the other bureaucracies we might be able to name. In section 2.3, the first paragraph should cross-reference section 2.2 since the topic is related to the lack of external review. Perhaps better, the bullet in section 2.2 should be moved here, on the theory that this is a fact of life, not a problem we can try to solve. I have another thought about section 2.3 that I have moved into a separate note. Regarding the point on pg. 14: > o The IETF does not have an effective means for defining > architectures and frameworks that will shape the work of multiple > WGs. ... that is something that should be done by the IAB. So I would say that the IETF does have the means, but it's perhaps not yet effective. On page 16, in section 2.5, the following sentence should be deleted: > Whilst this might be put down to contributors having less time > available in their work schedule during the downturn of the last two > years, this is not the whole story because there were signs of this > effect back at the height of the boom in 2000. In section 2.6.4, the last paragraph should be deleted. It has no place, and the most charitable interpretation would put it squarely into a solutions document. More likely, it looks like an insult. In section 2.7, the claim is made that problems result from the non-hierarchical nature of the working group. I don't believe it. I have never seen this as a problem. In fact, I would characterize it as a feature. If anything, there might be a problem with assignment of tasks, and accountability for accomplishing those tasks. Typically, hierarchy helps with delegation, accountability, and evaluation, but the lack of hierarchy does not mean the lack of those three management aids. In fact, I would in solution space suggest that the new methods for issue tracking could be tied in with a non-hierarchical method for delegation, accountability, and evaluation for better results. I will send out yet another note with detailed editorial remarks, with a lot less substance and importance compared to these comments. Regards, Charlie P. From problem-statement-bounces@alvestrand.no Mon Oct 6 22:18:46 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA02177 for ; Mon, 6 Oct 2003 22:18:45 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id A227861C0A; Tue, 7 Oct 2003 04:18:23 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by eikenes.alvestrand.no (Postfix) with ESMTP id 0050161C04 for ; Tue, 7 Oct 2003 04:18:10 +0200 (CEST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h972I8h04393 for ; Mon, 6 Oct 2003 19:18:08 -0700 X-mProtect: <200310070218> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (10.241.55.53, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdCP0mMV; Mon, 06 Oct 2003 19:18:06 PDT Message-ID: <3F822246.404@iprg.nokia.com> Date: Mon, 06 Oct 2003 19:17:42 -0700 From: Charlie Perkins Organization: Nokia User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Problem Statement Working Group Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Ownership and "cross-licensing" of protocols by working groups X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit Hello again folks, While reading section 2.3, I remembered a terrible problem with cross-working-group interactions. Suppose that working group A standardizes protocol A, and that working group B needs the functionality of protocol A for the operation of the protocol that is to become protocol B. One would think it should be natural for WG-B to build on the work within WG-A. In fact, one would think that WG-A would actively encourage the work of WG-B. Unfortunately, this obvious strategy fails in practice, for reasons that are unreasonably tedious and counterproductive to the point of daffiness. What happens, is that WG-A can, and does, refuse to ratify even the most minor changes needed by WG-B. Then, WG-B has to go back to the drawing boards, losing valuable time and/or features. Specific areas where I have seen this occur include: - security(IPsec), and - neighborhood determination in IPv6 I would be amazed if these are the only examples. Therefore for self-preservation, an IETF working group should _never_ try to use a protocol for which it does not own complete change control. Or else, we could have a statement by the IAB that mandated more flexibility by working groups whose outputs MIGHT be useful by someone else in the universe. I exaggerate. mea culpa. I get aggravated thinking about it. Regards, Charlie P. From problem-statement-bounces@alvestrand.no Tue Oct 7 01:35:43 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA06935 for ; Tue, 7 Oct 2003 01:35:42 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 8D32561C19; Tue, 7 Oct 2003 07:35:18 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by eikenes.alvestrand.no (Postfix) with ESMTP id 49DCA61C17 for ; Tue, 7 Oct 2003 07:35:16 +0200 (CEST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h975ZA717574; Mon, 6 Oct 2003 22:35:10 -0700 X-mProtect: <200310070535> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (10.241.49.169, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdTm88RP; Mon, 06 Oct 2003 22:35:08 PDT Message-ID: <3F82506D.80005@iprg.nokia.com> Date: Mon, 06 Oct 2003 22:34:37 -0700 From: Charlie Perkins Organization: Nokia User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Elwyn Davies Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Problem Statement Working Group Subject: Detailed editorial comments X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit Hello Elwyn, Here are some detailed editorial comments, mostly as a matter of style and syntax. I found several instances of language that made me stop, sit up, and ponder. This could be viewed as a technique for getting someone's attention, but more often it's just distracting to the person who was really flowing along with the main thought. In such cases, the ornamental value of the expression is outweighed by the derailment of the train of thought. I hope you don't mind if I point out a few instances of this among my suggestions below. It's not that they are incorrect, strictly speaking. In my writing preference, the word "clearly", and usually the word "clear", is a "clear" indication of something wrong. First, it is usually meant to browbeat the reader into submission -- as if, there is "obviously" no room for disagreement. Similarly, "obvious" is also a danger sign. Secondly, it begs the reader to disagree with you, in a way to counteract your implicit act of verbal dominance. I'd suggest purging practically every occurrence of "clear" from the document. Change: > work which has lead to an extremely successful, all-pervasive network to: > work which has led to an successful and pervasive network or, better: "work which has facilitated the widespread deployment of the Internet and especially the infrastructure of the Internet" After all, most of the people in the world have never even made a telephone call. Change: > a, still extensive, list of perceived problems which were classified to: > a (still extensive) list of perceived problems which were classified or, better: a list of perceived problems which were classified Change: > and in terms of work in progress. The effects of this growth have to: > and volume of work in progress. The effects of this growth have Delete "Extant" in: > time. Extant evidence dating back to at least 1992 drew similar In section 1.3, the colons should be replaced by periods. In current section 1.6, which I hope will be moved to an appendix, there is an extra space before "term" in: > o The term customer has been replaced by stakeholder when In section 2.1, replace "sectional" by "narrow" in: > o Working Groups can potentially be hijacked by sectional interests Also, replace "blinker" by "obstruct" in: > technology because this would be likely to blinker the IETF's view Replace "concensus" by "consensus". In the paragraph before section 2.2: - Replace "mandated" by "official" (if I understand the meaning correctly!) - Delete "the 'conventional'" - Replace "which" by "that" Change: > Externally, the IETF is often placed in the same bracket as these to: > Externally, the IETF is often classified with these In section 2.2, there's too much capitalization in the first paragraph. Changing all the "extras" to lower case would not be a bad idea, but changing at least the first two extras is really recommended. Insert "as used here" after: > ........... . Effective Engineering Practices Change: > o Failure to identify at an early stage (before the design is > frozen), and/or then to ensure that there is a uniform view in the > WG of the issues that need to be resolved to bring the work to a > satisfactory conclusion. to: > o Failure to identify the issues that need to be resolved at an early > stage (before the design is frozen), and/or then to ensure that > there > is a uniform view in the WG of those issues In the following sentence, replace "to deliver" by "for" > The IETF standards engineering process is not set up to deliver In the following, replace "mebers" by "members": > directly interested mebers of the WG, and by subject matter Replace "emphasises" by "emphasizes", unless this is your personal preference, in: > structure of the IETF emphasises communication between the IESG Replace "posess" by "possess" in: > o The IETF does not posess effective formal mechanisms for inter-WG Change: > adequate for the older, smaller organization, but are apparently not to: > adequate for an older, smaller IETF, but are apparently not Replace "of" by "likely to be found in" in: > the capabilities of a single person. Change: > o Interacting with WGs > > o Understanding network and computer technology generally, and their > own area in detail > > o Cross-pollinating between groups > > o Coordinating with other areas to: > o Interaction with WGs > > o Understanding network and computer technology generally, and their > own area in detail > > o Cross-pollination between groups > > o Coordination with other areas Change: > clear that only superhumans can be expected to do this job well. To to: > extremely difficult to do this job well. To In the following, change "second" to "send": > people who work for large companies who can afford to second IESG Change: > this flexibility, and is burying itself in procedures that rapidly > move from organizational conveniences to rigid and immutable > shibboleths. to: > this flexibility, and is entangling itself in procedures that evolve > from organizational conveniences into encumbrances. Change "weighting" to "emphasis" in: > have chosen to give heavy weighting to continuity of IESG and IAB In section 2.6.6, replace "whilst" by "while". On the previous line, delete "Clearly". In the same sentence as whilst, again delete "clearly". In the next sentence, replace "Also" by "Furthermore". In section 2.6.7, first sentence, delete "intensely". On page 21, delete "a particular kind of" On page 23, replace "steeped" by "immersed", or perhaps "long familiar" Lastly, on page 24, replace "Author's" by "Editor's". Regards, Charlie P. From problem-statement-bounces@alvestrand.no Tue Oct 7 03:49:37 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA22305 for ; Tue, 7 Oct 2003 03:49:36 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id D671661C19; Tue, 7 Oct 2003 09:49:13 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from HALVESTR-W2K1.cisco.com (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 5269661C1C; Tue, 7 Oct 2003 09:49:12 +0200 (CEST) Date: Tue, 07 Oct 2003 09:48:11 +0200 From: Harald Tveit Alvestrand To: Charlie Perkins , problem-statement@alvestrand.no Message-ID: <97109636.1065520091@localhost> In-Reply-To: <3F81FE6D.3000703@iprg.nokia.com> References: <4103264BC8D3D51180B7002048400C450162382C@zhard0jd.europe.nortel. com> <3F81FE6D.3000703@iprg.nokia.com> X-Mailer: Mulberry/3.1.0b8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: Re: Comments on the Problem Statement draft: Document structure X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit --On 6. oktober 2003 16:44 -0700 Charlie Perkins wrote: > A statement is made that the "Unclear Mission" root > cause is the "fundamental" cause. I don't believe it. > I think it's much more a case of arbitrary procedures > applied selectively according to circumstance and > personal preference. Charlie, I don't believe that the document as currently written raises the "unclear mission" point above the other points, one of which is the "management" issue. It just happens to come first in the list. I think there are two issues with percieved arbitrariness: - If we allow ourselves to assume that leaders have been genuinely acting in bad faith, I think we will jeopardize our ability to correctly diagnose and correct the real problems we have. - If we do not understand the processes that led to the decisions that are being labelled "arbitrary" being taken by competent people acting in good faith, we are doomed to repeat them. Harald From problem-statement-bounces@alvestrand.no Tue Oct 7 04:33:45 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA23160 for ; Tue, 7 Oct 2003 04:33:44 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 3140C61C19; Tue, 7 Oct 2003 10:33:22 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from i2kc04-ukbr.domain1.systemhost.net (unknown [217.32.164.151]) by eikenes.alvestrand.no (Postfix) with ESMTP id D2C8461C17 for ; Tue, 7 Oct 2003 10:33:20 +0200 (CEST) Received: from i2km96-ukbr.domain1.systemhost.net ([193.113.197.84]) by i2kc04-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(5.0.2195.6713); Tue, 7 Oct 2003 09:33:20 +0100 Received: from i2km02-ukbr.domain1.systemhost.net ([193.113.197.79]) by i2km96-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(5.0.2195.6713); Tue, 7 Oct 2003 09:33:19 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 7 Oct 2003 09:33:19 +0100 Message-ID: <3D67CCA7D63E714B980D21A038EEA08E05927697@i2km02-ukbr.domain1.systemhost.net> Thread-Topic: Comments on the Problem Statement draft: Document structure Thread-Index: AcOMY+cGI4qqI+NCQXqt7c/VHLdtwQAR9fQg From: To: , X-OriginalArrivalTime: 07 Oct 2003 08:33:19.0613 (UTC) FILETIME=[A96B7AD0:01C38CAD] Subject: RE: Comments on the Problem Statement draft: Document structure X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: quoted-printable Charlie, You wrote: "A statement is made that the "Unclear Mission" root cause is the = "fundamental" cause. I don't believe it. I think it's much more a case = of arbitrary procedures applied selectively according to circumstance = and personal preference." IMHO, the procedures are merely tools to be used in achieving an end. = If the end is unclear, or unknown, no amount of tools will help to = achieve it, whether they are well or badly used. So the mission is = fundamental. It may be true that every IETF participant ( thinks he / she ) knows = what the end is. But how many different ends would be listed if you = asked everybody ? Even if there were one agreed end today, it might = well have changed in a years time, however subtly. We can, and should, = regularly review the IETF mission, to ensure that we are taking account = of changing circumstances and customer requirements. Regards, Graham Travers International Standards Manager BT Exact e-mail: graham.travers@bt.com tel: +44(0) 1359 235086 mobile: +44(0) 7808 502536 fax: +44(0) 1359 235087 HWB279, PO Box 200,London, N18 1ZF, UK BTexact Technologies is a trademark of British Telecommunications plc Registered office: 81 Newgate Street London EC1A 7AJ Registered in England no. 1800000 This electronic message contains information from British = Telecommunications plc which may be privileged or confidential. The = information is intended to be for the use of the individual(s) or entity = named above. If you are not the intended recipient be aware that any = disclosure, copying, distribution or use of the contents of this = information is prohibited. If you have received this electronic message = in error, please notify us by telephone or email (to the numbers or = address above) immediately. =20 -----Original Message----- From: Charlie Perkins [mailto:charliep@iprg.nokia.com] Sent: 07 October 2003 00:45 To: problem-statement@alvestrand.no Subject: Comments on the Problem Statement draft: Document structure Hello folks, I have some comments on the draft. I'll break it down into three different e-mail messages, because otherwise I am afraid that many points might be lost. I believe that the document structure causes the document to lose effectiveness. It can be improved by some pretty basic reorganization: - The "Changes" sections should be moved into an appendix (or multiple appendices) - The "Acknowledgement" section (currently 1.4) should be moved to be the last section before the normative references. - In Section (2), the first part of the section should itemize the list of root causes, e.g.: =3D Unclear Mission =3D Poor Use of Effective Engineering Practice =3D Standards Process Abuse =3D Workload exceeds available staffing levels =3D Unsuitable Management Structure =3D Poor WG dynamics =3D Inadequate Staff Preparation This text should be placed before section 2.1. I know that the IETF participants are "Staff", because I have two IETF t-shirts that say so. Also I would strongly encourage _short_ formulations for the "root causes", because long rambling formulations just don't get the point across anywhere near as well. A statement is made that the "Unclear Mission" root cause is the "fundamental" cause. I don't believe it. I think it's much more a case of arbitrary procedures applied selectively according to circumstance and personal preference. When I discuss with people at the IETF, I may often hear a point of view that I don't agree with. But I rarely would characterize it as not having a clue about mission. Without formulating a proposed "mission statement" to try to prove my point, I would at least like to strongly suggest that the characterization in section 2., preceding section 2.1, is wrong. If I had to pick out a more fundamental root cause, it would be "Unsuitable Management Structure", at least from the current formulation for the set of root causes. Thus, I would suggest demoting section 2.2 to be placed _much_ later in section 2. More in another e-mail coming shortly. Regards, Charlie P. From problem-statement-bounces@alvestrand.no Tue Oct 7 04:49:56 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA23667 for ; Tue, 7 Oct 2003 04:49:55 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 2CBE861C17; Tue, 7 Oct 2003 10:49:33 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from i2kc05-ukbr.domain1.systemhost.net (unknown [217.32.164.139]) by eikenes.alvestrand.no (Postfix) with ESMTP id CCA6D61C16 for ; Tue, 7 Oct 2003 10:49:30 +0200 (CEST) Received: from i2km98-ukbr.domain1.systemhost.net ([193.113.197.85]) by i2kc05-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(5.0.2195.6713); Tue, 7 Oct 2003 09:49:30 +0100 Received: from i2km02-ukbr.domain1.systemhost.net ([193.113.197.79]) by i2km98-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(5.0.2195.6713); Tue, 7 Oct 2003 09:49:30 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 7 Oct 2003 09:49:29 +0100 Message-ID: <3D67CCA7D63E714B980D21A038EEA08E045A2AC5@i2km02-ukbr.domain1.systemhost.net> Thread-Topic: Ownership and "cross-licensing" of protocols by working groups Thread-Index: AcOMeUnRMa3cP5srQCCCkUzHRwgc1QANeKTw From: To: , X-OriginalArrivalTime: 07 Oct 2003 08:49:30.0089 (UTC) FILETIME=[EBDE5D90:01C38CAF] Subject: RE: Ownership and "cross-licensing" of protocols by working groups X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: quoted-printable Charlie, I agree; but this problem doesn't just apply to internal IETF WG = relationships. The more that IETF protocols are used for applications = that are not strictly within the scope of the Internet, the more = important this issue becomes. =20 Think about SIP and 3GPP. I now hear that the OMA is planning = extensions to SIP, which it has no intention of referring back to the = IETF. The IETF has to become more accommodating to the requirements of = other organisations, or this sort of thing will happen more and more - = and that's bad for ( nearly ) everyone. Regards, Graham Travers International Standards Manager BT Exact e-mail: graham.travers@bt.com tel: +44(0) 1359 235086 mobile: +44(0) 7808 502536 fax: +44(0) 1359 235087 HWB279, PO Box 200,London, N18 1ZF, UK BTexact Technologies is a trademark of British Telecommunications plc Registered office: 81 Newgate Street London EC1A 7AJ Registered in England no. 1800000 This electronic message contains information from British = Telecommunications plc which may be privileged or confidential. The = information is intended to be for the use of the individual(s) or entity = named above. If you are not the intended recipient be aware that any = disclosure, copying, distribution or use of the contents of this = information is prohibited. If you have received this electronic message = in error, please notify us by telephone or email (to the numbers or = address above) immediately. =20 -----Original Message----- From: Charlie Perkins [mailto:charliep@iprg.nokia.com] Sent: 07 October 2003 03:18 To: Problem Statement Working Group Subject: Ownership and "cross-licensing" of protocols by working groups Hello again folks, While reading section 2.3, I remembered a terrible problem with cross-working-group interactions. Suppose that working group A standardizes protocol A, and that working group B needs the functionality of protocol A for the operation of the protocol that is to become protocol B. One would think it should be natural for WG-B to build on the work within WG-A. In fact, one would think that WG-A would actively encourage the work of WG-B. Unfortunately, this obvious strategy fails in practice, for reasons that are unreasonably tedious and counterproductive to the point of daffiness. What happens, is that WG-A can, and does, refuse to ratify even the most minor changes needed by WG-B. Then, WG-B has to go back to the drawing boards, losing valuable time and/or features. Specific areas where I have seen this occur include: - security(IPsec), and - neighborhood determination in IPv6 I would be amazed if these are the only examples. Therefore for self-preservation, an IETF working group should _never_ try to use a protocol for which it does not own complete change control. Or else, we could have a statement by the IAB that mandated more flexibility by working groups whose outputs MIGHT be useful by someone else in the universe. I exaggerate. mea culpa. I get aggravated thinking about it. Regards, Charlie P. From problem-statement-bounces@alvestrand.no Tue Oct 7 06:56:25 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA26615 for ; Tue, 7 Oct 2003 06:56:24 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 733B061C1C; Tue, 7 Oct 2003 12:56:02 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from psg.com (psg.com [147.28.0.62]) by eikenes.alvestrand.no (Postfix) with ESMTP id C35EB61C1C for ; Tue, 7 Oct 2003 12:56:00 +0200 (CEST) Received: from [147.28.0.62] (helo=acm.org) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1A6pVX-0007cR-Hy for problem-statement@alvestrand.no; Tue, 07 Oct 2003 10:55:59 +0000 Date: Tue, 7 Oct 2003 19:55:17 +0900 Mime-Version: 1.0 (Apple Message framework v552) Content-Type: text/plain; delsp=yes; charset=US-ASCII; format=flowed From: Avri Doria To: problem-statement@alvestrand.no Content-Transfer-Encoding: 7bit Message-Id: X-Mailer: Apple Mail (2.552) Subject: Fwd: I-D ACTION:draft-ietf-problem-issue-statement-04.txt X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit Just noticed this never got posted to the list. a. Begin forwarded message: > From: Internet-Drafts@ietf.org > Date: tis sep 30, 2003 04:38:18 Asia/Seoul > To: IETF-Announce: ; > Cc: problem-statement@alvestrand.no > Subject: I-D ACTION:draft-ietf-problem-issue-statement-04.txt > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Problem Statement Working Group of > the IETF. > > Title : IETF Problem Statement > Author(s) : E. Davies > Filename : draft-ietf-problem-issue-statement-04.txt > Pages : 26 > Date : 2003-9-29 > > This memo summarizes perceived problems in the structure, function > and processes of the Internet Engineering Task Force (IETF). We are > attempting to identify these problems, so that they can be addressed > and corrected by the IETF community. > The problems have been digested and categorized from an extensive > discussion which took place on the 'problem-statement' mailing list > from November 2002 to September 2003. The problem list has been > further analyzed to try and determine the root causes, that are at > the heart of the perceived problems: The result will be used to guide > the next stage of the process in the Problem Statement working group > which is to recommend the structures and processes that will carry > out the corrections. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-problem-issue- > statement-04.txt > > To remove yourself from the IETF Announcement list, send a message to > ietf-announce-request with the word unsubscribe in the body of the > message. > > Internet-Drafts are also available by anonymous FTP. Login with the > username > "anonymous" and a password of your e-mail address. After logging in, > type "cd internet-drafts" and then > "get draft-ietf-problem-issue-statement-04.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-ietf-problem-issue-statement-04.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > Content-Type: text/plain > Content-ID: <2003-9-29153102.I-D@ietf.org> From problem-statement-bounces@alvestrand.no Tue Oct 7 08:12:26 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA28471 for ; Tue, 7 Oct 2003 08:12:25 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 797D661C1F; Tue, 7 Oct 2003 14:12:02 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from rwcrmhc12.comcast.net (rwcrmhc12.comcast.net [216.148.227.85]) by eikenes.alvestrand.no (Postfix) with ESMTP id CBEF561C1C for ; Tue, 7 Oct 2003 14:12:00 +0200 (CEST) Received: from dfnjgl21 (12-237-229-250.client.attbi.com[12.237.229.250]) by comcast.net (rwcrmhc12) with SMTP id <200310071211580140069t6ie> (Authid: sdawkins@comcast.net); Tue, 7 Oct 2003 12:11:59 +0000 Message-ID: <070701c38ccc$368cccc0$0400a8c0@DFNJGL21> From: "Spencer Dawkins" To: References: <3D67CCA7D63E714B980D21A038EEA08E045A2AC5@i2km02-ukbr.domain1.systemhost.net> Date: Tue, 7 Oct 2003 07:12:00 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Subject: Re: Ownership and "cross-licensing" of protocols by working groups X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list Reply-To: Spencer Dawkins List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit Dear Graham, In my opinion, the real danger isn't another standards body planning extensions to IETF protocols, it's another standards body dorking with IETF protocols. The problem with SIP and 3GPP wasn't that 3GPP extended SIP, it was that one group had headers classified as mandatory that the other did not, so that an application that was conformant for one group might send a request that an application conformant for the other group would consider malformed. Don't get me wrong - I agree that if we solve some of the IETF problems, we'll probably get more work than if we don't, and that's especially true of the problem of committed interdependencies. I'm saying that the problem with interdependencies isn't just that interdependencies are harder, it's that interoperability is jeopardized. Spencer ----- Original Message ----- From: To: ; Sent: Tuesday, October 07, 2003 3:49 AM Subject: RE: Ownership and "cross-licensing" of protocols by working groups Charlie, I agree; but this problem doesn't just apply to internal IETF WG relationships. The more that IETF protocols are used for applications that are not strictly within the scope of the Internet, the more important this issue becomes. Think about SIP and 3GPP. I now hear that the OMA is planning extensions to SIP, which it has no intention of referring back to the IETF. The IETF has to become more accommodating to the requirements of other organisations, or this sort of thing will happen more and more - and that's bad for ( nearly ) everyone. Regards, Graham Travers International Standards Manager BT Exact e-mail: graham.travers@bt.com tel: +44(0) 1359 235086 mobile: +44(0) 7808 502536 fax: +44(0) 1359 235087 HWB279, PO Box 200,London, N18 1ZF, UK BTexact Technologies is a trademark of British Telecommunications plc Registered office: 81 Newgate Street London EC1A 7AJ Registered in England no. 1800000 This electronic message contains information from British Telecommunications plc which may be privileged or confidential. The information is intended to be for the use of the individual(s) or entity named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information is prohibited. If you have received this electronic message in error, please notify us by telephone or email (to the numbers or address above) immediately. -----Original Message----- From: Charlie Perkins [mailto:charliep@iprg.nokia.com] Sent: 07 October 2003 03:18 To: Problem Statement Working Group Subject: Ownership and "cross-licensing" of protocols by working groups Hello again folks, While reading section 2.3, I remembered a terrible problem with cross-working-group interactions. Suppose that working group A standardizes protocol A, and that working group B needs the functionality of protocol A for the operation of the protocol that is to become protocol B. One would think it should be natural for WG-B to build on the work within WG-A. In fact, one would think that WG-A would actively encourage the work of WG-B. Unfortunately, this obvious strategy fails in practice, for reasons that are unreasonably tedious and counterproductive to the point of daffiness. What happens, is that WG-A can, and does, refuse to ratify even the most minor changes needed by WG-B. Then, WG-B has to go back to the drawing boards, losing valuable time and/or features. Specific areas where I have seen this occur include: - security(IPsec), and - neighborhood determination in IPv6 I would be amazed if these are the only examples. Therefore for self-preservation, an IETF working group should _never_ try to use a protocol for which it does not own complete change control. Or else, we could have a statement by the IAB that mandated more flexibility by working groups whose outputs MIGHT be useful by someone else in the universe. I exaggerate. mea culpa. I get aggravated thinking about it. Regards, Charlie P. From problem-statement-bounces@alvestrand.no Tue Oct 7 09:37:36 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01356 for ; Tue, 7 Oct 2003 09:37:35 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 430F461C1D; Tue, 7 Oct 2003 15:37:13 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by eikenes.alvestrand.no (Postfix) with ESMTP id 40DA961C1A for ; Tue, 7 Oct 2003 15:37:12 +0200 (CEST) Received: from piuha.net (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 7C46C6A906; Tue, 7 Oct 2003 16:37:11 +0300 (EEST) Message-ID: <3F82C09E.1010901@piuha.net> Date: Tue, 07 Oct 2003 16:33:18 +0300 From: Jari Arkko Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20030225 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Charlie Perkins References: <3D67CCA7D63E714B980D21A038EEA08E045A2AC5@i2km02-ukbr.domain1.systemhost.net> <070701c38ccc$368cccc0$0400a8c0@DFNJGL21> In-Reply-To: <070701c38ccc$368cccc0$0400a8c0@DFNJGL21> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: problem-statement@alvestrand.no Subject: Re: Ownership and "cross-licensing" of protocols by working groups X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list Reply-To: jari.arkko@piuha.net List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit Yes, I've felt the same problem as Charlie has. And I'm now more cautious about using components from other WGs than I used to be. I would add that even if the other WGs would be very willing to co-operate, the chances are that there's a schedule mismatch. The extensions would be needed sooner than they can be delivered. However, I think the solutions for this problem are harder than you Charlie indicate. Like it or not the net is getting more complicated. We have more applications. We have infrastructure components such as various kinds of agents, AAA servers, security devices, and so on. We have more transport services and associated security mechanisms to go with them. There is *bound* to be more interactions between the various pieces. And the world is bigger, with more SDOs than we had to deal with before. Pretty much everything runs over IP, so its no wonder we'll have to deal with various needs to build new things on top of IP. I can see several issues associated with this situation: - Interactions with the results of some other WG, or IETF->SDO dependencies are not inherently bad. A well-designed dependency is a good thing. But you have to have a good design, its bad to depend on all sorts of other stuff that isn't strictly speaking essential. - One way to measure whether you are having a good dependency is to ask whether you are expecting a lot of modifications to the protocol that you depend on. If no, its good. If yes, its bad. If the protocol needs some new general purpose extensions (many of the SIP extensions needed by 3GPP were of this sort), this can be still be OK. But if you are starting to need specific support for your application, you are on thin ice. - If you find that the thing the other WG has developed does exactly match your requirements, it may be a good idea to design your own. Of course, we need to apply some common sense with this rule. If we need some small feature to a large, co-operating set of protocols (SIP + RTP + SDP, etc to give one example), designing your own set of protocols may not be wise. On the other hand, you might be better off developing your own (even if tweaking an existing component is possible) if it would create many new dependencies or APIs. We had this case with SEND and AH; it would have been possible to use AH but it would have resulted in quite SEND-specific AH extensions as well as a number of internal APIs that would have been needed. So we decided to build our own authentication scheme for SEND instead. So, here's my tentative set of rules to follow: R1. REUSE. Where a component exists (or is being developed) by someone else, and it matches your requirements, always reuse that component in your design. R2. FOLLOW THE RULES. You must follow the component designer's rules (e.g. SIP RFC) when using the component in your own system. R3. DO NOT TWEAK. If there is no component that exists and suits your requirements exactly, you should in most cases develop your own mechanisms. R4. PRODUCE GENERAL RESULTS. In your own work, ensure that what you do is readily usable in many environments without a need for extensions. R5. LEAVE ROOM FOR OTHERS (corollary of R4). Don't try to solve everything. Your component should perform a function, and deliver some information to the layers above. Don't dictate what the layers above do. A good example to follow here is TLS, it performs a communications security function and delivers some information about the endpoints to the application layer. The application layer can still make use of that information in some application specific way, e.g., match the TLS identities to application layer identities. R6. EXPLICIT APPLICATION RULES. Make it very clear what others can and can not do with your protocol components. Can they add header fields? Can they specify a particular algorithm for deciding when to initiate a specific event? We pretty much have IANA considerations in all protocols by now, which is good. We also have more specific extensibility documents, a good example is the SIP document which talks about the process for adding new header fields. (I like the fact that such a document exists, I'm not sure if the IETF went overboard with the strict requirements for adding header fields.) We also have some protocol applicability statements, which should tell whether the component can be applied in the situation that you think of. This rule is particularly important when working with other SDOs. --Jari From problem-statement-bounces@alvestrand.no Tue Oct 7 09:42:59 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01496 for ; Tue, 7 Oct 2003 09:42:58 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id DEECD61C1A; Tue, 7 Oct 2003 15:42:35 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from d12lmsgate.de.ibm.com (d12lmsgate-2.de.ibm.com [194.196.100.235]) by eikenes.alvestrand.no (Postfix) with ESMTP id 6AD4861C19 for ; Tue, 7 Oct 2003 15:42:34 +0200 (CEST) Received: from d12relay01.megacenter.de.ibm.com (d12relay01.megacenter.de.ibm.com [9.149.165.180]) by d12lmsgate.de.ibm.com (8.12.10/8.12.8) with ESMTP id h97DgXoS162930 for ; Tue, 7 Oct 2003 15:42:33 +0200 Received: from ochsehorn.zurich.ibm.com (ochsehorn.zurich.ibm.com [9.4.16.140]) by d12relay01.megacenter.de.ibm.com (8.12.9/NCO/VER6.6) with ESMTP id h97DgXqi235006 for ; Tue, 7 Oct 2003 15:42:33 +0200 Received: from zurich.ibm.com (sig-9-145-225-13.de.ibm.com [9.145.225.13]) by ochsehorn.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id PAA55832 for ; Tue, 7 Oct 2003 15:42:32 +0200 Message-ID: <3F82C2AD.E3B43FD5@zurich.ibm.com> Date: Tue, 07 Oct 2003 15:42:05 +0200 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de MIME-Version: 1.0 To: problem-statement@alvestrand.no References: <4103264BC8D3D51180B7002048400C450162382C@zhard0jd.europe.nortel.com> <3F81FE6D.3000703@iprg.nokia.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: Comments on the Problem Statement draft: Document structure X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit Charlie has spent a lot of time on this draft. But (and I suspect I am repeating myself) I believe we are way beyond the point of diminishing returns with this document. I believe, although I have my own quibbles, that we should stop investing effort in polishing it. It is a document of *no* long-term value; its value lies in triggering remedial action, and that is where all our effort should now go. Brian Charlie Perkins wrote: > > Hello folks, > > I have some comments on the draft. I'll break it down into > three different e-mail messages, because otherwise I am > afraid that many points might be lost. > > I believe that the document structure causes the > document to lose effectiveness. It can be improved by > some pretty basic reorganization: > > - The "Changes" sections should be moved into an > appendix (or multiple appendices) > > - The "Acknowledgement" section (currently 1.4) should > be moved to be the last section before the normative > references. > > - In Section (2), the first part of the section should > itemize the list of root causes, e.g.: > = Unclear Mission > = Poor Use of Effective Engineering Practice > = Standards Process Abuse > = Workload exceeds available staffing levels > = Unsuitable Management Structure > = Poor WG dynamics > = Inadequate Staff Preparation > > This text should be placed before section 2.1. > > I know that the IETF participants are "Staff", because > I have two IETF t-shirts that say so. Also I would > strongly encourage _short_ formulations for the "root > causes", because long rambling formulations just don't > get the point across anywhere near as well. > > A statement is made that the "Unclear Mission" root > cause is the "fundamental" cause. I don't believe it. > I think it's much more a case of arbitrary procedures > applied selectively according to circumstance and > personal preference. When I discuss with people at > the IETF, I may often hear a point of view that I don't > agree with. But I rarely would characterize it as not > having a clue about mission. Without formulating a > proposed "mission statement" to try to prove my > point, I would at least like to strongly suggest that the > characterization in section 2., preceding section 2.1, > is wrong. If I had to pick out a more fundamental > root cause, it would be "Unsuitable Management > Structure", at least from the current formulation for > the set of root causes. > > Thus, I would suggest demoting section 2.2 to be placed > _much_ later in section 2. > > More in another e-mail coming shortly. > > Regards, > Charlie P. -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Brian E Carpenter Distinguished Engineer, Internet Standards & Technology, IBM NEW ADDRESS PLEASE UPDATE ADDRESS BOOK From problem-statement-bounces@alvestrand.no Tue Oct 7 09:47:09 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01613 for ; Tue, 7 Oct 2003 09:47:08 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 8F62D61C1A; Tue, 7 Oct 2003 15:46:45 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by eikenes.alvestrand.no (Postfix) with ESMTP id 04EE661C19 for ; Tue, 7 Oct 2003 15:46:44 +0200 (CEST) Received: from piuha.net (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id C23936A908; Tue, 7 Oct 2003 16:46:43 +0300 (EEST) Message-ID: <3F82C2DB.7010702@piuha.net> Date: Tue, 07 Oct 2003 16:42:51 +0300 From: Jari Arkko Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20030225 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Charlie Perkins References: <3F822045.7040208@iprg.nokia.com> In-Reply-To: <3F822045.7040208@iprg.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: Problem Statement Working Group Subject: Re: More detailed comments on the Problem Statement document X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list Reply-To: jari.arkko@piuha.net List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit Charlie Perkins wrote: > In general, the document is quite verbose. A spell checker should > be employed, and ways should be found to eliminate redundancy. Yes. > Here are some more detailed comments on the draft. > > In section 2.1, I do not like the following sentence: > >> o The misty vision has inhibited the development of roadmaps that >> would inform the IETF's stakeholders of our longer term >> intentions, > > > In the first place, I don't think the IETF has many longer term intentions, > except perhaps "saving the Internet". Such intentions don't necessarily > need "roadmaps". I think the IETF is much more reactive than would be understood from the above sentence I agree. > and I think it's a good thing for > the IETF to be that way. This is not to say that the IETF can only solve > problems after they occur. I do think think that the IETF should try to > prevent problems, as far in advance as we reasonably can. But the > IETF actions are happening in response to identified problems, not > (in general!) according to some over-arching roadmap, architecture, > plan, or vision. Hmm... I agree that this is what appears to be happening now. I would actually prefer to see a more "planned" approach where we publish roadmaps for some developments that we foresee. For instance, is there an IETF/IAB/IESG plan for dealing with "wireless"? We certainly are doing a lot of work in this space, but I think it would be beneficial if we developed a roadmap of things we need to do for the "wireless" in the next 2-5 years. This would benefit both external parties, as they could learn what we intend to do, as well as ourselves in terms of making it clearer how we are doing, and how much more work remains. > In section 2.2, on page six, there is the following text: > >> o Failure to identify and articulate engineering trade-offs that may >> be needed to meet the deadlines that the WG has set without >> inappropriately reducing the 'fitness for purpose' for the >> intended customers. >> >> o Continued refinement of the solution beyond the point at which it >> is adequate to meet the requirements placed on it by the intended >> purpose. > > > > I am concerned that listing these as bullets needing attention is > counterproductive. For one thing, most engineers are aware that > these problems need to be avoided. On the general assumption that > most WG staff (i.e., the ones that do the work and that care) are > engineers, there isn't much need to restate the obvious, and most > people will not derive much useful content from these bullets -- i.e., > it's the negative equivalent of "motherhood and apple pie". I don't > remember when anyone consciously acted in the above bad ways. Not consciously. But I do get a sense that we have a culture for perfection -- in the requirements phase its taking too many requirements as given, in the design phase its the continued refinement of the specs. --Jari From problem-statement-bounces@alvestrand.no Tue Oct 7 09:47:32 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01640 for ; Tue, 7 Oct 2003 09:47:31 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 39BD261C20; Tue, 7 Oct 2003 15:47:09 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from d12lmsgate.de.ibm.com (d12lmsgate-5.de.ibm.com [194.196.100.238]) by eikenes.alvestrand.no (Postfix) with ESMTP id 6B95261C1F for ; Tue, 7 Oct 2003 15:47:07 +0200 (CEST) Received: from d12relay01.megacenter.de.ibm.com (d12relay01.megacenter.de.ibm.com [9.149.165.180]) by d12lmsgate.de.ibm.com (8.12.10/8.12.8) with ESMTP id h97Dl5Nb117882 for ; Tue, 7 Oct 2003 15:47:05 +0200 Received: from ochsehorn.zurich.ibm.com (ochsehorn.zurich.ibm.com [9.4.16.140]) by d12relay01.megacenter.de.ibm.com (8.12.9/NCO/VER6.6) with ESMTP id h97Dl6qi229020 for ; Tue, 7 Oct 2003 15:47:06 +0200 Received: from zurich.ibm.com (sig-9-145-225-13.de.ibm.com [9.145.225.13]) by ochsehorn.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id PAA33984 for ; Tue, 7 Oct 2003 15:47:05 +0200 Message-ID: <3F82C3C1.816C8E6@zurich.ibm.com> Date: Tue, 07 Oct 2003 15:46:41 +0200 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de MIME-Version: 1.0 To: problem-statement@alvestrand.no References: <3D67CCA7D63E714B980D21A038EEA08E045A2AC5@i2km02-ukbr.domain1.systemhost.net> <070701c38ccc$368cccc0$0400a8c0@DFNJGL21> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: Ownership and "cross-licensing" of protocols by working groups X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit Getting back to Charlie's point (because we *can't* reform other bodies, but we *can* reform the IETF), isn't this in fact the same point that is made in section 2.3: > o The IETF is not consistently effective at resolving issues that > cross WG or area boundaries. > > o The IETF does not posess effective formal mechanisms for inter-WG > cooperation, coordination or communication, including the handling > of dependencies between deliverables and processes specified in in > WG charters. > > o The IETF does not have an effective means for defining > architectures and frameworks that will shape the work of multiple > WGs. Brian Spencer Dawkins wrote: > > Dear Graham, > > In my opinion, the real danger isn't another standards body planning > extensions to IETF protocols, it's another standards body dorking with > IETF protocols. The problem with SIP and 3GPP wasn't that 3GPP > extended SIP, it was that one group had headers classified as > mandatory that the other did not, so that an application that was > conformant for one group might send a request that an application > conformant for the other group would consider malformed. > > Don't get me wrong - I agree that if we solve some of the IETF > problems, we'll probably get more work than if we don't, and that's > especially true of the problem of committed interdependencies. I'm > saying that the problem with interdependencies isn't just that > interdependencies are harder, it's that interoperability is > jeopardized. > > Spencer > > ----- Original Message ----- > From: > To: ; > Sent: Tuesday, October 07, 2003 3:49 AM > Subject: RE: Ownership and "cross-licensing" of protocols by working > groups > > Charlie, > > I agree; but this problem doesn't just apply to internal IETF WG > relationships. The more that IETF protocols are used for applications > that are not strictly within the scope of the Internet, the more > important this issue becomes. > > Think about SIP and 3GPP. I now hear that the OMA is planning > extensions to SIP, which it has no intention of referring back to the > IETF. The IETF has to become more accommodating to the requirements > of other organisations, or this sort of thing will happen more and > more - and that's bad for ( nearly ) everyone. > > Regards, > > Graham Travers > > International Standards Manager > BT Exact > > e-mail: graham.travers@bt.com > tel: +44(0) 1359 235086 > mobile: +44(0) 7808 502536 > fax: +44(0) 1359 235087 > > HWB279, PO Box 200,London, N18 1ZF, UK > > BTexact Technologies is a trademark of British Telecommunications plc > Registered office: 81 Newgate Street London EC1A 7AJ > Registered in England no. 1800000 > > This electronic message contains information from British > Telecommunications plc which may be privileged or confidential. The > information is intended to be for the use of the individual(s) or > entity named above. If you are not the intended recipient be aware > that any disclosure, copying, distribution or use of the contents of > this information is prohibited. If you have received this electronic > message in error, please notify us by telephone or email (to the > numbers or address above) immediately. > > -----Original Message----- > From: Charlie Perkins [mailto:charliep@iprg.nokia.com] > Sent: 07 October 2003 03:18 > To: Problem Statement Working Group > Subject: Ownership and "cross-licensing" of protocols by working > groups > > Hello again folks, > > While reading section 2.3, I remembered a terrible problem > with cross-working-group interactions. Suppose that working > group A standardizes protocol A, and that working group B > needs the functionality of protocol A for the operation of the > protocol that is to become protocol B. One would think it should > be natural for WG-B to build on the work within WG-A. In fact, > one would think that WG-A would actively encourage the work > of WG-B. Unfortunately, this obvious strategy fails in practice, > for reasons that are unreasonably tedious and counterproductive > to the point of daffiness. > > What happens, is that WG-A can, and does, refuse to ratify > even the most minor changes needed by WG-B. Then, WG-B > has to go back to the drawing boards, losing valuable time and/or > features. > > Specific areas where I have seen this occur include: > - security(IPsec), and > - neighborhood determination in IPv6 > I would be amazed if these are the only examples. > > Therefore for self-preservation, an IETF working group > should _never_ try to use a protocol for which it does not > own complete change control. > > Or else, we could have a statement by the IAB that mandated > more flexibility by working groups whose outputs MIGHT be > useful by someone else in the universe. I exaggerate. mea culpa. > I get aggravated thinking about it. > > Regards, > Charlie P. -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Brian E Carpenter Distinguished Engineer, Internet Standards & Technology, IBM NEW ADDRESS PLEASE UPDATE ADDRESS BOOK From problem-statement-bounces@alvestrand.no Tue Oct 7 09:50:47 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01724 for ; Tue, 7 Oct 2003 09:50:46 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 3A9A961C20; Tue, 7 Oct 2003 15:50:24 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by eikenes.alvestrand.no (Postfix) with ESMTP id BF29561C1A for ; Tue, 7 Oct 2003 15:50:22 +0200 (CEST) Received: from piuha.net (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 884B96A908; Tue, 7 Oct 2003 16:50:22 +0300 (EEST) Message-ID: <3F82C3B6.6030206@piuha.net> Date: Tue, 07 Oct 2003 16:46:30 +0300 From: Jari Arkko Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20030225 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Charlie Perkins References: <4103264BC8D3D51180B7002048400C450162382C@zhard0jd.europe.nortel.com> <3F81FE6D.3000703@iprg.nokia.com> In-Reply-To: <3F81FE6D.3000703@iprg.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: problem-statement@alvestrand.no Subject: Re: Comments on the Problem Statement draft: Document structure X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list Reply-To: jari.arkko@piuha.net List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit Charlie Perkins wrote: > > Hello folks, > > I have some comments on the draft. I'll break it down into > three different e-mail messages, because otherwise I am > afraid that many points might be lost. > > I believe that the document structure causes the > document to lose effectiveness. It can be improved by > some pretty basic reorganization: > > - The "Changes" sections should be moved into an > appendix (or multiple appendices) > > - The "Acknowledgement" section (currently 1.4) should > be moved to be the last section before the normative > references. > > - In Section (2), the first part of the section should > itemize the list of root causes, e.g.: > = Unclear Mission > = Poor Use of Effective Engineering Practice > = Standards Process Abuse > = Workload exceeds available staffing levels > = Unsuitable Management Structure > = Poor WG dynamics > = Inadequate Staff Preparation > > This text should be placed before section 2.1. Agreed. Note that we should probably publish this document as soon as possible, and get to the next step (see the thread about needless continuous refinement). But the above modifications are very easy and they should be done to get the point across better. --Jari From problem-statement-bounces@alvestrand.no Tue Oct 7 11:07:57 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05931 for ; Tue, 7 Oct 2003 11:07:57 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id B1EAD61C1D; Tue, 7 Oct 2003 17:07:34 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by eikenes.alvestrand.no (Postfix) with ESMTP id 6A54461C1A for ; Tue, 7 Oct 2003 17:07:32 +0200 (CEST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h97F7SN18892; Tue, 7 Oct 2003 08:07:28 -0700 X-mProtect: <200310071507> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (10.241.52.1, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpd8lTEie; Tue, 07 Oct 2003 08:07:25 PDT Message-ID: <3F82D694.8080300@iprg.nokia.com> Date: Tue, 07 Oct 2003 08:07:00 -0700 From: Charlie Perkins Organization: Nokia User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Brian E Carpenter References: <4103264BC8D3D51180B7002048400C450162382C@zhard0jd.europe.nortel.com> <3F81FE6D.3000703@iprg.nokia.com> <3F82C2AD.E3B43FD5@zurich.ibm.com> In-Reply-To: <3F82C2AD.E3B43FD5@zurich.ibm.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: problem-statement@alvestrand.no Subject: Re: Comments on the Problem Statement draft: Document structure X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit Hello Brian, If there are situations listed that aren't solvable problems, then the document shouldn't contain them because the solutionists will be wasting their time. If there are problems that aren't listed, then I should think they need to be listed if they are serious, but as you point out a decision has eventually to made about whether the serious problems have all been identified. The editorial suggestions are typically easy to incorporate. I don't think my editorial suggestions, or even substantive comments, would materially delay the progress of this document. At least, I don't expect to be making any attempt to delay the document. I wish that I had been able to make these comments much earlier, but better late than never. Or, what in the heck is the purpose of Last Call??! Regards, Charlie P. Brian E Carpenter wrote: >Charlie has spent a lot of time on this draft. But (and I suspect I am >repeating myself) I believe we are way beyond the point of diminishing >returns with this document. I believe, although I have my own quibbles, >that we should stop investing effort in polishing it. It is a document >of *no* long-term value; its value lies in triggering remedial action, >and that is where all our effort should now go. > > Brian > >Charlie Perkins wrote: > > >>Hello folks, >> >>I have some comments on the draft. I'll break it down into >>three different e-mail messages, because otherwise I am >>afraid that many points might be lost. >> >>I believe that the document structure causes the >>document to lose effectiveness. It can be improved by >>some pretty basic reorganization: >> >>- The "Changes" sections should be moved into an >> appendix (or multiple appendices) >> >>- The "Acknowledgement" section (currently 1.4) should >> be moved to be the last section before the normative >> references. >> >>- In Section (2), the first part of the section should >> itemize the list of root causes, e.g.: >> = Unclear Mission >> = Poor Use of Effective Engineering Practice >> = Standards Process Abuse >> = Workload exceeds available staffing levels >> = Unsuitable Management Structure >> = Poor WG dynamics >> = Inadequate Staff Preparation >> >>This text should be placed before section 2.1. >> >>I know that the IETF participants are "Staff", because >>I have two IETF t-shirts that say so. Also I would >>strongly encourage _short_ formulations for the "root >>causes", because long rambling formulations just don't >>get the point across anywhere near as well. >> >>A statement is made that the "Unclear Mission" root >>cause is the "fundamental" cause. I don't believe it. >>I think it's much more a case of arbitrary procedures >>applied selectively according to circumstance and >>personal preference. When I discuss with people at >>the IETF, I may often hear a point of view that I don't >>agree with. But I rarely would characterize it as not >>having a clue about mission. Without formulating a >>proposed "mission statement" to try to prove my >>point, I would at least like to strongly suggest that the >>characterization in section 2., preceding section 2.1, >>is wrong. If I had to pick out a more fundamental >>root cause, it would be "Unsuitable Management >>Structure", at least from the current formulation for >>the set of root causes. >> >>Thus, I would suggest demoting section 2.2 to be placed >>_much_ later in section 2. >> >>More in another e-mail coming shortly. >> >>Regards, >>Charlie P. >> >> > > > From problem-statement-bounces@alvestrand.no Tue Oct 7 11:51:01 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09175 for ; Tue, 7 Oct 2003 11:51:00 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 20C9261C1D; Tue, 7 Oct 2003 17:50:38 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by eikenes.alvestrand.no (Postfix) with ESMTP id 87BA061C1A for ; Tue, 7 Oct 2003 17:50:36 +0200 (CEST) Message-ID: <007201c38cea$c9f94ba0$956015ac@dclkempt40> From: "James Kempf" To: "Charlie Perkins" , "Problem Statement Working Group" References: <3F822246.404@iprg.nokia.com> Date: Tue, 7 Oct 2003 08:50:51 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Subject: Re: Ownership and "cross-licensing" of protocols by working groups X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit > What happens, is that WG-A can, and does, refuse to ratify > even the most minor changes needed by WG-B. Then, WG-B > has to go back to the drawing boards, losing valuable time and/or > features. > > Specific areas where I have seen this occur include: > - security(IPsec), and > - neighborhood determination in IPv6 > I would be amazed if these are the only examples. > > Therefore for self-preservation, an IETF working group > should _never_ try to use a protocol for which it does not > own complete change control. > > Or else, we could have a statement by the IAB that mandated > more flexibility by working groups whose outputs MIGHT be > useful by someone else in the universe. I exaggerate. mea culpa. > I get aggravated thinking about it. > A recent counterexample is the router certificate profile for SEND. The PKIX WG has standardized an X.509 profile for routers that was originally intended for SBGP but will work for SEND as well. The SEND WG has adopted it, so the IETF now has an integrated certificate hierarchy for routers. The downside, of course, is that the SEND draft is now dependent on the PKIX draft, since the PKIX draft is normative. My personal opinion is that it is this which primarily acts as an incentive for WGs to try to minimize dependencies with other WGs. Success for a WG is getting your documents published as an RFC, and if you write in a dependency with ongoing work, essentially you've handed the keys to your succes to the other WG. But I agree that this is a problem that results in designs which are less clean and less integrated than could be the case. jak From problem-statement-bounces@alvestrand.no Tue Oct 7 12:09:38 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10095 for ; Tue, 7 Oct 2003 12:09:38 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 5089261C1D; Tue, 7 Oct 2003 18:09:16 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by eikenes.alvestrand.no (Postfix) with ESMTP id 4ED3261C1A for ; Tue, 7 Oct 2003 18:09:14 +0200 (CEST) Message-ID: <011f01c38ced$64a37e80$956015ac@dclkempt40> From: "James Kempf" To: , "Charlie Perkins" References: <3F822045.7040208@iprg.nokia.com> <3F82C2DB.7010702@piuha.net> Date: Tue, 7 Oct 2003 09:09:31 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Cc: Problem Statement Working Group Subject: Re: More detailed comments on the Problem Statement document X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit Jari, > Hmm... I agree that this is what appears to be happening now. > I would actually prefer to see a more "planned" approach where > we publish roadmaps for some developments that we foresee. For instance, > is there an IETF/IAB/IESG plan for dealing with "wireless"? We certainly > are doing a lot of work in this space, but I think it would be beneficial > if we developed a roadmap of things we need to do for the "wireless" in > the next 2-5 years. This would benefit both external parties, as they could > learn what we intend to do, as well as ourselves in terms of making it > clearer how we are doing, and how much more work remains. > While I agree that this would be useful, it isn't typically how IETF has worked. New work in IETF is driven by a community of interest that wants to do it. Suppose IESG/IAB published such a roadmap and nobody showed up to do the work? There are already problems with lots of enthusiasm and support during a BOF, then people slowly vanishing until, by the end of a WG, it's only the chairs who are doing any work. I suspect any attempt to publish such a roadmap would only make this problem worse. jak From problem-statement-bounces@alvestrand.no Tue Oct 7 15:08:32 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17376 for ; Tue, 7 Oct 2003 15:08:31 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 8832261C1D; Tue, 7 Oct 2003 21:08:08 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from athene.wz-berlin.de (athene.wz-berlin.de [193.174.6.3]) by eikenes.alvestrand.no (Postfix) with ESMTP id 3872A61C13 for ; Tue, 7 Oct 2003 21:08:06 +0200 (CEST) Received: from medea.wz-berlin.de ([193.174.6.5]) by athene.wz-berlin.de with esmtp (Exim 4.24) id 1A6xBk-0003fF-ST; Tue, 07 Oct 2003 21:08:04 +0200 Received: from ERDE/SpoolDir by medea.wz-berlin.de (Mercury 1.48); 7 Oct 03 21:08:05 +0200 Received: from SpoolDir by ERDE (Mercury 1.48); 7 Oct 03 21:07:38 +0200 From: "Jeanette Hofmann" Organization: Wissenschaftszentrum Berlin To: problem-statement@alvestrand.no, Brian E Carpenter Date: Tue, 07 Oct 2003 21:07:35 +0200 MIME-Version: 1.0 Message-ID: <3F832B1B.32020.20D9B5C@localhost> Priority: normal In-reply-to: <3F82C2AD.E3B43FD5@zurich.ibm.com> X-mailer: Pegasus Mail for Windows (v4.12a) Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Content-description: Mail message body X-WZB-Virus-Scanned: by McAfee VirusScan at athene.wz-berlin.de Subject: Re: Comments on the Problem Statement draft: Document structure X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7BIT On 7 Oct 2003 at 15:42, Brian E Carpenter wrote: > Charlie has spent a lot of time on this draft. But (and I suspect I am > repeating myself) I believe we are way beyond the point of diminishing > returns with this document. I believe, although I have my own quibbles, > that we should stop investing effort in polishing it. It is a document > of *no* long-term value; While I agree with you that polishing efforts don't increase the usefulness of the draft, I would hope that it does have some long-term value. After all it is the first document in many years that lists in a systematic way operational and structural problems of the IETF. As some have remarked during the process of putting this draft together, a relevant number of problems was already known in 1992 around the Kobe events. The IETF has not much organizational memory, at least not in a written, systematic way. Likewise, the IETF's understanding of its own change seems rather anecdotical. In order to foster learning processes, drafts such as Elwyn's problem-issue statement should be ascribed a long-term value. I also don't mind a few repetitions and redundancies in the draft. They make the whole text more understandable for outsiders and newcomers, who might struggle with some of the problems discussed in the document. Jeanette its value lies in triggering remedial action, > and that is where all our effort should now go. > > Brian > > Charlie Perkins wrote: > > > > Hello folks, > > > > I have some comments on the draft. I'll break it down into > > three different e-mail messages, because otherwise I am > > afraid that many points might be lost. > > > > I believe that the document structure causes the > > document to lose effectiveness. It can be improved by > > some pretty basic reorganization: > > > > - The "Changes" sections should be moved into an > > appendix (or multiple appendices) > > > > - The "Acknowledgement" section (currently 1.4) should > > be moved to be the last section before the normative > > references. > > > > - In Section (2), the first part of the section should > > itemize the list of root causes, e.g.: > > = Unclear Mission > > = Poor Use of Effective Engineering Practice > > = Standards Process Abuse > > = Workload exceeds available staffing levels > > = Unsuitable Management Structure > > = Poor WG dynamics > > = Inadequate Staff Preparation > > > > This text should be placed before section 2.1. > > > > I know that the IETF participants are "Staff", because > > I have two IETF t-shirts that say so. Also I would > > strongly encourage _short_ formulations for the "root > > causes", because long rambling formulations just don't > > get the point across anywhere near as well. > > > > A statement is made that the "Unclear Mission" root > > cause is the "fundamental" cause. I don't believe it. > > I think it's much more a case of arbitrary procedures > > applied selectively according to circumstance and > > personal preference. When I discuss with people at > > the IETF, I may often hear a point of view that I don't > > agree with. But I rarely would characterize it as not > > having a clue about mission. Without formulating a > > proposed "mission statement" to try to prove my > > point, I would at least like to strongly suggest that the > > characterization in section 2., preceding section 2.1, > > is wrong. If I had to pick out a more fundamental > > root cause, it would be "Unsuitable Management > > Structure", at least from the current formulation for > > the set of root causes. > > > > Thus, I would suggest demoting section 2.2 to be placed > > _much_ later in section 2. > > > > More in another e-mail coming shortly. > > > > Regards, > > Charlie P. > > -- > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - > Brian E Carpenter > Distinguished Engineer, Internet Standards & Technology, IBM > > NEW ADDRESS PLEASE UPDATE ADDRESS BOOK From problem-statement-bounces@alvestrand.no Fri Oct 10 12:22:26 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05609 for ; Fri, 10 Oct 2003 12:22:25 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 7069A61B9F; Fri, 10 Oct 2003 18:22:02 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from sj-iport-3.cisco.com (sj-iport-3-in.cisco.com [171.71.176.72]) by eikenes.alvestrand.no (Postfix) with ESMTP id E186961B8C for ; Fri, 10 Oct 2003 18:21:59 +0200 (CEST) Received: from cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 10 Oct 2003 09:30:30 -0700 Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id h9AGLvXg003454 for ; Fri, 10 Oct 2003 09:21:58 -0700 (PDT) Received: from cisco.com (stealth-10-32-241-45.cisco.com [10.32.241.45]) by mira-sjc5-c.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with SMTP id ANA29330; Fri, 10 Oct 2003 09:21:56 -0700 (PDT) Date: Fri, 10 Oct 2003 12:21:55 -0400 Mime-Version: 1.0 (Apple Message framework v552) Content-Type: text/plain; charset=US-ASCII; format=flowed From: Melinda Shore To: problem-statement@alvestrand.no Content-Transfer-Encoding: 7bit Message-Id: X-Mailer: Apple Mail (2.552) Subject: Process document X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit It's been extraordinarily difficult to excite the interest of working group participants about the process document. The fact remains, however, that we have a charter commitment to produce a document describing a process for organizational change. We need to talk a bit about how to proceed. Broadly, we have two options: 1) produce a document, and 2) weasel out of producing a document (NOT THAT I'M BIASED). If there's a very strong sense that the latter is what the working group actively wants, we can discuss it with our Area Director. If we go forward with a process document we have several options for what to do, including 1) produce actual recommendations, several of which have been floated here, and 2) document what we've been doing, the ideas that have been proposed and rejected, and so on, and not produce any actual recommendations. Either way, we do need to come to some decisions about how to handle this document and a necessary step that we have to take right now is to get a sense of what working group participants are thinking about this, about how we're going to go about finishing up our work and closing down the working group, and about the change process in general. Melinda From problem-statement-bounces@alvestrand.no Sat Oct 11 16:55:39 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12598 for ; Sat, 11 Oct 2003 16:55:38 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 4C45B61BB4; Sat, 11 Oct 2003 22:55:15 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from EXECDSL.COM (ns.execdsl.net [208.184.15.238]) by eikenes.alvestrand.no (Postfix) with ESMTP id F3FE861BB3 for ; Sat, 11 Oct 2003 22:55:12 +0200 (CEST) Received: from [66.95.38.74] (HELO JLaptop.stevecrocker.com) by EXECDSL.COM (CommuniGate Pro SMTP 3.3) with ESMTP id 5600627 for problem-statement@alvestrand.no; Sat, 11 Oct 2003 16:55:12 -0400 Message-Id: <5.1.0.14.0.20031011165246.02048208@mail.stevecrocker.com> X-Sender: joel@stevecrocker.com@mail.stevecrocker.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Sat, 11 Oct 2003 16:54:50 -0400 To: problem-statement@alvestrand.no From: "Joel M. Halpern" In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: Process document X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no While I happen to think we are unlikely to be able to produce a useful (set of) recommendation(s), it is probably still worth trying. In contrast, producing a document about all the things we considered and all the manifold variations that did not produce a recommendation (if that is what happens) is not a useful document. Rather than trying to write such a document, if we can not produce useful recommendations we should admit that fact and close up. Yours, Joel M. Halpern At 12:21 PM 10/10/2003 -0400, Melinda Shore wrote: >Broadly, we have two options: 1) produce a document, and >2) weasel out of producing a document (NOT THAT I'M BIASED). >If there's a very strong sense that the latter is what the >working group actively wants, we can discuss it with our >Area Director. > >If we go forward with a process document we have several >options for what to do, including 1) produce actual >recommendations, several of which have been floated here, and >2) document what we've been doing, the ideas that have been >proposed and rejected, and so on, and not produce any >actual recommendations. From problem-statement-bounces@alvestrand.no Mon Oct 13 09:20:32 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03254 for ; Mon, 13 Oct 2003 09:20:31 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 80D6161C17; Mon, 13 Oct 2003 15:20:08 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from smail.alcatel.fr (colt-na165.alcatel.fr [62.23.212.165]) by eikenes.alvestrand.no (Postfix) with ESMTP id C365961BDA for ; Mon, 13 Oct 2003 15:20:05 +0200 (CEST) Received: from frmail31.netfr.alcatel.fr (frmail31.netfr.alcatel.fr [155.132.251.42]) by smail.alcatel.fr (ALCANET/NETFR) with ESMTP id h9DDJv4W007560; Mon, 13 Oct 2003 15:19:57 +0200 To: Brian E Carpenter X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: Alistair.Urie@alcatel.com Date: Mon, 13 Oct 2003 15:19:56 +0200 X-MIMETrack: Serialize by Router on FRMAIL31/FR/ALCATEL(Release 5.0.11 |July 24, 2002) at 10/13/2003 15:19:57 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii X-Virus-Scanned: by amavisd-new Cc: problem-statement@alvestrand.no Subject: Re: Ownership and "cross-licensing" of protocols by working groups X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Brian, I tend to agree with you on this. I was very worried about the -03 draft on this issue and had proposed changes to section 2.2. and 2.3. These are now, more or less, included in the 04 draft so I think we now need to move forward on fixing the problem since it is now captured well enough in the problem-statement I-D. As far as solving the problem of dependencies (both between WGs and between IETF and other SDOs) I would be VERY concerned about a solution that is based on "should _never_ try to use a protocol for which it does not own complete change control" since this implies that other SDOs should "never try to work with IETF" and likewise, other SDOs should stop trying to work with the IETF. A better, and more scalable, solution should be based on a mutual agreement on what is needed to be changed, why this is the correct route and when will the outputs (=RFC publication!) be expected. In other words, a way of formally agreeing that A is dependent on the work of B and that B both recognises this dependency and committs to deliver on time. That is, a "WG should never try to use a protocol for which it hasn't reach an agreement with the originating group" By the way, there are really two types of dependencies: Loose and Tight 1) Loose dependencies are ones that simply say the A recommends to use the next version of B. B agrees to do the extension but A doesn't really need to know the details of how it is done. This type of dependency is basically covered by an agreement on release date (in time or not for A) and reference (what does A write in its output to mean "the next release of B") 2 ) Tight dependencies are ones where A is building directly on the work of B and its own output needs to be adjusted after B completes its work. This type of dependency is more complex and often the work of A can be made more or less difficult if B choses to implement the extension in one way or another and so a system level design may be needed if we are to optimise the overal solution. - alistair Brian E Carpenter To: problem-statement@alvestrand.no Sent by: cc: problem-statement-bounces@al Subject: Re: Ownership and "cross-licensing" of protocols by working groups vestrand.no 07/10/2003 15:46 Getting back to Charlie's point (because we *can't* reform other bodies, but we *can* reform the IETF), isn't this in fact the same point that is made in section 2.3: > o The IETF is not consistently effective at resolving issues that > cross WG or area boundaries. > > o The IETF does not posess effective formal mechanisms for inter-WG > cooperation, coordination or communication, including the handling > of dependencies between deliverables and processes specified in in > WG charters. > > o The IETF does not have an effective means for defining > architectures and frameworks that will shape the work of multiple > WGs. Brian Spencer Dawkins wrote: > > Dear Graham, > > In my opinion, the real danger isn't another standards body planning > extensions to IETF protocols, it's another standards body dorking with > IETF protocols. The problem with SIP and 3GPP wasn't that 3GPP > extended SIP, it was that one group had headers classified as > mandatory that the other did not, so that an application that was > conformant for one group might send a request that an application > conformant for the other group would consider malformed. > > Don't get me wrong - I agree that if we solve some of the IETF > problems, we'll probably get more work than if we don't, and that's > especially true of the problem of committed interdependencies. I'm > saying that the problem with interdependencies isn't just that > interdependencies are harder, it's that interoperability is > jeopardized. > > Spencer > > ----- Original Message ----- > From: > To: ; > Sent: Tuesday, October 07, 2003 3:49 AM > Subject: RE: Ownership and "cross-licensing" of protocols by working > groups > > Charlie, > > I agree; but this problem doesn't just apply to internal IETF WG > relationships. The more that IETF protocols are used for applications > that are not strictly within the scope of the Internet, the more > important this issue becomes. > > Think about SIP and 3GPP. I now hear that the OMA is planning > extensions to SIP, which it has no intention of referring back to the > IETF. The IETF has to become more accommodating to the requirements > of other organisations, or this sort of thing will happen more and > more - and that's bad for ( nearly ) everyone. > > Regards, > > Graham Travers > > International Standards Manager > BT Exact > > e-mail: graham.travers@bt.com > tel: +44(0) 1359 235086 > mobile: +44(0) 7808 502536 > fax: +44(0) 1359 235087 > > HWB279, PO Box 200,London, N18 1ZF, UK > > BTexact Technologies is a trademark of British Telecommunications plc > Registered office: 81 Newgate Street London EC1A 7AJ > Registered in England no. 1800000 > > This electronic message contains information from British > Telecommunications plc which may be privileged or confidential. The > information is intended to be for the use of the individual(s) or > entity named above. If you are not the intended recipient be aware > that any disclosure, copying, distribution or use of the contents of > this information is prohibited. If you have received this electronic > message in error, please notify us by telephone or email (to the > numbers or address above) immediately. > > -----Original Message----- > From: Charlie Perkins [mailto:charliep@iprg.nokia.com] > Sent: 07 October 2003 03:18 > To: Problem Statement Working Group > Subject: Ownership and "cross-licensing" of protocols by working > groups > > Hello again folks, > > While reading section 2.3, I remembered a terrible problem > with cross-working-group interactions. Suppose that working > group A standardizes protocol A, and that working group B > needs the functionality of protocol A for the operation of the > protocol that is to become protocol B. One would think it should > be natural for WG-B to build on the work within WG-A. In fact, > one would think that WG-A would actively encourage the work > of WG-B. Unfortunately, this obvious strategy fails in practice, > for reasons that are unreasonably tedious and counterproductive > to the point of daffiness. > > What happens, is that WG-A can, and does, refuse to ratify > even the most minor changes needed by WG-B. Then, WG-B > has to go back to the drawing boards, losing valuable time and/or > features. > > Specific areas where I have seen this occur include: > - security(IPsec), and > - neighborhood determination in IPv6 > I would be amazed if these are the only examples. > > Therefore for self-preservation, an IETF working group > should _never_ try to use a protocol for which it does not > own complete change control. > > Or else, we could have a statement by the IAB that mandated > more flexibility by working groups whose outputs MIGHT be > useful by someone else in the universe. I exaggerate. mea culpa. > I get aggravated thinking about it. > > Regards, > Charlie P. -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Brian E Carpenter Distinguished Engineer, Internet Standards & Technology, IBM NEW ADDRESS PLEASE UPDATE ADDRESS BOOK From problem-statement-bounces@alvestrand.no Tue Oct 14 17:48:54 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04323 for ; Tue, 14 Oct 2003 17:48:53 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id B559661C19; Tue, 14 Oct 2003 23:48:31 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from halvestr-w2k1 (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 015B661C15; Tue, 14 Oct 2003 23:48:29 +0200 (CEST) Date: Tue, 14 Oct 2003 23:48:10 +0200 From: Harald Tveit Alvestrand To: ietf@ietf.org, problem-statement@alvestrand.no Message-ID: <157547561.1066175290@localhost> X-Mailer: Mulberry/3.1.0b8 (Win32) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="==========FE903CE760CF831D098F==========" Subject: IESG proposed statement on the IETF mission X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no --==========FE903CE760CF831D098F========== Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline Content-Transfer-Encoding: 7bit Greetings, As part of the discussions about change process within the IETF, the IESG has come to believe that a somewhat longer statement of the IETF's mission and social dynamics might provide useful context for the community's discussion. As part of that, we'd like to put the following document out for feedback. It incorporates lots of ideas and some text from existing RFCs and IETF web pages, but is more focused on change than those have been. We hope it captures a sense of the context of the work of improving the IETF, by capturing some of the social dynamics which have been an implicit part of the IETF's work and style over the years. We also hope that by making some of those implicit elements more explicit, we may find it easier to understand how to make changes that will "go with the grain" of the IETF's history and culture. We'd be happy to have feedback on it, either sent to the IETF list for public discussion or to the IESG. This is an informal piece of work, and may never be published in RFC form, but may rather appear on the IETF web pages somewhere. Your comments are welcome! Harald Alvestrand For the IESG --==========FE903CE760CF831D098F========== Content-Type: text/plain; charset=us-ascii; name="social-contract.txt" Content-Disposition: attachment; filename="social-contract.txt"; size=10544 Content-Transfer-Encoding: 7bit The IETF Mission and Social Contract Introduction ------------ The Internet Engineering Task Force (IETF) is a large open international community of network engineers concerned with the evolution of the Internet architecture and facilitating the operation of the Internet. In the seventeen years since thirty-odd engineers first met in a single room, the Internet and the IETF have grown considerably; the IETF is attempting to adapt to these changes. Most of the basic processes and the social contracts by which the IETF works, both formal and informal, were developed when it was a community of fifty to two hundred engineers. Much of its internal communication depended on long-term personal relationships and an implicit understanding of shared goals and culture. This has worked well for many years and much growth. The IETF has been and is a very successful organization, and has produced much serious work which has both furthered its own goals of Internet evolution and had a notable effect on global human society. The processes and social contracts that worked for fifty engineers have managed to sustain the IETF in dealing with a community of thousands of engineers and a greatly expanded technology and market space. However, while Dave Clark's famous saying "We do not believe in kings, presidents, or voting. We believe only in rough consensus and running code," is still a touchstone of the IETF culture, the rapid growth of participation in the IETF, the growth of the Internet itself, and the rapid integration of Internet technology in real-world markets and society in general are seriously straining the IETF's traditional understated and informal communication and methods. Though the process of organizational change has actually been going on continuously for a long time, it would be useful to state more formally many previously implicit understandings and to make explicit some previously informal processes. This note tries to lay the social foundation for that continuing journey. The IETF Mission ---------------- The IETF's mission has historically been embedded in a shared understanding that making engineering choices based on the long term interest of the Internet as a whole produces better long-term results for each participant than making choices based on short term considerations, because the value of those advantages is ultimately derived from the health of the whole. The long term interest of the Internet includes the premise that "the Internet is for everyone". Two years ago, the IESG felt that making the mission of the IETF more explicit was needed. The following terse statement has since been promulgated, first by IESG members and then by others: "The purpose of the IETF is to create high quality, relevant, and timely standards for the Internet." Note that this clearly positions the IETF primarily as a standards development organization. There are other activities in the IETF; but if the IETF does not do its core mission, all else will quickly fade. This is intended to be an ordered list of characteristics. Timely standards of low quality or that are irrelevant will not serve the Internet's or the IETF's needs. This leaves open the very interesting and difficult questions of how to measure quality, relevance, and timeliness. The IETF has identified interoperability, security, and scalability as essential, but without attaching measurements to those characteristics. It is important that this is "For the Internet," and does not include everything that happens to use IP. IP is being used in a myriad of real-world applications, such as controlling street lights, but the IETF does not standardize those applications. Supporting Missions ------------------- Historically, the IETF has also been a place for experimentation, both with protocols and with operational practices. Testbeds such as the mbone, 6bone, etc., have been born, coordinated within, and run in association with the IETF. Such efforts have been very useful in developing high quality relevant standards. The IETF has also had a strong operational component, with a tight bond, and hence coordination, between protocol developers and network operators, and has had many participants who did both. This has provided valuable feedback to allow correction of misguided standardization efforts, and has provided feedback to sort out which standards were actually needed. As the field has grown explosively, specialization has set in, and market pressures have risen, there has been less and less operator participation in the IETF. Social Dynamics --------------- Growth has stressed many parts of the IETF's social and procedural fabric, and it may be useful to consider some fundamental forces that are causing these stresses. As they are neither good nor bad, it is not appropriate to call them "problems;" rather think of them as social forces and dynamics. Scaling - Increased Participation The IETF is a semi-formal community of individual engineers, not of organizations, expert in and dedicated to the growth and technical development of the Internet. With the popularity and explosive growth of the Internet, the number and diversity of people wanting or needing to participate in the IETF has grown a hundredfold. Many of these have had experience in other standards orgizations with different operating procedures and focus. As good engineers, these new participants have opinions, want to contribute, need to find a place in the complex social and technology fabric, and, in general, want to join the jostle of a now large organization. As the size and scope of the IETF have increased, the informal mechanisms for incorporating new participants have been strained, often creating the appearance of opaque barriers to entry. Scaling - More Complex Technical Interactions The number and span of interacting technologies has made the IETF a far more complex work space, both technically and socially. A culture that worked for layers three and four and 50-300 engineers is being severely stretched working at layers one through nine. Furthermore, many new participants now come from a far wider set of disciplines, making integration more difficult. Scaling - More External Interactions As the Internet has become widely popular, it has become a serious marketplace and is being seen as the communication infrastructure of the future. This has drawn serious attention from external forces such as vendors, press, regulators, politicians, and other standards organizations, whose traditional work now interacts with that of the IETF. Often, the relationship turns out to be tangential, but it takes a long time to get all parties to see this. The resultant need for quality interaction with these external forces places new needs and stresses on the IETF's view of how it represents itself. Quality and Architectural Review With the increase in complexity, it has become increasingly difficult to maintain the high quality that the IETF has always demanded. A bit of engineering in one space can and usually does interact with many other components of the Internet, and thus requires deep multi-area review and consensus. This has been most easily seen with security and operational scaling considerations, but actually happens across the board. As the number of engineers and work areas increases, the number of documents increases, and the resulting importance of and interactions needed for inter-area quality coordination and review grows as a product of these forces. Replacing Personalities with Process As the IETF grows and evolves, leaders come and go. Hence, the organization needs processes to both ensure continuity as leaders succeed each other, and to ensure that the organization remains open and fair, and can continue to interact successfully with the more complex environment in which the IETF now operates. But Not Too Much Process On the other hand, the IETF culture has always been to have formal processes grow only as needed, and it has resisted unneeded formal structures as impeding timeliness and driving out key players. There is deep cultural distrust of 'professional standards goers', for Dave Clark's kings and presidents, and for institutional authority. Tension Among the Dynamics Many of the above dynamics are in tension with each other; the IETF can not always have its cake and eat it too. One of the most critical tensions is the increase in the number of documents and the need for cross-technology review. The number of articulate engineers who have wide technological span and can and will review a lot of documents is not growing as fast as the document count. Changing What We Can Change --------------------------------------------- These social dynamics can be seen as underlying drivers of many of the problems identified by those attempting to improve the IETF. As part of the effort to diagnose those problems, identifying which of the underlying forces are or are not within the control of the IETF is an important aspect of targeting change. For those within the control of the IETF, a relatively small but fundamental change may engender substantial improvements in a number of areas. For those outside of the control of the IETF, changes may need to focus on ameliorating symptoms of the underlying problem or on enabling the community to work within the identified constraints. As part of the ongoing effort to improve the IETF, there will always be a number of specific proposals coming forward for discussion. Some may ask the community to consider changes to existing assumptions or structures; others may be intended to provide specific solutions to problems which require them. As those proposals emerge, the first step must be to recognize that the IETF will change over time, both as the community's membership changes and as the work it does evolves. In adapting the mechanisms by which the IETF operates, we are simply recognizing that reality. No matter what type of change is proposed, however, it is essential to make sure that the IETF continues to serve its basic mission well. That mission not only supports an industry and enables a technology; it makes the IETF as a community more than the sum of its parts. --==========FE903CE760CF831D098F==========-- From problem-statement-bounces@alvestrand.no Tue Oct 14 18:26:21 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07440 for ; Tue, 14 Oct 2003 18:26:20 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id EC0DA61C13; Wed, 15 Oct 2003 00:25:58 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by eikenes.alvestrand.no (Postfix) with ESMTP id 556F861C0E for ; Wed, 15 Oct 2003 00:25:57 +0200 (CEST) Received: from [209.187.148.215] (helo=scan.jck.com) by bs.jck.com with esmtp (Exim 4.10) id 1A9Xc4-000H45-00; Tue, 14 Oct 2003 17:25:56 -0500 Date: Tue, 14 Oct 2003 18:25:56 -0400 From: John C Klensin To: Elwyn Davies , "IETF problem (problem-statement@alvestrand.no)" Message-ID: <101053977.1066155956@scan.jck.com> In-Reply-To: <4103264BC8D3D51180B7002048400C4501623805@zhard0jd.europe.nortel.com> References: <4103264BC8D3D51180B7002048400C4501623805@zhard0jd.eu rope.nortel.com> X-Mailer: Mulberry/3.1.0b8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: Re: New version (04) of Problem Issue Document on its way X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit My apologies for being so late in picking this up -- and my surprise that no one else has. My small excuse is that I am more comfortable raising it now that the person whose situation causes the comment is apparently on the road to a full recovery, for which I am personally very grateful. Problem: We have procedures for replacing an IESG member who resigns or otherwise becomes permanently unavailable. We have no mechanism for dealing with the situation of an IESG member who, due to illness or some other serious personal or professional condition, becomes unavailable for an extended period. It is unreasonable, and probably not in the IETF's best interest, to ask a person in that situation to step down. It is equally unreasonable to ask a co-AD, or someone else on the IESG, to pick up the load for an extended period of time (even though some co-ADs have done it, for which we should all be very grateful). So I suggest (this is a pointer, not a proposed solution) that we need to think about a mechanism by which, if an AD becomes temporarily incapacitated for a time and to a degree that the AD, or a co-AD, or the IESG (details to be worked out as part of the solution), anticipates will be problematic, a temporary replacement or can be selected and seated. If the disability is only partial (i.e., the AD can fulfill some, but not all, of his or her duties), there should be some way to select and seat an assistant or stand-in. I have no idea whether similar rules should be available for IAB members, but I suspect so. regards, john From problem-statement-bounces@alvestrand.no Tue Oct 14 23:31:46 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA15515 for ; Tue, 14 Oct 2003 23:31:45 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id B405D61B9C; Wed, 15 Oct 2003 05:31:23 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by eikenes.alvestrand.no (Postfix) with ESMTP id 7BF5F61B9B for ; Wed, 15 Oct 2003 05:31:21 +0200 (CEST) Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id h9F3VKd26445 for ; Wed, 15 Oct 2003 06:31:20 +0300 (EET DST) Received: from esebh004.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 15 Oct 2003 06:31:20 +0300 Received: from esebe009.NOE.Nokia.com ([172.21.138.41]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 15 Oct 2003 06:31:20 +0300 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe009.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 15 Oct 2003 06:31:19 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 15 Oct 2003 06:31:18 +0300 Message-ID: Thread-Topic: New version (04) of Problem Issue Document on its way Thread-Index: AcOSolOXSvT60aDyQVS0d38RsrpSowAKjHWw From: To: , , X-OriginalArrivalTime: 15 Oct 2003 03:31:19.0846 (UTC) FILETIME=[CC807460:01C392CC] Subject: RE: New version (04) of Problem Issue Document on its way X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: quoted-printable Hi John, > Problem: We have procedures for replacing an IESG member who=20 > resigns or otherwise becomes permanently unavailable. We have=20 > no mechanism for dealing with the situation of an IESG member=20 > who, due to illness or some other serious personal or=20 > professional condition, becomes unavailable for an extended=20 > period. It is unreasonable, and probably not in the IETF's=20 > best interest, to ask a person in that situation to step down.=20 > It is equally unreasonable to ask a co-AD, or someone else on=20 > the IESG, to pick up the load for an extended period of time=20 > (even though some co-ADs have done it, for which we should all=20 > be very grateful). >=20 > So I suggest (this is a pointer, not a proposed solution) that=20 > we need to think about a mechanism by which, if an AD becomes=20 > temporarily incapacitated for a time and to a degree that the=20 > AD, or a co-AD, or the IESG (details to be worked out as part of=20 > the solution), anticipates will be problematic, a temporary=20 > replacement or can be selected and seated. If the disability is=20 > only partial (i.e., the AD can fulfill some, but not all, of his=20 > or her duties), there should be some way to select and seat an=20 > assistant or stand-in. >=20 > I have no idea whether similar rules should be available for IAB=20 > members, but I suspect so. I agree with your point. In these type of circumstances, it can=20 also happen that WG chairs or authors depending upon the AD are unaware of the situation, creating a serious impediment for ensuring that work gets done. =20 John From problem-statement-bounces@alvestrand.no Wed Oct 15 01:42:13 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA18135 for ; Wed, 15 Oct 2003 01:42:12 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id C6E5061B9B; Wed, 15 Oct 2003 07:41:47 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from psg.com (psg.com [147.28.0.62]) by eikenes.alvestrand.no (Postfix) with ESMTP id F268B61B8A for ; Wed, 15 Oct 2003 07:41:46 +0200 (CEST) Received: from [147.28.0.62] (helo=acm.org) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1A9ePp-000CXy-Ad for problem-statement@alvestrand.no; Wed, 15 Oct 2003 05:41:45 +0000 Date: Wed, 15 Oct 2003 14:40:48 +0900 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) From: Avri Doria To: problem-statement@alvestrand.no Content-Transfer-Encoding: 7bit In-Reply-To: Message-Id: <2114B480-FED2-11D7-897E-000393CC2112@acm.org> X-Mailer: Apple Mail (2.552) Subject: Re: New version (04) of Problem Issue Document on its way X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit I am wondering whether this is not an aspect of the too few doing too much issue that is documented. if everyone wasn't already overloaded with work then covering an absence should not be too much stress on the system. On onsdag, okt 15, 2003, at 12:31 Asia/Seoul, wrote: >> >> So I suggest (this is a pointer, not a proposed solution) that >> we need to think about a mechanism by which, if an AD becomes >> temporarily incapacitated for a time and to a degree that the >> AD, or a co-AD, or the IESG (details to be worked out as part of >> the solution), anticipates will be problematic, a temporary >> replacement or can be selected and seated. If the disability is >> only partial (i.e., the AD can fulfill some, but not all, of his >> or her duties), there should be some way to select and seat an >> assistant or stand-in. >> out of curiosity is there a rule that currently forbids the IESG from bringing in someone for a temporary task, including this one, should they desire to do so. or that forbids an AD from appointing an assistant to help in times of stress? or that forbids the IAB from bringing in an observer/consultant for any purpose they may decide needs doing. >> I have no idea whether similar rules should be available for IAB >> members, but I suspect so. > > I agree with your point. In these type of circumstances, it can > also happen that WG chairs or authors depending upon the AD > are unaware of the situation, creating a serious impediment for > ensuring that work gets done. > > John > From problem-statement-bounces@alvestrand.no Wed Oct 15 04:14:47 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA19975 for ; Wed, 15 Oct 2003 04:14:46 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 0DFC261B8B; Wed, 15 Oct 2003 10:14:22 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from noxmail.sandelman.ottawa.on.ca (noxmail.sandelman.ottawa.on.ca [205.150.200.166]) by eikenes.alvestrand.no (Postfix) with ESMTP id BB94F61B9B; Wed, 15 Oct 2003 04:45:57 +0200 (CEST) Received: from lox.sandelman.ottawa.on.ca (IDENT:root@lox.sandelman.ottawa.on.ca [205.150.200.178]) by noxmail.sandelman.ottawa.on.ca (8.11.6p3/8.11.6) with ESMTP id h9F2maG00264 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified NO); Tue, 14 Oct 2003 22:48:47 -0400 (EDT) Received: from sandelman.ottawa.on.ca (fctn1-2531.nb.aliant.net [156.34.217.227]) by lox.sandelman.ottawa.on.ca (8.11.6p3/8.11.6) with ESMTP id h9F2Iie17828; Tue, 14 Oct 2003 22:18:44 -0400 (EDT) Received: from marajade.sandelman.ottawa.on.ca (marajade [127.0.0.1]) by sandelman.ottawa.on.ca (8.12.3/8.12.3/Debian-6.6) with ESMTP id h9F0bxcw005441 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Tue, 14 Oct 2003 21:38:00 -0300 Received: from marajade.sandelman.ottawa.on.ca (mcr@localhost) by marajade.sandelman.ottawa.on.ca (8.12.3/8.12.3/Debian-6.6) with ESMTP id h9F0bkvG005434; Tue, 14 Oct 2003 21:37:59 -0300 To: Harald Tveit Alvestrand In-reply-to: Your message of "Tue, 14 Oct 2003 23:48:10 +0200." <157547561.1066175290@localhost> Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Tue, 14 Oct 2003 21:37:46 -0300 Message-ID: <5433.1066178266@marajade.sandelman.ottawa.on.ca> From: Michael Richardson X-Mailman-Approved-At: Wed, 15 Oct 2003 10:14:21 +0200 Cc: problem-statement@alvestrand.no Subject: Re: IESG proposed statement on the IETF mission X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no >>>>> "Harald" == Harald Tveit Alvestrand writes: Harald> sort out which standards were actually needed. As the field has Harald> grown explosively, specialization has set in, and market pressures Harald> have risen, there has been less and less operator participation in Harald> the IETF. I'm unclear if this documents thinks this is a good thing or a bad thing. I think that it is a bad thing. ] Collecting stories about my dad: http://www.sandelman.ca/cjr/ | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another NetBSD/notebook using, kernel hacking, security guy"); [ From problem-statement-bounces@alvestrand.no Wed Oct 15 04:39:51 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA20471 for ; Wed, 15 Oct 2003 04:39:50 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 5ED3061BA0; Wed, 15 Oct 2003 10:39:26 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from halvestr-w2k1 (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id A233261B8A; Wed, 15 Oct 2003 10:39:24 +0200 (CEST) Date: Wed, 15 Oct 2003 09:35:24 +0200 From: Harald Tveit Alvestrand To: Michael Richardson Message-ID: <192781875.1066210524@localhost> In-Reply-To: <5433.1066178266@marajade.sandelman.ottawa.on.ca> References: <5433.1066178266@marajade.sandelman.ottawa.on.ca> X-Mailer: Mulberry/3.1.0b8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Cc: problem-statement@alvestrand.no Subject: Re: IESG proposed statement on the IETF mission X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit It is a bad thing. But we saw in Vienna that the exodus is far from complete yet. So it could be worse.... --On 14. oktober 2003 21:37 -0300 Michael Richardson wrote: > >>>>>> "Harald" == Harald Tveit Alvestrand writes: > Harald> sort out which standards were actually needed. As the field > has Harald> grown explosively, specialization has set in, and market > pressures Harald> have risen, there has been less and less operator > participation in Harald> the IETF. > > I'm unclear if this documents thinks this is a good thing or a bad > thing. I think that it is a bad thing. > > ] Collecting stories about my dad: http://www.sandelman.ca/cjr/ | > firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON > |net architect[ ] mcr@sandelman.ottawa.on.ca > http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another > NetBSD/notebook using, kernel hacking, security guy"); [ > > From problem-statement-bounces@alvestrand.no Wed Oct 15 04:57:12 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA20989 for ; Wed, 15 Oct 2003 04:57:11 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id D5BD461B9E; Wed, 15 Oct 2003 10:56:47 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from i2kc05-ukbr.domain1.systemhost.net (unknown [217.32.164.139]) by eikenes.alvestrand.no (Postfix) with ESMTP id C840261B8A; Wed, 15 Oct 2003 10:56:44 +0200 (CEST) Received: from i2km96-ukbr.domain1.systemhost.net ([193.113.197.84]) by i2kc05-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(5.0.2195.6713); Wed, 15 Oct 2003 09:56:44 +0100 Received: from i2km02-ukbr.domain1.systemhost.net ([193.113.197.79]) by i2km96-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(5.0.2195.6713); Wed, 15 Oct 2003 09:56:43 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 15 Oct 2003 09:56:42 +0100 Message-ID: <3D67CCA7D63E714B980D21A038EEA08E059276AB@i2km02-ukbr.domain1.systemhost.net> Thread-Topic: IESG proposed statement on the IETF mission Thread-Index: AcOS99vhEOzaVpyrSVasm1U7od+4xQAAFhjQ From: To: , X-OriginalArrivalTime: 15 Oct 2003 08:56:43.0737 (UTC) FILETIME=[41A5CC90:01C392FA] Cc: problem-statement@alvestrand.no Subject: RE: IESG proposed statement on the IETF mission X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: quoted-printable Harald & Michael, It's *getting* worse ! =20 A few years ago one operator was prepared to fund about 20 individuals = to participate in the IETF; now that's reduced to about 5, with no = guarantee that such a level will be sustained. This is not just about the downturn in the industry. Real problems that = operators have are not being addressed by the IETF. If the IETF won't = address my concerns, and if I have to go to the OMA to meet my = requirements for application protocols, for example, that's where I'll = go. You may say "That's fine". OK, if that's the policy. But, then, don't = be surprised if it happens ! Regards, Graham Travers International Standards Manager BT Exact e-mail: graham.travers@bt.com tel: +44(0) 1359 235086 mobile: +44(0) 7808 502536 fax: +44(0) 1359 235087 HWB279, PO Box 200,London, N18 1ZF, UK BTexact Technologies is a trademark of British Telecommunications plc Registered office: 81 Newgate Street London EC1A 7AJ Registered in England no. 1800000 This electronic message contains information from British = Telecommunications plc which may be privileged or confidential. The = information is intended to be for the use of the individual(s) or entity = named above. If you are not the intended recipient be aware that any = disclosure, copying, distribution or use of the contents of this = information is prohibited. If you have received this electronic message = in error, please notify us by telephone or email (to the numbers or = address above) immediately. =20 -----Original Message----- From: Harald Tveit Alvestrand [mailto:harald@alvestrand.no] Sent: 15 October 2003 08:35 To: Michael Richardson Cc: problem-statement@alvestrand.no Subject: Re: IESG proposed statement on the IETF mission=20 It is a bad thing. But we saw in Vienna that the exodus is far from complete yet. So it = could=20 be worse.... --On 14. oktober 2003 21:37 -0300 Michael Richardson=20 wrote: > >>>>>> "Harald" =3D=3D Harald Tveit Alvestrand = writes: > Harald> sort out which standards were actually needed. As the = field > has Harald> grown explosively, specialization has set in, and = market > pressures Harald> have risen, there has been less and less = operator > participation in Harald> the IETF. > > I'm unclear if this documents thinks this is a good thing or a bad > thing. I think that it is a bad thing. > > ] Collecting stories about my dad: http://www.sandelman.ca/cjr/ | > firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, = ON > |net architect[ ] mcr@sandelman.ottawa.on.ca > http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just = another > NetBSD/notebook using, kernel hacking, security guy"); [ > > From problem-statement-bounces@alvestrand.no Wed Oct 15 05:23:02 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA21716 for ; Wed, 15 Oct 2003 05:23:00 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 3AB5A61C05; Wed, 15 Oct 2003 11:22:37 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from halvestr-w2k1 (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 19B8861B8A; Wed, 15 Oct 2003 11:22:32 +0200 (CEST) Date: Wed, 15 Oct 2003 11:22:32 +0200 From: Harald Tveit Alvestrand To: graham.travers@bt.com, mcr@sandelman.ottawa.on.ca Message-ID: <199210068.1066216952@halvestr-w2k1> In-Reply-To: <3D67CCA7D63E714B980D21A038EEA08E059276AB@i2km02-ukbr.domain1.systemhost.net> References: <3D67CCA7D63E714B980D21A038EEA08E059276AB@i2km02-ukbr.domain1.sy stemhost.net> X-Mailer: Mulberry/3.1.0b8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Cc: problem-statement@alvestrand.no Subject: RE: IESG proposed statement on the IETF mission X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit --On 15. oktober 2003 09:56 +0100 graham.travers@bt.com wrote: > Harald & Michael, > > It's *getting* worse ! > > A few years ago one operator was prepared to fund about 20 individuals to > participate in the IETF; now that's reduced to about 5, with no > guarantee that such a level will be sustained. > > This is not just about the downturn in the industry. Real problems that > operators have are not being addressed by the IETF. If the IETF won't > address my concerns, and if I have to go to the OMA to meet my > requirements for application protocols, for example, that's where I'll go. > > You may say "That's fine". OK, if that's the policy. But, then, don't > be surprised if it happens ! Graham, thanks for your input! it would be nice if you could name examples - since I'm not an operator and have rarely been on the forefront of the debates where you have been engaged, I don't have enough background to evaluate the experiences you're sharing. In particular, I'm interested in hearing your requirements for applications protocols - both because I come from an applications background myself and believe the applications perspective to be important for the IETF, and because the proper boundary between "IETF work" and "application space work" is one of the long-simmering (long-festering?) debates that the IETF has never been able to come to resolution on. Harald From problem-statement-bounces@alvestrand.no Wed Oct 15 06:47:41 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA24143 for ; Wed, 15 Oct 2003 06:47:40 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id F147861C0A; Wed, 15 Oct 2003 12:47:16 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from i2kc01-ukbr.domain1.systemhost.net (unknown [217.32.164.137]) by eikenes.alvestrand.no (Postfix) with ESMTP id CFFF261B8A; Wed, 15 Oct 2003 12:47:12 +0200 (CEST) Received: from i2km99-ukbr.domain1.systemhost.net ([193.113.197.31]) by i2kc01-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(5.0.2195.6713); Wed, 15 Oct 2003 11:47:12 +0100 Received: from i2km02-ukbr.domain1.systemhost.net ([193.113.197.79]) by i2km99-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(5.0.2195.6713); Wed, 15 Oct 2003 11:47:10 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 15 Oct 2003 11:47:09 +0100 Message-ID: <3D67CCA7D63E714B980D21A038EEA08E059276AC@i2km02-ukbr.domain1.systemhost.net> Thread-Topic: IESG proposed statement on the IETF mission Thread-Index: AcOS/eBSBFOeHIF9R5mMG/+MMbPcZQAA9qCw From: To: , X-OriginalArrivalTime: 15 Oct 2003 10:47:10.0854 (UTC) FILETIME=[AFB79A60:01C39309] Cc: problem-statement@alvestrand.no Subject: RE: IESG proposed statement on the IETF mission X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: quoted-printable Harald, OK, since you ask so nicely. 8o) I'll amplify my comments in the full realisation that the last time I = mentioned that I have people working for me, I was practically accused = of being the Capitalist exploiter of slave labour ! There are two specific examples, where I supported issues being brought = to the IETF, and where I was prepared to put *real* effort into helping = to find solutions. (I mean actual resources to edit documents, chair = meetings, etc.) 1. Operations and maintenance support for MPLS. I went so far as to (be able to) run a BOF on this one (not me = personally). Despite a lot of interest at the BOF, and a stream of = "operator people" at the microphone supporting the view that the = functionality was needed, nothing useful transpired. Sure, the issue = was referred to the MPLS WG for consideration - and no doubt they = considered a lot - but the end result wasn't much use to me. It's now = been addressed elsewhere. This operator just can't afford to run = protocols which don't allow it to know what control it has. 2. Midcom. Some of my colleagues and I were instrumental in bringing this issue to = the IETF, and, sure enough, a WG was formed. While the analysis of = existing protocols was useful, after several years I still don't see any = standardised solution that I can/should use. Midcom is still running, = so I suppose that it hasn't finished its work yet. I'm still interested = in having a solution to this issue, but in the operator world time = presses. Please understand that I'm *NOT* condemning the IETF for choosing its = work items. I am simply explaining that when something is needed, if it = can't be sourced from one supplier (the IETF) the purchaser has to find = another supplier, if possible (insert the name of any suitable SDO = here!). As far as applications protocols go, I don't have any specific = requirements in mind. I mentioned that as an example since I've heard = (not first-hand) that the OMA is planning protocol developments, which = will not be referred to the IETF. One specific example that I mentioned = earlier is SIP. =20 Brian Carpenter's response to this was to say that we can't control what = other SDO's do. =20 While this may be technically true, I don't think that the IETF is = without influence. Whether it wants to use that influence, even in an = advisory capacity, is up for debate, I guess. As the standards that it = produces increasingly impinge on aspects of society other than the = Internet (the IESG proposed Statement mentions "controlling street = lights" ), the IETF has to either assume the responsibility of = maintaining them for uses outside the Internet, or abrogate that = responsibility and let other organisations do what they will with them. = The "ultra-Internet" interests will not be stopped, if they really want = a solution. IMHO, to mangle a famous saying: "No SDO is an island." The = International Standards Community comprises many standards bodies, which = have to cooperate to achieve useful solutions. Where would the Internet = be if there were no standards for electricity supply, or cable capacity, = or even time and date ? The most important thing about a standard is = not that the solution is necessarily the best one, but that it is the = *agreed* one. If we start to have different versions of SIP, for = example - the IETF version, the 3GPP version, the OMA version - where is = the standard, then ? BTW, when is an application not an application ? What are the = characteristics that make "controlling street lights" less of an = application than (say) calendaring and scheduling? I don't expect an = answer, but there must be some differentiator, if they both use the = Internet as a transport mechanism. If the IETF has, or is developing, = such differentiators, it would be useful to have them published. If it = hasn't, that may help to explain why there's been such a long-running = debate. Regards, Graham Travers International Standards Manager BT Exact e-mail: graham.travers@bt.com tel: +44(0) 1359 235086 mobile: +44(0) 7808 502536 fax: +44(0) 1359 235087 HWB279, PO Box 200,London, N18 1ZF, UK BTexact Technologies is a trademark of British Telecommunications plc Registered office: 81 Newgate Street London EC1A 7AJ Registered in England no. 1800000 This electronic message contains information from British = Telecommunications plc which may be privileged or confidential. The = information is intended to be for the use of the individual(s) or entity = named above. If you are not the intended recipient be aware that any = disclosure, copying, distribution or use of the contents of this = information is prohibited. If you have received this electronic message = in error, please notify us by telephone or email (to the numbers or = address above) immediately. =20 ----Original Message----- From: Harald Tveit Alvestrand [mailto:harald@alvestrand.no] Sent: 15 October 2003 10:23 To: Travers,G,Graham,XVT TRAVERG R; mcr@sandelman.ottawa.on.ca Cc: problem-statement@alvestrand.no Subject: RE: IESG proposed statement on the IETF mission=20 --On 15. oktober 2003 09:56 +0100 graham.travers@bt.com wrote: > Harald & Michael, > > It's *getting* worse ! > > A few years ago one operator was prepared to fund about 20 individuals = to > participate in the IETF; now that's reduced to about 5, with no > guarantee that such a level will be sustained. > > This is not just about the downturn in the industry. Real problems = that > operators have are not being addressed by the IETF. If the IETF won't > address my concerns, and if I have to go to the OMA to meet my > requirements for application protocols, for example, that's where I'll = go. > > You may say "That's fine". OK, if that's the policy. But, then, = don't > be surprised if it happens ! Graham, thanks for your input! it would be nice if you could name examples - since I'm not an operator = and=20 have rarely been on the forefront of the debates where you have been=20 engaged, I don't have enough background to evaluate the experiences = you're=20 sharing. In particular, I'm interested in hearing your requirements for = applications=20 protocols - both because I come from an applications background myself = and=20 believe the applications perspective to be important for the IETF, and=20 because the proper boundary between "IETF work" and "application space=20 work" is one of the long-simmering (long-festering?) debates that the = IETF=20 has never been able to come to resolution on. Harald From problem-statement-bounces@alvestrand.no Wed Oct 15 09:51:06 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29636 for ; Wed, 15 Oct 2003 09:51:05 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id D8E0E61B9B; Wed, 15 Oct 2003 15:50:41 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by eikenes.alvestrand.no (Postfix) with ESMTP id 8B4E161B89; Wed, 15 Oct 2003 15:50:38 +0200 (CEST) Received: from cisco.com (erosen-u10.cisco.com [161.44.70.36]) by rtp-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h9FDoYlb019613; Wed, 15 Oct 2003 09:50:34 -0400 (EDT) Message-Id: <200310151350.h9FDoYlb019613@rtp-core-2.cisco.com> To: graham.travers@bt.com In-reply-to: Your message of Wed, 15 Oct 2003 11:47:09 +0100. <3D67CCA7D63E714B980D21A038EEA08E059276AC@i2km02-ukbr.domain1.systemhost.net> User-Agent: EMH/1.14.1 SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (=?ISO-8859-4?Q?Unebigory=F2mae?=) APEL/10.3 Emacs/21.3 (sparc-sun-solaris2.8) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII Date: Wed, 15 Oct 2003 09:50:34 -0400 From: Eric Rosen Cc: harald@alvestrand.no, mcr@sandelman.ottawa.on.ca, problem-statement@alvestrand.no Subject: Re: Operator participation X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list Reply-To: erosen@cisco.com List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no This business about there not being enough operator participation is a lot of baloney. The reasons some operators think that there isn't enough operator participation are (a) different sets of operators inhabit different WGs, and (b) operators tend to ignore the input of other operators who may disagree with them. If you look, e.g., at the main IETF list, at the routing-discussion list, at the idr list, etc., you'll see one class of operator. If you look at the PWE3 list, the MPLS list, the CCAMP list, the L3VPN list, the L2VPN list, etc., you'll see an entirely different class. And within the latter lists, there are large disagreements about very fundamental principles. For some reason, each group denies the existence of the others. Of course, when any particular operator fails to achieve consensus for his preferred solution, the problem is perceived as "not enough operator input". I think the set of operators that Harald is thinking of would be aghast at the proposals of the set of operators that Graham is thinking of. From problem-statement-bounces@alvestrand.no Wed Oct 15 10:01:33 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29996 for ; Wed, 15 Oct 2003 10:01:32 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 9B23D61B9B; Wed, 15 Oct 2003 16:01:07 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from i2kc01-ukbr.domain1.systemhost.net (unknown [217.32.164.137]) by eikenes.alvestrand.no (Postfix) with ESMTP id A7FB061B89; Wed, 15 Oct 2003 16:01:04 +0200 (CEST) Received: from i2km97-ukbr.domain1.systemhost.net ([193.113.197.30]) by i2kc01-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(5.0.2195.6713); Wed, 15 Oct 2003 15:01:04 +0100 Received: from i2km02-ukbr.domain1.systemhost.net ([193.113.197.79]) by i2km97-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(5.0.2195.6713); Wed, 15 Oct 2003 15:01:03 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 15 Oct 2003 15:01:02 +0100 Message-ID: <3D67CCA7D63E714B980D21A038EEA08E059276AD@i2km02-ukbr.domain1.systemhost.net> Thread-Topic: Operator participation Thread-Index: AcOTI1L7fRFMGVZwSvSYTYN+RowqPgAAGZ+A From: To: X-OriginalArrivalTime: 15 Oct 2003 14:01:03.0971 (UTC) FILETIME=[C5986330:01C39324] Cc: harald@alvestrand.no, mcr@sandelman.ottawa.on.ca, problem-statement@alvestrand.no Subject: RE: Operator participation X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: quoted-printable Eric, You may be right. I wasn't thinking of any "set" of operators, though; = just of my own requirements. I'm not qualified to say what other = operators want.=20 Regards, Graham Travers International Standards Manager BT Exact e-mail: graham.travers@bt.com tel: +44(0) 1359 235086 mobile: +44(0) 7808 502536 fax: +44(0) 1359 235087 HWB279, PO Box 200,London, N18 1ZF, UK BTexact Technologies is a trademark of British Telecommunications plc Registered office: 81 Newgate Street London EC1A 7AJ Registered in England no. 1800000 This electronic message contains information from British = Telecommunications plc which may be privileged or confidential. The = information is intended to be for the use of the individual(s) or entity = named above. If you are not the intended recipient be aware that any = disclosure, copying, distribution or use of the contents of this = information is prohibited. If you have received this electronic message = in error, please notify us by telephone or email (to the numbers or = address above) immediately. =20 -----Original Message----- From: Eric Rosen [mailto:erosen@cisco.com] Sent: 15 October 2003 14:51 To: Travers,G,Graham,XVT TRAVERG R Cc: harald@alvestrand.no; mcr@sandelman.ottawa.on.ca; problem-statement@alvestrand.no Subject: Re: Operator participation This business about there not being enough operator participation is a = lot of baloney.=20 The reasons some operators think that there isn't enough = operator participation are (a) different sets of operators inhabit different WGs, = and (b) operators tend to ignore the input of other operators who may = disagree with them. =20 If you look, e.g., at the main IETF list, at the routing-discussion = list, at the idr list, etc., you'll see one class of operator. If you look at = the PWE3 list, the MPLS list, the CCAMP list, the L3VPN list, the L2VPN = list, etc., you'll see an entirely different class. And within the latter = lists, there are large disagreements about very fundamental principles. For = some reason, each group denies the existence of the others. Of course, when any particular operator fails to achieve consensus for = his preferred solution, the problem is perceived as "not enough = operator input". =20 I think the set of operators that Harald is thinking of would be = aghast at the proposals of the set of operators that Graham is thinking of.=20 From problem-statement-bounces@alvestrand.no Wed Oct 15 10:36:27 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02507 for ; Wed, 15 Oct 2003 10:36:24 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id BF5DF61B9C; Wed, 15 Oct 2003 16:35:57 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from d12lmsgate.de.ibm.com (d12lmsgate-4.de.ibm.com [194.196.100.237]) by eikenes.alvestrand.no (Postfix) with ESMTP id 8F84061B8B; Wed, 15 Oct 2003 16:35:54 +0200 (CEST) Received: from d12relay01.megacenter.de.ibm.com (d12relay01.megacenter.de.ibm.com [9.149.165.180]) by d12lmsgate.de.ibm.com (8.12.10/8.12.8) with ESMTP id h9FEZro0078122; Wed, 15 Oct 2003 16:35:53 +0200 Received: from ochsehorn.zurich.ibm.com (ochsehorn.zurich.ibm.com [9.4.16.140]) by d12relay01.megacenter.de.ibm.com (8.12.9/NCO/VER6.6) with ESMTP id h9FEZrW3239878; Wed, 15 Oct 2003 16:35:53 +0200 Received: from zurich.ibm.com (dyn-9-13-126-138.ge.ch.ibm.com [9.13.126.138]) by ochsehorn.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id QAA50880; Wed, 15 Oct 2003 16:35:52 +0200 Message-ID: <3F8D5B2E.B9F52816@zurich.ibm.com> Date: Wed, 15 Oct 2003 16:35:26 +0200 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de MIME-Version: 1.0 To: graham.travers@bt.com References: <3D67CCA7D63E714B980D21A038EEA08E059276AC@i2km02-ukbr.domain1.systemhost.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: harald@alvestrand.no, mcr@sandelman.ottawa.on.ca, problem-statement@alvestrand.no Subject: Re: IESG proposed statement on the IETF mission X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit Graham, I think the issues you are raising are very important. But I've been told that, in fact, 3GPP is doing things with SIP that have been specifically pointed out as mistakes by the IETF. I hope the same doesn't arise with OMA (it was someone active in OMA who told me the above, in fact). However, when this happens, there really is very little the IETF can do, however it reforms itself. I've been to enough Global Standards Coordination meetings and the like to doubt seriously whether such coordination can ever be better than an approximation. I think we have to concentrate on fixing what we have decided is wrong with the IETF. But identifying topics of importance to operators that are not being tackled in the IETF would be a useful exercise, IMHO. I've always wanted to see Area Plans for each IETF Area. Brian graham.travers@bt.com wrote: > > Harald, > > OK, since you ask so nicely. 8o) > > I'll amplify my comments in the full realisation that the last time I mentioned that I have people working for me, I was practically accused of being the Capitalist exploiter of slave labour ! > > There are two specific examples, where I supported issues being brought to the IETF, and where I was prepared to put *real* effort into helping to find solutions. (I mean actual resources to edit documents, chair meetings, etc.) > > 1. Operations and maintenance support for MPLS. > I went so far as to (be able to) run a BOF on this one (not me personally). Despite a lot of interest at the BOF, and a stream of "operator people" at the microphone supporting the view that the functionality was needed, nothing useful transpired. Sure, the issue was referred to the MPLS WG for consideration - and no doubt they considered a lot - but the end result wasn't much use to me. It's now been addressed elsewhere. This operator just can't afford to run protocols which don't allow it to know what control it has. > > 2. Midcom. > Some of my colleagues and I were instrumental in bringing this issue to the IETF, and, sure enough, a WG was formed. While the analysis of existing protocols was useful, after several years I still don't see any standardised solution that I can/should use. Midcom is still running, so I suppose that it hasn't finished its work yet. I'm still interested in having a solution to this issue, but in the operator world time presses. > > Please understand that I'm *NOT* condemning the IETF for choosing its work items. I am simply explaining that when something is needed, if it can't be sourced from one supplier (the IETF) the purchaser has to find another supplier, if possible (insert the name of any suitable SDO here!). > > As far as applications protocols go, I don't have any specific requirements in mind. I mentioned that as an example since I've heard (not first-hand) that the OMA is planning protocol developments, which will not be referred to the IETF. One specific example that I mentioned earlier is SIP. > > Brian Carpenter's response to this was to say that we can't control what other SDO's do. > While this may be technically true, I don't think that the IETF is without influence. Whether it wants to use that influence, even in an advisory capacity, is up for debate, I guess. As the standards that it produces increasingly impinge on aspects of society other than the Internet (the IESG proposed Statement mentions "controlling street lights" ), the IETF has to either assume the responsibility of maintaining them for uses outside the Internet, or abrogate that responsibility and let other organisations do what they will with them. The "ultra-Internet" interests will not be stopped, if they really want a solution. > > IMHO, to mangle a famous saying: "No SDO is an island." The International Standards Community comprises many standards bodies, which have to cooperate to achieve useful solutions. Where would the Internet be if there were no standards for electricity supply, or cable capacity, or even time and date ? The most important thing about a standard is not that the solution is necessarily the best one, but that it is the *agreed* one. If we start to have different versions of SIP, for example - the IETF version, the 3GPP version, the OMA version - where is the standard, then ? > > BTW, when is an application not an application ? What are the characteristics that make "controlling street lights" less of an application than (say) calendaring and scheduling? I don't expect an answer, but there must be some differentiator, if they both use the Internet as a transport mechanism. If the IETF has, or is developing, such differentiators, it would be useful to have them published. If it hasn't, that may help to explain why there's been such a long-running debate. > > Regards, > > Graham Travers > > International Standards Manager > BT Exact > > e-mail: graham.travers@bt.com > tel: +44(0) 1359 235086 > mobile: +44(0) 7808 502536 > fax: +44(0) 1359 235087 > > HWB279, PO Box 200,London, N18 1ZF, UK > > BTexact Technologies is a trademark of British Telecommunications plc > Registered office: 81 Newgate Street London EC1A 7AJ > Registered in England no. 1800000 > > This electronic message contains information from British Telecommunications plc which may be privileged or confidential. The information is intended to be for the use of the individual(s) or entity named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information is prohibited. If you have received this electronic message in error, please notify us by telephone or email (to the numbers or address above) immediately. > > > ----Original Message----- > From: Harald Tveit Alvestrand [mailto:harald@alvestrand.no] > Sent: 15 October 2003 10:23 > To: Travers,G,Graham,XVT TRAVERG R; mcr@sandelman.ottawa.on.ca > Cc: problem-statement@alvestrand.no > Subject: RE: IESG proposed statement on the IETF mission > > --On 15. oktober 2003 09:56 +0100 graham.travers@bt.com wrote: > > > Harald & Michael, > > > > It's *getting* worse ! > > > > A few years ago one operator was prepared to fund about 20 individuals to > > participate in the IETF; now that's reduced to about 5, with no > > guarantee that such a level will be sustained. > > > > This is not just about the downturn in the industry. Real problems that > > operators have are not being addressed by the IETF. If the IETF won't > > address my concerns, and if I have to go to the OMA to meet my > > requirements for application protocols, for example, that's where I'll go. > > > > You may say "That's fine". OK, if that's the policy. But, then, don't > > be surprised if it happens ! > > Graham, > > thanks for your input! > > it would be nice if you could name examples - since I'm not an operator and > have rarely been on the forefront of the debates where you have been > engaged, I don't have enough background to evaluate the experiences you're > sharing. > > In particular, I'm interested in hearing your requirements for applications > protocols - both because I come from an applications background myself and > believe the applications perspective to be important for the IETF, and > because the proper boundary between "IETF work" and "application space > work" is one of the long-simmering (long-festering?) debates that the IETF > has never been able to come to resolution on. > > Harald From problem-statement-bounces@alvestrand.no Wed Oct 15 11:07:24 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03492 for ; Wed, 15 Oct 2003 11:07:23 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id EFFD861B9B; Wed, 15 Oct 2003 17:06:59 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from sj-iport-2.cisco.com (sj-iport-2-in.cisco.com [171.71.176.71]) by eikenes.alvestrand.no (Postfix) with ESMTP id 9729861B89; Wed, 15 Oct 2003 17:06:56 +0200 (CEST) Received: from cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 15 Oct 2003 08:03:39 -0700 Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h9FF6reH018252; Wed, 15 Oct 2003 08:06:54 -0700 (PDT) Received: from cisco.com (stealth-10-32-241-46.cisco.com [10.32.241.46]) by mira-sjc5-c.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with SMTP id AND87838; Wed, 15 Oct 2003 08:06:52 -0700 (PDT) Date: Wed, 15 Oct 2003 11:06:49 -0400 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) To: Harald Tveit Alvestrand From: Melinda Shore In-Reply-To: <157547561.1066175290@localhost> Message-Id: <33D8F6AA-FF21-11D7-B68A-000A95E35274@cisco.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) Cc: problem-statement@alvestrand.no, ietf@ietf.org Subject: Re: IESG proposed statement on the IETF mission X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit It's an interesting document, but it looks to me a bit much like a problem description and I'm not sure how it relates to other existing work (the problem description document in the problem working group, most obviously). I particularly liked the discussion of the IETF mission - it could provide the basis for tackling one problem that's been raised on a number of occasions, which is that the organization doesn't have a clear sense of mission or vision. Even though in the first paragraph of the "Social Dynamics" section you say that "As they are neither good nor bad, it is not appropriate to call them "problems;" rather think of them as social forces and dynamics" a number of them really are framed as problems. Indeed, it would be hard to define some way in which statements like "making integration more difficult" are not problem statements. I'd really like to see the document, which I think has good fundamentals, refocused on mission and goals. Melinda From problem-statement-bounces@alvestrand.no Wed Oct 15 11:23:20 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04341 for ; Wed, 15 Oct 2003 11:23:18 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 78FEC61B9C; Wed, 15 Oct 2003 17:22:55 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from smail.alcatel.fr (colt-na165.alcatel.fr [62.23.212.165]) by eikenes.alvestrand.no (Postfix) with ESMTP id 8D6B261B8B for ; Wed, 15 Oct 2003 17:22:53 +0200 (CEST) Received: from frmail31.netfr.alcatel.fr (frmail31.netfr.alcatel.fr [155.132.251.42]) by smail.alcatel.fr (ALCANET/NETFR) with ESMTP id h9FFMq4W021459; Wed, 15 Oct 2003 17:22:52 +0200 To: Brian E Carpenter X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: Alistair.Urie@alcatel.com Date: Wed, 15 Oct 2003 17:22:41 +0200 X-MIMETrack: Serialize by Router on FRMAIL31/FR/ALCATEL(Release 5.0.11 |July 24, 2002) at 10/15/2003 17:22:52 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii X-Virus-Scanned: by amavisd-new Cc: problem-statement@alvestrand.no Subject: Re: IESG proposed statement on the IETF mission X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Brian, I think the SIP and 3GPP story is a bit more complex than you make out. The so called "mistakes" are basically a set of direct consequences of 3GPP strictly following the mobile operator's requirements to maintain a place in the value chain and to let them hide certain details of their networks from other operators. How this could be seen as being a "mistake" within IETF does raise a few questions about our mechanisms for handling operator requirements :-) As far as GSC (last meeting was in Ottawa - see http://www.tsacc.ca/e/gsc/index.shtml) goes, all I can say is you have been missing something since the last few meetings have been quite interesting especially with respect to the use of SIP and other IETF protocols, midcom, etc. within NGN. Scott has been coming and has been a very useful contributor. I normally atend via "another organisation". - Aistair Brian E Carpenter To: graham.travers@bt.com Sent by: cc: harald@alvestrand.no, mcr@sandelman.ottawa.on.ca, problem-statement-bounces@al problem-statement@alvestrand.no vestrand.no Subject: Re: IESG proposed statement on the IETF mission 15/10/2003 16:35 Graham, I think the issues you are raising are very important. But I've been told that, in fact, 3GPP is doing things with SIP that have been specifically pointed out as mistakes by the IETF. I hope the same doesn't arise with OMA (it was someone active in OMA who told me the above, in fact). However, when this happens, there really is very little the IETF can do, however it reforms itself. I've been to enough Global Standards Coordination meetings and the like to doubt seriously whether such coordination can ever be better than an approximation. I think we have to concentrate on fixing what we have decided is wrong with the IETF. But identifying topics of importance to operators that are not being tackled in the IETF would be a useful exercise, IMHO. I've always wanted to see Area Plans for each IETF Area. Brian graham.travers@bt.com wrote: > > Harald, > > OK, since you ask so nicely. 8o) > > I'll amplify my comments in the full realisation that the last time I mentioned that I have people working for me, I was practically accused of being the Capitalist exploiter of slave labour ! > > There are two specific examples, where I supported issues being brought to the IETF, and where I was prepared to put *real* effort into helping to find solutions. (I mean actual resources to edit documents, chair meetings, etc.) > > 1. Operations and maintenance support for MPLS. > I went so far as to (be able to) run a BOF on this one (not me personally). Despite a lot of interest at the BOF, and a stream of "operator people" at the microphone supporting the view that the functionality was needed, nothing useful transpired. Sure, the issue was referred to the MPLS WG for consideration - and no doubt they considered a lot - but the end result wasn't much use to me. It's now been addressed elsewhere. This operator just can't afford to run protocols which don't allow it to know what control it has. > > 2. Midcom. > Some of my colleagues and I were instrumental in bringing this issue to the IETF, and, sure enough, a WG was formed. While the analysis of existing protocols was useful, after several years I still don't see any standardised solution that I can/should use. Midcom is still running, so I suppose that it hasn't finished its work yet. I'm still interested in having a solution to this issue, but in the operator world time presses. > > Please understand that I'm *NOT* condemning the IETF for choosing its work items. I am simply explaining that when something is needed, if it can't be sourced from one supplier (the IETF) the purchaser has to find another supplier, if possible (insert the name of any suitable SDO here!). > > As far as applications protocols go, I don't have any specific requirements in mind. I mentioned that as an example since I've heard (not first-hand) that the OMA is planning protocol developments, which will not be referred to the IETF. One specific example that I mentioned earlier is SIP. > > Brian Carpenter's response to this was to say that we can't control what other SDO's do. > While this may be technically true, I don't think that the IETF is without influence. Whether it wants to use that influence, even in an advisory capacity, is up for debate, I guess. As the standards that it produces increasingly impinge on aspects of society other than the Internet (the IESG proposed Statement mentions "controlling street lights" ), the IETF has to either assume the responsibility of maintaining them for uses outside the Internet, or abrogate that responsibility and let other organisations do what they will with them. The "ultra-Internet" interests will not be stopped, if they really want a solution. > > IMHO, to mangle a famous saying: "No SDO is an island." The International Standards Community comprises many standards bodies, which have to cooperate to achieve useful solutions. Where would the Internet be if there were no standards for electricity supply, or cable capacity, or even time and date ? The most important thing about a standard is not that the solution is necessarily the best one, but that it is the *agreed* one. If we start to have different versions of SIP, for example - the IETF version, the 3GPP version, the OMA version - where is the standard, then ? > > BTW, when is an application not an application ? What are the characteristics that make "controlling street lights" less of an application than (say) calendaring and scheduling? I don't expect an answer, but there must be some differentiator, if they both use the Internet as a transport mechanism. If the IETF has, or is developing, such differentiators, it would be useful to have them published. If it hasn't, that may help to explain why there's been such a long-running debate. > > Regards, > > Graham Travers > > International Standards Manager > BT Exact > > e-mail: graham.travers@bt.com > tel: +44(0) 1359 235086 > mobile: +44(0) 7808 502536 > fax: +44(0) 1359 235087 > > HWB279, PO Box 200,London, N18 1ZF, UK > > BTexact Technologies is a trademark of British Telecommunications plc > Registered office: 81 Newgate Street London EC1A 7AJ > Registered in England no. 1800000 > > This electronic message contains information from British Telecommunications plc which may be privileged or confidential. The information is intended to be for the use of the individual(s) or entity named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information is prohibited. If you have received this electronic message in error, please notify us by telephone or email (to the numbers or address above) immediately. > > > ----Original Message----- > From: Harald Tveit Alvestrand [mailto:harald@alvestrand.no] > Sent: 15 October 2003 10:23 > To: Travers,G,Graham,XVT TRAVERG R; mcr@sandelman.ottawa.on.ca > Cc: problem-statement@alvestrand.no > Subject: RE: IESG proposed statement on the IETF mission > > --On 15. oktober 2003 09:56 +0100 graham.travers@bt.com wrote: > > > Harald & Michael, > > > > It's *getting* worse ! > > > > A few years ago one operator was prepared to fund about 20 individuals to > > participate in the IETF; now that's reduced to about 5, with no > > guarantee that such a level will be sustained. > > > > This is not just about the downturn in the industry. Real problems that > > operators have are not being addressed by the IETF. If the IETF won't > > address my concerns, and if I have to go to the OMA to meet my > > requirements for application protocols, for example, that's where I'll go. > > > > You may say "That's fine". OK, if that's the policy. But, then, don't > > be surprised if it happens ! > > Graham, > > thanks for your input! > > it would be nice if you could name examples - since I'm not an operator and > have rarely been on the forefront of the debates where you have been > engaged, I don't have enough background to evaluate the experiences you're > sharing. > > In particular, I'm interested in hearing your requirements for applications > protocols - both because I come from an applications background myself and > believe the applications perspective to be important for the IETF, and > because the proper boundary between "IETF work" and "application space > work" is one of the long-simmering (long-festering?) debates that the IETF > has never been able to come to resolution on. > > Harald From problem-statement-bounces@alvestrand.no Wed Oct 15 11:57:50 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06113 for ; Wed, 15 Oct 2003 11:57:49 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 2717461B9F; Wed, 15 Oct 2003 17:57:26 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by eikenes.alvestrand.no (Postfix) with ESMTP id 7E0B461B9B; Wed, 15 Oct 2003 17:57:22 +0200 (CEST) Message-ID: <00f101c39335$0feff640$956015ac@dclkempt40> From: "James Kempf" To: , , References: <3D67CCA7D63E714B980D21A038EEA08E059276AB@i2km02-ukbr.domain1.systemhost.net> Date: Wed, 15 Oct 2003 08:57:40 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Cc: problem-statement@alvestrand.no Subject: Re: IESG proposed statement on the IETF mission X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit Graham, > It's *getting* worse ! > > A few years ago one operator was prepared to fund about 20 individuals to participate in the IETF; now that's reduced to about 5, with no guarantee that such a level will be sustained. > > This is not just about the downturn in the industry. Real problems that operators have are not being addressed by the IETF. If the IETF won't address my concerns, and if I have to go to the OMA to meet my requirements for application protocols, for example, that's where I'll go. > Can you cite an example? I am not aware of any case where a group of operaters has come to the IETF with a proposal for an application protocol and had the charter turned down at some point during the process of new work startup (i.e. no BOF consensus or charter rejected at I* review). > You may say "That's fine". OK, if that's the policy. But, then, don't be surprised if it happens ! > Well, personally, coming from an operator I don't think it is fine. Having operators involved is important, but I don't think that it is just a matter of how many people they send to IETFs. Operators need to take the initative to start new work and contribute their perspective to ongoing work. And, they need to contribute people to sit on Nomcom and otherwise be involved. If an operator sends 20 people and they just sit in the audience, never contribute to mailing lists, it doesn't help get the operator perspective represented. jak From problem-statement-bounces@alvestrand.no Wed Oct 15 12:05:21 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06613 for ; Wed, 15 Oct 2003 12:05:19 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 451E361BA7; Wed, 15 Oct 2003 18:04:56 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by eikenes.alvestrand.no (Postfix) with ESMTP id A5CC361B8B; Wed, 15 Oct 2003 18:04:52 +0200 (CEST) Received: from cisco.com (sjc-vpn3-678.cisco.com [10.21.66.166]) by sj-core-4.cisco.com (8.12.6/8.12.6) with SMTP id h9FG4mH7015688; Wed, 15 Oct 2003 09:04:49 -0700 (PDT) Received: by cisco.com (sSMTP sendmail emulation); Wed, 15 Oct 2003 12:04:45 -0400 Date: Wed, 15 Oct 2003 12:04:45 -0400 From: Scott W Brim To: Harald Tveit Alvestrand Message-ID: <20031015120445.O2320@sbrim-w2k01> Mail-Followup-To: Scott W Brim , Harald Tveit Alvestrand , ietf@ietf.org, problem-statement@alvestrand.no References: <157547561.1066175290@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <157547561.1066175290@localhost>; from harald@alvestrand.no on Tue, Oct 14, 2003 at 11:48:10PM +0200 Cc: problem-statement@alvestrand.no, ietf@ietf.org Subject: Re: IESG proposed statement on the IETF mission X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no On Tue, Oct 14, 2003 11:48:10PM +0200, Harald Tveit Alvestrand allegedly wrote: > As part of the discussions about change process within > the IETF, the IESG has come to believe that a somewhat longer statement of > the IETF's mission and social dynamics might provide useful context for the > community's discussion. As part of that, we'd like to put the following > document out for feedback. > > It incorporates lots of ideas and some text from existing RFCs > and IETF web pages, but is more focused on change than those have > been. We hope it captures a sense of the context of the work of > improving the IETF, by capturing some of the social dynamics which > have been an implicit part of the IETF's work and style over the years. OK, but first, it doesn't clarify the mission, or the social contract. At most it makes a couple vague statements after describing some general problems. It looks like the IESG has some sense of where the problem-statement/solutions process is going, and wants to run with it. That's okay -- but please say explicitly that's what's happening, if it is. > We also hope that by making some of those implicit elements more > explicit, we may find it easier to understand how to make changes > that will "go with the grain" of the IETF's history and culture. What I want is a renewed, clear statement of the fundamental principles of the IETF which must not be violated or weakened during the problem/solution process. It's important that the leadership of the IETF keep clear themselves on what the fundamental principles are, and to reiterate them when necessary (like now). That's part of the social contract itself. There are principles which are at the heart of the organization and which the (pseudo-)consensus process doesn't get to touch. > The IETF Mission > ---------------- > > The IETF's mission has historically been embedded in a shared > understanding that making engineering choices based on the long > term interest of the Internet as a whole produces better long-term > results for each participant than making choices based on short term > considerations, because the value of those advantages is ultimately > derived from the health of the whole. The long term interest of the > Internet includes the premise that "the Internet is for everyone". > > Two years ago, the IESG felt that making the mission of the IETF > more explicit was needed. The following terse statement has since > been promulgated, first by IESG members and then by others: > > "The purpose of the IETF is to create high quality, relevant, > and timely standards for the Internet." The purpose of the IETF has always been to make the Internet work better, in measurable operational terms. All else descends from that. We do standards because we have to, for now and for the future. Why do we care about network operators being in the room if our prime mission is to make standards? Why do we care if there are two interoperable implementations? The operations work of the IETF is important unless it is being taken care of elsewhere. It isn't frosting on a standards body cake, it's just as important as standards. Beyond that, yes, the IETF is primarily an SDO, because many operational issues and agreement on deployment BCPs are being taken care of by other means, and also because standards is our main measurable output in the eyes of the outside world. The above statement applies, but it is not a basic principle. It derives from our fundamental responsibility, to have an Internet that works well today and is robust and flexible enough to work well in the future. > It is important that this is "For the Internet," and does not include > everything that happens to use IP. IP is being used in a myriad of > real-world applications, such as controlling street lights, but the > IETF does not standardize those applications. A very poor distinction. Everything runs on the Internet eventually, regardless of what private area it was meant for to start with. Experience is that everyone wins if there are Internet-compatible ways of doing things from the beginning. I fully expect street light control to run as a secure service along with many other services over a generic IP network. However, it's okay to say that priority will be given to work on the public Internet. > The IETF has also had a strong operational component, with a tight > bond, and hence coordination, between protocol developers and > network operators, and has had many participants who did both. > This has provided valuable feedback to allow correction of > misguided standardization efforts, and has provided feedback to > sort out which standards were actually needed. As the field has > grown explosively, specialization has set in, and market pressures > have risen, there has been less and less operator participation in > the IETF. This has nothing to do with either mission or social contract. Are you saying "therefore we need to change our mission"? Similarly for almost all of the rest. What's the point? Are you reiterating the problem-statement work? They're doing all right, although perhaps you could help push the work to completion. It would be much more useful for you to reaffirm the fundamental principles that are not on the auction block. Have a good time at the meeting, I won't make it this time. See you ... Scott From problem-statement-bounces@alvestrand.no Wed Oct 15 12:46:32 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08634 for ; Wed, 15 Oct 2003 12:46:32 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 2D92261B8C; Wed, 15 Oct 2003 18:45:59 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by eikenes.alvestrand.no (Postfix) with ESMTP id F1E3361B8B for ; Wed, 15 Oct 2003 18:45:55 +0200 (CEST) Message-ID: <01a001c3933b$d453ef90$956015ac@dclkempt40> From: "James Kempf" To: "Brian E Carpenter" , References: Date: Wed, 15 Oct 2003 09:46:06 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Cc: problem-statement@alvestrand.no Subject: Re: IESG proposed statement on the IETF mission X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit Alistair, > I think the SIP and 3GPP story is a bit more complex than you make out. > The so called "mistakes" are basically a set of direct consequences of 3GPP > strictly following the mobile operator's requirements to maintain a place > in the value chain and to let them hide certain details of their networks > from other operators. How this could be seen as being a "mistake" within > IETF does raise a few questions about our mechanisms for handling operator > requirements :-) > It is a mistake because the architectural consequences of its assumption of a particular business model have proven, in the past, to be an inhibitor for service innovation in other contexts. > As far as GSC (last meeting was in Ottawa - see > http://www.tsacc.ca/e/gsc/index.shtml) goes, all I can say is you have been > missing something since the last few meetings have been quite interesting > especially with respect to the use of SIP and other IETF protocols, midcom, > etc. within NGN. Scott has been coming and has been a very useful > contributor. I normally atend via "another organisation". > I have not checked into this in detail, but I have heard that 3GPP has been responding positively to IETF suggestions for improving utilization of SIP. There was a very good and frank technical discussion at the joint meeting in January this year. That said, there are a few other areas of concern in some peripherial support for 3GPP's system, which are not directly under control of 3GPP (I'm speaking here of GRX). 3GPP has been quite helpful in addressing IETF's concerns in this area where there is interaction with 3GPP's system, but since the specifications are not directly under its control, there is only so much 3GPP can do. jak From problem-statement-bounces@alvestrand.no Wed Oct 15 12:53:22 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08910 for ; Wed, 15 Oct 2003 12:53:21 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 5CB30622CE; Wed, 15 Oct 2003 18:52:58 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from i2kc01-ukbr.domain1.systemhost.net (unknown [217.32.164.137]) by eikenes.alvestrand.no (Postfix) with ESMTP id 07A8E62256; Wed, 15 Oct 2003 18:52:34 +0200 (CEST) Received: from i2km95-ukbr.domain1.systemhost.net ([193.113.197.29]) by i2kc01-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(5.0.2195.6713); Wed, 15 Oct 2003 17:52:33 +0100 Received: from i2km02-ukbr.domain1.systemhost.net ([193.113.197.79]) by i2km95-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(5.0.2195.6713); Wed, 15 Oct 2003 17:52:33 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 15 Oct 2003 17:52:33 +0100 Message-ID: <3D67CCA7D63E714B980D21A038EEA08E059276B3@i2km02-ukbr.domain1.systemhost.net> Thread-Topic: IESG proposed statement on the IETF mission Thread-Index: AcOTNQgGKanpcK6eQoq5T4OFZIsT1QABpmdw From: To: , , X-OriginalArrivalTime: 15 Oct 2003 16:52:33.0624 (UTC) FILETIME=[BAB4D580:01C3933C] Cc: problem-statement@alvestrand.no Subject: RE: IESG proposed statement on the IETF mission X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: quoted-printable James, Sorry, I wasn't clear. The phrase about applications protocols was an = hypothetical case, not an actual occurrence. =20 See my follow-up posting for details of attempts to get work initiated. Regards, Graham Travers International Standards Manager BT Exact e-mail: graham.travers@bt.com tel: +44(0) 1359 235086 mobile: +44(0) 7808 502536 fax: +44(0) 1359 235087 HWB279, PO Box 200,London, N18 1ZF, UK BTexact Technologies is a trademark of British Telecommunications plc Registered office: 81 Newgate Street London EC1A 7AJ Registered in England no. 1800000 This electronic message contains information from British = Telecommunications plc which may be privileged or confidential. The = information is intended to be for the use of the individual(s) or entity = named above. If you are not the intended recipient be aware that any = disclosure, copying, distribution or use of the contents of this = information is prohibited. If you have received this electronic message = in error, please notify us by telephone or email (to the numbers or = address above) immediately. =20 =20 -----Original Message----- From: James Kempf [mailto:kempf@docomolabs-usa.com] Sent: 15 October 2003 16:58 To: Travers,G,Graham,XVT TRAVERG R; harald@alvestrand.no; mcr@sandelman.ottawa.on.ca Cc: problem-statement@alvestrand.no Subject: Re: IESG proposed statement on the IETF mission=20 Graham, > It's *getting* worse ! > > A few years ago one operator was prepared to fund about 20 individuals = to participate in the IETF; now that's reduced to about 5, with no = guarantee that such a level will be sustained. > > This is not just about the downturn in the industry. Real problems = that operators have are not being addressed by the IETF. If the IETF won't address my concerns, and if I have to go to the OMA to meet my = requirements for application protocols, for example, that's where I'll go. > Can you cite an example? I am not aware of any case where a group of operaters has come to the IETF with a proposal for an application = protocol and had the charter turned down at some point during the process of new = work startup (i.e. no BOF consensus or charter rejected at I* review). > You may say "That's fine". OK, if that's the policy. But, then, = don't be surprised if it happens ! > Well, personally, coming from an operator I don't think it is fine. = Having operators involved is important, but I don't think that it is just a = matter of how many people they send to IETFs. Operators need to take the = initative to start new work and contribute their perspective to ongoing work. And, they need to contribute people to sit on Nomcom and otherwise be = involved. If an operator sends 20 people and they just sit in the audience, never contribute to mailing lists, it doesn't help get the operator = perspective represented. jak From problem-statement-bounces@alvestrand.no Wed Oct 15 12:54:35 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08957 for ; Wed, 15 Oct 2003 12:54:33 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id DBC9961B9F; Wed, 15 Oct 2003 18:54:09 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from klutz.cs.utk.edu (klutz.cs.utk.edu [160.36.56.50]) by eikenes.alvestrand.no (Postfix) with ESMTP id C25DA622F0; Wed, 15 Oct 2003 18:53:46 +0200 (CEST) Received: from localhost (klutz [127.0.0.1]) by smtp.cs.utk.edu (Postfix) with ESMTP id DBCC21409F; Wed, 15 Oct 2003 12:53:45 -0400 (EDT) Received: from klutz.cs.utk.edu ([127.0.0.1]) by localhost (klutz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 08711-05; Wed, 15 Oct 2003 12:53:44 -0400 (EDT) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by smtp.cs.utk.edu (Postfix) with ESMTP id 4C2B71410F; Wed, 15 Oct 2003 12:53:44 -0400 (EDT) Date: Wed, 15 Oct 2003 12:48:37 -0400 From: Keith Moore To: Harald Tveit Alvestrand Message-Id: <20031015124837.79dbcd11.moore@cs.utk.edu> In-Reply-To: <157547561.1066175290@localhost> References: <157547561.1066175290@localhost> X-Mailer: Sylpheed version 0.9.6 (GTK+ 1.2.10; i386--netbsdelf) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new and ClamAV at cs.utk.edu Cc: problem-statement@alvestrand.no, moore@cs.utk.edu, ietf@ietf.org Subject: Re: IESG proposed statement on the IETF mission X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit overall, I like the document. some comments: > However, while Dave Clark's famous saying > > "We do not believe in kings, presidents, or voting. > We believe only in rough consensus and running code," is this an accurate quote? I've usually seen it written We reject kings, presidents, and voting. We believe in rough consensus and running code. I agree with this form, but not with the way you've stated it. I certainly don't believe "only" in rough consensus and running code - I also believe in explicit definition of goals and requirements, careful design by knowledgable experts, analysis, iterative specification, wide public review, etc. > "The purpose of the IETF is to create high quality, relevant, > and timely standards for the Internet." I actually believe IETF has a somewhat wider purpose than that. What I usually say is "we're trying to help the Internet work better". We do this partially by authoring and maintaining protocol standards, but we use other mechanisms also. In addition to standards, we produce informational and experimental documents and BCPs. We provide formal and informal advice and feedback to various parties about operational practices, implementation practices, efforts by other SDOs, proposed regulations, etc. All of these are relevant to, and consistent with, the purpose of helping the Internet to work better. We *ought* to provide more architectural direction or advice - our failure to resolve architectural issues in advance of deployment of products with conflicting views of the architecture (or in some cases, a simple lack of care or foresight on those vendors' parts) has caused a number of conflicts and operational problems, and has impaired the ability of the Internet to support diverse applications. I also believe that some amount of experimentation (perhaps not all that is being done under IETF's purview) is part of the process of "trying to make the Internet work better" > The IETF > has identified interoperability, security, and scalability as > essential, but without attaching measurements to those > characteristics. that's a start. there are a lot more characteristics than these that should be considered in a design, that we haven't articulated yet, but we need to. > It is important that this is "For the Internet," and does not include > everything that happens to use IP. IP is being used in a myriad of > real-world applications, such as controlling street lights, but the > IETF does not standardize those applications. I disagree with the sentiment as I understand it. I don't think it's realistic anymore to take the view that what people run entirely on private networks is their own business and outside of IETF's purview. NATs, private addresses, and DHCP with short lease times have all had devistating effects on the Internet's ability to support applications. Insecure applications can facilitate the breeding of viruses that affect the entire network even if their intended interactions are only between a local client and server. We do have to limit our scope. We don't have the ability to scale to the point where we could standardize everything that uses IP, and it would be silly of us to try to claim authority to do so. But it might be reasonable for us to define standards for how local networks work (to provide applications with a predictable environment), or to define standards which all applications should adhere to (to minimize security issues) which can be incorporated by reference into other protocol specifications. regarding the section on "Quality and Architectural Review". what strikes me about this section is the (implicit) assumption that architecture is done after the fact. rather than looking ahead to minimize and resolve conflicts well before they acquire the inertia of wide deployment, we try to fix things after the fact. From problem-statement-bounces@alvestrand.no Wed Oct 15 12:57:44 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09154 for ; Wed, 15 Oct 2003 12:57:43 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id C8FBF61BDC; Wed, 15 Oct 2003 18:57:20 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by eikenes.alvestrand.no (Postfix) with ESMTP id B668861BB5; Wed, 15 Oct 2003 18:57:17 +0200 (CEST) Received: from cisco.com (64.102.124.13) by sj-iport-5.cisco.com with ESMTP; 15 Oct 2003 09:57:39 -0700 Received: from cisco.com (erosen-u10.cisco.com [161.44.70.36]) by rtp-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h9FGvBlb000917; Wed, 15 Oct 2003 12:57:12 -0400 (EDT) Message-Id: <200310151657.h9FGvBlb000917@rtp-core-2.cisco.com> To: Harald Tveit Alvestrand In-reply-to: Your message of Tue, 14 Oct 2003 23:48:10 +0200. <157547561.1066175290@localhost> User-Agent: EMH/1.14.1 SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (=?ISO-8859-4?Q?Unebigory=F2mae?=) APEL/10.3 Emacs/21.3 (sparc-sun-solaris2.8) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII Date: Wed, 15 Oct 2003 12:57:11 -0400 From: Eric Rosen Cc: problem-statement@alvestrand.no, ietf@ietf.org Subject: Re: IESG proposed statement on the IETF mission X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list Reply-To: erosen@cisco.com List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no > "The purpose of the IETF is to create high quality, relevant, and timely > standards for the Internet." > It is important that this is "For the Internet," and does not include > everything that happens to use IP. IP is being used in a myriad of > real-world applications, such as controlling street lights, but the > IETF does not standardize those applications. Well, let's test this assertion. Suppose a consortium of electric companies develops a UDP-based protocol for monitoring and controlling street lights. It turns out that this protocol generates an unbounded amount of traffic (say, proportional to the square of the number of street lights in the world), has no congestion control, and no security, but is expected to run over the Internet. According to you, this has nothing to do with the IETF. It might result in the congestive collapse of the Internet, but who cares, the IETF doesn't do street lights. I would like to see the criteria which determine that telephones belong on the Internet but street lights don't! Another problem with your formulation is that the Internet is a growing, changing, entity, so "for the Internet" often means "for what I think the Internet should be in a few years", and this is then a completely unobjective criterion. One would hope instead that the IETF would want to encourage competition between different views of Internet evolution, as the competition of ideas is the way to make progress. I also do not understand whether "for the Internet" means something different than "for IP networking" or not. I think it should also be part of the mission to produce standards that facilitate the migration to IP of applications and infrastructures that use legacy networking technologies. Such migration seems to be good for the Internet, but I don't know if it is "for the Internet" or not. From problem-statement-bounces@alvestrand.no Wed Oct 15 13:02:59 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09397 for ; Wed, 15 Oct 2003 13:02:58 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 00BA661BD6; Wed, 15 Oct 2003 19:02:36 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from i2kc03-ukbr.domain1.systemhost.net (unknown [217.32.164.138]) by eikenes.alvestrand.no (Postfix) with ESMTP id 8A4A461B9F for ; Wed, 15 Oct 2003 19:02:34 +0200 (CEST) Received: from i2km96-ukbr.domain1.systemhost.net ([193.113.197.84]) by i2kc03-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(5.0.2195.6713); Wed, 15 Oct 2003 18:02:34 +0100 Received: from i2km02-ukbr.domain1.systemhost.net ([193.113.197.79]) by i2km96-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(5.0.2195.6713); Wed, 15 Oct 2003 18:02:33 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 15 Oct 2003 18:02:33 +0100 Message-ID: <3D67CCA7D63E714B980D21A038EEA08E059276B4@i2km02-ukbr.domain1.systemhost.net> Thread-Topic: IESG proposed statement on the IETF mission Thread-Index: AcOTO9Rzt6AsfEbpTxS2UJ19e8Qw7AAAWN4w From: To: , , X-OriginalArrivalTime: 15 Oct 2003 17:02:33.0937 (UTC) FILETIME=[20855410:01C3933E] Cc: problem-statement@alvestrand.no Subject: RE: IESG proposed statement on the IETF mission X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: quoted-printable James Kempf wrote: I have not checked into this in detail, but I have heard that 3GPP has = been responding positively to IETF suggestions for improving utilization of = SIP. There was a very good and frank technical discussion at the joint = meeting in January this year. That said, there are a few other areas of concern in some peripherial support for 3GPP's system, which are not directly under control of 3GPP = (I'm speaking here of GRX). 3GPP has been quite helpful in addressing IETF's concerns in this area where there is interaction with 3GPP's system, but since the specifications are not directly under its control, there is = only so much 3GPP can do. jak If this is true, it's the sort of cooperation that I referred to earlier = - and of which I would like to see more. Sure, the IETF can't force = 3GPP to do anything; but it *can* offer advice and design help, etc. = Similarly, 3GPP can't force the IETF to do anything; but it can present = requirements, which should be listened to sympathetically by the IETF. Regards, Graham Travers International Standards Manager BT Exact e-mail: graham.travers@bt.com tel: +44(0) 1359 235086 mobile: +44(0) 7808 502536 fax: +44(0) 1359 235087 HWB279, PO Box 200,London, N18 1ZF, UK BTexact Technologies is a trademark of British Telecommunications plc Registered office: 81 Newgate Street London EC1A 7AJ Registered in England no. 1800000 This electronic message contains information from British = Telecommunications plc which may be privileged or confidential. The = information is intended to be for the use of the individual(s) or entity = named above. If you are not the intended recipient be aware that any = disclosure, copying, distribution or use of the contents of this = information is prohibited. If you have received this electronic message = in error, please notify us by telephone or email (to the numbers or = address above) immediately. =20 From problem-statement-bounces@alvestrand.no Wed Oct 15 13:03:51 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09449 for ; Wed, 15 Oct 2003 13:03:50 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 4B58561C1B; Wed, 15 Oct 2003 19:03:28 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27]) by eikenes.alvestrand.no (Postfix) with ESMTP id 5FB3261BB5; Wed, 15 Oct 2003 19:03:25 +0200 (CEST) Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id h9FH3OX14460; Wed, 15 Oct 2003 20:03:24 +0300 (EET DST) Received: from daebh001.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 15 Oct 2003 20:03:24 +0300 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 15 Oct 2003 10:02:50 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 15 Oct 2003 13:01:53 -0400 Message-ID: Thread-Topic: IESG proposed statement on the IETF mission Thread-Index: AcOTNkIQ3jR8xoGcQk6oVsjGtGIIFgAB6bXQ From: To: , X-OriginalArrivalTime: 15 Oct 2003 17:02:50.0899 (UTC) FILETIME=[2AA18630:01C3933E] Cc: problem-statement@alvestrand.no, ietf@ietf.org Subject: RE: IESG proposed statement on the IETF mission X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: quoted-printable Hi Scott, > Similarly for almost all of the rest. What's the point? Are you > reiterating the problem-statement work? They're doing all right, > although perhaps you could help push the work to completion. It would > be much more useful for you to reaffirm the fundamental=20 > principles that are not on the auction block. >From your perspective, what are those fundamental principles? Margaret From problem-statement-bounces@alvestrand.no Wed Oct 15 13:04:00 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09501 for ; Wed, 15 Oct 2003 13:03:59 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 958A061C25; Wed, 15 Oct 2003 19:03:34 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from klutz.cs.utk.edu (klutz.cs.utk.edu [160.36.56.50]) by eikenes.alvestrand.no (Postfix) with ESMTP id 69D2561BD6; Wed, 15 Oct 2003 19:03:32 +0200 (CEST) Received: from localhost (klutz [127.0.0.1]) by smtp.cs.utk.edu (Postfix) with ESMTP id CF82313FAF; Wed, 15 Oct 2003 13:03:31 -0400 (EDT) Received: from klutz.cs.utk.edu ([127.0.0.1]) by localhost (klutz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 09603-11; Wed, 15 Oct 2003 13:03:30 -0400 (EDT) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by smtp.cs.utk.edu (Postfix) with ESMTP id 82DCF1409F; Wed, 15 Oct 2003 13:03:30 -0400 (EDT) Date: Wed, 15 Oct 2003 12:58:24 -0400 From: Keith Moore To: erosen@cisco.com Message-Id: <20031015125824.3c865835.moore@cs.utk.edu> In-Reply-To: <200310151657.h9FGvBlb000917@rtp-core-2.cisco.com> References: <157547561.1066175290@localhost> <200310151657.h9FGvBlb000917@rtp-core-2.cisco.com> X-Mailer: Sylpheed version 0.9.6 (GTK+ 1.2.10; i386--netbsdelf) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new and ClamAV at cs.utk.edu Cc: harald@alvestrand.no, moore@cs.utk.edu, ietf@ietf.org, problem-statement@alvestrand.no Subject: Re: IESG proposed statement on the IETF mission X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit > One would hope instead that the IETF would want to > encourage competition between different views of Internet evolution, as the > competition of ideas is the way to make progress. what I would say instead is that the IETF should encourage this competition within the sphere of architectural discussion - well in advance of development of specific standards or deployment of specific products. From problem-statement-bounces@alvestrand.no Wed Oct 15 13:17:27 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11044 for ; Wed, 15 Oct 2003 13:17:26 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 07BCC61BB5; Wed, 15 Oct 2003 19:17:03 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by eikenes.alvestrand.no (Postfix) with ESMTP id 2575E61B8C; Wed, 15 Oct 2003 19:17:00 +0200 (CEST) Received: from employees.org (171.68.223.138) by sj-iport-5.cisco.com with ESMTP; 15 Oct 2003 10:17:24 -0700 Received: from cisco.com (sjc-vpn3-678.cisco.com [10.21.66.166]) by sj-core-4.cisco.com (8.12.6/8.12.6) with SMTP id h9FHGtH7010500; Wed, 15 Oct 2003 10:16:56 -0700 (PDT) Received: by cisco.com (sSMTP sendmail emulation); Wed, 15 Oct 2003 13:16:52 -0400 Date: Wed, 15 Oct 2003 13:16:52 -0400 From: Scott W Brim To: Margaret.Wasserman@nokia.com Message-ID: <20031015131652.P2320@sbrim-w2k01> Mail-Followup-To: Scott W Brim , Margaret.Wasserman@nokia.com, harald@alvestrand.no, problem-statement@alvestrand.no, ietf@ietf.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from Margaret.Wasserman@nokia.com on Wed, Oct 15, 2003 at 01:01:53PM -0400 Cc: harald@alvestrand.no, ietf@ietf.org, problem-statement@alvestrand.no Subject: Re: IESG proposed statement on the IETF mission X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no On Wed, Oct 15, 2003 01:01:53PM -0400, Margaret.Wasserman@nokia.com allegedly wrote: > > Hi Scott, > > > Similarly for almost all of the rest. What's the point? Are you > > reiterating the problem-statement work? They're doing all right, > > although perhaps you could help push the work to completion. It would > > be much more useful for you to reaffirm the fundamental > > principles that are not on the auction block. > > >From your perspective, what are those fundamental principles? I can't do that today, but will reply soon. From problem-statement-bounces@alvestrand.no Wed Oct 15 19:05:19 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA29056 for ; Wed, 15 Oct 2003 19:05:18 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 5EFDE61BB4; Thu, 16 Oct 2003 01:04:55 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from mtiwmhc13.worldnet.att.net (mtiwmhc13.worldnet.att.net [204.127.131.117]) by eikenes.alvestrand.no (Postfix) with ESMTP id B096B61BAE; Thu, 16 Oct 2003 01:04:52 +0200 (CEST) Received: from bolaba (34.sanjose-08-09rs16rt.ca.dial-access.att.net[12.81.3.34]) by worldnet.att.net (mtiwmhc13) with SMTP id <2003101523044211300p9nk2e>; Wed, 15 Oct 2003 23:04:46 +0000 Message-ID: <005201c39370$19b776e0$010aff0a@bolaba> From: "todd glassey" To: References: <3D67CCA7D63E714B980D21A038EEA08E059276AB@i2km02-ukbr.domain1.systemhost.net> Date: Wed, 15 Oct 2003 16:00:07 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Cc: problem-statement@alvestrand.no Subject: Re: IESG proposed statement on the IETF mission X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit Harald - So what does this remark say? simple it says that that the IETF and IESG are both currently failing to provide lasting value in their processes and deliverables. Your problem as the IETF's chair and 'Sheppard's, is that its just as easy for 5 or 10 people to spin a group outside of the IETF - setup a website and a PHPCollab posting site and viola - instant initiative infrastructure. Really, its that easy, just add participants. The server can be up in an hour. So if there is a real infrastructure that can compete with the IETF's process and it comes in a can - then what do I get from the IETF? - This is a serious question for you as the person responsible for maintaining value in the IETF to answer... Got any ideas? The point is that the IETF has competition from all over today and to insure the continued value of its process and insured industry participation the IETF needs to wake up and smell the coffee. So Mr. Chair - what are you going to do? Todd Glassey ----- Original Message ----- From: To: ; Cc: Sent: Wednesday, October 15, 2003 1:56 AM Subject: RE: IESG proposed statement on the IETF mission Harald & Michael, It's *getting* worse ! A few years ago one operator was prepared to fund about 20 individuals to participate in the IETF; now that's reduced to about 5, with no guarantee that such a level will be sustained. This is not just about the downturn in the industry. Real problems that operators have are not being addressed by the IETF. If the IETF won't address my concerns, and if I have to go to the OMA to meet my requirements for application protocols, for example, that's where I'll go. You may say "That's fine". OK, if that's the policy. But, then, don't be surprised if it happens ! Regards, Graham Travers International Standards Manager BT Exact e-mail: graham.travers@bt.com tel: +44(0) 1359 235086 mobile: +44(0) 7808 502536 fax: +44(0) 1359 235087 HWB279, PO Box 200,London, N18 1ZF, UK BTexact Technologies is a trademark of British Telecommunications plc Registered office: 81 Newgate Street London EC1A 7AJ Registered in England no. 1800000 This electronic message contains information from British Telecommunications plc which may be privileged or confidential. The information is intended to be for the use of the individual(s) or entity named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information is prohibited. If you have received this electronic message in error, please notify us by telephone or email (to the numbers or address above) immediately. -----Original Message----- From: Harald Tveit Alvestrand [mailto:harald@alvestrand.no] Sent: 15 October 2003 08:35 To: Michael Richardson Cc: problem-statement@alvestrand.no Subject: Re: IESG proposed statement on the IETF mission It is a bad thing. But we saw in Vienna that the exodus is far from complete yet. So it could be worse.... --On 14. oktober 2003 21:37 -0300 Michael Richardson wrote: > >>>>>> "Harald" == Harald Tveit Alvestrand writes: > Harald> sort out which standards were actually needed. As the field > has Harald> grown explosively, specialization has set in, and market > pressures Harald> have risen, there has been less and less operator > participation in Harald> the IETF. > > I'm unclear if this documents thinks this is a good thing or a bad > thing. I think that it is a bad thing. > > ] Collecting stories about my dad: http://www.sandelman.ca/cjr/ | > firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON > |net architect[ ] mcr@sandelman.ottawa.on.ca > http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another > NetBSD/notebook using, kernel hacking, security guy"); [ > > From problem-statement-bounces@alvestrand.no Wed Oct 15 22:49:51 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA04517 for ; Wed, 15 Oct 2003 22:49:50 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id B8BB261BB5; Thu, 16 Oct 2003 04:49:26 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from noxmail.sandelman.ottawa.on.ca (oetest.freeswan.org [205.150.200.166]) by eikenes.alvestrand.no (Postfix) with ESMTP id D3D5561B9B; Wed, 15 Oct 2003 17:28:49 +0200 (CEST) Received: from sandelman.ottawa.on.ca (fctn1-2531.nb.aliant.net [156.34.217.227]) by noxmail.sandelman.ottawa.on.ca (8.11.6p3/8.11.6) with ESMTP id h9FFVcc04098 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified OK); Wed, 15 Oct 2003 11:31:40 -0400 (EDT) Received: from marajade.sandelman.ottawa.on.ca (marajade [127.0.0.1]) by sandelman.ottawa.on.ca (8.12.3/8.12.3/Debian-6.6) with ESMTP id h9FFN1cw028264 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Wed, 15 Oct 2003 12:23:02 -0300 Received: from marajade.sandelman.ottawa.on.ca (mcr@localhost) by marajade.sandelman.ottawa.on.ca (8.12.3/8.12.3/Debian-6.6) with ESMTP id h9FFMgt6028254; Wed, 15 Oct 2003 12:22:52 -0300 To: Harald Tveit Alvestrand In-reply-to: Your message of "Wed, 15 Oct 2003 11:22:32 +0200." <199210068.1066216952@halvestr-w2k1> Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Wed, 15 Oct 2003 12:22:42 -0300 Message-ID: <28253.1066231362@marajade.sandelman.ottawa.on.ca> From: Michael Richardson X-Mailman-Approved-At: Thu, 16 Oct 2003 04:49:25 +0200 Cc: graham.travers@bt.com, problem-statement@alvestrand.no Subject: Re: IESG proposed statement on the IETF mission X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no -----BEGIN PGP SIGNED MESSAGE----- I am also interesting in some examples. I'm not generally considered an operator. I seem to be involved in network, transport and security. (I say "seem", because I don't recall making a conscious decision to be...) But, I do run and deploy the systems that I build, and even run and co-own a small co-location facility in Ottawa. In fact, that's how I got into writing security systems - as a small operator (a student, at the time) who needed something done, and did it. My impression is that part of the "gap" is because fewer operators are actually doing development, and at the same time, we have more and more "engineers" who are not operators. (I put engineer in quotes on purpose. I seriously question their competency) For example, I point to people who post IDs to the mailing list (past the deadline) because... they don't have a personal web site they can post it to and give a pointer! Few in the IETF would consider "operating" a web site to be something that makes you an "operator", but the in-ability for supposedly competent engineers to even sign up at one of a zillion "free hosting" services, and "operate" a web site has astonished me. Of course they don't design good protocols- they seldom even use the ones already there. ] Collecting stories about my dad: http://www.sandelman.ca/cjr/ | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another Debian/notebook using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Finger me for keys - custom hacks make this fully PGP2 compat iQCVAwUBP41mQYqHRg3pndX9AQEADQP+OZkdEP42qiHDIWQo7WAocnEXXO/HCJpD QDOXED+gMtLNnPxjTK/XWEIIUFY6C3HhW6XvGqHOi+Y25Lw1tPH3Cob6pIEtHXM3 32X9rr4Ht65dEibn19rofkitBvGF/tsVzkkK6cRZYh9qt8FRMJpfnGkLBV1EqYiA 7QUbOLIfMh8= =0OWB -----END PGP SIGNATURE----- From problem-statement-bounces@alvestrand.no Wed Oct 15 22:49:53 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA04539 for ; Wed, 15 Oct 2003 22:49:53 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 8F64561C1C; Thu, 16 Oct 2003 04:49:29 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from noxmail.sandelman.ottawa.on.ca (noxmail.sandelman.ottawa.on.ca [205.150.200.166]) by eikenes.alvestrand.no (Postfix) with ESMTP id D86C461B9F; Wed, 15 Oct 2003 17:59:06 +0200 (CEST) Received: from sandelman.ottawa.on.ca (fctn1-2531.nb.aliant.net [156.34.217.227]) by noxmail.sandelman.ottawa.on.ca (8.11.6p3/8.11.6) with ESMTP id h9FG1tZ01465 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified OK); Wed, 15 Oct 2003 12:01:59 -0400 (EDT) Received: from marajade.sandelman.ottawa.on.ca (marajade [127.0.0.1]) by sandelman.ottawa.on.ca (8.12.3/8.12.3/Debian-6.6) with ESMTP id h9FFpEcw029924 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Wed, 15 Oct 2003 12:51:15 -0300 Received: from marajade.sandelman.ottawa.on.ca (mcr@localhost) by marajade.sandelman.ottawa.on.ca (8.12.3/8.12.3/Debian-6.6) with ESMTP id h9FFoxVJ029901; Wed, 15 Oct 2003 12:51:14 -0300 To: graham.travers@bt.com In-reply-to: Your message of "Wed, 15 Oct 2003 11:47:09 BST." <3D67CCA7D63E714B980D21A038EEA08E059276AC@i2km02-ukbr.domain1.systemhost.net> Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Wed, 15 Oct 2003 12:50:58 -0300 Message-ID: <29900.1066233058@marajade.sandelman.ottawa.on.ca> From: Michael Richardson X-Mailman-Approved-At: Thu, 16 Oct 2003 04:49:25 +0200 Cc: harald@alvestrand.no, problem-statement@alvestrand.no Subject: Re: IESG proposed statement on the IETF mission X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no -----BEGIN PGP SIGNED MESSAGE----- >>>>> "graham" == graham travers writes: graham> BTW, when is an application not an application ? What are the graham> characteristics that make "controlling street lights" less of an graham> application than (say) calendaring and scheduling? I don't The critical difference is whether or not multiple *operators* will have to communicate using the protocol. So, in the case of controlling street lights, it is pretty unlikely that the Chicago Municipal Street-Light Control Network (CMSLCN) will have to control lights located in New York City. As long as all of the equipement in the CMSLCN.net are owned by CMSLCN.net, then CMSLCN is in a position to: 1) dictate to their vendor what the standard will be. 2) provision the equipment (in advance) such that things interoperate 3) buy from whatever vendor pleases it most. As soon as the lights in NYC (owned, provisioned and bought by NYC) have to operate with the light controller in Chicago, then we need an IETF standard. Clearly, it is easiest for CMSLCN.net if they have a proven standard with products from multiple vendors that are already proven to interoperate, but the lack of such a thing does not affect the internet as a whole. This is one of the reasons why MPLS, and to a certain extent "PPVPN" gets downtrodden at the IETF - both are in many ways designed to operate within an AS, so it isn't clear that we should allocate lots of time to them. Vis multicast or IPv6, where it has been successfully deployed by many operators, but still isn't universally available, because it requires that all the operators between the n-locations cooperate and agree to some set of standards. (Not to mention that there be some rational business plan. Not that IPv4 had a rational business plan when it started either!) ] Collecting stories about my dad: http://www.sandelman.ca/cjr/ | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another Debian/notebook using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Finger me for keys - custom hacks make this fully PGP2 compat iQCVAwUBP41s4YqHRg3pndX9AQEm8QP/aYCldiWputlcxD5S4Ysu5phDrntUQE4W CMuJdk0GiwZanMOGYuuvKLHBLS7K4QGeFyZDhMZj8MjHzumZItSLOTluPR1jzadq eG1TQs63rRMVnyN4KZpx1SqupCaWi8HUClhLz4sxfPDMVHi5dxD3la3TgLoSK+as E0fPetNDOKw= =MoC/ -----END PGP SIGNATURE----- From problem-statement-bounces@alvestrand.no Thu Oct 16 01:30:51 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA07813 for ; Thu, 16 Oct 2003 01:30:50 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 642E361C1B; Thu, 16 Oct 2003 07:30:26 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from mtiwmhc11.worldnet.att.net (mtiwmhc11.worldnet.att.net [204.127.131.115]) by eikenes.alvestrand.no (Postfix) with ESMTP id F16B761BB5; Thu, 16 Oct 2003 07:30:23 +0200 (CEST) Received: from bolaba (190.sanjose-03-04rs16rt.ca.dial-access.att.net[12.81.1.190]) by worldnet.att.net (mtiwmhc11) with SMTP id <2003101605301511100a7lmfe>; Thu, 16 Oct 2003 05:30:18 +0000 Message-ID: <00a301c393a5$f1d179b0$010aff0a@bolaba> From: "todd glassey" To: , References: <200310151350.h9FDoYlb019613@rtp-core-2.cisco.com> Date: Wed, 15 Oct 2003 22:25:34 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Cc: harald@alvestrand.no, mcr@sandelman.ottawa.on.ca, problem-statement@alvestrand.no Subject: Re: Operator participation X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit The issue is one of whether the participants represent their own interests or those of the sponsor and how the sponsor itself becomes the focal point for an initiative. The intent is not to build "Joe's protocol" and Joe was sponsored by Widget Co, the intent is to have Widget Co's Protocol run through the IETF and this is a core reversal of the focus of the organization which was setup along the lines of an academic standards process - it supported the individual researcher as an individual - and there is nothing wrong with this, its just that the other side of the coin needs representation too. Todd ----- Original Message ----- From: "Eric Rosen" To: Cc: ; ; Sent: Wednesday, October 15, 2003 6:50 AM Subject: Re: Operator participation > > This business about there not being enough operator participation is a lot > of baloney. > > The reasons some operators think that there isn't enough operator > participation are (a) different sets of operators inhabit different WGs, and > (b) operators tend to ignore the input of other operators who may disagree > with them. > > If you look, e.g., at the main IETF list, at the routing-discussion list, at > the idr list, etc., you'll see one class of operator. If you look at the > PWE3 list, the MPLS list, the CCAMP list, the L3VPN list, the L2VPN list, > etc., you'll see an entirely different class. And within the latter lists, > there are large disagreements about very fundamental principles. For some > reason, each group denies the existence of the others. > > Of course, when any particular operator fails to achieve consensus for his > preferred solution, the problem is perceived as "not enough operator > input". > > I think the set of operators that Harald is thinking of would be aghast at > the proposals of the set of operators that Graham is thinking of. > > > > > > > From problem-statement-bounces@alvestrand.no Thu Oct 16 03:12:48 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA22420 for ; Thu, 16 Oct 2003 03:12:47 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 7AB2B61C25; Thu, 16 Oct 2003 09:12:24 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from d12lmsgate.de.ibm.com (d12lmsgate.de.ibm.com [194.196.100.234]) by eikenes.alvestrand.no (Postfix) with ESMTP id 1998161C23 for ; Thu, 16 Oct 2003 09:12:22 +0200 (CEST) Received: from d12relay01.megacenter.de.ibm.com (d12relay01.megacenter.de.ibm.com [9.149.165.180]) by d12lmsgate.de.ibm.com (8.12.10/8.12.8) with ESMTP id h9G7B8fw031642; Thu, 16 Oct 2003 09:11:23 +0200 Received: from ochsehorn.zurich.ibm.com (ochsehorn.zurich.ibm.com [9.4.16.140]) by d12relay01.megacenter.de.ibm.com (8.12.9/NCO/VER6.6) with ESMTP id h9G7AlRC251258; Thu, 16 Oct 2003 09:10:47 +0200 Received: from zurich.ibm.com (sig-9-145-243-99.de.ibm.com [9.145.243.99]) by ochsehorn.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id JAA19096; Thu, 16 Oct 2003 09:10:46 +0200 Message-ID: <3F8E33BB.471454B6@zurich.ibm.com> Date: Thu, 16 Oct 2003 07:59:23 +0200 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de MIME-Version: 1.0 To: Alistair.Urie@alcatel.com References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: problem-statement@alvestrand.no Subject: Re: IESG proposed statement on the IETF mission X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit Alistair, Actually I think it qualifies as a mistake according to the conclusions of the IAB workshop three years ago (RFC 3002), where we clearly identified walled gardens as a threat to the Internet as a whole. But I am not a SIP expert so I will not say more. I didn't mean that GSC iss a waste of time. However, there are strong limits to what such coordination can do. Ultimately, all the standards bodies are autonomous. Brian Alistair.Urie@alcatel.com wrote: > > Brian, > I think the SIP and 3GPP story is a bit more complex than you make out. > The so called "mistakes" are basically a set of direct consequences of 3GPP > strictly following the mobile operator's requirements to maintain a place > in the value chain and to let them hide certain details of their networks > from other operators. How this could be seen as being a "mistake" within > IETF does raise a few questions about our mechanisms for handling operator > requirements :-) > > As far as GSC (last meeting was in Ottawa - see > http://www.tsacc.ca/e/gsc/index.shtml) goes, all I can say is you have been > missing something since the last few meetings have been quite interesting > especially with respect to the use of SIP and other IETF protocols, midcom, > etc. within NGN. Scott has been coming and has been a very useful > contributor. I normally atend via "another organisation". > > - Aistair > > > Brian E Carpenter > To: graham.travers@bt.com > Sent by: cc: harald@alvestrand.no, mcr@sandelman.ottawa.on.ca, > problem-statement-bounces@al problem-statement@alvestrand.no > vestrand.no Subject: Re: IESG proposed statement on the IETF mission > > > 15/10/2003 16:35 > > > > Graham, > > I think the issues you are raising are very important. But I've been told > that, in > fact, 3GPP is doing things with SIP that have been specifically pointed out > as > mistakes by the IETF. I hope the same doesn't arise with OMA (it was > someone active > in OMA who told me the above, in fact). However, when this happens, there > really is > very little the IETF can do, however it reforms itself. I've been to enough > Global > Standards Coordination meetings and the like to doubt seriously whether > such > coordination can ever be better than an approximation. > > I think we have to concentrate on fixing what we have decided is wrong with > the > IETF. But identifying topics of importance to operators that are not being > tackled > in the IETF would be a useful exercise, IMHO. I've always wanted to see > Area Plans > for each IETF Area. > > Brian > > graham.travers@bt.com wrote: > > > > Harald, > > > > OK, since you ask so nicely. 8o) > > > > I'll amplify my comments in the full realisation that the last time I > mentioned that I have people working for me, I was practically accused of > being the Capitalist exploiter of slave labour ! > > > > There are two specific examples, where I supported issues being brought > to the IETF, and where I was prepared to put *real* effort into helping to > find solutions. (I mean actual resources to edit documents, chair > meetings, etc.) > > > > 1. Operations and maintenance support for MPLS. > > I went so far as to (be able to) run a BOF on this one (not me > personally). Despite a lot of interest at the BOF, and a stream of > "operator people" at the microphone supporting the view that the > functionality was needed, nothing useful transpired. Sure, the issue was > referred to the MPLS WG for consideration - and no doubt they considered a > lot - but the end result wasn't much use to me. It's now been addressed > elsewhere. This operator just can't afford to run protocols which don't > allow it to know what control it has. > > > > 2. Midcom. > > Some of my colleagues and I were instrumental in bringing this issue to > the IETF, and, sure enough, a WG was formed. While the analysis of > existing protocols was useful, after several years I still don't see any > standardised solution that I can/should use. Midcom is still running, so I > suppose that it hasn't finished its work yet. I'm still interested in > having a solution to this issue, but in the operator world time presses. > > > > Please understand that I'm *NOT* condemning the IETF for choosing its > work items. I am simply explaining that when something is needed, if it > can't be sourced from one supplier (the IETF) the purchaser has to find > another supplier, if possible (insert the name of any suitable SDO here!). > > > > As far as applications protocols go, I don't have any specific > requirements in mind. I mentioned that as an example since I've heard (not > first-hand) that the OMA is planning protocol developments, which will not > be referred to the IETF. One specific example that I mentioned earlier is > SIP. > > > > Brian Carpenter's response to this was to say that we can't control what > other SDO's do. > > While this may be technically true, I don't think that the IETF is > without influence. Whether it wants to use that influence, even in an > advisory capacity, is up for debate, I guess. As the standards that it > produces increasingly impinge on aspects of society other than the Internet > (the IESG proposed Statement mentions "controlling street lights" ), the > IETF has to either assume the responsibility of maintaining them for uses > outside the Internet, or abrogate that responsibility and let other > organisations do what they will with them. The "ultra-Internet" interests > will not be stopped, if they really want a solution. > > > > IMHO, to mangle a famous saying: "No SDO is an island." The International > Standards Community comprises many standards bodies, which have to > cooperate to achieve useful solutions. Where would the Internet be if > there were no standards for electricity supply, or cable capacity, or even > time and date ? The most important thing about a standard is not that the > solution is necessarily the best one, but that it is the *agreed* one. If > we start to have different versions of SIP, for example - the IETF version, > the 3GPP version, the OMA version - where is the standard, then ? > > > > BTW, when is an application not an application ? What are the > characteristics that make "controlling street lights" less of an > application than (say) calendaring and scheduling? I don't expect an > answer, but there must be some differentiator, if they both use the > Internet as a transport mechanism. If the IETF has, or is developing, such > differentiators, it would be useful to have them published. If it hasn't, > that may help to explain why there's been such a long-running debate. > > > > Regards, > > > > Graham Travers > > > > International Standards Manager > > BT Exact > > > > e-mail: graham.travers@bt.com > > tel: +44(0) 1359 235086 > > mobile: +44(0) 7808 502536 > > fax: +44(0) 1359 235087 > > > > HWB279, PO Box 200,London, N18 1ZF, UK > > > > BTexact Technologies is a trademark of British Telecommunications > plc > > Registered office: 81 Newgate Street London EC1A 7AJ > > Registered in England no. 1800000 > > > > This electronic message contains information from British > Telecommunications plc which may be privileged or confidential. The > information is intended to be for the use of the individual(s) or entity > named above. If you are not the intended recipient be aware that any > disclosure, copying, distribution or use of the contents of this > information is prohibited. If you have received this electronic message in > error, please notify us by telephone or email (to the numbers or address > above) immediately. > > > > > > ----Original Message----- > > From: Harald Tveit Alvestrand [mailto:harald@alvestrand.no] > > Sent: 15 October 2003 10:23 > > To: Travers,G,Graham,XVT TRAVERG R; mcr@sandelman.ottawa.on.ca > > Cc: problem-statement@alvestrand.no > > Subject: RE: IESG proposed statement on the IETF mission > > > > --On 15. oktober 2003 09:56 +0100 graham.travers@bt.com wrote: > > > > > Harald & Michael, > > > > > > It's *getting* worse ! > > > > > > A few years ago one operator was prepared to fund about 20 individuals > to > > > participate in the IETF; now that's reduced to about 5, with no > > > guarantee that such a level will be sustained. > > > > > > This is not just about the downturn in the industry. Real problems > that > > > operators have are not being addressed by the IETF. If the IETF won't > > > address my concerns, and if I have to go to the OMA to meet my > > > requirements for application protocols, for example, that's where I'll > go. > > > > > > You may say "That's fine". OK, if that's the policy. But, then, don't > > > be surprised if it happens ! > > > > Graham, > > > > thanks for your input! > > > > it would be nice if you could name examples - since I'm not an operator > and > > have rarely been on the forefront of the debates where you have been > > engaged, I don't have enough background to evaluate the experiences > you're > > sharing. > > > > In particular, I'm interested in hearing your requirements for > applications > > protocols - both because I come from an applications background myself > and > > believe the applications perspective to be important for the IETF, and > > because the proper boundary between "IETF work" and "application space > > work" is one of the long-simmering (long-festering?) debates that the > IETF > > has never been able to come to resolution on. > > > > Harald -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Brian E Carpenter Distinguished Engineer, Internet Standards & Technology, IBM NEW ADDRESS PLEASE UPDATE ADDRESS BOOK From problem-statement-bounces@alvestrand.no Thu Oct 16 05:37:50 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA25786 for ; Thu, 16 Oct 2003 05:37:49 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id C7B1261C23; Thu, 16 Oct 2003 11:37:27 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from halvestr-w2k1 (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 9ACA561C22; Thu, 16 Oct 2003 11:37:25 +0200 (CEST) Date: Thu, 16 Oct 2003 11:04:32 +0200 From: Harald Tveit Alvestrand To: erosen@cisco.com Message-ID: <11016450.1066302272@localhost> In-Reply-To: <200310151657.h9FGvBlb000917@rtp-core-2.cisco.com> References: <200310151657.h9FGvBlb000917@rtp-core-2.cisco.com> X-Mailer: Mulberry/3.1.0b8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Cc: problem-statement@alvestrand.no, ietf@ietf.org Subject: IETF mission boundaries (Re: IESG proposed statement on the IETF mission ) X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit Eric, --On 15. oktober 2003 12:57 -0400 Eric Rosen wrote: > Well, let's test this assertion. Suppose a consortium of electric > companies develops a UDP-based protocol for monitoring and controlling > street lights. It turns out that this protocol generates an unbounded > amount of traffic (say, proportional to the square of the number of > street lights in the world), has no congestion control, and no > security, but is expected to run over the Internet. > > According to you, this has nothing to do with the IETF. It might result > in the congestive collapse of the Internet, but who cares, the IETF > doesn't do street lights. I would like to see the criteria which > determine that telephones belong on the Internet but street lights don't! thanks for making the most concise statement of the conflict here in the discussion so far! I think this point is one of the critical causes of conflict when talking about the IETF mission - and unless we lance the boil, actually talk about it, and attempt to *resolve* the issue, we will go on revisiting the issue forever, with nothing but wasted energy to show for it. In the discussions leading up to this document, we actually had 3 different other levels of "inclusivity" up for consideration: - "Everything that runs over the Internet is appropriate for IETF standardization". Obviously, that might cause some reactions from organizations like the W3C, OMG, ISO, ITU, the power grid standardizers, the bank transaction standardizers and others.... even if the IETF were able to gather the required competence, it's hard to see how we could build a management structure that could handle "everything". - "Everything that needs open, documented interoperability and runs over the Internet is appropriate for IETF standardization". A bit smaller, but still huge, and hard to draw boundaries around. Advantage: Everything we currently work on is unquestionably part of the IETF's scope. - "Everything that builds infrastructures on the Internet that needs to be open and interoperable is appropriate for IETF standardization". This would place SMTP, DNS and LDAP (in the original vision) inside the IETF's sphere, but would leave the traffic lights (and the current way LDAP is used) outside it. - "Everything that can seriously impact the Internet is appropriate for IETF standardization". Argues for keeping HTTP and DNS, would include your hypothetical traffic lights, but would probably leave POP/IMAP out, and leaves people arguing about both SIP and L3VPN. - "For the Internet" - only the stuff that is directly involved in making the Internet work is included in the IETF's scope. It's far from clear in my mind what the right thing is, or what the appropriate path forward is if the IETF regards its purpose as being one or the other - we might, for instance, decide that we standardize stuff that needs to be open and interoperable, but have different evaluation criteria for those things than for those things that "make the Internet work", and will dispose our resources accordingly - I don't know. And if we decide that certain things we currently do are outside our scope, we've got a responsibility to make sure the work effort is handled in a responsible fashion. But it's relatively clear to my mind that continuing to have both sides of a discussion argue based on "the mission of the IETF", with conflicting definitions, is not the best thing for the Internet. So - rather than stating something completely vague, we put out a proposal. If it's the wrong proposal, it should be changed. But please be specific about what you think it should be changed to. makes sense? Harald From problem-statement-bounces@alvestrand.no Thu Oct 16 05:45:29 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA25939 for ; Thu, 16 Oct 2003 05:45:28 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id C7AB161C1C; Thu, 16 Oct 2003 11:45:06 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from halvestr-w2k1 (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id BD1D961BB5; Thu, 16 Oct 2003 11:45:04 +0200 (CEST) Date: Thu, 16 Oct 2003 11:43:07 +0200 From: Harald Tveit Alvestrand To: Melinda Shore Message-ID: <13331129.1066304587@localhost> X-Mailer: Mulberry/3.1.0b8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Cc: problem-statement@alvestrand.no Subject: Problems vs Social Dynamics (Re: IESG proposed statement on the IETF mission) X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit [limiting distribution a little] --On 15. oktober 2003 11:06 -0400 Melinda Shore wrote: > It's an interesting document, but it looks to me a bit much > like a problem description and I'm not sure how it relates > to other existing work (the problem description document in > the problem working group, most obviously). I particularly > liked the discussion of the IETF mission - it could provide > the basis for tackling one problem that's been raised on > a number of occasions, which is that the organization doesn't > have a clear sense of mission or vision. Even though in the > first paragraph of the "Social Dynamics" section you say that > "As they are neither good nor bad, it is not appropriate to > call them "problems;" rather think of them as social forces > and dynamics" a number of them really are framed as problems. > Indeed, it would be hard to define some way in which statements like > "making integration more difficult" are not problem statements. > > I'd really like to see the document, which I think has good > fundamentals, refocused on mission and goals. I think of this text (which was a collective work of the IESG, btw - I stand behind the words, but cannot take any special credit for them) as having two parts - one is the IETF mission, another is a view of the forcs that drive our present issues. These two have different purposes and targets, so it seems likely that they will eventually detach from each other and become separate documents. The discussion of "social dynamics" documents an attempt to understand *why* we have the problems we have, rather than naming the specific problems - it's trying to work at a different level than the level that the problem-statement WG has chosen. So I don't think of this and the problem-statement work as conflicting descriptions - this is rather an attempt to look at the same reality in a different way. Makes sense? Harald From problem-statement-bounces@alvestrand.no Thu Oct 16 08:26:49 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00242 for ; Thu, 16 Oct 2003 08:26:48 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id CDEC861BA0; Thu, 16 Oct 2003 14:26:25 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from d12lmsgate.de.ibm.com (d12lmsgate.de.ibm.com [194.196.100.234]) by eikenes.alvestrand.no (Postfix) with ESMTP id 4B6AC61B9E for ; Thu, 16 Oct 2003 14:26:23 +0200 (CEST) Received: from d12relay02.megacenter.de.ibm.com (d12relay02.megacenter.de.ibm.com [9.149.165.196]) by d12lmsgate.de.ibm.com (8.12.10/8.12.8) with ESMTP id h9GCQJfw032290 for ; Thu, 16 Oct 2003 14:26:21 +0200 Received: from ochsehorn.zurich.ibm.com (ochsehorn.zurich.ibm.com [9.4.16.140]) by d12relay02.megacenter.de.ibm.com (8.12.9/NCO/VER6.6) with ESMTP id h9GCQGWm255042 for ; Thu, 16 Oct 2003 14:26:16 +0200 Received: from zurich.ibm.com (sig-9-145-243-99.de.ibm.com [9.145.243.99]) by ochsehorn.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id OAA42448 for ; Thu, 16 Oct 2003 14:26:15 +0200 Message-ID: <3F8E8E4D.50A002D6@zurich.ibm.com> Date: Thu, 16 Oct 2003 14:25:49 +0200 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de MIME-Version: 1.0 To: problem-statement@alvestrand.no References: <157547561.1066175290@localhost> <20031015124837.79dbcd11.moore@cs.utk.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: IESG proposed statement on the IETF mission X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit (Only to problem-statement. I assume the interested parties are mainly here.) Firstly a general point. I am rather amazed that this draft comes from the IESG alone, and not from the IAB+IESG. In fact, I'd like an explanation. Since the IAB and the IESG are the two peer committees that the IETF puts in place to oversee the architecture and oversee the process, I simply don't buy the idea of a draft mission statement that comes from only one of them. Secondly, I agree with Melinda: take out the "problem" language. This document should contain exclusively positive statements. Thirdly: Keith Moore wrote: (and other people wrote similar things) ... > > > It is important that this is "For the Internet," and does not include > > everything that happens to use IP. IP is being used in a myriad of > > real-world applications, such as controlling street lights, but the > > IETF does not standardize those applications. > > I disagree with the sentiment as I understand it. I don't think it's > realistic anymore to take the view that what people run entirely on > private networks is their own business and outside of IETF's purview. > NATs, private addresses, and DHCP with short lease times have all had > devistating effects on the Internet's ability to support applications. > Insecure applications can facilitate the breeding of viruses that affect > the entire network even if their intended interactions are only between > a local client and server. Furthermore, we have *explicitly* in the past given warnings about the risk to users' interests of walled garden approaches. And RFC 3002 made a specific recommendation as a result (please read the whole RFC for context): 4.2.1 It was strongly recommended that independent of the ubiquity of the "walled garden" deployment scenario that protocols and architectural decisions should not target this model. To continue the success of Internet protocols at operating across a highly diverse and heterogeneous environment the IETF must continue to foster the adoption of an "open model". IETF protocol design must address seamless, secure, and scalable access. I would like to see the mission statement endorsing this. Of course the IETF will not standardize all *applications* but if we don't standardize the IP environment, including at least transport and transport security, and whatever is needed in the way of a session level, regardless of whether it is part of the big-I Internet, we will be doing our ultimate customers (ordinary users) an important disservice. What we also need in the mission statement is enough boundary-setting that we can relatively easily decide what fits into the "Applications" Area and whether the Sub-IP Area belonged here in the first place. (I put "Applications" in quotes because there isn't much in the Apps area that outsiders think of as applications.) Brian From problem-statement-bounces@alvestrand.no Thu Oct 16 08:38:44 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00702 for ; Thu, 16 Oct 2003 08:38:43 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 7DBD661BA7; Thu, 16 Oct 2003 14:38:20 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from sj-iport-1.cisco.com (sj-iport-1-in.cisco.com [171.71.176.70]) by eikenes.alvestrand.no (Postfix) with ESMTP id 2FD5F61B9E; Thu, 16 Oct 2003 14:38:17 +0200 (CEST) Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h9GCcDeH029375; Thu, 16 Oct 2003 05:38:14 -0700 (PDT) Received: from cisco.com (stealth-10-32-241-42.cisco.com [10.32.241.42]) by mira-sjc5-c.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with SMTP id ANE92439; Thu, 16 Oct 2003 05:38:12 -0700 (PDT) Date: Thu, 16 Oct 2003 08:38:11 -0400 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) To: Harald Tveit Alvestrand From: Melinda Shore In-Reply-To: <13331129.1066304587@localhost> Message-Id: <9A502998-FFD5-11D7-B3E6-000A95E35274@cisco.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) Cc: problem-statement@alvestrand.no Subject: Re: Problems vs Social Dynamics (Re: IESG proposed statement on the IETF mission) X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit On Thursday, October 16, 2003, at 05:43 AM, Harald Tveit Alvestrand wrote: > The discussion of "social dynamics" documents an attempt to understand > *why* we have the problems we have, rather than naming the specific > problems Arguably the problem-statement document was to have done that. At any rate my primary concern is that the draft of the IESG statement makes a start at articulating a mission but drifts towards problem description in the second half, and I think there's a strong sense within the organization that we really need a clear mission statement. Melinda From problem-statement-bounces@alvestrand.no Thu Oct 16 08:50:32 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA01165 for ; Thu, 16 Oct 2003 08:50:31 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id C55A261BA7; Thu, 16 Oct 2003 14:50:09 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27]) by eikenes.alvestrand.no (Postfix) with ESMTP id D875361B9A; Thu, 16 Oct 2003 14:50:06 +0200 (CEST) Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id h9GCo6X04144; Thu, 16 Oct 2003 15:50:06 +0300 (EET DST) Received: from daebh001.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 16 Oct 2003 15:50:06 +0300 Received: from daebe007.NOE.Nokia.com ([172.18.242.211]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 16 Oct 2003 05:50:05 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 16 Oct 2003 07:50:03 -0500 Message-ID: <697DAA22C5004B4596E033803A7CEF44013EFBED@daebe007.americas.nokia.com> Thread-Topic: Problems vs Social Dynamics (Re: IESG proposed statement on theIETF mission) Thread-Index: AcOT4mVUKn4GZfreRy2yJetxyExCYAAABjCQ From: To: , X-OriginalArrivalTime: 16 Oct 2003 12:50:05.0126 (UTC) FILETIME=[0589F660:01C393E4] Cc: problem-statement@alvestrand.no Subject: RE: Problems vs Social Dynamics (Re: IESG proposed statement on theIETF mission) X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: quoted-printable >=20 > On Thursday, October 16, 2003, at 05:43 AM, Harald Tveit Alvestrand=20 > wrote: > > The discussion of "social dynamics" documents an attempt to = understand=20 > > *why* we have the problems we have, rather than naming the specific=20 > > problems >=20 > Arguably the problem-statement document was to have done that. > At any rate my primary concern is that the draft of the IESG > statement makes a start at articulating a mission but drifts > towards problem description in the second half, and I think > there's a strong sense within the organization that we really > need a clear mission statement. I agree. The expanded/revised mission statement rambled on about how things have changed dramatically in the Internet and the=20 organizational issues as a result. However this is of no help to someone who is new and wants to understand what the IETF's mission is. It would be clearly far more valuable to explain=20 what are the goals of the IETF. So if this is mission statement is an attempt to fix one of the problems identified by the Problem-statement WG, then it does not *yet* solve the problem. But then its a +ve start and with a few revisions it can be fixed.=20 =20 >=20 > Melinda >=20 -Basavaraj From problem-statement-bounces@alvestrand.no Thu Oct 16 08:54:24 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA01267 for ; Thu, 16 Oct 2003 08:54:22 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id C94A361B9E; Thu, 16 Oct 2003 14:54:00 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from rwcrmhc12.comcast.net (rwcrmhc12.comcast.net [216.148.227.85]) by eikenes.alvestrand.no (Postfix) with ESMTP id 3DA7861B9A for ; Thu, 16 Oct 2003 14:53:59 +0200 (CEST) Received: from dfnjgl21 (12-237-229-250.client.attbi.com[12.237.229.250]) by comcast.net (rwcrmhc12) with SMTP id <2003101612535701400ki9p8e> (Authid: sdawkins@comcast.net); Thu, 16 Oct 2003 12:53:58 +0000 Message-ID: <023001c393e4$914412d0$0400a8c0@DFNJGL21> From: "Spencer Dawkins" To: References: <9A502998-FFD5-11D7-B3E6-000A95E35274@cisco.com> Date: Thu, 16 Oct 2003 07:53:58 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Subject: Re: Problems vs Social Dynamics (Re: IESG proposed statement on theIETF mission) X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list Reply-To: Spencer Dawkins List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit ... and, if we don't already have a problem statement, that's a problem, too ... Seriously, Brian wasn't very excited about an IESG-only/non-IESG+IAB mission statement, and I take his point. I have to say that I'm still wondering what more than two or three people on IESG think of the current problem statement draft, too. The contributions from IESG members have been very helpful. In the absence of a Process specification with WG oomph behind it, we seem to be (per the last Plenary) looking expectantly at the IESG as a group to respond to the problem statement draft. At least, that was my take - did I get it wrong? Any plans to respond at plenary time? Spencer p.s. I would have checked the Plenary minutes for confirmation, but I'm getting a 404 from http://www.ietf.org/proceedings/03jul/index.html :-{ ----- Original Message ----- From: "Melinda Shore" To: "Harald Tveit Alvestrand" Cc: Sent: Thursday, October 16, 2003 7:38 AM Subject: Re: Problems vs Social Dynamics (Re: IESG proposed statement on theIETF mission) > On Thursday, October 16, 2003, at 05:43 AM, Harald Tveit Alvestrand > wrote: > > The discussion of "social dynamics" documents an attempt to understand > > *why* we have the problems we have, rather than naming the specific > > problems > > Arguably the problem-statement document was to have done that. > At any rate my primary concern is that the draft of the IESG > statement makes a start at articulating a mission but drifts > towards problem description in the second half, and I think > there's a strong sense within the organization that we really > need a clear mission statement. > > Melinda > From problem-statement-bounces@alvestrand.no Thu Oct 16 10:33:34 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05367 for ; Thu, 16 Oct 2003 10:33:33 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id DD0EC61BDC; Thu, 16 Oct 2003 16:33:10 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by eikenes.alvestrand.no (Postfix) with ESMTP id F3F2B61BB9; Thu, 16 Oct 2003 16:33:07 +0200 (CEST) Received: from cisco.com (erosen-u10.cisco.com [161.44.70.36]) by rtp-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h9GEX3FQ022376; Thu, 16 Oct 2003 10:33:03 -0400 (EDT) Message-Id: <200310161433.h9GEX3FQ022376@rtp-core-2.cisco.com> To: Michael Richardson In-reply-to: Your message of Wed, 15 Oct 2003 12:50:58 -0300. <29900.1066233058@marajade.sandelman.ottawa.on.ca> User-Agent: EMH/1.14.1 SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (=?ISO-8859-4?Q?Unebigory=F2mae?=) APEL/10.3 Emacs/21.3 (sparc-sun-solaris2.8) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII Date: Thu, 16 Oct 2003 10:33:02 -0400 From: Eric Rosen Cc: graham.travers@bt.com, problem-statement@alvestrand.no, harald@alvestrand.no Subject: Re: IESG proposed statement on the IETF mission X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list Reply-To: erosen@cisco.com List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no > The critical difference is whether or not multiple *operators* will have > to communicate using the protocol. > As soon as the lights in NYC (owned, provisioned and bought by NYC) have > to operate with the light controller in Chicago, then we need an IETF > standard. You are making a host of unwarranted assumptions. It's perfectly conceivable that NYC has, say, five different networks, one for each of its five boroughs, and that each network is run in an autonomous fashion. It's equally conceivable that the main street light control facility is in Manhattan, and it needs to talk to the lights in each of the five boroughs. If one thinks of street lights in a set of smaller towns, it's quite conceivable that each town has its own network, but that light control is done from a regional center jointly funded by the towns. It's also conceivable that a bunch of towns in one state might contract out their light control functions to a company whose monitoring/control center is in another state entirely. So I don't think your criterion rules out the street light protocol. There are some things which are clearly ruled out by your criterion: for example, OSPF would be ruled out, and so would DHCP. I think SNMP would be ruled out as well (one operator managing another's routers?). I'd say then that your criterion does not reflect any existing practice nor does it reflect a desirable practice. From problem-statement-bounces@alvestrand.no Thu Oct 16 13:15:29 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11562 for ; Thu, 16 Oct 2003 13:15:28 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id CF8C361C0A; Thu, 16 Oct 2003 19:15:07 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by eikenes.alvestrand.no (Postfix) with ESMTP id CD84961BE1; Thu, 16 Oct 2003 19:15:05 +0200 (CEST) Received: from cisco.com (erosen-u10.cisco.com [161.44.70.36]) by rtp-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h9GHF2FQ026610; Thu, 16 Oct 2003 13:15:02 -0400 (EDT) Message-Id: <200310161715.h9GHF2FQ026610@rtp-core-2.cisco.com> To: Harald Tveit Alvestrand In-reply-to: Your message of Thu, 16 Oct 2003 11:04:32 +0200. <11016450.1066302272@localhost> User-Agent: EMH/1.14.1 SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (=?ISO-8859-4?Q?Unebigory=F2mae?=) APEL/10.3 Emacs/21.3 (sparc-sun-solaris2.8) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII Date: Thu, 16 Oct 2003 13:15:02 -0400 From: Eric Rosen Cc: problem-statement@alvestrand.no, ietf@ietf.org Subject: Re: IETF mission boundaries (Re: IESG proposed statement on the IETF mission ) X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list Reply-To: erosen@cisco.com List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no > - "For the Internet" - only the stuff that is directly involved in making > the Internet work is included in the IETF's scope. In other words, routing, DNS, and Internet operations/management. Adopting this as the IETF's mission would be a very radical change indeed! While this particular mission statement does seem to reflect the interests of a certain notorious IESG member, let's not pretend that this has ever been the limit of the IETF's mission. The IETF has always been concerned with things that make the Internet more useful, and with things that expand the utility of the IP protocol suite. There's never been a time when "for the Internet" was an accurate representation of the IETF's concerns. You are of course welcome to propose such a radical change to the IETF's mission. But if you are going to circulate a document under the subject line "IESG proposed statement on the IETF mission", you should make it clear that the IESG is proposing to make a complete change in the IETF mission. Instead, you give the impression that the IESG thinks that "for the Internet" is and has always been the IETF's mission. The formulation I like is "Everything that needs open, documented interoperability and runs over the Internet is appropriate for IETF standardization". This is much truer to the IETF's current and historical practice. That doesn't necessarily mean that the IETF has to standardize everything that falls within its mission. For instance, a particular area might fall within the mission, but the IETF might not have the expertise to tackle it. A WG in that area could then be rejected on the grounds of "insufficient expertise". Such decisions would have to be made on a case-by-case basis. Again, this is the way such decisions have always been made in the IETF. From problem-statement-bounces@alvestrand.no Fri Oct 17 03:58:53 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA23225 for ; Fri, 17 Oct 2003 03:58:52 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id E1B0B61BDF; Fri, 17 Oct 2003 09:58:28 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by eikenes.alvestrand.no (Postfix) with ESMTP id A936D61BB9; Thu, 16 Oct 2003 18:41:37 +0200 (CEST) Received: (from bmanning@localhost) by boreas.isi.edu (8.11.6p2+0917/8.11.2) id h9GGfZe28863; Thu, 16 Oct 2003 09:41:35 -0700 (PDT) From: Bill Manning Message-Id: <200310161641.h9GGfZe28863@boreas.isi.edu> In-Reply-To: <11016450.1066302272@localhost> from Harald Tveit Alvestrand at "Oct 16, 3 11:04:32 am" To: harald@alvestrand.no (Harald Tveit Alvestrand) Date: Thu, 16 Oct 2003 09:41:35 -0700 (PDT) X-Mailer: ELM [version 2.4ME+ PL39 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Fri, 17 Oct 2003 09:58:27 +0200 Cc: problem-statement@alvestrand.no, ietf@ietf.org Subject: Re: IETF mission boundaries (Re: IESG proposed statement on the IETF mission ) X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit % --On 15. oktober 2003 12:57 -0400 Eric Rosen wrote: % % > Well, let's test this assertion. Suppose a consortium of electric % > companies develops a UDP-based protocol for monitoring and controlling % > street lights. It turns out that this protocol generates an unbounded % > amount of traffic (say, proportional to the square of the number of % > street lights in the world), has no congestion control, and no % > security, but is expected to run over the Internet. % > % > According to you, this has nothing to do with the IETF. It might result % > in the congestive collapse of the Internet, but who cares, the IETF % > doesn't do street lights. I would like to see the criteria which % > determine that telephones belong on the Internet but street lights don't! % % thanks for making the most concise statement of the conflict here in the % discussion so far! % I think this point is one of the critical causes of conflict when talking % about the IETF mission - and unless we lance the boil, actually talk about % it, and attempt to *resolve* the issue, we will go on revisiting the issue % forever, with nothing but wasted energy to show for it. % % In the discussions leading up to this document, we actually had 3 different % other levels of "inclusivity" up for consideration: % % - "Everything that runs over the Internet is appropriate for IETF % % - "Everything that needs open, documented interoperability and runs over % the Internet is appropriate for IETF % % - "Everything that builds infrastructures on the Internet that needs to be % open and interoperable is appropriate for IETF standardization". % % - "Everything that can seriously impact the Internet is appropriate for % IETF standardization". % - "For the Internet" - only the stuff that is directly involved in making % the Internet work is included in the IETF's scope. % % a discussion argue based on "the mission of the IETF", with conflicting % definitions, is not the best thing for the Internet. % % Harald I guess for me, I always thought that the IETF and its precursors were interested in developing engineering solutions / designing protocols that would allow "end2end or any2any" communications, regardless of underlying transport media, be it seismic wave, avian carrier, radio waves or the PSTN. - At no time did I ever truly beleive that the systems that used these protocols/solutions would always be on and fully connected. Infrastructures that use IETF products have nearly always been only partially connected and many systems are not always on. So while a design goal might have been to support always on/fully connected state, the reality is that infrastructres have nearly always been disjoint/unconnected and endpoints come and go. But when they are connectable, they should function in a seamless, e2e fashion, at least IMHO. And then you neglect an unstated presumption in the last two bullet points: As perceived by who? --bill Opinions expressed may not even be mine by the time you read them, and certainly don't reflect those of any other entity (legal or otherwise). From problem-statement-bounces@alvestrand.no Fri Oct 17 03:58:55 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA23241 for ; Fri, 17 Oct 2003 03:58:54 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id B22BB61C05; Fri, 17 Oct 2003 09:58:31 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from mail3.microsoft.com (mail3.microsoft.com [131.107.3.123]) by eikenes.alvestrand.no (Postfix) with ESMTP id 0FB4B61BAC; Fri, 17 Oct 2003 00:15:54 +0200 (CEST) Received: from INET-VRS-03.redmond.corp.microsoft.com ([157.54.5.27]) by mail3.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 16 Oct 2003 15:15:52 -0700 Received: from 157.54.8.109 by INET-VRS-03.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 16 Oct 2003 15:15:51 -0700 Received: from RED-IMC-04.redmond.corp.microsoft.com ([157.54.2.168]) by inet-hub-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 16 Oct 2003 15:15:51 -0700 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by RED-IMC-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 16 Oct 2003 15:15:50 -0700 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Thu, 16 Oct 2003 15:15:50 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7097.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 16 Oct 2003 15:15:56 -0700 Message-ID: Thread-Topic: IETF mission boundaries (Re: IESG proposed statement on the IETF mission ) thread-index: AcOTzBbAi1IaJVfhQ0yRRlka+N83eQAZNxhg From: "Christian Huitema" To: "Harald Tveit Alvestrand" , X-OriginalArrivalTime: 16 Oct 2003 22:15:50.0414 (UTC) FILETIME=[0E81DAE0:01C39433] X-Mailman-Approved-At: Fri, 17 Oct 2003 09:58:27 +0200 Cc: problem-statement@alvestrand.no, ietf@ietf.org Subject: RE: IETF mission boundaries (Re: IESG proposed statement on the IETF mission ) X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: quoted-printable > > According to you, this has nothing to do with the IETF. It might > result > > in the congestive collapse of the Internet, but who cares, the IETF > > doesn't do street lights. I would like to see the criteria which > > determine that telephones belong on the Internet but street lights > don't! >=20 > thanks for making the most concise statement of the conflict here in the > discussion so far! > I think this point is one of the critical causes of conflict when talking > about the IETF mission - and unless we lance the boil, actually talk about > it, and attempt to *resolve* the issue, we will go on revisiting the issue > forever, with nothing but wasted energy to show for it. Well, to paraphrase a well known leader, "the IETF, how many divisions?" The gist of this comment is that someone developing a network application protocol ought to somehow get a blessing from the IETF. Reality check. Who got the IETF approval to deploy ICQ, Kazaa, or for that matter HTTP? If the Internet is so fragile that a poorly developed application can break it, then the IETF response should not be to try control each application. It has to be, design checks that can be implemented by cooperating hosts and routers so that their neck of the Internet is in good health! -- Christian Huitema From problem-statement-bounces@alvestrand.no Fri Oct 17 03:58:58 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA23265 for ; Fri, 17 Oct 2003 03:58:57 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 8F51E61C13; Fri, 17 Oct 2003 09:58:35 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from tomts31-srv.bellnexxia.net (tomts31-srv.bellnexxia.net [209.226.175.105]) by eikenes.alvestrand.no (Postfix) with ESMTP id 425D761B8D; Fri, 17 Oct 2003 08:30:17 +0200 (CEST) Received: from yahoo.com ([65.93.181.155]) by tomts31-srv.bellnexxia.net (InterMail vM.5.01.06.05 201-253-122-130-105-20030824) with ESMTP id <20031017063012.NOTJ20110.tomts31-srv.bellnexxia.net@yahoo.com>; Fri, 17 Oct 2003 02:30:12 -0400 Date: Fri, 17 Oct 2003 02:30:10 -0400 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) To: erosen@cisco.com From: Simon Woodside In-Reply-To: <200310151657.h9FGvBlb000917@rtp-core-2.cisco.com> Message-Id: <5BC4BFD8-006B-11D8-B366-000A9573F104@yahoo.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) X-Mailman-Approved-At: Fri, 17 Oct 2003 09:58:27 +0200 Cc: problem-statement@alvestrand.no, ietf@ietf.org, Harald Tveit Alvestrand Subject: Re: IESG proposed statement on the IETF mission X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit On Wednesday, October 15, 2003, at 12:57 PM, Eric Rosen wrote: > >> "The purpose of the IETF is to create high quality, relevant, and >> timely >> standards for the Internet." > >> It is important that this is "For the Internet," and does not include >> everything that happens to use IP. IP is being used in a myriad of >> real-world applications, such as controlling street lights, but the >> IETF does not standardize those applications. Yes, and towards a possibly more contentious application, see Voice over IP. Lots of VoIP work is being done without involving the internet at all. Used by telecoms for telecoms applications, where "best effort" isn't good enough because it needs to keep working when the power goes out. IP, yes, Internet, no. Against that you have "voice over internet" which is AKA "voice chat" and already abounds in true internet p2p apps like iChat, GnomeMeeting, and some programs on that other OS. These run on the public internet and benefit from the IETF design paradigms like edge-to-edge (aka end2end) and best effort but also have to accept the relevant drawbacks. simon > Well, let's test this assertion. Suppose a consortium of electric > companies > develops a UDP-based protocol for monitoring and controlling street > lights. > It turns out that this protocol generates an unbounded amount of > traffic > (say, proportional to the square of the number of street lights > in the > world), has no congestion control, and no security, but is expected > to run > over the Internet. > > According to you, this has nothing to do with the IETF. It might > result in > the congestive collapse of the Internet, but who cares, the IETF > doesn't do > street lights. I would like to see the criteria which determine > that > telephones belong on the Internet but street lights don't! > > Another problem with your formulation is that the Internet is a > growing, > changing, entity, so "for the Internet" often means "for what I > think the > Internet should be in a few years", and this is then a > completely > unobjective criterion. One would hope instead that the IETF would > want to > encourage competition between different views of Internet evolution, > as the > competition of ideas is the way to make progress. > > I also do not understand whether "for the Internet" means something > different > than "for IP networking" or not. > > I think it should also be part of the mission to produce > standards that > facilitate the migration to IP of applications and infrastructures > that use > legacy networking technologies. Such migration seems to be good > for the > Internet, but I don't know if it is "for the Internet" or not. > > -- www.simonwoodside.com :: www.openict.net :: www.semacode.org 99% Devil, 1% Angel From problem-statement-bounces@alvestrand.no Fri Oct 17 03:59:01 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA23285 for ; Fri, 17 Oct 2003 03:59:00 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 520CE61C1C; Fri, 17 Oct 2003 09:58:37 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132]) by eikenes.alvestrand.no (Postfix) with SMTP id DD77E61BDF for ; Fri, 17 Oct 2003 09:42:00 +0200 (CEST) Received: (qmail 50454 invoked from network); 17 Oct 2003 07:41:29 -0000 Received: from vaio.hpcl.titech.ac.jp (HELO necom830.hpcl.titech.ac.jp) (131.112.32.134) by necom830.hpcl.titech.ac.jp with SMTP; 17 Oct 2003 07:41:29 -0000 Message-ID: <3F8F9D82.80602@necom830.hpcl.titech.ac.jp> Date: Fri, 17 Oct 2003 16:42:58 +0900 From: masataka ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja, en-us, en MIME-Version: 1.0 To: Simon Woodside References: <5BC4BFD8-006B-11D8-B366-000A9573F104@yahoo.com> In-Reply-To: <5BC4BFD8-006B-11D8-B366-000A9573F104@yahoo.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Fri, 17 Oct 2003 09:58:27 +0200 Cc: problem-statement@alvestrand.no, ietf@ietf.org, Harald Tveit Alvestrand Subject: Re: IESG proposed statement on the IETF mission X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit Simon Woodside; > Yes, and towards a possibly more contentious application, see Voice over > IP. Lots of VoIP work is being done without involving the internet at > all. Used by telecoms for telecoms applications, where "best effort" > isn't good enough because it needs to keep working when the power goes > out. IP, yes, Internet, no. Why, do you think, the Internet may stop working when the power goes out? It should not, which is required to certain ISPs by regulation at least in Japan. > Against that you have "voice over internet" which is AKA "voice chat" > and already abounds in true internet p2p apps like iChat, GnomeMeeting, > and some programs on that other OS. These run on the public internet and > benefit from the IETF design paradigms like edge-to-edge (aka end2end) > and best effort but also have to accept the relevant drawbacks. "voice chat"? Are you assuming PCs? POTS telephone devices and terminal adaptors is the natural way of "voice over the Internet". Note that end to end architecture means ultimate availability of fate sharing. Masataka Ohta PS According to the end to end principle, end user equipments should have their own power backup, of course, which is also the case with ISDN TA or cellular phone devices. Then, with multihoming, your connection is a lot more robust than that of a single telephone company. From problem-statement-bounces@alvestrand.no Fri Oct 17 07:47:29 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28550 for ; Fri, 17 Oct 2003 07:47:26 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 7D52661BE1; Fri, 17 Oct 2003 13:47:03 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from zctfs063.nortelnetworks.com (zctfs063.nortelnetworks.com [47.164.128.120]) by eikenes.alvestrand.no (Postfix) with ESMTP id 1BBAA61BDF for ; Fri, 17 Oct 2003 13:46:52 +0200 (CEST) Received: from znsgs01r.nortelnetworks.com (znsgs01r.nortelnetworks.com [47.137.129.92]) by zctfs063.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h9HBklb15043; Fri, 17 Oct 2003 13:46:47 +0200 (MEST) Received: from zwcwc012.europe.nortel.com (zwcwc012.europe.nortel.com [47.160.46.124]) by znsgs01r.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h9HBkjs24936; Fri, 17 Oct 2003 12:46:45 +0100 (BST) Received: by zwcwc012.europe.nortel.com with Internet Mail Service (5.5.2653.19) id <4D03MGR7>; Fri, 17 Oct 2003 12:46:46 +0100 Message-ID: <4103264BC8D3D51180B7002048400C45043ABACD@zhard0jd.europe.nortel.com> From: "Elwyn Davies" To: "'Charlie Perkins'" , Problem Statement Working Group Date: Fri, 17 Oct 2003 12:46:45 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C394A4.5749E4D6" Subject: RE: More detailed comments on the Problem Statement document X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C394A4.5749E4D6 Content-Type: text/plain Hi, again. Thoughts below. > -----Original Message----- > From: Charlie Perkins [mailto:charliep@iprg.nokia.com] > Sent: 07 October 2003 03:09 > To: Problem Statement Working Group > Subject: More detailed comments on the Problem Statement document > > > > Hello again folks, > > In general, the document is quite verbose. A spell checker should > be employed, and ways should be found to eliminate redundancy. Apologies for the spelling drop-offs - they will be fixed. Jeanette Hofmann has already commented on the issue of redundancy (I don't think there is much anyway). As regards verbosity - it is sometimes difficult to avoid touching peoples hot buttons without a few extra words. > > Here are some more detailed comments on the draft. > > In section 2.1, I do not like the following sentence: > > > o The misty vision has inhibited the development of > roadmaps that > > would inform the IETF's stakeholders of our longer term > > intentions, > > In the first place, I don't think the IETF has many longer > term intentions, > except perhaps "saving the Internet". Such intentions don't > necessarily > need "roadmaps". I think the IETF is much more reactive than would > be understood from the above sentence, and I think it's a > good thing for > the IETF to be that way. This is not to say that the IETF > can only solve > problems after they occur. I do think think that the IETF > should try to > prevent problems, as far in advance as we reasonably can. But the > IETF actions are happening in response to identified problems, not > (in general!) according to some over-arching roadmap, architecture, > plan, or vision. This is a matter of opinion - some people certainly perceive that we need more in the way of forward planning against a roadmap and others would like to know further in advance where we think we are going. Maybe the IETF is too reactive! > > In section 2.2, on page six, there is the following text: > > > o Failure to identify and articulate engineering > trade-offs that may > > be needed to meet the deadlines that the WG has set without > > inappropriately reducing the 'fitness for purpose' for the > > intended customers. > > > > o Continued refinement of the solution beyond the point > at which it > > is adequate to meet the requirements placed on it by > the intended > > purpose. > > > I am concerned that listing these as bullets needing attention is > counterproductive. For one thing, most engineers are aware that > these problems need to be avoided. On the general assumption that > most WG staff (i.e., the ones that do the work and that care) are > engineers, there isn't much need to restate the obvious, and most > people will not derive much useful content from these bullets -- i.e., > it's the negative equivalent of "motherhood and apple pie". I don't > remember when anyone consciously acted in the above bad ways. > I fear I have taken part in a number of working groups that have lost sight of these engineering principles even if the individual engineers are indeed well aware of them (the tail end of DiffServ comes to mind - the discussions of the minutiae of how Expedited Forwarding might be refined in particular). This is certainly related to the demise of the true purpose of Proposed Standards and the rise of the thought experiment. > In the next list: > > > o Poorly defined success criteria for WGs and > individual documents. > > I'm not sure this is really worth calling out as a specific problem. > For one thing, the success criteria are the charter items. > For another > thing, if there is a poorly defined criterion, it stems more from the > problem with the standards track than anything else, and that's > not going to get fixed by rewhacking WG processes. Most charters specify that they will produce a set of documents for standardizing something (OK some of them do rather better recently) but we really ought to be clearer about when we will know we have the right answer. > > To the point: > > > o Lack of review, especially early review, by reviewers > who are not > > directly interested mebers of the WG, and by subject matter > > experts for topics related to, but not necessarily > the immediate > > focus of the document. > > I would like to suggest that we not view this as a "problem", > because there > might not be a good solution. Good external reviewers don't > grow on trees, > and if they did anyway we would find the trees are already completely > plucked for other reasons. I don't see how we can expect to > get so many > good external reviewers that they could spend time reading > early drafts that > aren't even implemented by WG members yet. I'd much rather see such a > valuable resource be put to use after some initial validation > within the > working > group itself. I am sorry to say that I think this is defeatist and an attempt to brush under the carpet something which can cause us lots of problems downstream. I thought that our experiences in software engineering had demonstrated that early review paid dividends many times over! Early review needn't necessarily be terribly time consuming (after all the details are probably not yet fleshed out) but an experienced SME might well catch the flaws quickly and before they become too well embedded into the fundamental structure. > > Another way to attack this deficiency, as I have tried to > suggest before, is > that as time goes on, we amass a body of documentation by > subject matter > experts that explain how to avoid certain cross-working-group > problems. > It's a lot more scalable to ask engineers to try to find > relevant documents > that have been written about a relevant area of cross-expertise > interactions, > than it is for them to find an expert to explain it for the millionth > time on the > expert's personal timeline. > > So, I'd replace that bullet by something like: > > o Lack of documentation about likely problem areas that might arise > due to interactions with other popular IETF protocols. I'd rather add this bullet - I think you raise a good point but ultimately there is no substitute for a practised eye and a broad knowledge of what is going on now (as opposed to distilled wisdom which will inevitably be abstracted and somewhat out of date). > > The point, on page 12 > > > o Absence of documented debriefing sessions to assess > and record the > > successes and failures of WGs (and other processes) > so that the > > positive and negative lessons learned can be used to > facilitate > > future work and improve the processes. > > is essentially the same as the previous point, and both could > be expressed > more succinctly as: > > o Lack of a WG "post mortem" procedure to drive the improvement of > the standards development process. Agreed but it should also extend beyond WG processes. > > The following point: > > > o Lack of criteria for determining when a piece of work is > > overrunning and/or is unlikely to be concluded > successfully either > > at all or within an acceptable time frame: Lack of process for > > either extending the time frame, adjusting the scope or > > terminating the work item or the whole Working Group. > > is debatable, because the process should be "amending the charter", > and the criteria should be "according to the charter". It may be debatable but it is a perceived problem - this one of those where some people see it as a problem but you don't. > > On a positive note, I wholeheartedly agree with the following point, > and I suggest that current efforts towards improvement be encouraged > and extended: > > > o Automated tools to support the engineering process > are minimal. Phew! > > Regarding the next bullet item, I would suggest that no > change is needed > to current IETF processes: > > > o Despite its commitment to 'running code', the IETF is not > > proactive in providing ways for developers to verify their > > implementations of IETF standards. > > So far as I can tell, the developers are quite adept at making this > happen regardless of whether the IETF helps or not. Or, as they > say, "If it's not broke, don't fix it". > > Also on page 12, the following bullets are redundant and > could beneficially > be deleted to avoid numbing repetition: > > > o Project entry, goal setting, dependency identification, > > coordination and tracking processes are all either missing or > > implemented less effectively than the norm for commercial > > organizations in related activities. Dependencies and > coordination > > should cover both other WGs within the IETF and any > outside SDO > > with which the IETF is collaborating. > > > > o Charters regularly fail to set sufficiently granular > milestones at > > which progress of WGs, individuals and documents can > be evaluated. > > Also WGs often do not make more detailed work plans > to refine the > > charter plans. > > > > o The acceptable deadlines for finishing a piece of > work, and the > > criteria used to determine them, are rarely, if ever, > documented. > > Also the estimates of the time required to complete > the work often > > ....... > > Unless I am missing something, all of these ideas have > already appeared > earlier in the section. I agree that there is some overlap but I would argue that it is justified because the evidence is posted regarding separate issues (lack of process improvement techniques and poor application of management techniques). Also I think mind-numbing is over-egging the pudding! If you want mind-numbing go and re-read the problem statement mailing list archives. > > On the next page, I disagree with the following statement: > > > One problem which the IETF does not appear to suffer from is > > excessive bureaucracy, in the sense that transfer of > information is > > generally kept to the minimum necessary to accomplish the task. > > For one thing, I might suggest that the current "rfc-editor" > processing > is quite bureaucratic, regardless of its value. Also, the > evaluation of > criteria for advancement along the standards track, the submission > process for Internet Drafts, the BOF approval, and other examples > can be viewed as more or less bureaucratic. Maybe it's not as > bureaucratic as other organizations. Maybe. > > Another problem is that one person's "minimality" may well be another > person's "insufficiency". Typically, bureaucracy creates > procedure based > on historical problem solving episodes. I can think about the IANA > considerations in exactly this way -- a little bit along the > way towards > how mortgage agreements are structured. Of course, one wants to > avoid ALL systemic problems in permanent transactions. > > So, I'd reduce the amount of self-congratulation on this > point. The best > you can say is that the IETF bureaucracy is younger than some of the > other bureaucracies we might be able to name. A matter of opinion - I haven't seen any other criticism of this point. > > In section 2.3, the first paragraph should cross-reference section 2.2 > since the topic is related to the lack of external review. > Perhaps better, > the bullet in section 2.2 should be moved here, on the theory > that this > is a fact of life, not a problem we can try to solve. Not everybody agrees that this can't be solved. The cross reference may be useful. > > I have another thought about section 2.3 that I have moved into > a separate note. I have reviewed this and the responses - I think Brian Carpenter's view that the matter is already covered is correct. It is however a major potential roadblock if it results in reinvention of wheels and should certainly be addressed in 'solutions'. > > Regarding the point on pg. 14: > > > o The IETF does not have an effective means for defining > > architectures and frameworks that will shape the work > of multiple > > WGs. > > ... that is something that should be done by the IAB. So I would say > that the IETF does have the means, but it's perhaps not yet effective. Maybe it ought to but it is not clear that it believes it has a mandate to do this. > > On page 16, in section 2.5, the following sentence should be deleted: > > > Whilst this might be put down to contributors having less time > > available in their work schedule during the downturn of > the last two > > years, this is not the whole story because there were > signs of this > > effect back at the height of the boom in 2000. > I disagree. I think that it is important that this is not just dismissed as a side-effect of the industry downturn. > > In section 2.6.4, the last paragraph should be deleted. It > has no place, > and the most charitable interpretation would put it squarely into a > solutions > document. More likely, it looks like an insult. This paragraph has escaped the de-solutioning sweep. However I don't believe it should be deleted. It certainly appears that in some cases IESG delays have been used as a smoke-screen to disguise or even foment slow progress (where some interest group doesn't really want progress). I'll rephrase it a bit. > > In section 2.7, the claim is made that problems result from the > non-hierarchical nature of the working group. I don't believe it. > I have never seen this as a problem. In fact, I would characterize > it as a feature. > > If anything, there might be a problem with assignment of tasks, > and accountability for accomplishing those tasks. Typically, > hierarchy helps with delegation, accountability, and evaluation, > but the lack of hierarchy does not mean the lack of those > three management aids. In fact, I would in solution space > suggest that the new methods for issue tracking could be tied > in with a non-hierarchical method for delegation, accountability, > and evaluation for better results. It is certainly a feature but many people find it difficult or contrary to their normal working experience, and it certainly can make it very difficult to handle deadlines. I am guilty as charged! Regards, Elwyn. > > I will send out yet another note with detailed editorial remarks, > with a lot less substance and importance compared to these > comments. > > Regards, > Charlie P. > > > ------_=_NextPart_001_01C394A4.5749E4D6 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: More detailed comments on the Problem Statement = document

Hi, again.

Thoughts below.

> -----Original Message-----
> From: Charlie Perkins [mailto:charliep@iprg.nokia.com]
> Sent: 07 October 2003 03:09
> To: Problem Statement Working Group
> Subject: More detailed comments on the Problem = Statement document
>
>
>
> Hello again folks,
>
> In general, the document is quite = verbose.  A spell checker should
> be employed, and ways should be found to = eliminate redundancy.
Apologies for the spelling drop-offs - they will be = fixed.
Jeanette Hofmann has already commented on the issue = of redundancy (I don't think there is
much anyway).
As regards verbosity - it is sometimes difficult to = avoid touching peoples hot buttons without a few extra words.
>
> Here are some more detailed comments on the = draft.
>
> In section 2.1, I do not like the following = sentence:
>
> >    o  The misty vision = has inhibited the development of
> roadmaps that
> >       would = inform the IETF's stakeholders of our longer term
> >       = intentions,
>
> In the first place, I don't think the IETF has = many longer
> term intentions,
> except perhaps "saving the = Internet".  Such intentions don't
> necessarily
> need "roadmaps".  I think the = IETF is much more reactive than would
> be understood from the above sentence, and I = think it's a
> good thing for
> the IETF to be that way.  This is not to = say that the IETF
> can only solve
> problems after they occur.  I do think = think that the IETF
> should try to
> prevent problems, as far in advance as we = reasonably can.  But the
> IETF actions are happening in response to = identified problems, not
> (in general!) according to some over-arching = roadmap, architecture,
> plan, or vision.

This is a matter of opinion - some people certainly = perceive that we need more in the way of forward planning against a = roadmap and others would like to know further in advance where we think = we are going.  Maybe the IETF is too reactive!

>
> In section 2.2, on page six, there is the = following text:
>
> >    o  Failure to = identify and articulate engineering
> trade-offs that may
> >       be = needed to meet the deadlines that the WG has set without
> >       = inappropriately reducing the 'fitness for purpose' for the
> >       = intended customers.
> >
> >    o  Continued = refinement of the solution beyond the point
> at which it
> >       is = adequate to meet the requirements placed on it by
> the intended
> >       = purpose.
>
>
> I am concerned that listing these as bullets = needing attention is
> counterproductive.  For one thing, most = engineers are aware that
> these problems need to be avoided.  On the = general assumption that
> most WG staff (i.e., the ones that do the work = and that care) are
> engineers, there isn't much need to restate the = obvious, and most
> people will not derive much useful content from = these bullets -- i.e.,
> it's the negative equivalent of = "motherhood and apple pie".  I don't
> remember when anyone consciously acted in the = above bad ways.
>
I fear I have taken part in a number of working = groups that have lost sight of these engineering principles even if the = individual engineers are indeed well aware of them (the tail end of = DiffServ comes to mind - the discussions of the minutiae of how = Expedited Forwarding might be refined in particular).  This is = certainly related to the demise of the true purpose of Proposed = Standards and the rise of the thought experiment.

> In the next list:
>
> >    o  Poorly defined = success criteria for WGs and
> individual documents.
>
> I'm not sure this is really worth calling out = as a specific problem.
> For one thing, the success criteria are the = charter items. 
> For another
> thing, if there is a poorly defined criterion, = it stems more from the
> problem with the standards track than anything = else, and that's
> not going to get fixed by rewhacking WG = processes.
Most charters specify that they will produce a set = of documents for standardizing something (OK some of them do rather = better recently) but we really ought to be clearer about when we will = know we have the right answer.

>
> To the point:
>
> >    o  Lack of review, = especially early review, by reviewers
> who are not
> >       = directly interested mebers of the WG, and by subject matter
> >       = experts for topics related to, but not necessarily
> the immediate
> >       focus = of the document.
>
> I would like to suggest that we not view this = as a "problem",
> because there
> might not be a good solution.  Good = external reviewers don't
> grow on trees,
> and if they did anyway we would find the trees = are already completely
> plucked for other reasons.  I don't see = how we can expect to
> get so many
> good external reviewers that they could spend = time reading
> early drafts that
> aren't even implemented by WG members = yet.  I'd much rather see such a
> valuable resource be put to use after some = initial validation
> within the
> working
> group itself.

I am sorry to say that I think this is defeatist and = an attempt to brush under the carpet something which can cause us lots = of problems downstream.  I thought that our experiences in = software engineering had demonstrated that early review paid dividends = many times over!  Early review needn't necessarily be terribly = time consuming (after all the details are probably not yet fleshed out) = but an experienced SME might well catch the flaws quickly and before = they become too well embedded into the fundamental = structure.

>
> Another way to attack this deficiency, as I = have tried to
> suggest before, is
> that as time goes on, we amass a body of = documentation by
> subject matter
> experts that explain how to avoid certain = cross-working-group
> problems.
> It's a lot more scalable to ask engineers to = try to find
> relevant documents
> that have been written about a relevant area of = cross-expertise
> interactions,
> than it is for them to find an expert to = explain it for the millionth
> time on the
> expert's personal timeline.
>
> So, I'd replace that bullet by something = like:
>
> o  Lack of documentation about likely = problem areas that might arise
>     due to interactions = with other popular IETF protocols.

I'd rather add this bullet - I think you raise a good = point but ultimately there is no substitute for a practised eye and a = broad knowledge of what is going on now (as opposed to distilled wisdom = which will inevitably be abstracted and somewhat out of = date).

>
> The point, on page 12
>
> >    o  Absence of = documented debriefing sessions to assess
> and record the
> >       = successes and failures of WGs (and other processes)
> so that the
> >       = positive and negative lessons learned can be used to
> facilitate
> >       future = work and improve the processes.
>
> is essentially the same as the previous point, = and both could
> be expressed
> more succinctly as:
>
> o  Lack of a WG "post mortem" = procedure to drive the improvement of
>     the standards = development process.

Agreed but it should also extend beyond WG = processes.

>
> The following point:
>
> >    o  Lack of criteria = for determining when a piece of work is
> >       = overrunning and/or is unlikely to be concluded
> successfully either
> >       at all = or within an acceptable time frame: Lack of process for
> >       either = extending the time frame, adjusting the scope or
> >       = terminating the work item or the whole Working Group.
>
> is debatable, because the process should be = "amending the charter",
> and the criteria should be "according to = the charter".

It may be debatable but it is a perceived problem - = this one of those where some people see it as a problem but you = don't.

>
> On a positive note, I wholeheartedly agree with = the following point,
> and I suggest that current efforts towards = improvement be encouraged
> and extended:
>
> >    o  Automated tools = to support the engineering process
> are minimal.

Phew!

>
> Regarding the next bullet item, I would suggest = that no
> change is needed
> to current IETF processes:
>
> >    o  Despite its = commitment to 'running code', the IETF is not
> >       = proactive in providing ways for developers to verify their
> >       = implementations of IETF standards.
>
> So far as I can tell, the developers are quite = adept at making this
> happen regardless of whether the IETF helps or = not.  Or, as they
> say, "If it's not broke, don't fix = it".
>
> Also on page 12, the following bullets are = redundant and
> could beneficially
> be deleted to avoid numbing repetition:
>
> >    o  Project entry, = goal setting, dependency identification,
> >       = coordination and tracking processes are all either missing or
> >       = implemented less effectively than the norm for commercial
> >       = organizations in related activities. Dependencies and
> coordination
> >       should = cover both other WGs within the IETF and any
> outside SDO
> >       with = which the IETF is collaborating.
> >
> >    o  Charters regularl= y fail to set sufficiently granular
> milestones at
> >       which = progress of WGs, individuals and documents can
> be evaluated.
> >       Also = WGs often do not make more detailed work plans
> to refine the
> >       = charter plans.
> >
> >    o  The acceptable = deadlines for finishing a piece of
> work, and the
> >       = criteria used to determine them, are rarely, if ever,
> documented.
> >       Also = the estimates of the time required to complete
> the work often
> = >           &n= bsp;   .......
>
> Unless I am missing something, all of these = ideas have
> already appeared
> earlier in the section.

I agree that there is some overlap but I would argue = that it is justified because the evidence is posted regarding separate = issues (lack of process improvement techniques and poor application of = management techniques).  Also I think mind-numbing is over-egging = the pudding!  If you want mind-numbing go and re-read the problem = statement mailing list archives.

>
> On the next page, I disagree with the following = statement:
>
> >    One problem which the = IETF does not appear to suffer from is
> >    excessive bureaucracy, = in the sense that transfer of
> information is
> >    generally kept to the = minimum necessary to accomplish the task.
>
> For one thing, I might suggest that the current = "rfc-editor"
> processing
> is quite bureaucratic, regardless of its = value.  Also, the
> evaluation of
> criteria for advancement along the standards = track, the submission
> process for Internet Drafts, the BOF approval, = and other examples
> can be viewed as more or less = bureaucratic.  Maybe it's not as
> bureaucratic as other organizations.  = Maybe.
>
> Another problem is that one person's = "minimality" may well be another
> person's "insufficiency".  = Typically, bureaucracy creates
> procedure based
> on historical problem solving episodes.  I = can think about the IANA
> considerations in exactly this way -- a little = bit along the
> way towards
> how mortgage agreements are structured.  = Of course, one wants to
> avoid ALL systemic problems in permanent = transactions.
>
> So, I'd reduce the amount of = self-congratulation on this
> point.  The best
> you can say is that the IETF bureaucracy is = younger than some of the
> other bureaucracies we might be able to = name.

A matter of opinion - I haven't seen any other = criticism of this point.

>
> In section 2.3, the first paragraph should = cross-reference section 2.2
> since the topic is related to the lack of = external review. 
> Perhaps better,
> the bullet in section 2.2 should be moved here, = on the theory
> that this
> is a fact of life, not a problem we can try to = solve.

Not everybody agrees that this can't be solved. The = cross reference may be useful.

>
> I have another thought about section 2.3 that I = have moved into
> a separate note.

I have reviewed this and the responses - I think = Brian Carpenter's view that the matter is already covered is = correct.  It is however a major potential roadblock if it results = in reinvention of wheels and should certainly be addressed in = 'solutions'.

>
> Regarding the point on pg. 14:
>
> >    o  The IETF does = not have an effective means for defining
> >       = architectures and frameworks that will shape the work
> of multiple
> >       = WGs.
>
> ... that is something that should be done by = the IAB.  So I would say
> that the IETF does have the means, but it's = perhaps not yet effective.

Maybe it ought to but it is not clear that it = believes it has a mandate to do this.

>
> On page 16, in section 2.5, the following = sentence should be deleted:
>
> >    Whilst this might be put = down to contributors having less time
> >    available in their work = schedule during the downturn of
> the last two
> >    years, this is not the = whole story because there were
> signs of this
> >    effect back at the = height of the boom in 2000.
>

I disagree. I think that it is important that this is = not just dismissed as a side-effect of the industry downturn.

>
> In section 2.6.4, the last paragraph should be = deleted.  It
> has no place,
> and the most charitable interpretation would = put it squarely into a
> solutions
> document.  More likely, it looks like an = insult.

This paragraph has escaped the de-solutioning = sweep.  However I don't believe it should be deleted.  It = certainly appears that in some cases IESG delays have been used as a = smoke-screen to disguise or even foment slow progress (where some = interest group doesn't really want progress).  I'll rephrase it a = bit.

>
> In section 2.7, the claim is made that problems = result from the
> non-hierarchical nature of the working = group.  I don't believe it.
> I have never seen this as a problem.  In = fact, I would characterize
> it as a feature.
>
> If anything, there might be a problem with = assignment of tasks,
> and accountability for accomplishing those = tasks.  Typically,
> hierarchy helps with delegation, = accountability, and evaluation,
> but the lack of hierarchy does not mean the = lack of those
> three management aids.  In fact, I would = in solution space
> suggest that the new methods for issue tracking = could be tied
> in with a non-hierarchical method for = delegation, accountability,
> and evaluation for better results.

It is certainly a feature but many people find it = difficult or contrary to their normal working experience, and it = certainly can make it very difficult to handle deadlines.  I am = guilty as charged!

Regards,
Elwyn.

>
> I will send out yet another note with detailed = editorial remarks,
> with a lot less substance and importance = compared to these
> comments.
>
> Regards,
> Charlie P.
>
>
>

------_=_NextPart_001_01C394A4.5749E4D6-- From problem-statement-bounces@alvestrand.no Fri Oct 17 08:21:27 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA29518 for ; Fri, 17 Oct 2003 08:21:25 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 914B861C05; Fri, 17 Oct 2003 14:21:02 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from zctfs063.nortelnetworks.com (zctfs063.nortelnetworks.com [47.164.128.120]) by eikenes.alvestrand.no (Postfix) with ESMTP id 6AACC61BE1 for ; Fri, 17 Oct 2003 14:20:55 +0200 (CEST) Received: from znsgs01r.nortelnetworks.com (znsgs01r.nortelnetworks.com [47.137.129.92]) by zctfs063.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h9HCKob29145 for ; Fri, 17 Oct 2003 14:20:50 +0200 (MEST) Received: from zwcwc012.europe.nortel.com (zwcwc012.europe.nortel.com [47.160.46.124]) by znsgs01r.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h9HCKms07034 for ; Fri, 17 Oct 2003 13:20:49 +0100 (BST) Received: by zwcwc012.europe.nortel.com with Internet Mail Service (5.5.2653.19) id <4D03MHWD>; Fri, 17 Oct 2003 13:20:49 +0100 Message-ID: <4103264BC8D3D51180B7002048400C45043ABACE@zhard0jd.europe.nortel.com> From: "Elwyn Davies" To: "'Problem Statement Working Group'" Date: Fri, 17 Oct 2003 13:20:48 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C394A9.072D3D18" Subject: RE: Detailed editorial comments X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C394A9.072D3D18 Content-Type: text/plain Hi Charlie. Thanks for the comments. I will be producing a new version shortly taking some of these on board. > -----Original Message----- > From: Charlie Perkins [mailto:charliep@iprg.nokia.com] > Sent: 07 October 2003 06:35 > To: Davies, Elwyn [HAL02:0S00:EXCH] > Cc: Problem Statement Working Group > Subject: Detailed editorial comments > > > > Hello Elwyn, > > Here are some detailed editorial comments, mostly as > a matter of style and syntax. I found several instances of > language that made me stop, sit up, and ponder. This > could be viewed as a technique for getting someone's > attention, but more often it's just distracting to the person > who was really flowing along with the main thought. > In such cases, the ornamental value of the expression > is outweighed by the derailment of the train of thought. > I hope you don't mind if I point out a few instances of > this among my suggestions below. It's not that they are > incorrect, strictly speaking. I agree there are a couple of places where some extravagant language has persisted since earlier and more inflammatory drafts - 'all-pervasive' is a case in point. Some of the others are perhaps English usage rather than American and I will defend them since I am editor (what was that about North American cultural bias!). > > In my writing preference, the word "clearly", and usually > the word "clear", is a "clear" indication of something > wrong. First, it is usually meant to browbeat the reader > into submission -- as if, there is "obviously" no room for > disagreement. Similarly, "obvious" is also a danger sign. > Secondly, it begs the reader to disagree with you, in a > way to counteract your implicit act of verbal dominance. > I'd suggest purging practically every occurrence of "clear" > from the document. Detailed inspection of the text indicates that there are two cases of 'Clearly' used in this way. The one associated with 'superhuman' is used ironically (see below). I think the other instances are used differently and can stand. > > Change: > > > work which has lead to an extremely successful, > all-pervasive network > > to: > > > work which has led to an successful and pervasive network > > or, better: > "work which has facilitated the widespread deployment of > the Internet and especially the infrastructure of the Internet" > > After all, most of the people in the world have never > even made a telephone call. I'll go with your first alternative - the major point is to emphasise that the IETF is (or has been) a successful organisation. > > Change: > > > a, still extensive, list of perceived problems which were classified > > to: > > > a (still extensive) list of perceived problems which were classified > > or, better: > a list of perceived problems which were classified OK > > Change: > > > and in terms of work in progress. The effects of this growth have > > to: > > > and volume of work in progress. The effects of this growth have > OK > > Delete "Extant" in: > > > time. Extant evidence dating back to at least 1992 drew similar > > > In section 1.3, the colons should be replaced by periods. > > In current section 1.6, which I hope will be moved to an appendix, > there is an extra space before "term" in: > > > o The term customer has been replaced by stakeholder when > > In section 2.1, replace "sectional" by "narrow" in: > > > o Working Groups can potentially be hijacked by sectional interests I think sectional is the right adjective here. They might also be narrow . > > Also, replace "blinker" by "obstruct" in: > > > technology because this would be likely to blinker the IETF's view I think blinker is the right concept here. > > Replace "concensus" by "consensus". One of my spelling blind spots! > > In the paragraph before section 2.2: > - Replace "mandated" by "official" (if I understand the > meaning correctly!) Mandated is intended deliberately to be stronger than official in the sense that they come mandated to achieve certain things by their parent organisations, rather than being left to make up their own minds. > - Delete "the 'conventional'" Disagree. > - Replace "which" by "that" Matter of style. > > Change: > > > Externally, the IETF is often placed in the same bracket as these > > to: > > > Externally, the IETF is often classified with these > > In section 2.2, there's too much capitalization in the first > paragraph. Changing all the "extras" to lower case would > not be a bad idea, but changing at least the first two extras > is really recommended. We can de-capitalise the two Engineering Practices but I don't see any 'extras' - did you mean this literally? > > Insert "as used here" after: > > > ........... . Effective Engineering Practices OK. > > Change: > > > o Failure to identify at an early stage (before the design is > > frozen), and/or then to ensure that there is a > uniform view in the > > WG of the issues that need to be resolved to bring > the work to a > > satisfactory conclusion. > > to: > > > o Failure to identify the issues that need to be > resolved at an early > > stage (before the design is frozen), and/or then to > ensure that > > there > > is a uniform view in the WG of those issues > Agreed - this was clumsy. > > In the following sentence, replace "to deliver" by "for" > > > The IETF standards engineering process is not set up to deliver > > In the following, replace "mebers" by "members": > > > directly interested mebers of the WG, and by subject matter > > Replace "emphasises" by "emphasizes", unless this is your personal > preference, in: > > > structure of the IETF emphasises communication between the IESG > > Replace "posess" by "possess" in: > > > o The IETF does not posess effective formal mechanisms for inter-WG > > > Change: > > > adequate for the older, smaller organization, but are > apparently not > > to: > > > adequate for an older, smaller IETF, but are apparently not > > Replace "of" by "likely to be found in" in: > > > the capabilities of a single person. > > Change: > > > o Interacting with WGs > > > > o Understanding network and computer technology > generally, and their > > own area in detail > > > > o Cross-pollinating between groups > > > > o Coordinating with other areas > > to: > > > o Interaction with WGs > > > > o Understanding network and computer technology > generally, and their > > own area in detail > > > > o Cross-pollination between groups > > > > o Coordination with other areas Disagree - style is consistent between bullet points and reads fine to me. > > Change: > > > clear that only superhumans can be expected to do this job well. To > > to: > > > extremely difficult to do this job well. To I would say that given what has gone before the hyperbole and irony is justified here. This is not a standards document... > > > In the following, change "second" to "send": > > > people who work for large companies who can afford to second IESG > Disagree. > > Change: > > > this flexibility, and is burying itself in procedures > that rapidly > > move from organizational conveniences to rigid and immutable > > shibboleths. > > to: > > > this flexibility, and is entangling itself in procedures > that evolve > > from organizational conveniences into encumbrances. > Spoilsport. I am sure you are right but the existing wording is more exciting. > > Change "weighting" to "emphasis" in: > > > have chosen to give heavy weighting to continuity of IESG and IAB > > > In section 2.6.6, replace "whilst" by "while". I'll stick with Whilst here. On the previous line, > delete "Clearly". In the same sentence as whilst, again > delete "clearly". Agree for the first one - disagree for second one. > In the next sentence, replace "Also" by "Furthermore". OK. > > In section 2.6.7, first sentence, delete "intensely". No. > > On page 21, delete "a particular kind of" Disagree. > > On page 23, replace "steeped" by "immersed", or perhaps "long > familiar" Disagree. > > Lastly, on page 24, replace "Author's" by "Editor's". OK > > Regards, > Charlie P. > > > > > > > > > > > > > > > > > > ------_=_NextPart_001_01C394A9.072D3D18 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: Detailed editorial comments

Hi Charlie.

Thanks for the comments.  I will be producing a = new version shortly taking some of these on board.

> -----Original Message-----
> From: Charlie Perkins [mailto:charliep@iprg.nokia.com]
> Sent: 07 October 2003 06:35
> To: Davies, Elwyn [HAL02:0S00:EXCH]
> Cc: Problem Statement Working Group
> Subject: Detailed editorial comments
>
>
>
> Hello Elwyn,
>
> Here are some detailed editorial comments, = mostly as
> a matter of style and syntax.  I found = several instances of
> language that made me stop, sit up, and = ponder.  This
> could be viewed as a technique for getting = someone's
> attention, but more often it's just distracting = to the person
> who was really flowing along with the main = thought.
> In such cases, the ornamental value of the = expression
> is outweighed by the derailment of the train of = thought.
> I hope you don't mind if I point out a few = instances of
> this among my suggestions below.  It's not = that they are
> incorrect, strictly speaking.

I agree there are a couple of places where some = extravagant language has persisted since earlier and more inflammatory = drafts - 'all-pervasive' is a case in point.  Some of the others = are perhaps English usage rather than American and I will defend them = since I am editor (what was that about North American cultural = bias!).

>
> In my writing preference, the word = "clearly", and usually
> the word "clear", is a = "clear" indication of something
> wrong.  First, it is usually meant to = browbeat the reader
> into submission -- as if, there is = "obviously" no room for
> disagreement.  Similarly, = "obvious" is also a danger sign.
> Secondly, it begs the reader to disagree with = you, in a
> way to counteract your implicit act of verbal = dominance.
> I'd suggest purging practically every = occurrence of "clear"
> from the document.

Detailed inspection of the text indicates that there = are two cases of 'Clearly' used in this way. The one associated with = 'superhuman' is used ironically (see below).  I think the other = instances are used differently and can stand.

>
> Change:
>
> > work which has lead to an extremely = successful,
> all-pervasive network
>
> to:
>
> > work which has led to an successful and = pervasive network
>
> or, better:
>     "work which has = facilitated the widespread deployment of
>       the = Internet and especially the infrastructure of the Internet"
>
> After all, most of the people in the world have = never
> even made a telephone call.

I'll go with your first alternative - the major point = is to emphasise that the IETF is (or has been) a successful = organisation.

>
> Change:
>
> > a, still extensive, list of perceived = problems which were classified
>
> to:
>
> > a (still extensive) list of perceived = problems which were classified
>
> or, better:
>     a list of perceived = problems which were classified

OK
>
> Change:
>
> >    and in terms of work in = progress. The effects of this growth have
>
> to:
>
> >    and volume of work in = progress. The effects of this growth have
>
OK

>
> Delete "Extant" in:
>
> >    time. Extant evidence = dating back to at least 1992 drew similar
>
>
> In section 1.3, the colons should be replaced = by periods.
>
> In current section 1.6, which I hope will be = moved to an appendix,
> there is an extra space before "term" = in:
>
> >    o  The  term = customer has been replaced by stakeholder when
>
> In section 2.1, replace "sectional" = by "narrow" in:
>
> > o  Working Groups can potentially be = hijacked by sectional interests

I think sectional is the right adjective here.  = They might also be narrow .
>
> Also, replace "blinker" by = "obstruct" in:
>
> > technology because this would be likely to = blinker the IETF's view

I think blinker is the right concept here.

>
> Replace "concensus" by = "consensus".

One of my spelling blind spots!

>
> In the paragraph before section 2.2:
> - Replace "mandated" by = "official" (if I understand the
> meaning correctly!)
Mandated is intended deliberately to be stronger = than official in the sense that they come mandated to achieve certain = things by their parent organisations, rather than being left to make up = their own minds.

> - Delete "the 'conventional'"
Disagree.

> - Replace "which" by = "that"
Matter of style.



>
> Change:
>
> > Externally, the IETF is often placed in = the same bracket as these
>
> to:
>
> > Externally, the IETF is often classified = with these
>
> In section 2.2, there's too much capitalization = in the first
> paragraph.  Changing all the = "extras" to lower case would
> not be a bad idea, but changing at least the = first two extras
> is really recommended.

We can de-capitalise the two Engineering Practices = but I don't see any 'extras' - did you mean this literally?

>
> Insert "as used here" after:
>
> = >           = ...........          =    .  Effective Engineering Practices

OK.

>
> Change:
>
> >    o  Failure to = identify at an early stage (before the design is
> >       = frozen), and/or then to ensure that there is a
> uniform view in the
> >       WG of = the issues that need to be resolved to bring
> the work to a
> >       = satisfactory conclusion.
>
> to:
>
> >    o  Failure to = identify the issues that need to be
> resolved at an early
> >       stage = (before the design is frozen), and/or then to
> ensure that
> > there
> >       is a = uniform view in the WG of those issues
>
Agreed - this was clumsy.

>
> In the following sentence, replace "to = deliver" by "for"
>
> > The IETF standards engineering process is = not set up to deliver
>
> In the following, replace "mebers" by = "members":
>
> > directly interested mebers of the WG, and = by subject matter
>
> Replace "emphasises" by = "emphasizes", unless this is your personal
> preference, in:
>
> > structure of the IETF emphasises = communication between the IESG
>
> Replace "posess" by = "possess" in:
>
> > o  The IETF does not posess effective = formal mechanisms for inter-WG
>
>
> Change:
>
> >    adequate for the older, = smaller organization, but are
> apparently not
>
> to:
>
> >    adequate for an older, = smaller IETF, but are apparently not
>
> Replace "of" by "likely to be = found in" in:
>
> > the capabilities of a single = person.
>
> Change:
>
> >    o  Interacting with = WGs
> >
> >    o  Understanding = network and computer technology
> generally, and their
> >       own = area in detail
> >
> >    o  = Cross-pollinating between groups
> >
> >    o  Coordinating = with other areas
>
> to:
>
> >    o  Interaction with = WGs
> >
> >    o  Understanding = network and computer technology
> generally, and their
> >       own = area in detail
> >
> >    o  = Cross-pollination between groups
> >
> >    o  Coordination = with other areas

Disagree - style is consistent between bullet points = and reads fine to me.

>
> Change:
>
> > clear that only superhumans can be = expected to do this job well.  To
>
> to:
>
> > extremely difficult to do this job = well.  To

I would say that given what has gone before the = hyperbole and irony is justified here.  This is not a standards = document...

>
>
> In the following, change "second" to = "send":
>
> > people who work for large companies who = can afford to second IESG
>
Disagree.

>
> Change:
>
> >    this flexibility, and is = burying itself in procedures
> that rapidly
> >    move from organizational = conveniences to rigid and immutable
> >    shibboleths.
>
> to:
>
> >    this flexibility, and is = entangling itself in procedures
> that evolve
> >    from organizational = conveniences into encumbrances.
>
Spoilsport. I am sure you are right but the existing = wording is more exciting.

>
> Change "weighting" to = "emphasis" in:
>
> >    have chosen to give = heavy weighting to continuity of IESG and IAB
>
>
> In section 2.6.6, replace "whilst" by = "while". 
I'll stick with Whilst here.

On the previous line,
> delete "Clearly". In the same = sentence as whilst, again
> delete "clearly".
Agree for the first one - disagree for second = one.

> In the next sentence, replace "Also" = by "Furthermore".

OK.
>
> In section 2.6.7, first sentence, delete = "intensely".

No.

>
> On page 21, delete "a particular kind = of"
Disagree.

>
> On page 23, replace "steeped" by = "immersed", or perhaps "long
> familiar"
Disagree.

>
> Lastly, on page 24, replace = "Author's" by "Editor's".
OK

>
> Regards,
> Charlie P.
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>

------_=_NextPart_001_01C394A9.072D3D18-- From problem-statement-bounces@alvestrand.no Fri Oct 17 11:20:27 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06023 for ; Fri, 17 Oct 2003 11:20:26 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 81E8261C1C; Fri, 17 Oct 2003 17:20:04 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by eikenes.alvestrand.no (Postfix) with ESMTP id 8527961C16; Fri, 17 Oct 2003 17:20:00 +0200 (CEST) Received: from cisco.com (64.102.124.13) by sj-iport-5.cisco.com with ESMTP; 17 Oct 2003 08:20:07 -0700 Received: from cisco.com (erosen-u10.cisco.com [161.44.70.36]) by rtp-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h9HFJuFQ008370; Fri, 17 Oct 2003 11:19:56 -0400 (EDT) Message-Id: <200310171519.h9HFJuFQ008370@rtp-core-2.cisco.com> To: "Christian Huitema" In-reply-to: Your message of Thu, 16 Oct 2003 15:15:56 -0700. User-Agent: EMH/1.14.1 SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (=?ISO-8859-4?Q?Unebigory=F2mae?=) APEL/10.3 Emacs/21.3 (sparc-sun-solaris2.8) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII Date: Fri, 17 Oct 2003 11:19:55 -0400 From: Eric Rosen Cc: Harald Tveit Alvestrand , ietf@ietf.org, problem-statement@alvestrand.no Subject: Re: IETF mission boundaries (Re: IESG proposed statement on the IETF mission ) X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list Reply-To: erosen@cisco.com List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no > The gist of this comment is that someone developing a network > application protocol ought to somehow get a blessing from the IETF. > Reality check. Who got the IETF approval to deploy ICQ, Kazaa, or for > that matter HTTP? The fact that someone did something without the IETF's approval does not imply that what they did is outside the scope of the IETF, or that it is beyond the IETF's mission. From problem-statement-bounces@alvestrand.no Sat Oct 18 00:27:16 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA06377 for ; Sat, 18 Oct 2003 00:27:16 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 79C2861D30; Sat, 18 Oct 2003 06:26:54 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from halvestr-w2k1 (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id A6C7B61C20; Sat, 18 Oct 2003 06:26:51 +0200 (CEST) Date: Fri, 17 Oct 2003 22:09:44 +0100 From: Harald Tveit Alvestrand To: Christian Huitema Message-ID: <36324071.1066428584@localhost> In-Reply-To: References: X-Mailer: Mulberry/3.1.0b8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Cc: problem-statement@alvestrand.no, ietf@ietf.org Subject: RE: IETF mission boundaries (Re: IESG proposed statement on the IETF mission ) X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit Christian, we might be looking through opposite ends of this tunnel..... --On 16. oktober 2003 15:15 -0700 Christian Huitema wrote: >> I think this point is one of the critical causes of conflict when > talking >> about the IETF mission - and unless we lance the boil, actually talk > about >> it, and attempt to *resolve* the issue, we will go on revisiting the > issue >> forever, with nothing but wasted energy to show for it. > > Well, to paraphrase a well known leader, "the IETF, how many divisions?" > The gist of this comment is that someone developing a network > application protocol ought to somehow get a blessing from the IETF. > Reality check. Who got the IETF approval to deploy ICQ, Kazaa, or for > that matter HTTP? For application protocols, I view it in the opposite direction - if someone comes to the IETF and *asks* for the IETF's advice, blessing or ownership, what are the conditions under which we say "yes"? Or "no"? For those that never ask, and never become important, I say "not my problem". The number of application protocols with the oomph to "break" the Internet is quite small - offhand, I'd say that HTTP/1.0 probably was the closest try. > If the Internet is so fragile that a poorly developed application can > break it, then the IETF response should not be to try control each > application. It has to be, design checks that can be implemented by > cooperating hosts and routers so that their neck of the Internet is in > good health! Now there's an idea..... :-) The flipside is of course with those things that are *already* under IETF control, or critical for our infrastructure, for some reason. The abstracted version of the fights over MIME types, URI schemes, SIP extension etcetera seems to be "don't extend until you've talked to us about what you're doing, and if we don't like it, don't try to pretend that we did" (the P-headers, vnd. MIME types and the proposed faceted URI schemes); I'm not certain what the abstracted version of the fights over COPS, CR-LDP, RSVP-TE and so on are..... The IETF has got fewer divisions than the Pope, of course. Anyone is free to ignore us. And we need to remember that, sometimes. From problem-statement-bounces@alvestrand.no Sat Oct 18 00:27:23 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA06403 for ; Sat, 18 Oct 2003 00:27:23 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id DDD63621B8; Sat, 18 Oct 2003 06:27:01 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from halvestr-w2k1 (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 46B6E61F4A; Sat, 18 Oct 2003 06:26:56 +0200 (CEST) Date: Fri, 17 Oct 2003 22:18:41 +0100 From: Harald Tveit Alvestrand To: Keith Moore Message-ID: <36860662.1066429121@localhost> In-Reply-To: <20031015124837.79dbcd11.moore@cs.utk.edu> References: <157547561.1066175290@localhost> <20031015124837.79dbcd11.moore@cs.utk.edu> X-Mailer: Mulberry/3.1.0b8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Cc: problem-statement@alvestrand.no, ietf@ietf.org Subject: Re: IESG proposed statement on the IETF mission X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit since both you and Scott pointed out this one.... --On 15. oktober 2003 12:48 -0400 Keith Moore wrote: >> "The purpose of the IETF is to create high quality, relevant, >> and timely standards for the Internet." > > I actually believe IETF has a somewhat wider purpose than that. What > I usually say is "we're trying to help the Internet work better". my personal belief is that the purpose of the *Internet technical community* is to make the Internet work better. But we have to admit to division of labor, and the part that we call the IETF needs to concentrate on standards, and the "supporting functions" of fora for experimentation and gathering of operational experience. Others do the work of pulling fiber, designing routers, arresting spammers and detecting virii. We, gathered as the IETF, should not (IMHO) attempt to take over those functions. Despite the fact that it's what many of us do when we're not doing IETF stuff! Harald From problem-statement-bounces@alvestrand.no Sat Oct 18 00:27:28 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA06425 for ; Sat, 18 Oct 2003 00:27:27 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 6716E61C21; Sat, 18 Oct 2003 06:27:06 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from halvestr-w2k1 (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 9CBDD621B6; Sat, 18 Oct 2003 06:26:59 +0200 (CEST) Date: Fri, 17 Oct 2003 22:27:14 +0100 From: Harald Tveit Alvestrand To: erosen@cisco.com Message-ID: <37373730.1066429634@localhost> In-Reply-To: <200310161715.h9GHF2FQ026610@rtp-core-2.cisco.com> References: <200310161715.h9GHF2FQ026610@rtp-core-2.cisco.com> X-Mailer: Mulberry/3.1.0b8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Cc: problem-statement@alvestrand.no, ietf@ietf.org Subject: Re: IETF mission boundaries (Re: IESG proposed statement on the IETF mission ) X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit --On 16. oktober 2003 13:15 -0400 Eric Rosen wrote: >> - "For the Internet" - only the stuff that is directly involved in >> making the Internet work is included in the IETF's scope. > > In other words, routing, DNS, and Internet operations/management. > Adopting this as the IETF's mission would be a very radical change > indeed! I erred in describing that category. I should have used something else - it was not what the IESG thought it was saying in its proposed mission statement, so me recycling the term "for the Internet" in the bulleted list I made added confusion rather than clarifying. Sorry! (I still think it's a valid point on the scale. It leaves us with a much smaller IETF. But some people tend to think that's a positive side.) Harald From problem-statement-bounces@alvestrand.no Sun Oct 19 22:06:55 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA26518 for ; Sun, 19 Oct 2003 22:06:55 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id D1D0361C04; Mon, 20 Oct 2003 04:06:28 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from klutz.cs.utk.edu (klutz.cs.utk.edu [160.36.56.50]) by eikenes.alvestrand.no (Postfix) with ESMTP id ADAE361BFD; Mon, 20 Oct 2003 04:06:25 +0200 (CEST) Received: from localhost (klutz [127.0.0.1]) by smtp.cs.utk.edu (Postfix) with ESMTP id 1B70A14138; Sun, 19 Oct 2003 22:06:25 -0400 (EDT) Received: from klutz.cs.utk.edu ([127.0.0.1]) by localhost (klutz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 17606-03; Sun, 19 Oct 2003 22:06:24 -0400 (EDT) Received: from envy.indecency.org (user-119b1dm.biz.mindspring.com [66.149.133.182]) by smtp.cs.utk.edu (Postfix) with ESMTP id DC443140AB; Sun, 19 Oct 2003 22:06:23 -0400 (EDT) Date: Sun, 19 Oct 2003 22:02:29 -0400 From: Keith Moore To: Harald Tveit Alvestrand Message-Id: <20031019220229.2cdc63dc.moore@cs.utk.edu> In-Reply-To: <36324071.1066428584@localhost> References: <36324071.1066428584@localhost> X-Mailer: Sylpheed version 0.9.6 (GTK+ 1.2.10; i386--netbsdelf) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new and ClamAV at cs.utk.edu Cc: huitema@windows.microsoft.com, problem-statement@alvestrand.no, moore@cs.utk.edu, ietf@ietf.org Subject: Re: IETF mission boundaries (Re: IESG proposed statement on the IETF mission ) X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit > The number of application protocols with the oomph to "break" the > Internet is quite small however, it's not safe to assume that it's zero. any new killer app that were poorly designed could do it. also, you might be underestimating the damage done by HTTP (1.0 or later). From problem-statement-bounces@alvestrand.no Sun Oct 19 22:40:36 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA27204 for ; Sun, 19 Oct 2003 22:40:35 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 2D58E61B97; Mon, 20 Oct 2003 04:40:14 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from rwcrmhc12.comcast.net (rwcrmhc12.comcast.net [216.148.227.85]) by eikenes.alvestrand.no (Postfix) with ESMTP id F362F61B93 for ; Mon, 20 Oct 2003 04:40:08 +0200 (CEST) Received: from dfnjgl21 (12-237-229-250.client.attbi.com[12.237.229.250]) by comcast.net (rwcrmhc12) with SMTP id <200310200240060140072s8ke> (Authid: sdawkins@comcast.net); Mon, 20 Oct 2003 02:40:06 +0000 Message-ID: <046a01c396b3$7c47d2a0$0400a8c0@DFNJGL21> From: "Spencer Dawkins" To: , References: <36324071.1066428584@localhost> <20031019220229.2cdc63dc.moore@cs.utk.edu> Date: Sun, 19 Oct 2003 21:40:11 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Subject: Re: IETF mission boundaries (Re: IESG proposed statement on the IETF mission ) X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list Reply-To: Spencer Dawkins List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit > The number of application protocols with the oomph to "break" the > Internet is quite small OK, I've gotta ask - how many times do we break the Internet before we reverse this reasoning? (How many times is "too many"?) (signed) curious From problem-statement-bounces@alvestrand.no Mon Oct 20 11:42:42 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01205 for ; Mon, 20 Oct 2003 11:42:41 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 6B72E61BF4; Mon, 20 Oct 2003 17:42:18 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from mtiwmhc12.worldnet.att.net (mtiwmhc12.worldnet.att.net [204.127.131.116]) by eikenes.alvestrand.no (Postfix) with ESMTP id 0E4F561B89 for ; Mon, 20 Oct 2003 17:42:17 +0200 (CEST) Received: from bolaba (117.sanjose-08-09rs16rt.ca.dial-access.att.net[12.81.3.117]) by worldnet.att.net (mtiwmhc12) with SMTP id <2003102015421311200ik72ve>; Mon, 20 Oct 2003 15:42:14 +0000 Message-ID: <001901c39720$21548240$010aff0a@bolaba> From: "todd glassey" To: "Spencer Dawkins" , , References: <36324071.1066428584@localhost><20031019220229.2cdc63dc.moore@cs.utk.edu> <046a01c396b3$7c47d2a0$0400a8c0@DFNJGL21> Date: Mon, 20 Oct 2003 08:37:51 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Subject: Re: IETF mission boundaries (Re: IESG proposed statement on theIETF mission ) X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit Spencer, this is not intended at you personally but rather at the whole IETF and this WG in particular. So let me ask then - What makes you think *you* or anyone else here has any say as to what is or is not routed on the Internet. ***YOU DON'T*** also as to "what breaks the Internet" - You don't there too. None of us do. And in fact NO ONE PERSON has any possible say as to the US internet except the person running DHS and if you doubt this - try arguing with them. BTW - The biggest thing the IETF can do is to get off the concept of "that its wares and efforts" only pertain to the Internet. Because they don't - obviously so too, and this is a key issue. If the IETF's actions only pertained to the Internet and there was such a quantifiable thing as the Internet then this might have some meaning - but its a fantasy that the IESG likes to propagate to justify its existence. Sorry if the truth hurts - but it is what it is. Todd ----- Original Message ----- From: "Spencer Dawkins" To: ; Sent: Sunday, October 19, 2003 7:40 PM Subject: Re: IETF mission boundaries (Re: IESG proposed statement on theIETF mission ) > > The number of application protocols with the oomph to "break" the > > Internet is quite small > > OK, I've gotta ask - how many times do we break the Internet before we > reverse this reasoning? (How many times is "too many"?) > > (signed) curious > > > From problem-statement-bounces@alvestrand.no Mon Oct 20 18:30:50 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11258 for ; Mon, 20 Oct 2003 18:30:49 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 3A5B861B9D; Tue, 21 Oct 2003 00:30:27 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from halvestr-w2k1 (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 1621A61AA5; Tue, 21 Oct 2003 00:30:25 +0200 (CEST) Date: Mon, 20 Oct 2003 10:58:45 -0700 From: Harald Tveit Alvestrand To: Spencer Dawkins , problem-statement@alvestrand.no Message-ID: <17066029.1066647525@localhost> In-Reply-To: <023001c393e4$914412d0$0400a8c0@DFNJGL21> References: <9A502998-FFD5-11D7-B3E6-000A95E35274@cisco.com> <023001c393e4$914412d0$0400a8c0@DFNJGL21> X-Mailer: Mulberry/3.1.0b8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: Re: Problems vs Social Dynamics (Re: IESG proposed statement on theIETF mission) X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit --On 16. oktober 2003 07:53 -0500 Spencer Dawkins wrote: > ... and, if we don't already have a problem statement, that's a > problem, too ... > > Seriously, Brian wasn't very excited about an IESG-only/non-IESG+IAB > mission statement, and I take his point. I have to say that I'm still > wondering what more than two or three people on IESG think of the > current problem statement draft, too. > > The contributions from IESG members have been very helpful. In the > absence of a Process specification with WG oomph behind it, we seem to > be (per the last Plenary) looking expectantly at the IESG as a group > to respond to the problem statement draft. At least, that was my > take - did I get it wrong? My take too. And we're working on it - the task was harder than I'd anticipated. > > Any plans to respond at plenary time? Yes. And having stuff visible before that. Harald From problem-statement-bounces@alvestrand.no Mon Oct 20 18:31:09 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11305 for ; Mon, 20 Oct 2003 18:31:08 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 9056061C28; Tue, 21 Oct 2003 00:30:47 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from halvestr-w2k1 (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id D1B8061B8B; Tue, 21 Oct 2003 00:30:41 +0200 (CEST) Date: Mon, 20 Oct 2003 11:44:16 -0700 From: Harald Tveit Alvestrand To: Brian E Carpenter , problem-statement@alvestrand.no Message-ID: <19797377.1066650256@localhost> In-Reply-To: <3F8E8E4D.50A002D6@zurich.ibm.com> References: <157547561.1066175290@localhost> <20031015124837.79dbcd11.moore@cs.utk.edu> <3F8E8E4D.50A002D6@zurich.ibm.com> X-Mailer: Mulberry/3.1.0b8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: Re: IESG proposed statement on the IETF mission X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit --On 16. oktober 2003 14:25 +0200 Brian E Carpenter wrote: > (Only to problem-statement. I assume the interested parties are mainly > here.) > > Firstly a general point. I am rather amazed that this draft comes > from the IESG alone, and not from the IAB+IESG. In fact, I'd like > an explanation. Since the IAB and the IESG are the two peer committees > that the IETF puts in place to oversee the architecture and oversee > the process, I simply don't buy the idea of a draft mission statement > that comes from only one of them. Put this down as bad management (ie my fault). The IESG was anxious to get this draft in front of the community, so we shipped it publicly just about the moment it had a form that the IESG could stand behind. Nowhere was there an intention of not getting IAB comment and buy-in. > Secondly, I agree with Melinda: take out the "problem" language. This > document should contain exclusively positive statements. Point. > Thirdly: > > Keith Moore wrote: > > (and other people wrote similar things) > > ... >> >> > It is important that this is "For the Internet," and does not include >> > everything that happens to use IP. IP is being used in a myriad of >> > real-world applications, such as controlling street lights, but the >> > IETF does not standardize those applications. >> >> I disagree with the sentiment as I understand it. I don't think it's >> realistic anymore to take the view that what people run entirely on >> private networks is their own business and outside of IETF's purview. >> NATs, private addresses, and DHCP with short lease times have all had >> devistating effects on the Internet's ability to support applications. >> Insecure applications can facilitate the breeding of viruses that affect >> the entire network even if their intended interactions are only between >> a local client and server. > > Furthermore, we have *explicitly* in the past given warnings about the > risk to users' interests of walled garden approaches. And RFC 3002 made > a specific recommendation as a result (please read the whole RFC for > context): > > 4.2.1 > > It was strongly recommended that independent of the ubiquity of the > "walled garden" deployment scenario that protocols and architectural > decisions should not target this model. To continue the success of > Internet protocols at operating across a highly diverse and > heterogeneous environment the IETF must continue to foster the > adoption of an "open model". IETF protocol design must address > seamless, secure, and scalable access. > > I would like to see the mission statement endorsing this. Of course the > IETF will not standardize all *applications* but if we don't standardize > the IP environment, including at least transport and transport security, > and whatever is needed in the way of a session level, regardless of > whether it is part of the big-I Internet, we will be doing our ultimate > customers (ordinary users) an important disservice. That's a discussion we need to have. I think of the walled garden as being "off the Internet", and "open model" applications as being "on the Internet", and thus within reach of the proper focus of the IETF. If what we do works inside walled gardens too - nice, but not something I think we should value excessively. > What we also need in the mission statement is enough boundary-setting that > we can relatively easily decide what fits into the "Applications" Area > and whether the Sub-IP Area belonged here in the first place. (I put > "Applications" in quotes because there isn't much in the Apps area that > outsiders think of as applications.) Yes. Suggested text? From problem-statement-bounces@alvestrand.no Mon Oct 20 18:31:12 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11328 for ; Mon, 20 Oct 2003 18:31:11 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id CFC9E61C4C; Tue, 21 Oct 2003 00:30:49 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from halvestr-w2k1 (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 258CD61B8B; Tue, 21 Oct 2003 00:30:46 +0200 (CEST) Date: Mon, 20 Oct 2003 11:46:15 -0700 From: Harald Tveit Alvestrand To: Michael Richardson , graham.travers@bt.com Message-ID: <19916228.1066650375@localhost> In-Reply-To: <29900.1066233058@marajade.sandelman.ottawa.on.ca> References: <29900.1066233058@marajade.sandelman.ottawa.on.ca> X-Mailer: Mulberry/3.1.0b8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Cc: problem-statement@alvestrand.no Subject: Re: IESG proposed statement on the IETF mission X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit --On 15. oktober 2003 12:50 -0300 Michael Richardson wrote: > The critical difference is whether or not multiple *operators* will have > to communicate using the protocol. > So, in the case of controlling street lights, it is pretty unlikely that > the Chicago Municipal Street-Light Control Network (CMSLCN) will have to > control lights located in New York City. As long as all of the equipement > in the CMSLCN.net are owned by CMSLCN.net, then CMSLCN is in a position > to: 1) dictate to their vendor what the standard will be. > 2) provision the equipment (in advance) such that things interoperate > 3) buy from whatever vendor pleases it most. > > As soon as the lights in NYC (owned, provisioned and bought by NYC) > have to operate with the light controller in Chicago, then we need an > IETF standard. Why an IETF standard, and not a Traffic Light Controllers Forum standard? From problem-statement-bounces@alvestrand.no Mon Oct 20 18:45:20 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12159 for ; Mon, 20 Oct 2003 18:45:19 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 5C2E961B8B; Tue, 21 Oct 2003 00:44:58 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from hatl0ms21.CORP.COX.COM (lakehearnglobal.coxinc.com [206.157.224.254]) by eikenes.alvestrand.no (Postfix) with ESMTP id E5B4F61AA5 for ; Tue, 21 Oct 2003 00:44:55 +0200 (CEST) Received: from catl0ms22.corp.cox.com ([10.62.200.101]) by hatl0ms21.CORP.COX.COM with Microsoft SMTPSVC(5.0.2195.6713); Mon, 20 Oct 2003 18:44:52 -0400 Received: from mail pickup service by catl0ms22.corp.cox.com with Microsoft SMTPSVC; Mon, 20 Oct 2003 18:28:33 -0400 Received: from hatl0ms22.CORP.COX.COM ([10.62.201.69]) by catl0ms22.corp.cox.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 20 Oct 2003 12:02:46 -0400 Received: from bastion.cox.com ([10.230.2.65]) by hatl0ms22.CORP.COX.COM with Microsoft SMTPSVC(5.0.2195.6713); Mon, 20 Oct 2003 12:02:46 -0400 Received: from asgard.ietf.org (asgard.ietf.org [132.151.6.40]) by bastion.cox.com (8.11.7p1+Sun/8.11.6) with SMTP id h9KG2jr07008; Mon, 20 Oct 2003 12:02:45 -0400 (EDT) Received: from majordomo by asgard.ietf.org with local (Exim 4.14) id 1ABcC9-0008SR-Q2 for ietf-list@asgard.ietf.org; Mon, 20 Oct 2003 11:43:45 -0400 Received: from ietf.org ([10.27.2.28]) by asgard.ietf.org with esmtp (Exim 4.14) id 1ABcBD-0008RR-Gi for ietf@asgard.ietf.org; Mon, 20 Oct 2003 11:42:47 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01194 for ; Mon, 20 Oct 2003 11:42:38 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ABcBC-0001Wq-00 for ietf@ietf.org; Mon, 20 Oct 2003 11:42:46 -0400 Received: from mtiwmhc12.worldnet.att.net ([204.127.131.116]) by ietf-mx with esmtp (Exim 4.12) id 1ABcBC-0001Wb-00 for ietf@ietf.org; Mon, 20 Oct 2003 11:42:46 -0400 Received: from bolaba (117.sanjose-08-09rs16rt.ca.dial-access.att.net[12.81.3.117]) by worldnet.att.net (mtiwmhc12) with SMTP id <2003102015421311200ik72ve>; Mon, 20 Oct 2003 15:42:14 +0000 Message-ID: <001901c39720$21548240$010aff0a@bolaba> From: "todd glassey" To: "Spencer Dawkins" , , References: <36324071.1066428584@localhost><20031019220229.2cdc63dc.moore@cs.utk.edu> <046a01c396b3$7c47d2a0$0400a8c0@DFNJGL21> Date: Mon, 20 Oct 2003 08:37:51 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Transfer-Encoding: 7bit Precedence: bulk X-OriginalArrivalTime: 20 Oct 2003 16:02:46.0461 (UTC) FILETIME=[9A48AED0:01C39723] Subject: Re: IETF mission boundaries (Re: IESG proposed statement on theIETF mission ) X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit Spencer, this is not intended at you personally but rather at the whole IETF and this WG in particular. So let me ask then - What makes you think *you* or anyone else here has any say as to what is or is not routed on the Internet. ***YOU DON'T*** also as to "what breaks the Internet" - You don't there too. None of us do. And in fact NO ONE PERSON has any possible say as to the US internet except the person running DHS and if you doubt this - try arguing with them. BTW - The biggest thing the IETF can do is to get off the concept of "that its wares and efforts" only pertain to the Internet. Because they don't - obviously so too, and this is a key issue. If the IETF's actions only pertained to the Internet and there was such a quantifiable thing as the Internet then this might have some meaning - but its a fantasy that the IESG likes to propagate to justify its existence. Sorry if the truth hurts - but it is what it is. Todd ----- Original Message ----- From: "Spencer Dawkins" To: ; Sent: Sunday, October 19, 2003 7:40 PM Subject: Re: IETF mission boundaries (Re: IESG proposed statement on theIETF mission ) > > The number of application protocols with the oomph to "break" the > > Internet is quite small > > OK, I've gotta ask - how many times do we break the Internet before we > reverse this reasoning? (How many times is "too many"?) > > (signed) curious > > > From problem-statement-bounces@alvestrand.no Mon Oct 20 20:52:45 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA16436 for ; Mon, 20 Oct 2003 20:52:45 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 2825A61BB4; Tue, 21 Oct 2003 02:52:22 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from hatl0ms22.CORP.COX.COM (unknown [206.157.230.254]) by eikenes.alvestrand.no (Postfix) with ESMTP id 5A48A61B9D for ; Tue, 21 Oct 2003 02:52:20 +0200 (CEST) Received: from catl0ms23.corp.cox.com ([10.64.200.46]) by hatl0ms22.CORP.COX.COM with Microsoft SMTPSVC(5.0.2195.6713); Mon, 20 Oct 2003 20:52:19 -0400 Received: from mail pickup service by catl0ms23.corp.cox.com with Microsoft SMTPSVC; Mon, 20 Oct 2003 20:44:17 -0400 Received: from hatl0ms22.CORP.COX.COM ([10.62.201.69]) by catl0ms23.corp.cox.com with Microsoft SMTPSVC(5.0.2195.6713); Sun, 19 Oct 2003 22:52:51 -0400 Received: from bastion.cox.com ([10.230.2.65]) by hatl0ms22.CORP.COX.COM with Microsoft SMTPSVC(5.0.2195.6713); Sun, 19 Oct 2003 22:52:51 -0400 Received: from asgard.ietf.org (asgard.ietf.org [132.151.6.40]) by bastion.cox.com (8.11.7p1+Sun/8.11.6) with SMTP id h9K2qor07982; Sun, 19 Oct 2003 22:52:50 -0400 (EDT) Received: from majordomo by asgard.ietf.org with local (Exim 4.14) id 1ABQ0Q-0002UG-Rb for ietf-list@asgard.ietf.org; Sun, 19 Oct 2003 22:42:50 -0400 Received: from ietf.org ([10.27.2.28]) by asgard.ietf.org with esmtp (Exim 4.14) id 1ABPyJ-0002SZ-5X for ietf@asgard.ietf.org; Sun, 19 Oct 2003 22:40:39 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA27200 for ; Sun, 19 Oct 2003 22:40:29 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ABPyH-0002ww-00 for ietf@ietf.org; Sun, 19 Oct 2003 22:40:37 -0400 Received: from rwcrmhc12.comcast.net ([216.148.227.85]) by ietf-mx with esmtp (Exim 4.12) id 1ABPyG-0002wj-00 for ietf@ietf.org; Sun, 19 Oct 2003 22:40:36 -0400 Received: from dfnjgl21 (12-237-229-250.client.attbi.com[12.237.229.250]) by comcast.net (rwcrmhc12) with SMTP id <200310200240060140072s8ke> (Authid: sdawkins@comcast.net); Mon, 20 Oct 2003 02:40:06 +0000 Message-ID: <046a01c396b3$7c47d2a0$0400a8c0@DFNJGL21> From: "Spencer Dawkins" To: , References: <36324071.1066428584@localhost> <20031019220229.2cdc63dc.moore@cs.utk.edu> Date: Sun, 19 Oct 2003 21:40:11 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Transfer-Encoding: 7bit Precedence: bulk X-OriginalArrivalTime: 20 Oct 2003 02:52:51.0455 (UTC) FILETIME=[40A8B0F0:01C396B5] Subject: Re: IETF mission boundaries (Re: IESG proposed statement on the IETF mission ) X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Reply-To: Spencer Dawkins List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit > The number of application protocols with the oomph to "break" the > Internet is quite small OK, I've gotta ask - how many times do we break the Internet before we reverse this reasoning? (How many times is "too many"?) (signed) curious From problem-statement-bounces@alvestrand.no Tue Oct 21 11:32:49 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23494 for ; Tue, 21 Oct 2003 11:32:48 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id B151B61BAD; Tue, 21 Oct 2003 17:32:21 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by eikenes.alvestrand.no (Postfix) with ESMTP id 2D63161BA7; Tue, 21 Oct 2003 17:32:18 +0200 (CEST) Received: from cisco.com (64.102.124.13) by sj-iport-5.cisco.com with ESMTP; 21 Oct 2003 08:33:53 -0700 Received: from cisco.com (erosen-u10.cisco.com [161.44.70.36]) by rtp-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h9LFWEFQ026434; Tue, 21 Oct 2003 11:32:14 -0400 (EDT) Message-Id: <200310211532.h9LFWEFQ026434@rtp-core-2.cisco.com> To: Harald Tveit Alvestrand In-reply-to: Your message of Mon, 20 Oct 2003 11:46:15 -0700. <19916228.1066650375@localhost> User-Agent: EMH/1.14.1 SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (=?ISO-8859-4?Q?Unebigory=F2mae?=) APEL/10.3 Emacs/21.3 (sparc-sun-solaris2.8) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII Date: Tue, 21 Oct 2003 11:32:13 -0400 From: Eric Rosen Cc: graham.travers@bt.com, Michael Richardson , problem-statement@alvestrand.no Subject: Re: IESG proposed statement on the IETF mission X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list Reply-To: erosen@cisco.com List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no > Why an IETF standard, and not a Traffic Light Controllers Forum standard? Here's the typical progression. The "traffic light controllers forum" concludes that the Internet doesn't really provide adequate service/qos/oam/security or whatever and that controlling traffic lights requires an ATM/FrameRelay/DialUp/X.25/Ethernet or whatever. (Perhaps the rules for voting in the traffic light controllers forum prevent the technical issues from being considered.) A few rebel traffic light providers then get together with one or two networking vendors and figure out how to do the traffic light control over the Internet. In a short time, this proprietary mechanism becomes widely deployed, while the "standard" produced by the forum has no deployment. The forum fails to see this, and continues to work on perfecting the standard by adding additional OAM to it. The rebels (who by now are controlling most of the traffic lights) start to worry about their dependence on one or two vendors, and decide they want a published standard with some sort of imprimatur. So they ask for an IETF WG. Meantime, the IAB (whose job is to fret and deplore) issues a paper deploring the inadequate congestion control, security, and scalability of the proprietary mechanisms, fretting about the effect on the Internet. Prominent IESG members announce that anyone who pays attention to traffic lights is clueless, that no one will ever control them over the Internet anyway, and that the whole thing is just a vendor scam. Operators don't care whether traffic lights work or not, controlling them just adds complexity. Besides, traffic light control protocols weren't needed in 1990, so how can they be needed today? A WG is formed, but the charter requires that a requirements and framework document be produced before any protocol specification work is done. Four years later the IETF standards for the application get approved. They are quite similar to the proprietary mechanisms, which already dominate the industry. Prominent IESG members still insist that no one will ever deploy them. Other IETF members ask why the standards have been rushed through. The traffic light controller forum then endorses the IETF standard, renames themsevles to be the "IP-based real time device control forum", and asserts itself to be the proper standards body for all kinds of IP-based protocols. Seriously: - A considerable amount of time could be saved if the IETF just does the work in the first place. - The very last thing we want is a proliferation of clueless forums claiming to be producing standards for IP-based protocols; it's hard to see how that is "good for the Internet". - Traffic light control was picked as an example in order to make IETF involvement look absurd; if a more realistic example (providing some sort of network service or network infrastructure) had been picked, the proper conclusions would be even more obvious. From problem-statement-bounces@alvestrand.no Tue Oct 21 15:35:15 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03023 for ; Tue, 21 Oct 2003 15:35:14 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 2DB4361BAD; Tue, 21 Oct 2003 21:34:52 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from noxmail.sandelman.ottawa.on.ca (oetest.freeswan.org [205.150.200.166]) by eikenes.alvestrand.no (Postfix) with ESMTP id 0F7E061B9A; Tue, 21 Oct 2003 21:34:49 +0200 (CEST) Received: from sandelman.ottawa.on.ca (marajade.sandelman.ottawa.on.ca [205.150.200.247]) by noxmail.sandelman.ottawa.on.ca (8.11.6p3/8.11.6) with ESMTP id h9LJbd721936 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified OK); Tue, 21 Oct 2003 15:37:45 -0400 (EDT) Received: from marajade.sandelman.ottawa.on.ca (mcr@marajade [127.0.0.1]) by sandelman.ottawa.on.ca (8.12.3/8.12.3/Debian-6.6) with ESMTP id h9LJVamr000972 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Tue, 21 Oct 2003 15:31:37 -0400 Received: from marajade.sandelman.ottawa.on.ca (mcr@localhost) by marajade.sandelman.ottawa.on.ca (8.12.3/8.12.3/Debian-6.6) with ESMTP id h9LJVWOv000968; Tue, 21 Oct 2003 15:31:35 -0400 To: Harald Tveit Alvestrand In-reply-to: Your message of "Mon, 20 Oct 2003 11:46:15 PDT." <19916228.1066650375@localhost> Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Tue, 21 Oct 2003 15:31:31 -0400 Message-ID: <967.1066764691@marajade.sandelman.ottawa.on.ca> From: Michael Richardson Cc: graham.travers@bt.com, problem-statement@alvestrand.no Subject: Re: IESG proposed statement on the IETF mission X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Harald" == Harald Tveit Alvestrand writes: >> As soon as the lights in NYC (owned, provisioned and bought by NYC) >> have to operate with the light controller in Chicago, then we need an >> IETF standard. Harald> Why an IETF standard, and not a Traffic Light Controllers Forum Harald> standard? a) Fora tend to include only people who pay to join them, and not the general public, or things like LEAs, or pedestrian and cycling organizations (which in this case, might care) b) I'm not actually sure the answer to the above question for any of the things currently in Applications, and even some of things in Transport. Having said that, I'm not sure that they shouldn't be there. ] Collecting stories about my dad: http://www.sandelman.ca/cjr/ | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another Debian/notebook using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Finger me for keys - custom hacks make this fully PGP2 compat iQCVAwUBP5WJkYqHRg3pndX9AQFJBwP8DeUyQRw37EAuHNcs1hHVwhovL+HmklNb TjqZMpUhTXEpg8GBYKI2varLevOyK0GxdnFb3gpdhcoMmYGjrACueYk3IuASLHb+ Ba6k4w5/I5e8vJmjK8HWqY4T4pjkb3rKnSJR9x7SXYeemUof8RHfuV3w379ST/Gw 36+Vwfz575o= =TNmg -----END PGP SIGNATURE----- From problem-statement-bounces@alvestrand.no Wed Oct 22 08:27:18 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA05403 for ; Wed, 22 Oct 2003 08:27:13 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 05A2A61BEA; Wed, 22 Oct 2003 14:26:49 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by eikenes.alvestrand.no (Postfix) with ESMTP id CC3A461B8D; Wed, 22 Oct 2003 14:26:46 +0200 (CEST) Received: from employees.org (171.68.223.138) by sj-iport-5.cisco.com with ESMTP; 22 Oct 2003 05:28:41 -0700 Received: from cisco.com (sjc-vpn2-404.cisco.com [10.21.113.148]) by sj-core-4.cisco.com (8.12.6/8.12.6) with SMTP id h9MCQebd029997; Wed, 22 Oct 2003 05:26:41 -0700 (PDT) Received: by cisco.com (sSMTP sendmail emulation); Wed, 22 Oct 2003 08:26:28 -0400 Date: Wed, 22 Oct 2003 08:26:28 -0400 From: Scott W Brim To: Margaret.Wasserman@nokia.com Message-ID: <20031022082628.F2936@sbrim-w2k01> Mail-Followup-To: Scott W Brim , Margaret.Wasserman@nokia.com, harald@alvestrand.no, problem-statement@alvestrand.no, ietf@ietf.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from Margaret.Wasserman@nokia.com on Wed, Oct 15, 2003 at 01:01:53PM -0400 Cc: harald@alvestrand.no, ietf@ietf.org, problem-statement@alvestrand.no Subject: Re: IESG proposed statement on the IETF mission X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no On Wed, Oct 15, 2003 01:01:53PM -0400, Margaret.Wasserman@nokia.com allegedly wrote: > > Hi Scott, > > > Similarly for almost all of the rest. What's the point? Are you > > reiterating the problem-statement work? They're doing all right, > > although perhaps you could help push the work to completion. It would > > be much more useful for you to reaffirm the fundamental > > principles that are not on the auction block. > > >From your perspective, what are those fundamental principles? I still haven't replied and I don't know when I'll get to. I thought I would have room in the last few days, but we're trying to finish a document and my wife goes for her (hopefully final) chemotherapy session on Thursday, which means I turn into a pumpkin for the rest of the week. Someday. Sorry. From problem-statement-bounces@alvestrand.no Wed Oct 22 19:19:40 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA05894 for ; Wed, 22 Oct 2003 19:19:40 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 8B26161C09; Thu, 23 Oct 2003 01:19:02 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from halvestr-w2k1 (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 46DD461BF4; Thu, 23 Oct 2003 01:18:57 +0200 (CEST) Date: Wed, 22 Oct 2003 18:18:44 -0500 From: Harald Tveit Alvestrand To: Michael Richardson Message-ID: <209060583.1066846724@localhost> In-Reply-To: <967.1066764691@marajade.sandelman.ottawa.on.ca> References: <967.1066764691@marajade.sandelman.ottawa.on.ca> X-Mailer: Mulberry/3.1.0b8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Cc: graham.travers@bt.com, problem-statement@alvestrand.no Subject: Re: IESG proposed statement on the IETF mission X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit --On 21. oktober 2003 15:31 -0400 Michael Richardson wrote: > Harald> Why an IETF standard, and not a Traffic Light Controllers > Forum Harald> standard? > > a) Fora tend to include only people who pay to join them, and not the > general public, or things like LEAs, or pedestrian and cycling > organizations (which in this case, might care) That's an issue with the form of the forum. I think the Global Grid Forum has taken a number of ideas from the IETF in how they do their work, for instance. And the interests of pedestrian organizations aren't very well served by the current IETF constituency, for that matter.... > > b) I'm not actually sure the answer to the above question for any of the > things currently in Applications, and even some of things in > Transport. Having said that, I'm not sure that they shouldn't be > there. I don't think that it's necessary for the IETF mission to be consistent with every decision we've taken in the past. And some things (like LDAP) didn't turn out the way we thought they would five or ten years back - the global directory is as dead as the global PKI at the moment. From problem-statement-bounces@alvestrand.no Thu Oct 23 09:51:59 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21282 for ; Thu, 23 Oct 2003 09:51:56 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 5207061BD6; Thu, 23 Oct 2003 15:51:31 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by eikenes.alvestrand.no (Postfix) with ESMTP id 9AB1261BB4; Thu, 23 Oct 2003 15:51:28 +0200 (CEST) Received: from cisco.com (64.102.124.13) by sj-iport-5.cisco.com with ESMTP; 23 Oct 2003 06:53:43 -0700 Received: from cisco.com (erosen-u10.cisco.com [161.44.70.36]) by rtp-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h9NDpNN0016869; Thu, 23 Oct 2003 09:51:24 -0400 (EDT) Message-Id: <200310231351.h9NDpNN0016869@rtp-core-2.cisco.com> To: Harald Tveit Alvestrand In-reply-to: Your message of Wed, 22 Oct 2003 18:18:44 -0500. <209060583.1066846724@localhost> User-Agent: EMH/1.14.1 SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (=?ISO-8859-4?Q?Unebigory=F2mae?=) APEL/10.3 Emacs/21.3 (sparc-sun-solaris2.8) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII Date: Thu, 23 Oct 2003 09:51:23 -0400 From: Eric Rosen Cc: graham.travers@bt.com, Michael Richardson , problem-statement@alvestrand.no Subject: Re: IESG proposed statement on the IETF mission X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list Reply-To: erosen@cisco.com List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Harald> I don't think that it's necessary for the IETF mission to be Harald> consistent with every decision we've taken in the past. If your "mission statement" is inconsistent with MANY of the decisions that have been taken in the past, then you should admit that you are trying to change the IETF's mission to suit your own preferences, rather than trying to codify any existing practice. If we're not trying for any consistency, then I would raise the following questions: 1. Why should the IETF work on BGP? Can't that be done by a consortium of vendors and ISPs separate from the IETF? 2. Why should the IETF work on DNS? Can't that be done by a consortium of vendors and ISPs separate from the IETF? 3. Why should the IETF exist at all? Surely anything it does can be done somewhere else by some other group. We should either aim for consistency with the past, or else do a "zero-based" mission statement in which everything is up for grabs and there are no sacred cows. From problem-statement-bounces@alvestrand.no Thu Oct 23 12:45:10 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06339 for ; Thu, 23 Oct 2003 12:45:09 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 3438661BDA; Thu, 23 Oct 2003 18:44:48 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from halvestr-w2k1 (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id D72C061BD6; Thu, 23 Oct 2003 18:44:45 +0200 (CEST) Date: Thu, 23 Oct 2003 11:40:32 -0500 From: Harald Tveit Alvestrand To: erosen@cisco.com Message-ID: <271568785.1066909232@localhost> In-Reply-To: <200310231351.h9NDpNN0016869@rtp-core-2.cisco.com> References: <200310231351.h9NDpNN0016869@rtp-core-2.cisco.com> X-Mailer: Mulberry/3.1.0b8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Cc: problem-statement@alvestrand.no Subject: Re: IESG proposed statement on the IETF mission X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit --On 23. oktober 2003 09:51 -0400 Eric Rosen wrote: > > Harald> I don't think that it's necessary for the IETF mission to > be Harald> consistent with every decision we've taken in the past. > > If your "mission statement" is inconsistent with MANY of the decisions > that have been taken in the past, then you should admit that you are > trying to change the IETF's mission to suit your own preferences, > rather than trying to codify any existing practice. True. But I don't want to close out the option of admitting that adopting TRADE, FORCES, OPES or SPEECHSC was a mistake, or that we shouldn't have kicked HTML work out of the IETF and into the World Wide Web Consortium, if that's what the community thinks. All of these were debated at the time the decisions were made. It would be a surprise if we, using 20/20 hindsight, were to conclude that we did the right thing every time. Note: If I was trying to change the IETF's mission to suit my own preferences, this discussion would be shorter. I'm trying to change the IETF's mission to suit the *IETF*'s preferences. Harald From problem-statement-bounces@alvestrand.no Thu Oct 23 16:45:32 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18109 for ; Thu, 23 Oct 2003 16:45:31 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id C31FB61BDA; Thu, 23 Oct 2003 22:45:09 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from noxmail.sandelman.ottawa.on.ca (noxmail.sandelman.ottawa.on.ca [205.150.200.166]) by eikenes.alvestrand.no (Postfix) with ESMTP id 415FB61BD9 for ; Thu, 23 Oct 2003 22:45:07 +0200 (CEST) Received: from sandelman.ottawa.on.ca (marajade.sandelman.ottawa.on.ca [205.150.200.247]) by noxmail.sandelman.ottawa.on.ca (8.11.6p3/8.11.6) with ESMTP id h9NKln302736 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified OK); Thu, 23 Oct 2003 16:47:54 -0400 (EDT) Received: from marajade.sandelman.ottawa.on.ca (mcr@marajade [127.0.0.1]) by sandelman.ottawa.on.ca (8.12.3/8.12.3/Debian-6.6) with ESMTP id h9NKfEmr030114 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Thu, 23 Oct 2003 16:41:14 -0400 Received: from marajade.sandelman.ottawa.on.ca (mcr@localhost) by marajade.sandelman.ottawa.on.ca (8.12.3/8.12.3/Debian-6.6) with ESMTP id h9NKf88f030091; Thu, 23 Oct 2003 16:41:11 -0400 To: ietf@ietf.org, problem-statement@alvestrand.no In-reply-to: Your message of "Thu, 16 Oct 2003 11:04:32 +0200." <11016450.1066302272@localhost> Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Thu, 23 Oct 2003 16:41:08 -0400 Message-ID: <30090.1066941668@marajade.sandelman.ottawa.on.ca> From: Michael Richardson Subject: Re: IETF mission boundaries (Re: IESG proposed statement on the IETF mission ) X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Harald" == Harald Tveit Alvestrand writes: Harald> In the discussions leading up to this document, we actually had 3 Harald> different other levels of "inclusivity" up for consideration: okay, I very much like these descriptions. Harald> - "Everything that runs over the Internet is appropriate for IETF Harald> standardization". Harald> - "Everything that needs open, documented interoperability and Harald> runs over the Internet is appropriate for IETF Harald> standardization". Harald> - "Everything that builds infrastructures on the Internet that Harald> needs to be open and interoperable is appropriate for IETF Harald> standardization". These are three levels that I understand, and each seems to enclose the next. Harald> - "Everything that can seriously impact the Internet is Harald> appropriate for IETF standardization". This is very much more nebulous, because "seriously impact" is a question of very open judgement. ] Collecting stories about my dad: http://www.sandelman.ca/cjr/ | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another Debian/notebook using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Finger me for keys - custom hacks make this fully PGP2 compat iQCVAwUBP5g84oqHRg3pndX9AQH01AP/ayMZ2WJVxz7xZXVSu9Pbew9U1A+GLUFb PVgK45qNL/qsL95U4cU1SyV5Tn2YYTjWkSD4j8tVNHAX+HyoqDJPYgWFwevOKblY HCwUj3N6Y/U43TpIZ8+w8NqcIkV0Z4BPc9kjpSjiUeTOZ4nfY+Pbg3yS+vaUvWcd ThqgtWgB7Lc= =p3P3 -----END PGP SIGNATURE----- From problem-statement-bounces@alvestrand.no Thu Oct 23 19:18:58 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA24143 for ; Thu, 23 Oct 2003 19:18:57 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id AFE0761BE5; Fri, 24 Oct 2003 01:18:37 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from mtiwmhc12.worldnet.att.net (mtiwmhc12.worldnet.att.net [204.127.131.116]) by eikenes.alvestrand.no (Postfix) with ESMTP id DC7D161B8E; Fri, 24 Oct 2003 01:18:34 +0200 (CEST) Received: from bolaba (34.sanjose-01-02rs16rt.ca.dial-access.att.net[12.81.0.34]) by worldnet.att.net (mtiwmhc12) with SMTP id <2003102323182711200kr63ne>; Thu, 23 Oct 2003 23:18:30 +0000 Message-ID: <009f01c399bb$53537ba0$010aff0a@bolaba> From: "todd glassey" To: "Harald Tveit Alvestrand" , References: <200310231351.h9NDpNN0016869@rtp-core-2.cisco.com> <271568785.1066909232@localhost> Date: Thu, 23 Oct 2003 16:13:21 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Cc: problem-statement@alvestrand.no Subject: Re: IESG proposed statement on the IETF mission X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit Harald - perhaps the problem is that the IETF's preferences are the issue. Todd ----- Original Message ----- From: "Harald Tveit Alvestrand" To: Cc: Sent: Thursday, October 23, 2003 9:40 AM Subject: Re: IESG proposed statement on the IETF mission > > > --On 23. oktober 2003 09:51 -0400 Eric Rosen wrote: > > > > > Harald> I don't think that it's necessary for the IETF mission to > > be Harald> consistent with every decision we've taken in the past. > > > > If your "mission statement" is inconsistent with MANY of the decisions > > that have been taken in the past, then you should admit that you are > > trying to change the IETF's mission to suit your own preferences, > > rather than trying to codify any existing practice. > > True. But I don't want to close out the option of admitting that adopting > TRADE, FORCES, OPES or SPEECHSC was a mistake, or that we shouldn't have > kicked HTML work out of the IETF and into the World Wide Web Consortium, if > that's what the community thinks. > All of these were debated at the time the decisions were made. It would be > a surprise if we, using 20/20 hindsight, were to conclude that we did the > right thing every time. > > Note: If I was trying to change the IETF's mission to suit my own > preferences, this discussion would be shorter. I'm trying to change the > IETF's mission to suit the *IETF*'s preferences. > > Harald > > From problem-statement-bounces@alvestrand.no Fri Oct 24 01:40:39 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA04093 for ; Fri, 24 Oct 2003 01:40:39 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 76CF561BE2; Fri, 24 Oct 2003 07:40:16 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from mail3.microsoft.com (mail3.microsoft.com [131.107.3.123]) by eikenes.alvestrand.no (Postfix) with ESMTP id F16FE61BDA; Fri, 24 Oct 2003 07:40:12 +0200 (CEST) Received: from INET-VRS-03.redmond.corp.microsoft.com ([157.54.5.27]) by mail3.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 23 Oct 2003 22:40:11 -0700 Received: from 157.54.5.25 by INET-VRS-03.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 23 Oct 2003 22:40:11 -0700 Received: from red-imc-01.redmond.corp.microsoft.com ([157.54.9.102]) by inet-hub-03.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 23 Oct 2003 22:40:10 -0700 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by red-imc-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Thu, 23 Oct 2003 22:40:10 -0700 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Thu, 23 Oct 2003 22:40:10 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7097.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 23 Oct 2003 22:40:15 -0700 Message-ID: Thread-Topic: Proposed statement quotes wrong numbers thread-index: AcOSoeR8gDOBL1xpRi+gwL537VDkXgHTW/xA From: "Christian Huitema" To: "Harald Tveit Alvestrand" , , X-OriginalArrivalTime: 24 Oct 2003 05:40:10.0206 (UTC) FILETIME=[49DF87E0:01C399F1] Subject: Proposed statement quotes wrong numbers X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: quoted-printable The statement that you issued repeatedly mentions that the IETF rules and social contract were establish at a time when the IETF had 50 to 250 or 50 to 300 members. The obvious implication is that, since the attendance has grown by an order of magnitude, the rules have to change significantly. The problem is that the 50-300 numbers are wrong. The original rules of the IETF were indeed devised in 1986, when the IETF was just created and had maybe 30-50 members. However, the current rules were designed in 1992-1993, in large part because the IETF had outgrown the previous rules. If you look at http://www.ietf.org/meetings/past.meetings.html, you will see that the attendance then was in the 500-700 range. Dave Clark's statement was made during the 24th IETF, held July 13-17, 1992 in Cambridge, Massachusetts. There were 677 attendees. Since then, the IETF has grown, and then shrunk. The current size is about double the size of 1992. That is significant, but not quite an order of magnitude. -- Christian Huitema From problem-statement-bounces@alvestrand.no Fri Oct 24 11:08:04 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07409 for ; Fri, 24 Oct 2003 11:08:02 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id CC0DA61BDA; Fri, 24 Oct 2003 17:07:38 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by eikenes.alvestrand.no (Postfix) with ESMTP id A55E661B94; Fri, 24 Oct 2003 17:07:36 +0200 (CEST) Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id h9OF7aI21757; Fri, 24 Oct 2003 18:07:36 +0300 (EET DST) Received: from esebh001.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 24 Oct 2003 18:07:35 +0300 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Fri, 24 Oct 2003 18:07:35 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Fri, 24 Oct 2003 18:07:35 +0300 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Fri, 24 Oct 2003 18:07:35 +0300 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Date: Fri, 24 Oct 2003 18:07:35 +0300 Message-ID: Thread-Topic: I-D ACTION:draft-loughney-what-standards-00.txt Thread-Index: AcOZan/ybnuBEDdBQhOskuYJ8g09xQAs/HUQ From: To: , X-OriginalArrivalTime: 24 Oct 2003 15:07:35.0277 (UTC) FILETIME=[8E5119D0:01C39A40] Subject: For your consideration: I-D ACTION:draft-loughney-what-standards-00.txt X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: quoted-printable Hi all, I've written up a document which discusses in more detail some of the = issues discussed on the Problem Statement list, and work forward on producing a possible solution for these problems. Initially, I have outlined the problems & I intend, in future updates, to discuss the solution = possibilities in more details My intention in sharing this with the problem statement list is to = verify that my understanding of the problems discussed are more-or-less = accurate. I would hope, though, to do the bulk of discussion on the Solutions = mailing list. thanks, John Title : Standards, What Standards? Author(s) : J. Loughney Filename : draft-loughney-what-standards-00.txt Pages : 15 Date : 2003-10-23 =09 The current problem working group has identified problems with they way = in which the IETF manages the document series. This document discusses some of the = problems caused by the current state of affairs and lays out some steps to = correct the problems. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-loughney-what-standards-00.txt From problem-statement-bounces@alvestrand.no Fri Oct 24 11:08:22 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07438 for ; Fri, 24 Oct 2003 11:08:18 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id D098961BF4; Fri, 24 Oct 2003 17:07:54 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by eikenes.alvestrand.no (Postfix) with ESMTP id 663B961B94; Fri, 24 Oct 2003 17:07:52 +0200 (CEST) Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id h9OF7pI22006; Fri, 24 Oct 2003 18:07:51 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 24 Oct 2003 18:07:51 +0300 Received: from esebe007.NOE.Nokia.com ([172.21.138.47]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Fri, 24 Oct 2003 18:07:50 +0300 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe007.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Fri, 24 Oct 2003 18:07:50 +0300 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Date: Fri, 24 Oct 2003 18:07:49 +0300 Message-ID: Thread-Topic: IESG proposed statement on the IETF mission Thread-Index: AcOSnRJ0iekjj9LVTOe1EGpNCLmQ1AHg3WRQ From: To: , , X-OriginalArrivalTime: 24 Oct 2003 15:07:50.0390 (UTC) FILETIME=[97532960:01C39A40] Subject: RE: IESG proposed statement on the IETF mission X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: quoted-printable Hi Harald, I'm going to pick on one statement, which other have as well. > It is important that this is "For the Internet," and does not include = > everything that happens to use IP. IP is being used in a myriad of=20 > real-world applications, such as controlling street lights, but the=20 > IETF does not standardize those applications. I almost feel that this should just be dropped from the statement. My reasons being that I have been told by the IESG about protocol = extensibility is that the IETF wants to have a tighter control over protocol=20 extensibility, even for extensions thought to be for limited use or specific networks (for example, cellular networks). The reason being is that once something is out there, it often starts to be used in ways which were not originally planned or used outside of its=20 original 'limited use' plans. Therefore, in order to ensure proper protocol behavior & interoperability, the IESG wants to manage extensibility. This has been very true in SIP & Diameter, for example. On the other hand, we see a protocol like RADIUS, which the IETF has never done a good job at working with or standardizing, being developed in 4 or more SDOs, and not in a colaborative manner. This makes a big mess with the RADIUS spec, and RADIUS does seem like a protocol that has a big effect on the Internet. So, in summary, the IESG has shown not to follow the above paragraph, sometimes even for good reasons. I can't think of a way in which=20 modify the paragraph to make it any better - because there will always be examples of work that the IETF choses to standardize (or not) which will violate that part of the mission. Perhaps moving the=20 'for the internet to the previous paragraph is what is needed. This leaves open the very interesting and difficult questions of how to measure quality, relevance, and timeliness. The IETF has identified interoperability, security, scalability and=20 'for the Internet' as essential, but without attaching measurements=20 to those characteristics. John From problem-statement-bounces@alvestrand.no Sun Oct 26 04:27:02 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA12683 for ; Sun, 26 Oct 2003 04:27:01 -0500 (EST) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 21D7461B9D; Sun, 26 Oct 2003 10:26:39 +0100 (CET) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by eikenes.alvestrand.no (Postfix) with ESMTP id DBF0161B98 for ; Sun, 26 Oct 2003 10:26:36 +0100 (CET) Message-ID: <000201c39ba3$4c36a510$596015ac@dclkempt40> From: "James Kempf" To: Date: Sun, 26 Oct 2003 00:26:03 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Subject: Comments on draft-wasserman-rfc2418-update-00.txt X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit Margaret, Looks really good, only two comments: - The section on what to do if a WG chair is also a document editor seems a little unclear to me. I'd suggest the following rewording of the second paragraph: If a WG chair also serves as the Document Editor for a WG document, that WG chair is expected to recluse from all decisions about the document, including calling concensus and judging quality. If the WG has more than one WG chair, as is typically the case, then the chair who is not also Document Editor will manage the working group process for that document. The roles of the WG Chairs must be made clear to the WG in this case. In rare cases, perhaps due to a role change, a lone WG Chair may also serve as a Document Editor for a WG document, but that situation should be avoided when possible, and must be corrected as quickly as practical by turning over the Document Editor role to another person. - I think something should be added in the appeals section (Section 3.5 in the new document) about appealing quality and mailing list management decisions. These changes are giving significant new authority to WG chairs, which I think is absolutely necessary, but the document should also remind people that they have recourse if they believe they are being treated unfairly. I think this will go a long way towards making the IETF process more scalable, and reducing the management burden on the IESG. jak From problem-statement-bounces@alvestrand.no Sun Oct 26 05:03:56 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA13352 for ; Sun, 26 Oct 2003 05:03:55 -0500 (EST) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id D6C1461B9D; Sun, 26 Oct 2003 11:03:35 +0100 (CET) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from netcore.fi (netcore.fi [193.94.160.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 800F261B98 for ; Sun, 26 Oct 2003 11:03:34 +0100 (CET) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h9QA3LB25724; Sun, 26 Oct 2003 12:03:21 +0200 Date: Sun, 26 Oct 2003 12:03:20 +0200 (EET) From: Pekka Savola To: James Kempf In-Reply-To: <000201c39ba3$4c36a510$596015ac@dclkempt40> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: problem-statement@alvestrand.no Subject: Re: Comments on draft-wasserman-rfc2418-update-00.txt X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no On Sun, 26 Oct 2003, James Kempf wrote: [...] > I think this will go a long way towards making the IETF process more > scalable, and reducing the management burden on the IESG. Yes, maybe the goal is to change the "big bad IESG" to "big bad WG chair".. I'm not sure whether that's a bad thing, but that it might have implications (such as, WG chairs getting fired more easily for not standing up against bad ideas, WG chairs being required to commit a lot more resources to the job (properly), decisions appealed more often and all the time wasted processing the appeals and appeals on appeals, etc.). It's just that _someone_ has to be able to tell the bad news about a document. Now it's easier when the WG chair can blame the AD, and the AD can blame the WG ("good cop, bad cop" :-). If you bundle these responsibilities in one, the WG chair (acting responsibly) would be seen as a lot more partial in the discussion. The ADs and the IESG, as currently done, don't have to care (.. that much). Whether that's a bug or feature is another thing.. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From problem-statement-bounces@alvestrand.no Sun Oct 26 05:34:04 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA13979 for ; Sun, 26 Oct 2003 05:34:04 -0500 (EST) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 694B461B9D; Sun, 26 Oct 2003 11:33:44 +0100 (CET) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by eikenes.alvestrand.no (Postfix) with ESMTP id ED2C361B98 for ; Sun, 26 Oct 2003 11:33:41 +0100 (CET) Message-ID: <00b701c39bac$ab75cc50$596015ac@dclkempt40> From: "James Kempf" To: "Pekka Savola" References: Date: Sun, 26 Oct 2003 02:33:57 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Cc: problem-statement@alvestrand.no Subject: Re: Comments on draft-wasserman-rfc2418-update-00.txt X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit Pekka, It simply isn't scalable to have 13 people take first line responsibility for a 2000+ person technical organization with 240 working groups generating X x 10**2 documents per year. To say nothing of requiring the full IESG to decide whether someone should be ejected from a mailing list for disruption. Hierarchical management is the only way to inject scalability into the process. Directorates help a little if the ADs use them, since they can offload some processing, but I'm sure most ADs won't trust directorates opinions alone with standards track documents, and many people are suspicious of directorates because they have no official status. We can either set up another level of management hierarchy or we can take the level that's there, namely the WG chairs, and empower them to really manage their WGs. Naturally, as you point out, this makes the WG chairs responsible for their decisions, but that's part of empowerment. And, yes, WG chairs need to be removed if they aren't performing (they are occasionally today), and, yes, they need to commit more time to the job. To prevent an increase in appeals, WG chairs need to understand their roles, hence the need for the kind of training Margaret and others are trying to organize. The ADs still have the final decision, of course, and they can still push back and the WG chairs need to convey that to the WG, just like today. But hopefully, the upshot will be that fewer poor quality documents are sent to the IESG. So I agree this will be more work for the WG chairs, but you don't get something for nothing. If we want to relieve the pressure on the IESG, the load has got to spread out somewhere and the WG chairs are the logical place to do it. jak ----- Original Message ----- From: "Pekka Savola" To: "James Kempf" Cc: Sent: Sunday, October 26, 2003 2:03 AM Subject: Re: Comments on draft-wasserman-rfc2418-update-00.txt > On Sun, 26 Oct 2003, James Kempf wrote: > [...] > > I think this will go a long way towards making the IETF process more > > scalable, and reducing the management burden on the IESG. > > Yes, maybe the goal is to change the "big bad IESG" to "big bad WG > chair".. I'm not sure whether that's a bad thing, but that it might have > implications (such as, WG chairs getting fired more easily for not > standing up against bad ideas, WG chairs being required to commit a lot > more resources to the job (properly), decisions appealed more often and > all the time wasted processing the appeals and appeals on appeals, etc.). > > It's just that _someone_ has to be able to tell the bad news about a > document. Now it's easier when the WG chair can blame the AD, and the AD > can blame the WG ("good cop, bad cop" :-). If you bundle these > responsibilities in one, the WG chair (acting responsibly) would be seen > as a lot more partial in the discussion. The ADs and the IESG, as > currently done, don't have to care (.. that much). Whether that's a bug > or feature is another thing.. > > -- > Pekka Savola "You each name yourselves king, yet the > Netcore Oy kingdom bleeds." > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings > > From problem-statement-bounces@alvestrand.no Sun Oct 26 15:26:22 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27603 for ; Sun, 26 Oct 2003 15:26:21 -0500 (EST) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id DA68B61BDE; Sun, 26 Oct 2003 21:26:00 +0100 (CET) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from zctfs063.nortelnetworks.com (zctfs063.nortelnetworks.com [47.164.128.120]) by eikenes.alvestrand.no (Postfix) with ESMTP id 4ADEC61BA0 for ; Sun, 26 Oct 2003 21:25:58 +0100 (CET) Received: from znsgs01r.nortelnetworks.com (znsgs01r.europe.nortel.com [47.166.48.91] (may be forged)) by zctfs063.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h9QKPtb03769 for ; Sun, 26 Oct 2003 21:25:56 +0100 (MET) Received: from zwcwc012.europe.nortel.com (zwcwc012.europe.nortel.com [47.160.46.124]) by znsgs01r.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h9QKPsC18367 for ; Sun, 26 Oct 2003 20:25:54 GMT Received: by zwcwc012.europe.nortel.com with Internet Mail Service (5.5.2653.19) id ; Sun, 26 Oct 2003 20:25:55 -0000 Message-ID: <4103264BC8D3D51180B7002048400C45043ABB1C@zhard0jd.europe.nortel.com> From: "Elwyn Davies" To: "'Problem Statement Working Group'" Date: Sun, 26 Oct 2003 20:25:54 -0000 X-Mailer: Internet Mail Service (5.5.2653.19) Subject: New versions of issues and resolutions drafts X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no I have sent new versions of the two drafts to the I-D editor today. draft-ietf-problem-issue-summary-04.txt draft-ietf-problem-process-03.txt These reflect comments received during the last call on the issues document and the inability of the WG to come to a consensus on a way for resolving the structural problems. Regards, Elwyn on behalf of document editors. ---------------------------------------------------------------------------- ------ Elwyn B Davies Routing and Addressing Strategy Prime & IPv6 Core Team Leader CTO Office, Portfolio Integration Solutions Ready Nortel Networks plc Email: elwynd@nortelnetworks.com Harlow Laboratories ESN 6-742-5498 London Road, Harlow, Direct Line +44-1279-405498 Essex, CM17 9NA, UK Fax +44-1279-402047 Registered Office: Maidenhead Office Park, Westacott Way, Company No. 3937799 Maidenhead, Berkshire, SSL6 3QH ---------------------------------------------------------------------------- This message may contain information proprietary to Nortel Networks plc so any unauthorised disclosure, copying or distribution of its contents is strictly prohibited. ---------------------------------------------------------------------------- "The Folly is mostly mine" and the opinions are mine and not those of my employer. ============================================================================ ====== From problem-statement-bounces@alvestrand.no Mon Oct 27 00:35:08 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA13149 for ; Mon, 27 Oct 2003 00:35:07 -0500 (EST) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id EA5DC61BFD; Mon, 27 Oct 2003 06:34:48 +0100 (CET) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from halvestr-w2k1 (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 6498961BFB; Mon, 27 Oct 2003 06:34:46 +0100 (CET) Date: Sun, 26 Oct 2003 21:34:45 -0800 From: Harald Tveit Alvestrand To: Christian Huitema , ietf@ietf.org, problem-statement@alvestrand.no Message-ID: <222145117.1067204085@[192.168.1.49]> In-Reply-To: References: X-Mailer: Mulberry/3.1.0b8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: Re: Proposed statement quotes wrong numbers X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit Christian, thanks for the correction. We can quibble about the exact dates for a while, but I've made the quip quite a few times that the IETF has a fine scalable management structure, which will scale all the way to 700 participants...... so I agree that "order of magnitude" is a misnomer. We do, however, have trouble, even at our currently reduced size. Harald --On 23. oktober 2003 22:40 -0700 Christian Huitema wrote: > The statement that you issued repeatedly mentions that the IETF rules > and social contract were establish at a time when the IETF had 50 to 250 > or 50 to 300 members. The obvious implication is that, since the > attendance has grown by an order of magnitude, the rules have to change > significantly. > > The problem is that the 50-300 numbers are wrong. The original rules of > the IETF were indeed devised in 1986, when the IETF was just created and > had maybe 30-50 members. However, the current rules were designed in > 1992-1993, in large part because the IETF had outgrown the previous > rules. If you look at http://www.ietf.org/meetings/past.meetings.html, > you will see that the attendance then was in the 500-700 range. Dave > Clark's statement was made during the 24th IETF, held July 13-17, 1992 > in Cambridge, Massachusetts. There were 677 attendees. > > Since then, the IETF has grown, and then shrunk. The current size is > about double the size of 1992. That is significant, but not quite an > order of magnitude. > > -- Christian Huitema > From problem-statement-bounces@alvestrand.no Mon Oct 27 00:44:37 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA13419 for ; Mon, 27 Oct 2003 00:44:36 -0500 (EST) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id F223861BFD; Mon, 27 Oct 2003 06:44:17 +0100 (CET) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from halvestr-w2k1 (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id ED03C61BFB; Mon, 27 Oct 2003 06:44:14 +0100 (CET) Date: Sun, 26 Oct 2003 21:44:13 -0800 From: Harald Tveit Alvestrand To: john.loughney@nokia.com, ietf@ietf.org, problem-statement@alvestrand.no Message-ID: <222713495.1067204653@[192.168.1.49]> In-Reply-To: References: X-Mailer: Mulberry/3.1.0b8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: RE: IESG proposed statement on the IETF mission X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit --On 24. oktober 2003 18:07 +0300 john.loughney@nokia.com wrote: > Hi Harald, > > I'm going to pick on one statement, which other have as well. > >> It is important that this is "For the Internet," and does not include >> everything that happens to use IP. IP is being used in a myriad of >> real-world applications, such as controlling street lights, but the >> IETF does not standardize those applications. > > I almost feel that this should just be dropped from the statement. My > reasons being that I have been told by the IESG about protocol > extensibility is that the IETF wants to have a tighter control over > protocol > extensibility, even for extensions thought to be for limited use > or specific networks (for example, cellular networks). The reason > being is that once something is out there, it often starts to be used > in ways which were not originally planned or used outside of its > original 'limited use' plans. Therefore, in order to ensure proper > protocol behavior & interoperability, the IESG wants to manage > extensibility. This has been very true in SIP & Diameter, for example. True. Nearly a year ago, we attempted to publish draft-iesg-vendor-extensions, to describe these problems in more detail - but we failed to get that finished. > > On the other hand, we see a protocol like RADIUS, which the IETF > has never done a good job at working with or standardizing, being > developed in 4 or more SDOs, and not in a colaborative manner. This > makes a big mess with the RADIUS spec, and RADIUS does seem like a > protocol that has a big effect on the Internet. You'll have no disagreement from me that RADIUS is a problem! > So, in summary, the IESG has shown not to follow the above paragraph, > sometimes even for good reasons. I can't think of a way in which > modify the paragraph to make it any better - because there will always > be examples of work that the IETF choses to standardize (or not) > which will violate that part of the mission. Perhaps moving the > 'for the internet to the previous paragraph is what is needed. as I've said before - I don't think we can come up with a mission statement that retroactively blesses everything we've done well before, or retroactively curses everything we've done badly. And we do require flexibility to "do what's right". But without the ability to talk about what the mission of the IETF ... I think we'll do badly. Harald From problem-statement-bounces@alvestrand.no Mon Oct 27 06:58:48 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA08255 for ; Mon, 27 Oct 2003 06:58:47 -0500 (EST) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 5924261BFC; Mon, 27 Oct 2003 12:58:27 +0100 (CET) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from rwcrmhc12.comcast.net (rwcrmhc12.comcast.net [216.148.227.85]) by eikenes.alvestrand.no (Postfix) with ESMTP id 514B861BFB for ; Mon, 27 Oct 2003 12:58:25 +0100 (CET) Received: from dfnjgl21 (12-237-229-250.client.attbi.com[12.237.229.250]) by comcast.net (rwcrmhc12) with SMTP id <2003102711582301400nsntde> (Authid: sdawkins@comcast.net); Mon, 27 Oct 2003 11:58:23 +0000 Message-ID: <08fc01c39c81$a89d2110$0400a8c0@DFNJGL21> From: "Spencer Dawkins" To: , References: <222713495.1067204653@[192.168.1.49]> Date: Mon, 27 Oct 2003 05:58:38 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Subject: Re: IESG proposed statement on the IETF mission X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list Reply-To: Spencer Dawkins List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit ----- Original Message ----- From: "Harald Tveit Alvestrand" > > True. Nearly a year ago, we attempted to publish > draft-iesg-vendor-extensions, to describe these problems in more detail - > but we failed to get that finished. I should probably get out more, but I wasn't familiar with this draft. I see that version 00 was announced. It looks to have been discussed in a couple of posts on ccamp (and mpls? but I didn't look), and revectored onto the main IETF discussion list, where it was the subject of two posts. The draft says "The initial version of this document was put together by the IESG", suggesting that they were asking for input or other forms of help, but that didn't happen. (In your opinion:) Was this a case of insufficient agreement, or a case of insufficient cycles? Or something else? Spencer From problem-statement-bounces@alvestrand.no Mon Oct 27 10:49:10 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21100 for ; Mon, 27 Oct 2003 10:49:09 -0500 (EST) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id DB8EA61BFC; Mon, 27 Oct 2003 16:48:48 +0100 (CET) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from mtiwmhc13.worldnet.att.net (mtiwmhc13.worldnet.att.net [204.127.131.117]) by eikenes.alvestrand.no (Postfix) with ESMTP id 6861661B8F; Mon, 27 Oct 2003 16:48:46 +0100 (CET) Received: from bolaba (34.sanjose-01-02rs16rt.ca.dial-access.att.net[12.81.0.34]) by worldnet.att.net (mtiwmhc13) with SMTP id <2003102715484211300890r3e>; Mon, 27 Oct 2003 15:48:44 +0000 Message-ID: <027e01c39ca1$31452a70$010aff0a@bolaba> From: "todd glassey" To: "Harald Tveit Alvestrand" , "Christian Huitema" , , References: <222145117.1067204085@[192.168.1.49]> Date: Mon, 27 Oct 2003 06:15:43 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Subject: Re: Proposed statement quotes wrong numbers X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit Harald, ----- Original Message ----- From: "Harald Tveit Alvestrand" To: "Christian Huitema" ; ; Sent: Sunday, October 26, 2003 9:34 PM Subject: Re: Proposed statement quotes wrong numbers > Christian, > > thanks for the correction. > We can quibble about the exact dates for a while, but I've made the quip > quite a few times that the IETF has a fine scalable management structure, > which will scale all the way to 700 participants...... so I agree that > "order of magnitude" is a misnomer. > > We do, however, have trouble, even at our currently reduced size. > > Harald > > --On 23. oktober 2003 22:40 -0700 Christian Huitema > wrote: > > > The statement that you issued repeatedly mentions that the IETF rules > > and social contract were establish at a time when the IETF had 50 to 250 > > or 50 to 300 members. The obvious implication is that, since the > > attendance has grown by an order of magnitude, the rules have to change > > significantly. > > > > The problem is that the 50-300 numbers are wrong. The original rules of > > the IETF were indeed devised in 1986, when the IETF was just created and > > had maybe 30-50 members. However, the current rules were designed in > > 1992-1993, in large part because the IETF had outgrown the previous > > rules. If you look at http://www.ietf.org/meetings/past.meetings.html, > > you will see that the attendance then was in the 500-700 range. Dave > > Clark's statement was made during the 24th IETF, held July 13-17, 1992 > > in Cambridge, Massachusetts. There were 677 attendees. What was the attendance of the last meeting then? and also what then is the sum total of unique EMail Addresses in the Lists then too? I.e. what is the total size of the Vetting Community Resource that the IETF brings to the Party as an enterprise/org??? > > > > Since then, the IETF has grown, and then shrunk. The current size is > > about double the size of 1992. That is significant, but not quite an > > order of magnitude. > > > > -- Christian Huitema > > > > > > From problem-statement-bounces@alvestrand.no Mon Oct 27 12:08:00 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25485 for ; Mon, 27 Oct 2003 12:07:59 -0500 (EST) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 2365B61B91; Mon, 27 Oct 2003 18:07:40 +0100 (CET) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from ietf.org (odin.ietf.org [132.151.1.176]) by eikenes.alvestrand.no (Postfix) with ESMTP id 8CAD961B8F for ; Mon, 27 Oct 2003 18:07:38 +0100 (CET) Received: from tigger (scoya-desktop.cnri.reston.va.us [10.27.16.2]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA25431; Mon, 27 Oct 2003 12:07:24 -0500 (EST) Date: Mon, 27 Oct 2003 12:07:05 -0500 (Eastern Standard Time) From: Steve Coya To: todd glassey In-Reply-To: <027e01c39ca1$31452a70$010aff0a@bolaba> Message-ID: X-X-Sender: scoya@odin.cnri.reston.va.us MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: problem-statement@alvestrand.no Subject: Re: Proposed statement quotes wrong numbers X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no >>and also what then is the sum total of unique EMail Addresses in the >>Lists then too? Counting the number of "entries" in the email lists will NOT produce a count of IETF participants. Considering the IETF and IETF-Announce lists, a number of "entries" are, in fact, local exploders/redistributors, and knowing how many individuals receive a message is an exercise in futility. Note also that many opted to be removed from the lists, preferring to view the web page for the list. Steve From problem-statement-bounces@alvestrand.no Mon Oct 27 17:03:39 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18018 for ; Mon, 27 Oct 2003 17:03:38 -0500 (EST) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id A558B61BAD; Mon, 27 Oct 2003 23:03:18 +0100 (CET) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from mail4.microsoft.com (mail4.microsoft.com [131.107.3.122]) by eikenes.alvestrand.no (Postfix) with ESMTP id A302861B8D; Mon, 27 Oct 2003 23:03:16 +0100 (CET) Received: from inet-vrs-04.redmond.corp.microsoft.com ([157.54.8.149]) by mail4.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 27 Oct 2003 14:03:15 -0800 Received: from 157.54.8.155 by inet-vrs-04.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 27 Oct 2003 14:03:14 -0800 Received: from red-imc-02.redmond.corp.microsoft.com ([157.54.9.107]) by inet-hub-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 27 Oct 2003 14:03:05 -0800 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by red-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 27 Oct 2003 14:03:13 -0800 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Mon, 27 Oct 2003 14:03:04 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7097.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 27 Oct 2003 14:00:56 -0800 Message-ID: Thread-Topic: Proposed statement quotes wrong numbers thread-index: AcOcTAjU4nRN2fz/QF2A/BNNGoUZ4AAiStEg From: "Christian Huitema" To: "Harald Tveit Alvestrand" , , X-OriginalArrivalTime: 27 Oct 2003 22:03:04.0051 (UTC) FILETIME=[18436430:01C39CD6] Subject: RE: Proposed statement quotes wrong numbers X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: quoted-printable In fact, if you go back to the archives of the 1992 discussions, it was perceived then that the previous structure did not scale. For example, the IAB was in charge of reviewing every RFC before it could be published, and as the number of WG increased that became a bottleneck. A lot of the 1992 effort was about designing a structure that would scale better -- i.e. scale for much more than the 600-700 participants at the time. I am not sure that the IETF problems are primarily a scaling issue. > -----Original Message----- > From: Harald Tveit Alvestrand [mailto:harald@alvestrand.no] > Sent: Sunday, October 26, 2003 9:35 PM > To: Christian Huitema; ietf@ietf.org; problem-statement@alvestrand.no > Subject: Re: Proposed statement quotes wrong numbers >=20 > Christian, >=20 > thanks for the correction. > We can quibble about the exact dates for a while, but I've made the quip > quite a few times that the IETF has a fine scalable management structure, > which will scale all the way to 700 participants...... so I agree that > "order of magnitude" is a misnomer. >=20 > We do, however, have trouble, even at our currently reduced size. >=20 > Harald >=20 > --On 23. oktober 2003 22:40 -0700 Christian Huitema > wrote: >=20 > > The statement that you issued repeatedly mentions that the IETF rules > > and social contract were establish at a time when the IETF had 50 to 250 > > or 50 to 300 members. The obvious implication is that, since the > > attendance has grown by an order of magnitude, the rules have to change > > significantly. > > > > The problem is that the 50-300 numbers are wrong. The original rules of > > the IETF were indeed devised in 1986, when the IETF was just created and > > had maybe 30-50 members. However, the current rules were designed in > > 1992-1993, in large part because the IETF had outgrown the previous > > rules. If you look at http://www.ietf.org/meetings/past.meetings.html, > > you will see that the attendance then was in the 500-700 range. Dave > > Clark's statement was made during the 24th IETF, held July 13-17, 1992 > > in Cambridge, Massachusetts. There were 677 attendees. > > > > Since then, the IETF has grown, and then shrunk. The current size is > > about double the size of 1992. That is significant, but not quite an > > order of magnitude. > > > > -- Christian Huitema > > >=20 >=20 >=20 From problem-statement-bounces@alvestrand.no Mon Oct 27 19:19:04 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA00299 for ; Mon, 27 Oct 2003 19:19:03 -0500 (EST) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 2DA6A61BDF; Tue, 28 Oct 2003 01:18:44 +0100 (CET) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from mtiwmhc11.worldnet.att.net (mtiwmhc11.worldnet.att.net [204.127.131.115]) by eikenes.alvestrand.no (Postfix) with ESMTP id CDEF861BB5; Tue, 28 Oct 2003 01:18:40 +0100 (CET) Received: from bolaba (141.sanjose-05-10rs16rt.ca.dial-access.att.net[12.81.6.141]) by worldnet.att.net (mtiwmhc11) with SMTP id <2003102800183611100iehk9e>; Tue, 28 Oct 2003 00:18:38 +0000 Message-ID: <000701c39ce8$6917f7b0$010aff0a@bolaba> From: "todd glassey" To: "Harald Tveit Alvestrand" , , References: <222713495.1067204653@[192.168.1.49]> Date: Mon, 27 Oct 2003 15:56:34 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Subject: Re: IESG proposed statement on the IETF mission X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit Harald - I would agree that you are right here that the IETF's mission process and in fact operations have fluttered in the breeze but the breeze was caused by whoever was chair at the time's running by or away from the key issue that they as the chair were given the ability because of a very weak charter and very ambiguous processes (may instead of must everywhere) create whatever it is they wanted. The issue is that the wants and mandates of the chair's have changed over the years and so the IETF has changed in response to that. What that tends to indicate is that the IETF is responsive to changes in its management's desires but not in the proletariat's... So then what I suggest is the answer is a more rigidized standards process and in particular a set of unambiguous policies and procedures that are at least modeled if not tested before being released. And that are in and of themselves the same for all they are applied to or around. Todd Glassey ----- Original Message ----- From: "Harald Tveit Alvestrand" To: ; ; Sent: Sunday, October 26, 2003 9:44 PM Subject: RE: IESG proposed statement on the IETF mission > > > --On 24. oktober 2003 18:07 +0300 john.loughney@nokia.com wrote: > > > Hi Harald, > > > > I'm going to pick on one statement, which other have as well. > > > >> It is important that this is "For the Internet," and does not include > >> everything that happens to use IP. IP is being used in a myriad of > >> real-world applications, such as controlling street lights, but the > >> IETF does not standardize those applications. > > > > I almost feel that this should just be dropped from the statement. My > > reasons being that I have been told by the IESG about protocol > > extensibility is that the IETF wants to have a tighter control over > > protocol > > extensibility, even for extensions thought to be for limited use > > or specific networks (for example, cellular networks). The reason > > being is that once something is out there, it often starts to be used > > in ways which were not originally planned or used outside of its > > original 'limited use' plans. Therefore, in order to ensure proper > > protocol behavior & interoperability, the IESG wants to manage > > extensibility. This has been very true in SIP & Diameter, for example. > > True. Nearly a year ago, we attempted to publish > draft-iesg-vendor-extensions, to describe these problems in more detail - > but we failed to get that finished. > > > > On the other hand, we see a protocol like RADIUS, which the IETF > > has never done a good job at working with or standardizing, being > > developed in 4 or more SDOs, and not in a colaborative manner. This > > makes a big mess with the RADIUS spec, and RADIUS does seem like a > > protocol that has a big effect on the Internet. > > You'll have no disagreement from me that RADIUS is a problem! > > > So, in summary, the IESG has shown not to follow the above paragraph, > > sometimes even for good reasons. I can't think of a way in which > > modify the paragraph to make it any better - because there will always > > be examples of work that the IETF choses to standardize (or not) > > which will violate that part of the mission. Perhaps moving the > > 'for the internet to the previous paragraph is what is needed. > > as I've said before - I don't think we can come up with a mission statement > that retroactively blesses everything we've done well before, or > retroactively curses everything we've done badly. And we do require > flexibility to "do what's right". But without the ability to talk about > what the mission of the IETF ... I think we'll do badly. > > Harald > > From problem-statement-bounces@alvestrand.no Tue Oct 28 03:39:41 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA08946 for ; Tue, 28 Oct 2003 03:39:40 -0500 (EST) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 5D28C61BAC; Tue, 28 Oct 2003 09:39:19 +0100 (CET) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by eikenes.alvestrand.no (Postfix) with ESMTP id B10AF61B8D; Tue, 28 Oct 2003 09:39:16 +0100 (CET) Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id h9S8dFI20339; Tue, 28 Oct 2003 10:39:16 +0200 (EET) Received: from esebh004.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 28 Oct 2003 10:39:13 +0200 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Tue, 28 Oct 2003 10:39:13 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 28 Oct 2003 10:39:13 +0200 Message-ID: Thread-Topic: IESG proposed statement on the IETF mission Thread-Index: AcOcTV6CeIFNyCmlR3+M30EMD6JtkwA4UALA From: To: , , X-OriginalArrivalTime: 28 Oct 2003 08:39:13.0374 (UTC) FILETIME=[F6F3DFE0:01C39D2E] Subject: RE: IESG proposed statement on the IETF mission X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: quoted-printable Harald, > > > I almost feel that this should just be dropped from the statement. = My > > reasons being that I have been told by the IESG about protocol > > extensibility is that the IETF wants to have a tighter control over = protocol > > extensibility, even for extensions thought to be for limited use > > or specific networks (for example, cellular networks). The reason > > being is that once something is out there, it often starts to be = used > > in ways which were not originally planned or used outside of its > > original 'limited use' plans. Therefore, in order to ensure proper > > protocol behavior & interoperability, the IESG wants to manage > > extensibility. This has been very true in SIP & Diameter,=20 > > for example. >=20 > True. Nearly a year ago, we attempted to publish=20 > draft-iesg-vendor-extensions, to describe these problems in more = detail -=20 > but we failed to get that finished. So, I think we have to be careful about what we consider part of the IETF mission, if we cannot get basic agreement upon the implications of the mission statement. > > On the other hand, we see a protocol like RADIUS, which the IETF > > has never done a good job at working with or standardizing, being > > developed in 4 or more SDOs, and not in a colaborative manner. This > > makes a big mess with the RADIUS spec, and RADIUS does seem like a > > protocol that has a big effect on the Internet. >=20 > You'll have no disagreement from me that RADIUS is a problem! >=20 > > So, in summary, the IESG has shown not to follow the above = paragraph, > > sometimes even for good reasons. I can't think of a way in which > > modify the paragraph to make it any better - because there will = always > > be examples of work that the IETF choses to standardize (or not) > > which will violate that part of the mission. Perhaps moving the > > 'for the internet to the previous paragraph is what is needed. >=20 > as I've said before - I don't think we can come up with a mission = statement=20 > that retroactively blesses everything we've done well before, or=20 > retroactively curses everything we've done badly. And we do require=20 > flexibility to "do what's right". But without the ability to talk = about=20 > what the mission of the IETF ... I think we'll do badly. The past is the past, I don't want to revisit the past. What I want to do is to look forward. We should have flexibility in terms of how to decide what the IETF can do, what it can't do and what it should (or shouldn't do). I think we cannot make a blanket statement in the mission that covers this. thanks, John From problem-statement-bounces@alvestrand.no Tue Oct 28 05:00:02 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA13057 for ; Tue, 28 Oct 2003 05:00:01 -0500 (EST) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 04AD461B8D; Tue, 28 Oct 2003 10:59:41 +0100 (CET) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from postman.ripe.net (postman.ripe.net [193.0.0.199]) by eikenes.alvestrand.no (Postfix) with ESMTP id D0EA661B91; Tue, 28 Oct 2003 10:59:38 +0100 (CET) Received: by postman.ripe.net (Postfix, from userid 8) id 7EDC74EF2C; Tue, 28 Oct 2003 10:59:38 +0100 (CET) Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by postman.ripe.net (Postfix) with ESMTP id DC5A34EF08; Tue, 28 Oct 2003 10:59:37 +0100 (CET) Received: from x53.ripe.net (x53.ripe.net [193.0.1.53]) by birch.ripe.net (8.12.10/8.11.6) with ESMTP id h9S9xbHm017251; Tue, 28 Oct 2003 10:59:37 +0100 Date: Tue, 28 Oct 2003 10:59:37 +0100 (CET) From: Bruce Campbell X-X-Sender: bc@x53.ripe.net To: todd glassey In-Reply-To: <027e01c39ca1$31452a70$010aff0a@bolaba> Message-ID: References: <222145117.1067204085@[192.168.1.49]> <027e01c39ca1$31452a70$010aff0a@bolaba> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-RIPE-Spam-Status: N 0.499386 X-RIPE-Signature: 2036598cba69016b7157691c222971af Cc: Christian Huitema , Harald Tveit Alvestrand , ietf@ietf.org, problem-statement@alvestrand.no Subject: Re: Proposed statement quotes wrong numbers X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no On Mon, 27 Oct 2003, todd glassey wrote: > What was the attendance of the last meeting then? and also what then is the > sum total of unique EMail Addresses in the Lists then too? I.e. what is the > total size of the Vetting Community Resource that the IETF brings to the > Party as an enterprise/org??? Are you sure that you can count the (large) number of subscribers that are on the main IETF lists, and the umpteen WG lists, as participants? There seem to be a lot of people who are subscribed to various IETF-related lists who do not seem to participate in the IETF discussions. ( But theres still a lot more than just 700 people who participate in the IETF ) --==-- Bruce. From problem-statement-bounces@alvestrand.no Tue Oct 28 20:15:03 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA14011 for ; Tue, 28 Oct 2003 20:15:02 -0500 (EST) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 24AD561BB4; Wed, 29 Oct 2003 02:14:41 +0100 (CET) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from mtiwmhc13.worldnet.att.net (mtiwmhc13.worldnet.att.net [204.127.131.117]) by eikenes.alvestrand.no (Postfix) with ESMTP id 46DA861BAE; Wed, 29 Oct 2003 02:14:38 +0100 (CET) Received: from bolaba (209.sanjose-03-04rs16rt.ca.dial-access.att.net[12.81.1.209]) by worldnet.att.net (mtiwmhc13) with SMTP id <20031029011433113008c3tde>; Wed, 29 Oct 2003 01:14:35 +0000 Message-ID: <031a01c39db9$65a9c000$010aff0a@bolaba> From: "todd glassey" To: "Bruce Campbell" References: <222145117.1067204085@[192.168.1.49]> <027e01c39ca1$31452a70$010aff0a@bolaba> Date: Tue, 28 Oct 2003 17:09:12 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Cc: Christian Huitema , Harald Tveit Alvestrand , ietf@ietf.org, problem-statement@alvestrand.no Subject: Re: Proposed statement quotes wrong numbers X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit Bruce - ----- Original Message ----- From: "Bruce Campbell" To: "todd glassey" Cc: "Harald Tveit Alvestrand" ; "Christian Huitema" ; ; Sent: Tuesday, October 28, 2003 1:59 AM Subject: Re: Proposed statement quotes wrong numbers > On Mon, 27 Oct 2003, todd glassey wrote: > > > What was the attendance of the last meeting then? and also what then is the > > sum total of unique EMail Addresses in the Lists then too? I.e. what is the > > total size of the Vetting Community Resource that the IETF brings to the > > Party as an enterprise/org??? > > Are you sure that you can count the (large) number of subscribers that are > on the main IETF lists, and the umpteen WG lists, as participants? participants as far as meetings are concerned? no - obviously not, but this pool of good email addresses constitute the core value of the IETF, that being its Vettig Pool. So yes indeed, and also remember that the IETF is a voluntary particpation standards process and platform, and that the reliable email addresses for this "Vetting Pool" is what the core of the IETF's ideas are vetted against. So put on your "organizational leader's" hat and then ask me the same question - > There > seem to be a lot of people who are subscribed to various IETF-related > lists who do not seem to participate in the IETF discussions. But the point is that they have the option. Its their choice as to whether to participate of not. > > ( But theres still a lot more than just 700 people who participate in the > IETF ) I agree - so lets ask the question again, how many unique names are there in the lists - what's the total 'verified email addresses' that make up the total of the vetting pool? - 5000 - 10000 - 50000? what is it? Harald? - this seems like a number that you as the Chair of the IETF would not only be proud of, but would also have on the top of your head on a monthly basis... Any ideas as to the number? Todd > > --==-- > Bruce. From problem-statement-bounces@alvestrand.no Wed Oct 29 10:50:01 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15043 for ; Wed, 29 Oct 2003 10:50:00 -0500 (EST) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id C3D2161BFC; Wed, 29 Oct 2003 16:49:38 +0100 (CET) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from d12lmsgate.de.ibm.com (d12lmsgate-4.de.ibm.com [194.196.100.237]) by eikenes.alvestrand.no (Postfix) with ESMTP id C384061BD9; Wed, 29 Oct 2003 16:49:35 +0100 (CET) Received: from d12relay01.megacenter.de.ibm.com (d12relay01.megacenter.de.ibm.com [9.149.165.180]) by d12lmsgate.de.ibm.com (8.12.10/8.12.8) with ESMTP id h9TFnYo0025154; Wed, 29 Oct 2003 16:49:34 +0100 Received: from ochsehorn.zurich.ibm.com (ochsehorn.zurich.ibm.com [9.4.16.140]) by d12relay01.megacenter.de.ibm.com (8.12.9/NCO/VER6.6) with ESMTP id h9TFnTMt224328; Wed, 29 Oct 2003 16:49:29 +0100 Received: from zurich.ibm.com ([9.145.229.81]) by ochsehorn.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id QAA62472; Wed, 29 Oct 2003 16:49:26 +0100 Message-ID: <3F9FD90F.ADC56796@zurich.ibm.com> Date: Wed, 29 Oct 2003 16:13:20 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de MIME-Version: 1.0 To: Harald Tveit Alvestrand References: <157547561.1066175290@localhost> <20031015124837.79dbcd11.moore@cs.utk.edu> <3F8E8E4D.50A002D6@zurich.ibm.com> <19797377.1066650256@localhost> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: problem-statement@alvestrand.no Subject: Re: IESG proposed statement on the IETF mission X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit Harald Tveit Alvestrand wrote: > > --On 16. oktober 2003 14:25 +0200 Brian E Carpenter > wrote: ... > > What we also need in the mission statement is enough boundary-setting that > > we can relatively easily decide what fits into the "Applications" Area > > and whether the Sub-IP Area belonged here in the first place. (I put > > "Applications" in quotes because there isn't much in the Apps area that > > outsiders think of as applications.) > > Yes. Suggested text? (long pause due to day job) The IETF covers a wide range of technical areas and it is impossible to set fully objective boundaries that allow an algorithmic answer to the question whether a particular item is within the IETF's technical scope. However, it can be stated that IETF work items are always concerned with either the Internet Protocol layer itself (Layer 3 in the ISO/OSI Reference Model), with its management and routing, with transport protocols (Layer 4) that may seriously impact the correct functioning of the IP layer, or with direct uses of the transport layer that provide generic services. Security mechanisms for all of the above are also in scope. Transmission technologies below Layer 3, and upper layer protocols that are not generic in nature, are generally out of scope. Also, tightly integrated suites of generic upper layer protocols (for example, the Web Services protocols) may be more appropriately specified by a dedicated standards body. Hmm. Not perfect, but it's a start. Which list should we discuss this on? Brian From problem-statement-bounces@alvestrand.no Wed Oct 29 11:09:04 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16089 for ; Wed, 29 Oct 2003 11:09:03 -0500 (EST) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id E74C061BE3; Wed, 29 Oct 2003 17:08:42 +0100 (CET) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by eikenes.alvestrand.no (Postfix) with ESMTP id D6FD661AD5; Wed, 29 Oct 2003 17:08:39 +0100 (CET) Received: from cisco.com (sjc-vpn4-148.cisco.com [10.21.80.148]) by sj-core-4.cisco.com (8.12.6/8.12.6) with SMTP id h9TG8Zbd003158; Wed, 29 Oct 2003 08:08:36 -0800 (PST) Received: by cisco.com (sSMTP sendmail emulation); Wed, 29 Oct 2003 11:08:35 -0500 Date: Wed, 29 Oct 2003 11:08:35 -0500 From: Scott W Brim To: Brian E Carpenter Message-ID: <20031029160835.GV324@sbrim-w2k01> Mail-Followup-To: Scott W Brim , Brian E Carpenter , Harald Tveit Alvestrand , problem-statement@alvestrand.no References: <157547561.1066175290@localhost> <20031015124837.79dbcd11.moore@cs.utk.edu> <3F8E8E4D.50A002D6@zurich.ibm.com> <19797377.1066650256@localhost> <3F9FD90F.ADC56796@zurich.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3F9FD90F.ADC56796@zurich.ibm.com> User-Agent: Mutt/1.4.1i Cc: Harald Tveit Alvestrand , problem-statement@alvestrand.no Subject: Re: IESG proposed statement on the IETF mission X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no On Wed, Oct 29, 2003 04:13:20PM +0100, Brian E Carpenter allegedly wrote: > The IETF covers a wide range of technical areas and it is impossible > to set fully objective boundaries that allow an algorithmic answer to > the question whether a particular item is within the IETF's technical > scope. However, it can be stated that IETF work items are always > concerned with either the Internet Protocol layer itself (Layer 3 in > the ISO/OSI Reference Model), with its management and routing, with > transport protocols (Layer 4) that may seriously impact the correct > functioning of the IP layer, or with direct uses of the transport > layer that provide generic services. Security mechanisms for all of > the above are also in scope. > > Transmission technologies below Layer 3, and upper layer protocols > that are not generic in nature, are generally out of scope. Also, > tightly integrated suites of generic upper layer protocols (for > example, the Web Services protocols) may be more appropriately > specified by a dedicated standards body. Corollary: Anything that has to run everywhere IP runs. This pulls in protocols which need to establish state at every IP hop, not just waypoints (e.g. application proxies). The one that's on my mind is MPLS. From problem-statement-bounces@alvestrand.no Wed Oct 29 12:59:52 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23373 for ; Wed, 29 Oct 2003 12:59:51 -0500 (EST) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 0BE1261C05; Wed, 29 Oct 2003 18:59:31 +0100 (CET) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from mtiwmhc11.worldnet.att.net (mtiwmhc11.worldnet.att.net [204.127.131.115]) by eikenes.alvestrand.no (Postfix) with ESMTP id 906C661B90; Wed, 29 Oct 2003 18:59:28 +0100 (CET) Received: from bolaba (106.sanjose-11-12rs16rt.ca.dial-access.att.net[12.81.4.106]) by worldnet.att.net (mtiwmhc11) with SMTP id <2003102917592411100iu8g4e>; Wed, 29 Oct 2003 17:59:26 +0000 Message-ID: <051a01c39e45$c7bd7480$010aff0a@bolaba> From: "todd glassey" To: "Ray Plzak" , "'Bruce Campbell'" References: <00e901c39e04$87a633a0$728888c0@arin.net> Date: Wed, 29 Oct 2003 09:53:36 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Cc: "'Christian Huitema'" , "'Harald Tveit Alvestrand'" , ietf@ietf.org, problem-statement@alvestrand.no Subject: Re: Proposed statement quotes wrong numbers X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit Ray - the idea is that you don't need to - the purpose of the IETF as a standards development platform is to provide the "opportunity for participation" and not the "enforced mandatory participation" - after all the IETF is not a slave march (or is it :-) (Damn this is scary Harald - I am defending the IETF - what's wrong with this picture?)... Todd ----- Original Message ----- From: "Ray Plzak" To: "'Bruce Campbell'" ; "'todd glassey'" Cc: "'Harald Tveit Alvestrand'" ; "'Christian Huitema'" ; ; Sent: Wednesday, October 29, 2003 2:07 AM Subject: RE: Proposed statement quotes wrong numbers > > > > -----Original Message----- > > From: owner-ietf@ietf.org [mailto:owner-ietf@ietf.org] On > > Behalf Of Bruce Campbell > > Sent: Tuesday, October 28, 2003 5:00 AM > > To: todd glassey > > Cc: Harald Tveit Alvestrand; Christian Huitema; > > ietf@ietf.org; problem-statement@alvestrand.no > > Subject: Re: Proposed statement quotes wrong numbers > > > > > > ( But theres still a lot more than just 700 people who > > participate in the > > IETF ) > > > > --==-- > > Bruce. > > There are certainly more than 700 who attend. I don't know if you can > characterize them as all participating. > > Ray > > From problem-statement-bounces@alvestrand.no Wed Oct 29 13:12:43 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24268 for ; Wed, 29 Oct 2003 13:12:42 -0500 (EST) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id D5EFD61C01; Wed, 29 Oct 2003 19:12:21 +0100 (CET) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from mtiwmhc11.worldnet.att.net (mtiwmhc11.worldnet.att.net [204.127.131.115]) by eikenes.alvestrand.no (Postfix) with ESMTP id 2BDB361B90; Wed, 29 Oct 2003 19:12:19 +0100 (CET) Received: from bolaba (106.sanjose-11-12rs16rt.ca.dial-access.att.net[12.81.4.106]) by worldnet.att.net (mtiwmhc11) with SMTP id <2003102918121611100igegge>; Wed, 29 Oct 2003 18:12:17 +0000 Message-ID: <055001c39e47$93617450$010aff0a@bolaba> From: "todd glassey" To: "Scott W Brim" , "Brian E Carpenter" References: <157547561.1066175290@localhost><20031015124837.79dbcd11.moore@cs.utk.edu><3F8E8E4D.50A002D6@zurich.ibm.com> <19797377.1066650256@localhost><3F9FD90F.ADC56796@zurich.ibm.com> <20031029160835.GV324@sbrim-w2k01> Date: Wed, 29 Oct 2003 10:03:10 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Cc: Harald Tveit Alvestrand , problem-statement@alvestrand.no Subject: Re: IESG proposed statement on the IETF mission X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit ----- Original Message ----- From: "Scott W Brim" To: "Brian E Carpenter" Cc: "Harald Tveit Alvestrand" ; Sent: Wednesday, October 29, 2003 8:08 AM Subject: Re: IESG proposed statement on the IETF mission > On Wed, Oct 29, 2003 04:13:20PM +0100, Brian E Carpenter allegedly wrote: > > The IETF covers a wide range of technical areas and it is impossible > > to set fully objective boundaries that allow an algorithmic answer to > > the question whether a particular item is within the IETF's technical > > scope. However, it can be stated that IETF work items are always > > concerned with either the Internet Protocol layer itself (Layer 3 in > > the ISO/OSI Reference Model), with its management and routing, with > > transport protocols (Layer 4) that may seriously impact the correct > > functioning of the IP layer, or with direct uses of the transport > > layer that provide generic services. Security mechanisms for all of > > the above are also in scope. As are the critical audit and timestamping (the evidentiary processes) that document the functioning of the system. Generally these have been mashed into the "Security Stuff" listing but in many instances they should and are stand-alone feature-sets and technologies so... > > > > Transmission technologies below Layer 3, and upper layer protocols > > that are not generic in nature, are generally out of scope. Also, > > tightly integrated suites of generic upper layer protocols (for > > example, the Web Services protocols) may be more appropriately > > specified by a dedicated standards body. > > Corollary: Anything that has to run everywhere IP runs. This pulls in > protocols which need to establish state at every IP hop, not just > waypoints (e.g. application proxies). The one that's on my mind is > MPLS. From problem-statement-bounces@alvestrand.no Wed Oct 29 16:00:38 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05831 for ; Wed, 29 Oct 2003 16:00:37 -0500 (EST) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 46AB261BDA; Wed, 29 Oct 2003 22:00:16 +0100 (CET) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from smtp2.arin.net (smtp2.arin.net [192.149.252.32]) by eikenes.alvestrand.no (Postfix) with ESMTP id B7D5B61AD5; Wed, 29 Oct 2003 11:08:08 +0100 (CET) Received: by smtp2.arin.net (Postfix, from userid 5003) id D4DB06DD; Wed, 29 Oct 2003 05:08:05 -0500 (EST) Received: from ops.arin.net (ops [192.149.252.141]) by smtp2.arin.net (Postfix) with ESMTP id 6D70F2ED; Wed, 29 Oct 2003 05:08:05 -0500 (EST) Received: from ano2 ([192.136.136.114]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id FAA03558; Wed, 29 Oct 2003 05:08:02 -0500 (EST) From: "Ray Plzak" To: "'Bruce Campbell'" , "'todd glassey'" Date: Wed, 29 Oct 2003 05:07:54 -0500 Message-ID: <00e901c39e04$87a633a0$728888c0@arin.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal X-Spam-Status: No, hits=-0.3 required=5.0 tests=IN_REP_TO,SPAM_PHRASE_01_02 version=2.43-arin1 X-Mailman-Approved-At: Wed, 29 Oct 2003 22:00:14 +0100 Cc: "'Christian Huitema'" , "'Harald Tveit Alvestrand'" , ietf@ietf.org, problem-statement@alvestrand.no Subject: RE: Proposed statement quotes wrong numbers X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit > -----Original Message----- > From: owner-ietf@ietf.org [mailto:owner-ietf@ietf.org] On > Behalf Of Bruce Campbell > Sent: Tuesday, October 28, 2003 5:00 AM > To: todd glassey > Cc: Harald Tveit Alvestrand; Christian Huitema; > ietf@ietf.org; problem-statement@alvestrand.no > Subject: Re: Proposed statement quotes wrong numbers > > > ( But theres still a lot more than just 700 people who > participate in the > IETF ) > > --==-- > Bruce. There are certainly more than 700 who attend. I don't know if you can characterize them as all participating. Ray