Subject: RE: [arch-d] Defining terms

From: "Bound, Jim" <[email-masked]>
Date: Fri, 24 Mar 2006 10:24:15 -0500

No disagreements with the below I see your point better now. Thanks for
taking time with the response.  Yes I have looked at VJs new stuff and
agree its not entirely a new idea or circular buffers, did not know that
about Multics, and interesting.  Also yes for verification running code
can be lazy just to get proof of concept, I would suggest it is lazy
evaulation of programming to see if stuff works.  I don't write code
anymore but I still read it occasionally.  Speaking of changes.  I had
to review the Grid Globus Toolkit for day job and IPv6 Forum and pulled
over entire 10 MB (at the time) source pool.  I jumped into all the
java, xml, et al. and I said oh my great-spirit I am glad I am not a
programmer anymore :--)  But I did find what I was looking for so it was
useful exercise.

thx
/jim

> -----Original Message-----
> From: John Day [mailto:[email-masked]] 
> Sent: Friday, March 24, 2006 10:02 AM
> To: Bound, Jim; John Day; John Leslie
> Cc: [email-masked]; Noel Chiappa
> Subject: RE: [arch-d] Defining terms
> 
> At 0:48 -0500 2006/03/24, Bound, Jim wrote:
> >
> >
> >>  -----Original Message-----
> >>  From: John Day [mailto:[email-masked]]
> >>  Sent: Thursday, March 23, 2006 3:08 PM
> >>  To: Bound, Jim; John Leslie
> >>  Cc: John Day; [email-masked]; Noel Chiappa
> >>  Subject: RE: [arch-d] Defining terms
> >>
> >>  At 14:52 -0500 2006/03/23, Bound, Jim wrote:
> >>  >Valid point but I took the BGP more as abstraction to 
> define a layer
> >>  >called routing for discussion. IP model don't call out a
> >>  routing layer.
> >>  >Forwarding is different than extraplation of routes and discovery
> >>  >clearly.
> >>
> >>  But we are trying to *find* the right model.  We can't 
> let the fact
> >>  that the IP model doesn't call out a routing layer affect 
> our view.
> >
> >I don't think that was being done it was a discussion 
> regarding what is
> >implemented in some cases today simply as part of the 
> discussion.  That
> >in my view helps with what can be done tomorrow.
> >
> >>  The IP model may be wrong, or not quite right.
> >
> >I for one have not on any mail made such a judgement.  
> Making it better
> >to me is the key objective.  For me this is not about right 
> or wrong.  I
> >don't like that we have lost the end-to-end model on the Internet.
> 
> Well, right or wrong here is used to mean a good theory that fits the 
> data and makes good predictions, i.e. when you try to do things 
> hadn't thought about it helps rather than gets in the way.
> 
> We have lost the end-to-end model because we had half an addressing 
> architecture.
> 
> To follow Alexis comment the other day, we basically have an 
> unfinished demo on our hands. ;-)
> 
> >  >  It was assuming that
> >>  it was right that got us where we are. We have to find 
> what is really
> >>  going on. Once we understand that, then we can worry about how to
> >>  engineer it.
> >
> >Agreed but as I said above that is how I "perceived" the 
> discussion and
> >comment.
> >
> >>
> >>  As you tell kids when they are doing their math homework: 
>  Don't skip
> >>  steps. It will only get you in trouble. ;-) (Always hated 
> it when my
> >>  father told me that.)
> >
> >Agree and I think what is now is part of the steps at various points
> >within the discussion.
> >
> >>
> >>  >
> >>  >More important to your mail yes we need to find consensus
> >>  but only rough
> >>  >consensus to keep moving once that is achieved.  But then we
> >>  get to the
> >>  >running code part :--)
> >>
> >>  Ahh, yes science by popularity.  Wonder how often that has
> >>  been the case.
> >
> >I cannot parse how you came up with science by popularity from my
> >comment. If you beleive rough consensus is popularity then I 
> guess that
> >is a point.  The alternative is elitism and that I find 
> vulgar, and my
> >view is kings should have heads chopped off :--), so support 
> the rough
> >consensus.
> 
> Science is elitist, not democratic.  It goes with evidence and proof. 
> It is normally the case that what becomes the "right" answer was not 
> a view held by the majority of scientists, let alone the majority of 
> the population.  In fact, it is almost expected that science shows 
> that our intuitions about things are usually wrong. ;-)  Damned 
> embarrassing!
> 
> Now that said, all models/theories in science are working 
> assumptions.  None are True.  Our job is always to try to prove them 
> wrong.
> 
> >I don't think you were speaking of running code as that is cleary
> >important and has nothing to do with popularity, and more 
> about proof of
> >concept.
> 
> Yea, no I wasn't.  But running code has its concerns as well.  Of 
> course, it is good to ensure that it works and can be done.  But I 
> often worry that given natural laziness, it limits the range of 
> implementation strategies that get tried.  Have you seen Jacobsen's 
> recent stuff on improving TCP that seems to indicate that everyone 
> was just doing what Berkeley did which was pretty much what Multics 
> did and it wasn't the best way?  Also running code has the tendency 
> to become the spec again limiting variety but these are nits.
> 
> >  >
> >>  rough consensus applies to electro-political engineering.
> >
> >We can agree to disagree, but I am pretty sure this list and the IETF
> >support and will continue to support rough consensus.
> 
> The problem in the IETF isn't rough consensus per se.  All standards 
> committees I have ever been in use it at the working group level. 
> The problem in the IETF is that they have an organization without 
> checks and balances on the individual.  This doesn't mean that what 
> comes out doesn't work, it means that the process is open to 
> manipulation and is exploited.  The dynamics of representative 
> organizations should go on elsewhere.
> 
> >  > I didn't
> >>  realize that was the domain of this discussion.  I 
> thought this was a
> >>  more scientific inquiry. Science must follow the data 
> regardless of
> >>  how unpopular it may be.
> >
> >Well I could remind all Philosophy is the Mother of All 
> Sciences, but I
> >won't.  Part of scientific inquiry is analysis, and part of 
> analysis is
> >discussion, censoring discussion to suit any one individuals needs is
> >probably not going to happen in the IETF or in most forums I work in
> >unless it is an elitist group and then I usually leave 
> because I don't
> >find that type of crowd very respectful to others and I 
> don't deal well
> >with disrespect nor put up with it as one human on the planet, we all
> >have our limitations.
> 
> I think a tyranny of the majority is more likely.  Often in science, 
> the new idea is quite unpopular. Consider how long the idea that 
> continents moved was around before the bulk of the community came to 
> the idea.  No, scientific inquiry is an odd bird.
> 
> Take care,
> John
> 

