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

Dnssd Status Pages

Extensions for Scalable DNS Service Discovery (Active WG)
Int Area: Suresh Krishnan, Terry Manderson | 2013-Oct-25 —  
Chairs
 
 


IETF-102 dnssd minutes

Session 2018-07-19 0930-1200: Duluth - Audio stream - dnssd chatroom

Minutes

minutes-102-dnssd-00 minutes



          DNSSD Minutes
          
          IETF 102, Montreal, Canada
          Thursday, July 19, 2018
          9:30-12:00 Local Time (EDT)
          Duluth Room
          
          Chairs: David Schinazi, Tim Chown (absent)
              Tim Wicinski (temporarily standing in for Tim Chown)
          Minutes: Barbara Stark
          Jabber: Tim Wattenberg
          
          --------------------------------------------------
          Agenda
          --------------------------------------------------
          Introduction -- Chairs -- 5 mins
          
          Discovery Proxy -- Stuart Cheshire -- 15 mins
                 draft-ietf-dnsop-session-signal (DNS Stateful Operations)
                         Awaiting shepherd writeup and IESG decision
                 draft-ietf-dnssd-push (DNS Push)
                         Currently held by working group, discuss next steps
                 draft-ietf-dnssd-hybrid (Discovery Proxy)
                         Approved by IESG, waiting for DNS Stateful Operations
                         and DNS Push
          
          Discovery Relay -- Ted Lemon -- 15 mins
                 draft-ietf-dnssd-mdns-relay
                         Working group document, discuss starting working group
                         last call
          
          Service Registration -- Ted Lemon -- 15 mins
                 draft-sctl-service-registration
                         Individual draft, discuss adoption
          
          CoRE Resource Directory DNSSD Mapping -- Kerry Lynn -- 15 mins
                 draft-ietf-core-rd-dns-sd
                         CoRE working group document, asking for input from DNSSD
          
          Privacy -- Stuart Cheshire -- 50 mins
                 Discuss adoption and aim to reach consensus on way forward
                 draft-ietf-dnssd-privacy (Privacy Extensions)
                 draft-huitema-dnssd-prireq (Privacy and Security Requirements)
                 draft-huitema-dnssd-privacyscaling (Privacy Scaling Tradeoffs)
                 draft-ietf-dnssd-pairing (Short Authentication Strings)
                 draft-ietf-dnssd-pairing-info (Pairing Design Issues)
          
          Rechartering -- Chairs & Tom Pusateri-- 30 mins
          
          Conclusion -- Chairs -- 5 mins
          
          --------------------------------------------------
          Minutes
          --------------------------------------------------
          9:30
          Chair Slides
          <https://datatracker.ietf.org/meeting/102/materials/slides-102-dnssd-chairs-introduction-01>
          David Schinazi presented.
          Thanks to Tim Chown, who is stepping down as chair.
          Applause for Tim Chown from room.
          Contact Terry Manderson if you would like to be considered for the open
          co-chair position.
          
          Hackathon update
          Ted Lemon: It was very useful. Good discussion. Running code.
          Tim Wattenberg: It was good.
          
          --------------------------------------------------
          9:37
          DNSSD Document Status Update
          <https://datatracker.ietf.org/meeting/102/materials/slides-102-dnssd-discovery-proxy-00>
          Stuart Cheshire presented.
          
          dnssd-push which is currently held,
          will probably need some edits after IETF LC of Stateful Operations
          
          Terry Manderson: I approved earlier today.
          Tom Pusateri: I intend to re-read.
          Stuart: Yes, I intend to do that to.
          
          --------------------------------------------------
          9:41
          DNS Discovery Relay
          <https://datatracker.ietf.org/meeting/102/materials/slides-102-dnssd-discovery-relay-00>
          Ted Lemon presented
          
          slide 5
          Ted: May remove Discovery Proxy from document.
          Stuart: Discovery Proxy was in the draft as optional.
          
          Ted: It would be really great to have a second implementation.
              If you want to do interop with me, let me know.
          Tim Wicinski: It's in WGLC and there have been no comments. Read it
          and comment.
          David: Who has read? <some hands were raised>
              Please provide comments or explicitly say you have no comments.
          Tim Wicinski will shepherd
          
          --------------------------------------------------
          9:51
          Service Registration Ted Lemon  draft-sctl-service-registration
          <https://datatracker.ietf.org/doc/draft-sctl-service-registration/>
          <https://datatracker.ietf.org/meeting/102/materials/slides-102-dnssd-service-registration-01>
          
          David: We will reach out to DNSOP list and get review.
          Kerry Lynn: Discussion in CORE group about how a device can assert
          veracity of its claim
              that it owns a service. Are any people in this group investigating
              this question?
          Ted: You are talking about enrollment process. I agree that may be
          a problem.
              But I think we may be ok here (in this doc). But I would like to
              work with you on that.
              I think it applies to homenet, too. Anima also has an enrollment
              process.
              I don't want to see many, many enrollment processes.
          Andrew Sullivan: I agree. I don't think that belongs in this document.
          
          Stuart: With normal DNS Update, the assumption is that if you have the
          key you are
              trusted to make the update.
              What we want to do here is let any device with credentials make
              the update.
              But we also want to make sure it cannot be stolen.
              We need for Update to be the current DNS Update command (semantics).
              But we need to specify the sanity checking that gets done.
          Ted: We don't have Update constraints in this doc. We're trying to keep
          this down to
              single Update. So we're putting additional requirements on the server.
          
          slide 7
          Tom Pusateri: You may have to do A/AAAA Registration over TCP and not UDP.
          Ted: Yes. This is something we need to decide what we want to do.
          Mark Andrews: It doesn't matter.
          Ted: We don't have proof of connection.
              This can potentially be used by device on local network to get access
              to device
              not on local network. I don't think we're ready to say it's not
              a problem.
          Mark: Disagree.
          Stuart: I think I agree with Mark. I think packing everything in one
          Update is useful
              to constrained device. But we need to consider downsides of possible
              attack.
          Ted: I'm not ready to say we don't care. We need to think about it more.
          David S: <not as chair> I think I agree with Ted.
          Ted: I don't think we actually have a problem with constrained devices.
          
          slide 12
          Tom: When name is already taken there's no indication for what to
          try next.
              Not just problem here, but problem in general.
          Ted: Stuart and I talked about this and don't know of cases where this
          happens in the wild.
              We've seen it happen when we're doing strange things and a device
              with multiple
              network connections ends up competing with itself.
              There needs to be a user interface where you can configure this stuff.
              We need to figure out if name change is something stored in the
              service.
          Dave Robin: It's not hard to make unambiguous. Use MAC address.
              You are right that there is no delete function and you rely on
              garbage collection.
              But I think there does need to be a delete key here.
              I also want to talk about issue of replacing.
              I want to power down and have it say "delete me" during its dying
              breath.
          Ted: I don't think dying breath is realistic.
          Dave R: I'm in commercial space where we have a special ability to
          do this.
          Ted: You could go into UI and reclaim there. I'm not saying you're wrong,
              but I think you also want the UI.
          Stuart: We should make note of 3 things. (1) You're right about delete
          function need.
              (2) DNS server may not be the same one run on your corporate site.
              (3) The draft needs to talk about the UI.
          Mark: This is a problem that has already been solved.
          Kerry: Human in the loop is needed to set up security association.
              If printer is already on the link using mDNS,
              hasn't it already claimed the name and able to defend it?
          Ted: I don't think that's the same.
          Kerry: Is the device that is doing the registration also participating
          in mDNS?
          Ted: It's a good question. Stuart, I think you've said you think it's
          a good
              idea to also be doing mDNS?
          Stuart: I think you (Ted) have some use cases where there will not
          be mDNS.
          * Delete: yes
          
          last slide:
          Ted: I'd like to adopt.
          Tom: I think what is here is good, but I think RFC 6367 already has some
          of this and the
              name of this doc is confusing. If we changed name of this doc,
              I could support.
              Because this is not a new protocol.
          Ted: Are you aware of cases where it is being used for service
          registration?
          Tom: No. But 6367 says we don't need to define service registration
          because we
              have DNS Update. Will take this to email.
          Tim Wicinski:  Address any Underscore naming attributes (if needed)
          Mark: I think you want to do some things.
          David: Adoption call goes through next week. If you do or don't support
          adoption, say so.
              Currently leaning towards adoption.
          
          -------------------------------------------------------------
          10:37
          CoRE Discovery Mapping
          <https://datatracker.ietf.org/meeting/102/materials/slides-102-dnssd-core-discovery-mapping-00>
          Kerry Lynn presented.
          
          Dave Thaler: Issue we talked about in CORE is about coming up with the
          oic.r label.
              This issue needs to be discussed. Is there any value in having per
              organization "dot"
              or just per resource "dot"? Don't have to worry about how to map?
          Kerry: I'll take you points one at a time. RFC 5690 was first output of
          CORE WG.
              That allows any rt as value and was done before there was any
              operational experience with
              CoAP. Maybe now is time to tighten up values of metadata. In general
              case, perhaps it is
              up to anyone who wishes to export to decide how translation is done.
              I think that is your point -- why break this up instead of seeing
              it as flat.
          Dave T: I don't think that has correlation with rt.
          Kerry: Trying to find semantic alignment with CORE and DNSSD.
              But there doesn't have to be direct or one to one translation.
          Barbara Stark: Broadband forum has uses for these records, we need to
          make sure CoRE
              does not impact that. We need to separate this from other uses
          Kerry: there is a heuristic
          Barbara: Just make sure we do not need to change existing devices -
          we have our rt and
              should not need to use this heuristic
          Tim Wicinski (as DNSOP co-chair): We have doc in WGLC that built entire
          IANA registry.
              As these docs come up, people need to pay attention.
              draft is <https://datatracker.ietf.org/doc/draft-ietf-dnsop-attrleaf/>
              draft which fixes existing is
              <https://datatracker.ietf.org/doc/draft-ietf-dnsop-attrleaf-fix/>
          David S: Kerry's draft is a Core WG doc, CORE chairs and DNSOP chairs
          need to talk.
          Carsten Bormann: We want to provide both registered services can exist
          and things are useful
              for people who just want to build things. Maybe not everything
              registered on CORE needs
              to be registered on DNS-SD.
          Dave R: I have problem with using rt for service. Don't you want to
          export concept of
              thermostat, and isn't that more "if" than "rt"? Just register "if"
              and be done with it.
          David S <chair>: Please discuss this on mailing lists: cross-post core
          and dnssd
          Dave T: Don't relate "rt" with protocol.
              As long as you can put something in txt record you can get everything
              in one record.
          Kerry: Service types was not intended to be human readable.
          Stuart: Right. Dave said earlier that rt has nothing to do with service
          type.
              Mapping these may not be the right thing. rt is data model.
          Kerry: We will take this to the list.
          
          ---------------------------------------------------------------
          11:05
          DNSSD Privacy
          <https://datatracker.ietf.org/meeting/102/materials/slides-102-dnssd-dnssd-privacy-00>
          Stuart Cheshire presented on behalf of Christian Huitema
          
          Mohit Sethi: What do you mean by shared public key?
          Stuart: The intention is the device has key pair and it has shared its
              public key with devices around it.
          Mohit: So later, I will still know who is talking to these devices.
          Stuart: That's why "volunteers?" on the slide has a question mark.
              We have not explored all possibilities.
          Chris Wood: Trying to understand what you (Mohit) are asking.
          Mohit: Maybe I am misunderstanding.
          Stuart: I think Chris is saying there are mechanisms that don't reveal
          what
              key you are using.
          Chris: Yes. Another comment -- with Christian we are looking at some of
          the messaging
              in the shared key space. People interested in collaborating should
              let us know.
          David S <chair>: We're interested in opinions on this and on requirements.
          Dave R: This is reasonable. I assume we want observers not to know who
          is talking to whom.
              But people will know who has MAC address. They may not know contents
              of discussion,
              but they will always be able to figure out who the communicating
              parties are.
          David S <chair>: My understanding is that privacy is about fixing
          many holes.
              But we should not say we should not fix some holes just because we
              cannot fix all.
          Dave R: Not my point. I support this doc.
              I was just pointing out it does not support all aspects of privacy.
              It prevents additional PII from being leaked. Need to be clear
              on goals.
          Stuart: I think we could change some word to clarify things.
          Sara Dickinson: We've got new proposed research group on privacy
          enhancements
              (Privacy Enhancement Research Group -- PEARG).
              <https://trac.ietf.org/trac/irtf/wiki/pearg>
              Should use RFC6973 (Privacy Considerations for Internet Protocols)
              as resource.
              It has good definitions, so people can start using common terminology
              and language.
              It also occurs to me this is a really a more generalized problem.
          
          Chris: Are there expectations that solution must cover all 3 scenarios?
          David <chair>: We need to see what's possible.
              It would be nice if we could have 1 solution fits all.
          Chris: One size fits all may not be possible.
              I think everything but last 2 (on slide 8) are difficult.
          Dave T: I think hardest (slide 8) is resistance to DoS attacks.
          Chris: Will talk about ways to optimize off-line.
          David: Chris, can you send paper you mentioned to list.
          Andrew Sullivan: Threat amplification should not be possible.
          Chris: You were thinking you want to scope the solution to not revealing
          new PII.
              Does that mean solutions that solve more than this are not in scope?
          David <chair>: More could be in scope. We need to clarify our scope more.
          David <chair>: Who has read at least one version of these drafts
          (slide 2)?
              <some hands raised> Who has read all? <most hands went down>
          
          ---------------------------------------------------------------
          11:38
          Using Github
          David Schinazi presented from the Chair slides
          
          David: Should we start using github?
          Tim Wicinski: DNSOP co-chair. We are using github for some docs.
              But not for full WG engagement; more that authors are using.
          Stuart: I see no reason not to.
          Ted: I agree with Stuart.
          Stuart/Tim/Ted: There is difference between individual draft and WG draft.
              But even for individual draft, no intention to keep it private.
          David: This wouldn't be requirement from chairs.
              We would set it up and offer it to authors.
              We'll pick a draft and see how it works.
          Stuart: Is there anyone who believes this isn't what we should
          do? <silence>
          
          --------------------------------------------------------------
          11:43
          Rechartering
          <https://datatracker.ietf.org/meeting/102/materials/slides-102-dnssd-recharter-01>
          David Schinazi presented the final slides from the Chair slides that
          describe the charter.
          Tom Pusateri presented Rechartering slides
          
          Tim Wicinski: My employer has lots of apps. I love a lot of these
          ideas. I'm all for this.
          Kerry: I remember when this group was first chartered.
              There were things in initial charter proposal for making things work
              over mesh or
              multi-link network. I want to make sure we capture homenet
              requirements this
              time and that they are part of charter.
          Dave T: I want to talk more about "finding things near me" and
              "finding things associated with me".
          Phillip Hallam-Baker: You have listed different methods of discovery.
              We need abstract definition of what discovery is.
          David: Please bring your proposal to list.
          Terry Manderson: Want to set aside more time than what we have today
          to discuss.
              Note we still have existing charter items to complete.
          
          David: Who volunteers to help draft the re-charter?
          Volunteers who raised hands: Kerry Lynn, Ted Lemon, Tom Pusateri,
          Tim Wicinski
          
          -------------------------------------------------------------
          11:59
          Wrap-up
          David Schinazi read out action items he recorded:
          1) DNS Stateful Ops will go through IESG telechat early August, then
              authors will update DNS Push and we can move forward.
          2) mDNS Relay
              we would like more review from WG
          3) service registration
              WG adoption imminent
          4) Potential new draft for EDNS0 lease
              authors should bring the draft to the WG list
          5) CoRE
              lively conversation on mapping
              participants should continue conversation, cross-posted on dnssd
              and core lists
          6) Privacy
              Need to clarify scope of DNSSD privacy
              We'll look into RFC6973
              Get early review and input from PEARG
              Chairs should make it easier to discover which privacy draft to
              read first
          7) Github
              Support from working group for experimentation
              Chairs will experiment with one draft
          8) Recharter
              Kerry, Ted, Tom, Tim Wi to provide new text on mailing list
          
          



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