Subject: RE: Where's the code (was: Input solicited: IETF problem pinpoint ing at the plenary?)

From: "Harrington, David" <[email-masked]>
Date: Wed, 30 Oct 2002 14:20:10 -0500

Hi,

If the WG needs to show interoperable implementations to progress from
Proposed to Draft Standard, I don't see how a submission can advance without
running code. Did you have some specific examples of standards-track
advancement without running code?

Are you suggesting that running code be a requirement to be met before a
document can be submitted to become a Proposed Standard? That would require
running code based in internet-drafts, and I wouldn't like that. The
Proposed Standard level was designed to provide a relatively stable
specification (WG agrees spec is acceptable) for implementation to develop
running code.

dbh
---
David Harrington            
[email-masked]           
co-chair, IETF SNMPv3 WG

> -----Original Message-----
> From: Kurt D. Zeilenga [mailto:[email-masked]]
> Sent: Wednesday, October 30, 2002 1:38 PM
> To: Harald Tveit Alvestrand
> Cc: [email-masked]
> Subject: Where's the code (was: Input solicited: IETF problem
> pinpointing at the plenary?)
> 
> 
> I wonder if anyone else has noticed the growing lack of
> "running code" associated with works being progressed on
> the Standard Track.  For every standard track submission,
> we need to ask "where's the code?" and, when the answer
> is "none (yet)", seriously doubt the appropriateness of
> progressing the work on the Standard Track.
> 
> Kurt
>

---

From: "James Luciani" <[email-masked]>
Date: Wed, 30 Oct 2002 14:32:27 -0500

RE: Where's the code (was: Input solicited: IETF problem pinpointing at the plenary?)The thought that you need running code before draft standard is one of those things where someone wants their cake and eat it too...  When packet formats change from rev to rev in a internet draft in an incompatible way, the theory is that it is no big deal because "if you are implementing a draft then caveat emptor... get over it!"  I certainly have heard this MANY times before...  what I am hearing here is a proposal for running code prior to being draft standard,i.e.,when the protocol is an internet draft.....  Hmmm....

----- Original Message ----- 
  From: Harrington, David 
  To: 'Kurt D. Zeilenga' ; Harald Tveit Alvestrand 
  Cc: [email-masked] 
  Sent: Wednesday, October 30, 2002 2:20 PM
  Subject: RE: Where's the code (was: Input solicited: IETF problem pinpointing at the plenary?)

  Hi, 

  If the WG needs to show interoperable implementations to progress from Proposed to Draft Standard, I don't see how a submission can advance without running code. Did you have some specific examples of standards-track advancement without running code?

  Are you suggesting that running code be a requirement to be met before a document can be submitted to become a Proposed Standard? That would require running code based in internet-drafts, and I wouldn't like that. The Proposed Standard level was designed to provide a relatively stable specification (WG agrees spec is acceptable) for implementation to develop running code.

  dbh 
  --- 
  David Harrington            
  [email-masked]           
  co-chair, IETF SNMPv3 WG

---

From: "James Luciani" <[email-masked]>
Date: Wed, 30 Oct 2002 15:11:16 -0500

:-) Have you looked at RFC2547?   Oh yeh... I mean 2547bis and the 10
supporting drafts.

----- Original Message -----
From: "Liming Wei" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>; <[email-masked]>;
<[email-masked]>
Sent: Wednesday, October 30, 2002 2:59 PM
Subject: Re: Where's the code (was: Input solicited: IETF problem
pinpointing at the plenary?)

