|
PROTO Writeup for draft-ietf-radext-tcp-transport ================================================= http://tools.ietf.org/html/draft-ietf-radext-tcp-transport (1.a) Who is the Document Shepherd for this document?
Has the Document Shepherd personally reviewed this version of
the document and, in particular, does he or she believe this
version is ready for forwarding to the IESG for publication? Bernard Aboba is the document shepherd. I have personally
reviewed the document, and believe it is ready for publication as an
Experimental RFC. (1.b) Has the document had adequate review both from key
members of the interested community and others? Does the
Document Shepherd have any concerns about the depth or breadth of the
reviews that have been performed? The document has undergone review within the community of
RTLS implementers, as well as within the RADEXT WG. It could
benefit from additional review by the transport community. (1.c) Does the Document Shepherd have concerns that the
document needs more review from a particular or broader
perspective, e.g., security, operational complexity, someone familiar
with AAA, internationalization or XML? This document should be reviewed by the Transport
Directorate prior to publication. (1.d) Does the Document Shepherd have any specific
concerns or issues 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 interested community has discussed those issues
and has indicated that it still wishes to advance the
document, detail those concerns here. As noted in Section 2.5, there are situations (such as NAS
avalanche restart) where a proxy implementing RADIUS over TCP/TLS would be
unable to keep up with the UDP packets generated by NAS devices not
implementing the congestion control algorithm described in RFC 5080 Section
2.2.1. (1.e) How solid is the consensus of the interested
community behind this document? Does it represent the strong
concurrence of a few individuals, with others being silent, or does the
interested community as a whole understand and agree with it? There is consensus within the RADEXT WG to publish the
document as an Experimental RFC. (1.f) 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 entered into the ID Tracker.) No. (1.g) Has the Document Shepherd personally verified that
the document satisfies all ID nits? (See http://www.ietf.org/ID-Checklist.html and http://tools.ietf.org/tools/idnits/). Boilerplate
checks are not enough; this check needs to be thorough. Has the
document met all formal review criteria it needs to, such as the MIB
Doctor, media type and URI type reviews? idnits is clean: idnits 2.12.00 tmp/draft-ietf-radext-tcp-transport-05.txt: Checking boilerplate required by RFC 5378 and the IETF
Trust (see http://trustee.ietf.org/license-info):
---------------------------------------------------------------------------- No issues found here. Checking nits according to
http://www.ietf.org/ietf/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to
http://www.ietf.org/ID-Checklist.html:
---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings:
---------------------------------------------------------------------------- No issues found here. Checking references for intended status: Experimental
---------------------------------------------------------------------------- -- Unexpected draft version: The latest known version of draft-ietf-radext-status-server is -03, but you're
referring to -06. (However, the state information for draft-ietf-radext-status-server
is not up-to-date. The last update was 2009-02-13) Summary: 0 errors (**), 0 warnings (==), 1 comment
(--). (1.h) Has the document split its references into
normative and informative? 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
strategy for their completion? Are there normative references that are
downward references, as described in [RFC3967]? If so, list
these downward references to support the Area Director in the Last
Call procedure for them [RFC3967]. The references in the document have been split into
normative and informative. Normative references are all stable documents published as
RFCs. (1.i) Has the Document Shepherd verified that the
document IANA consideration section exists and is consistent with
the body of the document? If the document specifies protocol extensions,
are reservations requested in appropriate IANA
registries? Are the IANA registries clearly identified? If the document
creates a new registry, does it define the proposed initial contents
of the registry and an allocation procedure for future
registrations? Does it suggested a reasonable name for the new
registry? See [I-D.narten-iana-considerations-rfc2434bis]. If the
document describes an Expert Review process has Shepherd
conferred with the Responsible Area Director so that the IESG can appoint
the needed Expert during the IESG Evaluation? The IANA Considerations section exists (section 4). It
requires no action by IANA. (1.j) Has the Document Shepherd verified that sections
of the document that are written in a formal language, such
as XML code, BNF rules, MIB definitions, etc., validate correctly
in an automated checker? Not applicable. (1.k) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Writeup? Recent examples can be found in
the "Action" announcements for approved
documents. The approval announcement contains the following sections: Technical Summary RADIUS has traditionally used UDP as its underlying
transport layer, for reasons described in RFC 2865 Section 2.4. This document
defines RADIUS over TCP, in order to address handling issues related to
RADIUS over TLS (RTLS). It is not intended to define TCP as a transport
protocol for RADIUS in the absence of TLS. Working Group Summary This document is part of a set (including the Status-Server
and RTLS specifications) which together define RADIUS over TLS
(RTLS). This document has completed RADEXT WG last call, with the
primary areas of discussion relating to liveness detection and
congestion control. Document Quality The document has been reviewed by IETF RADEXT WG members. RADIUS over TLS/TCP has been implemented by multiple
vendors, including RADIATOR and FreeRADIUS. The protocol is
currently the subject of a large scale experiment involving deployment
by EDUROAM, an educational roaming consortium supporting
more than one million users worldwide. Personnel Bernard Aboba is the document shepherd for this document. Dan Romascanu is the responsible AD. |