Support of Fragmentation of RADIUS Packets
RFC 7499

Thank you for positioning this as Experimental and for writing sections 2 and 3: they cleared up any concerns I had.

In section 3 you say:
   Instead, the CoA client MUST send a CoA-Request
   packet containing session identification attributes, along with
   Service-Type = Additional-Authorization, and a State attribute.
   Implementations not supporting fragmentation will respond with a CoA-
   NAK, and an Error-Cause of Unsupported-Service.
Since this is not new behaviour (i.e. an implementation that is not part of this experiment will follow this behaviour according to previous specifications), a reference would be nice. Perhaps...
s/the CoA client MUST/according to [RFCfoo] the CoA client will/

This seems a very well written document, and was easy to read.  In particular, thanks very much for Section 2: it's one of the best of that sort of explanation I've seen, and should be a model for other such specs.

Version -11 addresses all the minor comments I had; thanks.

bert Wijnen's opsdir review which I think was adequately discussed.

I did the OPS-DIR review for document
    draft-ietf-radext-radius-fragmentation-09

Such OPS-DIR reviews focus on operational (operator) and management aspects.

I notice that there is a section:

  12.  Operational considerations

But the considerations do (if I understand it correctly) not describe
any considerations for operating or managing the Internet network.
They have to do with the process of knowing/assigning new values or
flags in  the "Reserved" field of the "Long Extended Type"
attribute [RFC6929].

So trhat seems to be more of a ietf-process consideration than an
operational consideration. Since we often do use a section name of
"Operational Considerations:" to describe considerations that
network operators must understand and/or be aware of, it may be
confusing for readers of this document.
Maybe a solution is to rename section 12 to "Future IETF document
considerations" or some such ??

nit and/or minor question:

I wondered about:

   2.  Status of this document

   This document is an Experimental RFC.  It defines a proposal to allow
   sending and receiving data exceeding the 4096 octet limit in RADIUS
   packets imposed by [RFC2865], without requiring the modification of
   intermediary proxies.

I thought that one would never describe inside a document that it is experimental,
do we? The status I thought was an external tag, no?
Anyways, given the content of section2, it is fine. That text will need to be changed
anyways if this ever advances onto standards track.

Bert Wijnen

A well-written document and thank you for being an experimental document.

Looking forward to reports from the wild how good or bad it works.

I echo Adrian's thanks for positioning this as Experimental, and describing what the experiment is.

I echo Barry's "well-written document".

I'm delighted to read this text:

12.4.  Transport behaviour

   This proposal does not modify the way RADIUS interacts with the
   underlying transport (UDP).  That is, RADIUS keeps following a lock-
   step behaviour, that requires receiving an explicit acknowledge for
   each chunk sent.  Hence, bursts of traffic which could congest links
   between peers are not an issue.