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

[Ballot comment]
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.

[Ballot comment]
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

[Ballot comment]
bert's opsdir review

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

[Ballot discuss]
I have no concerns with the technical content of the document; I did a quick review, and nothing causes concern. But I do want to briefly DISCUSS a procedural point. I am quite sure I will clear the DISCUSS on the call.

The issue of "Updates" worries me a bit. Here's the part that concerned me:

  Note that if this experiment does not succeed, the
  "T" flag allocation would not persist, as it is tightly associated to
  this document.

That's true, but using Updates will mean that RFC 6929 will *always* have an "Updated By" pointer pointing to this Experimental RFC. That itself could cause serious confusion, and would likely result in the "T" allocation never being able to be used again.

I really don't think this document needs to, or should, update the other documents. 2865 and 6158 are only being updated because this document violates a MUST and a SHOULD. But it's an experiment. Any implementation of 2865 or 6158 not participating in the experiment is going to need to honor those MUSTs and SHOULDs. There's no real reason to call out this update to people who are only looking at those two documents. 6929 is a bit trickier, because of the issue of other folks trying to use the reserved value, but as you say in the document: "not such a great number of specifications extending that field are expected." If/when this document goes to Standards Track, that's the time to let people know. If there's a real fear of this experiment interfering with other implementations, it really is time to make the registry. Finally, I'm concerned about the precedent of Experimental documents updating Standards Track and BCP docs, especially on the grounds provided. Perhaps there's a case for that to happen once in a while, but we don't want pointers to possibly failed experiments to be in the meta-data forever.

Like I said, we can sort this on the call pretty quickly. But I want to make sure we understand the implications here.

[Ballot discuss]
In the security considerations section, I didn't see a discussion on packet re-assembly and associated security issues such as overlapping fragments.  If there is a reference that already covers that in the draft, I missed it and would appreciate you pointing me to it.

In a quick search, I found a couple of references that may be useful for some text/reference on details of this attack type,  but are at the IP layer.  The draft already prevents other attack types that involve ordering and size of fragments with lengths included, so this is just meant to ask about overlapping fragments.

Section 4 of: https://tools.ietf.org/html/rfc1858
https://tools.ietf.org/html/draft-ietf-6man-overlap-fragment-03

Examples might overlap to change any part of the AAA data once reassembled.

[Ballot comment]
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.

[Ballot comment]
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.

[Ballot comment]
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.

[Ballot discuss]
This is just to make sure that the IANA allocations are clear, because I have some questions about that:

-- Section 14 --

  In particular, this document defines two new RADIUS attributes,
  entitled "Frag-Status" and "Proxy-State-Len" (see section 9),
  assigned values of TBD1 and TBD2 from the Long Extended Space

But these are not defined in Section 9, but in Sections 10.1 and 10.2.

And I see that these are the "Type" values, but where's the allocation of the "Extended-Type" values that are mentioned in those sections?

Also, there's another "TBA" at the end of Section 14 that points to Section 4.1, but there is no Section 4.1.  It looks like maybe that's supposed to be 5.1.

[Ballot comment]
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.

Very minor point: In the diagram in Section 3, I suggest fitting all the boxed text as in the box that includes "CoA Proxy".  That is, putting "CoA" on top of "Server" and "client" (why not "Client"?) in the other boxes makes the separation between the left-side text and the right-side text just a little clearer.

-- Sections 10.1 and 10.2 --
It's not clear to me how the RFC Editor will know which values to replace into the four "TBA" items in these sections (two "Type" and two "Extended-Type" values).  Shouldn't they be distinguished from each other, to make that clear?  (And see my DISCUSS comments.)

[Ballot comment]
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/

IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-radext-radius-fragmentation-09.  Authors should review the comments and/or questions below.  Please report any inaccuracies and respond to any questions as soon as possible.

IANA's reviewer has the following comments/questions:

IANA understands that, upon approval of this document, there are three actions which need to be completed.

First, in the Radius Attribute Types subregistry of the Radius Types registry at

https://www.iana.org/assignments/radius-types/

two new radius types will be registered as follows:

Value: [ TBD-at-registration ]
Name: Frag-Status
Reference: [ RFC-to-be ]

Value: [ TBD-at-registration ]
Name: Proxy-State-Len
Reference: [ RFC-to-be ]

IANA understands that these new registrations are to come from the Long Extended Space ranges of the registry. IANA will consult with the authors on appropriate values to register at the time of approval of the document.

Second, a new sub-registry for the radius type for "Frag-Status" above will be created called "Code Values (Attribute [ TBD-at-registration ], Frag-Status" and located in:

