Subject: Re: [Sigtran] m3ua- IG

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

Samuel,

First of all I consider whether a SG supports this or that type of RK as a
feature of that SG, not as a property of M3UA protocol. M3UA does not work
assuming some special RK type.
IMO, the only place where RK type comes into play is dynamic registration.
And this is natural, because there one tells about the type of the RK. One
has to define some types for registration otherwise how can you tell your
peer what you want? Also please note, RK type not supported case is
handled, so it is not a problem if an ASP asks to register for a SSN based
RK to a SG, which does not support it.

     Tolga

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

  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,
>
> 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
>

_______________________________________________
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:35:40 -0600 (CST)

Tolga,

Agreed.Using flexible RK we support SSN.But How do you handle SSN
congested, SSN unavailable and SSN available ? 
What M3UA message carries these information from ASP to SG?
If you say 'DATA' then what is the need of SUA?

--Samuel