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

From: Qin Wu <[email-masked]>
Date: Wed, 25 Nov 2009 15:47:10 +0800

Hi,Tina:
Sorry for my late reply. Thank for your shepherding this document. Please see my answer below.
If your comments are addressed, please let us know.

Regards!
-Qin
  ----- Original Message ----- 
  From: Tina TSOU 
  To: [email-masked] 
  Sent: Tuesday, July 21, 2009 3:14 PM
  Subject: [HOKEY] Comments on draft-ietf-hokey-preauth-ps-09 as the documentshepherd

  Hi all,
  Here are my comments as the document shepherd:
  =====================

  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.

  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.

  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.

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

  [Qin]: Accepted, Thank for your correction.

  Definition "peer": the RFC 3748 definition talks about "the end of the link" 
  that responds to the authenticator. Taking out the link part has made the 
  definition ambiguous -- the peer could be the EAP Server. Suggest that the 
  definition read instead: "The entity requiring authentication" and add that this 
  is the same as the peer as defined by RFC 3748.

  [Qin]: Okay. Maybe the proper way to say would be
   "
  The entity that reponds to the authenticator and requires authentication [RFC3748].
  "

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

  [Qin]: Accepted.

  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).

  [Qin]: Okay, thanks.

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

  [Qin]: Thank for your correction.

  Provide a reference for ERP (end of 7th line of paragraph after bullets).
  [Qin]: Clarification, the refence for ERP has been provided in the previous section 3.3.

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

  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.

  [Qin]: Okay.

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

  [Qin]: Okay.

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

  [Qin]: Okay.

  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.

  [Qin]: Sorry for this typo. The cases 2(b) and 3 should be 1(b) and 2.

  Aside from that, when the sentence says "the most likely cases", is that 
  overall, or when the transfer is inter-technology? Please specify.

  [Qin]: Clarification. what we are really saying in this sentence is:
  In the case 1(a), the peer moves from Serving Attachment point to the Candidate Attachment point, 
  the attachment point is changed, but authenticator may keep unchanged or may be changed.
  Different from case 1(a), in the case 1(b) or case 2, when the peer moves from the serving attachment point to the candidate
  attachment point, the authenticator,in most cases,may be changed, . The reason is 
  In the case 1(b),network is changed from the serving access network to the candidate access network, normally one authenticator will not be shared by both networks.
  or in the case 2, access technology is changed, normally one authenticator does not support two access technology at the same time.
  That is why we say the most like cases are 1(b) and 2.

  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.

  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.

  Same sentence, "a candidate attachment point" -> "the candidate attachment 
  point" to be consistent with the rest of the paragraph.
  [Qin]: Okay.

  Section 6.1  EAP Pre-authentication Models
  -------------------------------------------
  First sentence: "In the EAP Pre-authentication model," -> "In the EAP 
  pre-authentication model,".
  ^
  [Qin]: Okay

  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".
  [Qin]: Okay.

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

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

------------------------------------------------------------------------------

  _______________________________________________
  HOKEY mailing list
  [email-masked]
  https://www.ietf.org/mailman/listinfo/hokey

---

From: "Glen Zorn" <[email-masked]>
Date: Sun, 29 Nov 2009 13:33:20 -0800

Tina TSOU  <mailto:[mailto://[email-masked]%5d> [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",

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

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?

.