Skip to main content

Last Call Review of draft-ietf-radext-radius-fragmentation-09
review-ietf-radext-radius-fragmentation-09-opsdir-lc-wijnen-2015-01-04-00

Request Review of draft-ietf-radext-radius-fragmentation
Requested revision No specific revision (document currently at 12)
Type Last Call Review
Team Ops Directorate (opsdir)
Deadline 2014-12-25
Requested 2014-12-15
Authors Alejandro Pérez-Méndez , Rafael Marin-Lopez , Fernando Pereniguez-Garcia , Gabriel Lopez-Millan , Diego R. Lopez , Alan DeKok
I-D last updated 2015-01-04
Completed reviews Genart Last Call review of -09 by Meral Shirazipour (diff)
Genart Telechat review of -10 by Meral Shirazipour (diff)
Opsdir Last Call review of -09 by Bert Wijnen (diff)
Assignment Reviewer Bert Wijnen
State Completed
Request Last Call review on draft-ietf-radext-radius-fragmentation by Ops Directorate Assigned
Reviewed revision 09 (document currently at 12)
Result Has issues
Completed 2015-01-04
review-ietf-radext-radius-fragmentation-09-opsdir-lc-wijnen-2015-01-04-00
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