Subject: [homenet] Benoit Claise's Discuss on draft-ietf-homenet-dncp-09: (with DISCUSS and COMMENT)

From: "Benoit Claise" <[email-masked]>
Date: Thu, 17 Sep 2015 02:11:11 -0700

Benoit Claise has entered the following ballot position for
draft-ietf-homenet-dncp-09: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-homenet-dncp/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

Other ADs focused on the protocol specific points. So let me focus on
something else.
The applicability section doesn't answer my questions: when to (re-)use
this protocol?
Note that the write-up mentioned ANIMA.

I see the protocol description:

   DNCP is designed to provide a way for each participating node to
   publish a set of TLV (Type-Length-Value) tuples, and to provide a
   shared and common view about the data published by every currently or
   recently bidirectionally reachable DNCP node in a network.

I see, under the applicability section, under which conditions to use
it.
Basically, suitable to exchange any TLV tuples, infrequently. 

However, this applicability section doesn't tell me when to re-use DNCP
(or define a profile for it).
What about the environment: home network versus LAN versus WAN? How big
can the network be?
Does the technology matter? 
Regarding transport, it's basically any transport, unicast or multicast,
right? (DNCP can be used in networks where only unicast transport is
available.  While DNCP uses the least amount of bandwidth when multicast
is utilized)
All devices in a DNCP network must be DNCP node?
I have a DNCP network with profile 1, can I use the same DNCP network
with profile 2?
IANA and enterprise specific TLVs?
UDP is fine as a transport?
What if I know my topology already (I see later: "may use multicast for
Trickle-based shared state dissemination and topology discovery") 
etc.  

Just reading the intro and the applicability, I scratched my head: it's
so generic, should I even consider it for ANIMA?

A few paragraphs, somewhere in the document, would solve my DISCUSS:
- this protocol should be used to exchange the following type of data
...
- it's envisioned that this generic state synchronization protocol will
be used in the following environments ...
- potential DNCP-based protocols include ...

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

- I would agree with Alvaro, when he wrote: "In general, I found the text
not straight forward or easy to understand." Potentially due to the
structure.

- I hope that a document about manageability considerations (see
https://tools.ietf.org/html/rfc5706#appendix-A) will follow.

- As reported by Victor, part of his OPS DIR review:
Found In Nits:

(https://tools.ietf.org/idnits?url=https://tools.ietf.org/id/draft-ietf-homenet-dncp-09.txt)

    - Use of lower case not with SHOULD statement (see Paragraph 2,
    Section 4.5)

    - Flagged spacing items (Lines 197, 252, 256 and 260)

Section 3: Overview 
   
    paragraph 2: their addresses may be manually configured or they may

       be found by some other means defined in a later specification

    ** This text is not quite clear.  Is it the author’s intention that
    the reader assume the other means will be part of a specific DNCP
    profile specification, a revision of the DNCP document or a
    different type of document.? ***

Section 4.2: Data Transport 

    Paragraph 4 / Part “Multicast+Unicast”

     <old> It is used to send Network State TLVs every now and

          then, as specified in Section 4.3

    <suggested> It is used to send Network State TLVs
    periodically, as specified in Section 4.3

    <reason>  Avoids using an idiom to express sending frequency
    in text.

Section 8.1 Pre-Shared Kay Trust Method

    ** Would it be within the DNCP document to discuss how PSKs are
    stored (as to not be externally accessed) or would it be to the
    profile to defined that level? ***

---

From: Markus Stenberg <[email-masked]>
Date: Thu, 17 Sep 2015 13:51:13 +0300

This is the gist of it. Even more frequently is ok, but then you have extra complexity without gaining from it.

_That_ is what you have to determine if you want to use it; do you want to synchronize a small set of TLV tuples, communicating efficiently, across a set of nodes.

> available.  While DNCP uses the least amount of bandwidth when multicast

Guesses are correct, but given it is more of an algorithm than concrete protocol, your questions are hard to respond in a generic way.

> All devices in a DNCP network must be DNCP node?

It is actually definition of DNCP network ; a set of DNCP nodes.

> I have a DNCP network with profile 1, can I use the same DNCP network

If the profiles’ transport details match and use a shared IANA TLV space, then yes.

> IANA and enterprise specific TLVs?

I am not sure what you mean by this; ultimately actually used TLVs are matter of (DNCP profile specific) IANA sub-registry, which should reserve the space. While DNCP itself reserves some space for DNCP-specific extensions (so far considered fragmentation, delta synchronization, authentication/confidentiality of multicast traffic using PSKs, and few other things), and leaves most of space open (for e.g. to be used as bits later on), the rest is up to profile.

> UDP is fine as a transport?

There is another DISCUSS on this, I will reply to it there.

> Trickle-based shared state dissemination and topology discovery") 

You can define a protocol that is solely TCP unicast based, for example, and make it’s definition of peer liveliness depend only on the TCP connections +- knowledge of topology graph changing.

(This assuming you know which nodes need to communicate with each other.)

> so generic, should I even consider it for ANIMA?

Funny, I get the opposite impression reading ANIMA mailing list, as I wonder if it is too generic for DNCP.

E.g. what if someone wants to share a DVD image to upgrade their routers using the protocol? DNCP is _not_ the way. URL + hash of content, or magnet link, perhaps, but not the image.

> - this protocol should be used to exchange the following type of data

See edit of first sentence of introduction in [1]. Still work in progress, but emphasizing that a) set of TLVs published by a node is small, and b) it has hard cap of 64kb.

> be used in the following environments …
> - potential DNCP-based protocols include …

I do not really see where to stick these or what the exact content would be;

‘anywhere you can use _a_ transport protocol’, ’to synchronize stuff (home automation? configuration? cache synchronization? routing? you name it, this can do it, although not necessarily well, and all have _already been done_ although not necessarily documented in the IETF)’

Structure has been rewritten more than once due to various reviews too. 

> https://tools.ietf.org/html/rfc5706#appendix-A) will follow.

Hm, I see value of having one for particular DNCP-based protocols but not really DNCP itself.

>    - Use of lower case not with SHOULD statement (see Paragraph 2,

Fixed in [1].

>    - Flagged spacing items (Lines 197, 252, 256 and 260)

In terminology. Fixing if someone tells me how, as I think it is just idnits not understanding the extra spaces between (multi-line) term being explained and it’s description.

>    different type of document.? ***

Addressed in [1]. The text is not actually clear at all, as it should REALLY say that that can be specified in a particular DNCP profile.  Rewrote and gave an example. Is it better?

>    <reason>  Avoids using an idiom to express sending frequency

Thanks, fixed. [1]

>    profile to defined that level? ***

That is entirely implementation matter; I do not think any other protocols that employ DTLS or TLS documents specify how that is done either. 

(Given counter-example, I do not mind copying text.)

Cheers,

-Markus

[1] https://github.com/fingon/ietf-drafts/commit/6ba8c1b73e49d64667ae1dabc1113ce5c6673e34 - to be published as dncp-10 at some point once we have DISCUSSes addressed.

---

From: Benoit Claise <[email-masked]>
Date: Thu, 17 Sep 2015 18:22:55 +0200

Markus,

Instead of focusing on the specific questions/answers, the key message is.
The applicability section doesn't answer my questions: when to (re-)use 
this protocol?

Regards, Benoit
> .

---

From: Markus Stenberg <[email-masked]>
Date: Thu, 17 Sep 2015 20:22:47 +0300

> On 17.9.2015, at 19.22, Benoit Claise <[email-masked]> wrote:
> The applicability section doesn’t answer my questions: when to (re-)use this protocol?

I still rephrase my previous answer - the one sentence that summarizes (what intro + applicability statement detain more detail) is: do you want to synchronize a small set of TLV tuples that changes relatively infrequently across a set of nodes, or not.

To expand it somewhat, most ‘application’ protocols can be more or less modeled as client-server (potentially hierarchical - hello DHCP), or distributed state sharing (e.g. link-state routing protocols, Pierre’s recent prefix assignment RFC). DNCP-profile defined TLV _transport_ can be used for either (it would be trivial to e.g. encapsulate DHCPv6 if you felt like it, not like it were a good idea). DNCP _state synchronization_ is just for the latter, and optimized for the case noted above.

I still do not know what to do about the text though.

Cheers,

-Markus

---

From: Juliusz Chroboczek <[email-masked]>
Date: Wed, 30 Sep 2015 12:59:30 +0200

> E.g. what if someone wants to share a DVD image to upgrade their routers
> using the protocol? DNCP is _not_ the way. URL + hash of content, or
> magnet link, perhaps, but not the image.

I think that's an enlightening example.  Perhaps it could be mentioned in
the document somewhere?

-- Juliusz