> If a protocol is so unstable prior to being a draft standard,
> something is wrong with the standardization process.
>
> Has the time changed that the IETF now moves forward protocols based on
> time schedule, instead of the specification's maturity ?
>
> -Liming
> ---------
> > From: "James Luciani" <[email-masked]>
> >
> > RE: Where's the code (was: Input solicited: IETF problem pinpointing at
=
> > the plenary?)The thought that you need running code before draft =
> > standard is one of those things where someone wants their cake and eat =
> > it too...  When packet formats change from rev to rev in a internet =
> > draft in an incompatible way, the theory is that it is no big deal =
> > because "if you are implementing a draft then caveat emptor... get over
=
> > it!"  I certainly have heard this MANY times before...  what I am =
> > hearing here is a proposal for running code prior to being draft =
> > standard,i.e.,when the protocol is an internet draft.....  Hmmm....
> >
> > ----- Original Message -----=20
> >   From: Harrington, David=20
> >   To: 'Kurt D. Zeilenga' ; Harald Tveit Alvestrand=20
> >   Cc: [email-masked]=20
> >   Subject: RE: Where's the code (was: Input solicited: IETF problem =
> >   Hi,=20
=
> > Proposed to Draft Standard, I don't see how a submission can advance =
> > without running code. Did you have some specific examples of =
> > standards-track advancement without running code?
> >
> >   Are you suggesting that running code be a requirement to be met before
=
> > a document can be submitted to become a Proposed Standard? That would =
> > require running code based in internet-drafts, and I wouldn't like that.
=
> > The Proposed Standard level was designed to provide a relatively stable
=
> > specification (WG agrees spec is acceptable) for implementation to =
> > develop running code.
> >
> >   dbh=20
> >   ---=20
> >   David Harrington           =20
> >   [email-masked]          =20
> >   co-chair, IETF SNMPv3 WG=20
> >
> >
> >
> >   > -----Original Message-----=20
> >   > From: Kurt D. Zeilenga [mailto:[email-masked]]=20
> >   > Sent: Wednesday, October 30, 2002 1:38 PM=20
> >   > To: Harald Tveit Alvestrand=20
> >   > Cc: [email-masked]=20
> >   > Subject: Where's the code (was: Input solicited: IETF problem=20
> >   > pinpointing at the plenary?)=20
> >   >=20
> >   >=20
> >   > I wonder if anyone else has noticed the growing lack of=20
> >   > "running code" associated with works being progressed on=20
> >   > the Standard Track.  For every standard track submission,=20
> >   > we need to ask "where's the code?" and, when the answer=20
> >   > is "none (yet)", seriously doubt the appropriateness of=20
> >   > progressing the work on the Standard Track.=20
> >   >=20
> >   > Kurt=20
> >   >=20
> >
> >
> > ------=_NextPart_000_0179_01C28021.2B916460
> > Content-Type: text/html;
> > charset="iso-8859-1"
> > Content-Transfer-Encoding: quoted-printable
> >
> > <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
> > <HTML><HEAD><TITLE>RE: Where's the code (was: Input solicited: IETF =
> > problem pinpointing at the plenary?)</TITLE>
> > <META content=3D"text/html; charset=3Diso-8859-1" =
> > http-equiv=3DContent-Type>
> > <META content=3D"MSHTML 5.00.3504.2500" name=3DGENERATOR>
> > <STYLE></STYLE>
> > </HEAD>
> > <BODY bgColor=3D#ffffff>
> > <DIV><FONT face=3DArial size=3D2>The thought that you need running code
=
> > before draft=20
> > standard is one of those things where someone wants their cake and eat =
> > it=20
> > too...&nbsp; When packet formats change from rev to rev in&nbsp;a =
> > internet draft=20
> > in an incompatible way, the theory is that it is no big deal because "if
=
> > you are=20
> > implementing a draft then caveat emptor... get over it!"&nbsp; I =
> > certainly have=20
> > heard this MANY times before...&nbsp; what I am hearing here is&nbsp;a =
> > proposal=20
> > for running code prior to being draft standard,i.e.,when the protocol is
=
> > an=20
> > internet draft.....&nbsp; Hmmm....</FONT></DIV>
> > <DIV>&nbsp;</DIV>
> > <DIV>----- Original Message ----- </DIV>
> > <BLOCKQUOTE=20
> > style=3D"BORDER-LEFT: #000000 2px solid; MARGIN-LEFT: 5px; MARGIN-RIGHT:
=
> > 0px; PADDING-LEFT: 5px; PADDING-RIGHT: 0px">
> >   <DIV=20
> >   style=3D"BACKGROUND: #e4e4e4; FONT: 10pt arial; font-color: =
> > black"><B>From:</B>=20
> >   <A href=3D"mailto:[email-masked]" =
> > title=[email-masked]>Harrington,=20
> >   David</A> </DIV>
> >   <DIV style=3D"FONT: 10pt arial"><B>To:</B> <A =
> > href=3D"mailto:[email-masked]"=20
> >   title=[email-masked]>'Kurt D. Zeilenga'</A> ; <A=20
> >   href=3D"mailto:[email-masked]" =
> > title=[email-masked]>Harald Tveit=20
> >   Alvestrand</A> </DIV>
> >   <DIV style=3D"FONT: 10pt arial"><B>Cc:</B> <A =
> > href=3D"mailto:[email-masked]"=20
> >   title=[email-masked]>[email-masked]</A> </DIV>
> >   <DIV style=3D"FONT: 10pt arial"><B>Sent:</B> Wednesday, October 30, =
> > 2002 2:20=20
> >   PM</DIV>
> >   <DIV style=3D"FONT: 10pt arial"><B>Subject:</B> RE: Where's the code =
> > (was: Input=20
> >   solicited: IETF problem pinpointing at the plenary?)</DIV>
> >   <DIV><BR></DIV>
> >   <P><FONT size=3D2>Hi,</FONT> </P>
> >   <P><FONT size=3D2>If the WG needs to show interoperable =
> > implementations to=20
> >   progress from Proposed to Draft Standard, I don't see how a submission
=
> > can=20
> >   advance without running code. Did you have some specific examples
of=20
> >   standards-track advancement without running code?</FONT></P>
> >   <P><FONT size=3D2>Are you suggesting that running code be a =
> > requirement to be=20
> >   met before a document can be submitted to become a Proposed Standard?
=
> > That=20
> >   would require running code based in internet-drafts, and I wouldn't =
> > like that.=20
> >   The Proposed Standard level was designed to provide a relatively =
> > stable=20
> >   specification (WG agrees spec is acceptable) for implementation to =
> > develop=20
> >   running code.</FONT></P>
> >   <P><FONT size=3D2>dbh</FONT> <BR><FONT size=3D2>---</FONT> <BR><FONT =
> > size=3D2>David=20
> >   =
> >
Harrington&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
> > sp;=20
> >   </FONT><BR><FONT=20
> >   =
size=3D2>[email-masked]&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
> > ;&nbsp;&nbsp;=20
> >   </FONT><BR><FONT size=3D2>co-chair, IETF SNMPv3 WG</FONT> </P><BR>
> >   <P><FONT size=3D2>&gt; -----Original Message-----</FONT> <BR><FONT =
> > size=3D2>&gt;=20
> >   From: Kurt D. Zeilenga [<A=20
> >   href=3D"mailto:[email-masked]">mailto:[email-masked]</A>]</FONT>
=
> > <BR><FONT=20
> >   size=3D2>&gt; Sent: Wednesday, October 30, 2002 1:38 PM</FONT> =
> > <BR><FONT=20
> >   size=3D2>&gt; To: Harald Tveit Alvestrand</FONT> <BR><FONT =
> > size=3D2>&gt; Cc:=20
> >   [email-masked]</FONT> <BR><FONT size=3D2>&gt; Subject: Where's the
=
> > code (was:=20
> >   Input solicited: IETF problem</FONT> <BR><FONT size=3D2>&gt; =
> > pinpointing at the=20
> >   plenary?)</FONT> <BR><FONT size=3D2>&gt; </FONT><BR><FONT =
> > size=3D2>&gt;=20
> >   </FONT><BR><FONT size=3D2>&gt; I wonder if anyone else has noticed the
=
> > growing=20
> >   lack of</FONT> <BR><FONT size=3D2>&gt; "running code" associated with
=
> > works=20
> >   being progressed on</FONT> <BR><FONT size=3D2>&gt; the Standard =
> > Track.&nbsp; For=20
> >   every standard track submission,</FONT> <BR><FONT size=3D2>&gt; we =
> > need to ask=20
> >   "where's the code?" and, when the answer</FONT> <BR><FONT =
> > size=3D2>&gt; is "none=20
> >   (yet)", seriously doubt the appropriateness of</FONT> <BR><FONT =
> > size=3D2>&gt;=20
> >   progressing the work on the Standard Track.</FONT> <BR><FONT =
> > size=3D2>&gt;=20
> >   </FONT><BR><FONT size=3D2>&gt; Kurt</FONT> <BR><FONT size=3D2>&gt;=20
> > </FONT></P></BLOCKQUOTE></BODY></HTML>
> >
> > ------=_NextPart_000_0179_01C28021.2B916460--
> >

