Subject: [eap] review of draft-ietf-eap-netsel-problem-04.txt

From: Jari Arkko <[email-masked]>
Date: Wed, 06 Sep 2006 17:40:55 +0300

I have reviewed the latest version of this
draft.

Overall, I liked this version much more
than the previous ones. The new terminology
and problem definitions are great.

There are a few relatively small issues
left, however. Please see below:

ISSUE: RFC 2606 compliance.

>          Figure 1: Two credentials, three possible access networks

The examples in this figure (and elsewhere) need to
conform to RFC 2606, e.g., example.com instead of
example1.com.

ISSUE: NAI hint recommendation strength

>    As a result, network-based AAA routing mechanisms are preferred over
>    user-based selection where sufficient routes have been configured and
>    there is no need for user control.  Where these conditions are not
>    met -- particularly when an attempt to use the network-based routing
>    mechanism has failed -- routing hints can be placed in an NAI as
>    defined in [12]. 

I would like to make the above a bit stronger. How about

   As a result, network-based AAA routing mechanisms should be used
   instead of user-based selection where sufficient routes exist.  In
   an error situation, such as when an attempt to use the network-based
routing
   mechanism has failed, routing hints can be advertised and used as
   defined in [13] and [12]. Even so, such approaches have severe
   scalability limitations. See Section 3.1 for further discussion.

>    Since RFC 1035 [1] enables FQDNs to be
>    up to 255 octets in length, this may not enable the announcement of
>    many realms, although if SSIDs are used, the maximum length of 32
>    octets per SSID may provide somewhat better scaling.  The use of
>    other network identifiers than domain names is also possible, for
>    instance the PANA protocol uses an a free form string and an SMI
>    Network Management Private Enterprise Code [17], or Mobile Network
>    Codes embedded in NAIs as specified in 3GPP.

I don't think we should talk about SSIDs here because
[13] explicitly uses realms, not SSIDs (and the proliferation
of new Id Request parameters would be harmful). If
MNCs are embedded in NAIs, this does not really reduce
the length all that much. I think this leaves only the PANA
example, even if the general point is valid.

ISSUE: Extensibility in 3GPP section

>    o  Extensibility is desired, to allow the advertisement of other
>       parameters later.  The current network advertisement and selection
>       is based on [12].
>
The right reference is [13] and [12], I think.

In addition, both references are very explicit
about extensibility to other parameters: this
is discouraged. As a result the statement in the
draft is quite misleading. Delete the bullet item
or reformulate.

Editorial:

ISSUE: Editorial

Overall, the editorial state of the document
is good. My main problem was that the same
topic (e.g. properties of the Adrangi scheme)
is discussed in several different parts of the
document. But I did not come up with a better
organization, so I'm fine with this as it is.

Smaller issues:

>                 Network Discovery and Selection Problem
> ...
> Abstract
>
>    The so called realm discovery and selection problem affects network
>    access, particularly in the presence of multiple available wireless
>    accesses and roaming.  This problem has been the subject of
>    discussions in various standards bodies.  This document summarizes
>    the discussion held about this problem in the Extensible
>    Authentication Protocol (EAP) working group at the IETF.  The problem
>    is defined and divided into subproblems, and some constraints for
>    possible solutions are outlined.  The document also provides a
>    discussion of the limitations of certain classes of solution,
>    including some that have been previously defined.

There a mismatch between the title and the abstract (realm vs.
network). I think most of the document deals with realm discovery,
but you could also start with a network discovery title and explain
that the realm discovery is a part of the network discovery. This
would actually be my preference, because one of useful features
of this document is that it reminds people of the existence of
various different types of discovery.

>    The realm discovery and selection problem becomes relevant when any
>    of the following conditions are true:
>
>    o  There is more than one available network attachment point, and the
>       different attachment points may have different characteristics or
>       belong to different operators.  In the case of virtual operators,
>       access network infrastructure including e.g. the access points can
>       be shared by multiple operators.

Presumably *realm* discovery is not an issue if you
have a set of access points if they all provide the same
authentication service. Maybe delete the part about different
characteristics.

>  Miscellaneous warnings:
>  - Line 275 has weird spacing: '... realms  are a...'
>  - Line 713 has weird spacing: '...lection  solut...'
>
>  Experimental warnings:
>  - Unused Reference: '4' is defined on line 1019, but not referenced
>  - Unused Reference: '6' is defined on line 1025, but not referenced
>  - Unused Reference: '7' is defined on line 1029, but not referenced
>  - Unused Reference: '9' is defined on line 1036, but not referenced
>  - Unused Reference: '21' is defined on line 1086, but not referenced
>  - Unused Reference: '24' is defined on line 1097, but not referenced
>  - Unused Reference: '26' is defined on line 1103, but not referenced
>  - Unused Reference: '28' is defined on line 1109, but not referenced
>  
>
Please fix the above idnits warnings.

> As noted in [10] Section 4.x, the minimum EAP MTU is 1020 octets,

Delete Section 4.x, or provide the exact reference.

--Jari

_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/eap

