Subject: RE: [SPIRITS] Architecture Document?

From: "Buller, Jeremy" <[email-masked]>
Date: Wed, 29 Nov 2000 15:28:45 -0500

Hi Igor,

I trust you are well.

Lawrence has probably gone for a PINT or two now :) so I'll take 
on some of these points, as I'm this side of the pond, if I may.

> Lawrence Conroy wrote:
> > 
> > 
> > The Architecture (and the diagram it contains) doesn't seem to have
> > changed in light of
> > the discussions in Pittsburgh (and before):
> 
> Well, the document was supposed to change in view of the discussion
> on-line. We did NOT finish the Pittsburgh discussion at the 
> meeting.And
> even if we did, the meetings do NOT make decisions.
I think you'll find that Lawrence was in fact eluding to not only 
the discussion at Pittsburgh but also prior discussions on this 
list and ID submissions that, now I've checked, for some reason 
do not seem to have found there way into the respective IETF WG 
pages, namely:

  draft-conroy-pint-acct-00.txt
  draft-conroy-pint-acct-00.txt
  draft-buller-spirits-ccib-00.txt

Maybe their absense is the cause of confusion, difference of 
opinion.

draft-buller-spirits-ccib-00.txt itself contains a slightly 
more generic architecture diagram (figure 2) in which one could 
conceivably foresee some people replacing the generic term 
'Initiative system' with 'SCF' if they were so disposed. 

> > (i) It shows the "Subscribers Telephone" in the Internet (i.e. above
> > the horizontal dashed line),
> > even though we aren't talking about Voice over IP phones.
> 
> We could re-draw that, althought I really don't see how that 
> could cause
> a confusion. The document very clearly states that it has 
> nothing to do with Voice over IP.
Well, Section 2.1. describing ICW, third '+' bullet point, 
indicates that the call may in fact be handled using VoIP.
Whatever, it's a small point and I think Lawrence was just 
intending to provide helpful comment to aid reading by a 
wider audience.

> > (ii) It also shows a PINT Server *in* the Internet. This is not a
> > good place for an Application
> > Level Gateway ->between<- the PSTN and the Internet. It should
> > instead be on the border,
> > arguably level with the SPIRITS Client.
> 
> The PINT server is an Internet end-point. But if Lawrence re-drew the
> picture to improve the visual statement, I would happily accept.
As stated above there is another draft with another diagram. 
Admittedly, it only makes casual reference to the need for a 
proxy (more on this below). Please feel free to use or modify 
this as you see appropriate if necessary. Alternatively, as you 
suggest, perhaps Lawrence may be able to spare some time to 
redraw said diagram to provide clarification as the co-author 
of the PINT RFC, I think it might help.

> > (iii) Similarly, the SPIRITS system has a proxy between the client
> > and server, whilst the PINT
> > system doesn't.
> 
> That is true. The role of the proxy is well described in the 
> document to explain why.
Would this be:

-- 5. SPIRITS proxy, which is co-located with the PINT Server
-- and serves as an intermediary between the SPIRITS Server 
-- and SPIRITS Client via the B and C interfaces, respectively.

Descriptions of the B and C interface seem to imply that the 
the SPIRITS proxy just forwards requests and responses unless
it acts as an endpoint itself or 'virtual server'.

More below...

> > These are *examples* of Executives and Initiatives, not the *only
> > possibility*. Check back
> > through the PINT and SPIRITS meetings for statements to that effect.
> 
> In PINT, yes, but in SPIRITS, no. These are NOT the examples, and the
> SPIRITS charter makes a very clear statement to that effect. The
> interface between the SPIRITS client and the SPIRITS proxy is 
> precisely
> the interface to carry the IN trigger information. For the 
> more abstract
> things, there is an interface between the SPIRITS proxy and SPIRITS
> server, which is why Lev placed the SPIRITS proxy and PINT 
> server on the
> same level. Thus, the "Executive System" would need to be at the level
> of SPIRITS Proxy.
Uh? Wait a minute! My understanding was that interface D carried 
the IN trigger information and was BTW pretty much outside the 
scope of the WG. The SPIRITS client was intended to transform 
this into messages for the SPIRITS server (or Proxy depending on 
you point of view). Subsequently, this WG was only concerned 
with the protocol to handle the C interface. This is why I for 
one could not see an explicit requirement for the B interface 
or 'explicit' reference to a proxy.

The description you've provided above seems to imply a requirement 
for two protocols; one for the C interface and one for the B 
interface? Is this correct? 

> > It appears that the original goal of symmetry and generality 
> > that I thought we had for PINT and SPIRITS is less clear 
> > than it was
> 
> I respectfully disagree. "Symmetry" perhaps was a goal, but it means
> nothing to me without a specific context. We are not doing things for
> the sake of symmetry, we are doing them to make things work.  As for
> "generality," I believe the things ought to be specific, not 
> general. We
> had an Informational that clearly showed how things were implemented,
> and Lev came up with the architecture that captured it.
If this is not symetric why include PINT at all? It seems to 
have been the source of some confusion relating to the identifying 
the source of specific flows. I personally thought, as Lawrence 
did, that PINT and SPIRITS were symetric or mirror images of each 
other.

As for 'generality' I think Lawrence is making the point that
PINT didn't really care what was in the executive system of PSTN, 
to all intents and purposes it could have been a text display to an 
operator who manually made calls or connected parties on behalf 
of the PINT client. SPIRITS seems to be a different animal, one 
that requires IN (not just triggers). As I have stated in the 
past I have no problem with trigger mapping happening 'somewhere' 
in a service description but I believe its actual implementation  
should be hidden behind the line that is the PSTN/IP boundary 
in the same way that PINT is not interested in the 'actual' 
implementation undertaken in the PINT executive system.
 
