* WGs marked with an * asterisk has had at least one new draft made available during the last 5 days

Add Status Pages

Adaptive DNS Discovery ()
Int Area: Éric Vyncke, Erik Kline | 2020-Feb-21 —  
Chairs
 
 


IETF-107 add minutes

Session 2020-03-24 2000-2200: Virtual Track 1 - add chatroom

Minutes

minutes-107-add-00 minute



          **********************************************************************
                    Agenda & Minutes
          **********************************************************************
          Chairs: Glenn Deen and David Lawrence
          Notes: Barbara Stark (hopefully with help)
          Jabber Scribe: 
              
          Etherpad is at:
             
          https://etherpad.ietf.org:9009/p/notes-ietf-107-add?useMonospaceFont=true
              
          Webex is at: (220 on webex)
             
          https://ietf.webex.com/ietf/j.php?MTID=m342b913bf84bd74824d9dec9b153b872
              
          Jabber is: add@jabber.ietf.org  (104 people on jabber)
          
          Blue Sheets are at the bottom of this etherpad page
          
          ADD Agenda for IETF107 
          ======================
           
          1.         Introduction to ADD WG    [Chairs ]
          
          2.         Agenda Bash
          
          3. 15min   draft-arkko-abcd-distributed-resolver-selection  [Jari
          Arkko/Ted Hardie]
          
          4. 15min   discovery-selection directions  [Tommy Pauly]
          
          5. 20min   draft-btw-add-home  [Dan Wing]
          
          6. 10min   draft-reddy-add-server-policy-selection [Dan Wing]
          
          7. 15min   draft-mglt-add-rdp  [Daniel Migault]
          
          8. 15min   ADD Q&A  [Chairs et al]
          
          *********************************************************************
          Minutes
          *********************************************************************
          1&2. Introduction to ADD WG and Agenda Bash
          Main Agenda:
          https://datatracker.ietf.org/meeting/107/materials/slides-107-add-agenda
          
          Glenn Deen started the meeting. Note the instructions on the first slide.
          And note the Note Well.
          No bashing of the agenda on slide 4.
          Glenn provided ADD history, while displaying the really nice pictures
          of the chairs on slide 5.
          
          Barry Leiba: As AD, had no comments at this time.
          
          *********************************************************
          3. draft-arkko-abcd-distributed-resolver-selection  [Jari Arkko/Ted
          Hardie ]
          Ted Hardie presented. Slides:
          https://datatracker.ietf.org/meeting/107/materials/slides-107-add-dns-resolver-selection-arkko-hardie
          
          Tommy Pauly: Thank you for coming up with this. First, when you have
          ordering of common types, I would expect network resolver to be most
          common. It's important for local network interaction to view local
          network resolver as status quo. Otherwise, many assumptions will break,
          e.g., about provisioning domains, etc. Reducing concetration of info is
          useful, but need to consider privacy impacts not just in resolution but
          also in context of entire connection.
          
          Mohit Sethi: Question about interface selection. I assume by interfaces
          you mean wifi, eth, etc.? And then you use different resolver per
          interface? Some devices can only do one interface at a time. What are
          impacts if interface is not up? Do you allow use of a resolver discovered
          on an interface that is no longer up and running?
          
          Ted Hardie: If you have multiple ifaces, each with different resolver,
          it's ok to have name resolution associated to specific iface. Do
          mechanisms developed take this optimization into account?
          
          David Lawrence (chair): Will close mic line after Warren. 
          
          Pete Resnick: Suggestion -- it does seem VPN case is subsumed by multiple
          interface case because the VPN case is just multi iface where 1 iface is
          VPN. So no need to separate out. Question -- If WG answers yes to first
          question, what happens. Is this a WG doc? Is this just a use case doc?
          
          Ted Hardie: This isn't really a good place to discuss the draft. But
          various possible outcomes exist. It may also be that we decide we cannot
          achieve this optimization.
          
          Ben Schwartz: Yes, the WG should consider approaches that result in
          multiple resolvers being discovered. As for optimization question,
          that relies on WG to have increased understanding of where queries
          go. So maybe just say configs that alter the concentration and leave
          it to future users/implementers to decide what is optimal. As for 3rd
          question, we shouldn't guess at some of these.
          
          David Lawrence: 5 people left in queue. Please keep comments brief.
          
          Sanjay Mishra: WG should look at these issues. Did you (draft authors)
          have chance to see what impact different resolvers would have on
          performance.
          
          Ted Hardie: No.
          
          Sanjay Mishra: Would you consider looking at this?
          
          Ted Hardie: The WG will need to answer performance questions more broadly.
          
          Eric Rescorla (EKR): I think the best place for this draft would be as
          an analysis draft. Please don't say we should treat network resolvers
          as status quo.
          
          Ted Hardie: There are some cases where we cannot assume sets of resolvers
          are equivalent.
          
          EKR: I'm suggesting focusing on the 2nd of the cases you described.
          
          Chris Box: Using multiple resolvers imples multiple privacy policies. Some
          may be "better" than others. 
          
          Glenn Deen: Thank you.
          
          *************************************
          4. discovery-selection directions  [Tommy Pauly]
          Tommy Pauly presented. Slides:
          https://datatracker.ietf.org/meeting/107/materials/slides-107-add-adaptive-dns-paully
          
          EKR: Once you control DNS, ESNI is lost. But that isn't necessarily true
          here. Larger point is this seems to have some large failure cases. Take
          case of resolvers A and B where A gets 90% of traffic. In this case,
          temporary traffic shifts are hard to fix.
          
          Tommy Pauly: ESNI does require DNSSEC -- that's true. But just because
          we present this way doesn't mean DNSSEC isn't there.
          
          EKR: Every ISP will want to advertise itself as authoritative. My concern
          is that makes the traffic allocation at any point in time stable and
          hard to change.
          
          Tommy Pauly: I do want to get more input from the group on ths. I see
          2 deployment scenarios. There could be a DoH resolver in charge of
          splitting traffic between 2. Or there is no reason there cannot be 2
          designated load-balanced servers.
          
          Erik Nygren: Is it accurate that ...  ... and I'll put that in the
          jabber chat.
          
                           erik: To EKR's concern, one approach would be that the
                          .well-known/pvd would have its domain be the SvcDomainName
                          in the HTTPSSVC record.  For example with: 
                          "www.example.com 7200 IN CNAME foo.cdn1.example."  
                          and "foo.cdn1.example. 7200 HTTPSSVC 1 ."  then if
                          the policy is on "https://cdn1.example/.well-known/pvd"
                          it would apply for just that one CDN.  And since it is
                          the A/AAAA records for "foo.cdn1.example" which want to
                          have lower TTLs and the CDN-controlled mapping then this
                          addresses the issue.  
          
          Tommy Pauly: Thanks. I'll look at that.
          
          Andrew Campling: How do I as a user express my preferences? It looks
          like the machine is taking control. How can I say I only want certain
          resolvers?
          
          Tommy Pauly: Good question. That's something the WG needs to talk
          about. This here is just about discovery of resolvers. I think what you
          describe is follow-on discussion that's needed.
          
          Ralf Weber: There might be some situations where this provides more info
          about the client than the way things are now. The DoH or DoT server will
          get all client info. Maybe that's something you can improve on.
          
          Tommy Pauly: Good point. We need to take into account which resolver
          you're using. If we could limit so that for google.com I'm only talking
          to Google server, hopefully we can keep info from going elsewhere.
          
          Ralf Weber: There are other requirements, too. Not just top level,
          2nd level.
          
          Puneet Sood: This works well where connectivity and DNS are operated
          by same entity. For small ISPs, this may not be the case. In that case,
          there will not be a net improvement for the client.
          
          Ben Schwartz (from jabber): I understand how this scheme improves privacy
          when combined with Oblivious DNS, but in the absence of Oblivious DNS
          (which is out of scope for ADD) I think this is only a privacy improvement
          for certain assumptions about TTLs, and some queries will leak when TTLs
          expire.  I'd like to see those assumptions clarified, and see if there
          is a simpler solution, such as using long-lived CNAMEs.  I'd also want
          some consideration about whether these long TTLs are a tracking vector. 
          
          Tommy Pauly: Good comment and a discussion we should continue having.
          
          Warren Kumari: I don't know what a Google name is. There are 1000s
          of names. If I know a priori what maps then I don't need to ask a
          resolver. If I don't know, then I have to ask  a resolver. 
          
          Tommy Pauly: You can switch after you disover that something is a
          Google name.
          
          ******************************
          5. draft-btw-add-home  [Dan Wing]
          Dan Wing presented. Slides:
          https://datatracker.ietf.org/meeting/107/materials/slides-107-add-btw-add-home-wing
          
          Jim Reid: Question about verified resolvers. 
          
          Dan Wing: The intent is that if you're a subscriber to Comcast, you
          would say "I want Comcast-signed DoH servers" and then use them.
          
          Martin Thomson: I think it's sad there are lists at endpoints. CPE don't
          get upgraded in my experience. 
          
          Dan Wing: I'm familiar with and agree with that analysis.
          
          Ralf Weber: The CPE angle is one I've thought ablout. There are ISPs
          who manage their CPE, and those can be relied on to be up-to-date. Why
          DoH and not DoT between client and CPE?
          
          Dan Wing: the only thing preventing this from including DoT is the HTTP
          redirect that can be used on DoH (caught this right?)
          
          Ralf Weber: Maybe there is room to work on another protocol?
          
          Dan Wing: We could consider that.
          
          Wes Hardaker: You suffer with cached queries across resolvers. There
          are choices to make.
          
          Dan Wing: And also about prevent delays from short TTL.
          
          Wes Hardaker: Pre-fetching can lead to pre-fetching of entire Internet.
          
          **************************
          6. draft-reddy-add-server-policy-selection [Dan Wing]
          Dan Wing presented. Slides:
          https://datatracker.ietf.org/meeting/107/materials/slides-107-add-redd-add-server-policy-selection-wing
          
          Jim Reid: Would you expect it to be signed?
          
          Dan Wing: Do53 could be interfered with by someone on path so it presents
          wider attack vetors.
          
          John Todd: Push seems very complex. Is there some reason other
          possibilities were not considered, like TTL?
          
          Dan Wing: TTL seems like it might be a nivce way to solve.
          
          Allison Mankin: There is advice on creating privacy policy in draft
          in dprive.
          
          *******************************
          7. draft-mglt-add-rdp  [Daniel Migault]
          Daniel Migault presented. Slides:
          https://datatracker.ietf.org/meeting/107/materials/slides-107-add-dns-resolver-discovery-protocol
          
          Puneet Sood: This may tie in well with draft Dan and I wrote. Who is
          generating list of available resolvers? When the client is getting the
          response, where is the server with the list of resolver names?
          
          Daniel Migault: Companies will have to register to have their DN pointed
          there. That's on slide 8. I don't know who will take care of that. It
          could be IANA?
          
          Puneet Sood: 2nd question?
          
          Daniel Migault: Go to slide 9. Does that answer 2nd question? The person
          responsible for example.com...
          
          Puneet Sood: Who is responsible for server that is responding to
          client? Are you envisioning a new operator?
          
          Daniel Migault: I'm envisioning something shared by operators. Like IANA.
          
          David Lawrence: Take this off-line.
          
          Ben Schwartz (from jaber): https://public-dns.info/ has 11,000
          resolvers.  Do you propose to publish them 
          
          Daniel Migault: Yes.
          
          Harald Alvestrand: If you define business model where someone has
          monopoly on who gets to participate, you're asking for trouble. We
          shouldn't do that.
          
          Daniel Migault: I think this list will exist anyway. As long as the
          process is open I think it's solvable. I do understand the risk.
          
          Harald Alvestrand: You might want to look into complexities currently
          experienced with authorizing CAs.
          
          *************************************
          ADD Q&A  [Chairs et al]
          
          Glenn Deen: This is your opportunity to make a comment.
          
          Martin Thomson: I saw a lot of concentration on topic of discovery
          mechanisms without really understanding the principles and requirements
          driving. There were different approaches presented. Are we talking about
          networks providing info or something else?
          
          Paul Hoffman: One of the things that drove creation of this WG was
          question of how can I upgrade from unencrypted to encrypted DNS. It
          seems that would be easy to solve but I saw no proposals.
          
          Simon Hicks: We're looking at technical details; but when are we going
          to talk about the user experience (talk about all of this from the user
          perspective)? We seem to be lacking the ability to allow user choice.
          
          David Lawrence (hatless): This seems to me to be a pervasive consideration
          rather than something that needs to be brought up in each of the docs.
          
          Chris Box: I want to agree with Martin Thomson. We need to discuss
          principles and requirements first. But it is tricky.
          
          Jim Reid: Need to look at impact to enterprise networks of various
          solutions.
          
          Andrew Campling: Going back to point about user. Note that user might
          be enterprise administrator or parent. We need to make sure this isn't
          just about providing the client with options. The "user" who needs to
          be considered may not be the literal user of the client.
          
          **********************************************************************
                    Agenda & Minutes
          **********************************************************************
          Chairs: Glenn Deen and David Lawrence
          Notes: Barbara Stark (hopefully with help)
          Jabber Scribe: 
              
          Etherpad is at:
             
          https://etherpad.ietf.org:9009/p/notes-ietf-107-add?useMonospaceFont=true
              
          Webex is at: (220 on webex)
             
          https://ietf.webex.com/ietf/j.php?MTID=m342b913bf84bd74824d9dec9b153b872
              
          Jabber is: add@jabber.ietf.org  (104 people on jabber)
          
          Blue Sheets are at the bottom of this etherpad page
          
          ADD Agenda for IETF107 
          ======================
           
          1.         Introduction to ADD WG    [Chairs ]
          
          2.         Agenda Bash
          
          3. 15min   draft-arkko-abcd-distributed-resolver-selection  [Jari
          Arkko/Ted Hardie]
          
          4. 15min   discovery-selection directions  [Tommy Pauly]
          
          5. 20min   draft-btw-add-home  [Dan Wing]
          
          6. 10min   draft-reddy-add-server-policy-selection [Dan Wing]
          
          7. 15min   draft-mglt-add-rdp  [Daniel Migault]
          
          8. 15min   ADD Q&A  [Chairs et al]
          
          *********************************************************************
          Minutes
          *********************************************************************
          1&2. Introduction to ADD WG and Agenda Bash
          Main Agenda:
          https://datatracker.ietf.org/meeting/107/materials/slides-107-add-agenda
          
          Glenn Deen started the meeting. Note the instructions on the first slide.
          And note the Note Well.
          No bashing of the agenda on slide 4.
          Glenn provided ADD history, while displaying the really nice pictures
          of the chairs on slide 5.
          
          Barry Leiba: As AD, had no comments at this time.
          
          *********************************************************
          3. draft-arkko-abcd-distributed-resolver-selection  [Jari Arkko/Ted
          Hardie ]
          Ted Hardie presented. Slides:
          https://datatracker.ietf.org/meeting/107/materials/slides-107-add-dns-resolver-selection-arkko-hardie
          
          Tommy Pauly: Thank you for coming up with this. First, when you have
          ordering of common types, I would expect network resolver to be most
          common. It's important for local network interaction to view local
          network resolver as status quo. Otherwise, many assumptions will break,
          e.g., about provisioning domains, etc. Reducing concetration of info is
          useful, but need to consider privacy impacts not just in resolution but
          also in context of entire connection.
          
          Mohit Sethi: Question about interface selection. I assume by interfaces
          you mean wifi, eth, etc.? And then you use different resolver per
          interface? Some devices can only do one interface at a time. What are
          impacts if interface is not up? Do you allow use of a resolver discovered
          on an interface that is no longer up and running?
          
          Ted Hardie: If you have multiple ifaces, each with different resolver,
          it's ok to have name resolution associated to specific iface. Do
          mechanisms developed take this optimization into account?
          
          David Lawrence (chair): Will close mic line after Warren. 
          
          Pete Resnick: Suggestion -- it does seem VPN case is subsumed by multiple
          interface case because the VPN case is just multi iface where 1 iface is
          VPN. So no need to separate out. Question -- If WG answers yes to first
          question, what happens. Is this a WG doc? Is this just a use case doc?
          
          Ted Hardie: This isn't really a good place to discuss the draft. But
          various possible outcomes exist. It may also be that we decide we cannot
          achieve this optimization.
          
          Ben Schwartz: Yes, the WG should consider approaches that result in
          multiple resolvers being discovered. As for optimization question,
          that relies on WG to have increased understanding of where queries
          go. So maybe just say configs that alter the concentration and leave
          it to future users/implementers to decide what is optimal. As for 3rd
          question, we shouldn't guess at some of these.
          
          David Lawrence: 5 people left in queue. Please keep comments brief.
          
          Sanjay Mishra: WG should look at these issues. Did you (draft authors)
          have chance to see what impact different resolvers would have on
          performance.
          
          Ted Hardie: No.
          
          Sanjay Mishra: Would you consider looking at this?
          
          Ted Hardie: The WG will need to answer performance questions more broadly.
          
          Eric Rescorla (EKR): I think the best place for this draft would be as
          an analysis draft. Please don't say we should treat network resolvers
          as status quo.
          
          Ted Hardie: There are some cases where we cannot assume sets of resolvers
          are equivalent.
          
          EKR: I'm suggesting focusing on the 2nd of the cases you described.
          
          Chris Box: Using multiple resolvers imples multiple privacy policies. Some
          may be "better" than others. 
          
          Glenn Deen: Thank you.
          
          *************************************
          4. discovery-selection directions  [Tommy Pauly]
          Tommy Pauly presented. Slides:
          https://datatracker.ietf.org/meeting/107/materials/slides-107-add-adaptive-dns-paully
          
          EKR: Once you control DNS, ESNI is lost. But that isn't necessarily true
          here. Larger point is this seems to have some large failure cases. Take
          case of resolvers A and B where A gets 90% of traffic. In this case,
          temporary traffic shifts are hard to fix.
          
          Tommy Pauly: ESNI does require DNSSEC -- that's true. But just because
          we present this way doesn't mean DNSSEC isn't there.
          
          EKR: Every ISP will want to advertise itself as authoritative. My concern
          is that makes the traffic allocation at any point in time stable and
          hard to change.
          
          Tommy Pauly: I do want to get more input from the group on ths. I see
          2 deployment scenarios. There could be a DoH resolver in charge of
          splitting traffic between 2. Or there is no reason there cannot be 2
          designated load-balanced servers.
          
          Erik Nygren: Is it accurate that ...  ... and I'll put that in the
          jabber chat.
          
                           erik: To EKR's concern, one approach would be that the
                          .well-known/pvd would have its domain be the SvcDomainName
                          in the HTTPSSVC record.  For example with: 
                          "www.example.com 7200 IN CNAME foo.cdn1.example."  
                          and "foo.cdn1.example. 7200 HTTPSSVC 1 ."  then if
                          the policy is on "https://cdn1.example/.well-known/pvd"
                          it would apply for just that one CDN.  And since it is
                          the A/AAAA records for "foo.cdn1.example" which want to
                          have lower TTLs and the CDN-controlled mapping then this
                          addresses the issue.  
          
          Tommy Pauly: Thanks. I'll look at that.
          
          Andrew Campling: How do I as a user express my preferences? It looks
          like the machine is taking control. How can I say I only want certain
          resolvers?
          
          Tommy Pauly: Good question. That's something the WG needs to talk
          about. This here is just about discovery of resolvers. I think what you
          describe is follow-on discussion that's needed.
          
          Ralf Weber: There might be some situations where this provides more info
          about the client than the way things are now. The DoH or DoT server will
          get all client info. Maybe that's something you can improve on.
          
          Tommy Pauly: Good point. We need to take into account which resolver
          you're using. If we could limit so that for google.com I'm only talking
          to Google server, hopefully we can keep info from going elsewhere.
          
          Ralf Weber: There are other requirements, too. Not just top level,
          2nd level.
          
          Puneet Sood: This works well where connectivity and DNS are operated
          by same entity. For small ISPs, this may not be the case. In that case,
          there will not be a net improvement for the client.
          
          Ben Schwartz (from jabber): I understand how this scheme improves privacy
          when combined with Oblivious DNS, but in the absence of Oblivious DNS
          (which is out of scope for ADD) I think this is only a privacy improvement
          for certain assumptions about TTLs, and some queries will leak when TTLs
          expire.  I'd like to see those assumptions clarified, and see if there
          is a simpler solution, such as using long-lived CNAMEs.  I'd also want
          some consideration about whether these long TTLs are a tracking vector. 
          
          Tommy Pauly: Good comment and a discussion we should continue having.
          
          Warren Kumari: I don't know what a Google name is. There are 1000s
          of names. If I know a priori what maps then I don't need to ask a
          resolver. If I don't know, then I have to ask  a resolver. 
          
          Tommy Pauly: You can switch after you disover that something is a
          Google name.
          
          ******************************
          5. draft-btw-add-home  [Dan Wing]
          Dan Wing presented. Slides:
          https://datatracker.ietf.org/meeting/107/materials/slides-107-add-btw-add-home-wing
          
          Jim Reid: Question about verified resolvers. 
          
          Dan Wing: The intent is that if you're a subscriber to Comcast, you
          would say "I want Comcast-signed DoH servers" and then use them.
          
          Martin Thomson: I think it's sad there are lists at endpoints. CPE don't
          get upgraded in my experience. 
          
          Dan Wing: I'm familiar with and agree with that analysis.
          
          Ralf Weber: The CPE angle is one I've thought ablout. There are ISPs
          who manage their CPE, and those can be relied on to be up-to-date. Why
          DoH and not DoT between client and CPE?
          
          Dan Wing: the only thing preventing this from including DoT is the HTTP
          redirect that can be used on DoH (caught this right?)
          
          Ralf Weber: Maybe there is room to work on another protocol?
          
          Dan Wing: We could consider that.
          
          Wes Hardaker: You suffer with cached queries across resolvers. There
          are choices to make.
          
          Dan Wing: And also about prevent delays from short TTL.
          
          Wes Hardaker: Pre-fetching can lead to pre-fetching of entire Internet.
          
          **************************
          6. draft-reddy-add-server-policy-selection [Dan Wing]
          Dan Wing presented. Slides:
          https://datatracker.ietf.org/meeting/107/materials/slides-107-add-redd-add-server-policy-selection-wing
          
          Jim Reid: Would you expect it to be signed?
          
          Dan Wing: Do53 could be interfered with by someone on path so it presents
          wider attack vetors.
          
          John Todd: Push seems very complex. Is there some reason other
          possibilities were not considered, like TTL?
          
          Dan Wing: TTL seems like it might be a nivce way to solve.
          
          Allison Mankin: There is advice on creating privacy policy in draft
          in dprive.
          
          *******************************
          7. draft-mglt-add-rdp  [Daniel Migault]
          Daniel Migault presented. Slides:
          https://datatracker.ietf.org/meeting/107/materials/slides-107-add-dns-resolver-discovery-protocol
          
          Puneet Sood: This may tie in well with draft Dan and I wrote. Who is
          generating list of available resolvers? When the client is getting the
          response, where is the server with the list of resolver names?
          
          Daniel Migault: Companies will have to register to have their DN pointed
          there. That's on slide 8. I don't know who will take care of that. It
          could be IANA?
          
          Puneet Sood: 2nd question?
          
          Daniel Migault: Go to slide 9. Does that answer 2nd question? The person
          responsible for example.com...
          
          Puneet Sood: Who is responsible for server that is responding to
          client? Are you envisioning a new operator?
          
          Daniel Migault: I'm envisioning something shared by operators. Like IANA.
          
          David Lawrence: Take this off-line.
          
          Ben Schwartz (from jaber): https://public-dns.info/ has 11,000
          resolvers.  Do you propose to publish them 
          
          Daniel Migault: Yes.
          
          Harald Alvestrand: If you define business model where someone has
          monopoly on who gets to participate, you're asking for trouble. We
          shouldn't do that.
          
          Daniel Migault: I think this list will exist anyway. As long as the
          process is open I think it's solvable. I do understand the risk.
          
          Harald Alvestrand: You might want to look into complexities currently
          experienced with authorizing CAs.
          
          *************************************
          ADD Q&A  [Chairs et al]
          
          Glenn Deen: This is your opportunity to make a comment.
          
          Martin Thomson: I saw a lot of concentration on topic of discovery
          mechanisms without really understanding the principles and requirements
          driving. There were different approaches presented. Are we talking about
          networks providing info or something else?
          
          Paul Hoffman: One of the things that drove creation of this WG was
          question of how can I upgrade from unencrypted to encrypted DNS. It
          seems that would be easy to solve but I saw no proposals.
          
          Simon Hicks: We're looking at technical details; but when are we going
          to talk about the user experience (talk about all of this from the user
          perspective)? We seem to be lacking the ability to allow user choice.
          
          David Lawrence (hatless): This seems to me to be a pervasive consideration
          rather than something that needs to be brought up in each of the docs.
          
          Chris Box: I want to agree with Martin Thomson. We need to discuss
          principles and requirements first. But it is tricky.
          
          Jim Reid: Need to look at impact to enterprise networks of various
          solutions.
          
          Andrew Campling: Going back to point about user. Note that user might
          be enterprise administrator or parent. We need to make sure this isn't
          just about providing the client with options. The "user" who needs to
          be considered may not be the literal user of the client.
          
          



Generated from PyHt script /wg/add/minutes.pyht Latest update: 24 Oct 2012 16:51 GMT -