DNS-SD Extensions
charter-ietf-dnssd-01-03

This is timely and important.
I hope that the issues raised by other ADs can be resolved quickly so that work proceeds.

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.

The supplied -03 version of the charter addresses my concerns adequately.  Thank you.

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)"

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").

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.