[radext] Ben Campbell's No Objection on draft-ietf-radext-coa-proxy-06: (with COMMENT)

[Ben Campbell <[e-mail]>]

Ben Campbell has entered the following ballot position for
draft-ietf-radext-coa-proxy-06: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-radext-coa-proxy/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

I'm clearing my DISCUSS based on discussion over email and in the telechat. I
am happy to leave the outcome to Benjamin's discretion. I'm including the
original text below for reference:

<old-discuss>
(This is a procedural DISCUSS. Hopefully it can be resolved easily, but I do
think it needs to be resolved prior to publication..)

This draft is standards track, yet it primarily serves to extend RFC 5176. That
RFC is informational. The shepherd writeup argues that this is okay because it
seems like 5176 should have been standards track. But the applicability
statement RFC 5176 explains why it was informational, and the reasons seem
convincing. Therefore I do not think it is appropriate to publish this draft as
Standards Track. I think it would be fine to progress it as Informational (or
even Experimental) if it included an applicability statement explaining why in
order to avoid the appearance of a standard masquerading as an Informational
RFC. </old-discuss>

Thanks for a readable and understandable drafts. I have some additional
comments that do not rise to the level of a DISCUSS

Substantive Comments:

- I support Adam's DISCUSS point concerning the security properties of
Operator-NAS-Identifier. But I will let that play out in Adam's thread.

§3.1 and §3,3: Do the normative changes to Access-Request and
Accounting-Request mean that this draft needs to update documents other than
just RFC 5176?

Editorial Comments:

- The abstract and introduction explain how this draft updates 5176, which is
good. However, they avoid using the explicit term-of-art "Updates RFC 5176".
Doing so would help make things more explicit. (The RFC style guide recommends
doing this at least in the abstract.)

- Please expand PPTP and L2TP on first mention.

§3.1: I suspect some of the normative keywords in this section refer to
previously existing requirements rather than new requirements. If  so, they
should not be capitalized except in literal quotes.

§6: I think it would be helpful to mention the discussion in §4.3 in the
security considerations.

§7: It would be helpful for the IANA considerations to briefly summarize the
new attributes, so that a reader that started out reading the IANA
considerations doesn't have to flip back to §3.3 just to find out what they are.