It just seems a little odd to include PINT (a protocol that 
'requires' no specific implementation in the PSTN) and SPIRITS
(which 'requires' IN) in the same discussion. What happens to 
services that use a little of both?... maybe PINT and SPIRITS 
are, and should be, considered separately and in isolation?

> The architecture document does not address any message 
> sequencing, so I
> don't see how this argument applies here. But, actually, I don't
> understand the issue.  If a service starts in the PSTN, it is SPIRITS;
> if it starts in the Internet, it is PINT. 
I think the issue is that confusion can still be seen to reign
when describing services that may use functionality from PINT 
and/or SPIRITS.

Kind regards and look forward to seeing you in San Diego,

Jim Buller

----------------------------------
 Unisphere Networks,
 7800 Congress Avenue, Suite 100,
 Boca Raton, FL 33487. USA

 (+)1 561 981 7011
----------------------------------

_______________________________________________
SPIRITS mailing list
[email-masked]
http://lists.bell-labs.com/mailman/listinfo/spirits

---

From: Igor Faynberg <[email-masked]>
Date: Thu, 30 Nov 2000 08:40:32 -0500

Jim,

Thanks for your attention and for the note. (I am still on the other
side of the pond you have mentioned, typing the response while at a
meeting). Anyway, here is the response

> Maybe their absense is the cause of confusion, difference of

Thee drafts are individual submissions (as are mine on PINT/IN
requirements), which is why they are not on either PINT or SPIRITS page.
(The I-D section of the IETF page explains the conventions of naming
drafts.) As for the drafts, I read them and saw no problem with them. If
in the first two drafts you change "conroy" to "ietf," I will have no
problem accepting them for PINT (if Steve agrees, of course). As for
SPIRITS, it is up to SPIRITS chairs to accept.  You guys were supposed
to work with Lev (the editor) to include what you wanted to include or
change what you wanted to change. And if you disagreed, you should have
said you did, and it would be better to say it earlier than later. At
the meeting, as I recall, Alec and Steve asked if the Architecture
document is finished, and no one has raised any objection. The the Last
Call was announced, and there were specific on-line proposals made, and
an agreement on changes was made.

Suddenly "remembering" that you need changes after all that is a
somewhat surprising action, but a perfectly legal one from the
procedural point of view. It is up to the chairs to re-open a year-old
discussion, and postpone the real work or declare the rough consensus
and move on.

> 'Initiative system' with 'SCF' if they were so disposed.

Did you discuss that with the editor? Have you proposed to include this
diagram before?

> intending to provide helpful comment to aid reading by a

I agree. From the agreement made on the list this week you can find that
there is going to be specific text explaining the role of the telephone
line. I thought this would make things clear.

> of the PINT RFC, I think it might help.

As I said, if there is a better diagram, and if the editor agrees with
it, I will be happy to include it in my role as a stuckee. But what I
still cannot understand is why this had not been worked on with the
editor before. (I am a proxy, not the editor.)

> it acts as an endpoint itself or 'virtual server'.

Ah, that is an interesting question. We did our best to answer it in the
requirements.

>...

Why "Uh?"? Lev's proposal in Adelaide has identified these interfaces,
and we have been discussing them since then. Please read the
requirements draft, which explicitly says (and has been saying it for a
long time) what is happening at which interface. You may also need to
re-read the Implementation RFC whence the architecture Lev has been
using came.

> >...

The PINT was included for the reasons that have been repeated enough
times not to repeat them once more. (I am afraid I will look like a mad
cow chewing its mad cud.) Steve Bellovin asked me to write PINT
requirements. You may disagree with them or agree with them (but one or
the other, please).  For sure, we could once more discuss them at the
meeting--I would leave it up to the chairmen. Yes, I agree that PINT and
SPIRITS are mirror images, and "Symmetric" and "Mirror Images" are good
terms, but they are well defined only in the context of Geometry (and,
subsequently, Microsoft Power Point). In life and in SPIRITS things are
driven by functional needs, which may differ from what looks good on
viewgraphs.

For example, I have two legs, two arms, but only one head. Had I had two
heads, I would have been much more symmetric, but much less functional,
I am afraid. (Here I think you would agree with me.)

> that requires IN (not just triggers).

Yes, but it is even more complex. In our conversation in September,
Soren mentioned that he wishes to recieve a notification from IN and
then immediately off-load everything to a SIP network. I strongly
believe that this is a valid requirement for SPIRITS. In this case,
there is no need for persistent interactions with IN (and not need for
PINT). (Incidentally, here is one need for the SPIRITS proxy, which will
continue when the client has been forgotten.) And then there are other
options, which will require persistent communications with IN. So, we
have a full spectrum of things that SPIRITS has to deal with, and this
was the main reason--as Lev explained--to have three entities and two
interfaces in SPIRITS. But these are two INTERFACES; whether there are
two PROTOCOLS is an open question.

> As I have stated in the

First of all, PINT DOES require a specific implementation in the PSTN.
It so happened that this implementation exists, as ITU-T has confirmed.
Second, the relation between PINT and SPIRITS has been explored in the
requirement document. 

> when describing services that may use functionality from PINT

Please read the IN-PINT requirements document and see if the reign of
the confusion is over. I also repeat (for the fourth time) an invitation
to contribute to the overall requirements document. I asked you and
Lawrence to provide the extractions from the drafts you wrote to the
overall requirements RFC-to-be and work with the existing de-fact design
team to ensure that the document accomodates you. Again, this is best
done before the Last Call is announced, and especially before the Last
Call has ended.

With thanks for the discussion and best regards,

Igor