Re: SE-IPSP definition

Peter,

A couple of comments:

- (See "[SUA issue 17 & M3UA issue #11] IPSP cases" in the archives, as
  well as "M3UA/SUA IPSP" and "IPSP proposed text (1st approach)"
  "IPSP-IPSP summary" "Consensus call (was: IPSP-IPSP summary)" "IPSP
  test (2nd approach)" "IPSP text - poll" "IPSP text (take 3?)" "Summary
  (hopefully) was: IPSP Text (take 3?)")

  There were several thousand mails exchanged on the topic.

- What you quote is just a definition, not a requirement.  (And in fact
  it is an old one that predates the SE model and the entire IPSP
  discussion.)  As it contains no requirements, there was no need to
  change it.

- The phrase "SGP or IPSP" occurs many times in RFC 3332 and RFC 3868.

- I invented SE mode (when the rest of the WG was demanding DE mode).
  If I had not argued through several hundred emails, you would only
  have DE mode now.

- To have a single exchange of messages it is a necessary that one side
  behave like an ASP (messages and state machines) and the other behave
  like an SGP (messages and state machines).

- An IPSP is often described as behaving like an SGP.

- John Loughney described how an IPSP responds to a received message in
  an attempt to limit complexity.  Because ASPs normally initiate
  messages, the passages describing IPSP decribe the IPSP as responding
  to the message in the same manner as an SGP (making the same state
  transitions and performing the same actions).  So even if an IPSP is
  defined as something like an ASP, its behaviour is most often
  described in the RFC as something like an SGP.

- Contrary to what Tolga says now, exchange of SSNM was always part of
  SE-IPSP.  It was exchange of ASPTM/SM that was questioned as whether
  it should be included in SE-IPSP communication at all.

- To limit changes to the RFC and move forward, we underspecified IPSP
  to allow for a wide range of combinations.  The resulting nightmare
  for interoperability was supposed to be addressed in extension drafts
  but never was.

- We purposely did not preclude any arrangements or interpretations in
  the RFC.  What functions the IPSP provides locally are closer to an
  implementation decision than a a protocol requirement.

- We intentionally did not introduce any changes to the ASP/SGP exchange
  for IPSP (we did not want define two protocols in one RFC).  Any
  changes to (or narrowing of) the normal ASP/SGP exchanges were to be
  addressed by extension drafts (but never were).

--brian

Holland, Peter Michael (Peter) wrote:           (Thu, 10 Nov 2005 10:39:28)
> Brian,
> Can I remind you that the definition of IPSP is:
>    IP Server Process (IPSP) - A process instance of an IP-based
>    application.  An IPSP is essentially the same as an ASP, except that
>    it uses M3UA in a point-to-point fashion.  Conceptually, an IPSP does
>    not use the services of a Signalling Gateway node.
> 
> Thus your mention of IPSP acting as an SGP is not according to spec.
> Considering that definition, your statement:
> > In SE mode,
> > it was never intended that both sides behave like an ASP at the same
> > time.  That is DE mode.
> is not reflected in the spec - thus the confusion.
> 
> Pete
> 

-- 
Brian F. G. Bidulock
[email protected]
http://www.openss7.org/