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 <i...@thomasclausen.org> 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
_______________________________________________
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet
