Subject: [Anima] reserving SRV.* for GRASP Object Names --- (was Re: [IANA #1050768] expert review for draft-ietf-anima-autonomic-control-plane)

From: Michael Richardson <[email-masked]>
Date: Wed, 21 Feb 2018 16:54:53 -0500

Hi, WG.

I'm the designated expert reviewer for GRASP Object Names.
IANA asked me to look at autonomic-control-plane.  What fun!

I had NO problems with AN_ACP or SRV.est, but the following paragraph surprised me:

>    Note that the objective format "SRV.<service-name>" is intended to be
>    used for any <service-name> that is an [RFC6335] registered service
>    name.  This is a proposed update to the GRASP registry subject to
>    future work and only mentioned here for informational purposed to
>    explain the unique format of the objective name.

I think that if we want to reserve SRV.* for RFC6335 services, then we should
do exactly that.

The ship hasn't quite sailed on GRASP-15, because it's in gonna be in MISREF
on a bunch of other documents.  It could be done in GRASP-15, or in ACP; I
don't think that IANA cares, but it would less surprising to have it in
GRASP-15.  I don't know if it's been through AUTH48, I suspect not?

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Toerless Eckert <[email-masked]>
Date: Thu, 22 Feb 2018 02:43:26 +0100

Hi Michael,

I did not want to reopen the bottle on GRASP, and i did not want to
delay ACP spec either with discussions about this naming strategy either.

Therefore my idea was to simply use SRV.est in ACP without having to decide whether
or not this should or should not become a generic scheme.

The whole explanation of the idea and ask for reserving of the whole
SRV.est is in draft-eckert-anima-grasp-dnssd. Once we would adopt this
and it goes to RFC, that would be an update to GRASP RFC asking for the
IANA update to the registry.

This should give us more time to decide whether this should be the strategy
or if not, it will just be a one-off name for the ACP GRASP objective. No harm
done. just a strange name then. 

I also think technically its most logical to have this scheme in GRASP-DNS RFC:
it has the context explaining what these services are, how they can be mapped
to GRASP and thats all the context justifying the naming scheme. If we tried
to move this back into GRASP, this might be more text for explanation than we
want to have this late in the process. And in ACP it's even more a one-off.

Site Note: i started GRASP-DNS primarily to cut down on the complexity of
the GRASP service-discovery options that we would have to document in
ACP/BRSKI - and that feedback came from you too (remember i had one rev with TTL
and service priority etc of ACP and removed that - out of acp into grasp-dns after
your feedback)..

Cheers
    Toerless

> _______________________________________________
> Anima mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/anima

-- 
---
[email-masked]

---

From: Michael Richardson <[email-masked]>
Date: Thu, 22 Feb 2018 11:29:36 -0500

> delay ACP spec either with discussions about this naming strategy

I understand.

The problem is that I don't know how to read the paragraph I quoted.
It *seems* to instruct IANA to reserve more names, yet doesn't actually go as
far as saying that.

If it is not doing that, then maybe it should be removed and
let draft-eckert-anima-grasp-dnssd do it's thing.

The problem is that once the document is adopted, the WG could decide that
we want to name it "SERVICE.<foo>", or maybe some other scheme, but your
text, in attempting to anticipate things, constraints what the WG can do.

    >> Note that the objective format "SRV.<service-name>" is intended to
    >> be used for any <service-name> that is an [RFC6335] registered
    >> service name.  This is a proposed update to the GRASP registry
    >> subject to future work and only mentioned here for informational
    >> purposed to explain the unique format of the objective name.

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 23 Feb 2018 14:36:49 +1300

> let draft-eckert-anima-grasp-dnssd do it's thing.

At the moment I think that's best. I've already verified by writing
proof-of-concept code that what Toerless proposes is perfectly possible
and works with the DNS-SD examples at dns-sd.org, but if we reserve
SRV.est now and the designated expert (i.e. Michael R) blocks any
other SRV. registrations, we can go through a normal WG process.

For those interested the code is at https://github.com/becarpenter/graspy
(AskDNSSD2.py and GetDNSSD2.py)

     Brian

---

From: Toerless Eckert <[email-masked]>
Date: Fri, 23 Feb 2018 05:48:40 +0100

> It *seems* to instruct IANA to reserve more names, yet doesn't actually go as

Sorry for my language being difficult to understand. The paragraph was explicitly
meant to NOT give instructions to IANA (hence the "mentioned here for information
purposes"). Just to explain the choice of the name "SRV.est".

> let draft-eckert-anima-grasp-dnssd do it's thing.

Sure, i can remove that explanatory paragraph. Was just meant for a reviewer like you
anyhow. 

> text, in attempting to anticipate things, constraints what the WG can do.

The WG is completely free to do what it wants, adopt/not-adopt grasp-dnssd,
and if adopted choose the naming scheme. As an author of both drafts i
was just trying to make a good guess at a name to minimize the chance of
having to update it later. That's all. 

Wrt. good ideas that turned out not to be so good: check out the redundant
_udp, _tcp in DNS-SD names. Aka: There are worse things than picking aspirational
naming schemes even if they don't work out later.

So, lets see if i understand your guidance:

I will remove the explanatory paragraph, but wait for the next rev i need to do
for IANA/IESG review anyhow. I will keep the suggested name SRV.est.

Let me know if thats not ok.

Cheers
    Toerless

-- 
---
[email-masked]

---

From: Michael Richardson <[email-masked]>
Date: Fri, 23 Feb 2018 11:45:06 -0500

> for IANA/IESG review anyhow. I will keep the suggested name SRV.est.

check!

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        | network architect  [
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

---

From: Toerless Eckert <[email-masked]>
Date: Fri, 23 Feb 2018 17:48:58 +0100

>     > for IANA/IESG review anyhow. I will keep the suggested name SRV.est.
ack!

-- 
---
[email-masked]