RE: [Dime] RFC3588 7.2 Misleading ABNF

["Tolga Asveren" <asveren at ulticom.com>]

Hi Yoshihiro,

Please see my responses inline.

   Thanks,
   Tolga

> On Thu, Jun 15, 2006 at 12:26:11PM -0400, Tolga Asveren wrote:
> > RFC3588 7.2 defines the ABNF to be used for answer messages
> with a protocol
> > error return result. It is quite
> confusing/misleading/not-optimal (or I got
> > it wrong what it should be).
> >
> > As the starting assumption, I believe Protocol Errors must be
> related only
> > with routing, i.e. erorrs which are interesting from
> intermediares point of
> > view. Currently there a few errors classiefed as protocl errors, which
> > aren't, and hopefully we can have some cleanup there.
>
> Can you eraborate on why protocols errors must be related only to routing?
[TOLGA]Mainly because I think it is a good idea to have a separate category
only for routing errors ("Routing Erros" would probably be more appropriate
as a name), which is easily detectable by intermediares (I am not claiming
that this is currently the case based on RFC3588, this is just what I think
as a better solution). It is really handy/fast just to check the E-bit on
answers to decide whether Result-Code needs to be examined and wether there
should be another attempt to route the corresponding request. I may be
missing something but I don't see any good reason for a relay agent to
process an error answer message, unless it is related with a routing
decision. IMHO, it is better to send any other type of error answer to the
originator of the request, i.e. DIAMETER_COMMAND_UNSUPPORTED,
DIAMETER_INVALID_HDR_BITS, DIAMETER_INVALID_AVP_BITS are better not treated
on a per-hop basis.
>
> >
> >
> > I think the idea in 7.2 is:
> > a)Protocol error answer message must include the original
> message, e.g. so
> > that a relay agent can route it to some other peer. I assume *[
> AVP ] stands
> > for that.
>
> Since the node that received the answer message would need to keep the
> original request (e.g., to deal with redirect or failover), I don't
> see a need for the original message to be included in the protocol
> error answer message, but I may be missing something.
[TOLGA]I have the impression that pending request queue is mainly to deal
with transport errors rather than with errors on Diameter level. RFC3588
speaks also of removing a request from the pending queue, when an answer is
received for it. It is not spelled clearly but my understanding is that this
removing of request happens regardless of the Result-Code value.( My
understanding on this is based on 5.5.4)
>
> >
> > b)Protocol error answer message must include Result-Code, so that an
> > intermediary can decide what to do with that answer. This is
> why we have {
> > Result Code }.
> >
> > So far so good....
> >
> > c) { Origin-Host } { Origin-Realm }
> > I assume those are *not* the Origin-Host Origin-Realm AVP of
> the original
> > message -7.4 Error-Reporting hints that they aren't-. Why do we
> need them?
> > If for troubleshooting, I would opt for Error-Reporting-Host AVP. When a
> > relay agent receives a protocol error answer, how does it know which
> > Origin-Host/Origin-Realm AVP to remove -there is also a pair for the
> > original message, which should be kept intact-.
>
> Origin-Host AVP and Error-Reporting-Host AVP may point to different
> nodes, since Origin-Host and Origin-Realm AVPs may be replaced by a
> proxy.
[TOLGA]If we consider only routing type of errors (my original comment was
based on this assumption), why would we care about the value in
Origin-Host/Origin-Realm AVP at all? They won't be used for further routing
decisions. Even Error-Reporting-Host seems to be useful only for
troubleshooting purposes.
Maybe the reason is that all answer messages are supposed to have
Origin-Host/Origin-Realm AVPs?

>
> >
> > d) [ Error-Reporting-Host ]
> > It is a good idea to have an AVP for troubleshooting purposes
> -as specified
> > in 7.4-. IMHO, it is better to have this as optional rather
> than a MUST. I
> > think, it is a better idea not ise Origin-Host/Origin-Realm for
> debugging
> > and rely on this specific AVP.
>
> Please see my comment above.
>
> >
> > e) [ Origin-state-Id ] [ Proxy-Info ]
> > Why are they explicitly mentioned?
>
> I guess the reason is that those AVPs are generic enough to be
> included in any answer message regardless of E-bit.
>
> Yoshihiro Ohba
>
>
> >
> >
> > Overall, IMO, 7.2 should have said that protocol error answers
> must include
> > the original message, Result-Code AVP and may include
> Error-Reporting-Host
> > AVP.
> >
> >     Thanks,
> >     Tolga
> >
> >
> >
> >
> > _______________________________________________
> > DiME mailing list
> > DiME at ietf.org
> > https://www1.ietf.org/mailman/listinfo/dime
> >


_______________________________________________
DiME mailing list
DiME at ietf.org
https://www1.ietf.org/mailman/listinfo/dime