Re: [radext] draft-cullen-radextra-status-realm-00

[Terry Burton <[e-mail]>]

Regarding draft-cullen-radextra-status-realm-00.


Section 4.2: "When a RADIUS Proxy receives a RADIUS Request packet, it
checks to see if the Request contains a Server-Identifier attribute
indicating that it has already processed this packet. If so, it
discards the packet. If not, it adds its own Server Identifier to the
packet before forwarding it."

Should consideration be given to MTU constraints that may be
encountered by increasing the hop-by-hop packet size?


Section 6: "If the Max-Hop-Count attribute is present and the value is
zero, the Request MUST NOT be forwarded and an error response SHOULD
be returned, as appropriate to the request type."

May be beneficial to define the appropriate behaviour for each request type:

  - Access-Request: What error should go in an Access-Reject?
  - Accounting-Request: Presumably we don't actually want to send an
accounting response? (vs "SHOULD be returned.")
  - Status-Realm-Request: As explained elsewhere,
Status-Realm-Response with Response-Code = 4 ("Max-Hop-Count
exceeded").
  - CoA: ...


Section 7:

Status-Realm-Response-Code table needs work:

  - 256 is missing.
  - Is there an intended difference between 3 and 259?
  - 260 has multiple definitions.

Assuming that 5-255 means temporary reachability issue and 260-511
means "internal error" (may or may not be reachable), i.e. differing
semantics rather than extension of the same range.

Is the intent to allow automation on the basis of the Status-Realm, or
only to support administration?

If the former, to avoid ossification it may be worth splitting the
values into ranges against which one might associate differing
behaviours, e.g. Temporary path faults (e.g. "definately
unreachable"), temporary configuration faults (e.g. "unable to
dynamically look up a realm"), permanent configuration "faults"
(invalid realm / prohibited realm), unexpected errors. New definitions
can be added to the appropriate range.

Are there recommended policy behaviours for "realm unreachable",
"status unknown" and "reserved"?


Section 15:

Might be worth extending the table of attributes (or add another
table) to show other types of request Max-Hop-Count and
Server-Information are valid for.


Thanks.