Subject: RE: [Sigtran] I-D ACTION:draft-ietf-sigtran-m3ua-implementors-gui de-02.txt

From: "Javier Pastor-Balbas (ECE)" <[email-masked]>
Date: Wed, 15 Jan 2003 15:22:44 +0100

Brian, 

IMHO an implementation supports or not the registration procedures. Supporting some of the messages means increasing the coding without getting any practical advantage. I agree with Tolga on this point: it is not a vital decission, but it makes sense to choose the message class error.

The inclusion of 40 bytes of the message was decided in order to find what message you sent. If you don't do that way you may not find what was the origin of the failure. Since the source of the failure could have been a software bug, you may have produced a lot of messages with the erroneous message class/type and can not find which one was the faulty one. I might help in the debugging process...

Cheers // Javier. 

> -----Original Message-----
> From: Brian F. G. Bidulock [mailto:[email-masked]]
> Sent: Wednesday, January 15, 2003 1:11 PM
> To: TOLGA ASVEREN
> Cc: [email-masked]
> Subject: Re: [Sigtran] I-D
> ACTION:draft-ietf-sigtran-m3ua-implementors-guide-02.txt
> 
> 
> TOLGA,
> 
> TOLGA ASVEREN wrote:                                          
>                        (Wed, 15 Jan 2003 13:35:13)
> > 
> > Brian,
> > > Resend...
> > >
> > > Ken Morneault wrote:
> > > (Thu, 02 Jan 2003 09:05:39)
> > > >
> > > >
> > > > Brian,
> > > >
> > > > Please address your concerns to the entire group
> > > as your proposed
> > > > change is something for all to discuss.
> > > >
> > > > Regards,
> > > >
> > > > Ken
> > >
> > >
> > > SIGTRAN,
> > >
> > > Section 3.2.
> > >
> > > What does it matter if the SGP sends "Unsupported
> > > Message Type" or
> > > "Unsupported Message Class"?  Acutally, if we ever
> > > add a message to the class,
> > > "Unsupport Message Class" might no longer be
> > > correct, whereas "Unsupported
> > > Message Type" survives the addition of new message
> > > types to the class.
> > [TOLGA]Although IMO not very important to send which one 
> still just my 2
> > cents: Personally I would prefer "Unsupported Message 
> Class" because it
> > suits better for the case, where registration procedure and 
> so all of the
> > related messages in the message class is not supported.
> 
> Well, the ASP didn't send every message type in the class, it just
> sent one message type.  It is easy to conceiver that an implementation
> could support DEREG REQ without supporting REG REQ.  When an ASP sends
> DEREG REQ, it is responded to with a DEREG RSP with a Deregistration
> Result indicating "Error - Not Registered".  So it is possible that
> an implementation supports DEREG REQ without supporting REG REQ.
> 
> In fact, an SGP not supporting dynamic registration could easily
> send REG RSP with Registration Result "Error - Unsupported RK 
> parameter
> field" or some such.  Just because an SGP "does not suppor the
> registration procedure" does not mean that it cannot respond to
> any message in the class.
> 
> At best, section 3.2 of the IG needs to be reworked in light of the
> above.
> 
> Comments?
> 
> --brian
> 
> 
> > >
> > > Also, as the only necessary piece of information
> > > given in the Error message
> > > is the Message Class and Type, why force an
> > > implementation to include the
> > > first 40 bytes of the message?  That's ridiculous.
> > > All that needs to be
> > > included a couple bytes of the message header.
> > [TOLGA] For that I agree. For those error types, reporting 
> message class
> > and type should be enough.
> > >
> > > Also, there is no more need to correlate this error
> > > than others.  The
> > > ASP is obviously misconfigured (it figures it can
> > > register with an SGP
> > > that does not even supoprt registration), so it
> > > really doesn't matter
> > > what happens to it: there are many ways to
> > > misconfigure an ASP so that
> > > it will not be caught by the protocol.
> > >
> > > Please strike section 3.2.
> > >
> > > Also note that M2UA and SUA also use the same text.
> > > It makes no sense to
> > > have M3UA act differently in this regard than M2UA
> > > and SUA.
> > 
> > _______________________________________________
> > Sigtran mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/sigtran
> 
> -- 
> Brian F. G. Bidulock
> [email-masked]
> http://www.openss7.org/
> _______________________________________________
> 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: "Brian F. G. Bidulock" <[email-masked]>
Date: Fri, 17 Jan 2003 06:13:12 -0700

Javier,

Javier Pastor-Balbas (ECE) wrote:                                                   (Wed, 15 Jan 2003 15:22:44)
> Brian, 
> 
> IMHO an implementation supports or not the registration procedures.
> Supporting some of the messages means increasing the coding without getting
> any practical advantage. I agree with Tolga on this point: it is not a vital
> decission, but it makes sense to choose the message class error.

If it is not vital, the word "MUST" must go.

> 
> The inclusion of 40 bytes of the message was decided in order to find what
> message you sent. If you don't do that way you may not find what was the
> origin of the failure. Since the source of the failure could have been a
> software bug, you may have produced a lot of messages with the erroneous
> message class/type and can not find which one was the faulty one. I might
> help in the debugging process...

The statement that all error messages SHOULD include the offending message
(and not just the first 40 bytes) should suffice.  The IG decleares a "MUST"
include 40 bytes in contradiction to the SHOULD include the message.  Again,
since it is no more vital than any other error case, the statement should be
struct and the "SHOULD contain the offending message" will apply.

--brian