Arhives: http://lists.frascone.com/pipermail/eap

---

From: "Bert Weiner" <[email-masked]>
Date: Thu, 07 Sep 2006 18:33:24 -0400

To our friends, relatives, and colleagues:

We are sharing this information about a venture capital investment club of
which we are members, with people and organizations who may want to consider
buying preconstruction real estate from a developer at a discount and then
assigning (“flipping”) it profitably, before closing, to another buyer.  Our
club produces a minimum total profitability of 40%, and structures these
transactions in a way that avoids all risk to its members.  This, of course,
will strike you as too good to be true.  As you read further, however, you
will realize that by shifting all risk out of the member and into the
developer, high profitability with no risk is, indeed, quite attainable. 

Membership in the club is by invitation only.  We invite you to learn more
about it, and then, if you’d like, to apply for membership.  The minimum
commitment to invest is $100,000 (which can control more than $1,000,000
worth of preconstruction real estate).  If you’d like, your investment can
be part of a self-directed retirement account (IRA, 401(k), etc.), or can be
in the name of your business or yourself. 

 Briefly, each club member contracts for the purchase of a unit in a real
estate developer's commercial or residential project, and deposits into
escrow about 10% of about 85% of the developer’s preconstruction price.  The
member’s purchase contract is then assigned (without the member closing), at
100% of the preconstruction price, to a secondary purchaser. The member’s
escrow deposit is always safe because neither the developer nor the club has
access to it (thus avoiding loss to the member if the developer becomes
bankrupt or otherwise fails to complete the project).  The member’s profit
also is protected against the risk of a market decline, because the member’s
price is reduced, dollar for dollar, by the amount of the decline, thus
leaving the profit margin intact.  Upon settlement by the secondary
purchaser, 50% of the net profit is distributed to the member and 50% to the
club (which has borne the costs of putting the transaction together) .  The
member’s 50% amounts to a minimum of 40% of the amount originally deposited
in escrow.  The escrowed amount (typically plus interest), of course, is
refunded to the member. 

The club is able to achieve these benefits and protections for its members
because of its immense buying power derived from having many members, and
because (for a variety of the developer’s own reasons) it is in the
developer's economic best interest to relieve the member of the risks by
taking them on itself.  You are being invited to become a member of the club
because as the cadre of investors increases, the club is able to work with
more developers simultaneously. 

                If you are intrigued enough to want more information, please
call Bert at (301) 593-7744.  Thanks.      Bert and Elaine Weiner

Bert Weiner, J.D., M.P.A.
   Certified Mediator of Divorce, Workplace,  
     Business and Real Estate Disputes.
   Seminar:  "Managing Workplace and Home    
     Conflict To Save, Time, Stress and Money."
   Real Estate Broker: Flipping Without Closing to     
     Safely Yield 41% Minimum.

          (301) 593-7744    Fax (301) 593-3921
[email-masked]     www.mediate.com/bertel

-- 
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.0.405 / Virus Database: 268.12.2/441 - Release Date: 9/7/2006

---

From: "Bari, Farooq" <[email-masked]>
Date: Thu, 7 Sep 2006 15:06:29 -0700

See responses inline.

BR,

Farooq

> -----Original Message-----
> From: Jari Arkko [mailto:[email-masked]]
> Sent: Wednesday, September 06, 2006 7:41 AM
> To: [email-masked]; [email-masked]
> Subject: [eap] review of draft-ietf-eap-netsel-problem-04.txt
> 
> 
[Bari, Farooq] Agree to update the draft accordingly.

>    scalability limitations. See Section 3.1 for further discussion.
[Bari, Farooq] Agree

> example, even if the general point is valid.
[Bari, Farooq] Agree. Bernard had comment on the same part. Propose the
following text.

Since RFC 1035 [1] enables FQDNs to be up to 255 octets in length, this
may not enable the announcement of many realms. The use of other network
identifiers than domain names is also possible, for instance the PANA
protocol uses a free form string and an SMI  Network Management Private
Enterprise Code [17], or Mobile Network Codes embedded in NAIs as
specified in 3GPP.

> draft is quite misleading. Delete the bullet item
[Bari, Farooq] Agree to delete the bullet.

> various different types of discovery.
[Bari, Farooq] Bernard had comments on the same topic in issue 376 and
378. Please see the proposal in response to issue 376.

> authentication service. Maybe delete the part about different
[Bari, Farooq] not sure I understood the comment. The reason for using
the term "different characteristics" was to indicate that the access
networks associated with the attachment points may be from different
technologies (e.g 802.11, 802.16, UMTS etc.) and therefore will have
different capabilities.
 
> >  - Unused Reference: '28' is defined on line 1109, but not
referenced
[Bari, Farooq] Agree to the fixes above.

> Delete Section 4.x, or provide the exact reference.
[Bari, Farooq] Agree to delete "section 4.x" from the sentence.

---

From: Jari Arkko <[email-masked]>
Date: Fri, 08 Sep 2006 10:06:09 +0300

>Enterprise Code [17], or Mobile Network Codes embedded in NAIs as
Ok.

--Jari