I am repeating below my comments previously made on the -00 version, since they still apply to -01.
FYI there is some hacked-together Python3 code for the GRASP part of this at https://github.com/becarpenter/graspy/blob/master/AskDNSSD2.py and https://github.com/becarpenter/graspy/blob/master/GetDNSSD2.py The code has zero production value but it validates the GRASP objective syntax in the draft against real-world DNSSD examples. ---- 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 _______________________________________________ Anima mailing list [email protected] https://www.ietf.org/mailman/listinfo/anima
