Re: [Dime] RFC3588 7.2 Misleading ABNF

[Anders Kristensen <andersk at cisco.com>]

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


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.

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.

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

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

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