[mif] MIF IETF 80th draft minutes

[Hui Deng <[e-mail]>]

Hello all

Please help to check the below draft minutes, thanks Jouni's kind help to
take minutes.
Forget who help to take jabber, thank you as well.

There are several ..../??? in the minutes still, please help to correct
them,

thanks in advance

-Chairs.


MIF Monday 28.3.2011
1 Agenda bashing (Chairs, 5 min)
2 LC documents (Chairs, 10 min)
>>draft-ietf-mif-problem-statement-05
Updated according to #79 discussions.
New problems added:
 - On going session continuity, IP connectivity
 - TCP sessions break if host implements weak host model
Jari Arkko: Discusses from other ADs. Are those addressed?
Margaret: Will send mail and check whether all are addressed.
Jari Arkko: Ralph Drom's discusses were pretty complicated.
Dave Thaler: On the 1st problem. I do not understand the case.
             Interface change does not cause the connection to
             break but e.g. an ingress filtering.
Margaret: We had a document on this in the last meting. One interface
          went down and other came up to as a backup.
Dave Thaler: That is not about the weak host model.
Margaret: Need to clarify the terms.
Zhen Cao: Same problem with strong host model also. It is not only the
          weak host model.
Dave Thaler: Asymmetric routing can cause the session go down but that
             is due filtering etc not the host model.
Brian Carpenter: There's a architectural probelem that this document
                 starts building a solution already.
Ted Lemon: Two observations: the draft is already past WGLC thus little
           to do. Agree there is an architectural problem.
Thomas: Seconds Brian. Architectural problem needs to be fixed before
        than doing other things in this space.
Scott:  Repeats.. get this document out and say these are the problems,
        and MIF is not probably the group to solve those (refers to
        architectural problems).
Margaret: This group was to figure out some of those point solutions
          that are needed. The group is not currently chartered to
          solve the big (architectural) problem of all mif issues.
Jari: We can try find an architecture that we should have. However,
      that does not seem to be optimistic. This document tries to
      describe these. Still OK to fix some of the known mif
      problems.
Margatet: ..
Jari: Not always necessary to define new protocols but document
      existing stacks. That is also useful.
Ted Lemon: Anybody here understand the architecture we try to describe? :)
           Thinks one more scenario is missing but the timing is bad to
           introduce anything new to the document.
Jari: Yes it is..
Ted:  In the last IETF I complained about one point solution because
      my architectural view does not match what others had in mind.
Scott: Not a problem statement only for the MIF WG but a problem
       statement for the whole internet.
Marc blanket: Next steps?
Margaret: Not going to define the architecture in this document. Rather
          ask the 3 ADs whether the document can progress as it is now.
Jari: Hoping to move it to LC.
Deng Hui:  Ted's issue/problem needs to be included?
Jari: Do not know what problem he is referring. current document has
      a limited scope. If the scope gets widened all kinds of
      new issues show up. Address Ted's issues/problem later.
Ted: About different trusted provisioning domains. Those should be
     explained. like DNS servers lie to you. You do not switch from
     a working to nonworking sandbox..
Marc: This is already described but not in these exact words.
Jari: It is about there is one network that is more trusted than
      other.. and that scenario is already described.
Ted: It is about that the host automatically connects to
     unauthenticated WLAN when one comes up. Whether the user wants
     or not. Other scenarios described on detail but not this.
Margaret: Asks Ted to post his issues/problem/scenario to the list.
???:  Points that 3484bis.. whether something has been missed
      regarding mif.
Margaret: Not really a problem of this WG? More like 6MAN's that is
          working on 3484bis.
>>draft-ietf-mif-current-practices-02
Apple section removed due lack of info.

3 Current Practice Analysis (5 min)
>> draft-cao-mif-analysis-01
Margaret: Little feedback from the WG. Does the WG think we need to
          continue with this work?
Ted: Analysis and current practices look the same.. confused..
Margaret: Should contains material that comes after current practices
          when looking identified issues through the problem statement.
Brian: Contains blanks.. those need to be filled in. Asks for
       architectural analysis. The analysis that needs to be in
       context of better architecture and not point solutions. Someone
       needs to do an architectural analysis.
Scott: Agrees with Brian. Need to fork the document. Need to
       contribute to the bigger architecture, which might be out of
       scope of this group. i.e. two documents.
Ted: Thinks is ok.
Jari: I am interested. One document though.
Margaret: The WG interested to do this? -> reasonable number shows
          hands. Please volunteer.
