[radext] moving forward with draft-ietf-radext-coa-proxy

[Benjamin Kaduk <[e-mail]>]

Hi all,

Thanks to Alan for submitting a new revision(s) of the draft; I believe that
the -07 contains sufficient changes to resolve the last DISCUSS poinits open
against the document.

I also plan to change the target status to Informational (from Proposed
Standard); it is a little unfortunate to need to do so, but the IESG's
discussions convinced me that this is the sort of thing that the downref
policy was intended to avoid.

There were a few things in the diff between the -05 and -07 that stuck out
to me, though, and might require further changes.

In Section 3.2,

   We also update Section 5 of [RFC5580] to permit CoA-Request and
   Disconnect-Request packets to contain zero or one instances of the
   Operator-Name attribute.

is not reflected in the Updates header and would require WG confirmation
and potentially re-running the IETF LC.
(Also, 5580 is Proposed Standard, so we'd have trouble doing this update
from an Informational document.)  It's somewhat unclear to me exactly what
is being Updated, too, so I'd appreciate a bit of explanation (here in the
email thread).

Section 3.3 introduces a new normative requirement:

   Some Home Networks will not have permission to send CoA packets to
   the Visited Network.  The CoA server SHOULD therefore also validate
   the NAI contained in the User-Name attribute.  If the Home Network is
   not permitted to send CoA packets to this Visited Network, then the
   CoA server MUST return a NAK packet that contains an Error-Cause
   attribute having value 502 ("Request Not Routable").

Can the chairs confirm there is WG consensus for it?

In Section 3.4:

      Implementations supporting this attribute MUST be able to handle
      between one (1) and thirty-two (32) octets of data.
      Implementations creating an Operator-NAS-Identifier MUST NOT
      create attributes with more than sixty-four octets of data.  A
      thirty-two octet string should be more than sufficient for future
      uses.

The bump from 20 to 32 octest is fine, but now we have MUST be able to
handle 32 and MUST NOT generate more than 64, which are different numbers.
(In the -05 the numbers were both 20.)  Where did the 64 come from?

Section 4.2 introduces a new normative requirement:

   The Visited Network MUST also ensure that the CoA packet sent to the
   NAS contains one of the following attributes: NAS-IP-Address, NAS-
   IPv6-Address, or NAS-Identifier.  This step is the inverse of the
   removal required above in Section 3.4.

First off, is this "at least one" or "exactly one"?
And the same question of WG consensus applies.

Thanks,

Ben