Subject: Re: [homenet] RtgDir review: draft-ietf-homenet-dncp-05.txt

From: Markus Stenberg <[email-masked]>
Date: Wed, 5 Aug 2015 22:53:06 +0300

Now -09 is available. Changelog (diff is relatively large, but these are the main parts):

        - Reserved 1024+ TLV types for future versions (=versioning
        mechanism); private use section moved from 192-255 to 512-767.

        - Added applicability statement and clarified some text based on
        reviews.

URL:            https://www.ietf.org/internet-drafts/draft-ietf-homenet-dncp-09.txt
Status:         https://datatracker.ietf.org/doc/draft-ietf-homenet-dncp/
Htmlized:       https://tools.ietf.org/html/draft-ietf-homenet-dncp-09
Diff:           https://www.ietf.org/rfcdiff?url2=draft-ietf-homenet-dncp-09

On 29.7.2015, at 15.02, Thomas Clausen <[email-masked]> wrote:
>> Anyway, on to comments..
>> 
>> Caveat: These are my comments, Steven is likely to fix typos before we actually hit publish button on -09 :)
>> 
>> Executive summary: Minor edits, but as you are good with words, time to ask for advice - how would you explain “Endpoint” in the terminology? (Anyone else on the list too, feel free to chime up..)
>> 
> 
> Actually, when doing my review I tried if I could come up with some text that I would thing worked — which, if I had succeeded, I’d have been throwing it at you saying “…but this would make me happy”.
> 
> I didn’t come up with something that I actually liked. So instead, you get my random thoughts … 

Steven came up with a new definition => another attempt :) (one of these days I will count the different definitions..)

> Proposal….you say that you have a large TLV type space so ….why don’t we set aside the first two bits in the TLV type field, call that “Version”, and define “if both are cleared, then it means this specification, DNCPv1" and then have 2^14 “TLV types” — with a potential for 4 DNCP “versions”?
> 
> Then, we take an appointment in 15 years time. If by then we still have not found a reason to flip either of these two version bits, then (i) we write an “Updates DNCPv1” RFC which reassigns that field as “16 bit TLV Type”, and I buy lunch — otherwise, lunch is on you? 

We chose only 2^10 TLV types + 6 bits for future use. Looking forward to the lunch. (Then again, I do not think the 2^10 bits run out so third option of ‘protocol was left as is’ is the most likely one I think.)

>> (802-style) broadcast domain is what we’re probably looking for. There’s also ‘multiple access link’ in one place in the spec, to denote availability of link-local multicast I guess.
>> 
>> This terminology could use some further work I think though.
> Thanks, let me know when you want me to look at something concrete.

-09 is hopefully bit more correct in what it refers to as links. Please take a look.

> Recapitulating, I see basically two potential issues where we do not yet have resolution:
> 
> 	o	Versioning 
> 	o	Address/Endpoint terminology

Hopefully both addressed (then again, only me + Steven like the current address + endpoint text; random anonymous lurker on the mailing list, now it’s your chance is now to be the third!).

Cheers,

-Markus

---

From: Juliusz Chroboczek <[email-masked]>
Date: Wed, 12 Aug 2015 20:46:22 +0200

> On a different topic, I think reserving 32 TLV types to DNCP is far from
> being enough.

Seconded.

> I guess that comment joins Thomas’ comment about version numbers, with
> which I agree (that we should add one).

Thirded.

-- Juliusz

---

From: Juliusz Chroboczek <[email-masked]>
Date: Wed, 12 Aug 2015 20:48:10 +0200

> We have to wait until HNCP is mature enough at least.

Please allocate a port now, so we can start patching /etc/services, nmap,
etc.

-- Juliusz