Re: [radext] Extended Identifiers: failure modes

[Stefan Winter <[e-mail]>]

Hello,

thanks for the clarification.

In this case - manual configuration is considered in scope -, both need
to be prepared for particular scrutiny of their respective failure modes.

The considerations in RFC5706 are of course valid for every draft in the
IETF; but they are even more in the focus of the Operations & Management
area, as the Appendix A of that RFC is what the Ops Directorate uses for
its OPSDIR reviews during IETF Last Call.

Failure Management is an explicit item to look out for, and the
pertinent question is:

"Does the solution have failure modes that are difficult to diagnose or correct?"


If there were only one draft, I'd happily care about this after WG
adoption. But considering that there are two competing concepts where
one of the main differences is apparently on this very question, and
where the difference is rooted in the /concept/ (i.e. not easy to fix
with draft revisions later on), I believe it makes sense to highlight
this right now.

We have seen many arguments going back and forth on this topic. I'm
trying to summarise those below.

The failure modes possible in draft-dekok
a) are always local to the client/server pair that tries to communicate
b) are harder to see during packet inspection of the request; need to
correlate request and response
c) correction of faulty configuration requires action of admnistrators
of two adjacent RADIUS nodes who are usually in contact with each other,
or even in the same administrative domain

The failure modes possible in draft-chen
a) possibly transpire over an arbitrary amount of proxies
b) are easier to see in a packet inspection in the request; no need to
correlate request and response
c) correction of faulty configuration requires interaction of all
administrators along the affected proxy chain, who are not necessarily
otherwise in direct contact

(IOW, two distinct arguments made earlier, "easier to debug" vs. "stay
local", actually both relate to the same topic of failure modes and
their remediation)

In that light, it would seem that neither of the two drafts are perfect.
draft-dekok has harder debugging on the local link, draft-chen may
involve parties across "the internet" (or rather the subset of RADIUS
servers on it).  In the end, the question is which failure mode is "less
difficult" to handle.

Greetings,

Stefan Winter

Am 14.12.2017 um 15:43 schrieb Stefan Winter:
> Hello,
>
>
> there is one question to which the answer did not become entirely clear
> in the discussion so far.
>
>
> Could the authors of the respective drafts please clearly indicate the
> answer to this question:
>
>
> Is a manually configured mode of operation considered in scope?
>
>
> I.e. do you consider it a valid use case that an implementation presents
> administrators with a configuration option "Enable Extended
> Identifiers", and that the implementation starts making use of that
> feature /without/ a capability negotiation using Status-Server with its
> next-hop peer?
>
>
> Greetings,
>
>
> Stefan Winter
>
>