Re: what is a threat analysis?

[Steven M. Bellovin]

In message <[EMAIL PROTECTED]>, Dave Crocker writes:
>
>> Having a "threat analysis" was brought up at the plenary by Steve
>> Bellovin as being a Good Thing(tm). At the MASS/DKIM BOF we are
>> being required to produce such a thing as a prerequisite to even
>> getting chartered as a working group. The problem that I have (and
>> Dave Crocker at the plenary) is that there doesn't seem to be
>> any definition of what a "threat analysis" is. 
>
>As I posted on the DKIM mailing list on Monday 
> our AD, Russ 
>Housely has provided us with a rather straight-forward, 3-question template 
>for discussing DKIM's threat analysis:
>
>   * Who are the bad actors?
>   * Where do they fit into the protocol environment (eg, middle of net)?
>   * What are we trying to prevent them from doing?
>
>I think Russ' list is quite reasonable and he has been clear as to the reason 
>he views the development of the threat analysis (TA) as a pre-requisite. 

The only thing I'd add is a clarification of the first point: are they 
on links, on nodes, or both?  One of the points of my talk is that in 
multiparty protocols, you don't know who runs remote protocol 
participants, even in the absence of hacking.  

--Steven M. Bellovin, http://www.cs.columbia.edu/~smb



___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: what is a threat analysis?

[David Hopwood]

Bruce Lilly wrote:

Date: 2005-08-10 15:41
From: Michael Thomas <[EMAIL PROTECTED]>



Having a "threat analysis" was brought up at the plenary by Steve
Bellovin as being a Good Thing(tm).


[...]


So, if this is going to be yet another hoop that the IESG and IAB
sends working groups through like problem statements, requirements
documents and the like, I think it ought to be incumbent on
those people demanding such things to actually both agree and
document what it is that they are demanding.


See FYI 36 (a.k.a. RFC 2828) for the definition of threat analysis.


   $ threat analysis
  (I) An analysis of the probability of occurrences and consequences
  of damaging actions to a system.

