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

[Steven Barth <[e-mail]>]

Hello Benoit,

in addition to the new appendix in -10 we have now staged the following text for the next Revision 
https://github.com/fingon/ietf-drafts/commit/fa712e2a2935fe3f4b6383582913ca6f4bc9e9f0

Does this address your issue or do you think we should add further applicability explanations.

PS: Sorry for the resend i screwed up my mail client earlier.

Thanks,

Steven

Am 17. September 2015 17:22:55 GMT+01:00, schrieb Benoit Claise <[e-mail]>:
>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
>> On 17.9.2015, at 12.11, Benoit Claise <[e-mail]> wrote:
>>>
>----------------------------------------------------------------------
>>> 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.
>> 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.
>>
>>> 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)
>> 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
>>> with profile 2?
>> 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.
>>
>>> What if I know my topology already (I see later: "may use multicast
>for
>>> Trickle-based shared state dissemination and topology discovery")
>>> etc.
>> 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.)
>>
>>> Just reading the intro and the applicability, I scratched my head:
>it's
>>> 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.
>>
>>> A few paragraphs, somewhere in the document, would solve my DISCUSS:
>>> - 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.
>>
>>> - it's envisioned that this generic state synchronization protocol
>will
>>> 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)’
>>
>>>
>----------------------------------------------------------------------
>>> 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.
>> Structure has been rewritten more than once due to various reviews
>too.
>>
>>> - I hope that a document about manageability considerations (see
>>> 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.
>>
>>> - 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)
>> 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.
>>
>>> 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.? ***
>> 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?
>>
>>> 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.
>> Thanks, fixed. [1]
>>
>>> 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? ***
>> 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.
>>
>> .
>>
>
>_______________________________________________
>homenet mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/homenet