Subject: Re: [Sigtran] IUA - ASP Active and ACTIVE ACK

From: [email-masked]
Date: Wed, 15 Jan 2003 12:04:23 +0200

"Brian F. G.                                                                         
                      Bidulock"                To:      [email-masked]                             
                      <bidulock@openss         cc:      [email-masked],                  
                      7.org>                   [email-masked], [email-masked],        
                                               [email-masked], [email-masked]                    
                      15/01/03 10:51           Subject: Re: [Sigtran] IUA -  ASP Active and ACTIVE ACK     
                      Please respond                                                                       
                      to bidulock                                                                          

> IUA IG Verion 2 Section 3.16.2 new text for Section 4.3.3.5, third
paragraph.

I see. The paragraph describes only ASP behavior. To be consistent the SG
behavior must be respectively described and section 3.3.2.6 to be changed.
Now 3.3.2.6 says:
   The ASPAC Ack message is used to acknowledge an ASP-Active message
   received from a remote IUA peer.
Personally I do not like to define sending of ACK not triggered by any
request.

>
> Wouldn't it be a good idea to start drafting an RFC3057bis.

In light of interop problems we met till today with different respect to IG
document I'd welcome RFC3057bis.

> Strangely, RFC3331 says in section 3.3.1:
>
>    The "Invalid Interface Identifier" error would be sent by a SGP if an
>    ASP sends a message (i.e. an ASP Active message) with an invalid (not
>    configured) Interface Identifier value.  One of the optional
>    Interface Identifier parameters (Integer-based, text-based or integer
>    range) MUST be used with this error code to identify the invalid
>    Interface Identifier(s) received.
>
> Which again says "not configured."
>
> Now, although RFC3331 (M2UA) says:
>
>                                           ...  The SGP MUST send an
>    Error message ("Invalid Interface Identifier") for each Interface
>    Identifier value that cannot be successfully activated.
>
> This text is not in RFC3057 or the IUA-IG and cannot be considered
applicable
> to IUA.
> For M2UA, failure to activate might not only be caused by
misconfiguration.
> (e.g. failure of switching elements at the SG for automatic allocation of
> signalling terminals or signalling data links or both, no reminaing
signalling
> terminals, etc...).

Thanks for explanation. Not only Error code description in (3.3.1) but also
its "name" does not sound for me covering the cases you have described.

Regards,
Lev

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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 15 Jan 2003 03:25:03 -0700

Lev.Finkel,

[email-masked] wrote:                                                   (Wed, 15 Jan 2003 12:04:23)
> Personally I do not like to define sending of ACK not triggered by any

Sorry, but the unsolicited behavior is permitted by all the UAs.  Section
3.3.2.6 does not need to be changed: it doesn't say "is _only_ used".

> document I'd welcome RFC3057bis.

I really meant just because there are all these modifications strewn across
a number of documents and it is getting difficult to piece the bits together
to get a complete picture.  If we had a RFC3057bis draft, then at least we
could see the changes in one coherent document.

> > This text is not in RFC3057 or the IUA-IG and cannot be considered applicable
> > to IUA.  For M2UA, failure to activate might not only be caused by misconfiguration.
> > signalling terminals or signalling data links or both, no reminaing signalling
> > terminals, etc...).
> >
> 

I agree, but RFC3331 does say "successfully activated" in section 4.whatever.
I would have no problems placing "(not configured)" in section 4.whatever of
RFC3331.  One of the M2UA-IG.

--brian

-- 
Brian F. G. Bidulock
[email-masked]
http://www.openss7.org/