---

From: George Swallow <[email-masked]>
Date: Wed, 30 Oct 2002 15:59:32 -0500

Jim -

RFC2547 is informational.  2547bis is an ID.  What's your point?  That
the standards process is too slow to meet market demand?

...George

> > time schedule, instead of the specification's maturity ?

==================================================================
George Swallow       Cisco Systems                  (978) 497-8143
                     250 Apollo Drive
                     Chelmsford, Ma 01824

---

From: "James Luciani" <[email-masked]>
Date: Wed, 30 Oct 2002 16:07:42 -0500

George,
    You are actually partly right and partly wrong.   And my point was
bigger than the largely tongue in cheek example.   I don't think that we as
a community are following the rules that we set out for ourselves (notice I
did not say the IESG except in as much as they are part of the community).
So to say that the rules are broken seems strange to me.
--Jim
----- Original Message -----
From: "George Swallow" <[email-masked]>
To: "James Luciani" <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>; <[email-masked]>;
<[email-masked]>; <[email-masked]>; <[email-masked]>
Sent: Wednesday, October 30, 2002 3:59 PM
Subject: Re: Where's the code (was: Input solicited: IETF problem
pinpointing at the plenary?)

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Thu, 31 Oct 2002 06:51:17 +0800

this particular thread is probably a rathole, and we should claw back to 
the higher levels.....the identified problem is, I think, that we think 
there are cases where things go to Proposed Standard specifying things that 
can't work.
One way to avoid that is to insist that someone try it before submission.

