RE: Recommendation for SUA modifications

"Tolga Asveren" <[email protected]>
Newsgroups gmane.ietf.sigtran
Message-ID <[email protected]>
Brian,

> -----Original Message-----
> From: [email protected] [mailto:[email protected]]On
> Behalf Of Brian F. G. Bidulock
> Sent: Wednesday, October 12, 2005 2:43 PM
> To: Tolga Asveren
> Cc: [email protected]
> Subject: Re: [Sigtran] Recommendation for SUA modifications
>
>
> Tolga,
>
> Tolga Asveren wrote:
>                    (Wed, 12 Oct 2005 14:02:19)
> > > Please bear in mind that an ASP is not restricted to sending messages
> > > from the source address that it has registered to receive messages.
> > > For example, if ASP A registers AS 1 with Routing key PC 111
> and SSN 5,
> > > obtaining RC 1, it is permitted to send messages with source address
> > > PC 333 SSN 7 labelled with RC 1.  There is no restriction in
> the ASP->SG
> > > direction for SCON either.
> > [TOLGA]I have a different opinion here based on 4.3.4.3 ASP Active
> > Procedures section.
> > "The ASP SHOULD NOT send Data or SSNM
> > messages for the related Routing Context(s) before receiving an ASP
> > Active Ack message, or it will risk message loss."
> > I know it is not a "MUST NOT" but still it is nota good thing
> to do unless
> > one is aware of consequences and happy with them.
>
> That would be sending messages with RC 1 in them before receiving
> ASP Active
> Ack for RC 1.  That passage does not speak to the addressing of
> the messages.
> Other passages do.  The SG provides uniform connectivity to all
> ASPs in an AS
> and can route any messagew within a Network Appearance.
[TOLGA]Here I still think different, i.e. I consider AS state to be honored
in both directions of message flow based on the above passage-.
>
> --brian
>
> --
> Brian F. G. Bidulock
> [email protected]
> http://www.openss7.org/
>
> _______________________________________________
> Sigtran mailing list
> [email protected]
> https://www1.ietf.org/mailman/listinfo/sigtran
>
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.