Problem Statement for Network-Based Localized Mobility Management (NETLMM)
draft-ietf-netlmm-nohost-ps-05

[Ballot comment]
I agree with the claim in the security considerations section that the
security requirements for signaling are the same as the security
requirements for routing information.  However I caution the netlmm
working group that what we want out of routing information security is
not at all what our current routing protocols deliver.  It is probably
not sufficient for a new working group such as netlmm to deliver the
same security as older routing protocols such as OSPF, IS-IS and BGP.
In particular, automated key management is probably necessary.  I
strongly recommend that netlmm start a discussion of what security is
required today rather than assuming an answer that may lead to
surprise later.

This document does not discuss security implications when a mobile
node moves from a link with one security configuration to a link with
a different security configuration.  For example if I move from a link
that requires 802.11i to one that has no authentication , my available
security changes.  Of particular concern are situations where an
attacker can make it appear that a node has moved to a link with
significantly less security.  It's fine that this document does not
discuss that concern.  Some document from netlmm needs to discuss that
issue.  You will either need to conclude the risk is acceptable or to
provide appropriate mitigation.

[Ballot discuss]
The security considerations section of this document claims that
netlmm introduces a need for access network to local node security.
If true, I don't understand how that requirement is compatible with no
changes to the mobile node.  I also don't see how you would implement
such a requirement: what authentication would be used?

However I'm somewhat dubious of such a requirement.  How is network
access under netlmm different than link layer network access?
I'd recommend reconsidering whether such a security requirement exists.

[Ballot discuss]
1. The document uses the teem 'WLAN switch' which is neither standard (afaik) nor explained - I suggest that a short definition be added
2. The document refers to several IEEE 802 protocols without providing references, and with incomplete designation in the text ('802.3', '802.11'). References are important because capabilities of the LAN protocols that are being discussed largely depend on the flavor of the Ethernet or WLAN protocol that is being used
3. The claims in Section 3.1 are vague, and I had a hard time understanding them. What is a 'large campus'? What has the presence of one or multiple VLAN has to do with scalability? Why is this linked with IEEE 802.3? - VLANs do not apply only to Ethernet. And what kind of VLANs - 802.1Q or 802.1ad? the reference question is important here, scaling capabilities are very different between these IEEE 802.1 protocol flavors
4.      '2)Each WLAN switch vendor has its own proprietary protocol that
        does not interoperate with other vendor's equipment.

        3) Because the solutions are based on layer 2 routing, they may not
        scale up to a metropolitan area, or local province.'

The IEEE 802.1 Working Group published or have in works a number of standards that at least according to their claims scale well at or beyond metro area limits. Would such protocols meet the needs listed in the Problem Statement, or are there specific needs that could be solved only by layer three protocols.

In general I believe that Section 4 could benefit from some editing. After listing the problems with the existing solutions, it should rather list the requirements of a solution that would fix those problems, rather than directly proposing that other solution.

[Ballot discuss]
1.1 Terminology

        Local Mobility (revised)
          Local Mobility is mobility over an access network. Note
          that, although the area of network topology over which the
          mobile node moves may be restricted, the actual geographic
          area could be quite large, depending on the mapping between
          the network topology and the wireless coverage area.