(That's the whole of the definition.)

This is not a property of a protocol (or of anything that the IETF
standardizes). It depends on how people will use the protocol, and how
attackers will respond to that use, which is *always* unknown at the
time when threat analyses are typically asked for. Indeed, if it were
possible to give an accurate assessment of "the probability of occurrences
and consequences of damaging actions to a system", it would probably be
only because the thing being proposed has a very narrow range of
applicability.


RFC 3552, "Guidelines for Writing RFC Text on Security Considerations",
may also be helpful (although it does not use the exact term "threat
analysis").  All RFCs must contain a Security Considerations section
(RFC 2223, section 9).


That RFC indeed has some very sensible discussion of threat models (not
the same thing as a threat analysis by the RFC 2828 definition). What it
says is:

   The Internet environment has a fairly well understood threat model.
   In general, we assume that the end-systems engaging in a protocol
   exchange have not themselves been compromised.  Protecting against an
   attack when one of the end-systems has been compromised is
   extraordinarily difficult.  It is, however, possible to design
   protocols which minimize the extent of the damage done under these
   circumstances.

   By contrast, we assume that the attacker has nearly complete control
   of the communications channel over which the end-systems communicate.
   This means that the attacker can read any PDU (Protocol Data Unit) on
   the network and undetectably remove, change, or inject forged packets
   onto the wire.  This includes being able to generate packets that
   appear to be from a trusted machine.  Thus, even if the end-system
   with which you wish to communicate is itself secure, the Internet
   environment provides no assurance that packets which claim to be from
   that system in fact are.

and later it also mentions replay attacks, man-in-the-middle, etc.

IOW, the threat model is much the same for all Internet protocols. Of course,
it's possible that a particular protocol may raise additional issues (for
example, the possibility of conspiring users being able to break a security
protocol, or reliance on a trusted party that would be a single point of
failure). But I agree with the thrust of Michael Thomas' point: it often
isn't clear what people who ask for a threat analysis are really asking to
be stated that isn't already obvious.

> At the MASS/DKIM BOF we are being required to produce such a thing as a
> prerequisite to even getting chartered as a working group.

A more pertinent request at that stage might be, "Please clarify the security
requirements for this protocol." IOW, what is the protocol supposed to
enforce or protect, under the assumption that it will be used in the Internet
environment with the "fairly well understood threat model" described above?

--
David Hopwood <[EMAIL PROTECTED]>


___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: what is a threat analysis?

[Stephen Kent]

Dave & Michael,

In the DoD environment, a threat analysis for a system identifies the 
classes of adversaries that the author believes are of concern, and 
describes their capabilities and motivations. Russ's three questions 
are a concise way of stating this:

- The "bad actors" are adversaries.
	- Their capabilities allude to where the adversaries "fit 
into the system" and what sorts of attacks they may employ of effect 
their goals.
	- Their motivations indicate what they are trying to do, the 
flip side of "what are we trying to prevent them from doing."



The term is often used more broadly in the commercial world today, 
encompassing activities that might be better termed "threat 
assessment" "risk analysis" etc.


Steve

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: what is a threat analysis?

[Dave Crocker]

Having a "threat analysis" was brought up at the plenary by Steve
Bellovin as being a Good Thing(tm). At the MASS/DKIM BOF we are
being required to produce such a thing as a prerequisite to even
getting chartered as a working group. The problem that I have (and
Dave Crocker at the plenary) is that there doesn't seem to be
any definition of what a "threat analysis" is. 


As I posted on the DKIM mailing list on Monday 
 our AD, Russ 
Housely has provided us with a rather straight-forward, 3-question template 
for discussing DKIM's threat analysis:


  * Who are the bad actors?
  * Where do they fit into the protocol environment (eg, middle of net)?
  * What are we trying to prevent them from doing?

I think Russ' list is quite reasonable and he has been clear as to the reason 
he views the development of the threat analysis (TA) as a pre-requisite. 
Further, given the history both of previous anti-spam standards efforts and 
previous IETF security efforts, I am hard-pressed to disagree with him.  It's 
a pain in the ass to have to develop this stuff prior to chartering, but the 
project manager in me knows it will be Very Good Thing for ensuring coherence 
and focus of the effort.


(In fact my own real concern about the TA requirement is noting how little 
followup there has been on the DKIM list, since my original posting there, 48 
hours ago. Some folks are having great fun, there, debating other details 
about DKIM concepts and DKIM documentation, but there has been essentially no 
followup on threat analysis.)


At any rate, my point at the plenary was a concern that the Security 
community, itself, does not yet appear to have adequate consensus description 
of, and requirements for, TA to give the rest of us consistent guidance. From 
what I have seen over the years, the requirement for doing a TA up-front, in 
the IETF, is recent.  So it is not surprising that the method of doing it is 
unfamiliar to the rest of us.




So, if this is going to be yet another hoop that the IESG and IAB
sends working groups through like problem statements, requirements
documents and the like, I think it ought to be incumbent on


No question about it.  Recruiting a larger community to support an effort 
certainly involves tasks that aren't fun.  Especially since it should be so 
obvious why the effort is wonderful...


In any event, Russ has been clear and consistent.  Although general discussion 
about threat analysis shows community variations, the DKIM effort has not 
(yet) been given inconsistent guidance (that I am aware of.)


d/

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: what is a threat analysis?

[Bruce Lilly]

>  Date: 2005-08-10 15:41
>  From: Michael Thomas <[EMAIL PROTECTED]>

> Having a "threat analysis" was brought up at the plenary by Steve
> Bellovin as being a Good Thing(tm).
[...]
> So, if this is going to be yet another hoop that the IESG and IAB
> sends working groups through like problem statements, requirements
> documents and the like, I think it ought to be incumbent on
> those people demanding such things to actually both agree and
> document what it is that they are demanding.

See FYI 36 (a.k.a. RFC 2828) for the definition of threat analysis.

RFC 3552, "Guidelines for Writing RFC Text on Security Considerations",
may also be helpful (although it does not use the exact term "threat
analysis").  All RFCs must contain a Security Considerations section
(RFC 2223, section 9).

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Cautionary tale: Paris pickpockets

[Dave Singer]

At 12:55  -0700 10/08/05, Dave Crocker wrote:

 > he said I'd be crazy

to have my wallet in the backpocket and urged me to put it somewhere
inside my jacket because that would be much more difficult to get.


when my wallet was lifted, 2 months ago in the Paris metro, it was 
in my front left pocket.


"much more difficult" is simply not correct.


I travel a lot.  In cities where worry is appropriate (Paris, Rome 
and quite a few others), I chain the wallet to the bottom of the 
pocket.  Go to local hardware store, get two feet of 'sink plug' 
chain (the stuff that look like balls joined together), and an eyelet 
for each end, and a small key-ring clip, and a safety pin.  Attach 
eyelet + safety pin to bottom of pocket, eyelet + clip to wallet. 
The chain is heavy and flexible enough that it naturally snakes into 
the pocket, and the whole solution costs maybe $5.  Yes, it's easy to 
cut, but most pickpockets don't have time for scissors or cutters or 
hassle.

--
David Singer
Apple Computer/QuickTime

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

what is a threat analysis?

[Michael Thomas]

Having a "threat analysis" was brought up at the plenary by Steve
Bellovin as being a Good Thing(tm). At the MASS/DKIM BOF we are
being required to produce such a thing as a prerequisite to even
getting chartered as a working group. The problem that I have (and
Dave Crocker at the plenary) is that there doesn't seem to be
any definition of what a "threat analysis" is. Contrary to what
it seems many people demanding such a thing suppose, the term
isn't self evident. Maybe I've missed it but I'm not sure that
I've ever seen one. Worse, I'm not very sure that the people who
were telling us that we needed one could easily be able to come to
consensus on what constitutes a threat analysis.

So, if this is going to be yet another hoop that the IESG and IAB
sends working groups through like problem statements, requirements
documents and the like, I think it ought to be incumbent on
those people demanding such things to actually both agree and
document what it is that they are demanding. This is not just
annoyance at yet more process on my part, but a real desire to
not have people waste a lot of time producing documents that
fail to meet a definition that is otherwise only determined by
multiple iterations of "that's not what we want". This is, in
fact, what happened this time around, and has happened in the
past with the SIP wg.

Mike

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Cautionary tale: Paris pickpockets

[Hadmut Danisch]

On Wed, Aug 10, 2005 at 12:55:42PM -0700, Dave Crocker wrote:
> 
> when my wallet was lifted, 2 months ago in the Paris metro, it was in my 
> front left pocket.
> 
> "much more difficult" is simply not correct.


I am not that experienced in that kind of security business.


Book reference:


Bambi Vincent and Bob Arno
Travel Advisory!
How to Avoid Thefts, Cons, and Street Scams While Travelling
Bonus Books, Chicago


Hadmut


___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Cautionary tale: Paris pickpockets

[Dave Crocker]

> he said I'd be crazy

to have my wallet in the backpocket and urged me to put it somewhere
inside my jacket because that would be much more difficult to get. 


when my wallet was lifted, 2 months ago in the Paris metro, it was in my front 
left pocket.


"much more difficult" is simply not correct.


___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Last Call: 'Internet Code Point Assignments' to Proposed Standard

[Pekka Savola]

On Wed, 10 Aug 2005, The IESG wrote:

The IESG has received a request from an individual submitter to consider the
following document:

- 'Internet Code Point Assignments '
   as a Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.  Please send any comments to the
iesg@ietf.org or ietf@ietf.org mailing lists by 2005-09-07.

The file can be obtained via
http://www.ietf.org/internet-drafts/draft-gray-rfc1888bis-01.txt


The title is inappropriately generic.

Given RFC 4048, is there sufficient evidence that this would be useful 
to the operational (or any other) community ?


(Being more explicit on this draft's relationship to RFC 1888 and 4048 
would not hurt in general.)


--
Pekka Savola "You each name yourselves king, yet the
Netcore Oykingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Why have we gotten away from running code?

[Henning Schulzrinne]

The next SIPit event is in about a month; see http://www.sipit.net/

There was a GIMPS (now GIST) + NSIS NSLP interop event just before the 
IETF meeting (pre-RFC).


I wish there were more, but there are some.

C Wegrzyn wrote:

Perhaps they are more "regionalized". I know there are some "labs" like
at the UNH that hold them but the attendance isn't nearly as universal
as they once were.

As for statistics, no I don't have any. But I bet there aren't any more
-- in fact -- I would bet there are a lot less. I can't remember the
last SIP bake-off...

Chuck


___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Why have we gotten away from running code?

[Dave Singer]

Don't forget the organizations that adopt IETF specs.  ISMA has a 
regular interop and conformance program for RTSP + RTP + the codecs 
used, both 'virtual' over the internet and face to face at most 
meetings.  Likewise IMTC does testing of 3GPP SA4 multimedia specs, 
again using RTSP, RTP, codecs etc.  I'm sure there are more.


Not that I am opposed to running code, sample code, or more IETF 
bake-offs, mind you.  Just that the number of organizations filling 
the glass is more than it used to be.




At 15:12  -0400 10/08/05, C Wegrzyn wrote:

Perhaps they are more "regionalized". I know there are some "labs" like
at the UNH that hold them but the attendance isn't nearly as universal
as they once were.

As for statistics, no I don't have any. But I bet there aren't any more
-- in fact -- I would bet there are a lot less. I can't remember the
last SIP bake-off...

Chuck

Jari Arkko wrote:


 C Wegrzyn wrote:


 Hey, we not only had code that ran we also had "bake-offs" to make sure
 all the stuff worked together. The idea was to work out the nuances (the
 20% of the inaccuracies) and produce a damn good system. Today the idea
 is to slap something together - damn the interop - and get out the door
 for the "first mover advantage."  We also tend to not worry about the
 experience of the user - we expect them to understand our "Gold" is more
 like fool's gold than a well thought out and tested system.



 We still have bakeoffs. Or do you have some statistics that
 show we have now less bakeoffs per RFC than we used to,
 or that the bakeoffs are later than they used to be? ("We"
 here is the internet community, the IETF doesn't hold
 bakeoffs.)

 --Jari







--
David Singer
Apple Computer/QuickTime

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Why have we gotten away from running code?

[C Wegrzyn]

Perhaps they are more "regionalized". I know there are some "labs" like
at the UNH that hold them but the attendance isn't nearly as universal
as they once were.

As for statistics, no I don't have any. But I bet there aren't any more
-- in fact -- I would bet there are a lot less. I can't remember the
last SIP bake-off...

Chuck

Jari Arkko wrote:

> C Wegrzyn wrote:
>
>> Hey, we not only had code that ran we also had "bake-offs" to make sure
>> all the stuff worked together. The idea was to work out the nuances (the
>> 20% of the inaccuracies) and produce a damn good system. Today the idea
>> is to slap something together - damn the interop - and get out the door
>> for the "first mover advantage."  We also tend to not worry about the
>> experience of the user - we expect them to understand our "Gold" is more
>> like fool's gold than a well thought out and tested system.
>>  
>>
> We still have bakeoffs. Or do you have some statistics that
> show we have now less bakeoffs per RFC than we used to,
> or that the bakeoffs are later than they used to be? ("We"
> here is the internet community, the IETF doesn't hold
> bakeoffs.)
>
> --Jari
>
>
>
>


___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Why have we gotten away from running code?

[Jari Arkko]

C Wegrzyn wrote:


Hey, we not only had code that ran we also had "bake-offs" to make sure
all the stuff worked together. The idea was to work out the nuances (the
20% of the inaccuracies) and produce a damn good system. Today the idea
is to slap something together - damn the interop - and get out the door
for the "first mover advantage."  We also tend to not worry about the
experience of the user - we expect them to understand our "Gold" is more
like fool's gold than a well thought out and tested system.
 


We still have bakeoffs. Or do you have some statistics that
show we have now less bakeoffs per RFC than we used to,
or that the bakeoffs are later than they used to be? ("We"
here is the internet community, the IETF doesn't hold
bakeoffs.)

--Jari



___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Why have we gotten away from running code?

[C Wegrzyn]

>From my experience over the last 25 years I have seen the number go from
almost all "academics" (and some truly impressive geeks) to more a mix
like OSI The people that attend are there to represent the position of
their management (or manager) and their companies not look for the best
solution. The idea behind the code was that it would help flush away bad
ideas and help tighten up the language in the RFCs.

Hey, we not only had code that ran we also had "bake-offs" to make sure
all the stuff worked together. The idea was to work out the nuances (the
20% of the inaccuracies) and produce a damn good system. Today the idea
is to slap something together - damn the interop - and get out the door
for the "first mover advantage."  We also tend to not worry about the
experience of the user - we expect them to understand our "Gold" is more
like fool's gold than a well thought out and tested system.

Chuck


Dave Singer wrote:

> I hear the opposite complaint enough to believe that the truth lies
> somewhere in between ("the ietf is dominated by academics who have no
> idea what it takes to design, deploy, and maintain large complex
> networks").  I only see a tiny portion of the ietf myself, agreed (I
> doubt many people see much more as it is so large), but I don't see
> reason to be excessively pejorative about the attendance I see.  It's
> mixed;  academics, industrial engineers, writers, thinkers,
> implementers, observers, dilettantes, all mixed in.  Just like other
> standards orgs.
>
>
>
> At 18:36  +0200 10/08/05, Simon Josefsson wrote:
>
>> I think that is a good point.  A variation on that theme is that the
>> IETF is no longer run by people who actually implement protocols.  The
>> relevance and impact of the IETF on what is actually used on the
>> Internet is marginalized through that change of membership.  The
>> attitude of "That is not how we do things in the IETF" make people go
>> away.
>>
>> Cheers,
>> Simon
>>
>> C Wegrzyn <[EMAIL PROTECTED]> writes:
>>
>>>  I think a big part of the issue is that the IETF has been taken over
>>>  little by little by corporate interests. Before it used to be for the
>>
>>  > "love of doing it". Today it is more for "the benefit of one".
>
>
>


___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Myths of the IESG: Reading documents is the problem

[Spencer Dawkins]

Dear All,

I don't mean to chime in here, but if we can agree that nobody is asking 
ADs to be only process mavens, and nobody is asking ADs to refrain from 
making technical contributions, we could probably make some progress.


I've worked for plenty of managers with technical skills. Some were 
coinventors on patent applications. We still did a budget every year, 
and we still had a plan with milestones that we worked to meet. Whatever 
else the Manager of an IETF Area does, they need to at least manage the 
working groups in that area - that's how I read 2026/2418.


Spencer, who is NOT planning to propose a terminology change to call 
them "Pointy-Haired Area Directors"...


Dave Crocker wrote:


HOWEVER, it does seem that you seem to believe that the _primary_
responsibility of an AD is as a project manager and a process
manager/cop.  



Yes...

RFC 2026, The Internet Standards Process -- Revision 3:


14. DEFINITIONS OF TERMS


...


   Area Director - The manager of an IETF Area.  The Area Directors
  along with the IETF Chair comprise the Internet Engineering
  Steering Group (IESG).



Hmmm.  Manager.

And the label is used alone.  No other descriptive word is used.  
Nothing about technical contribution.



RFC 2418, IETF Working Group Guidelines and Procedures:


6.7. Area Director

   Area Directors are responsible for ensuring that working groups in
   their area produce coherent, coordinated, architecturally consistent
   and timely output as a contribution to the overall results of the
   IETF.



"Coherent, coordinated and timely" are explicitly management tasks.  
As i noted about Steve Bellovin's AAA reference, there is a strong 
component of "architecturally consistent" that also is management, 
when the task is done properly in the way he described.




___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Why have we gotten away from running code?

[Lakshminath Dondeti]

My experience has been that implementations help improve the quality of 
the specifications, and formal security analyses help fix design 
errors.  I implemented two recent SEC area protocols, but unfortunately 
in both cases, my implementations were partial (due to lack of time, 
interest etc.,), and it appears that others' implementations were too 
(at least at the time we interoperated).  The other thing is that my 
counterparts and I were privy to some or all of the behind the scenes 
information.


The security analyses I am aware of (thanks to Cathy Meadows :-)) helped 
revise what is now RFC 3547 (and Russ H mentioned another example at the 
SAAG meeting in Paris).


The conclusion I draw is that a formal security analysis (or even 
protocol analysis) is very helpful once the protocol design has been 
completed to identify any errors, and implementations (preferably full 
implementations) would help improve the readability of specs (and that 
would happen if the implementer is basing the implementation only on a 
given I-D, and not on the history of it or behind the scenes info).  
Perhaps it might be worthwhile to identify "problem areas" in a spec and 
try and implement those parts to figure out whether we got them right.


best regards,
Lakshminath

Iljitsch van Beijnum wrote:


On 7-aug-2005, at 1:07, Brian Rosen wrote:


I notice that we have stopped being interested in running code.




I think that is to our community's detriment.



[...]


Probably more importantly, I think we should be VERY suspicious of  new,
complex specifications before we have running code.



I've been thinking about this on and off for a day, and I'm not  
convinced that having running code at the time a specification is  
first fleshed out would be all that helpful.


Can you point to any instance in recent IETF history (after 1995 or  
2000 or so) where having having running code early in the process  
would have made for a better _designed_ protocol?


Sure, trying to implement something brings out bugs in the  
specification, but those are usually relatively minor things that  
don't go to the design of the protocol. And wide deployment generally  
shows that a protocol could have been better in one regard or  
another, and that some parts of it don't turn out to be useful in  
practice.


However, waiting for implementations on account of the former only  
delays having a fixed spec even longer (we already see protocols  
_deployed_ before there is an RFC, which is very harmful IMO) while  
waiting for the latter leads to insanity such as RFC 1771 being stuck  
at "draft standard" even though it has dozens of interoperable  
implementations, a decade of operational experience and there  
wouldn't be an internet without it.


___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Why have we gotten away from running code?

[Marc Manthey]

On Aug 10, 2005, at 6:36 PM, Simon Josefsson wrote:


I think that is a good point.  A variation on that theme is that the
IETF is no longer run by people who actually implement protocols.  The
relevance and impact of the IETF on what is actually used on the
Internet is marginalized through that change of membership.  The
attitude of "That is not how we do things in the IETF" make people go
away.

Cheers,
Simon


hell o  , yes it is,

simon , all , see i am the  oppossite, a  i highly motivated  
undergraduated citizen.
with no money But i learn a lot in the last 2 year only by  reading  
lists and try to understand
what the real problem is or could be. I can´t do a lot,  just raise  
an issue

or have a meaning. But its  fantastic  to be  part of the whole thing.

just my 2 cents

marcM.

from old  germany;-P


C Wegrzyn <[EMAIL PROTECTED]> writes:


I think a big part of the issue is that the IETF has been taken over
little by little by corporate interests. Before it used to be for the
"love of doing it". Today it is more for "the benefit of one".

Chuck Wegrzyn

Marc Manthey wrote:


morning  experts,


(Note that I haven't implemented any IETF protocols myself, but I
did once do an implementation of a badly designed protocol.)



a, is this why  you think that there is  no need  for any  
new  or

old protocol at all ?

--
" The mind, once expanded to the dimensions of larger ideas,  never   
returns to its original size."


Les Enfants Terribles
www.let.de




smime.p7s
Description: S/MIME cryptographic signature
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Why have we gotten away from running code?

[Dave Singer]

I hear the opposite complaint enough to believe that the truth lies 
somewhere in between ("the ietf is dominated by academics who have no 
idea what it takes to design, deploy, and maintain large complex 
networks").  I only see a tiny portion of the ietf myself, agreed (I 
doubt many people see much more as it is so large), but I don't see 
reason to be excessively pejorative about the attendance I see.  It's 
mixed;  academics, industrial engineers, writers, thinkers, 
implementers, observers, dilettantes, all mixed in.  Just like other 
standards orgs.




At 18:36  +0200 10/08/05, Simon Josefsson wrote:

I think that is a good point.  A variation on that theme is that the
IETF is no longer run by people who actually implement protocols.  The
relevance and impact of the IETF on what is actually used on the
Internet is marginalized through that change of membership.  The
attitude of "That is not how we do things in the IETF" make people go
away.

Cheers,
Simon

C Wegrzyn <[EMAIL PROTECTED]> writes:


 I think a big part of the issue is that the IETF has been taken over
 little by little by corporate interests. Before it used to be for the

 > "love of doing it". Today it is more for "the benefit of one".



--
David Singer
Apple Computer/QuickTime

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Myths of the IESG: Reading documents is the problem

[Dave Crocker]

HOWEVER, it does seem that you seem to believe that the _primary_
responsibility of an AD is as a project manager and a process
manager/cop.  


Yes...

RFC 2026, The Internet Standards Process -- Revision 3:

14. DEFINITIONS OF TERMS

...

   Area Director - The manager of an IETF Area.  The Area Directors
  along with the IETF Chair comprise the Internet Engineering
  Steering Group (IESG).


Hmmm.  Manager.

And the label is used alone.  No other descriptive word is used.  Nothing 
about technical contribution.



RFC 2418, IETF Working Group Guidelines and Procedures:

6.7. Area Director

   Area Directors are responsible for ensuring that working groups in
   their area produce coherent, coordinated, architecturally consistent
   and timely output as a contribution to the overall results of the
   IETF.


"Coherent, coordinated and timely" are explicitly management tasks.  As i 
noted about Steve Bellovin's AAA reference, there is a strong component of 
"architecturally consistent" that also is management, when the task is done 
properly in the way he described.




If that is the case, then it may be that it may be very difficult to
find volunteers willing to do what is, quite frankly, scut work. 


There was no difficulty finding volunteers when area directors had literally 
NO authority, pre-Kobe.


I guess the quality of AD was lower then, as was the quality of IETF output. 
In terms of sampling, clearly such people are no longer prevalent in the IETF...




So if we do that, it may make sense to make the job of being a project
manager and process maven to be that of a staff position.


Yes, it is appealing to believe that the task can be routinized to be 
performed by someone with no knowledge of the technical specialties.


But it can't.



If that's not what you wanted to advocate, perhaps it would be helpful
if you were to offer some concrete examples of what would be part of
the AD's job in your ideal universe, and what would _not_ be part of


And here's where my frustration kicks in, since I have posted concrete 
examples pretty constantly over the last 3 years.  And, no, I'm not going to 
retrieve them from the archive.


d/

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Why have we gotten away from running code?

[Simon Josefsson]

I think that is a good point.  A variation on that theme is that the
IETF is no longer run by people who actually implement protocols.  The
relevance and impact of the IETF on what is actually used on the
Internet is marginalized through that change of membership.  The
attitude of "That is not how we do things in the IETF" make people go
away.

Cheers,
Simon

C Wegrzyn <[EMAIL PROTECTED]> writes:

> I think a big part of the issue is that the IETF has been taken over
> little by little by corporate interests. Before it used to be for the
> "love of doing it". Today it is more for "the benefit of one".
>
> Chuck Wegrzyn
>
> Marc Manthey wrote:
>
>> morning  experts,
>>
>>
>>> (Note that I haven't implemented any IETF protocols myself, but I 
>>> did once do an implementation of a badly designed protocol.)
>>
>>
>> a, is this why  you think that there is  no need  for any new  or 
>> old protocol at all ?
>>
>> have a great day
>>
>> marcM.
>>
>>
>>
>>___
>>Ietf mailing list
>>Ietf@ietf.org
>>https://www1.ietf.org/mailman/listinfo/ietf
>>  
>>
>
>
> ___
> Ietf mailing list
> Ietf@ietf.org
> https://www1.ietf.org/mailman/listinfo/ietf

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Myths of the IESG: Reading documents is the problem

[Theodore Ts'o]

On Tue, Aug 09, 2005 at 02:00:04PM -0700, Dave Crocker wrote: 
> So, Ted, please forgive me for using your posting to note a pattern,
> but I'm sufficiently tired of the very regular and usually
> hyperbole-filled pattern of misreading that happens in this realm,
> so that I feel the need to take explicit and forceful exception to
> it.
> 
> I did not say anything that bore any relationship to "forbid AD's
> from making any technical contributions."

No you didn't; and I apologize if I took a took your position to a
more extreme position than one you were advocating.

HOWEVER, it does seem that you seem to believe that the _primary_
responsibility of an AD is as a project manager and a process
manager/cop.  This would be particularly true if the document review
responsibility is taken away from the AD's, and if an AD is strongly
discouraged from offering their technical experitse as anything other
than "just another joe IETF member", lest they put undue stress on the
process.  

If that is the case, then it may be that it may be very difficult to
find volunteers willing to do what is, quite frankly, scut work.  It
may be utterly necessary work --- like writing technical documentation
or raking out the muck from a horse stable.  But that doesn't
necessarily mean that we will be successful finding volunteers to do
that work.

So if we do that, it may make sense to make the job of being a project
manager and process maven to be that of a staff position.  Some
standards organization do work that way, and it's not necessarily a
bad way of doing business.  It certainly isn't the way we are doing
business today; whether or not it is better seems in my mind to be
debateable.

If that's not what you wanted to advocate, perhaps it would be helpful
if you were to offer some concrete examples of what would be part of
the AD's job in your ideal universe, and what would _not_ be part of
the AD's job in your ideal universe, and what AD's do today that you
feel should result in their being bopped on the nose with a newspaper?

- Ted


___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Why have we gotten away from running code?

[wayne]

In <[EMAIL PROTECTED]> Harald Tveit Alvestrand <[EMAIL PROTECTED]> writes:

> --On onsdag, august 10, 2005 02:46:57 -0500 wayne <[EMAIL PROTECTED]> wrote:
>
>> The working group was shut down because no consensus could be
>> reached.  I think the lack of working code was one of the core causes
>> of the lack of consensus.
>>
>
> Don't be shy about naming names
>
> The MARID WG had one proposal (SPF) with running code and multiple
> implementations (I know nothing about whether the other proposals had
> implementations). It still failed to reach consensus.

Of the half dozen or so input documents to MARID, both SPF and DMP had
running code.  The WG decided not to adopt either of those two
proposals and instead went with an untested system.  (Ok, at almost
the very last minute, some working code to support the PRA was
created, but no significant testing was done.)


> It may say something about the value we place on running code, but I
> think it's hard to use it as an example of a situation with NO running
> code.

There was NO running code for the PRA during most of MARID's
existence.


-wayne


___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Why have we gotten away from running code?

[Jari Arkko]

Iljitsch van Beijnum wrote:


There are also specifications that would have been good to have
implementations before leaving the WG, because they are not
implemented-able as is (spkm).



Is that because the designers did a bad job or because there was no  
way to anticipate the implementation difficulties?


Protocol specs are like other pieces of engineering results:
they benefit greatly from testing and experience, particularly
if you've never created this specific type of entity before.

Sometimes what looks good on paper works but has nits and
missing details that need to filled out. In some other cases
there are more serious problems. In yet another cases there
are no issues.

I've seen many cases where supposedly well debated and
edited specifications had problems that could have been
detected by implementation experience. State transitions
or error conditions missed by specs written in prose rather
than in state machine form; security pixie dust that provides
a general solution but for which we cannot create a working
set of policy rules due to the nature of the application;
ambiguous requirements; lack of sufficient behaviour rules
to go with message formats; interactions between protocols
or layers that are hard to implement in commonly available
stack designs; optimizations that look good but turn out to
optimize an unimportant part of the problem; etc.

Obviously, I'm not advocating that we only listen to implementation
experience. A good spec combines input from multiple sources:
architetural insight, protocol design expertise, implementation
experience, marketing demand, different application areas, ...
You may also be able to trade one source to another one, but
not without limits.

--Jari


___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Myths of the IESG: Reading documents is the problem

[John C Klensin]

--On Wednesday, 10 August, 2005 09:49 -0400 Sam Hartman
<[EMAIL PROTECTED]> wrote:

>...
> Another point.  I think that John needs to do a bit more work
> explaining when this situation is intolerable.  I have no
> doubt there are cases where it would be bad.  However I'm also
> thinking of cases where it is reasonable.

Perhaps we can make some progress by examining each other's
examples.  I don't think that we are likely to find a single
bright line.

> Consider the following situation.  An AD tells a working group
> that some particular problem must be solved.  The AD proposes
> a solution as an individual and advocates for the solution.
> The working group decides to do something else that doesn't
> actually solve the problem. It seems both reasonable and
> necessary for the AD to apply pushback.

>From my perspective, two things are getting mixed up here, and
that is probably why my comment isn't obvious to you.  Steve
Bellovin's example is, I believe, helpful here.   But perhaps we
can think about some cases that fill in after "the working group
decides to do something else"...

(1) The problem is clear and real, and the working group decides
to do something that clearly and obviously doesn't solve the
problem.

It is entirely reasonable for the AD to push back on the
"doesn't solve the problem" issue.  If the AD's proposal
does solve the problem _and_ there are no other
problem-solving solutions on the table, it is reasonable
for the AD to remind the WG of that proposed solution.
But the AD is on very thin ice if things are said to the
WG that sound even vaguely like "no solution other than
mine is going to be accepted".

(2) The WG has examined the purported problem and there is a
disagreement between the AD and the WG as to whether the problem
is significant.

We have a gray area.  It gets appreciably more
gray if the AD is also pushing a particular solution to
the alleged problem.

(3) The WG agrees that there was a problem, but has fixed it
with a solution other than the one originally suggested by the
AD.  The AD continues to insist on his or her own solution. 

This is the case that I believe is intolerable,
certainly so unless the AD can clearly and publicly
document the reasons why the WG's solution is inadequate
and the AD-proposed solution is far superior.

There are other cases, but I believe the above group illustrates
the distinctions.

> I'm becoming increasingly convinced that there is not a shared
> understanding in the community about what is rereasonable and
> what would be a conflict of interest.

I agree.
   john



___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Why have we gotten away from running code?

[C Wegrzyn]

I think a big part of the issue is that the IETF has been taken over
little by little by corporate interests. Before it used to be for the
"love of doing it". Today it is more for "the benefit of one".

Chuck Wegrzyn

Marc Manthey wrote:

> morning  experts,
>
>
>> (Note that I haven't implemented any IETF protocols myself, but I 
>> did once do an implementation of a badly designed protocol.)
>
>
> a, is this why  you think that there is  no need  for any new  or 
> old protocol at all ?
>
> have a great day
>
> marcM.
>
>
>
>___
>Ietf mailing list
>Ietf@ietf.org
>https://www1.ietf.org/mailman/listinfo/ietf
>  
>


___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Why have we gotten away from running code?

[Marc Manthey]

morning  experts,


(Note that I haven't implemented any IETF protocols myself, but I  
did once do an implementation of a badly designed protocol.)


a, is this why  you think that there is  no need  for any new  or  
old protocol at all ?


have a great day

marcM.

--
"Reality is what, when you stop believing in it, doesn't go away.
Failure is not an option. It is a privilege reserved for those who try."

European headoffice
of the  first in- official
cuseeme protocol
testing lounge
www.let.de




smime.p7s
Description: S/MIME cryptographic signature
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Myths of the IESG: Reading documents is the problem

[Dave Crocker]

It seems to me that the *primary* responsibility for ensuring that
the WG considers everything it should consider, at an early enough
stage, lies with the WG Chair(s).

Certainly, the AD has an oversight and mentoring role here,
especially for first-time WG Chairs, but your obvious question
should be directed first to the WG Chair(s) and only second to
the ADs.


Brian,

We are talking about the IESG.  So that is what is being commented on.

We can always expand or redirect the scope of the discussion, with the 
predictable effect that it takes the focus off changes in IESG 
responsibilities and activities.  But that won't be productive.


For example, I could easily respond that the *primary* responsibility for 
ensuring that the wg considers everything it should consider lies with wg 
members.  Going down that path would ensure that we never really discuss 
anything about the IESG.  However I would rather look for productive changes 
that can be made in IETF management practises, since it is quite clear that 
SOME changes are needed and we have already spent some years NOT making them...


So, let's stay with the focus of this thread, shall we?

"Certainly, the AD has an oversight and mentoring role here?" captures the 
issue quite nicely.  It is an AD's trade-off between the role as individual 
technical contributor and the role of working group facilitator that I was 
highlighting.


My point is that the AD's primary responsibility is to focus on that oversight 
and mentoring.


d/

ps. I would argue, therefore, that Steve Bellovin's posting about carefully 
contributing to the AAA working group on the problems of proxies was, in fact, 
exactly this sort of strategic management mentoring.  Yes, he viewed it as 
technical contribution because, of course, it was. However he talked about the 
carefulness required in pursuing it and, of course, the strategic reasons 
proxies are a bad idea.  THAT is oversight and mentoring.


___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Why have we gotten away from running code?

[Iljitsch van Beijnum]

On 10-aug-2005, at 11:14, Love Hörnquist Åstrand wrote:

I don't agree, several IETF protocols that I've implemented while  
still
drafts have had major design changes done them because of an  
implementation

exposed serious flaws in them (secsh-gss, pk-init).


Hm, I'm not familiar with those. Still, for most of the protocols I'm  
familiar with I can't see how implementing them earlier would have  
changed the design. (Note that I haven't implemented any IETF  
protocols myself, but I did once do an implementation of a badly  
designed protocol.)



There are also specifications that would have been good to have
implementations before leaving the WG, because they are not
implemented-able as is (spkm).


Is that because the designers did a bad job or because there was no  
way to anticipate the implementation difficulties?

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Myths of the IESG: Reading documents is the problem

[Sam Hartman]

> "Harald" == Harald Tveit Alvestrand <[EMAIL PROTECTED]> writes:

Harald> --On tirsdag, august 09, 2005 16:33:46 -0400 John C
Harald> Klensin
Harald> <[EMAIL PROTECTED]> wrote:

>> And the notion of an AD who has contributed technically to a WG
>> in some significant way then pushing back during IESG review if
>> the WG reaches some other conclusion is pretty close to
>> intolerable.  Changing the review model would, presumably,
>> clear that situation up in a hurry.

Harald> Only if it does more than just replace "AD" with
Harald> "reviewer" in the above sentence.

Another point.  I think that John needs to do a bit more work
explaining when this situation is intolerable.  I have no doubt there
are cases where it would be bad.  However I'm also thinking of cases
where it is reasonable.

Consider the following situation.  An AD tells a working group that
some particular problem must be solved.  The AD proposes a solution as
an individual and advocates for the solution.  The working group
decides to do something else that doesn't actually solve the problem.
It seems both reasonable and necessary for the AD to apply pushback.q

I'm becoming increasingly convinced that there is not a shared
understanding in the community about what is rereasonable and what
would be a conflict of interest.

--Sam


___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Why have we gotten away from running code?

[Brian E Carpenter]

Bruce Lilly wrote:

Date: 2005-08-09 09:16
From: Brian E Carpenter <[EMAIL PROTECTED]>




The question on the table since RFC 3774 is: why don't we
execute the transition to Draft Standard more often,
otherwise known as: why are there so few implementation
reports at http://www.ietf.org/IESG/implementation.html
(three this year, I believe)?



One issue has been identified and discussed, but as far as I know has
not been resolved.  Consider RFCs 3885 through 3888 produced by the
MSGTRK working group; three of the four are Standards Track at Proposed,
all were published September 2004.  The PS RFCs could have advanced to
Draft as early as March 2005 (six months) but for one problem;
advancement requires that the WG Chair produce documentation on
interoperable implementations.  So why hasn't the MSGTRK WG worked on
advancement to Draft?  Well, there isn't a MSGTRK WG any more (and
therefore no MSGTRK WG Chair); the IESG disbanded it.  Will the IESG
reinstate the WG to advance the three Standards Track RFCs to Draft?


You're certainly correct. And the received wisdom for some years has
been that closing WGs is A Good Thing. I even got applause in plenary
for announcing that 22 WGs were closed since IETF62.

So, it would be a change in current practice to make "advance the stuff
to DS" a default goal of every WG charter. That presupposes an answer to
the question whether we need >1 stages, but the only consistent outputs
from newtrk will be "1 stage" or ">1 stages, but WGs must remain open."

I suggest we continue this over in newtrk.

Brian


___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Myths of the IESG: Reading documents is the problem

[Brian E Carpenter]

Dave Crocker wrote:
...
What is especially problematic is when the working group has late-stage 
process and project management difficulties, leading to the obvious 
question of what happened in the earlier stage?


Having a non-cognizant AD press late-stage issues leads to the question 
of why they did not pay attention earlier?  If the topic is important 
enough for them to delay the wg output now, why was it not important 
enough earlier?  


It seems to me that the *primary* responsibility for ensuring that
the WG considers everything it should consider, at an early enough
stage, lies with the WG Chair(s).

Certainly, the AD has an oversight and mentoring role here,
especially for first-time WG Chairs, but your obvious question
should be directed first to the WG Chair(s) and only second to
the ADs.

I don't mean the ADs have no duties in this area - but they
can't be everywhere at once and read every email.

Brian



___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Why have we gotten away from running code?

[Harald Tveit Alvestrand]

--On onsdag, august 10, 2005 02:46:57 -0500 wayne <[EMAIL PROTECTED]> wrote:


The working group was shut down because no consensus could be
reached.  I think the lack of working code was one of the core causes
of the lack of consensus.



Don't be shy about naming names

The MARID WG had one proposal (SPF) with running code and multiple 
implementations (I know nothing about whether the other proposals had 
implementations). It still failed to reach consensus.


It may say something about the value we place on running code, but I think 
it's hard to use it as an example of a situation with NO running code.


Harald


___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Autoreply: Re: Why have we gotten away from running code?

[hverma]

I am away on vacation until Aug 8 and will get back to you after that. Thanks


Your message reads:

Received: from megatron.ietf.org (unverified [132.151.6.71]) by 
hdflem01.fl.hostdepot.net
 (Vircom SMTPRS 4.1.361.21) with ESMTP id <[EMAIL PROTECTED]> for <[EMAIL 
PROTECTED]>;
 Wed, 10 Aug 2005 05:51:36 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
by megatron.ietf.org with esmtp (Exim 4.32)
id 1E2nCs-0004gN-8o; Wed, 10 Aug 2005 05:49:06 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
by megatron.ietf.org with esmtp (Exim 4.32) id 1E2nCp-0004cq-KV
for [EMAIL PROTECTED]; Wed, 10 Aug 2005 05:49:03 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA16847
for ; Wed, 10 Aug 2005 05:49:01 -0400 (EDT)
Received: from ns4a.townisp.com ([216.195.0.138] helo=ns4.townisp.com)
by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E2nku-SL-5U
for ietf@ietf.org; Wed, 10 Aug 2005 06:24:17 -0400
Received: from mail.blilly.com (dhcp-0-8-a1-c-fa-f7.cpe.townisp.com
[216.49.158.220])
(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
(Client CN "marty.blilly.com", Issuer "Bruce Lilly" (not verified))
by ns4.townisp.com (Postfix) with ESMTP id 5987F29966
for ; Wed, 10 Aug 2005 05:48:53 -0400 (EDT)
Received: from marty.blilly.com (marty.blilly.com [192.168.99.98] (may be
forged)) by mail.blilly.com with ESMTP
id j7A9mo2Z005170(8.13.1/8.13.1/mail.blilly.com /etc/sendmail.mc.mail
1.26 2005/06/24 20:47:59)
(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) ; 
Wed, 10 Aug 2005 05:48:52 -0400
Received: from marty.blilly.com (localhost [127.0.0.1])
(authenticated (0 bits)) by marty.blilly.com with ESMTP
id j7A9mnnO005165(8.13.1/8.13.1/blilly.com submit.mc 1.3 2005/04/08
12:29:31) (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) ;
Wed, 10 Aug 2005 05:48:50 -0400
From: Bruce Lilly <[EMAIL PROTECTED]>
Organization: Bruce Lilly
To: ietf@ietf.org
Date: Wed, 10 Aug 2005 05:48:42 -0400
User-Agent: KMail/1.8.2
References: <[EMAIL PROTECTED]>
In-Reply-To: <[EMAIL PROTECTED]>
MIME-Version: 1.0
Content-Type: text/plain;
  charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <[EMAIL PROTECTED]>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: d6b246023072368de71562c0ab503126
Content-Transfer-Encoding: 7bit
Subject: Re: Why have we gotten away from running code?
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: ietf@ietf.org
List-Id: IETF-Discussion 
List-Unsubscribe: ,

List-Post: 
List-Help: 
List-Subscribe: ,

Sender: [EMAIL PROTECTED]
Errors-To: [EMAIL PROTECTED]

> Date: 2005-08-09 09:16
> From: Brian E Carpenter <[EMAIL PROTECTED]>

> The question on the table since RFC 3774 is: why don't we
> execute the transition to Draft Standard more often,
> otherwise known as: why are there so few implementation
> reports at http://www.ietf.org/IESG/implementation.html
> (three this year, I believe)?

One issue has been identified and discussed, but as far as I know has
not been resolved.  Consider RFCs 3885 through 3888 produced by the
MSGTRK working group; three of the four are Standards Track at Proposed,
all were published September 2004.  The PS RFCs could have advanced to
Draft as early as March 2005 (six months) but for one problem;
advancement requires that the WG Chair produce documentation on
interoperable implementations.  So why hasn't the MSGTRK WG worked on
advancement to Draft?  Well, there isn't a MSGTRK WG any more (and
therefore no MSGTRK WG Chair); the IESG disbanded it.  Will the IESG
reinstate the WG to advance the three Standards Track RFCs to Draft?

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf


___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Why have we gotten away from running code?

[Bruce Lilly]

> Date: 2005-08-09 09:16
> From: Brian E Carpenter <[EMAIL PROTECTED]>

> The question on the table since RFC 3774 is: why don't we
> execute the transition to Draft Standard more often,
> otherwise known as: why are there so few implementation
> reports at http://www.ietf.org/IESG/implementation.html
> (three this year, I believe)?

One issue has been identified and discussed, but as far as I know has
not been resolved.  Consider RFCs 3885 through 3888 produced by the
MSGTRK working group; three of the four are Standards Track at Proposed,
all were published September 2004.  The PS RFCs could have advanced to
Draft as early as March 2005 (six months) but for one problem;
advancement requires that the WG Chair produce documentation on
interoperable implementations.  So why hasn't the MSGTRK WG worked on
advancement to Draft?  Well, there isn't a MSGTRK WG any more (and
therefore no MSGTRK WG Chair); the IESG disbanded it.  Will the IESG
reinstate the WG to advance the three Standards Track RFCs to Draft?

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Why have we gotten away from running code?

