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

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, internet-drafts@ietf.org 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
> I-D-Announce@ietf.org
> 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
> 