DNS-SD Extensions
charter-ietf-dnssdext-00-05

[Ballot comment]
That's a lot of words!

Not a required change, but...
I think that the two paragraphs before the subheading "Working Group Description" belong after the subheading. I would also be inclined to reverse their order.

[Ballot comment]

I'm not blocking but I think it'd be good if the charter made some
mention of security and privacy, in order to head off potential
discusses on documents later. Doesn't need much, but maybe
something like:

"Extending discovery beyond current cases can expose discovered
devices/services in ways that can be problematic for security or
privacy. The WG will consider such issues and attempt to define
appropriate mitigations."

[Ballot comment]
That's a lot of words!

I think that the two paragraphs before the subheading "Working Group Description" belong after the subheading. I would also be inclined to reverse their order.

[Ballot comment]
The deliverables are correctly covered in the "proposed milestones" section. They should not appear in the charter text, unless there is a very good reason.

[Ballot comment]
I continue to believe that the Deliverables section is unnecessary; the Goals section gives plenty of specifics. I just worry about people saying stupid things like, "The charter says 3 documents, so splitting one of the documents in two is out-of-charter" or "The charter says Informational, but really this is more like an applicability statement or a BCP and therefore we need to re-charter". I say leave the specific deliverables up to the WG and let the Goals put the appropriate limits.

[Ballot comment]
Thank you for addressing my BLOCK question about scoping service discovery. I think getting that work right will be important, but it's appropriate for the working group to flesh out the details (rather than holding up chartering while we chat about it).

I trust that Ted and the proposed chairs will add appropriate text about scoping service discovery to the charter if they think doing so would be helpful.

I agree with every single AD comment so far (Brian, Barry, Pete and Ted). I think I come down closest to where Pete comes down on remote service discovery (which I might paraphrase as "don't hold the working group to providing remote service discovery, but don't make them design local service discovery with their eyes closed, either").

[Ballot block]
Apologies in advance, but I have to ask about this:

Bonjour is an Apple registered trademark:
https://www.apple.com/legal/intellectual-property/trademark/appletmlist.html
Their licensing rules say "Use of the Bonjour name or logo requires a separate license from Apple":
https://developer.apple.com/softwarelicensing/agreements/bonjour.html

For RFC 6762 & 6763, there were two authors both from Apple so you could say they're using their own trademark so no need for a declaration.

This charter is different thought (isn't it) in that it's not authored by just by Apple employees.  Do we need a declaration from Apple that it's okay for the IETF to use "Bonjour" in the charter?

[Ballot comment]
When reading the charter, I took the following notes:
What are the services that DNSSDEXT will NOT be discovering: single link, multiple links/multiple subnets, remote service discovery, neighbouring or non-neighbouring links, etc...?
Basically, it's everything: my home, my neighbors' homes, my street, my city, my company within my VPN, ... Where do we stop?
Trying to picture this work within the homenet WG, dnssdext would do an excellent job if it would provide the means to discover services within the borders (term used in the homenet architecture doc).

Now, reading the ballot, my comment fits exactly Brian's BLOCK, and Joel's ABSTAIN (I guess)

Regards, Benoit, really hesitating between a COMMENT and a BLOCK. I want to hear the discussion first

[Ballot comment]

I support doing this, but have a comment on Spencer's comment.
If geopriv concepts are used by the wg, (which might well be a
fine idea), then I hope that is done with the goal of appropriately
protecting privacy for the node doing discovery. One could argue
that the protocols adopted by geopriv make the default assumption
that targets are ok with their identity and location being known to
parts of the network, which is perhaps not appropriate here.

[Ballot comment]
>>  not necessarily on directly connected links, e.g., on links elsewhere on the same site, or links at a remote site.

our history with local/site/enterprise/interdomain/internet scoping is ambivalent.

would greatly like to see this rule far flung activities out of scope. a single adminstrative domain or span of network control or what have you would be tollerable.

[Ballot block]
This would be a Discuss, if we Discussed charters. I think this work is important and plan to ballot as "yes" after chatting about one point ...

I don't have a good feeling about the proposal for scoped service discovery, especially since "site" is given as one of the possible scopes. When http://www.ietf.org/rfc/rfc3879.txt formally deprecated site-local addresses,one of the justifications given was Section 2.5 of that RFC, "Site is an Ill-Defined Concept", which makes for entertaining reading. I'm not sure why the problems described wouldn't apply to service discovery with a "site" scope today.

I would encourage people working on scoped service discovery to think about what GeoPriv civic location elements already defined in places like http://tools.ietf.org/html/rfc4119#section-2.2.1 might make sense as service discovery scopes ("floor" is defined, for example).

Is such a list of scopes something that should be included in this charter? Or something the working group should figure out after it's chartered?

[Ballot block]
This would be a Discuss, if we Discussed charters. I think this work is important and plan to ballot as "yes" after chatting about one point ...

I don't have a good feeling about the proposal for scoped service discovery, especially since "site" is given as one of the possible scopes. When http://www.ietf.org/rfc/rfc3879.txt formally deprecated site-local addresses,one of the justifications given was Section 2.5 of that RFC, "Site is an Ill-Defined Concept", which makes for entertaining reading.

I would encourage people working on scoped service discovery to think about what GeoPriv civic location elements already defined in places like http://tools.ietf.org/html/rfc4119#section-2.2.1 might make sense as service discovery scopes ("floor" is defined, for example).

Is such a list of scopes something that should be included in this charter? Or something the working group should figure out after it's chartered?

[Ballot comment]
I agree with every single AD comment so far (Brian, Barry, Pete and Ted). I think I come down closest to where Pete comes down on remote service discovery (which I might paraphrase as "don't hold the working group to providing remote service discovery, but don't make them design local service discovery with their eyes closed, either").

[Ballot comment]
I understand Brian and Barry's concerns, but I would hate for the WG not to consider the implications of remote discovery during the design phase: Certain choices may preclude adding on remote discovery. Perhaps it would suffice to simply make it clear that this can be considered, but may be tossed overboard and is not a requirement.

Goal 3: Change "To publish an Informational RFC that documents" to simply "To document" and "which should include" to "including". I don't think we should care whether this is a separate document, part of an applicability statement section of the protocol document, or something else entirely.

I also don't think the Deliverables need to be spelled out so specifically. The goals section is sufficient. I would strike the Deliverables section entirely.

Typos:

  Any solution developed by the dnssdext WG wil not conflict...

"will"

  (D) Mesh networks

"(E)"

[Ballot comment]
I had a similar thought to Brian's, and I support his blocking comment.

I also found the extensive background and exposition to be a bit longer-winded than is probably necessary, and I ask that you consider some significant editing and trimming.  That said, it's organized well enough that it's understandable, so this is a non-blocking comment.  If such editing doesn't happen, I won't raise any further objection.

[Ballot block]
Having sat through both BoFs on this subject, I am a little surprised by the inclusion of "remote service discovery" in the proposed charter.  That topic received little/no discussion during the BoFs and it is such an advanced subject, that I fear it may distract the WG from its core focus.  This is especially true when you consider the security/privacy ramifications of that level of service for a zero-config network.  I would propose that remote service discovery be taken out and be a potential subject for a re-chartering effort once the core deliverables are completed.