[ih] principles of the internet

[Dave Crocker]

On 6/1/2010 8:47 AM, Matthias Bärwolff wrote:
>>> 4. cascadability and symmetry (speaking to the rules of efficient and
>>> flexible protocol design)
>>
>> What do you mean by the term "cascadability"?  What do you mean by
>> "symmetry" in this context.
>
> There are ways in which you can have protocols doing similar things
> (e.g. file transfer) but which are not possible to concatenate (or
> cascade) without violating their semantics (pertaining to
> acknowledgments and other such control actions).

Do you have some examples of 'cascadability' for the Arpanet or Internet?  I am 
still not quite seeing how it applies to the design or operation of the protocols.


> Symmetry just means that neither end is conceptually master or slave,
> instead both being equal peers (cf. Telnet symmetry).

At the application level, symmetry is either absent or a myth, for almost all 
applications.

It also is not always present at lower layers (e.g., dhcp and I believe TLS.)

Hmmm.  For that matter, I suspect the Arpanet NCP was not all that symmetrical, 
although I do not remember enough of the details.  I also do not remember how 
symmetrical the IMP behavior was.  (But perhaps the Arpanet is going back too 
far for your discussion.)

The telnet reference is particularly salient.  When I was running an Internet 
software stack development group, we were seeking authorization to sell to the 
US government and they sent out a person to verify our standards compliance. 
During this, he required that we demonstrate that a host could sent the user 
(that is, serve to client) to WILL ECHO.  In other words, we had to support 
having the user's system echo data from the host server back to the host server.

We noted that this was illogical and highly undesireable.  He calmly agreed with 
us but them pointed to the symmetry of the protocol and said the formalities 
required us to support it.

We hacked the change long enough to pass the test, continuously shaking our 
heads in disbelief.


>>> 5. running code, complexity avoidance, rough consensus, and path
>>> dependence (speaking to the governance process and its stability)
>>
>> This sub-list merges at least two very different areas of concern.  One
>> is the process for developing specification and the other pertains to
>> technical characteristics of specifications.  The latter is also
>> reflected elsewhere in your list.
>
> Agreed, the latter stands out somewhat. As for the separation you
> mention, I would think, though, that the feasibility of getting anywhere
> involves both the organization of the process, and the characteristics
> of the resultant artifacts. I will have to think more about this.

I am not saying that they are not each important, but that combining them might 
confuse them as distinguishing concepts.

d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net