4 Working Group Documents
>> draft-ietf-mif-dns-server-selection-01 (Teemu, 10 min)
Most changes due the comments from Ted Lemon.
Andrew: Likes the improvements. Applications area said none of these
        (for DNSSEC) are deployed today. Need to have the revised text.
Teemu: Would you contribute the text (I do not know DNSSEC and trust
       anchors in detail enough).
Peter Koch: A bit concerned about the operational issues. Is the trust
            anchor used to distinguish which answer is a good one?
Teemu: Explains the NXDOMAIN case with intra and extra DSN servers
       (both validates)
Ted: Split horizon issue.. I don't know how to deal with this
     problem and that is the reason why this document was produced.
Peter: ...
Ted: Like the draft much more now. The draft bases on that the
     mobile node trusting some provisioning domain more to select
     the DNS server. I need to look more into this.
Teemu: ...
Ted: How to distinguish between trusted domains?
Dave: What about the case where the host does synthesis and other
      DNS server gives a native addresses? Which one to prefer.
Andrew: Brings up validations and synthesis.. You are totally lost
        in that case.
Teemu: How about IPv4? Any support needed for it?
Ted: Did not even notice that (IPv4 being not addressed).
Teemu: Multihoming with IPv4 is even more pain. We have serious
       problems there. Do we need to support for IPv4 or just
       stick with IPv6?
Ted: Does not mind if it works only in IPv6.
Teemu: Is ok not to support IPv4?
Margaret: We should do both..
Ted: Do not put IPv4 addresses into DHCPv6.
Margaret: If IPv4 needed -> do DHCPv4 solution.
* general discussion different Mif models. IPv4 only WLAN,
 IPv4v6 (dual-stack) cellular.. in different domain.
Dave: Says having IPv4 in DHCPv6 could be ok.
Jari: ...
Dave: What is the use case where you need different server per
      different name space that are delivered in the same
      DHCPv6 reply?
Margaret: Explains the two interfaces cases, two DHCP servers and
          several domains through those.
               ...
Ted: Brings up the case where DNS is configured using RAs (RFC6106).
     Then this solution is not applicable and one is tempted to use
     DHCPv4 options.
Ted: So may different scenarios that are not thought in this
     document -> loads of standards work (DHCPv4, DHCPv6, ..)
Dapeng: Need to support IPv4, maybe in a separate document.
Andrew: We seem to be tempted to do split DNS work reliably, which is
        broken by definition. If you want to solve it in large, it
        won't work. scope it well.
Thomas: Better scoping needed. Says only one DHCP response per
        interface and those have no conflict within an interface.
Margaret: Trying to provide hints that there is no need to query all
          known DNS servers to get an answer.
Thomas: Need better scoping.
teemu: Move the discussion to the list.
>> draft-ietf-mif-dhcpv6-route-option-01 (Woj, 20 min)
Ted:      Return nothing. (answer Woj's question).
Margaret: Not in IESG yet, rtg area doing review in advance.

5 Re-charter, milestone discussion
>> draft-liu-mif-api-extension-04
Note takes thinks most of these options are already provided
most APIs.. like BSD ioctl()s.
xyz:     Why S_ADDR needed?
Dapend:  You need to do specify the source address.
Margaret: Sockets API already allows you to do that.
Marc:   RFC3542..?
Dave: Will send comments to list. Also discussion about abstract API.
      There was a WG consensus not to do concrete APIs.
Margatet: Chartered to do abstract APIs.
Dave:   Austin Group owns the sockets API. For interface selection API
        there is no standard. We should look at what current OS
        APIs provide.
Ted:    Thinks the right way now is rewrite the whole document. Wants
        to be loop as he has lots of ideas here.
Alan Ford: Seconds Dave. Points to mptcp astract API work and asks for
           collaboration.
jabber:      Asks why not using advanced API from RFC3542?

>> draft-korhonen-mif-ra-offload-01 (Jouni, 10-15 min)
Alexandru Petrescu: Question whether both networks have to be
                    controlled by same administrator.
Jouni:          no, they don’t have to.
Ted Lemon: This document is more for addressing which network to prefer
           rather what address family to prefer. This approach could
           have some security implications (misuse). Additionally
           technical comment that shall be discussed offline.
>> draft-chen-mif-happy-eyeballs-extension-00 (Chen, 10 min)
          5.4 Multiple connections (Sri, if time allowed)
scott:  .. (missed)