_______________________________________________
Architecture-discuss mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/architecture-discuss

---

From: John Day <[email-masked]>
Date: Fri, 24 Mar 2006 10:37:30 -0500

>agree its not entirely a new idea or circular buffers, did not know that

That was my reaction as well.  I couldn't be sure, but was pretty 
sure we had not done it the way it was before VJ looked at it. ;-)

>evaulation of programming to see if stuff works.  I don't write code

Normally, I consider laziness a virtue!  ;-)  .i e. would rather sit 
around and think up an elegant simple solution than just barrel 
through it! ;-)

>programmer anymore :--)  But I did find what I was looking for so it was

Know what you mean.  I am not sure there is much good code being 
written these days.

Story from ancient past:  We wrote an OS once entirely based on 
semaphores.  Consequently, a task switch comes down to a single 
assignment statement.  Basically, Top of Stack goes to PC counter. 
You enter P one stack and you exit in V on another and everything is 
either doing procedure entry/exit or doing P and V except that 
assignment statement.  It was a really elegant piece of work.  The 
standard procedure entry/exit did the save and restore for you, so 
there was really nothing else to do but change the PC.  ;-)

Since it was a DARPA project we had a code review with Vint, 
McKenzie, Tomlinson, Steve Crocker, Roland Bryant, Ollikanen, the 
usual cast of characters.  When we got to explaining the semaphore 
code, they couldn't believe it.  It took 3 hours of explanation, 
drawing out how the stack changed, etc and I am not sure they ever 
truly believed it even though the code was running.

But then we had been using a Burroughs machine for 5 years at that 
point and we ate, drank and slept recursion.

Take care,
John

---

From: John Day <[email-masked]>
Date: Fri, 24 Mar 2006 10:37:30 -0500

Take care,
John