FW: review of draft-ietf-radext-status-server-06.txt

["Bernard Aboba" <bernard_aboba@hotmail.com>]

-----Original Message-----
From: Francis.Dupont@fdupont.fr [mailto:Francis.Dupont@fdupont.fr] 
Sent: Thursday, April 01, 2010 7:48 AM
To: gen-art@ietf.org
Cc: draft-ietf-radext-status-server.all@tools.ietf.org
Subject: review of draft-ietf-radext-status-server-06.txt

I have been selected as the General Area Review Team (Gen-ART)
reviewer for this draft (for background on Gen-ART, please see
http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).

Please resolve these comments along with any other Last Call comments
you may receive.

Document: draft-ietf-radext-status-server-06.txt
Reviewer: Francis Dupont
Review Date: 2010-03-28
IETF LC End Date: 2010-03-29
IESG Telechat date: unknown

Summary: Ready with nits

Major issues: none

Minor issues: none

Nits/editorial comments:
 - Abstract page 2: there is an explicit reference to a RFC, this is in
  general forbidden but IMHO we are here in the allowed exception case.

 - 2.1.1 page 8: a servers policy -> a server policy

 - 3 page 10 (twice): etc. -> etc., ???

 - 4.2 page 13: adminstrators -> administrators

 - 4.2 page 15 (twice): e.g. -> e.g.,

 - 4.3 page 16: modelled -> modeled

 - 4.3 page 16: usually the hysteresis against flapping tries to keep
  the connection (i.e., failover after 3 missed responses), here it is
  the opposite. IMHO it is very aggressive but it is how RFC 3539 works
  so I have no concern about it.

 - 4.5 page 16: Proxyhas -> Proxy has

 - 4.5 page 17: cannot, -> cannot

 - 4.5 page 18: i.e. -> i.e.,

 - 5 page 19: EAP-MEssage -> EAP-Message

 - 8 page 23: synthesise -> synthesize

 - 8 page 23: in "the suggestion of [RFC5080] Section 2.2.2, which suggests"
  suggests -> proposes

 - 8 page 23: configurably is not in my dict?

 - 9.2 page 23: IMHO the RFC2119 reference should be moved to normative
  references section (perhaps others too?)

 - Authors' Addresses -> Author's Address

Regards

Francis.Dupont@fdupont.fr

PS: I apologize for the delay. BTW I've seen a wording comment and proposal
from Bernard Aboba, I support it.


--
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/>