Open zihaohe123 opened 6 years ago
Yes, I noticed that “duid-invalid” and I think “duid-other” or “duid-unknown” would be more appropriate. Invalid is a judgement call – it could be a new type that just hasn’t made it to the model. Personally, I still prefer to treat this completely as an opaque data item and not decode it at all. That just encourages mis-use of the data by Yang model users (3315bis did relax to SHOULD NOT use instead of 3315’s MUST NOT).
BTW, we might want to review the comments in the attached review as there are some general comments that seem to be applicable to all models.
From: Zihao He [mailto:notifications@github.com] Sent: Thursday, January 18, 2018 2:03 AM To: dhcwg/yang yang@noreply.github.com Cc: Subscribed subscribed@noreply.github.com Subject: [dhcwg/yang] dhcpv6-yang-05 (#10)
Hi, This is the version 05. The mainly changes are:
You can view, comment on, or merge this pull request online at:
https://github.com/dhcwg/yang/pull/10
Commit Summary
File Changes
Patch Links:
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHubhttps://github.com/dhcwg/yang/pull/10, or mute the threadhttps://github.com/notifications/unsubscribe-auth/ABm3YZnh1p7h_rs25a6ka-giPQnK2wtDks5tLuyIgaJpZM4RieTj.
Thanks, I used "duid-unknown" instead. Yes, whether to treat 'duid' as a totally opaque data still needs further consideration and discussion. I think it’s worth discussing in our next meeting.
Is there a plan to have a periodic meeting about the draft? Or by next, are you referring to DHC WG meeting (perhaps in London)? If London, no one has requested time for discussing the draft there.
I do think we will do better if we have periodic co-author/volunteers meetings as that pushes people to have more smaller deadlines (and some will be missed, but that’s better than missing them until the next IETF meeting). It worked fairly well for us on the DHCPv6 bis draft. Yes, in many cases there were just a few on the call but that’s more than if we didn’t have the call.
From: Zihao He [mailto:notifications@github.com] Sent: Tuesday, January 23, 2018 10:53 PM To: dhcwg/yang yang@noreply.github.com Cc: Bernie Volz (volz) volz@cisco.com; Comment comment@noreply.github.com Subject: Re: [dhcwg/yang] dhcpv6-yang-05 (#10)
Thanks, I used "duid-unknown" instead. Yes, whether to treat 'duid' as a totally opaque data still needs further consideration and discussion. I think it’s worth discussing in our next meeting.
— You are receiving this because you commented. Reply to this email directly, view it on GitHubhttps://github.com/dhcwg/yang/pull/10#issuecomment-360013033, or mute the threadhttps://github.com/notifications/unsubscribe-auth/ABm3YeoVgjrjNAItGe_ROmfOZlHuXs5xks5tNqkVgaJpZM4RieTj.
One other comment as I have been working through the model is why numeric ids are used for identifiers. For our server, administrators name things. Thus, option sets, prefixes, clients, etc. should have a name, not an integer, for the identity. (You can store a number as a string; yes the sort order is different but you can fix that by using leading 0s if you care.) I think if it is something expected to be configuration, it should be named. If it something that is “learned”, it can be iterated by a number since there would be no name.
From: Zihao He [mailto:notifications@github.com] Sent: Tuesday, January 23, 2018 10:53 PM To: dhcwg/yang yang@noreply.github.com Cc: Bernie Volz (volz) volz@cisco.com; Comment comment@noreply.github.com Subject: Re: [dhcwg/yang] dhcpv6-yang-05 (#10)
Thanks, I used "duid-unknown" instead. Yes, whether to treat 'duid' as a totally opaque data still needs further consideration and discussion. I think it’s worth discussing in our next meeting.
— You are receiving this because you commented. Reply to this email directly, view it on GitHubhttps://github.com/dhcwg/yang/pull/10#issuecomment-360013033, or mute the threadhttps://github.com/notifications/unsubscribe-auth/ABm3YeoVgjrjNAItGe_ROmfOZlHuXs5xks5tNqkVgaJpZM4RieTj.
Thanks Bernie, No sooner had I request the timeslot than I received your response email. :-) Yes, by “next” I am referring to IETF101 in London. Sorry that this work remains silent for a while because I have a lot of personal stuff (including final exams, etc.) to deal with in the past few weeks. Thanks for your proposal about the periodic meeting. Deadlines do help a lot. We will consider the meeting carefully. (Do you think it is necessary for us? @iffy50 ) Anyway, we will sort out the possible further progress that we can make before London, and work out a schedule by next week. As for the numeric identifiers, I agree your idea that a ‘name’ is better than an integer. And I’ll check Kea for more details about it.
Thanks again, Zihao
Hi, This is the version 05. The mainly changes are: