Subject: Re: [Sigtran] m3ua- IG

From: "TOLGA ASVEREN" <[email-masked]>
Date: Fri, 10 Jan 2003 10:38:04 +0200

Samuel,

So, what is wrong with this? Those are features of each separate SG
products. Should we try to standardize the feature set supported by each
and every SG?

      Tolga

Tolga,

M3UA RFC must conflict with flexible RKs.If it allows flexible RKs
then somebody may develop M3UA stack with SSN and others may develop
M3UA stack with CIC...

So finally no standards are followed to define RK type which will
lead into confusion in interoperability.

--Samuel

  Alcatel USA, Inc.                  Internet: <userid>@ssd.usa.alcatel.com
  1000 Coit Road, Plano, Texas 75075
  ******* The opinions expressed are not those of Alcatel USA, Inc. *******

On Fri, 10 Jan 2003, TOLGA ASVEREN wrote:

>
> Samuel,
>
> An implementation dependent management functionality, which is
implemented
> without bringing any interoperability problems can decide for the status
of
> subsystems. How this funtionality can be implemented is beyond the scope
of
> M3UA IMO.
>
> RK types are flexible means, type of RKs is not limited by M3UA RFC.
>
>       Tolga
>
>
>
>
>
>              Tolga,
>
>              It means peer M3UA can not recognize whether SSN is
available
>              or congested
>              or unavailable...
>
>              what do you mean by saying "... RK types flexible..."
>
>
>
>
>         --Samuel
>
>           Alcatel USA, Inc.                  Internet: <userid>
>         @ssd.usa.alcatel.com
>           1000 Coit Road, Plano, Texas 75075
>           ******* The opinions expressed are not those of Alcatel USA,
Inc.
>         *******
>
>         On Fri, 10 Jan 2003, TOLGA ASVEREN wrote:
>
>         >
>         > Samuel,
>         >
>         > What does it mean exactly that M3UA supports this or that RK?
One
>         can argue
>         > about how suitable it is to use a certain RK type with M3UA but
>         this IMO is
>         > a different thing. I think the best is to leave RK types
flexible
>         and maybe
>         > with one sentence to warn people about non-MTP3 RK types, that
>         those might
>         > need some management functionalitiy on SG.
>         >
>         >         Tolga
>         >
>         >
>         >
>         >      I think it would be good if we remove all SSN(sub system
>         number)
>         >      references from RFC or make a global statement in IG as
"SSN
>         will not
>         >      be
>         >      supported by RFC 3332 and wherever it is being referred it
>         should be
>         >      ignored"
>         >
>         >      --Samuel
>         >
>         >        Alcatel USA, Inc.                  Internet: <userid>
>         >      @ssd.usa.alcatel.com
>         >        1000 Coit Road, Plano, Texas 75075
>         >        ******* The opinions expressed are not those of Alcatel
>         USA, Inc.
>         >      *******
>         >
>         >
>         >      _______________________________________________
>         >      Sigtran mailing list
>         >      [email-masked]
>         >      https://www1.ietf.org/mailman/listinfo/sigtran
>         >
>         >
>         >
>         >
>         > _______________________________________________
>         > Sigtran mailing list
>         > [email-masked]
>         > https://www1.ietf.org/mailman/listinfo/sigtran
>         >
>
>
>
>
>
> _______________________________________________
> Sigtran mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/sigtran
>

_______________________________________________
Sigtran mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/sigtran

---

From: "Samuel Dur D. Jeyaseelan" <[email-masked]>
Date: Fri, 10 Jan 2003 03:00:25 -0600 (CST)

Tolga,

RK with SSN, RK with CIC - they are not features of SG.
Total RFC strength is on RK.If RK is flexible then why 
RFC would say RK's mandatory and optional parameter,
It could have reserved some space and could have said
'this space can be used for any purpose'.

--Samuel