Skip to main content

Support of Fragmentation of RADIUS Packets
draft-ietf-radext-radius-fragmentation-12

Yes

(Benoît Claise)

No Objection

(Alia Atlas)
(Jari Arkko)
(Pete Resnick)
(Richard Barnes)
(Stephen Farrell)
(Ted Lemon)

Note: This ballot was opened for revision 10 and is now closed.

Benoît Claise Former IESG member
Yes
Yes (for -10) Unknown

                            
Kathleen Moriarty Former IESG member
(was Discuss) Yes
Yes (2015-02-09) Unknown
Thanks for your work on this draft, I also agree that it is well written and placed well as experimental.

Thank you for addressing my prior discuss questions.
Adrian Farrel Former IESG member
No Objection
No Objection (2015-01-17 for -10) Unknown
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/
Alia Atlas Former IESG member
No Objection
No Objection (for -11) Unknown

                            
Barry Leiba Former IESG member
(was Discuss) No Objection
No Objection (2015-01-20 for -11) Unknown
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.
Jari Arkko Former IESG member
No Objection
No Objection (for -11) Unknown

                            
Joel Jaeggli Former IESG member
No Objection
No Objection (2015-01-21 for -11) Unknown
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
Martin Stiemerling Former IESG member
No Objection
No Objection (2015-01-21 for -11) Unknown
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.
Pete Resnick Former IESG member
(was Discuss) No Objection
No Objection () Unknown

                            
Richard Barnes Former IESG member
No Objection
No Objection (for -11) Unknown

                            
Spencer Dawkins Former IESG member
No Objection
No Objection (2015-01-20 for -11) Unknown
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.
Stephen Farrell Former IESG member
No Objection
No Objection (for -11) Unknown

                            
Ted Lemon Former IESG member
No Objection
No Objection (for -11) Unknown