https://www.iana.org/assignments/radius-types/

The new registry will be managed through RFC Required as defined in RFC 5226. These are the initial registrations:

Value Frag-Status Code Name Reference
---- ------------------------ ----------
0 Reserved [ RFC-to-be ]
1 Fragmentation-Supported [ RFC-to-be ]
2 More-Data-Pending [ RFC-to-be ]
3 More-Data-Request [ RFC-to-be ]
4-255 Unassigned

Third, in the Values for RADIUS Attribute 6, Service-Type sub-registry also in the Radius Types registry at

https://www.iana.org/assignments/radius-types/

a new value will be registered as follows:

Value: [ TBD-at-registration ]
Description: Additional-Authorization
Reference: [ RFC-to-be ]

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is only to confirm what actions will be performed.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Support of fragmentation of RADIUS packets) to Experimental RFC


The IESG has received a request from the RADIUS EXTensions WG (radext) to
consider the following document:
- 'Support of fragmentation of RADIUS packets'
  as Experimental RFC

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2014-12-25. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  The Remote Authentication Dial-In User Service (RADIUS) protocol is
  limited to a total packet size of 4096 octets.  Provisions exist for
  fragmenting large amounts of authentication data across multiple
  packets, via Access-Challenge.  No similar provisions exist for
  fragmenting large amounts of authorization data.  This document
  specifies how existing RADIUS mechanisms can be leveraged to provide
  that functionality.  These mechanisms are largely compatible with
  existing implementations, and are designed to be invisible to
  proxies, and "fail-safe" to legacy RADIUS Clients and Servers.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-radext-radius-fragmentation/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-radext-radius-fragmentation/ballot/


No IPR declarations have been submitted directly on this I-D.