[Love Hörnquist Åstrand]

Iljitsch van Beijnum <[EMAIL PROTECTED]> writes:

> Sure, trying to implement something brings out bugs in the
> specification, but those are usually relatively minor things that
> don't go to the design of the protocol. And wide deployment generally
> shows that a protocol could have been better in one regard or
> another, and that some parts of it don't turn out to be useful in
> practice.

I don't agree, several IETF protocols that I've implemented while still
drafts have had major design changes done them because of an implementation
exposed serious flaws in them (secsh-gss, pk-init).

There are also specifications that would have been good to have
implementations before leaving the WG, because they are not
implemented-able as is (spkm).

Love



pgpJIglK9mNcw.pgp
Description: PGP signature
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Why have we gotten away from running code?

[Iljitsch van Beijnum]

On 7-aug-2005, at 1:07, Brian Rosen wrote:


I notice that we have stopped being interested in running code.



I think that is to our community's detriment.


[...]

Probably more importantly, I think we should be VERY suspicious of  
new,

complex specifications before we have running code.


I've been thinking about this on and off for a day, and I'm not  
convinced that having running code at the time a specification is  
first fleshed out would be all that helpful.


Can you point to any instance in recent IETF history (after 1995 or  
2000 or so) where having having running code early in the process  
would have made for a better _designed_ protocol?


