RE: SE-IPSP definition

Tolga,
See below...

Pete

> >
> > Tolga,
> > Concerning text clean up I see a couple of references to
> > C-IPSP/D-IPSP that I assume should be removed.
> > I also noticed several English problems with the numbered
> > items at the start of 4.3. I can send updated text if you
> > would like.
> [TOLGA]Ken/Javier are the authors, i.e. the text is not under 
> my control.
> OTOH based on Ken's last message, I have the impression that 
> we can't have
> non-editorial changes anymore(?) Otherwise I would like to 
> see C-IPSP/D-IPSP
> to be cleaned up as well.

PMH - I would have hoped this was editorial... :-)


> >
> > Reading this thread the problem I see with SE procedures was
> > identified in a mail where Brian said:
> > >If you want both IPSPs to each have an AS an traffic mode, 
> use DE instead
> > of SE.
> > Thus I understand there are situations where SE mode cannot be
> > used. This is not clear in RFC.
> [TOLGA]No, this is not true, one can use SE-IPSP for any 
> scenario. IMO, that
> traffic mode can't be specified bothways is something we need 
> to add to the
> specification.

PMH - to my view, the fact that traffic mode can't be specified bothways
makes SE probably un-usable in some situations.  But from what you
say its too late to add anything to the RFC to deal with this.

> >
> > Concerning the inapplicability of SSNM message in IPSP 
> mode, I definately
> > think it would help if this was explicitly stated - this has been a
> > subject on significant discussion in some fora.
> [TOLGA]Ken, is it possible to have the following modification:
> In 3.1.2 Message Classes and Types:
>   SS7 Signalling Network Management (SSNM) Messages (See Section
>       3.4)(Note: SSNM is not used for IPSP communication)
> 
> I believe the above change could be considered as "editorial". ;-)

PMH -  that would be a good change.

>