RE: [Dime] RFC3588 7.2 Misleading ABNF

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

Hi Yoshihiro,


[..snip..]
> The purpose of E-bit is to indicate that an error is detected AND the
> answer message does not contain the set of AVPs supposed to be
> included for normal answer.
>
> What you are suggesting here is changing the purpose of E-bit to
> indicate that a *routing error* is detected AND the answer message
> does not contain the set of AVPs supposed to be included for normal
> answer.  What happens if a *non-routing error* is detected AND the
> answer message does not contain the set of AVPs supposed to be
> included for normal answer?
[TOLGA]The way you described seems to be the case and I don't have a strong
opinion on using E-bit to detect routing errors. I strongly believe that
relay agents shouldn't care about non-routing errors though, E-bit was just
an easy way to detect such errors but relays can investigate Result-Code AVP
as well. One problem with the grouping in 7.1.3 is that it ties use of E-bit
with per-hop treatment, which is not a good idea AFAICS.

The use of E-bit seems quite arbitrary as well. What makes "DIAMETER INVALID
AVP BITS" answers  not to contain necessary answer AVPs whereas "DIAMETER
INVALID AVP BIT COMBO" answers do contain such AVPs? What is the criteria to
decide whether an answer should comply or not with expected answer ABNF?

I would think as a general rule for error answers, there is no need to
conform to the ABNF specification for the command, unless the AVPs in that
ABNF are necessary to interprete the error, e.g. we probably wouldn't need
the whole set of AVPs if there is a missing AVP, just the missing AVP in
Failed-AVP AVP. Does this make sense?

If the answer is "yes", it seems almost every error in base protocol would
fall into E-bit category -probably except errors which are more related with
application logic rather than the core base functionality like
decoding/encoding/routing messages, e.g. "DIAMETER AUTHENTICATION REJECTED".
>
> > >
> > > >
> > > >
> > > > 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)
>
> When the node remove the request from the queue when it receives an
> answer, the node can extract the original message.  So again I don't
> see a need for the original message to be included in the protocol
> error answer message.
[TOLGA]I think this is quite related with implementation decisions and the
"node" may be implemented according to a layered architecture where
transport related procedures are not tightly coupled with Diameter related
functionality. In any case, the way you suggested should work  -maybe not as
good for some implementations as for other ones-.


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