Fair summary? Let's put that on the problem list.

--On 30. oktober 2002 14:32 -0500 James Luciani 
<[email-masked]> wrote:

>
> The thought that you need running code before draft standard is one of
> those things where someone wants their cake and eat it too...  When
> packet formats change from rev to rev in a internet draft in an
> incompatible way, the theory is that it is no big deal because "if you
> are implementing a draft then caveat emptor... get over it!"  I certainly
> have heard this MANY times before...  what I am hearing here is a
> proposal for running code prior to being draft standard,i.e.,when the
> protocol is an internet draft.....  Hmmm....

having tried to claw up, I can't resist the temptation to dig the rathole a 
bit deeper..... I remember in particular my experience from the MIXER wg 
(X.400/SMTP interworking), where we made a great number of things go into 
the standard without coding them first - but we knew, with a very large 
degree of certainty, that they were *implementable*, because they were 
really of the kind "if this field is 5, put "high" in that field" - it's 
obvious by inspection that you can do it, but it just takes quite a few 
man-hours to go through them all, and you don't want to use that until the 
document is stable.

OTOH, someone should REALLY have tried to code the notification conversion 
routines before submitting for Proposed, because they were more than a 
little convoluted, and might have been done differently.

I wouldn't want to insist that all the paper sizes in the IPP protocol be 
implemented in running code before submission either - but would very much 
like to see that someone had made a secure operation using the security 
primitives defined. (I think that someone did - Carl?)

So "running code" is different for different specs, and even for parts of 
the spec - no "one size fits all" rule seems to be right here.

My contribution to the rathole...

                     Harald

---

From: Frank Kastenholz <[email-masked]>
Date: Thu, 31 Oct 2002 08:59:31 -0500

At 06:51 AM 10/31/2002 +0800, Harald Tveit Alvestrand wrote:
>this particular thread is probably a rathole, and we should claw back to the higher levels.....the identified problem is, I think, that we think there are cases where things go to Proposed Standard specifying things that can't work.

How many instances have there been of a proposed standard specifying things
that can't work? Can you cite drafts? 

I'm not saying that this isn't a problem. I am saying that I don't know
if it's a problem or how big the problem is, so I'd like some numbers.

Frank Kastenholz

---

From: Margaret Wasserman <[email-masked]>
Date: Thu, 31 Oct 2002 09:40:01 -0500

I have an issue with the current IETF processes that I'm not sure
how to address...  This issue is mentioned in the PACT I-D, as
well.

What is supposed to happen when one WG is making architectural
decisions that will have a major impact on other groups/areas?
How does the process handle the problem of getting the WGs to
make good decisions for the whole IETF, and getting the whole
IETF (or major parts of it) signed-up to deal with the technical
implications of those decisions?

