Re: [Anima] I-D Action: draft-eckert-anima-grasp-dnssd-01.txt

[Brian E Carpenter <[e-mail]>]

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