Requirements for Distributed Mobility Management
draft-ietf-dmm-requirements-17

I have no objection to the publication of this document as an 
Informational RFC.

---

I believe you could useful clarify "levels of routing hierarchy" through
an addition to Section 2.1

---

The shepherd write-up is silent on question 11 which is a shame because
this revision has nits.

---

In Section 5, it would be nice if the paragraphs "This requirement 
addresses..." were indented with the requirements they belong to. 
currently it looks like they are header text for the next requirement
rather than footer text for the previous requirement.

I would like to see the applicability and deployment considerations clearly documented.
I am happy for this to be part of the rechartering rather than requiring it in this draft.

I understand that with work, the current deployment environment may be changing.

Good stuff. Couple of nits:

There are a few places where the phrase "the DMM solution" is used, but I'm under the impression that multiple solutions exist and may be standardized, so it would probably be better to talk about "a solution" or "solutions."

Section 1:

"Yet these mechanisms were not pursued in the past owing to charging and billing which
        require solutions beyond the mobility protocol.  Consequently,
        assigning a gateway anchor node from a visited network in
        roaming scenario has until recently been done and are limited to
        voice services only."

I'm having trouble parsing this. Is it supposed to say "assigning a gateway anchor node from a visited network in a roaming scenario has until recently not been done"? Is the cited "roaming scenario" the same as the off-load scenario described earlier in the paragraph?

Version -16 moves three references to "normative", and addresses my issue.  Thanks!

Thanks for working together on REQ6: Operation and Management considerations.
Next time, let's work on this while the document is still in the WG.

 (1)  Mobile users are, more than ever, consuming Internet content
        including that of local Content Delivery Networks (CDNs) which
        had not taken mobility service into account before.  

It's a bit more accurate to characterize this as the CDN's being unable to take mobility services into account due to the design of mobile networks.

It's fair to say  that I don't think I'm  going to like what we do next here. but I can live with this document.

Thanks for addressing the SecDir comments already.

I have two suggestions:

- REQ6: Why MUST existing security protocols be used to
mitigate risks introduced because of a DMM solution? That
seems wrong. I think you want to say that you prefer
existing security protocols and strongly prefer existing
security mechanisms.

- REQ6: I would suggest that adding a sentence to REQ6
along these lines might be appropriate: "A DMM solution
SHOULD improve security and privacy for the user and the
network where possible." Merely saying "do not be worse"
seems like a fairly lame requirement given that the threat
landscape is constantly evovling and this is not aiming
for very short term deployments only. Make sense?

I'm clearing the DISCUSS based on discussions with the authors.

In section 1, item 1, first paragraph:
        Evolved Packet Core (EPC) [TS.29303].  Yet these mechanisms were
        not pursued in the past owing to charging and billing which
        require solutions beyond the mobility protocol.  Consequently,
        assigning a gateway anchor node from a visited network in
        roaming scenario has until recently been done and are limited to
        voice services only.

This reads (to me) as if there's some intent to charge/bill for content delivery through WLAN offloading.   Is that correct?

Also, the last sentence just doesn't parse.   Can you explain in a slightly longer form what it is intended to mean?

Text of former DISCUSS:

Based on discussion with the IESG, I am updating this DISCUSS.

My concern about this document is that it's making a change to the way mobile IP is done that I think is a very good change, but I don't think it's going far enough.   I think that with some relatively small changes, this could be stating requirements for a mobile IP architecture that works well in the currently intended environment, but also allows for a permissionless mode of operation—that is, allows at least some more intelligent mobile devices to participate in the mobile architecture even when they connect to a network that is not operated by their mobile operator, and that has no formal agreement to interoperate with their mobile operator's mobility infrastructure.

This is important for two reasons.   First of all, it allows for greater utility for the mobile device when it is in a location where the mobile operator provides no service, or provides poorer service than is available on a local non-affiliated WLAN.   Second, it creates an opportunity for lock-in, where by offering better service on the affiliated network than is available on a non-affiliated network, the customer will be motivated to switch wireline providers, and possibly to set up their home network in a way that isn't in their overall best interests in order to accommodate the mobile provider's mobility infrastructure.

To address this DISCUSS, what I am asking for is a change to REQ5 as follows.
OLD:
          protocols.  Furthermore, a DMM solution SHOULD work across
          different networks, possibly operated as separate
          administrative domains, when allowed by the trust relationship
          between them.
NEW:
          protocols.  Furthermore, a DMM solution SHOULD work across
          different networks, possibly operated as separate
          administrative domains, when allowed by the trust relationship
          between them.

REQ5a:
          In cases where there is no trust relationship
          between administrative domains, it should still be possible
          for a node to authenticate to its provider's mobility
          infrastructure so that it can offer mobility service to
          applications that require it.

REQ5b:
          When roaming on networks for which there is no relationship
          between administrative domains, some services such as QoS
          may not be achievable using DMM signaling.   A DMM
          solution should specify a fallback mechanism for
          providing QoS when it is required (e.g. for emergency
          service) and the provider network is available, even
          when the non-affiliated WLAN is being used for offload.

REQ5c:
          A DMM solution may have some mechanism for negotiating
          QoS with a non-affiliated provider.

The last bit isn't really a requirement, but more of a "would be a good extension, probably doesn't belong in the base spec".   None of this is text I seriously think should go in the document as written—I'm just providing it to illustrate what it is that I am asking for.   How this DISCUSS gets resolved depends on how the IESG as a whole reacts to it.

BTW, although my expertise on mobile IP protocols is very shallow, the requirements I'm proposing here are not motivated purely by  my personal preferences as an end-user.   The new requirements I'm suggesting would allow mobile operators to extend their service offerings to handsets in environments where that currently isn't possible.   This capability is currently an open item in some discussions I've had with mobile operators, and a DMM solution that addressed it would be very helpful.