Let me give an example...  The IPv6 WG is defining a new version
of IP (hopefully this isn't a surprise to any of you :-)), and
clearly our decisions will have wide-ranging impact on most other
groups/areas within the IETF.  Some of these decisions will
actually have _more_ impact on protocols and implementations at
other layers than they do on the IP-layer itself, such as the
decisions we are making regarding scoped IPv6 addressing.

Waiting until documents are complete and sending them to the IESG
for review does not seem to be the best way to deal with this.  By
that time, a lot of effort has been invested based on the decisions
made by the WG, and the cost of changing them can be very high.
We need a mechanism to make _good_, _final_ architectural decisions
earlier in the process and know that we will have the buy-in of the
IETF to deal with the implications of those decisions.

How can we make that happen?

Margaret

---

From: Frank Kastenholz <[email-masked]>
Date: Thu, 31 Oct 2002 09:55:21 -0500

Historically, the chairs of the wg making those changes have
been charged with ensuring that the right transfer of
information occurs, with the IESG acting as a second line
of defense there.

Mechanisms range from going to another working group's chair
and saying "you should follow this stuff we're doing" to
making a presentation at an IETF plenary.

---

From: Rohan Mahy <[email-masked]>
Date: Thu, 31 Oct 2002 08:08:11 -0800

Hi,

I support the idea of making architectural decisions which effect a 
large portion of the community as early as we can do a good job of it.  
I can think of two mechanism we could use to make architectural 
"policy" decisions already, but I agree that it would be good to 
address more of these upfront.  Maybe we need a new mechanism, or maybe 
we can use one that exists.

The first way we do this now is that the IAB writes an ID and various 
people comment on it.  Depending on the relevance to various working 
groups, these issues could even get discussed in a WG that is 
especially effected, and we can pop out a nice shiny RFC that reflects 
this good architectural decision which resulted from the consensus of 
the part of the community that cared. IMO, this process is not working 
as well as I would like.  For example, when the IAB circulated the 
UNSAF considerations ID, several folks who participate in the MIDCOM 
working group made comments, but there was no *discussion* from the WG 
or the IAB.  I think there was a fair amount of apathy all around.

The second way is that folks propose a BOF on an architectural or 
policy topic.  I can think of two policy BOFs off the top of my head 
(ipr and nomcom), but I don't recall us using the BOF mechanism to 
solve a meta-level *architectural* problem recently that wasn't 
supposed to result in a WG or a protocol.

thoughts?

thanks,
-rohan

---

From: Melinda Shore <[email-masked]>
Date: Thu, 31 Oct 2002 11:59:12 -0500

> or the IAB.  I think there was a fair amount of apathy all around.

What I've run into in several working groups, including
midcom, is that the problem isn't just apathy but
additionally some level of antipathy.  I've particularly run
into this in discussions of interactions between routing and
"other stuff," for example QoS or middlebox location/
discovery.  The IAB considerations documents have proven to
be enormously useful and are welcomed by a subset of the
community, but there's another subset that considers it
irrelevant meddling and something to be responded to as a
process issue (what's the architectural considerations
equivalent to "Just use IPSec?") rather than something that
needs to be taken to heart.  With the growth of the IETF has
come an increasing number of participants who come from
backgrounds other than IP and feel that because a particular
approach works correctly in ATM networks or in the PSTN it
will work correctly over IP.  Some of them have proven to be
both loud and intransigent, so the problem becomes how to
get them more interested - and invested - in doing things in
a way that is idiomatic to IP than they are in sticking to
their guns.

I think Margaret's question is really about insularity, and
I suspect that's almost unavoidable given the large number
of working groups.  For example, there are voice-related
working group meetings during almost every session in
Atlanta.  How does that affect cross-fertilization, and how
does that limit the ability of voice people to participate
in other areas, on the one hand, or the ability of curious
but as-yet uninvolved people from other areas to get a
handle on what's going on in voice on the other?  

I tend to think that architecture BOFs would suffer from the
same problem and that people not involved with the area
being discussed would tend not to show up.  As I've said
before I'm not much of a fan of introducing more layers of
hierarchy, but perhaps something like the equivalent of a
directorate under the IAB might help.

Melinda