Subject: RE: [NSIS] attempted summary of pre-emption thread

From: "Gary Kenward"<[email-masked]>
Date: Wed, 10 Apr 2002 13:19:02 -0400

Martin:

  Getting clearer to me. This would seem to be a state machine design
issue. One could define requirements that certain protocol events
were asynchronous, thus distinguishing them from the synchronous protocol
events, and require certain behaviours on the part of the communicating 
entities. In general, the normal assumption for the Internet is asynchronous
message, as ensuring synchronization (implying assured delivery, ordering, 
and no duplication) is often more complex (this is my perception, I am open
to correction on this). There are not many precedents for signalling in the
Internet.

  The other observation I would make is that the IETF does not specify
state machine behaviour, but rather protocol behaviour. Thus, the
requirement
for a message arrival at a node is usually an outcome at the node, and 
a (possible) response to the message. How the node effects the outcome and
generates the response is left to the node designer. Thus, in general,
one would not require that a state-machine be pre-empted by a protocol
event.

  Marcus was correct in his posting that there is confusion over the topic
here. Perhaps the confusion was mine, but my recollection is that this 
thread started with a discussion of "pre-emption" bits in NSIS to specify
flow
treatment. This issue with the protocol state machine is very different.

  My view, and this is just my view, is that specifying state-machine
pre-emption
is not the right requirement (in the IETF context). Rather, we should focus
on
the expected outcome of a protocol exchange and the dependence or
independence
of the sequencing of messages.

  Otherwise, I agree that it must be (and usually, btw, is) accounted for in
the protocol definition.

Regards,
Gary

> -----Original Message-----
> From: Martin Karsten [mailto:[email-masked]]
> Sent: April 10, 2002 10:35
> To: Kenward, Gary [WDLN2:AN10:EXCH]
> Subject: Re: [NSIS] attempted summary of pre-emption thread
> 
> 
> Yep, for this example, one might express it that way.
> 
> Martin
> 
> > Martin:
> > 
> >   If I understand this example correctly, the issue is the 
> relationship
> > between the state of the initiator and the arrival of 
> asynchronous messages
> > that should change that state?
> > 
> > Gary
> > 

*snip*

> > > > > 
> > > > > Martin
> > > > > 
> > > > > _______________________________________________
> > > > > nsis mailing list
> > > > > [email-masked]
> > > > > https://www1.ietf.org/mailman/listinfo/nsis
> > > > > 
> > > 
> > > 
> 
>

---

From: Behcet Sarikaya <[email-masked]>
Date: Wed, 10 Apr 2002 13:31:34 -0500

Gary Kenward wrote:

> state machine behaviour, but rather protocol behaviour.
>
Gary, what makes you say this? The state machine behaviour is part of 
protocol behavior. Protocol RFCs specify the behavior informally which 
makes it rather difficult to fully specify the state machine behavior 
more difficult than if the specs were in SDL. But that does not mean the 
state machine behavior is not or can not be specified.

> Thus, the requirement
> thread started with a discussion of "pre-emption" bits in NSIS to 
> specify flow
> is not the right requirement (in the IETF context). Rather, we should 
> focus on
--behcet