Subject: Re: [Anima-signaling] Draft design team report slides

From: Michael Richardson <[email-masked]>
Date: Wed, 01 Jul 2015 11:22:25 -0400

I might disagree with slide 6:
  "GDNP Discovery is not mandatory. For example, if DNS-SD is more
  appropriate, an ASA may use it."

I read this at first that DNS-SD would replace *GDNP*, but I guess it only
replaces GDNP *Discovery*.
I might prefer that use of DNS-SD might be an objective that GDNP negotiated.

If we are going to mix DNCP in, then I think we need to document how GDNP
and DNCP can be translated by an ASA.   If we have rejected DNCP outright as
basis for GDNP, I'm missed that part.

  "Using a simple JSON mapping for the protocol elements made this work much
  easier."

-- an interesting observation :-)

+10 on GRASP.
  
-- 
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 02 Jul 2015 08:34:02 +1200

> replaces GDNP *Discovery*.

OK, that needs better phrasing then,

> I might prefer that use of DNS-SD might be an objective that GDNP negotiated.

Actually I don't even think we need to specify that, do we? I'm more and
more inclined to the view that ASA designers should be left a lot of
flexibility. But it could certainly be possible.

> basis for GDNP, I'm missed that part.

I actually fail to understand how we could use DNCP in most cases. Maybe my brain
is built wrongly for this. I could see instantly when I first read an early
GDNP draft (before I was a co-author) how I could design options for almost
any use case. I was quickly convinced by Toerless that we could re-factor it
into a JSON or CBOR representation. But DNCP actually says nothing about how
I could represent, say, radio propagation characteristics (thinking back to
one of the UCAN use cases). Saying "Merkle trees" doesn't really help
with this.

> -- an interesting observation :-)

Well, I wasn't brought up on object-oriented programming, but I was
brought up on the virtues of Algol/Pascal class languages, and I think
that C was a great disaster for computer science, so... yes, JSON
pleases me as a design paradigm.

> +10 on GRASP.

Good. I'd just like to hear it from the WG.

Thanks
   Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 02 Jul 2015 14:18:49 +1200

Replying to myself...

> On 02/07/2015 03:22, Michael Richardson wrote:

...
> one of the UCAN use cases). Saying "Merkle trees" doesn't really help

Looking at the homenet list today, i.e. the two threads started by Julius
on "More about state desynchronisation in DNCP" and "More about lack of
fragmentation in HNCP", I am even more pessimistic about using DNCP for
general AN signaling. I'm sorry, it's an obscure design that is really tuned
for routing-related applications, and it lacks usability for easy-to-understand
interactions. (That is IMHO, of course.)

    Brian

---

From: Jéferson Campos Nobre <[email-masked]>
Date: Thu, 02 Jul 2015 04:52:38 +0000

Hi.
I think the slides show pretty much the idea in the text, which is good :)
About GDNP/DNS-SD and GDNP/HNCP/DNCP(ADNCP?): I agree in general with
Michael R., if we are going to mix GDNP and other protocols, it is
necessary to document that. Otherwise, we can see all these "hybrid modes"
as objectives negotiated using GDNP. I'm just not sure how much complexity
this will add to ASA design.
Cheers.
Jéferson

Em qua, 1 de jul de 2015 às 23:18, Brian E Carpenter <
[email-masked]> escreveu:

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