----------------------------------- IETF87 dnssdext BoF meeting minutes ----------------------------------- Wed 31st July 2013 9:00 - 11:00am CEST Room: Potsdam 3 Chairs: Tim Chown, Ralph Droms Original minutes taker: Shwetha Bhandari Jabber relay: Don York The dnssdext BoF began with review of the IETF "Note Well" and agenda bashing. The chairs thanked Shwetha and Don for volunteering to take minutes and relay Jabber comments. Tim Chown reviewed the mdnsext background. The mdnsext BoF at IETF 85 considered forming a WG with a similar charter, so this is the second BOF and the last chance to form a WG. Tim listed drafts, mailing lists, stats: http://www.ietf.org/proceedings/87/slides/slides-87-dnssdext-2.pptx Ralph Droms reminded the attendees of RFC 5434 on how to hold a successful BoF and thus the questions to be answered by this BoF. Stuart Cheshire gave a presentation about dnssdext requirements: http://www.ietf.org/proceedings/87/slides/slides-87-dnssdext-3.pptx and http://tools.ietf.org/html/draft-lynn-mdnsext-requirements-02 There was significant discussion of the requirements draft document. * Dan York - Windows 2008 server problem with recursive DNS server - is this fixed in a later version? And: don't know * Eliot Lear - clarification about REQ2 and use cases B - one forwarding device that has multiple subnets, C - multiple forwarding devices, not sure what is explained here matches the text of the draft * Ted Lemon - regarding REQ2 in use case C, s/tree/arbitrary mesh/; Tim Chown - perhaps "arbitrary topology" * Harald Albrecht asked for further description of REQ2 in relation to use cases A, B, C; how local is local? Stuart : explains distinction between A, B, C versus enterprise/campus network * Don York relaying for Kerry Lynn - case C is to cover homenet, as I recall, so intentionally general for all requirements * Ray Bellis - homenet case C as tree is restrictive, arbitrary mesh better description is a better description of REQ2 * Toerless Eckert - C should be restricted on size rather than on topology for REQ2, number of devices better gating factor * Tim Chown - administrative setting of the network for REQ2: administered versus home without dedicated administrator is another distinction * Toerless Eckert - changing the name of the BoF has implications on solution/protocol/zeroconf goal * Kerry Lynn - +1 on controlled flooding in some situations * Stuart Cheshire - REQ2 is strong for A, B, C not ruled out for other networks * John Brzozowski - text for REQ2 describing A, B, C to serve variety of topology required * Dan York relaying for Michael Richardson - the Starbucks is a variation of network B, and it needs to be in scope, because it's a case of a network with hostile peers. the point isn't that Starbucks hasn't got an IT guy.  The point is that their IT guy didn't get to configure my laptop, and I still want to find your laptop while there, and I want my tablet to find my laptop. * Stuart - naming on slide was not normative, just an example * John Jason Brzozowski - will the text allow for a range of topologies? * Peter Koch - REQ3 in relation to D & E unclear, not able to grasp; administrative domain is not clear * Stuart Cheshire - clarifying question: REQ3 shouldn't be in the draft because it is difficult to solve? * Peter Koch - there is ambiguity in underlying definition of administrative domain for REQ3 * Erik Kline - regarding REQ3, should we support one discovery scope or multiple scopes? - e.g department vs. campus wide; Stuart Cheshire responded there should be multiple scopes * Russ Mundy - regarding multiple administrative domains, what is the distinction between use cases D & E; Stuart Cheshire - I don't distinguish between D and E myself - we wanted to make it clear in the document that both cases were being covered * (unknown) What is the degree of certainty that is desired for correctness in the requirements? What are the security requirements and implications, e.g. location of the service; Stuart - printing on the wrong printer at home may not be a big deal, but it may be at a university * Ralph Droms - there are different kinds of administrative domains * Toerless Eckert - requirements are weak, scoping needs to be better, specify the scope of service better - other than TTL or type of link, scope should be part of the service announcement rather than determine the scope magically e.g. by the operator; Stuart Cheshire: scope is used in the broader sense - narrow what is the range of the discovery; e.g. a building, a room * Yi Yang - thinks scope in REQ3 could be a policy thing. Should support change of scope; discover scope vs. announcement case * Mathew Gast - regarding REQ3, categories A, B, C, D, E are confusing with complexity of IT org administrative domain. Auto scope determination should be called out explicitly * Dave Thaler - REQ3 should be split into separate requirements * Erik Kline - is the requirement to be two or arbitrary levels of scope e.g. department, building ,campus; Ralph Droms- not just levels but different kinds of scope: topological correlation or arbitrary * (unknown) There are different entities to be configurable for defining scope - 1. network administrator defines the scope, 2. entity that wants to be discovered defines the scope 3. entity discovering the service defines the scope * Peter Koch - what is the administrative domain perspective of scope user centric (highly mobile), service delivery scope (e.g. printer serving customer base) e.g. on the IETF network here can you discover the printer in the hotel business center? * Amine Chokur - advocates scope for announcement of service for REQ3 * Dan York relaying for Andrew Yourtchenko - in REQ3, scope can be location matrix value, geo, civic location.. * no comments on REQ4 * Dave Thaler - REQ5 should ensure that new protocols don't break any other protocols and other service discovery protocols, be generic."we don't want to break ANY link scope protocols" * Eliot Lear - uncomfortable with requirement REQ5 * Toerless Eckert - does REQ5 mean extending/changing existing protocol e.g. mDNS would inherently break what it is currently doing? Is it safe way to meet this requirement to invent a new protocol to do this? * Don York relaying for Kerry Lynn - Apple IPR applies to hybrid proxy not to the requirement draft * Stuart Cheshire- Apple's IPR disclosure was a mistake - Apple IPR meant for hybrid proxy not requirement draft * Richard Kelsey - 6lowpan requirement not clarified - will it be covered? * Ralph Droms presented a summary of the requirements discussion - There is general agreement with the requirements in draft-lynn-mdnsext-requirements-02 - Case C will be generalised to apply to networks with an "arbitrary topology" - Additional discussion of "scoping" is required * Eliot Lear - REQ5 if breaking means de-duplication of existing protocols mDNS/DNS-SD Tim Chown / Ralph Droms gave a draft charter presentation from the "Chair's slides" deck - slide 10 onwards leading into a discussion of the draft charter * Toerless Eckert - anything designed for use cases A, B, C environment shouldn't break when those devices are introduced into a larger network environment; e.g. via BYOD home devices bought into an enterprise network should have no surprises. This has to be part of the requirement * Peter koch - clarifying questions: 3rd bullet slide 11 - regarding scoping work (ZigBee work), is there a reference to some other work/document? Is the bullet 3 requirement for standards under development? Answer: No, SEP 2.0 is done * Andrew Sullivan - Bullet 3 opens up all types of networks such as wireless multilink mesh subnets; the use cases should nail down the specific problem to be solved * Erik Nordmark - in the scope discussion, multicast transport scope and service scope aren't the same and should not be confused * Toerless Eckert - the scope should not be tied to network topology or transport topology * Tim Chown - text to be refined to capture comments from Nordmark and Eckert * Dave Thaler - Slide 12 - goals - (1,2) are fine, (3) is not scoped appropriately and does not match problem statement. Goes back to mdnsext BoF that had consensus on service discovery requirement but not on name resolution requirements. Name resolution requirements should be out of scope of this BoF. * Don York relaying from Jabber for Kerry Lynn - at slide 12 I have an additional goal to propose: 4. To consider extensions to DNS-SD that improve its suitability for M2M and/or Aggregated Services Discovery. * Peter Koch - goal 3 has been referred to as the pony requirement - reference to BCP shouldn't be made namespace related as that goes into a rathole * Eliot Lear - goal 2 doesn't refer to wide area service discovery; rather multilink to home to wide area. * Andre - Slide 11 refers to a traditional routed network; should be unicast DNS not breaking but integrating existing protocols * Stuart Cheshire - 2 possibilities: 1. build on mDNS/DNS-SD or 2. start with a clean slate; my understanding was this BoF was going with (1). We need to be clear about this in the BoF goals * Andrew Sullivan - realistic goal is to build on existing protocols/interfaces. But goal 3 slide 12 co-existence of existing without breaking raises serious concerns - modify current charter to address this. * Eliot Lear - tradeoffs of building new versus re-using existing needs to be included in the goals/requirements * Toerless Eckert - increases adoption if incremental, i.e build on existing protools, but this may lead to issues * Better words to express Slide 13 (3) to be developed * Bernie Hoeneisen- the final requirement was vague (don't break anything). BCP milestone is not right way to do, should be part of architecture. * (unknown) how would deliverables (2) and (3) relate to each other? How will (2) and (3) integrate - architecture work required. * Dave Thaler - I am in favour of attempting more tightly scoped things, specifically goals and deliverables. Suggest not to attempt DNS namespace requirement/goal; rather, write an informational RFC that documents challenges and problems when developing SD solutions * Toerless Eckert - should include service announcement and discovery. deliverable (2) should document/define interfaces that can then be implemented and verified, separately to transport of the information. * Brian Dickson - split architecture , solution and revisit architecture when challenges and solutions to those are found * Ray Bellis - homenet requirement to be tied to this * Don York relaying for Kerry Lynn - reiterate the comments on mailer The chairs then took the views of the room for WG formation questions * Useful problem to solve? Loud hum in favour, no hums heard against * Is the problem well scoped? Hum was in favour, with some against - Chairs stated problem statement to be clarified to emphasise service discovery not name resolution - after wordsmithing from comments received today * Understanding of the requirements - maturity sufficient to form a WG? Hum was in favour with only one hum against * Do we think we can we solve the problem? Hum in favour, with one against * Are the goals/deliverable appropriate? Hum was in favour * Dave Thaler - scope management and discovery should be mentioned in the charter along with service discovery * The chairs asked in the charter was missing anything. Comments on scope discovery and service discovery focus were noted. The chairs then asked for people willing to: * Work on requirements - 10 * Work on solution - 12 * Work on Informational document of namespace problems/issues arising - 3 or 4 hands went up * Review documents - many hands, over 20 The chairs asked a final question: * Based on the commitment, do we want to move forward towards a WG? Hum in favour, with no hums against. The chairs closed the meeting at 11:00am, thanking all attendees, and stating that they would take the matter of forming a WG to the appropriate channels.