1) I was hoping this document might help me understand ways in which
candidate access points might be identified. It didn't though. Was it
supposed to tell me that?  If not, then what would tell me that?
(Maybe there is, or is not, a change needed for this, I don't yet.)

2) Section 9 doesn't do it for me, sorry;-) Two possibilities -
either you argue convincingly that its ok as-is (in mail and then the
PROTO write up please) or else you try to address/reference generic
hokey security considerations.  I'd prefer the latter, as I'd
otherwise expect the current empty section 9 to generate DISCUSSes if
nothing's done. The ones that occur to me that might not be elsewhere
would include: a) hokey implies moving more keys about in various new
ways, summarise the argument that none of these are leaking key bits,
b) AAK seems to have a potential DoS if e.g.  someone causes AAK to
be done with loads of CAPs, or loads of AAK with one CAP, and maybe
c) if someone chooses the wrong CAP then they might have been fooled
into sending all the user's traffic via a bad actor. There could also
be more of course, but that's what occurs to me. Note that I think a
sentence or two on each with a pointer to the RFC where its further
discussed would be fine if there's such an RFC.  (I think tihs does
need a change, and I'm reluctant to be convinced otherwise, but its
possible if you wanna try.)

not quite nits:

- I realise that this document references lots of others that define
things, but a bit of ascii art at the start would have been helpful.
Its not obvious where e.g. the "ER server" might live from the
current text.

- p16, I don't get 6.4 really - why is inter-technology the same as
intra-domain?

nits:

- p5, "For the purpose of this draft" is wrong. s/draft/memo/?

- p5, "All three mechanisms..." This description is a bit confusing,
since there are many RFCs referenced.  I think it'd be improved if
you listed the three mechanisms as bullets.

- p5, ER is used as an acronym - expand on 1st use as well as in
section 2 would be better

- p6, s/can be integrated/whether or not it can be integrated/?

- p7 - cute that you reference 2119 anyway:-) I wonder if this is its
first informative reference?

- p7, What is a re-authenticaiton root key? (3.2) I see its defined
in 5296 but wouldn't it be ok to just say "required keys" here - do
you *need* to be so precise? If so, then maybe add a ref to 5296 to
help point the reader to the right place?

- p8 - what is a "HOKEY server"? should that be in the terminology
section?

- p8, 1st para of 4.1 just confuses me - is it needed really?  Maybe
you could lose that and just s/subsystem/subsystem provided by HOKEY/
in the next para and that'd be good enough? (If you do keep the
current text, I also wonder if the "This section" at the start refers
to setction 4 generally or 4.1 only? As-is its a little ambiguous
looking.)

- p9, end of page - Got any references to that work in progress?

- p10, end of 4.5 - Ok to a "specification exists" but don't you need
to say more? Maybe that it does this job? Could as simple as
s/exists/for this exists/

- p10, 4.6 - putting the references in the bullet points might be
clearer rather than (almost) repeating?

- 5 (intro) says "the authenticator" but 5.2 talks about the "serving
authenticator"  and 5.3 talks about the "candidate authenticator" -
be better to be consistent and use the latter terms in the intro
maybe.

- p16, 6.3 s/as the peer/as is the peer/?

- p16, 7.1 s/influence in the authorization/influence the
authorization/

- I-D nits says:

  == Outdated reference: A later version (-06) exists of
     draft-ietf-hokey-erp-aak-05