Hi, I think this draft raises an important topic. In the early days of ANIMA we had quite some discussion about embedding discovery in GRASP rather than simply using DNS-SD. I think we took the right decision, since GRASP objectives are a very flexible concept, only one application being a mapping to a traditional 'service'. But this left open the question of how to link the ANI tools to traditional services when necessary. I think this a necessary next step for ANIMA.
I think the general direction is reasonable, but I don't understand DNS-SD enough to be sure if it all works. From a first reading, I have a few questions and comments: > 2.2. Objective Value Reuseable Elements Structure > > Because service discovery, as explained in the prior section, needs > to utilize different objectives, it requires cross-objective > standardized encoding of the elements of services. GRASP did not > define standardized message elements for the message body (called > "objective-value") of GRASP messages. I'd like to insert "intentionally" before "did not define". This was left open so that we can have effectively infinite extensibility of the syntax and semantics of GRASP. Therefore, considering the next sentence: > Therefore, this document introduces such a feature. I'd like it to be clear that it is intended for SRV.* and NAME.* objectives. (If people want to use the "@rfcXXX" construct elsewhere, that's fine, but we need to keep all the existing extensibility.) Also, should we add a convention that private use objectives may use the same feature, e.g. 411:SRV.example ? Some details and nits: s/<mayor>/<major>/ > 2.3.3. Name Element > > The NAME,<name> elements is meant to provide basic name resolution s/NAME,<name>/NAME.<name>/ > ipv6-address-option = [O_IPv4_ADDRESS, ipv6-address] > ipv4-address-option = [O_IPv6_ADDRESS, ipv6-address] 1) Check your 6's and 4's ;-) 2) It's confusing that these are different from the basic GRASP options: [O_IPv6_LOCATOR, ipv6-address, transport-proto, port-number] [O_IPv4_LOCATOR, ipv4-address, transport-proto, port-number] It costs almost nothing in CBOR to include null values for the protocol and port. If you use the same option format as basic GRASP, it will remove confusion and very likely save code. > 5. IANA Considerations > > This document requests a new "GRASP Objective Value Standard > Elements" table in the GRASP Parameter Registrar. The values in this > table are names and a unique numerical value assigned to each name. > Future values MUST be assigned using the RFC Required policy Do you really want "RFC Required"? We chose "Specification Required" for GRASP objectives in general, which still requires Expert Review but with less imposed bureaucracy. Regards Brian On 31/10/2017 10:41, [email protected] wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > Title : DNS-SD compatible service discovery in GRASP > Author : Toerless Eckert > Filename : draft-eckert-anima-grasp-dnssd-00.txt > Pages : 15 > Date : 2017-10-30 > > Abstract: > DNS Service Discovery (DNS-SD) defines the common framework for > applications to announce and discover services. This includes > service names, service instance names, common parameters for > selecting a service instance (weight, priority) as well as service > specific parameters. > > GRASP is intended to also be used for service discovery. Reinventing > service discovery for GRASP with a similar set of fetures would > result in duplication of work. Therefore, this document defines how > to use GRASP to announce and discover services in a way that inherits > DNS-SD features and also tries to be compatible in spirit as much as > possibel while still maintaining the intended simplicity of GRASP. > > The goal of this document is to permit defining service and their > parameters once and then use that in GRASP, mDNS and (unicast) DNS. > Future work can also define DNS-SD <-> GRASP gateway functions. > > In support of service discovery, this document also defines name > discovery and schemes for reuseable elements in GRASP objectives > which are designed to be extensible so that future work that > identifies elements required across multiple objectives do not need > to define a scheme how to do this. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-eckert-anima-grasp-dnssd/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-eckert-anima-grasp-dnssd-00 > https://datatracker.ietf.org/doc/html/draft-eckert-anima-grasp-dnssd-00 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > I-D-Announce mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > _______________________________________________ Anima mailing list [email protected] https://www.ietf.org/mailman/listinfo/anima
