Re: Contradiction in M3UA (rfc 4666) error-codes definition and suggested usage

Hi Brian,
>From where I can find the WGLC comments you were mentioned about.

With regards
Ravi J Sharma
Aricent Communications Software


On 2/19/07, Brian F. G. Bidulock <[email protected]> wrote:
> Ravi,
>
> Look back at the WGLC comments: the contradiction is there by
> "concensus".  IMO RFC 4666 is of particularly poor technical
> quality; its predecessor, RFC 3332 of much higher quality.
> The best way to correct RFC 4666 is to discard it and start
> again.
>
> --brian
>
> Ravi Sharma wrote:                                 (Mon, 19 Feb 2007 16:39:21)
> > Hi ,
> > The M3UA rfc 4666 section 3.8.1 describes error code 0x19(Invalid
> > Routing Context)
> > and 0x1a(No Configured AS for ASP) as following:
> > ---------------------------------------------------------------------------------------------------------------
> >    The "Invalid Routing Context" error is sent if a message is received
> >    from a peer with an invalid (unconfigured) Routing Context value.
> >    For this error, the invalid Routing Context(s) MUST be included in
> >    the Error message.
> >
> >    The "No Configured AS for ASP" error is sent if a message is received
> >    from a peer without a Routing Context parameter and it is not known
> >    by configuration data which Application Servers are referenced.
> > ---------------------------------------------------------------------------------------------------------------
> >
> > But in section 4.3.4.3 ( ASP Active Procedures) of same rfc states the usage of
> > the above mentioned error-code with a totally inverse interpretation. Following
> > are the concerned paragraphs of rfc.
> > ---------------------------------------------------------------------------------------------------------------
> >    - If the RC parameter is included in the ASP Active message and a
> >      corresponding RK has not been previously defined (by either static
> >      configuration or dynamic registration), the peer MUST respond with
> >      an ERROR message with the Error Code "No configured AS for ASP".
> > -
> > -
> > -
> > -
> >    - If the RC parameter is not included in the ASP Active message and
> >      there are no RKs defined, the peer node SHOULD respond with and
> >      ERROR message with the Error Code "Invalid Routing Context".
> > ---------------------------------------------------------------------------------------------------------------
> >
> > Whereas, the suggested usage of these error codes in section  4.3.4.4
> > (ASP Inactive
> > Procedures) is very much in-line with the error-code definitions( in
> > section 3.8.1).
> > Following are the paragraphs from section 4.3.4.4.
> > ---------------------------------------------------------------------------------------------------------------
> >       - If the received ASP Inactive message contains an RC parameter
> >         that is not defined (by either static configuration or dynamic
> >         registration), the SGP/IPSP MUST respond with an ERROR message
> >         with the Error Code "Invalid Routing Context".
> > -
> > -
> > -
> > -
> >       - If the received ASP Inactive message does not contain an RC
> >         parameter and the RK is not defined (by either static
> >         configuration or dynamic registration), the SGP/IPSP MUST
> >         respond with an ERROR message with the Error Code "No configured
> >         AS for ASP".
> > ---------------------------------------------------------------------------------------------------------------
> >
> > I think, the ASP Active Procedures defined in rfc 4666 should suggest the same
> > error-codes to communicate to peer in exceptional scenarios as the ASP Inactive
> > Procedure suggest for similar scenarios.
> >
> > Is there any specific reason for the contradiction of error-code
> > definitions and
> > their suggested usage in ASP Active procedures?
> >
> > With regards,
> > Ravi J. Sharma
> > Aricent Communications Software.
> >
> > _______________________________________________
> > Sigtran mailing list
> > [email protected]
> > https://www1.ietf.org/mailman/listinfo/sigtran
>
> --
> Brian F. G. Bidulock
> [email protected]
> http://www.openss7.org/
>