[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [HOKEY] WGLC: draft-ietf-hokey-preauth-ps-02



Hi Shubhranshu,

Thank you very much for your review.  I agree with most of your comments.
Please see my comments below.

On Mon, Apr 07, 2008 at 06:28:51PM +0530, Shubhranshu wrote:
> I went through draft-ietf-hokey-preauth-ps-02 and found it well
> written and easy to understand.
> 
> A few comments are provided below. Currently I am not subscribed to
> the mailing list. It is possible that some of my comments have already
> been discussed, if so please ignore them. Also, feel free to forward
> the comments to the list.
> 
> 2. Introduction
> 
> Throughout this document, "mobile", "mobile device" and "peer"  has
> been interchangeable used. Suggest to pick-up one, preferably between
> the later two, and use it consistently.

We will be adding a new terminology section to address your
comment and Charles' comment.

> 
> 3. Problem Statement
> 
> Suggested modification of first sentence: " From pre-authentication
> perspective, Basic mechanism of handover is a three-step procedure
> involving...."

I think that the three-step precedure is common to all handover
scenarios not necessarily from pre-authentication perspective.

> 
> "HOKEY server" has been used but not defined anywhere in the document.

A new terminology section will address this.

> 
> Suggest replacing "full authentication" with "normal authentication"
> else include some text to clarify the previous terminology (also
> applicable to other places in the document).

OK.

> 
> In the paragraph starting with "EAP pre-authentication discussed in
> this document",
> /s "...or of the same link-layer technology / or support same
> link-layer technology.

OK.

> 
> Not clear what is meant by "such use" ? Deleting the last sentence or
> starting the sentence with "Use of pre-authentication" might help.

We can remove the last sentence.

> 
> "This framework has general applicability to various deployment
> scenarios in which proactive signaling can take effect." Which
> framework ? Till this paragraph no framework has been defined.

We can revise it to: "EAP pre-authentication has general applicability
to ..."

> 
> "applicability of EAP pre-authentication is limited to the scenarios
> where candidate authenticators can be easily discovered, an accurate
> prediction of movement can be easily made". I'd think that candidate
> authenticator discovery is the issue here not the _easiness_ with
> which it can be discovered.  Remove "easily"

OK.

> 
> 5.2. Context Binding
> 
> s /a mechanisms is needed / a mechanism is needed

OK.

> 
> "There are two possible approaches to address the context binding
> issue." In order not to restrict any future solution space, consider
> replacing it with "There are at least two possible approaches to
> address the context binding issue."

OK.

> 
> 6. AAA Issues
> 
> s / has yet not moved to the new location / has not yet moved to the
> new location

OK.

> 
> Completion of network attachment: " ....There may need to be a
> mechanism within the AAA protocol to provide this indication to the
> AAA server." This is needed only when the AAA server differentiates
> between pre-authentication and normal  authentication states. Perhaps
> some text indicating this assumption would help.

OK, we will add some text indicating the assumption.

> 
> 
> 7. Security Considerations
> 
> " the candidate network or authenticator should apply non-
> cryptographic packet filtering " Suggest to keep the flexibility by
> using "may" instead of "should"

OK.

> 
> s / non-cryptograhpic packet filtering / non-cryptographic packet filtering

OK.

Regards,
Yoshihiro Ohba

> 
> - Shubhranshu
> 
> 
> 
> >
> > ----- Forwarded message from Charles Clancy <clancy at cs.umd.edu> -----
> >
> > X-VirusChecked: Checked
> > X-Env-Sender: hokey-bounces at ietf.org
> > X-Msg-Ref: server-5.tower-129.messagelabs.com!1206232734!8402261!1
> > X-StarScan-Version: 5.5.12.14.2; banners=-,-,-
> > X-Originating-IP: [64.170.98.32]
> > X-SpamWhitelisted: domain whitelist
> > X-Virus-Scanned: amavisd-new at amsl.com
> > X-Virus-Scanned: amavisd-new at amsl.com
> > From: Charles Clancy <clancy at cs.umd.edu>
> > User-Agent: Thunderbird 2.0.0.12 (Windows/20080213)
> > To: hokey at ietf.org
> > X-CSD-MailScanner-Information: Please email staff at cs.umd.edu for more
> > information
> > X-CSD-MailScanner: Found to be clean
> > X-CSD-MailScanner-SpamCheck: not spam, SpamAssassin (not cached,
> > score=-4.399, required 5, autolearn=not spam, ALL_TRUSTED -1.80,
> > BAYES_00 -2.60)
> > X-CSD-MailScanner-From: clancy at cs.umd.edu
> > Subject: [HOKEY] WGLC: draft-ietf-hokey-preauth-ps-02
> > X-BeenThere: hokey at ietf.org
> > X-Mailman-Version: 2.1.9
> > List-Id: HOKEY WG Mailing List <hokey.ietf.org>
> > List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/hokey>,
> > <mailto:hokey-request at ietf.org?subject=unsubscribe>
> > List-Archive: <http://www.ietf.org/pipermail/hokey>
> > List-Post: <mailto:hokey at ietf.org>
> > List-Help: <mailto:hokey-request at ietf.org?subject=help>
> > List-Subscribe: <https://www.ietf.org/mailman/listinfo/hokey>,
> > <mailto:hokey-request at ietf.org?subject=subscribe>
> > X-UIDL: ]Y-"!e'/"!ko1!!\&,!!
> >
> > This serves as the Working Group Last Call (WGLC) for the EAP
> > Pre-authentication Problem Statement:
> >
> > http://tools.ietf.org/html/draft-ietf-hokey-preauth-ps
> >
> > Please send any comments on the document to the list by April 7, 2008.
> >
> > --
> > t. charles clancy, ph.d.                 eng.umd.edu/~tcc
> > electrical & computer engineering, university of maryland
> > _______________________________________________
> > HOKEY mailing list
> > HOKEY at ietf.org
> > https://www.ietf.org/mailman/listinfo/hokey
> >
> >
> 
_______________________________________________
HOKEY mailing list
HOKEY at ietf.org
https://www.ietf.org/mailman/listinfo/hokey