Sure, trying to implement something brings out bugs in the  
specification, but those are usually relatively minor things that  
don't go to the design of the protocol. And wide deployment generally  
shows that a protocol could have been better in one regard or  
another, and that some parts of it don't turn out to be useful in  
practice.


However, waiting for implementations on account of the former only  
delays having a fixed spec even longer (we already see protocols  
_deployed_ before there is an RFC, which is very harmful IMO) while  
waiting for the latter leads to insanity such as RFC 1771 being stuck  
at "draft standard" even though it has dozens of interoperable  
implementations, a decade of operational experience and there  
wouldn't be an internet without it.


___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Myths of the IESG: Reading documents is the problem

[Harald Tveit Alvestrand]

--On tirsdag, august 09, 2005 16:33:46 -0400 John C Klensin 
<[EMAIL PROTECTED]> wrote:



And the notion of an AD who has contributed
technically to a WG in some significant way then pushing back
during IESG review if the WG reaches some other conclusion is
pretty close to intolerable.  Changing the review model would,
presumably, clear that situation up in a hurry.


Only if it does more than just replace "AD" with "reviewer" in the above 
sentence.



___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Why have we gotten away from running code?

[wayne]

In <[EMAIL PROTECTED]> "Brian Rosen" <[EMAIL PROTECTED]> writes:

> I notice that we have stopped being interested in running code.
>
> I think that is to our community's detriment.

I confess that while I've watched the IETF from afar for about a
decade, I am relatively new to actually doing anything in the IETF.  I
had always believed that "rough consensus and working code" were the
rules that the IETF lived by.

I was very surprised when participated in my first working group and
found that not only was working code was not required, but the
co-chairs and AD of the WG didn't think it was needed.


A few choice quotes from me about the lack of requiring working code:

   Without working code, we are just being a debating club.[1]

Another: [2]

There doesn't appear to be a rough consensus [and the co-chair of the
WG says likewise].  However, the long standing IETF mantra has, to the
best of my knowledge, been "rough consensus *AND* working code".  What
we lack with most proposals is working code.

I think the lack of a rough consensus is in large part due to the lack
of working code.  Working code quickly dispels both wishful-thinking
and FUD.  Working code is a different way of expressing a proposal so
disagreements and misunderstandings about a proposal can be cleared up
by looking at the code and then either the code or the proposal can be
fixed to make things clearer.

The devil is always in the details.  As long as we continue to
consider proposals that don't have working code, we allow people to
nit-pick proposals that are complete, while glossing over the problems
with proposals that exist on paper only.


The working group was shut down because no consensus could be
reached.  I think the lack of working code was one of the core causes
of the lack of consensus.



