Re: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-yang-18.txt

[t petch <[e-mail]>]

Ian

I put your last e-mail to me somewhere safe, too safe for me to find 
just now.  So, I am going through -18 and thoughts so far

I like the treatment of DUID.

IANA status codes needs adding to the I-D references

server-module (part-reviewed)
prefix-delegation
6.3 would seem a better reference than 6.2

rapid commit
5.1 might be better than 5.2

leaf id
  Equivalent to subnet ID
I do not understand this, nor do the RFC uses of subnet enlighten me


common module
You have a MUST in the common module which means you should have the 
RFC8174 text in the module as well

duid-base
why a length of 260?  RFC allows 128 which sort of suggests two-byte 
character sets!

between 1 and 128 bytes
RFC has octets so I think that better

duid-unstructured
I do not understand what the pattern is doing here

OPTION_AUTH
the RFC references auth-namespaces so I think that this should too here 
and in I-D references

I note that this uses HMAC-MD5; I do not know how Security ADs view 
this; it may need a note in the Security Considerations

auth-information
string or binary?

sub-optiondata
again string or binary?  RFC does not help me here
I note that there is a two octet length field ie 65535 max

More to come.

Tom Petch


On 02/02/2021 11:36, t petch wrote:
> Ian
>
> Looks good, although it will be some time before I digest all the
> detail.
>
> Some admin type thoughts to be going on with.
>
> Authors: the I-D has six, which may or may not be ok with the AD, but
> the YANG modules have five or six or seven which is not ok! Consistency
> please.
>
> Contact in YANG modules must include WG website and e-mail, in the YANG
> modules in Appendices as well.
>
> NMDA or lack thereof needs a mention in Introduction or Abstract
>
> References: the YANG modules  reference
> RFC826
> RFC2464
> RFC4122
> <https://www.iana.org/assignments/dhcpv6-parameters>
> which need to be in I-D Normative References
>
> References in the YANG modules are patchy. You need them, I think, for
> many more leaves, all the timers, all the counts, as RFC and section
> therein, and for IANA Enterprise numbers (the URI)
> Without them I do not know where to look to see if the YANG matches the
> underlying definitions.
>
> IANA Considerations must register the four namespaces
>
> RFC8513 appears in several places, which I find rather telling
>
> s.1 lacks reference for YANG and Netconf and lacks RESTCONF
>
> Options: I would like a list of all the options supported so I do not
> have to reverse engineer the YANG to find them
>
> Abbreviations need expanding on first use
>
> s.2.1
>    *  enabled: Enables/disables the function of the //DHCPv6 /server.
>
> s.3.1
>         leaf rapid-commit {
>           type boolean;
>           description "A value of 1 specifies that the pool supports
> boolean are true or false
>
>         leaf client-duid {
>           type binary;
> for me 'duid' cries out for a YANG type definition
>
> s.3.3
>           defined in [RFC8415] is unsuccessful.";
> looks like markup language which is not allowed in YANG modules
>
> s.3.4
>       typedef timer-seconds32 {
>         type uint32 {
>           range "1..4294967295";
> 4294967295 looks the maximum value which case you can say 'max'
>
> you exclude zero which used to be a valid value for such as T1 and T2
>
>         leaf type-code {
>           type uint16;
>            default 65535;
> why is the default 65535?
>
>           case duid-unstructured {
>           ...
>             leaf data {
>               type binary;
> as above, I think that this should be a type.  Were it binary, I think
> length should be restricted, such as min 3 octet max 128 octet
>
> /description "The replay detection method used/description "The Replay
> Detection Method used/
>
> Tom Petch
>
>
> ----- Original Message -----
> From: <[e-mail]>
> To: <[e-mail]>
> Sent: Friday, January 29, 2021 3:25 PM
> Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-yang-17.txt
>
>
>> I've just posted -17 of the draft following discussion on the
> structure on the netmod mailing list. The discussion is here:
>>
>>
> https://mailarchive.ietf.org/arch/msg/netmod/uFNY9XfCcNANQNA34HpLVsF_lU8
> /
>>
>>
>> A number of changes were discussed and have been incorporated in this
> update. These are:
>>
>> * The element specific modules previously had a second module which
> described options relevant to the node. These options definitions have
> been incorporated into the relevant element modules. This means there
> are now total 4 modules in the draft  (instead of 7):
>>
>> Ietf-dhcvp6-common
>> Ietf-dhcvp6-client
>> Ietf-dhcvp6-relay
>> Ietf-dhcvp6-server
>>
>> * Options which are applicable to more than one node are now defined
> in the 'common' module to be imported and used by the relevant elements.
>>
>> * As a result, the identities for each node type is no longer needed,
> so these has been removed.
>>
>> * Additional option definition modules no long use 'RFCXXXX' in their
> naming. Short, descriptive names are used instead.
>>
>> * The appendix example for defining additional option definitions has
> been updated along with the accompanying text.
>>
>> * 'Enable' nodes have been added to the client, relay and server
> modules to enable disable overall function. Client and relay modules
> also have enable nodes for each DHCP interface included.
>>
>>
>> In addition, there are a number of small wording cleanups. Also,  in
> the security section, a bullet point about reconfiguring the
> relay-destination address has been removed. This was a duplicate bullet,
> copied in error under the read-only security descriptions.
>>
>> Thanks,
>> Ian
>>
>> On 29. Jan 2021, at 16:21,
> [e-mail]<mailto:[e-mail]> wrote:
>>
>>
>