Subject: Re: [HOKEY] Comments on draft-ietf-hokey-preauth-ps-09 as the documentshepherd

From: Tina TSOU <[email-masked]>
Date: Mon, 07 Dec 2009 20:50:50 +0800

Hi authors,
It cleared my comments.
You may create a new version of draft-ietf-hokey-preauth-ps to address  
all the comments including mine.

B. R.
Tina
http://tinatsou.weebly.com/contact.html

> ----- Original Message -----
> From: Glen Zorn
> To: 'Qin Wu' ; 'Tina TSOU'
> Cc: [email-masked]
> Sent: Monday, November 30, 2009 5:33 AM
> Subject: RE: [HOKEY] Comments on draft-ietf-hokey-preauth-ps-09 as  
> the documentshepherd
>
> Tina TSOU [mailto://[email-masked]] writes:
> …
> Speaking as Co-Chair, it should be noted that it's way too late to  
> address the issues raised here unless they really are showstoppers.   
> That said, however (and speaking as a document editor), please see  
> below.
> Section 1 Introduction
> ----------------------
> The second paragraph should be deleted. The contents are a  
> combination of the
> irrelevant and the redundant. The deletion makes the reference [WCM]
> unnecessary, so that should be dropped too.
> [Qin]: In my understanding, this paragraph is more relevant to the  
> section 7.2 "Context binding",
> Therefore I would like to suggest to keep it as it does.
> I agree w/Qin.
>
> Section 2 Terminology
> ---------------------
> The appropriate reference for the definition "Authenticator" is RFC  
> 3748, not
> RFC 3588.
>
> [Qin]: The reason to change RFC3748 into RFC 3588 in this version is  
> according to the discussion in the IETF 74,
> the definition of "Authenticatior" is not necessary to be limited to  
> IEEE link layer technology, 3GPP and 3GPP2 scenarios
> should be considered as well. Thefore it is better to refrence to  
> RFC3588 than  RFC3748.
> Actually, I tend to agree w/Tina in this case: RFC 3588 only uses  
> the term "Authenticator once AFAICT & it is in reference to a  
> completely different thing (the RADIUS Request Authenticator).
>
> Definition "EAP Server": Suggest deleting ", using a AAA protocol to  
> communicate
> with remote pass-through authenticators". It is not essential to the  
> definition
> and is already well explained in section 4.
>
> [Qin]: It helps us to understand what's the role of AAA server when  
> EAP server is collocated with AAA server.
> I would like to suggest to keep it.
> I agree.
> …
> Section 6.  Models of Early Authentication
> ------------------------------------------
> The part beginning: "Different usage models..." and carrying on  
> through the
> three bullets is redundant. The earlier part of the first paragraph  
> is enough of
> an intro. The equal status of all three models in the bullets is not  
> consistent
> with the hierarchy introduced in Section 6.1 (model and sub-models),  
> and
> discarding the bullets solves that problem at the same time that it  
> gets rid of
> unnecessary text.
>
> [Qin]: No, it is not redundant at all. On the contrary, The three  
> bullets are well matched
> with the model and sub-models defined in the section 6.1 and 6.2,  
> they are quite useful
> to highlight the difference between the sub-modes described in the  
> section 6.1 and model
> described in the section 6.2.
> I'm in favor of redundancy in standards, anyway ;-).
> Last sentence before the Section 6.1 header: is the intention to say  
> no direct
> L2 connectivity before handover, or no direct L2 connectivity ever?
>
> [Qin]: The first one.
> Yes, that seems to be implied by the term: once L2 connectivity is  
> established with a CAP, it's no longer a "candidate", right?
> …

---

From: "Glen Zorn" <[email-masked]>
Date: Mon, 7 Dec 2009 10:58:05 -0800

Tina TSOU [mailto:[email-masked]] writes:

Hi authors,

It cleared my comments.

You may create a new version of draft-ietf-hokey-preauth-ps to address all
the comments including mine.

Thanks!  Do you have a list of the unresolved issues and/or suggested
changes?

.

---

From: Tina TSOU <[email-masked]>
Date: Tue, 08 Dec 2009 17:25:51 +0800

Hi authors,
Here is the list.

(1) Section 2 Terminology
---------------------
The appropriate reference for the definition "Authenticator" is RFC 3748, not 
RFC 3588.

Definition "Intra-AAA-realm Handover": typo in second line: include -> includes

Definition "peer": Change the definition read instead "The entity that responds to the authenticator and requires authentication [RFC3748]"

Definition "Serving Attachment Point": "The attachment point" -> "An attachment 
point" for consistency with other definitions.

(2) Section 3.2  Handover Execution
-------------------------------
Spell out the first occurrences of abbreviations, so the first sentence reads: 
"Handover execution consists of setting up layer 2 (L2) and layer 3 (L3) 
connectivity with the Target Access Point (TAP).

(3) Section 3.3.1  Context Transfer
-------------------------------
Typo: period after colon at the end of the first para.

In the 12th line of that para, delete "then", so text reads: "...key is derived 

(4) Section 3.3.2  Early Authentication
-----------------------------------
Spell out MD as "mobile device" on the fourth line. The abbreviation is 
(already) introduced more naturally in the next section, just before the figure 
in which it appears.

Break the final sentence of the first para into two at the semicolon (top of p. 8).

(5) Section 4.  System Overview
---------------------------
3rd line: "and an one" -> "and one"

(6) Section 5.  Topological Classification of Handover Scenarios
------------------------------------------------------------
Last sentence refers to cases 2(b) and 3. There is no explicit number 2(b) or 3 
in the preceding text. ("A third case" should be bullet 3?) Fix the references.

Same sentence, "a candidate attachment point" -> "the candidate attachment 
point" to be consistent with the rest of the paragraph.

(7) Section 6.1  EAP Pre-authentication Models
-------------------------------------------
First sentence: "In the EAP Pre-authentication model," -> "In the EAP 
pre-authentication model,".

(8) Section 6.1.1  The Direct Pre-authentication Model
--------------------------------------------------
Fifth line:  "establish a direct IP communication link with them" -> " establish 
direct IP communication with them".

Same line: break the sentence at the semicolon. Begin the new sentence: "This 
model is applicable...".

B. R.
Tina

  ----- Original Message ----- 
  From: Glen Zorn 
  To: 'Tina TSOU' 
  Cc: [email-masked] ; [email-masked] 
  Sent: Tuesday, December 08, 2009 2:58 AM
  Subject: RE: [HOKEY] Comments on draft-ietf-hokey-preauth-ps-09 as the documentshepherd

  Hi authors,

  It cleared my comments.

  You may create a new version of draft-ietf-hokey-preauth-ps to address all the comments including mine.

  Thanks!  Do you have a list of the unresolved issues and/or suggested changes?

  .