Requirements for Distributed Mobility Management
RFC 7333
Yes
No Objection
Note: This ballot was opened for revision 15 and is now closed.
(Brian Haberman; former steering group member) Yes
(Adrian Farrel; former steering group member) No Objection
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.
(Alia Atlas; former steering group member) (was Discuss) No Objection
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.
(Alissa Cooper; former steering group member) No Objection
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?
(Barry Leiba; former steering group member) (was Discuss) No Objection
Version -16 moves three references to "normative", and addresses my issue. Thanks!
(Benoît Claise; former steering group member) (was Discuss) No Objection
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.
(Jari Arkko; former steering group member) No Objection
(Joel Jaeggli; former steering group member) No Objection
(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.
(Kathleen Moriarty; former steering group member) No Objection
Thanks for addressing the SecDir comments already.
(Spencer Dawkins; former steering group member) No Objection
(Stephen Farrell; former steering group member) No Objection
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?
(Ted Lemon; former steering group member) (was Discuss) No Objection
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.