Re: [HOKEY] draft-ietf-hokey-preauth-ps-08.txt

["Glen Zorn" <gwz at net-zen.net>]

Hoeper Katrin-QWKN37 [mailto:khoeper at motorola.com] writes:


...

> > > For future revisions, I would like to ask the editors to describe
> how
> > > they addressed previously raised issues or why they didn't address
> > > some.
> > > Otherwise it's very difficult to keep track of the discussion and
> new
> > > draft releases.
> >
> > http://tools.ietf.org/rfcdiff seems to work pretty well; certainly,
> you
> > know
> > what your own comments were & can see if they have been addressed,
> no?
> 
> [KH] Yes, I can do that, but I was wondering if some of my previous
> comments have not been addressed for a reason (and not just
> accidently).

If your comments were not the focus of some controversy, you can assume that
they were accepted; in that case, if they were not addressed it was an
error.

> So instead of bringing up the same issues over and over again, I'd
> prefer discussing the remaining issues on the list. Like we are doing
> right now in this email :)

What a good idea!

...

> > > *) The direct pre-authentication model is the only one for which no
> > > assumptions or conditions are listed. I suggest rewording the
> > > description from Section 6.1.2 <quote> This pre-authentication
> model
> is
> > > needed if the peer cannot discover the candidate authenticator's
> > > identity or if direct IP communication between the MD and CAP is
> not
> > > possible due to security or network topology issues. </quote> as
> > > conditions for the direct pre-authentication model.
> >
> > I don't see the need for total consistency, but if you have some
> text...
> >
> [KH] I didn't suggest it for consistency sake but rather to help to
> distinguish the three use cases. For instance, if I want to implement
> an
> early authentication solution, conditions&requirements for each model
> would help me to identify the right approach for my system. Text could
> be like "The direct pre-authentication model is based on the assumption
> that the MD can discover candidate authenticators and establish a
> direct
> IP communication link with them."

OK.

...

> > > *) Section 6.1.1: Figure 2 is not referenced
> >
> > So what?
> >
> [KH] IMO if a figure or table is not referenced at all it should be
> removed.  So just reference it!

But the figure directly follows the text!

...

> > > *) Section 8: "Early authentication entries", you say the procedure
> for
> > > changing a peer's state from early to full authentication is not
> topic
> > > of <quote> this particular subsection </quote>. Where in this
> document
> > > is this procedure explained?
> >
> > I don't think that it is; is it even in the scope of this document?
> 
> [KH] That's exactly what I was wondering too! I don't think it is
> discussed at all. So just mention that it is out of scope of the
> document.

I just took it out altogether...

...