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

From: [email-masked]
Date: Wed, 15 Jan 2003 13:45:06 +0200

Brian,

                      "Brian F. G.                                                                         
                      Bidulock"                To:      [email-masked]                             
                      <bidulock@openss         cc:      [email-masked],                  
                      7.org>                   [email-masked], [email-masked],        
                      Sent by:                 [email-masked], [email-masked]                    
                      sigtran-admin@ie         Subject: Re: [Sigtran] IUA -  ASP Active and ACTIVE ACK     
                      tf.org                                                                               

                      15/01/03 12:25                                                                       
                      Please respond                                                                       
                      to bidulock                                                                          

> Lev.Finkel,
>
> [email-masked] wrote:
(Wed, > 15 Jan 2003 12:04:23)

> > > 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.
>
> 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".

I agree. It states that the behavior of SG is implementation dependent (may
be covered in real Implementation Guide, not in protocol definition).
Any way if section 4.3.3.5 updated in future bis draft, then in 3.3.2.8
(not 3.3.2.6 - sorry) would be better to say
  "The ASP Inactive (ASPIA) ACK message is used to acknowledge an ASP
Inactive message
   received from remote IUA peer or to inform the remote IUA peer about
current ASP
   state".
It will also clarify that ASPAC may be replied by ASPIA ACK.
>
> >
> > >
> > > 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.
>
> 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.

What are other docs (except mails) that cover issues not included to the
IG?

>  If we had a RFC3057bis draft, then at least we
> could see the changes in one coherent document.
>

Can you trigger this activity?
>
> > > 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.
>
> 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

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 05:17:33 -0700

Lev,

[email-masked] wrote:                                                   (Wed, 15 Jan 2003 13:45:06)
> 
> > > > 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 ASP Inactive (ASPIA) ACK message is used to acknowledge an ASP Inactive message
>    received from remote IUA peer or to inform the remote IUA peer about current ASP
>    state".

> It will also clarify that ASPAC may be replied by ASPIA ACK.

I agree.

> > > In light of interop problems we met till today with different respect to IG
> > 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

Well, the IUA-IG imports text wholesale from the other UAs.  However, some
of that text is being modified by other IGs.  For RFC3057 in particular it
becomes difficult to understand all the changes without considering the
IUA-IG, the M2UA IG, the M3UA IG, etc.

> Can you trigger this activity?

Well, I could write a draft-*-sigtran-RFC3057bis-00.txt that incorporates the
changes of the IG and pulls in changes from the other IGs.  But I think that
it would take endorsement of the WG and our WG Chair to slate the work.

--brain

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