Subject: [Dime] RFC3588 7.2 Misleading ABNF

From: "Tolga Asveren" <[email-masked]>
Date: Thu, 15 Jun 2006 12:26:11 -0400

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.

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.

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

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.

e) [ Origin-state-Id ] [ Proxy-Info ]
Why are they explicitly mentioned?

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
[email-masked]
https://www1.ietf.org/mailman/listinfo/dime

---

From: Yoshihiro Ohba <[email-masked]>
Date: Fri, 16 Jun 2006 11:36:51 -0400

Hi Tolga,

> aren't, and hopefully we can have some cleanup there.

Can you eraborate on why protocols errors must be related only to routing?

> that a relay agent can route it to some other peer. I assume *[ AVP ] stands

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.

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

> and rely on this specific AVP.

Please see my comment above.

> 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

---

From: "Tolga Asveren" <[email-masked]>
Date: Fri, 16 Jun 2006 14:11:55 -0400

Hi Yoshihiro,

Please see my responses inline.

   Thanks,
   Tolga

> > error return result. It is quite
> confusing/misleading/not-optimal (or I got
[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.
> 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)
> nodes, since Origin-Host and Origin-Realm AVPs may be replaced by a
[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?

---

From: Yoshihiro Ohba <[email-masked]>
Date: Fri, 16 Jun 2006 15:33:46 -0400

Hi Tolga,

> DIAMETER_INVALID_HDR_BITS, DIAMETER_INVALID_AVP_BITS are better not treated

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?

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

Yoshihiro Ohba

---

From: "Tolga Asveren" <[email-masked]>
Date: Fri, 16 Jun 2006 17:24:53 -0400

Hi Yoshihiro,

[..snip..]
> 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".
> see a need for the original message to be included in the protocol
[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-.

---

From: Anders Kristensen <[email-masked]>
Date: Fri, 16 Jun 2006 18:00:38 -0400

Some other things that I believe is wrong with the error ABNF:

f) It should say *[Proxy-Info], not [Proxy-Info].

g) Should explicitly allow *[Redirect-Host], [Redirect-Host-Usage], 
[Redirect-Host-Cache-Time] AVPs.

h) Should include [Error-Message].

i) Should include *[Failed-AVP] since presumably a 3009 
(DIAMETER_INVALID_AVP_BITS) error should include the offending AVP 
(although unlike similar error cases this is not mentioned explicitly 
for this error code).

Some comments inline...

> aren't, and hopefully we can have some cleanup there.

This makes some sense to me but I don't know if it can be fixed in a 
backwards compatible manner. It doesn't seem to be important enough to 
break compatibility for.

> that a relay agent can route it to some other peer. I assume *[ AVP ] stands

This was not my impression at all and I don't think there's any text in 
the base spec to back it up. Proxies/relays then have to be stateful in 
order to try another peer and that seems OK to me.

Thanks,
Anders