The list of messages that I could find where I stressed the importance
of working code: 


Apr 06, 2004 http://www.imc.org/ietf-mxcomp/mail-archive/msg00762.html
Apr 06, 2004 http://www.imc.org/ietf-mxcomp/mail-archive/msg00775.html

[1] Apr 22, 2004 http://www.imc.org/ietf-mxcomp/mail-archive/msg00994.html
   Without working code, we are just being a debating club.

May 21, 2004 http://www.imc.org/ietf-mxcomp/mail-archive/msg01617.html

[2] Jun 15, 2004 http://www.imc.org/ietf-mxcomp/mail-archive/msg01982.html

There doesn't appear to be a rough consensus [and the co-chair of the
WG says likewise].  However, the long standing IETF mantra has, to the
best of my knowledge, been "rough consensus *AND* working code".  What
we lack with most proposals is working code.

I think the lack of a rough consensus is in large part due to the lack
of working code.  Working code quickly dispels both wishful-thinking
and FUD.  Working code is a different way of expressing a proposal so
disagreements and misunderstandings about a proposal can be cleared up
by looking at the code and then either the code or the proposal can be
fixed to make things clearer.

The devil is always in the details.  As long as we continue to
consider proposals that don't have working code, we allow people to
nit-pick proposals that are complete, while glossing over the problems
with proposals that exist on paper only.


Jun 15, 2004 http://www.imc.org/ietf-mxcomp/mail-archive/msg01988.html

A reply to the co-chair of the WG after he said that working code
really isn't needed.

Jul 01, 2004 http://www.imc.org/ietf-mxcomp/mail-archive/msg02476.html
Jul 13, 2004 http://www.imc.org/ietf-mxcomp/mail-archive/msg02651.html


-wayne


___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf