[mif] MIF notes

[Hui Deng <[e-mail]>]

Hello all

Please check whether your comments have been covered correctly,
Thanks Stuart Cheshire for taking the notes.

-Hui

* draft-ietf-mif-problem-statement-05
Document in IESG review
Comments received from Dan Romascanu, Lars Eggert, Ralph Droms, Adrian
Farrel, Sean Turner
(See mif-6.ppt)

* draft-ietf-mif-current-practices-02
Review comments from AD:

Marc Blanchet: I wrote Mac OS X section based on observed evidence, not from
looking at the Darwin Open Source code

Bernie H: Move information to appendix

Jari: Delete if incomplete
Andrew Sullivan: Partial information is better than none

Marc Blanchet: I disagree. Incorrect information is worse than no
information

Margaret: The sections are really very weak. Was hoping to prompt vendor
input.

Andrew Sullivan: I still think partial information is better than none. In
the DNS community we have documented various aspects of brokenness.

Jari: Current text is currently not confusing and not very helpful.

Margaret: How to improve it?

Jari: State that text covers only some aspects of OS behavior, and not
others.

Margaret: Conclusion is we need to make text clear, or remove it.

Ted Lemon: There's another draft from Nokia which describes behavior. A
standardized template for the descriptions would make it clearer which
information is missing for which OSes.

* Split-DNS solution (Teemu, 10 min)

Jari: Lack of "." entry means no "default resolver". What does lack of this
DHCP option mean?

Teemu: This is not Not deprecating the existing DHCP option

Jari: Need to document how it interacts with existing DHCP option. What if
packet has both? Neither?

Dave Thaler: What if one interface gets old DHCP option and other interface
gets this new DHCP option, how do they interact.

Ted Lemon: This seems like a really bad idea. Security implications are mind
boggling. Creates lots of opportunities for attacks without stating how to
deal with them. Using this option should *require* DNSSEC.

Teemu: Vulnerabilities are not new.

Ted Lemon: But this allows more targetted vulnerability.

Teemu: RFC 4191

Ted Lemon: This is the wrong way to solve problem. Should not be adopted by
WG. If we want to add a new DHCP option we should add a new DHCP option
saying "you're connected to a hot spot". This adds complexity with no
benefit.

Stuart Cheshire: Problem is conflicting info. When you have two interfaces,
and two DHCP configurations, giving two DNS servers, and the two DNS servers
give conflicting answers, what do you do.

Ted: Public DNS server should simply drop packets asking about name that may
exist in some other "private" server, instead of NXDOMAIN.

Stuart Cheshire: Defining "silently drop" as response to query seems odd.
Dave Thaler: Servers currently respond with NXDOMAIN for private internal
names that don't exist externally. This WG is limited to defining client
behavior in today's world, not mandating new behaviour for servers and
operators.

Olafur: When connected to multiple providers, may get better answers from
some providers that others. E.g. On phone connected to China Mobile and IETF
WiFi, may get different answers for "google.com" from each provider. I may
consider the IETF WiFi answer "better", but not if I'm going to try to reach
it over China Mobile.

Andrew Sullivan: Arguments sound circular. How do we figure out what network
context we are in?

Gaetan Feige: Repeated Olafur's point.
Andrew Sullivan:

Hui Deng: Is this ready to adopt?

Jari: Don't think this draft is ready to adopt as WG draft.

Teemu: We talked about this in Maastricht, and no one commented on the
mailing list that time. Don't want to wait until Prague to talk about this
again.

* DHCP Route Option draft, Wojciech Dec
   See mif-1.ppt

Hui Deng: How many people have read draft? 20

Hui Deng: How many people think we should adopt as WG item? 15

Hui Deng: How many people think we should not adopt as WG item? 0

* MIF api (Juri, 10 min)

TED Hardie: Session layer using DTLS. Want to be able to talk about groups
of interfaces as well as individual interfaces. Not clear this API supports
that.

Ted Lemon: You've gone quite a long way down a path here. Not saying it's
the wrong path, but I've seen no discussion of this on WG mailing list. What
functionality does OS have to provide? Should propose some high-level
API(s), and from those, work out what functionality does OS have to provide.

Juri: This is intended to be a starting point, not far down a path or a
final solution.

Ted Lemon: Would like to see public discussion on WG mailing list.

Juri: We plan to start implementing soon.

Dave Thaler: We faced these problems. We use Scope ID and sockaddr. A Scope
ID names set of interfaces.
Dave Thaler: Should separate abstract API issues from concrete API issues.
Concrete sockets API is owned by Austin group.

* Connection manager requirements (Gaetan Feige , 10 min)

Gaetan Feige: "Connection manager" may be a poor choice of name.

Gabor Bajko: Some of these cases are annoying. When you have link layer
connectivity but no IP connectivity until you authenticated. There is is
ongoing work in the WiFi alliance. WiFi alliance covers both service
provider space and enterprise space.

Gaetan Feige: My understanding is that the WiFi alliance covers user
authentication, but doesn't cover routing, DNS, etc.

Gabor Bajko: WiFi alliance covers Problem

Margaret W: WiFi alliance work tends to be WiFi-specific.

Is WiFi alliance work covering ways of having

Gabor Bajko: WiFi alliance work focuses on picking right WiFi network to
join; still up to implementation to test if IP connecivity works.

Margaret W: So WiFi alliance provides part of the answer but there are still
problems that MIF needs to address.

Yuri Ismailov: What kind of "session layer" are you talking about?

Yuri Ismailov: Managing/configuring virtual interfaces? Virtual interfaces
should be standardized and presented explicitly to the system.

Gaetan Feige: Linux advanced routing has routing stack per interface.

Yuri Ismailov: API should expose purpose of each virtual interface.

Gaetan Feige: Don't want to burden every application with handling multiple
interfaces. Want to try to make it automatic.

Andrew Sullivan: Need to solve this for DNS too. This is exactly the
circularity argument we were having earlier.

* Holding the on-going sessions (Zhen, 5 min)

Yuri Ismailov: When talking about solutions to this problem, do Mobile IP,
HIP, SCTP, etc. already solve this problem?

Zhen: With IP mobility sessions move to new interface

Yuri Ismailov: Application session moves to new interface

Zhen: Intention here is that when new interface becomes available, new
sessions use that new interface but established sessions continue to use old
interface.

Dave Thaler: When you say "session" do you mean "TCP connection" or
something higher layer? With strong host model this is not a problem,
because TCP connection stays bound to one interface.

Gaetan Feige: Windows has strong host model?

Dave Thaler: Yes, everything later than XP uses strong host model for both
IPv4 and IPv6.

Gaetan Feige: Strong host model can mean that you have lots of bandwidth
available that you're not using.

Margaret: Does WG think we should extend problem statement to cover what to
do with ongoing connections when network environment changes?

Simon Perreault: Problem should be reformulated in terms of host models:
Weak or Strong.

Margaret: You mean we should state that if you use strong host model then
you'll have these issues; if you use weak host model then you'll have these
other issues.

Juan-Carlos Zuniga: We still have some homework to do, but I belive these do
belong in the problem statement.

Ted Hardie: Has to be scoped carefully. If you're treating set of interfaces
as a group, having interfaces join and leave the group is not the same as
interface going up or down. Exposing when interfaces join and leave the
group would be useful. How sessions handle that

Margaret: Our analysis will include that applications will have different
requirements. Applications need ways to influence behavior.

Ted Hardie: Right, a web browser has different requirements to a
jitter-sensitive application.

Margaret: There may be multiple definitions of layer 3 connectivity too.

Margaret: Should we expand the problem statement to cover this? 12-15 hands.

Margaret: Should we not expand the problem statement to cover this? 0 hands.

draft-cao-mif-analysis-01
See mif-3.pdf

Margaret (as individual): I fee we should wait. Do analysis after we define
problem(s).