Please state clearly whether an access network spans one or
multiple IP subnets. (In fact, a separate definition of "access
network" might be useful.)

3.1 Large Campus

    One  scenario  where  localized  mobility  management  would  be
    attractive is a large campus wireless LAN deployment.  Having a
    single broadcast domain for all WLAN access points doesn't scale
    very well.  Also, sometimes parts of the campus cannot be covered
    by one VLAN for other reasons (e.g., some links are other than
    802.3).

The 802/VLAN reference seems confused here. (1) is it 802.3, or 802.1
(where VLANs live)? (2) is it 802.3, or 802.11/16/other wireless?
(3) Are we discussing VLAN support across 802 MAC variations, or
something else? A rewrite seems needed.

[based on Gen-ART review by Spencer Dawkins]

[Ballot comment]
1.1 Terminology

        Local Mobility (revised)
          Local Mobility is mobility over an access network. Note
          that, although the area of network topology over which the
          mobile node moves may be restricted, the actual geographic
          area could be quite large, depending on the mapping between
          the network topology and the wireless coverage area.

Please state clearly whether an access network spans one or
multiple IP subnets. (In fact, a separate definition of "access
network" might be useful.)

3.1 Large Campus

    One  scenario  where  localized  mobility  management  would  be
    attractive is a large campus wireless LAN deployment.  Having a
    single broadcast domain for all WLAN access points doesn't scale
    very well.  Also, sometimes parts of the campus cannot be covered
    by one VLAN for other reasons (e.g., some links are other than
    802.3).

The 802/VLAN reference seems confused here. (1) is it 802.3, or 802.1
(where VLANs live)? (2) is it 802.3, or 802.11/16/other wireless?
(3) Are we discussing VLAN support across 802 MAC variations, or
something else? A rewrite seems needed.

[based on Gen-ART review by Spencer Dawkins]

Submission notes from the chairs below. In addition, please note
the additional observations:

- The other chair (Phil Roberts) concluded the WGLC as James Kempf
  is an author.

- I have also gotten confirmation from Phil Roberts that he has
  reviewed the spefication and is OK with it.

- There's been persistent debate in the NETLMM WG (and spilled over to
  the int-area, iab, and ietf lists) about the appropriateness of
  the NETLMM work, focusing partially on the statements in this
  document. This debate has been raised by only one person Hesham
  Soliman. (And in addition there was an earlier anynymous April 1
  draft submission with some of the same complaints.) However, the
  dissitents did not appear to gain traction in the discussion. From
  what I can tell, the WG has considered the arguments, and is moving
  on.

----

1) Have the chairs personally reviewed this version of the ID and do
  they believe this ID is sufficiently baked to forward to the IESG
  for publication?

James Kempf has reviewed the document, since he is editor. He believes
it is ready for publication

2) Has the document had adequate review from both key WG members and
  key non-WG members? Do you have any concerns about the depth or
  breadth of the reviews that have been performed?

We obtained three solicited reviews: Gab Montengero, Vidya Naryanan,
and Pete McCain. Gab and Pete are not WG members, both are WG chairs
of other mobility-related WGs and are members of the Mobility
Directorate. The document was also reviewed by Pekka Savola, not a
WG member. The document has had lots of commentary from the WG,
21 issues were filed at the tools.ietf.org Web page on the document,
all have been resolved. We went through two WG last calls on the
document.

3) Do you have concerns that the document needs more review from a
  particular (broader) perspective (e.g., security, operational
  complexity, someone familiar with AAA, etc.)?

We believe the document has had sufficient review.
 
4) Do you have any specific concerns/issues with this document that
  you believe the ADs and/or IESG should be aware of? For example,
  perhaps you are uncomfortable with certain parts of the document,
  or whether there really is a need for it, etc., but at the same
  time these issues have been discussed in the WG and the WG has
  indicated it wishes to advance the document anyway.

No.
 
5) How solid is the WG consensus behind this document?  Does it
  represent the strong concurrence of a few individuals, with others
  being silent, or does the WG as a whole understand and agree with
  it?

There has been a lot of comment from WG members on the document, we
believe the comments have been resolved to everyone's satisfaction.

6) Has anyone threatened an appeal or otherwise indicated extreme
  discontent?  If so, please summarize what are they upset about.

No.
 
7) Have the chairs verified that the document adheres to _all_ of the
  ID nits?  (see http://www.ietf.org/ID-nits.html).

I ran it through the tools.ietf.org nits checker. It checked OK.

AD review performed on June 14, 2006 and sent to the chairs. Chairs agreed with comments, and will also take care of finishing WGLC in the correct way. A revised ID needed to take care of the few smallish issues found in the AD review. Good document!