[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
FW: draft-ietf-radext-fixes-03 LC comments
> > -----Original Message-----
> > From: Alfred HÎnes [mailto:ah@tr-sys.de]
> > Sent: Sunday, May 20, 2007 2:54 PM
> > To: d.b.nelson@comcast.net; aland@freeradius.org
> > Subject: draft-ietf-radext-fixes-03 LC comments
> >
> > Hello,
> > after studying the Internet-Draft in IETF LC authored by you,
> > draft-ietf-radext-fixes-03 ,
> > I'd like to submit a few comment pointing out a few out textual
> > issues, and a procedural issue I found with that document.
> >
> >
> > (1) meta-data / procedural issue
> >
> > The heading of the draft says:
> > Updates: 2865, 2866, 2869, 3579
> > and the draft is intended for the IETF Standards Track.
> >
> > Now although RFC 2865 currently is a Draft Standard,
> > unfortunately the other three memos, RFC 2866, RFC 2869,
> > and RFC 3579 have benn published as Informational RFCs
> > and never been advanced onto the Standards Track.
> >
> > I am in serious doubt whether is conforms with the
> > established IETF Standards Track procedures to have a
> > document on the Standards Track update documents not on
> > the Standards Track.
> > Perhaps, the problem is not with the draft, but with the
> > three Informational RFCs which usually are seen as a part
> > of "the" RADIUS specification; it might be advantageous,
> > after all the implementation experience at large, to bring
> > these documents to Proposed Standard level - before or
> > together with the publication of this draft as an RFC.
> >
> >
> > (2) Section 2.2.2 -- typo
> >
> > At the end of the first paragraph of Section 2.2.2, please
> > change:
> > "suys" --> "says" .
> >
> >
> > (3) Section 2.2.2 -- grammar
> >
> > The 2nd sentence in the third-to-last paragraph of Section 2.2.2
> > says:
> >
> > Implementations MUST also cache the Responses (Access-Accept, Access-
> > Challenge, or Access-Reject) that is sends for those Access-Request
> > packets.
> >
> > To correct the grammar, it should better say either:
> >
> > vvvv
> > | An implementation MUST also cache the Responses (Access-Accept,
> > | Access-Challenge, or Access-Reject) that it sends for those Access-
> > Request packets.
> > ^^^^
> > or:
> >
> > Implementations MUST also cache the Responses (Access-Accept, Access-
> > | Challenge, or Access-Reject) they send for those Access-Request
> > packets.
> > ^^^^^^^^^^^
> > or:
> >
> > Implementations MUST also cache the Responses (Access-Accept, Access-
> > | Challenge, or Access-Reject) sent for those Access-Request packets.
> > ^^^^^^
> >
> > (4) Section 2.9 -- textual improvement
> >
> > In the last paragraph of Section 2.9, please change:
> >
> > v vvv
> > "... either omit a User-Name attribute ... or include the Calling-
> > Station-Id ..."
> >
> > I suggest to improve the language to say:
> >
> > vvv vvv
> > | "... either omit the User-Name attribute ... or include the Calling-
> > Station-Id ..."
> >
> >
> > (5) outdated Reference, and Section 6
> >
> > Hint: [PREFIX] has been published as RFC 4818, in the meantime.
> >
> > Hence, the replacements mentioned in Section 6 can be performed
> > immediately, and Section 6 be dropped from the draft.
> >
> >
> > Kind regards,
> > Alfred HÎnes.
> >
> > --
> >
> > +------------------------+--------------------------------------------+
> > | TR-Sys Alfred Hoenes | Alfred Hoenes Dipl.-Math., Dipl.-Phys. |
> > | Gerlinger Strasse 12 | Phone: (+49)7156/9635-0, Fax: -18 |
> > | D-71254 Ditzingen | E-Mail: ah@TR-Sys.de |
> > +------------------------+--------------------------------------------+
>
>
>
--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>