PROTO write-up for draft-ietf-radext-radius-fragmentation-08
============================================================
(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header?

This document is aiming for Experimental status. This is the correct choice because it
proposes complex changes to the RADIUS operational model to achieve transmission
of payload sizes beyond the current maximum (4096 bytes). It aims for backward
compatibility when being transmitted over legacy intermediate proxy systems which are
not yet upgraded to support the requirements of this document. The real-life suitability
of these changes needs further study; hence Experimental. There are other
approaches to the same problem discussed in the working group, but they are not
backwards compatible to non-upgraded proxies.

(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:

Technical Summary:

  The Remote Authentication Dial-In User Service (RADIUS) protocol is
  limited to a total packet size of 4096 octets.  Provisions exist for
  fragmenting large amounts of authentication data across multiple
  packets, via Access-Challenge.  No similar provisions exist for
  fragmenting large amounts of authorization data.  This document
  specifies how existing RADIUS mechanisms can be leveraged to provide
  that functionality.  These mechanisms are largely compatible with
  existing implementations, and are designed to be invisible to
  proxies, and "fail-safe" to legacy clients and servers.

Working Group Summary:

  The content of this document was discussed at length in the working
  group, and there are multiple other approaches to the same problem.
  The document thus got significant exposure at the experts of the
  working group. The document has a few rough edges which were the cause
  of discussions. Considering the target status of Experimental, they
  appear minor enough to carry on with the experiment. The authors have
  documented the friction points in their section 11 "Operational
  Considerations". 11.1 in particular shows a process question: is it
  appropriate for an Experimental RFC to update a Standards-track RFC?
  The document attempts to follow that course; if this is ultimately
  agreed after IESG review, the text in that section will be changed
  accordingly.

Document Quality:

  At least one implementation is known which implements this
  specification: FreeRADIUS. The sheperd has no information about plans of
  other vendors. There were no particular expert reviews outside the
  working group process; i.e. no MIB doctor review nor Media Type review
  (and no need for those two as the document contains neither MIBs nor
  requests a Media Type). Since the document adds new transport
  capabilities, a thorough review by transport experts (e.g. TSVDIR) during
  IETF Last Call would be appreciated.

Personnel:

  The Document Shepherd is Stefan Winter . The
  responsible Area Directors are Benoit Claise <​bclaise@cisco.com> and Joel
  Jaeggli <​joelja@bogus.com>.

(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.

The sheperd was actively reviewing the document during its entire lifecycle, back then
as individual participant in the WG (now chair). For the PROTO write-up, he gave the
then-latest version -06 a fresh read; which resulted in a number of minor changes
which are now the -08 version which is ready for advancement in the publication
process.

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?

No concerns; the document was read by and commented on by a comparatively high
number of participants.

(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.

The document addresses a very specific RADIUS shortcoming and this document's
impact does not appear to matter from a broader perspective at first glance. However,
the document introduces a new transport property for RADIUS (fragmentation support)
which deserves a close look by transport area experts. There may be issues with
traversing AAA proxies which are unaware of this document, but those issues have
been uncovered during the WG review process and are enumerated in section 11.

(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.

The issue described in 11.1 had no final conclusive answer; i.e. is it better to a) have
this document update a standards-track document, or b) have an IANA registry for the
flag field assignments, or c) just do nothing. The working group consensus went for a),
which is fine IMO, but the text in 11.1 will need to be updated with more confident
language once it is determined if that course of action is acceptable process-wise.

From a more general point of view, the entire solution is rather bulky and not very
elegant; but it solves an actual problem and operates despite possible presence of
unaware proxies on the path, which is a significant plus.

(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?

During the PROTO Write-Up, the sheperd asked each author and they all confirmed
that they have no outstanding IPR disclosures.

(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.

There was no IPR disclosure.

(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?

There is one group of individuals which was pushing for this document: the ABFAB WG
and implementers of the corresponding specs needed this solution and so far, use
cases beyond ABFAB have yet to surface. Naturally, these participants were most
active and drove most of the discussions. However, more participants than just those
were reviewing and commenting on the document, so there is solid consensus behind
the document.

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If
so, please summarise the areas of conflict in separate email messages to the
Responsible Area Director. (It should be in a separate email because this questionnaire
is publicly available.)

There was one individual who expressed major disconsent during the call for adoption,
and also on various design choices before and after adoption. There was no threat of
appeal though.

(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.

"The 'Updates: ' line in the draft header should list only the _numbers_
    of the RFCs which will be updated by this document (if approved); it
    should not include the word 'RFC' in the list."

There is a dangling reference [IANA-CONSIDERATIONS] (section pointer) which
can be fixed later in the publication process.

(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews.

There are no MIBs, media types, or URI requests in this document.

(13) Have all references within this document been identified as either normative or informative?

Yes.

(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?

All normative references are issued RFCs.

(15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.

There are no downward normative references (1 x Informational, 2 x BCP, 3 x standards-track).

(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary.

This document updates RFC6929. That document is mentioned in the introduction, but
not the abstract. The reason why it is omitted in the abstract is because the relationship
is relatively minor (a previously reserved flag is defined for use in this document) and
because there are two dedicated sections (8 + 11.1) which explain the update
relationship in considerable detail.

(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 5226).

The document introduces two new attributes, one new value for an existing attribute,
and a registry for an enumeration of values for one of those new attributes. The IANA
consideration section contains all the info required by IANA to perform the reservations
in question. Future allocations of the new registry are defined (RFC required). The
name for the registry ('RADIUS Frag-Status "Code" registry') is reasonable.

(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.

The new registry is 'RFC required'; no experts needed.

(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, etc.

There are no formal language constructs in the document.

PROTO write-up for draft-ietf-radext-radius-fragmentation-08
============================================================
(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header?

This document is aiming for Experimental status. This is the correct choice because it proposes complex changes to the RADIUS operational model to achieve transmission of payload sizes beyond the current maximum (4096 bytes). It aims for backward compatibility when being transmitted over legacy intermediate proxy systems which are not yet upgraded to support the requirements of this document. The real-life suitability of these changes needs further study; hence Experimental. There are other approaches to the same problem discussed in the working group, but they are not backwards compatible to non-upgraded proxies.

(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:

Technical Summary:

  The Remote Authentication Dial-In User Service (RADIUS) protocol is
  limited to a total packet size of 4096 octets.  Provisions exist for
  fragmenting large amounts of authentication data across multiple
  packets, via Access-Challenge.  No similar provisions exist for
  fragmenting large amounts of authorization data.  This document
  specifies how existing RADIUS mechanisms can be leveraged to provide
  that functionality.  These mechanisms are largely compatible with
  existing implementations, and are designed to be invisible to
  proxies, and "fail-safe" to legacy clients and servers.

Working Group Summary:

  The content of this document was discussed at length in the working
  group, and there are multiple other approaches to the same problem.
  The document thus got significant exposure at the experts of the
  working group. The document has a few rough edges which were the cause
  of discussions. Considering the target status of Experimental, they
  appear minor enough to carry on with the experiment. The authors have
  documented the friction points in their section 11 "Operational
  Considerations". 11.1 in particular shows a process question: is it
  appropriate for an Experimental RFC to update a Standards-track RFC?
  The document attempts to follow that course; if this is ultimately
  agreed after IESG review, the text in that section will be changed
  accordingly.

Document Quality:

  At least one implementation is known which implements this
  specification: FreeRADIUS. The sheperd has no information about plans of
  other vendors. There were no particular expert reviews outside the
  working group process; i.e. no MIB doctor review nor Media Type review
  (and no need for those two as the document contains neither MIBs nor
  requests a Media Type). Since the document adds new transport
  capabilities, a thorough review by transport experts (e.g. TSVDIR) during
  IETF Last Call would be appreciated.

Personnel:

  The Document Shepherd is Stefan Winter . The
  responsible Area Directors are Benoit Claise <​bclaise@cisco.com> and Joel
  Jaeggli <​joelja@bogus.com>.

(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.

The sheperd was actively reviewing the document during its entire lifecycle, back then as individual participant in the WG (now chair). For the PROTO write-up, he gave the then-latest version -06 a fresh read; which resulted in a number of minor changes which are now the -08 version which is ready for advancement in the publication process.

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?

No cencerns; the document was read by and commented on by a comparatively high number of participants.

(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.

The document addresses a very specific RADIUS shortcoming and this document's impact does not appear to matter from a broader perspective at first glance. However, the document introduces a new transport property for RADIUS (fragmentation support) which deserves a close look by transport area experts. There may be issues with traversing AAA proxies which are unaware of this document, but those issues have been uncovered during the WG review process and are enumerated in section 11.

(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.

The issue described in 11.1 had no final conclusive answer; i.e. is it better to a) have this document update a standards-track document, or b) have an IANA registry for the flag field assignments, or c) just do nothing. The working group consensus went for a), which is fine IMO, but the text in 11.1 will need to be updated with more confident language once it is determined if that course of action is acceptable process-wise.

From a more general point of view, the entire solution is rather bulky and not very elegant; but it solves an actual problem and operates despite possible presence of unaware proxies on the path, which is a significant plus.

(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?

During the PROTO Write-Up, the sheperd asked each author and they all confirmed that they have no outstanding IPR disclosures.

(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.

There was no IPR disclosure.

(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?

There is one group of individuals which was pushing for this document: the ABFAB WG and implementers of the corresponding specs needed this solution and so far, use cases beyond ABFAB have yet to surface. Naturally, these participants were most active and drove most of the discussions. However, more participants than just those were reviewing and commenting on the document, so there is solid consensus behind the document.

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)

There was one individual who expressed major disconsent during the call for adoption, and also on various design choices before and after adoption. There was no threat of appeal though.

(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.

"The 'Updates: ' line in the draft header should list only the _numbers_
    of the RFCs which will be updated by this document (if approved); it
    should not include the word 'RFC' in the list."

There is a dangling reference [IANA-CONSIDERATIONS] (section pointer) which
can be fixed later in the publication process.

(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews.

There are no MIBs, media types, or URI requests in this document.

(13) Have all references within this document been identified as either normative or informative?

Yes.

(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?

All normative references are issued RFCs.

(15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.

There are no downward normative references (1 x Informational, 2 x BCP, 3 x standards-track).

(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary.

This document updates RFC6929. That document is mentioned in the introduction, but
not the abstract. The reason why it is omitted in the abstract is because the relationship
is relatively minor (a previously reserved flag is defined for use in this document) and
because there are two dedicated sections (8 + 11.1) which explain the update
relationship in considerable detail.

(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 5226).

The document introduces two new attributes, one new value for an existing attribute,
and a registry for an enumeration of values for one of those new attributes. The IANA
consideration section contains all the info required by IANA to perform the reservations
in question. Future allocations of the new registry are defined (RFC required). The
name for the registry ('RADIUS Frag-Status "Code" registry') is reasonable.

(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.

The new registry is 'RFC required'; no experts needed.

(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, etc.

There are no formal language constructs in the document.

PROTO write-up for draft-ietf-radext-radius-fragmentation-08
============================================================
(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header?

This document is aiming for Experimental status. This is the correct choice because it proposes complex changes to the RADIUS operational model to achieve transmission of payload sizes beyond the current maximum (4096 bytes). It aims for backward compatibility when being transmitted over legacy intermediate proxy systems which are not yet upgraded to support the requirements of this document. The real-life suitability of these changes needs further study; hence Experimental. There are other approaches to the same problem discussed in the working group, but they are not backwards compatible to non-upgraded proxies.

(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:

Technical Summary:

  The Remote Authentication Dial-In User Service (RADIUS) protocol is
  limited to a total packet size of 4096 octets.  Provisions exist for
  fragmenting large amounts of authentication data across multiple
  packets, via Access-Challenge.  No similar provisions exist for
  fragmenting large amounts of authorization data.  This document
  specifies how existing RADIUS mechanisms can be leveraged to provide
  that functionality.  These mechanisms are largely compatible with
  existing implementations, and are designed to be invisible to
  proxies, and "fail-safe" to legacy clients and servers.

Working Group Summary:

  The content of this document was discussed at length in the working
  group, and there are multiple other approaches to the same problem.
  The document thus got significant exposure at the experts of the
  working group. The document has a few rough edges which were the cause
  of discussions. Considering the target status of Experimental, they
  appear minor enough to carry on with the experiment. The authors have
  documented the friction points in their section 11 "Operational
  Considerations". 11.1 in particular shows a process question: is it
  appropriate for an Experimental RFC to update a Standards-track RFC?
  The document attempts to follow that course; if this is ultimately
  agreed after IESG review, the text in that section will be changed
  accordingly.

Document Quality:

  At least one implementation is known which implements this
  specification: FreeRADIUS. The sheperd has no information about plans of
  other vendors. There were no particular expert reviews outside the
  working group process; i.e. no MIB doctor review nor Media Type review
  (and no need for those two as the document contains neither MIBs nor
  requests a Media Type). Since the document adds new transport
  capabilities, a thorough review by transport experts (e.g. TSVDIR) during
  IETF Last Call would be appreciated.

Personnel:

  The Document Shepherd is Stefan Winter . The
  responsible Area Directors are Benoit Claise <​bclaise@cisco.com> and Joel
  Jaeggli <​joelja@bogus.com>.

(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.

The sheperd was actively reviewing the document during its entire lifecycle, back then as individual participant in the WG (now chair). For the PROTO write-up, he gave the then-latest version -06 a fresh read; which resulted in a number of minor changes which are now the -08 version which is ready for advancement in the publication process.

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?

No cencerns; the document was read by and commented on by a comparatively high number of participants.

(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.

The document addresses a very specific RADIUS shortcoming and this document's impact does not appear to matter from a broader perspective at first glance. However, the document introduces a new transport property for RADIUS (fragmentation support) which deserves a close look by transport area experts. There may be issues with traversing AAA proxies which are unaware of this document, but those issues have been uncovered during the WG review process and are enumerated in section 11.

(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.

The issue described in 11.1 had no final conclusive answer; i.e. is it better to a) have this document update a standards-track document, or b) have an IANA registry for the flag field assignments, or c) just do nothing. The working group consensus went for a), which is fine IMO, but the text in 11.1 will need to be updated with more confident language once it is determined if that course of action is acceptable process-wise.

From a more general point of view, the entire solution is rather bulky and not very elegant; but it solves an actual problem and operates despite possible presence of unaware proxies on the path, which is a significant plus.

(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?

During the PROTO Write-Up, the sheperd asked each author and they all confirmed that they have no outstanding IPR disclosures.

(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.

There was no IPR disclosure.

(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?

There is one group of individuals which was pushing for this document: the ABFAB WG and implementers of the corresponding specs needed this solution and so far, use cases beyond ABFAB have yet to surface. Naturally, these participants were most active and drove most of the discussions. However, more participants than just those were reviewing and commenting on the document, so there is solid consensus behind the document.

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)

There was one individual who expressed major disconsent during the call for adoption, and also on various design choices before and after adoption. There was no threat of appeal though.

(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.

"The 'Updates: ' line in the draft header should list only the _numbers_
    of the RFCs which will be updated by this document (if approved); it
    should not include the word 'RFC' in the list."

There is a dangling reference [IANA-CONSIDERATIONS] (section pointer) which
can be fixed later in the publication process.

(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews.

There are no MIBs, media types, or URI requests in this document.

(13) Have all references within this document been identified as either normative or informative?

Yes.

(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?

All normative references are issued RFCs.

(15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.

There are no downward normative references (1 x Informational, 2 x BCP, 3 x standards-track).

(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary.

This document updates RFC6929. That document is mentioned in the introduction, but not the abstract. The reason why it is omitted in the abstract is because the relationship is relatively minor (a previously reserved flag is defined for use in this document) and because there are two dedicated sections (8 + 11.1) which explain the update relationship in considerable detail.

(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 5226).

The document introduces two new attributes, one new value for an existing attribute, and a registry for an enumeration of values for one of those new attributes. The IANA consideration section contains all the info required by IANA to perform the reservations in question. Future allocations of the new registry are defined (RFC required). The name for the registry ('RADIUS Frag-Status "Code" registry') is reasonable.

(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.

The new registry is 'RFC required'; no experts needed.

(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, etc.

There are no formal language constructs in the document.