From nobody Mon Jan 17 09:40:16 2022 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 156C43A094B; Mon, 17 Jan 2022 09:40:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gmx.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id htIdkFo2q5cC; Mon, 17 Jan 2022 09:40:03 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 10F7F3A0948; Mon, 17 Jan 2022 09:40:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1642441198; bh=NtG1BJNSxAf633ZX2JzPsVm8lk83vQVGEGoHYISw0MM=; h=X-UI-Sender-Class:Subject:From:In-Reply-To:Date:Cc:References:To; b=iWVQ4vk8hrYIcg0Q9pnDR82MRKQqGzf2rHf3m+BkbKkj7noyGzqFnfIgU60xikCNI c48RrYoxZa1JWMscWM5m4w22dCNFNntPJSitfWcyVRRMm3f6vlm6Awg2MHM6g4q7Nw 056cGHk3Ih2gNx2EtWUZl78rkDukfmsbS8btW8/Q= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from smtpclient.apple ([87.78.108.189]) by mail.gmx.net (mrgmx004 [212.227.17.184]) with ESMTPSA (Nemesis) id 1MgvvT-1mfPpT0LPx-00hM0f; Mon, 17 Jan 2022 18:39:58 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 15.0 \(3693.40.0.1.81\)) From: ianfarrer@gmx.com In-Reply-To: <163952685584.6395.6879611267419166159@ietfa.amsl.com> Date: Mon, 17 Jan 2022 18:39:56 +0100 Cc: The IESG , draft-ietf-dhc-dhcpv6-yang@ietf.org, dhc-chairs@ietf.org, dhcwg , Timothy Winters Content-Transfer-Encoding: quoted-printable Message-Id: References: <163952685584.6395.6879611267419166159@ietfa.amsl.com> To: Benjamin Kaduk X-Mailer: Apple Mail (2.3693.40.0.1.81) X-Provags-ID: V03:K1:Bu63pQZJAomKiHVQ8hgdRg1EVha82E+o9T+xjpwq4iinCADNjyn 6Pn1wkbYOzqC7GiqZDZq8epWo2hSc5cHAvl5b8iVIsNNpq1EefAdydF9JSm0C0IS1jb8BGj xyF2RG3Ar+38GyX4Lf9t6xoh/q7qJUByDZdziClqQBRDZWmCZgcRrFHEnP3ftSpQJtfM48z cNpJj1mYJL7Cap/HpGDqA== X-UI-Out-Filterresults: notjunk:1;V03:K0:8I/zgAEYVRw=:cHsz4nq/C3qu5TmNTuZ7T3 HT+a8ZE1BX4oVdUYE/j+aBg/xPfY4O+EiMdckW4e0CZHm2lLhT1TUZnna69Wi38FV3+Gj+ZO9 n/Hfk4vFf6MG5WvLyMn1/jogOpHRAZCnLKr2Mi53JdYqicEJl+dJspAPmj3PGiNxiUYwCZMQ/ QaSgqPcG337/sCcPqzeXWKhk2r6XbcPr3JzU1TbiNYCHpVC2YoQ+fYCbxIn2wWtQCrp0YoP5i XIGOnsZk43iWgq/Vbal6ewz/0oLilV0vXdfRHk+joM0tzYZ5+CigvnG7yY1zl+Ox52qqsfWiH zhZmVcLFFciBotfJc7y/18bw8/ijWWxD6z8slPfH86YYjnJRuxZzHlj3tMyRTVpDJwtx23srA ZXyxgs3a8nuXygTo8XwwCU1GykoCOhZUS0hW2x2GTpdZDKKG+G00+OB0+wOgOM9jN/IXY2IXx lUrfk4PNs2uv0BXF/3vxgVAUEWQYedyARr2xHrIiysjpROHM+2Hp7iHNzwn2hUMgM/GgwsFZo ae9uM9OecYXfv9LNTQg4hIcUwVI+d9Eh6fTA4xSEg78sQSsJ2SleCGcgyyMhlsi91p6IS/hJc cYZmIMs8iXj/Gs1HBRIct43AkF9uAp9ULUrafon/d4cKiuiQhne4egtvZFDLzBJGV7Oereaph mtc2S39WUkJ0WkGVO+JdACIXiuuXGLaPyw8gCcr6KXByyfN+Geuc09fm7nUPaGgsoEH7N5y75 kAnxsxn9A9vR51Hgzjv7iVrWrKvr0vmSVcgtU+XIVMnzDEKoEPaO8aYWZELFgPqnd126wTvIA 4/C2fZr9Zl19AD++WoPx3fNf4r2kpvMgsqXqWXk9zYLl6aN3kfivt2Kw+tCviEJsT+0D7ETci iSBnZK+zmIAi/zmSqtrh+0iYmhjsuD2A2H54b17awE45OKlDWh9hPNdJmg00q2zzfJA2iP09C M0JZxFegWEyflDr606ZzfCXxlz/DOCs3jxAyvGEv/qxHVU96fqDGBYUTx/yeAYnu93dPHXL47 M/Wb+DA7Dj+hyl4c2c/uu060dmb0jcObVARK0OQWgVAkk/AHqWZVeaXLadeZGp+xrTcRiDxFn cy6VSUtQv+Tc5w= Archived-At: Subject: Re: [dhcwg] Benjamin Kaduk's Discuss on draft-ietf-dhc-dhcpv6-yang-24: (with DISCUSS and COMMENT) X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Dynamic Host Configuration List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jan 2022 17:40:09 -0000 Hi Benjamin, First of all, many thanks for the detailed review and my apologies that = it=E2=80=99s taken so long for me to reply. Please see inline below. @Bernie/@Tim, there are a couple of points below that I would appreciate = your input on (specifically, restructuring of the OPTION_AUTH modelling = and the best type for interface-id-option-group and = user-class-option-group to use). Thanks, Ian > On 15. Dec 2021, at 01:07, Benjamin Kaduk via Datatracker = wrote: >=20 > Benjamin Kaduk has entered the following ballot position for > draft-ietf-dhc-dhcpv6-yang-24: Discuss >=20 > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut = this > introductory paragraph, however.) >=20 >=20 > Please refer to = https://www.ietf.org/blog/handling-iesg-ballot-positions/ > for more information about how to handle DISCUSS and COMMENT = positions. >=20 >=20 > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-dhc-dhcpv6-yang/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- >=20 > Roman's comment touched on a related point, but I'd like to (hopefully > briefly) discuss the way we encode certain opaque protocol fields. > There are some places where we clearly intend a hex representation (a > string with a pattern that's marked out as pairs of hex digits), but > there are others where we just say "type string" with no indication of > encoding, and even a "type binary". If we want the specification to > admit interoperable implementation we need to be more clear about what > encoding we expect for all of these nodes. I have noted most = (possibly > all, but please double check) in the COMMENT section, with a = preference > for "type binary" where we don't need to apply regex restrictions. = But > that's just a personal preference, and choosing to use hex (or base64, > or any other well-defined) encoding will suffice to resolve the = discuss > point. [if - I=E2=80=99ve changed from type string to binary where-ever = possible throughout according To the specific comments below. The one exception is for the = auth-option, which Allows for different formats depending on the auth protocol in use. = I=E2=80=99ve reworked the=20 Format of the option to make this explicit.] >=20 >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > Thanks to the shepherd for answering the second part of question (1) = in > the template, as well as the first; this part of the question is often > missed. (There is, however, a third part as well...) >=20 > Section 1.2.1 >=20 > Table 1 is described as showing "the DHCPv6 options that are modeled, > the element(s) they are sent by, and the relevant YANG module name". = In > my interpretation that means that: >=20 > - the only options that are in the table are ones that are modeled > - the contents of the table shows which elements send those options >=20 > But the contents of the table don't quite seem to match that -- it = seems > that they only indicate which nodes have YANG modeling for how to send > the option, and not indicate nodes that send the option but do not = need > YANG configuration to control how to populate the option. (E.g., > OPTION_AUTH and OPTION_USER_CLASS.) If this is the intent, then = perhaps > it's clearer to say "which YANG modules they are modeled for" or > something similar, rather than "the element(s) they are sent by". [if - Changed] >=20 > Section 3.1 >=20 > * address/prefix-pool-utilization-threshold-exceeded: Raised when > the number of leased addresses or prefixes exceeds the configured > usage threshold. >=20 > The node that seems to be where the "configured usage threshold" is > configured is scoped to an address pool or prefix pool. Should this > description say "number of leased [...] in an address pool exceeds the > configured usage threshold"? [if - I=E2=80=99ve changed this to read:=20 "address/prefix-pool-utilization-threshold-exceeded: Raised when the = number of leased addresses or prefixes in a pool exceeds the configured usage = threshold." >=20 > Section 4.1 >=20 > +------+------+----------+--------------+ > | 0001 | 0006 | 28490058 | 00005E005300 | > +------+------+----------+--------------+ >=20 > This example includes the 2-octet DUID type of 1 (0x01), the > hardware type is 0x06 (IEEE Hardware Types) the creation > time is 0x028490058 (constructed as described above). Finally, > the link-layer address is 0x5E005300 (EUI-48 address > 00-00-5E-00-53-00)"; >=20 > Should there be some more zeros in here (e.g., in the artwork before > 28490058)? [if - The creation time is a 4-octet field, so the artwork is correct. = I=E2=80=99ve=20 changed the value in the description to 0x28490058] >=20 > typedef duid-en { > type duid-base { > pattern '0002' > + '[0-9a-fA-F]{4,}'; > } > description > "DUID type 2, assigned by vendor based on Enterprise > Number (DUID-EN). This DUID consists of the 4-octet vendor's > registered Private Enterprise Number as maintained by IANA > followed by a unique identifier assigned by the vendor. For > example: >=20 > A 4-octet PEN would be 8 hex digits (the YANG allows as few as 4). [if - Changed to 8] >=20 > typedef duid-unstructured { > type duid-base { > pattern '(000[1-4].*|.*[^0-9a-fA-F].*)' { > modifier invert-match; > } > } >=20 > My understanding is that the "pattern" modifiers from the base type = and > the derived type are "and"-ed together, so the "|.*[^0-9a-fA-F].*" > clause is redundant with the pattern in the base type and thus not > needed. [if - Changed to=20 pattern '(000[1-4].*)'] >=20 > container status { > [...] > leaf message { > type string; > description > "A UTF-8 encoded text string suitable for display to an > end user. It MUST NOT be null-terminated."; >=20 > (Related to Roman's comment) > This is probably more of a comment on RFC 8415 than this document, but > BCP 18 seems pretty clear that a string destined for display to a = human > should be accompanied by a language indicator. > (This comment probably applies to every "leaf message" but I will just > mention it this once.) [if - I=E2=80=99m not sure how we can handle this as the leaf(s) is only = used for Holding RO state data which it obtains from the client/relay/server = implementation. As You mention, RFC8415 does not place any requirements on the message to = contain a language identifier.] >=20 > grouping auth-option-group { > [...] > container auth-option { > [...] > leaf auth-information { > type string; > description > "The authentication information, as specified by the > protocol and algorithm used in this Authentication > option."; >=20 > This should probably be binary, not a string. Or, if it needs to be a > string, it should specify an encoding (e.g., hex). [if - The authentication information format is dependant on the value Of the protocol field. I=E2=80=99ve re-modelled this option to take this = into account. The configuration-token (RFC3118) does allow for plain text and = specifically Gives a clear text password as an example use case. @Bernie, @Tim, please can you review this an make sure that I=E2=80=99ve=20= Understood DHCPv6 auth properly? grouping auth-option-group { =20= description =20= "OPTION_AUTH (11) Authentication Option."; =20= reference "RFC 8415: Dynamic Host Configuration Protocol =20= for IPv6 (DHCPv6), Section 21.11 = =20 RFC 3118: Authentication for DHCP Messages =20= IANA 'Dynamic Host Configuration Protocol (DHCP) Authentication =20= Option Name Spaces' registry. =20= "; =20= container auth-option { =20= description =20= "OPTION_AUTH (11) Authentication Option container."; =20= leaf algorithm { =20= type uint8; =20= description =20= "The algorithm used in the authentication protocol."; =20= } =20= leaf rdm { =20= type uint8; =20= description =20= "The Replay Detection Method (RDM) used in this =20= Authentication option."; =20= } =20= leaf replay-detection { =20= type uint64; =20= description =20= "The replay detection information for the RDM."; =20= } =20= choice protocol { = =20 description =20= "The authentication protocol used in the option. Namespace =20= values 1 (delayed authentication) and 2 (Delayed =20= Authentication (Obsolete) are not applicable and so are =20= not modelled."; =20= case conf-token { =20= leaf token-auth-information { =20= type string; =20= description = =20 "Protocol Namespace Value 0. The authentication = =20 information, as specified by the protocol and =20= algorithm used in this Authentication option."; =20= } =20= } =20= case rkap { = =20 description =20= "Protocol Namespace Value 3. RKAP provides protection =20= against misconfiguration of a client caused by a Reconfigure =20= message sent by a malicious DHCP server."; =20= leaf datatype { =20= type uint8 { =20= range "1 .. 2"; =20= } =20= description =20= "Type of data in the Value field carried in this =20= option. =20= 1 Reconfigure key value (used in the Reply =20= message). =20= 2 HMAC-MD5 digest of the message (used in =20= the Reconfigure message)."; =20= } =20= leaf auth-info-value { = =20 type binary { = =20 length 16; = =20 } =20= description "Data as defined by the Type field. A 16-octet =20= field."; =20= } =20= } =20= } =20= } =20= }=20 ] >=20 > grouping status-code-option-group { >=20 > FWIW, this grouping seems unused by the rest of the document. = (Perhaps > a remnant of a decision to move the status information out of the > options section and into a higher level of the relevant YANG trees?) [if - Yes, this was an unused remanent. Removed]=20 >=20 > leaf sub-option-data { > type string { > pattern '([0-9a-fA-F]{2}){0,}'; > } > description > "The data area for the sub-option."; >=20 > Why does this need to be hex-encoded (vs. YANG binary)? > And, if it is hex-encoded, we should probably say so explicitly in the > description. [if - Changed to binary] >=20 > Section 4.2 >=20 > leaf preferred-lifetime { > type dhc6:timer-seconds32; > description > "Preferred lifetime for the Identity Association (IA)."; > reference "RFC 8415: Dynamic Host Configuration Protocol for > IPv6 (DHCPv6), Section 6"; >=20 > Is Section 6 really the best section reference for this concept? [if - Changed to Section 12.1 (also changed for the valid-lifetime = leaf)] >=20 > grouping message-stats { >=20 > The relay module has a counter for discarded messages; would a similar > counter make sense here? (Also for the server module, I think.) [if - Added - also for the client module.] >=20 > Also, YANG does have dedicated "counter" types to more precisely > indicate semantics than just "uint32". They are by definition > monotonically increasing, though, and are their use is typically > accompanied by a "last discontinuity time" node to indicate when they > have been reset. [if - Changed to yang:counter32 throughout and added a = discontinuity-time node to server/relay/client modules] >=20 > grouping info-refresh-time-option-group { > [...] > leaf info-refresh-time { > type dhc6:timer-seconds32; > description > "Time duration relative to the current time, expressed > in units of seconds."; >=20 > Is this really "relative to the current time" for purposes of the YANG > module? This is the description that RFC 8415 uses, yes, but that > refers to the current time when the protocol message is received, and > YANG interactions may be asynchronous to that. [if - Changed to read: "Time duration specifying an upper bound for how long a =20= client should wait before refreshing information retrieved =20= from a DHCP server.=E2=80=9D; ] >=20 > container address-pools { > [...] > list address-pool { > key pool-id; > [...] > leaf pool-id { > type string; >=20 > What's the motivation for making the pool-id a string vs the = option-set > and allocation-range lists that have an integer identifier? (Also > applies to prefix pools.) [If - Initially all of the identifiers were integers. The change to = string=20 Specifically for Pool-id was made by =C3=89ric during the AD review. Agree that it makes sense to use the same format, so the option-set-id And allocation-range id are now type string.] >=20 > leaf pool-prefix { > type inet:ipv6-prefix; > mandatory true; > description > "IPv6 prefix for the pool."; >=20 > Does this prefix need to be contained within the overall > "network-prefix"? (Same question for prefix-pools' pool-prefix.) [if - With the DHCP server implementations that I am familiar with, yes = it would need to be contained, but I guess other implementations may not. I=E2=80=99= m not aware=20 of any way of enforcing this in the YANG.] >=20 > leaf max-address-utilization { > type dhc6:threshold; > description > "Maximum amount of the addresses in the > pool which can be simultaneously allocated, > calculated as a percentage of the available > addresses (end-address minus start-address plus > one)."; >=20 > Do we want to mention the relationship between this node and the > "address-pool-utiliziation-threshold-exceeded" notification? I see = the > pointer the other direction, but since we don't use the word = "threshold" > in the description here I wouldn't mind a more explicit linkage. > (Likewise for the prefix-allocation case.) [if - I=E2=80=99ve updated the description with: " Used to set the value for the = address-pool-utilization-threshold-exceeded =20 notification=E2=80=9D;=20 And the equivalent change for prefix-allocation.] >=20 > list active-lease { > key leased-prefix; > description > "List of active prefix leases."; > leaf leased-prefix { > type inet:ipv6-prefix; > description > "Active leased prefix entry."; >=20 > Is the prefix length available from some other information in the = tree? > If not, should it be listed here? [if I=E2=80=99m not sure I understand the comment. The prefix pool has = the=20 =E2=80=98Client-prefix-length=E2=80=99 leaf which defines the length of = prefixes that are offered for the pd-pool. However, client=E2=80=99s may hint that they want a different prefix = length in TOheir pd request and depending on implementation / policy the server May honour this (for a longer prefix than the defined = client-prefix-length). RFC8168 discusses this.] >=20 > notification decline-received { > if-feature na-assignment; > description > "Notification sent when the server has received a > Decline (9) message from a client."; >=20 > Is this a potential DoS vector to the notification recipient (if a > malicious client just starts declining everything)? Should we say > anything about rate-limiting? [if - =46rom the perspective of the YANG module and its implementation, I don=E2=80=99t think so. The reason is that state/counter data is = accessed via the YANG Operational data store and this is only retrieved from the process / = function=20 Being managed when a NETCONF request Is made for the information, so that it is as current as possible. This is for every YANG module implementation that we\ve done, but I = think this is general best practice.] >=20 > notification non-success-code-sent { > description > "Notification sent when the server responded > to a client with non-success status code."; >=20 > (similarly here) [if - See above] >=20 > Section 4.3 >=20 > grouping interface-id-option-group { > [...] > leaf interface-id { > type string; > description > "An opaque value of arbitrary length generated by the > relay agent to identify one of the relay agent's > interfaces."; >=20 > I think this is better as a YANG "binary" type than a string. If not, > we should say something about the encoding. [if - I=E2=80=99m familiar with the use of this option in Cisco and ALU = relay Implementations and both allow clear text configuration of the value that is carried in this field. RFC8415 doesn=E2=80=99t give any specific guidance on whether this Should be ASCII or can be UTF-8. RFC7227 Section 5.8 does state that future options should use UTF-8, But this option would have been defined before RFC7227 was published. @Bernie/@Tim, do you have any guidance on this?] >=20 > Section 4.4 >=20 > Why do we use "prefix-del" for the feature name in this module but the > full "prefix-delegation" in the other modules? [if - now using prefix-delegation throughout] >=20 > grouping message-statistics { >=20 > The relay module has a counter for discarded messages; should we? [if - Added] >=20 > grouping option-request-option-group { > description > "OPTION_ORO (6) Option Request Option. A client MUST include > an Option Request option in a Solicit, Request, Renew, > Rebind, or Information-request message to inform the server > about options the client wants the server to send to the > client."; >=20 > If I understand correctly, there are further MUST-level requirements = for > what options must be present in the ORO. E.g., = INFORMATION_REFRESH_TIME > is required in Information-Request. Do we want to mention that here? > Are there any considerations for how that requirement interacts with = the > values configured by YANG? E.g., do we expect implementations to > forcibly add those required options on top of the configured ones, in > scenarios where they are required? [if - Description now updated to: "List of options that the client is requesting, =20= identified by option code. This list MUST include the =20= code for option SOL_MAX_RT (82) when included in a = =20 Solicit-message. If this option is being =20= sent in an Infoformation-request message, then the code =20= for option OPTION_INFORMATION_REFRESH_TIME (32) and = =20 INF_MAX_RT (83) MUST be included.=E2=80=9D; =20 The references also updated for the sections of RFC8415 defining the = requirements.] >=20 > grouping user-class-option-group { > [...] > leaf user-class-data { > type string; > description > "Opaque field representing a User Class > of which the client is a member."; >=20 > I think this would be better as YANG binary than string. If we keep = it > as string, we need to say what encoding is used. >=20 > container vendor-class-option { > [...] > list vendor-class-option-instances { > [...] > list vendor-class-data-element { > [...] > leaf vendor-class-data { > type string; > description > "Opaque field representing a vendor class of which > the client is a member."; >=20 > (likewise here) [if - IME these are usually a user configurable text string on client / = server implementations. I think the same comment for the format as for Section 4.3 = interface-id-option group=20 Applies here. @Bernie/@Tim, any thoughts?] ] >=20 > leaf client-duid { > if-feature "non-temp-addr or prefix-del " + > "or temp-addr and not anon-profile"; >=20 > Does the default YANG operator precedence do what we want with respect > to ((non-temp-addr or prefix-del or temp-addr) and not anon-profile) = vs > (non-temp-addr or prefix-del or (temp-addr and not anon-profile))? >> =46rom the context in the rest of the document, it's clear that we = want > the former, but I'm not familiar enough with YANG minutiae to say if > that's what we actually are specifying. [if - Changed to "(non-temp-addr or prefix-delegation or temp-addr) and = not anon-profile=E2=80=9D. Per RFC7950, groupings in parentheses are evaluated first, then the = =E2=80=98not' statement.] >=20 > notification invalid-ia-address-detected { > if-feature "non-temp-addr or temp-addr"; > [...] > leaf ia-id { > type uint32; > mandatory true; > description > "IA-ID"; >=20 > If I understand correctly, in DHCP the IA-ID is scoped per client = DUID. > Does this notification convey enough information to disambiguate what > scope this IA-ID value belongs to? [if - The IA-ID is a 4-octet field which is present in options = requesting an address or prefix (OPTION_IA_NA/IA_TA/IA_PD). The client will normally have a single DUID for all of it=E2=80=99s = requests on all DHCP Enabled interfaces, but could make requests for multiple = addresses/prefixes in each DHCP request. In this case each IA_xA option would have the same = DUID, and a unique IA-ID field so the Client can associate the allocated address/prefix from the server to the = specific request option.] >=20 > [...] > leaf ia-na-t1-timer { > type uint32; > description > "The value of the T1 time field for non-temporary address > allocations (OPTION_IA_NA)."; > } > leaf ia-na-t2-timer { > type uint32; > description > "The value of the preferred-lifetime field for non-temporary > address allocations (OPTION_IA_NA)."; >=20 > Should these two be here without a feature conditional? They seem to = be > NA-specific but we could send this notification if NA is not > implemented. [if - notification invalid-ia-address-detected has if-feature = non-temp-addr or temp-addr which Is applicable to all of the nodes defined in the notification. The notification can only be triggered if an address is requested and = allocated then found to Be invalid, e.g. it fails DAD, so this couldn=E2=80=99t happen if the = client doesn=E2=80=99t implement IA_NA/IA_TA (And has the relevant feature enabled).] >=20 > notification transmission-failed { > [...] > leaf failure-type { > type enumeration { >=20 > (side note?) I get antsy about not leaving an extension point for = other > types of (re)transmission failure, but I also don't have any specific > scenario in mind that's not already covered, so. [if - I think that all of the client message transmission failures can = be boiled down to =E2=80=98I tried/retried sending this type of message and didn=E2=80=99t = get an answer=E2=80=99 which is what=E2=80=99s Covered in the notification. We could add an other/unspecified to the = enum, but I also Can=E2=80=99t think of what would trigger this.] >=20 > notification unsuccessful-status-code { > description > "Notification sent when the client receives a message that > includes an unsuccessful Status Code option."; >=20 > As for the other notifications on failure, is this a potential DoS > vector? [if - I don=E2=80=99t think so. For Netconf notifications, the network = management system Creates a session and subscribes to the notifications from the DHCP = client. If one (or many) DHCP clients were generating too many notifications, = then the NMS would Close the session and stop receiving the DHCP client=E2=80=99s = notifications.] >=20 > Section 5 >=20 > It's probably worth mentioning the risk of notifications turning into = a > DoS vector (absent rate-limiting) here. [if - This is surely a problem with Netconf notifications overall, = rather than specifically For the DHCP modules? I=E2=80=99ve checked through RFC5277 (Netconf = event notifications) and There is nothing on rate-limiting messages or in the Security = Considerations section on this subject.] >=20 > Can a misconfigured client cause problems for a (honest) server, e.g., > by sending a lot of requests for a lot of things, very quickly? [if - I=E2=80=99m sure that it would be possible. RFC8415 only places = requirements On clients to limit the rate for messages that they send, but not on a = server To limit the rate of received messages it will try and process. =46rom a little research, I see that some DHCP server implementations = have=20 configuration for this, but others do not. It=E2=80=99s feasible that = this could also be Done through e.g. ip6tables rules on a host. I would see this as being a feature that should be configured (if = available) through the=20 Implementation specific YANG module or possibly the ACL YANG (RFC8519)] >=20 > All data nodes defined in the YANG modules which can be created, > modified, and deleted (i.e., config true, which is the default) are > considered sensitive. Write operations (e.g., edit-config) to these > data nodes without proper protection can have a negative effect on > network operations. >=20 > Do we want to go further and give some broad treatment of how the > negative effects would come about (e.g., by disrupting address > allocation and the routability of addresses/prefixes that clients > attempt to use)? >=20 > An attacker with read/write access the DHCPv6 relay can undertake > various attacks, such as: >=20 > * Modifying the relay's "destination-address" to send messages to a > rogue DHCPv6 server. >=20 > * Deleting information about a client's delegated prefix, causing a > denial of service attack as traffic will no longer be routed to > the client. >=20 > I'd considering reiterating the "full denial of service" capability > (which is currently implicit in "send messages to a rouge DHCPv6 = server" > combined with the list of attacks that a compromised server can > undertake). [if - I=E2=80=99ve updated the examples as follows: Server: Denial of service attacks, such as disabling the DHCP =20= server sevice, or removing address/prefix pool = =20 configuration. =20= =20 Various attacks based on re-configuring the contents =20 of DHCPv6 options, leading to several types of security or =20= privacy threats. For example, changing the address of a = =20 DNS server supplied in a DHCP option to point =20= to a rogue server. =20= =20 And for the relay =20 Denial of service attacks, based on disabling the =20 DHCP relay function, or modifying the relay's =20= "destination-address" to a non-existant address. = =20 =20 Modifying the relay's "destination-address" to send =20 messages to a rogue DHCPv6 server. =20= =20 Deleting information about a client's delegated =20 prefix, causing a denial of service attack as traffic =20= will no longer be routed to the client. =20= =20 ] >=20 > Some of the readable data nodes in this YANG module may be = considered > sensitive or vulnerable in some network environments. Therefore, it > is important to control read access (e.g., only permitting get, get- > config, or notifications) to these data nodes. These subtrees and > data nodes can be misused to track the activity of a host: >=20 > First off, thank you for stating this consideration so clearly. >=20 > Second, there may be an additional consideration for read-only access = -- > knowledge of what pools of addresses are available for allocation = might > facilitate network reconaissance (viz. RFC 7707). [if - I=E2=80=99ve added the following text: Information about a server's configured address and prefix pools may =20= be used by an attacker for network reconnaissance [RFC7707]. The =20= following subtrees and data nodes could be used for this purpose: =20= =20= * Information about client address allocation ranges: (dhc6-srv/ =20= allocation-ranges/allocation-range/address-pools/ address-pool/ =20= pool-prefix) =20 =20= * Information about client prefix allocation ranges: (dhc6-srv/ = =20 allocation-ranges/allocation-range/prefix-pools/ prefix-pool/pool- prefix) =20 ] >=20 > [RFC7824] covers privacy considerations for DHCPv6 and is applicable > here. >=20 > I'd suggest mentioning the RFC 7844 privacy profile as a partial > mitigation that is sometimes applicable. [if - Do you mean that RFC7844 can provide partial mitigation of the = server Privacy issues in RFC7824?] >=20 > Section 9.2 >=20 > RFC 8987 is used as in a few YANG reference stanzas, but is not > mentioned in the preface before the containing YANG module. It could > arguably be classified as normative based on that usage. [if - I=E2=80=99ve added=20 "The RPCs in the module are taken from requirements defined = [RFC8987].=E2=80=9D To the preface before the relay tree diagram. RFC8987 is now normative.] >=20 > Appendix D >=20 > case user-class-option-id { > description > "Client class selection based on the value of the > OPTION_USER_CLASS(15) and its user-class-data field."; > leaf user-class-data { > type string; > mandatory true; > description > "Value of the enterprise-number field."; >=20 > This description doesn't look right. [if - Changed to =E2=80=9CUser Class value to match=E2=80=9D] >=20 > NITS >=20 > We might check the spelling of "grouping message-stats" (vs "grouping > message-statistics") across modules. [if - now uses =E2=80=98message-statistics=E2=80=99 throughout] >=20 > Section 4.2 >=20 > leaf rapid-commit { > type boolean; > description > "When set to 'true', Specifies that the pool supports > client-server exchanges involving two messages."; >=20 > This is in the "grouping resource-config" that may or may not be used > within a "pool" container. A more generic phrasing might be in order. [if - Changed to "When set to 'true', Specifies that client-server exchanges involving two messages is supported.=E2=80=9D;] >=20 > grouping sol-max-rt-option-group { > [...] > leaf sol-max-rt-value { > type dhc6:timer-seconds32; > description > "sol max rt value"; >=20 > That's a pretty sparse description. [if - Changed to: "Maximum Solicit timeout value.=E2=80=9D] >=20 > grouping inf-max-rt-option-group { > [...] > leaf inf-max-rt-value { > type dhc6:timer-seconds32; > description > "inf max rt value"; >=20 > (ditto) [if - Changed to: "Maximum Information-request timeout value.=E2=80=9D] >=20 > leaf max-address-utilization { > type dhc6:threshold; > description > "Maximum amount of the addresses in the > pool which can be simultaneously allocated, > calculated as a percentage of the available > addresses (end-address minus start-address plus > one)."; >=20 > The analogous prefix-allocation node has "rounded up" stated > explicitly. Should we do so here as well? [if - added] >=20 > Section 4.3 >=20 > leaf reply-sent-count { > type uint32; > config "false"; > description > "Number of Reply (7) messages received."; > } > leaf release-received-count { > type uint32; > config "false"; > description > "Number of Release (8) messages sent."; > } > leaf decline-received-count { > type uint32; > config "false"; > description > "Number of Decline (9) messages sent."; >=20 > The descriptions seem out of sync about sent vs received, here. [if - fixed] >=20 > Section 5 >=20 > As the RPCs for deleting/clearing active address and prefix entries > in the server and relay modules are particularly sensitive, these = use > 'nacm:default-deny-all'. >=20 > This looks like a comma splice. [if - Reworded to: The RPCs for deleting/clearing active address and prefix =20 entries in the server and relay modules are particularly =20= sensitive. These RPCs use 'nacm:default-deny-all'. ] >=20 > An attacker with read/write access the DHCPv6 server can undertake > various attacks, such as: > [...] > An attacker with read/write access the DHCPv6 relay can undertake > various attacks, such as: >=20 > s/access/access to/ [if - fixed] >=20 > Some of the readable data nodes in this YANG module may be = considered > sensitive or vulnerable in some network environments. Therefore, it > is important to control read access (e.g., only permitting get, get- > config, or notifications) to these data nodes. These subtrees and >=20 > This doesn't match the template at > https://trac.ietf.org/trac/ops/wiki/yang-security-guidelines , where = the > parenthetical is "(e.g., via get, get-config, or notification)" -- the > meaning is different! [if - Changed to =E2=80=98via=E2=80=99] >=20 > Appendix A.1 >=20 > The 'max-pd-space-utilization' is set to 80 so that a 'prefix-pool- > utilization-threshold-exceeded' notification will be raised if the > number of prefix allocations exceeds this. >=20 > the max-pd-space-utilitization is a percentage, so the "number of = prefix > allocations" needs a unit conversion to be comparable to it. [if - added 'percent' to the description] >=20 > Appendix C >=20 > container lease-storage { > description > "Configures how the server will stores leases."; > choice storage-type { > description > "The type storage that will be used for lease > information."; >=20 > s/type storage/type of storage/ [if - fixed] >=20 > case mysql { > leaf mysql-name { > type string; > description > "Name of the database."; > } > [...] >=20 > This seems to not have provision for configuring mandatory TLS usage = for > connection to the mysql server. > (Same for the postgres case.) [if - I=E2=80=99ve just found draft-ietf-netconf-tls-client-server-26 = which covers this and Would seem to be the right way to do this. However, importing this module and its dependencies and using the = tis-client-grouping for=20 Mysql and Postgres results in the tree diagram growing from 49 lines to 401 with the TLS configuration, which somewhat detracts from the point = of the example. Given that this is provided as an example module for a theoretical = implementation, Would it make more sense to remove the mysql-host choice and add text in The mysql-host configuration description to say that the database must = be running On the localhost? This could be noted in the Appendix descriptive text = as well.] >=20 > leaf mysql-port { > type inet:port-number; > default 5432; >=20 > mysql's registered port seems to be 3306 (5432 is assigned for > postgres). [if - changed] >=20 > Appendix D >=20 > classifying clients. So this standard does not try to provide full > specification for class selection, it only shows an example how it > could be defined. >=20 > s/example/example of/ [if - changed] >=20 > grouping client-class-id { > description > "Definitions of client message classification for > authorization and assignment purposes."; > leaf client-class-name { > type string; > description > "Unique Identifier for client class identification list > entries."; >=20 > Shouldn't this be mandatory if it's going to be the only way we refer = to > class IDs? I guess the grouping is currently only used in one place, > and it's a list key there (so implicitly mandatory), but I still = wonder > if the grouping is more reusable with "mandatory true". [if - Added mandatory true] >=20 > leaf relay-interface { > type string; > description > "Reference to the interface entry for the incoming > DHCPv6 message."; >=20 > Whatever we do in the main module for the encoding of the interface > entry should be reflected here as well. [if - Changed the descriptions to align with the interface-id option = text in the relay module: case relay-interface-id { =20= description =20= "Client class selection based on a received instance of =20= OPTION_INTERFACE_ID (18)."; =20= leaf relay-interface { =20= type string; =20= description =20= "An opaque value of arbitrary length generated by the = =20 relay agent to identify one of the relay agent's =20= interfaces.=E2=80=9D; =20 ] >=20 > leaf vendor-class-data { > type string; > mandatory true; > description > "Vendor class data to match."; >=20 > (likewise) [if - Changed to: container vendor-class-option-data { =20= description =20= "Vendor class option data container."; =20= leaf enterprise-number { =20= type uint32; =20= description =20= "The vendor's registered Enterprise Number as =20= maintained by IANA."; =20= } =20= leaf vendor-class-data-id { =20= type uint8; =20= description =20= "Vendor class data ID"; =20= } =20= leaf vendor-class-data { =20= type string; =20= description =20= "Opaque field for matching the client's vendor class =20= data."; =20= } =20 ] >=20 > leaf remote-id { > type string; > mandatory true; > description > "Remote-ID data to match."; >=20 > (and here) [if - The remote-id option case in the class selction example module was = left over from a previous version of the draft. As remote-id is not defined in RFC8415 it=E2=80=99s no longer modelled = in this doc, so I=E2=80=99ve removed it from the example.] >=20 >=20 >=20 From nobody Thu Jan 20 12:46:52 2022 Return-Path: X-Original-To: dhcwg@ietf.org Delivered-To: dhcwg@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id DB1C93A2076; Thu, 20 Jan 2022 12:46:49 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Acee Lindem via Datatracker To: Cc: dhcwg@ietf.org, draft-ietf-dhc-dhcpv6-yang.all@ietf.org, last-call@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.42.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <164271160981.14773.8936457326359214955@ietfa.amsl.com> Reply-To: Acee Lindem Date: Thu, 20 Jan 2022 12:46:49 -0800 Archived-At: Subject: [dhcwg] Yangdoctors telechat review of draft-ietf-dhc-dhcpv6-yang-24 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.29 List-Id: Dynamic Host Configuration List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jan 2022 20:46:50 -0000 Reviewer: Acee Lindem Review result: Ready with Nits Please fix YANG error: yanglint SO 1.6.7: yanglint --verbose -p {tmplib} -p {rfclib} -p {draftlib} -p {ianalib} -p {cataloglib} {model} -i: warn: File name "ietf-dhcpv6-common@2021-11-18.yang" does not match module revision "2021-10-25". Thank you for fixing the comments from my early review. From nobody Fri Jan 21 05:04:11 2022 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D11B43A1F28 for ; Fri, 21 Jan 2022 05:01:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=qacafe.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W5tN2_9KXQBw for ; Fri, 21 Jan 2022 05:01:02 -0800 (PST) Received: from mail-lj1-x236.google.com (mail-lj1-x236.google.com [IPv6:2a00:1450:4864:20::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4787A3A1F27 for ; Fri, 21 Jan 2022 05:01:01 -0800 (PST) Received: by mail-lj1-x236.google.com with SMTP id q12so53675ljp.9 for ; Fri, 21 Jan 2022 05:01:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=qacafe.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=/rpxPgpLgnnWtETN7AgbQ1BwRcMBEC/EiVuDwGm7qFg=; b=GZl7YNAzk8/9SKsNpFvn2khEPHTqoVknVfR1Hqh8tJmPemfci6CoubZAgvb2QYT69e lgWUspcIdxMBw7YBdAfHJjrPwsfPMIICbwkwj74u87I4bPgnfkujAumOjU1Y/hxeB1c2 ytFIpvYTfvPi3S+h4bT7e0XMg/BU2goO+nxrQ= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=/rpxPgpLgnnWtETN7AgbQ1BwRcMBEC/EiVuDwGm7qFg=; b=TVPEUjRbMTHb1bnmDcQVvgXsL5zad0Lph87gNffrXqeLZzR7v+33drxqrume2aACnX mMUPTWdP9FfAp3pa7SF0khDDW3/Fl2kTFgWo0wgz5aErwzLotmmFg0Z/cR48ftRIoxTG yQI2SZ084d0PAVfbXtA5xjUIOwzIAs5491PnAmrkxzLq+ShoIARR2q6rLdQwKl3YrruJ Y3JIpsXV0IxpduSxj8JEi8kSYSYVrz1vmelK4leIH8Ee4A6C8YLsyvMyKQnuWHhNw9Ub AQcNZZaOmF52wz1yCvn87LboyF3JorLY+w5tO+Me5qDyxg3ikQPOJOMc5oO9o/9tQ+t2 gT+A== X-Gm-Message-State: AOAM533l35zAH5apIcmBxw/cYOx+Dxe7RKRIwH0tiFCIAJKhgIZffyCc 5tI7cwpOnowRTPL2G9MGdv7k95w/Kljn9Bu80CJr1A== X-Google-Smtp-Source: ABdhPJzZhK/eFoRoqTK7fyyniFIFHWsO/+EtwrlYrUYoa8XvdUrUr01pRIeNe7LiSDQDu27DrPA/7aY+eLOFk92Zxk8= X-Received: by 2002:a2e:910b:: with SMTP id m11mr3133233ljg.103.1642770057086; Fri, 21 Jan 2022 05:00:57 -0800 (PST) MIME-Version: 1.0 References: <163952685584.6395.6879611267419166159@ietfa.amsl.com> In-Reply-To: From: Timothy Winters Date: Fri, 21 Jan 2022 08:00:45 -0500 Message-ID: To: ianfarrer@gmx.com Cc: Benjamin Kaduk , The IESG , draft-ietf-dhc-dhcpv6-yang@ietf.org, dhc-chairs@ietf.org, dhcwg Content-Type: multipart/alternative; boundary="000000000000b35c0e05d6173511" Archived-At: X-Mailman-Approved-At: Fri, 21 Jan 2022 05:04:09 -0800 Subject: Re: [dhcwg] Benjamin Kaduk's Discuss on draft-ietf-dhc-dhcpv6-yang-24: (with DISCUSS and COMMENT) X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Dynamic Host Configuration List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jan 2022 13:01:09 -0000 --000000000000b35c0e05d6173511 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Ian, I've responded below anywhere @Bernie/Tim. Thanks for you all your work on this. ~Tim On Mon, Jan 17, 2022 at 12:39 PM wrote: > Hi Benjamin, > > First of all, many thanks for the detailed review and my apologies that > it=E2=80=99s taken so long for me to > reply. > > Please see inline below. > > @Bernie/@Tim, there are a couple of points below that I would appreciate > your input on (specifically, restructuring of the OPTION_AUTH modelling a= nd > the best type for interface-id-option-group and user-class-option-group = to > use). > > Thanks, > Ian > > > > On 15. Dec 2021, at 01:07, Benjamin Kaduk via Datatracker < > noreply@ietf.org> wrote: > > > > Benjamin Kaduk has entered the following ballot position for > > draft-ietf-dhc-dhcpv6-yang-24: Discuss > > > > When responding, please keep the subject line intact and reply to all > > email addresses included in the To and CC lines. (Feel free to cut this > > introductory paragraph, however.) > > > > > > Please refer to > https://www.ietf.org/blog/handling-iesg-ballot-positions/ > > for more information about how to handle DISCUSS and COMMENT positions. > > > > > > The document, along with other ballot positions, can be found here: > > https://datatracker.ietf.org/doc/draft-ietf-dhc-dhcpv6-yang/ > > > > > > > > ---------------------------------------------------------------------- > > DISCUSS: > > ---------------------------------------------------------------------- > > > > Roman's comment touched on a related point, but I'd like to (hopefully > > briefly) discuss the way we encode certain opaque protocol fields. > > There are some places where we clearly intend a hex representation (a > > string with a pattern that's marked out as pairs of hex digits), but > > there are others where we just say "type string" with no indication of > > encoding, and even a "type binary". If we want the specification to > > admit interoperable implementation we need to be more clear about what > > encoding we expect for all of these nodes. I have noted most (possibly > > all, but please double check) in the COMMENT section, with a preference > > for "type binary" where we don't need to apply regex restrictions. But > > that's just a personal preference, and choosing to use hex (or base64, > > or any other well-defined) encoding will suffice to resolve the discuss > > point. > > [if - I=E2=80=99ve changed from type string to binary where-ever possible > throughout according > To the specific comments below. The one exception is for the auth-option, > which > Allows for different formats depending on the auth protocol in use. I=E2= =80=99ve > reworked the > Format of the option to make this explicit.] > > > > > > > ---------------------------------------------------------------------- > > COMMENT: > > ---------------------------------------------------------------------- > > > > Thanks to the shepherd for answering the second part of question (1) in > > the template, as well as the first; this part of the question is often > > missed. (There is, however, a third part as well...) > > > > Section 1.2.1 > > > > Table 1 is described as showing "the DHCPv6 options that are modeled, > > the element(s) they are sent by, and the relevant YANG module name". I= n > > my interpretation that means that: > > > > - the only options that are in the table are ones that are modeled > > - the contents of the table shows which elements send those options > > > > But the contents of the table don't quite seem to match that -- it seem= s > > that they only indicate which nodes have YANG modeling for how to send > > the option, and not indicate nodes that send the option but do not need > > YANG configuration to control how to populate the option. (E.g., > > OPTION_AUTH and OPTION_USER_CLASS.) If this is the intent, then perhap= s > > it's clearer to say "which YANG modules they are modeled for" or > > something similar, rather than "the element(s) they are sent by". > > [if - Changed] > > > > > > Section 3.1 > > > > * address/prefix-pool-utilization-threshold-exceeded: Raised when > > the number of leased addresses or prefixes exceeds the configured > > usage threshold. > > > > The node that seems to be where the "configured usage threshold" is > > configured is scoped to an address pool or prefix pool. Should this > > description say "number of leased [...] in an address pool exceeds the > > configured usage threshold"? > > [if - I=E2=80=99ve changed this to read: > "address/prefix-pool-utilization-threshold-exceeded: Raised when the numb= er > of leased addresses or prefixes in a pool exceeds the configured usage > threshold." > > > > > Section 4.1 > > > > +------+------+----------+--------------+ > > | 0001 | 0006 | 28490058 | 00005E005300 | > > +------+------+----------+--------------+ > > > > This example includes the 2-octet DUID type of 1 (0x01), the > > hardware type is 0x06 (IEEE Hardware Types) the creation > > time is 0x028490058 (constructed as described above). Finally, > > the link-layer address is 0x5E005300 (EUI-48 address > > 00-00-5E-00-53-00)"; > > > > Should there be some more zeros in here (e.g., in the artwork before > > 28490058)? > > [if - The creation time is a 4-octet field, so the artwork is correct. > I=E2=80=99ve > changed the value in the description to 0x28490058] > > > > > typedef duid-en { > > type duid-base { > > pattern '0002' > > + '[0-9a-fA-F]{4,}'; > > } > > description > > "DUID type 2, assigned by vendor based on Enterprise > > Number (DUID-EN). This DUID consists of the 4-octet vendor's > > registered Private Enterprise Number as maintained by IANA > > followed by a unique identifier assigned by the vendor. For > > example: > > > > A 4-octet PEN would be 8 hex digits (the YANG allows as few as 4). > > [if - Changed to 8] > > > > > typedef duid-unstructured { > > type duid-base { > > pattern '(000[1-4].*|.*[^0-9a-fA-F].*)' { > > modifier invert-match; > > } > > } > > > > My understanding is that the "pattern" modifiers from the base type and > > the derived type are "and"-ed together, so the "|.*[^0-9a-fA-F].*" > > clause is redundant with the pattern in the base type and thus not > > needed. > > [if - Changed to > pattern '(000[1-4].*)'] > > > > > container status { > > [...] > > leaf message { > > type string; > > description > > "A UTF-8 encoded text string suitable for display to an > > end user. It MUST NOT be null-terminated."; > > > > (Related to Roman's comment) > > This is probably more of a comment on RFC 8415 than this document, but > > BCP 18 seems pretty clear that a string destined for display to a human > > should be accompanied by a language indicator. > > (This comment probably applies to every "leaf message" but I will just > > mention it this once.) > > [if - I=E2=80=99m not sure how we can handle this as the leaf(s) is only = used for > Holding RO state data which it obtains from the client/relay/server > implementation. As > You mention, RFC8415 does not place any requirements on the message to > contain > a language identifier.] > > > > > grouping auth-option-group { > > [...] > > container auth-option { > > [...] > > leaf auth-information { > > type string; > > description > > "The authentication information, as specified by the > > protocol and algorithm used in this Authentication > > option."; > > > > This should probably be binary, not a string. Or, if it needs to be a > > string, it should specify an encoding (e.g., hex). > > [if - The authentication information format is dependant on the value > Of the protocol field. I=E2=80=99ve re-modelled this option to take this = into > account. > > The configuration-token (RFC3118) does allow for plain text and > specifically > Gives a clear text password as an example use case. > > @Bernie, @Tim, please can you review this an make sure that I=E2=80=99ve > Understood DHCPv6 auth properly? > [tim] - I think it can be any data based on the protocol field. So maybe this should be a binary? > > > > grouping auth-option-group { > description > "OPTION_AUTH (11) Authentication Option."; > reference "RFC 8415: Dynamic Host Configuration Protocol > for IPv6 (DHCPv6), Section 21.11 > RFC 3118: Authentication for DHCP Messages > IANA 'Dynamic Host Configuration Protocol (DHCP) Authentication > Option Name Spaces' registry. > "; > container auth-option { > description > "OPTION_AUTH (11) Authentication Option container."; > leaf algorithm { > type uint8; > description > "The algorithm used in the authentication protocol."; > } > leaf rdm { > type uint8; > description > "The Replay Detection Method (RDM) used in this > Authentication option."; > } > leaf replay-detection { > type uint64; > description > "The replay detection information for the RDM."; > } > choice protocol { > description > "The authentication protocol used in the option. Namespace > values 1 (delayed authentication) and 2 (Delayed > Authentication (Obsolete) are not applicable and so are > not modelled."; > case conf-token { > leaf token-auth-information { > type string; > description > "Protocol Namespace Value 0. The authentication > information, as specified by the protocol and > algorithm used in this Authentication option."; > } > } > case rkap { > description > "Protocol Namespace Value 3. RKAP provides protection > against misconfiguration of a client caused by a Reconfigure > message sent by a malicious DHCP server."; > leaf datatype { > type uint8 { > range "1 .. 2"; > } > description > "Type of data in the Value field carried in this > option. > 1 Reconfigure key value (used in the Reply > message). > 2 HMAC-MD5 digest of the message (used in > the Reconfigure message)."; > } > leaf auth-info-value { > type binary { > length 16; > } > description "Data as defined by the Type field. A 16-octet > field."; > } > } > } > } > } > > ] > > > > > grouping status-code-option-group { > > > > FWIW, this grouping seems unused by the rest of the document. (Perhaps > > a remnant of a decision to move the status information out of the > > options section and into a higher level of the relevant YANG trees?) > > [if - Yes, this was an unused remanent. Removed] > > > > > leaf sub-option-data { > > type string { > > pattern '([0-9a-fA-F]{2}){0,}'; > > } > > description > > "The data area for the sub-option."; > > > > Why does this need to be hex-encoded (vs. YANG binary)? > > And, if it is hex-encoded, we should probably say so explicitly in the > > description. > > [if - Changed to binary] > > > > > Section 4.2 > > > > leaf preferred-lifetime { > > type dhc6:timer-seconds32; > > description > > "Preferred lifetime for the Identity Association (IA)."; > > reference "RFC 8415: Dynamic Host Configuration Protocol for > > IPv6 (DHCPv6), Section 6"; > > > > Is Section 6 really the best section reference for this concept? > > [if - Changed to Section 12.1 (also changed for the valid-lifetime leaf)] > > > > > grouping message-stats { > > > > The relay module has a counter for discarded messages; would a similar > > counter make sense here? (Also for the server module, I think.) > > [if - Added - also for the client module.] > > > > > Also, YANG does have dedicated "counter" types to more precisely > > indicate semantics than just "uint32". They are by definition > > monotonically increasing, though, and are their use is typically > > accompanied by a "last discontinuity time" node to indicate when they > > have been reset. > > [if - Changed to yang:counter32 throughout and added a discontinuity-time > node to server/relay/client modules] > > > > > grouping info-refresh-time-option-group { > > [...] > > leaf info-refresh-time { > > type dhc6:timer-seconds32; > > description > > "Time duration relative to the current time, expressed > > in units of seconds."; > > > > Is this really "relative to the current time" for purposes of the YANG > > module? This is the description that RFC 8415 uses, yes, but that > > refers to the current time when the protocol message is received, and > > YANG interactions may be asynchronous to that. > > [if - Changed to read: > "Time duration specifying an upper bound for how long a > client should wait before refreshing information retrieved > from a DHCP server.=E2=80=9D; ] > > > > > container address-pools { > > [...] > > list address-pool { > > key pool-id; > > [...] > > leaf pool-id { > > type string; > > > > What's the motivation for making the pool-id a string vs the option-set > > and allocation-range lists that have an integer identifier? (Also > > applies to prefix pools.) > > [If - Initially all of the identifiers were integers. The change to strin= g > Specifically for Pool-id was made by =C3=89ric during the AD review. > > Agree that it makes sense to use the same format, so the option-set-id > And allocation-range id are now type string.] > > > > > leaf pool-prefix { > > type inet:ipv6-prefix; > > mandatory true; > > description > > "IPv6 prefix for the pool."; > > > > Does this prefix need to be contained within the overall > > "network-prefix"? (Same question for prefix-pools' pool-prefix.) > > [if - With the DHCP server implementations that I am familiar with, yes i= t > would > need to be contained, but I guess other implementations may not. I=E2=80= =99m not > aware > of any way of enforcing this in the YANG.] > > > > > leaf max-address-utilization { > > type dhc6:threshold; > > description > > "Maximum amount of the addresses in the > > pool which can be simultaneously allocated, > > calculated as a percentage of the available > > addresses (end-address minus start-address plus > > one)."; > > > > Do we want to mention the relationship between this node and the > > "address-pool-utiliziation-threshold-exceeded" notification? I see the > > pointer the other direction, but since we don't use the word "threshold= " > > in the description here I wouldn't mind a more explicit linkage. > > (Likewise for the prefix-allocation case.) > > [if - I=E2=80=99ve updated the description with: > " Used to set the value for the > address-pool-utilization-threshold-exceeded > notification=E2=80=9D; > > And the equivalent change for prefix-allocation.] > > > > > list active-lease { > > key leased-prefix; > > description > > "List of active prefix leases."; > > leaf leased-prefix { > > type inet:ipv6-prefix; > > description > > "Active leased prefix entry."; > > > > Is the prefix length available from some other information in the tree? > > If not, should it be listed here? > > [if I=E2=80=99m not sure I understand the comment. The prefix pool has th= e > =E2=80=98Client-prefix-length=E2=80=99 leaf which defines the length of p= refixes that > are offered for the pd-pool. > > However, client=E2=80=99s may hint that they want a different prefix leng= th in > TOheir pd request and depending on implementation / policy the server > May honour this (for a longer prefix than the defined > client-prefix-length). > RFC8168 discusses this.] > > > > > notification decline-received { > > if-feature na-assignment; > > description > > "Notification sent when the server has received a > > Decline (9) message from a client."; > > > > Is this a potential DoS vector to the notification recipient (if a > > malicious client just starts declining everything)? Should we say > > anything about rate-limiting? > > [if - From the perspective of the YANG module and its implementation, > I don=E2=80=99t think so. The reason is that state/counter data is access= ed via > the YANG > Operational data store and this is only retrieved from the process / > function > Being managed when a NETCONF request Is made for the information, > so that it is as current as possible. > > This is for every YANG module implementation that we\ve done, but I think > this is general best practice.] > > > > > notification non-success-code-sent { > > description > > "Notification sent when the server responded > > to a client with non-success status code."; > > > > (similarly here) > > [if - See above] > > > > > Section 4.3 > > > > grouping interface-id-option-group { > > [...] > > leaf interface-id { > > type string; > > description > > "An opaque value of arbitrary length generated by the > > relay agent to identify one of the relay agent's > > interfaces."; > > > > I think this is better as a YANG "binary" type than a string. If not, > > we should say something about the encoding. > > [if - I=E2=80=99m familiar with the use of this option in Cisco and ALU r= elay > Implementations and both allow clear text configuration of the > value that is carried in this field. > > RFC8415 doesn=E2=80=99t give any specific guidance on whether this > Should be ASCII or can be UTF-8. > > RFC7227 Section 5.8 does state that future options should use UTF-8, > But this option would have been defined before RFC7227 was published. > > @Bernie/@Tim, do you have any guidance on this?] > [tim] - According to RFC 8415 this is an opaque value, therefore it can be anything so I think binary makes sense. > > > > > Section 4.4 > > > > Why do we use "prefix-del" for the feature name in this module but the > > full "prefix-delegation" in the other modules? > > [if - now using prefix-delegation throughout] > > > > > grouping message-statistics { > > > > The relay module has a counter for discarded messages; should we? > > [if - Added] > > > > > grouping option-request-option-group { > > description > > "OPTION_ORO (6) Option Request Option. A client MUST include > > an Option Request option in a Solicit, Request, Renew, > > Rebind, or Information-request message to inform the server > > about options the client wants the server to send to the > > client."; > > > > If I understand correctly, there are further MUST-level requirements fo= r > > what options must be present in the ORO. E.g., INFORMATION_REFRESH_TIM= E > > is required in Information-Request. Do we want to mention that here? > > Are there any considerations for how that requirement interacts with th= e > > values configured by YANG? E.g., do we expect implementations to > > forcibly add those required options on top of the configured ones, in > > scenarios where they are required? > > [if - Description now updated to: > "List of options that the client is requesting, > identified by option code. This list MUST include the > code for option SOL_MAX_RT (82) when included in a > Solicit-message. If this option is being > sent in an Infoformation-request message, then the code > for option OPTION_INFORMATION_REFRESH_TIME (32) and > INF_MAX_RT (83) MUST be included.=E2=80=9D; > > The references also updated for the sections of RFC8415 defining the > requirements.] > > > > > grouping user-class-option-group { > > [...] > > leaf user-class-data { > > type string; > > description > > "Opaque field representing a User Class > > of which the client is a member."; > > > > I think this would be better as YANG binary than string. If we keep it > > as string, we need to say what encoding is used. > > > > > container vendor-class-option { > > [...] > > list vendor-class-option-instances { > > [...] > > list vendor-class-data-element { > > [...] > > leaf vendor-class-data { > > type string; > > description > > "Opaque field representing a vendor class of which > > the client is a member."; > > > > (likewise here) > > [if - IME these are usually a user configurable text string on client / > server implementations. > > I think the same comment for the format as for Section 4.3 > interface-id-option group > Applies here. > > @Bernie/@Tim, any thoughts?] > [tim] - Since anything can be put in this field as a opaque value, I think this a binary for yang model. > > ] > > > > leaf client-duid { > > if-feature "non-temp-addr or prefix-del " + > > "or temp-addr and not anon-profile"; > > > > Does the default YANG operator precedence do what we want with respect > > to ((non-temp-addr or prefix-del or temp-addr) and not anon-profile) vs > > (non-temp-addr or prefix-del or (temp-addr and not anon-profile))? > >> From the context in the rest of the document, it's clear that we want > > the former, but I'm not familiar enough with YANG minutiae to say if > > that's what we actually are specifying. > > [if - Changed to "(non-temp-addr or prefix-delegation or temp-addr) and > not anon-profile=E2=80=9D. > > Per RFC7950, groupings in parentheses are evaluated first, then the =E2= =80=98not' > statement.] > > > > > notification invalid-ia-address-detected { > > if-feature "non-temp-addr or temp-addr"; > > [...] > > leaf ia-id { > > type uint32; > > mandatory true; > > description > > "IA-ID"; > > > > If I understand correctly, in DHCP the IA-ID is scoped per client DUID. > > Does this notification convey enough information to disambiguate what > > scope this IA-ID value belongs to? > > [if - The IA-ID is a 4-octet field which is present in options requesting > an address or prefix (OPTION_IA_NA/IA_TA/IA_PD). > The client will normally have a single DUID for all of it=E2=80=99s reque= sts on > all DHCP > Enabled interfaces, but could make requests for multiple > addresses/prefixes in > each DHCP request. In this case each IA_xA option would have the same > DUID, and a unique IA-ID field so the > Client can associate the allocated address/prefix from the server to the > specific request option.] > > > > > [...] > > leaf ia-na-t1-timer { > > type uint32; > > description > > "The value of the T1 time field for non-temporary address > > allocations (OPTION_IA_NA)."; > > } > > leaf ia-na-t2-timer { > > type uint32; > > description > > "The value of the preferred-lifetime field for non-temporary > > address allocations (OPTION_IA_NA)."; > > > > Should these two be here without a feature conditional? They seem to b= e > > NA-specific but we could send this notification if NA is not > > implemented. > > [if - notification invalid-ia-address-detected has if-feature > non-temp-addr or temp-addr which > Is applicable to all of the nodes defined in the notification. > > The notification can only be triggered if an address is requested and > allocated then found to > Be invalid, e.g. it fails DAD, so this couldn=E2=80=99t happen if the cli= ent > doesn=E2=80=99t implement IA_NA/IA_TA > (And has the relevant feature enabled).] > > > > > notification transmission-failed { > > [...] > > leaf failure-type { > > type enumeration { > > > > (side note?) I get antsy about not leaving an extension point for other > > types of (re)transmission failure, but I also don't have any specific > > scenario in mind that's not already covered, so. > > [if - I think that all of the client message transmission failures can be > boiled down to > =E2=80=98I tried/retried sending this type of message and didn=E2=80=99t = get an answer=E2=80=99 > which is what=E2=80=99s > Covered in the notification. We could add an other/unspecified to the > enum, but I also > Can=E2=80=99t think of what would trigger this.] > > > > > notification unsuccessful-status-code { > > description > > "Notification sent when the client receives a message that > > includes an unsuccessful Status Code option."; > > > > As for the other notifications on failure, is this a potential DoS > > vector? > > [if - I don=E2=80=99t think so. For Netconf notifications, the network ma= nagement > system > Creates a session and subscribes to the notifications from the DHCP clien= t. > If one (or many) DHCP clients were generating too many notifications, the= n > the NMS would > Close the session and stop receiving the DHCP client=E2=80=99s notificati= ons.] > > > > > Section 5 > > > > It's probably worth mentioning the risk of notifications turning into a > > DoS vector (absent rate-limiting) here. > > [if - This is surely a problem with Netconf notifications overall, rather > than specifically > For the DHCP modules? I=E2=80=99ve checked through RFC5277 (Netconf event > notifications) and > There is nothing on rate-limiting messages or in the Security > Considerations section > on this subject.] > > > > > Can a misconfigured client cause problems for a (honest) server, e.g., > > by sending a lot of requests for a lot of things, very quickly? > > [if - I=E2=80=99m sure that it would be possible. RFC8415 only places req= uirements > On clients to limit the rate for messages that they send, but not on a > server > To limit the rate of received messages it will try and process. > > From a little research, I see that some DHCP server implementations have > configuration for this, but others do not. It=E2=80=99s feasible that thi= s could > also be > Done through e.g. ip6tables rules on a host. > > I would see this as being a feature that should be configured (if > available) through the > Implementation specific YANG module or possibly the ACL YANG (RFC8519)] > > > > > All data nodes defined in the YANG modules which can be created, > > modified, and deleted (i.e., config true, which is the default) are > > considered sensitive. Write operations (e.g., edit-config) to these > > data nodes without proper protection can have a negative effect on > > network operations. > > > > Do we want to go further and give some broad treatment of how the > > negative effects would come about (e.g., by disrupting address > > allocation and the routability of addresses/prefixes that clients > > attempt to use)? > > > > An attacker with read/write access the DHCPv6 relay can undertake > > various attacks, such as: > > > > * Modifying the relay's "destination-address" to send messages to a > > rogue DHCPv6 server. > > > > * Deleting information about a client's delegated prefix, causing a > > denial of service attack as traffic will no longer be routed to > > the client. > > > > I'd considering reiterating the "full denial of service" capability > > (which is currently implicit in "send messages to a rouge DHCPv6 server= " > > combined with the list of attacks that a compromised server can > > undertake). > > [if - I=E2=80=99ve updated the examples as follows: > > Server: > > Denial of service attacks, such as disabling the DHCP > server sevice, or removing address/prefix pool > configuration. > > Various attacks based on re-configuring the contents > of DHCPv6 options, leading to several types of security or > privacy threats. For example, changing the address of a > > DNS server supplied in a DHCP option to point > to a rogue server. > > > And for the relay > > Denial of service attacks, based on disabling the > DHCP relay function, or modifying the relay's > "destination-address" to a non-existant address. > > > Modifying the relay's "destination-address" to send > messages to a rogue DHCPv6 server. > > Deleting information about a client's delegated > prefix, causing a denial of service attack as traffic > will no longer be routed to the client. > > ] > > > > > > Some of the readable data nodes in this YANG module may be considered > > sensitive or vulnerable in some network environments. Therefore, it > > is important to control read access (e.g., only permitting get, get- > > config, or notifications) to these data nodes. These subtrees and > > data nodes can be misused to track the activity of a host: > > > > First off, thank you for stating this consideration so clearly. > > > > Second, there may be an additional consideration for read-only access -= - > > knowledge of what pools of addresses are available for allocation might > > facilitate network reconaissance (viz. RFC 7707). > > [if - I=E2=80=99ve added the following text: > > Information about a server's configured address and prefix pools may > be used by an attacker for network reconnaissance [RFC7707]. The > following subtrees and data nodes could be used for this purpose: > > * Information about client address allocation ranges: (dhc6-srv/ > allocation-ranges/allocation-range/address-pools/ address-pool/ > pool-prefix) > > * Information about client prefix allocation ranges: (dhc6-srv/ > > allocation-ranges/allocation-range/prefix-pools/ prefix-pool/pool- > prefix) > ] > > > > > [RFC7824] covers privacy considerations for DHCPv6 and is applicable > > here. > > > > I'd suggest mentioning the RFC 7844 privacy profile as a partial > > mitigation that is sometimes applicable. > > [if - Do you mean that RFC7844 can provide partial mitigation of the serv= er > Privacy issues in RFC7824?] > > > > > Section 9.2 > > > > RFC 8987 is used as in a few YANG reference stanzas, but is not > > mentioned in the preface before the containing YANG module. It could > > arguably be classified as normative based on that usage. > > [if - I=E2=80=99ve added > "The RPCs in the module are taken from requirements defined [RFC8987].=E2= =80=9D > > To the preface before the relay tree diagram. RFC8987 is now normative.] > > > > > Appendix D > > > > case user-class-option-id { > > description > > "Client class selection based on the value of the > > OPTION_USER_CLASS(15) and its user-class-data field."; > > leaf user-class-data { > > type string; > > mandatory true; > > description > > "Value of the enterprise-number field."; > > > > This description doesn't look right. > > [if - Changed to =E2=80=9CUser Class value to match=E2=80=9D] > > > > > NITS > > > > We might check the spelling of "grouping message-stats" (vs "grouping > > message-statistics") across modules. > > [if - now uses =E2=80=98message-statistics=E2=80=99 throughout] > > > > > Section 4.2 > > > > leaf rapid-commit { > > type boolean; > > description > > "When set to 'true', Specifies that the pool supports > > client-server exchanges involving two messages."; > > > > This is in the "grouping resource-config" that may or may not be used > > within a "pool" container. A more generic phrasing might be in order. > > [if - Changed to > "When set to 'true', Specifies that client-server exchanges involving > two messages is supported.=E2=80=9D;] > > > > > grouping sol-max-rt-option-group { > > [...] > > leaf sol-max-rt-value { > > type dhc6:timer-seconds32; > > description > > "sol max rt value"; > > > > That's a pretty sparse description. > > [if - Changed to: > "Maximum Solicit timeout value.=E2=80=9D] > > > > > grouping inf-max-rt-option-group { > > [...] > > leaf inf-max-rt-value { > > type dhc6:timer-seconds32; > > description > > "inf max rt value"; > > > > (ditto) > > [if - Changed to: > "Maximum Information-request timeout value.=E2=80=9D] > > > > > leaf max-address-utilization { > > type dhc6:threshold; > > description > > "Maximum amount of the addresses in the > > pool which can be simultaneously allocated, > > calculated as a percentage of the available > > addresses (end-address minus start-address plus > > one)."; > > > > The analogous prefix-allocation node has "rounded up" stated > > explicitly. Should we do so here as well? > > [if - added] > > > > > Section 4.3 > > > > leaf reply-sent-count { > > type uint32; > > config "false"; > > description > > "Number of Reply (7) messages received."; > > } > > leaf release-received-count { > > type uint32; > > config "false"; > > description > > "Number of Release (8) messages sent."; > > } > > leaf decline-received-count { > > type uint32; > > config "false"; > > description > > "Number of Decline (9) messages sent."; > > > > The descriptions seem out of sync about sent vs received, here. > > [if - fixed] > > > > > Section 5 > > > > As the RPCs for deleting/clearing active address and prefix entries > > in the server and relay modules are particularly sensitive, these use > > 'nacm:default-deny-all'. > > > > This looks like a comma splice. > > [if - Reworded to: > > The RPCs for deleting/clearing active address and prefix > entries in the server and relay modules are particularly > sensitive. These RPCs use 'nacm:default-deny-all'. ] > > > > > An attacker with read/write access the DHCPv6 server can undertake > > various attacks, such as: > > [...] > > An attacker with read/write access the DHCPv6 relay can undertake > > various attacks, such as: > > > > s/access/access to/ > > [if - fixed] > > > > > Some of the readable data nodes in this YANG module may be considered > > sensitive or vulnerable in some network environments. Therefore, it > > is important to control read access (e.g., only permitting get, get- > > config, or notifications) to these data nodes. These subtrees and > > > > This doesn't match the template at > > https://trac.ietf.org/trac/ops/wiki/yang-security-guidelines , where th= e > > parenthetical is "(e.g., via get, get-config, or notification)" -- the > > meaning is different! > > [if - Changed to =E2=80=98via=E2=80=99] > > > > > Appendix A.1 > > > > The 'max-pd-space-utilization' is set to 80 so that a 'prefix-pool- > > utilization-threshold-exceeded' notification will be raised if the > > number of prefix allocations exceeds this. > > > > the max-pd-space-utilitization is a percentage, so the "number of prefi= x > > allocations" needs a unit conversion to be comparable to it. > > [if - added 'percent' to the description] > > > > > Appendix C > > > > container lease-storage { > > description > > "Configures how the server will stores leases."; > > choice storage-type { > > description > > "The type storage that will be used for lease > > information."; > > > > s/type storage/type of storage/ > > [if - fixed] > > > > > case mysql { > > leaf mysql-name { > > type string; > > description > > "Name of the database."; > > } > > [...] > > > > This seems to not have provision for configuring mandatory TLS usage fo= r > > connection to the mysql server. > > (Same for the postgres case.) > > [if - I=E2=80=99ve just found draft-ietf-netconf-tls-client-server-26 whi= ch covers > this and > Would seem to be the right way to do this. > > However, importing this module and its dependencies and using the > tis-client-grouping for > Mysql and Postgres results in the tree diagram growing from 49 lines to > 401 with the TLS configuration, which somewhat detracts from the point of > the example. > > Given that this is provided as an example module for a theoretical > implementation, > Would it make more sense to remove the mysql-host choice and add text in > The mysql-host configuration description to say that the database must be > running > On the localhost? This could be noted in the Appendix descriptive text as > well.] > > > > > leaf mysql-port { > > type inet:port-number; > > default 5432; > > > > mysql's registered port seems to be 3306 (5432 is assigned for > > postgres). > > [if - changed] > > > > > Appendix D > > > > classifying clients. So this standard does not try to provide full > > specification for class selection, it only shows an example how it > > could be defined. > > > > s/example/example of/ > > [if - changed] > > > > > grouping client-class-id { > > description > > "Definitions of client message classification for > > authorization and assignment purposes."; > > leaf client-class-name { > > type string; > > description > > "Unique Identifier for client class identification list > > entries."; > > > > Shouldn't this be mandatory if it's going to be the only way we refer t= o > > class IDs? I guess the grouping is currently only used in one place, > > and it's a list key there (so implicitly mandatory), but I still wonder > > if the grouping is more reusable with "mandatory true". > > [if - Added mandatory true] > > > > > leaf relay-interface { > > type string; > > description > > "Reference to the interface entry for the incoming > > DHCPv6 message."; > > > > Whatever we do in the main module for the encoding of the interface > > entry should be reflected here as well. > > [if - Changed the descriptions to align with the interface-id option text > in the relay module: > > case relay-interface-id { > description > "Client class selection based on a received instance of > OPTION_INTERFACE_ID (18)."; > leaf relay-interface { > type string; > description > "An opaque value of arbitrary length generated by the > relay agent to identify one of the relay agent's > interfaces.=E2=80=9D; > ] > > > > > > leaf vendor-class-data { > > type string; > > mandatory true; > > description > > "Vendor class data to match."; > > > > (likewise) > > [if - Changed to: > > container vendor-class-option-data { > description > "Vendor class option data container."; > leaf enterprise-number { > type uint32; > description > "The vendor's registered Enterprise Number as > maintained by IANA."; > } > leaf vendor-class-data-id { > type uint8; > description > "Vendor class data ID"; > } > leaf vendor-class-data { > type string; > description > "Opaque field for matching the client's vendor class > data."; > } > > ] > > > > > leaf remote-id { > > type string; > > mandatory true; > > description > > "Remote-ID data to match."; > > > > (and here) > > [if - The remote-id option case in the class selction example module was > left over from a previous version of the draft. > As remote-id is not defined in RFC8415 it=E2=80=99s no longer modelled in= this > doc, so I=E2=80=99ve removed it from the example.] > > > > > > > > > --000000000000b35c0e05d6173511 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Ian,

I've respo= nded below anywhere @Bernie/Tim.=C2=A0 Thanks for you all your work on this= .

~Tim

<= div dir=3D"ltr" class=3D"gmail_attr">On Mon, Jan 17, 2022 at 12:39 PM <<= a href=3D"mailto:ianfarrer@gmx.com" target=3D"_blank">ianfarrer@gmx.com= > wrote:
Hi B= enjamin,

First of all, many thanks for the detailed review and my apologies that it= =E2=80=99s taken so long for me to
reply.

Please see inline below.

@Bernie/@Tim, there are a couple of points below that I would appreciate yo= ur input on (specifically, restructuring of the OPTION_AUTH modelling and t= he best type for=C2=A0 interface-id-option-group and user-class-option-grou= p to use).

Thanks,
Ian


> On 15. Dec 2021, at 01:07, Benjamin Kaduk via Datatracker <noreply@ietf.org> wro= te:
>
> Benjamin Kaduk has entered the following ballot position for
> draft-ietf-dhc-dhcpv6-yang-24: Discuss
>
> When responding, please keep the subject line intact and reply to all<= br> > email addresses included in the To and CC lines. (Feel free to cut thi= s
> introductory paragraph, however.)
>
>
> Please refer to https://www.ietf.org/b= log/handling-iesg-ballot-positions/
> for more information about how to handle DISCUSS and COMMENT positions= .
>
>
> The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/dr= aft-ietf-dhc-dhcpv6-yang/
>
>
>
> ----------------------------------------------------------------------=
> DISCUSS:
> ----------------------------------------------------------------------=
>
> Roman's comment touched on a related point, but I'd like to (h= opefully
> briefly) discuss the way we encode certain opaque protocol fields.
> There are some places where we clearly intend a hex representation (a<= br> > string with a pattern that's marked out as pairs of hex digits), b= ut
> there are others where we just say "type string" with no ind= ication of
> encoding, and even a "type binary".=C2=A0 If we want the spe= cification to
> admit interoperable implementation we need to be more clear about what=
> encoding we expect for all of these nodes.=C2=A0 I have noted most (po= ssibly
> all, but please double check) in the COMMENT section, with a preferenc= e
> for "type binary" where we don't need to apply regex res= trictions.=C2=A0 But
> that's just a personal preference, and choosing to use hex (or bas= e64,
> or any other well-defined) encoding will suffice to resolve the discus= s
> point.

[if - I=E2=80=99ve changed from type string to binary where-ever possible t= hroughout according
To the specific comments below. The one exception is for the auth-option, w= hich
Allows for different formats depending on the auth protocol in use. I=E2=80= =99ve reworked the
Format of the option to make this explicit.]

>
>
> ----------------------------------------------------------------------=
> COMMENT:
> ----------------------------------------------------------------------=
>
> Thanks to the shepherd for answering the second part of question (1) i= n
> the template, as well as the first; this part of the question is often=
> missed.=C2=A0 (There is, however, a third part as well...)
>
> Section 1.2.1
>
> Table 1 is described as showing "the DHCPv6 options that are mode= led,
> the element(s) they are sent by, and the relevant YANG module name&quo= t;.=C2=A0 In
> my interpretation that means that:
>
> - the only options that are in the table are ones that are modeled
> - the contents of the table shows which elements send those options >
> But the contents of the table don't quite seem to match that -- it= seems
> that they only indicate which nodes have YANG modeling for how to send=
> the option, and not indicate nodes that send the option but do not nee= d
> YANG configuration to control how to populate the option.=C2=A0 (E.g.,=
> OPTION_AUTH and OPTION_USER_CLASS.)=C2=A0 If this is the intent, then = perhaps
> it's clearer to say "which YANG modules they are modeled for&= quot; or
> something similar, rather than "the element(s) they are sent by&q= uot;.

[if - Changed]


>
> Section 3.1
>
>=C2=A0 =C2=A0*=C2=A0 address/prefix-pool-utilization-threshold-exceeded= : Raised when
>=C2=A0 =C2=A0 =C2=A0 the number of leased addresses or prefixes exceeds= the configured
>=C2=A0 =C2=A0 =C2=A0 usage threshold.
>
> The node that seems to be where the "configured usage threshold&q= uot; is
> configured is scoped to an address pool or prefix pool.=C2=A0 Should t= his
> description say "number of leased [...] in an address pool exceed= s the
> configured usage threshold"?

[if - I=E2=80=99ve changed this to read:
"address/prefix-pool-utilization-threshold-exceeded: Raised when the n= umber
of leased addresses or prefixes in a pool exceeds the configured usage thre= shold."

>
> Section 4.1
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+------+------+----------+-----------= ---+
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| 0001 | 0006 | 28490058 | 00005E0053= 00 |
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+------+------+----------+-----------= ---+
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0This example includes the 2-octet DUI= D type of 1 (0x01), the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0hardware type is 0x06 (IEEE Hardware = Types) the creation
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0time is 0x028490058 (constructed as d= escribed above). Finally,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0the link-layer address is 0x5E005300 = (EUI-48 address
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A000-00-5E-00-53-00)";
>
> Should there be some more zeros in here (e.g., in the artwork before > 28490058)?

[if - The creation time is a 4-octet field, so the artwork is correct. I=E2= =80=99ve
changed the value in the description to 0x28490058]

>
>=C2=A0 =C2=A0 =C2=A0typedef duid-en {
>=C2=A0 =C2=A0 =C2=A0 =C2=A0type duid-base {
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0pattern '0002'
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+ '[0-9a-fA-F]{4,}'; >=C2=A0 =C2=A0 =C2=A0 =C2=A0}
>=C2=A0 =C2=A0 =C2=A0 =C2=A0description
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"DUID type 2, assigned by vendor= based on Enterprise
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Number (DUID-EN). This DUID consists = of the 4-octet vendor's
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0registered Private Enterprise Number = as maintained by IANA
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0followed by a unique identifier assig= ned by the vendor. For
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0example:
>
> A 4-octet PEN would be 8 hex digits (the YANG allows as few as 4).

[if - Changed to 8]

>
>=C2=A0 =C2=A0 =C2=A0typedef duid-unstructured {
>=C2=A0 =C2=A0 =C2=A0 =C2=A0type duid-base {
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0pattern '(000[1-4].*|.*[^0-9a-fA-= F].*)' {
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0modifier invert-match;
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0}
>=C2=A0 =C2=A0 =C2=A0 =C2=A0}
>
> My understanding is that the "pattern" modifiers from the ba= se type and
> the derived type are "and"-ed together, so the "|.*[^0-= 9a-fA-F].*"
> clause is redundant with the pattern in the base type and thus not
> needed.

[if - Changed to
pattern '(000[1-4].*)']

>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0container status {
>=C2=A0 =C2=A0 =C2=A0 =C2=A0[...]
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0leaf message {
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0type string;
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0description
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"A UTF-8 encoded t= ext string suitable for display to an
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0end user. It MUST NOT b= e null-terminated.";
>
> (Related to Roman's comment)
> This is probably more of a comment on RFC 8415 than this document, but=
> BCP 18 seems pretty clear that a string destined for display to a huma= n
> should be accompanied by a language indicator.
> (This comment probably applies to every "leaf message" but I= will just
> mention it this once.)

[if - I=E2=80=99m not sure how we can handle this as the leaf(s) is only us= ed for
Holding RO state data which it obtains from the client/relay/server impleme= ntation. As
You mention, RFC8415 does not place any requirements on the message to cont= ain
a language identifier.]

>
>=C2=A0 =C2=A0 =C2=A0grouping auth-option-group {
>=C2=A0 =C2=A0 =C2=A0[...]
>=C2=A0 =C2=A0 =C2=A0 =C2=A0container auth-option {
>=C2=A0 =C2=A0 =C2=A0 =C2=A0[...]
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0leaf auth-information {
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0type string;
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0description
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"The authenticatio= n information, as specified by the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0protocol and algorithm = used in this Authentication
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0option.";
>
> This should probably be binary, not a string.=C2=A0 Or, if it needs to= be a
> string, it should specify an encoding (e.g., hex).

[if - The authentication information format is dependant on the value
Of the protocol field. I=E2=80=99ve re-modelled this option to take this in= to account.

The configuration-token (RFC3118) does allow for plain text and specificall= y
Gives a clear text password as an example use case.

@Bernie, @Tim, please can you review this an make sure that I=E2=80=99ve Understood DHCPv6 auth properly?
[tim] - I think it ca= n be any data based on the protocol field.=C2=A0 So maybe this should be a = binary?



=C2=A0 grouping auth-option-group {=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0
=C2=A0 =C2=A0 description=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0
=C2=A0 =C2=A0 =C2=A0 "OPTION_AUTH (11) Authentication Option.";= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0
=C2=A0 =C2=A0 reference "RFC 8415: Dynamic Host Configuration Protocol= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0
=C2=A0 =C2=A0 =C2=A0 for IPv6 (DHCPv6), Section 21.11=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0
=C2=A0 =C2=A0 =C2=A0 RFC 3118: Authentication for DHCP Messages=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0
=C2=A0 =C2=A0 =C2=A0 IANA 'Dynamic Host Configuration Protocol (DHCP) A= uthentication=C2=A0 =C2=A0
=C2=A0 =C2=A0 =C2=A0 Option Name Spaces' registry.=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0
=C2=A0 =C2=A0 =C2=A0 <https://www.iana.org/assign= ments/auth-namespaces>";=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0
=C2=A0 =C2=A0 container auth-option {=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0
=C2=A0 =C2=A0 =C2=A0 description=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0
=C2=A0 =C2=A0 =C2=A0 =C2=A0 "OPTION_AUTH (11) Authentication Option co= ntainer.";=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0
=C2=A0 =C2=A0 =C2=A0 leaf algorithm {=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0
=C2=A0 =C2=A0 =C2=A0 =C2=A0 type uint8;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0
=C2=A0 =C2=A0 =C2=A0 =C2=A0 description=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "The algorithm used in the authenti= cation protocol.";=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0
=C2=A0 =C2=A0 =C2=A0 }=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0
=C2=A0 =C2=A0 =C2=A0 leaf rdm {=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0
=C2=A0 =C2=A0 =C2=A0 =C2=A0 type uint8;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0
=C2=A0 =C2=A0 =C2=A0 =C2=A0 description=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "The Replay Detection Method (RDM) = used in this=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Authentication option.";=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0
=C2=A0 =C2=A0 =C2=A0 }=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0
=C2=A0 =C2=A0 =C2=A0 leaf replay-detection {=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0
=C2=A0 =C2=A0 =C2=A0 =C2=A0 type uint64;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <= br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 description=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "The replay detection information f= or the RDM.";=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0
=C2=A0 =C2=A0 =C2=A0 }=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0
=C2=A0 =C2=A0 =C2=A0 choice protocol {=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <= br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 description=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "The authentication protocol used i= n the option. Namespace=C2=A0 =C2=A0
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 values 1 (delayed authentication) and 2 = (Delayed=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Authentication (Obsolete) are not applic= able and so are=C2=A0 =C2=A0 =C2=A0 =C2=A0
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 not modelled.";=C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 case conf-token {=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 leaf token-auth-information {=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 type string;=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <= br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 description=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "Protocol Namespace Value 0.= The authentication=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 information, as specified by the = protocol and=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 algorithm used in this Authentica= tion option.";=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 }=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0
=C2=A0 =C2=A0 =C2=A0 =C2=A0 }=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0
=C2=A0 =C2=A0 =C2=A0 case rkap {=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0
=C2=A0 =C2=A0 =C2=A0 =C2=A0 description=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "Protocol Namespace Value 3. RKAP p= rovides protection=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 against misconfiguration of a client cau= sed by a Reconfigure=C2=A0
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 message sent by a malicious DHCP server.= ";=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 leaf datatype {=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 type uint8 {=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <= br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 range "1 .. 2";= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 }=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 description=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "Type of data in the = Value field carried in this=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 option.=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 1=C2=A0 Reconfigure= key value (used in the Reply=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0messag= e).=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 2=C2=A0 HMAC-MD5 di= gest of the message (used in=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0the Re= configure message).";=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 }=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 leaf auth-info-value {=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 type binary {=C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 length 16;=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 }=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 description "Data as defined by the= Type field.=C2=A0 A 16-octet=C2=A0 =C2=A0
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 field.";=C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 }=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0
=C2=A0 =C2=A0 =C2=A0 =C2=A0 }=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0
=C2=A0 =C2=A0 =C2=A0 }=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0
=C2=A0 =C2=A0 }=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0
=C2=A0 }

]

>
>=C2=A0 =C2=A0 =C2=A0grouping status-code-option-group {
>
> FWIW, this grouping seems unused by the rest of the document.=C2=A0 (P= erhaps
> a remnant of a decision to move the status information out of the
> options section and into a higher level of the relevant YANG trees?)
[if - Yes, this was an unused remanent. Removed]

>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0leaf sub-option-data {<= br> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0type string { >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0pattern &= #39;([0-9a-fA-F]{2}){0,}';
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0}
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0description
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"The= data area for the sub-option.";
>
> Why does this need to be hex-encoded (vs. YANG binary)?
> And, if it is hex-encoded, we should probably say so explicitly in the=
> description.

[if - Changed to binary]

>
> Section 4.2
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0leaf preferred-lifetime {
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0type dhc6:timer-seconds32;
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0description
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"Preferred lifetime for t= he Identity Association (IA).";
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0reference "RFC 8415: Dynamic Hos= t Configuration Protocol for
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0IPv6 (DHCPv6), Section 6"= ;
>
> Is Section 6 really the best section reference for this concept?

[if - Changed to Section 12.1 (also changed for the valid-lifetime leaf)]
>
>=C2=A0 =C2=A0 =C2=A0grouping message-stats {
>
> The relay module has a counter for discarded messages; would a similar=
> counter make sense here?=C2=A0 (Also for the server module, I think.)<= br>
[if - Added - also for the client module.]

>
> Also, YANG does have dedicated "counter" types to more preci= sely
> indicate semantics than just "uint32".=C2=A0 They are by def= inition
> monotonically increasing, though, and are their use is typically
> accompanied by a "last discontinuity time" node to indicate = when they
> have been reset.

[if - Changed to yang:counter32 throughout and added a discontinuity-time n= ode to server/relay/client modules]

>
>=C2=A0 =C2=A0 =C2=A0grouping info-refresh-time-option-group {
>=C2=A0 =C2=A0 =C2=A0 =C2=A0[...]
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0leaf info-refresh-time {
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0type dhc6:timer-seconds32;
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0description
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"Time duration rel= ative to the current time, expressed
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0in units of seconds.&qu= ot;;
>
> Is this really "relative to the current time" for purposes o= f the YANG
> module?=C2=A0 This is the description that RFC 8415 uses, yes, but tha= t
> refers to the current time when the protocol message is received, and<= br> > YANG interactions may be asynchronous to that.

[if - Changed to read:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "Time duration specifying an upper = bound for how long a=C2=A0 =C2=A0 =C2=A0 =C2=A0
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 client should wait before refreshing inf= ormation retrieved=C2=A0 =C2=A0
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 from a DHCP server.=E2=80=9D;=C2=A0 ]
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0container address-pools {
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0[...]
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0list address-pool {
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0key pool-id;
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0[...]
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0leaf pool-id { >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0type stri= ng;
>
> What's the motivation for making the pool-id a string vs the optio= n-set
> and allocation-range lists that have an integer identifier?=C2=A0 (Als= o
> applies to prefix pools.)

[If - Initially all of the identifiers were integers. The change to string =
Specifically for Pool-id was made by =C3=89ric during the AD review.

Agree that it makes sense to use the same format, so the option-set-id
And allocation-range id are now type string.]

>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0leaf pool-prefix= {
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0type inet= :ipv6-prefix;
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0mandatory= true;
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0descripti= on
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0&q= uot;IPv6 prefix for the pool.";
>
> Does this prefix need to be contained within the overall
> "network-prefix"?=C2=A0 (Same question for prefix-pools'= pool-prefix.)

[if - With the DHCP server implementations that I am familiar with, yes it = would
need to be contained, but I guess other implementations may not. I=E2=80=99= m not aware
of any way of enforcing this in the YANG.]

>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0leaf max-address= -utilization {
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0type dhc6= :threshold;
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0descripti= on
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0&q= uot;Maximum amount of the addresses in the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0po= ol which can be simultaneously allocated,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0ca= lculated as a percentage of the available
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0ad= dresses (end-address minus start-address plus
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0on= e).";
>
> Do we want to mention the relationship between this node and the
> "address-pool-utiliziation-threshold-exceeded" notification?= =C2=A0 I see the
> pointer the other direction, but since we don't use the word "= ;threshold"
> in the description here I wouldn't mind a more explicit linkage. > (Likewise for the prefix-allocation case.)

[if - I=E2=80=99ve updated the description with:
" Used to set the value for the address-pool-utilization-threshold-exc= eeded=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0
=C2=A0notification=E2=80=9D;

And the equivalent change for prefix-allocation.]

>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0list acti= ve-lease {
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0ke= y leased-prefix;
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0de= scription
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0"List of active prefix leases.";
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0le= af leased-prefix {
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0type inet:ipv6-prefix;
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0description
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0"Active leased prefix entry.";
>
> Is the prefix length available from some other information in the tree= ?
> If not, should it be listed here?

[if I=E2=80=99m not sure I understand the comment. The prefix pool has the =
=E2=80=98Client-prefix-length=E2=80=99 leaf which defines the length of pre= fixes that
are offered for the pd-pool.

However, client=E2=80=99s may hint that they want a different prefix length= in
TOheir pd request and depending on implementation / policy the server
May honour this (for a longer prefix than the defined client-prefix-length)= .
RFC8168 discusses this.]

>
>=C2=A0 =C2=A0 =C2=A0notification decline-received {
>=C2=A0 =C2=A0 =C2=A0 =C2=A0if-feature na-assignment;
>=C2=A0 =C2=A0 =C2=A0 =C2=A0description
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"Notification sent when the serv= er has received a
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Decline (9) message from a client.&qu= ot;;
>
> Is this a potential DoS vector to the notification recipient (if a
> malicious client just starts declining everything)?=C2=A0 Should we sa= y
> anything about rate-limiting?

[if - From the perspective of the YANG module and its implementation,
I don=E2=80=99t think so. The reason is that state/counter data is accessed= via the YANG
Operational data store and this is only retrieved from the process / functi= on
Being managed when a NETCONF request Is made for the information,
so that it is as current as possible.

This is for every YANG module implementation that we\ve done, but I think this is general best practice.]

>
>=C2=A0 =C2=A0 =C2=A0notification non-success-code-sent {
>=C2=A0 =C2=A0 =C2=A0 =C2=A0description
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"Notification sent when the serv= er responded
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0to a client with non-success status c= ode.";
>
> (similarly here)

[if - See above]

>
> Section 4.3
>
>=C2=A0 =C2=A0 =C2=A0grouping interface-id-option-group {
>=C2=A0 =C2=A0 =C2=A0 =C2=A0[...]
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 leaf interface-id {
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0type string;
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0description
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"An opaque value o= f arbitrary length generated by the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0relay agent to identify= one of the relay agent's
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0interfaces.";
>
> I think this is better as a YANG "binary" type than a string= .=C2=A0 If not,
> we should say something about the encoding.

[if - I=E2=80=99m familiar with the use of this option in Cisco and ALU rel= ay
Implementations and both allow clear text configuration of the
value that is carried in this field.

RFC8415 doesn=E2=80=99t give any specific guidance on whether this
Should be ASCII or can be UTF-8.

RFC7227 Section 5.8 does state that future options should use UTF-8,
But this option would have been defined before RFC7227 was published.

@Bernie/@Tim, do you have any guidance on this?]
[tim]= -=C2=A0 According to RFC 8415 this is an opaque value, therefore it can be= anything so I think binary makes sense.

>
> Section 4.4
>
> Why do we use "prefix-del" for the feature name in this modu= le but the
> full "prefix-delegation" in the other modules?

[if - now using prefix-delegation throughout]

>
>=C2=A0 =C2=A0 =C2=A0grouping message-statistics {
>
> The relay module has a counter for discarded messages; should we?

[if - Added]

>
>=C2=A0 =C2=A0 =C2=A0grouping option-request-option-group {
>=C2=A0 =C2=A0 =C2=A0 =C2=A0description
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"OPTION_ORO (6) Option Request O= ption. A client MUST include
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0an Option Request option in a Solicit= , Request, Renew,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Rebind, or Information-reques= t message to inform the server
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 about options the clie= nt wants the server to send to the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 client.";
>
> If I understand correctly, there are further MUST-level requirements f= or
> what options must be present in the ORO.=C2=A0 E.g., INFORMATION_REFRE= SH_TIME
> is required in Information-Request.=C2=A0 Do we want to mention that h= ere?
> Are there any considerations for how that requirement interacts with t= he
> values configured by YANG?=C2=A0 E.g., do we expect implementations to=
> forcibly add those required options on top of the configured ones, in<= br> > scenarios where they are required?

[if - Description now updated to:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "List of options that the client is= requesting,=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 identified by option code. This list MUS= T include the=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 code for option SOL_MAX_RT (82) when inc= luded in a=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Solicit-message. If this option is being= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 sent in an Infoformation-request message= , then the code=C2=A0 =C2=A0 =C2=A0 =C2=A0
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 for option OPTION_INFORMATION_REFRESH_TI= ME (32) and=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 INF_MAX_RT (83) MUST be included.=E2=80= =9D;=C2=A0

The references also updated for the sections of RFC8415 defining the requir= ements.]

>
>=C2=A0 =C2=A0 =C2=A0grouping user-class-option-group {
>=C2=A0 =C2=A0 =C2=A0 =C2=A0[...]
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0leaf user-class-data {
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0type string;
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0description
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"Opaque fie= ld representing a User Class
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0of which the cli= ent is a member.";
>
> I think this would be better as YANG binary than string.=C2=A0 If we k= eep it
> as string, we need to say what encoding is used.

>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0container vendor-class-option {
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0[...]
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0list vendor-class-option-instances {<= br> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0[...]
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0list vendor-class-data-element= {
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 [...]
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0leaf vendor-class-data = {
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0type string;
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0description
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"Opa= que field representing a vendor class of which
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0the clien= t is a member.";
>
> (likewise here)

[if - IME these are usually a user configurable text string on client / ser= ver implementations.

I think the same comment for the format as for Section 4.3 interface-id-opt= ion group
Applies here.

@Bernie/@Tim, any thoughts?]
[tim] - Since anything ca= n be put in this field as a opaque value, I think this a binary for yang mo= del.=C2=A0

]
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0leaf client-duid {
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0if-feature "non-temp-addr or pre= fix-del " +
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"or temp-addr and not ano= n-profile";
>
> Does the default YANG operator precedence do what we want with respect=
> to ((non-temp-addr or prefix-del or temp-addr) and not anon-profile) v= s
> (non-temp-addr or prefix-del or (temp-addr and not anon-profile))?
>> From the context in the rest of the document, it's clear that = we want
> the former, but I'm not familiar enough with YANG minutiae to say = if
> that's what we actually are specifying.

[if - Changed to "(non-temp-addr or prefix-delegation or temp-addr) an= d not anon-profile=E2=80=9D.

Per RFC7950, groupings in parentheses are evaluated first, then the =E2=80= =98not' statement.]

>
>=C2=A0 =C2=A0 =C2=A0notification invalid-ia-address-detected {
>=C2=A0 =C2=A0 =C2=A0 =C2=A0if-feature "non-temp-addr or temp-addr&= quot;;
>=C2=A0 =C2=A0 =C2=A0 =C2=A0[...]
>=C2=A0 =C2=A0 =C2=A0 =C2=A0leaf ia-id {
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0type uint32;
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0mandatory true;
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0description
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"IA-ID";
>
> If I understand correctly, in DHCP the IA-ID is scoped per client DUID= .
> Does this notification convey enough information to disambiguate what<= br> > scope this IA-ID value belongs to?

[if - The IA-ID is a 4-octet field which is present in options requesting a= n address or prefix (OPTION_IA_NA/IA_TA/IA_PD).
The client will normally have a single DUID for all of it=E2=80=99s request= s on all DHCP
Enabled interfaces, but could make requests for multiple addresses/prefixes= in
each DHCP request. In this case each IA_xA option would have the same DUID,= and a unique IA-ID field so the
Client can associate the allocated address/prefix from the server to the sp= ecific request option.]

>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0[...]
>=C2=A0 =C2=A0 =C2=A0 =C2=A0leaf ia-na-t1-timer {
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0type uint32;
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0description
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"The value of the T1 time= field for non-temporary address
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0allocations (OPTION_IA_NA).&qu= ot;;
>=C2=A0 =C2=A0 =C2=A0 =C2=A0}
>=C2=A0 =C2=A0 =C2=A0 =C2=A0leaf ia-na-t2-timer {
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0type uint32;
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0description
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"The value of the preferr= ed-lifetime field for non-temporary
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0address allocations (OPTION_IA= _NA).";
>
> Should these two be here without a feature conditional?=C2=A0 They see= m to be
> NA-specific but we could send this notification if NA is not
> implemented.

[if - notification invalid-ia-address-detected has if-feature non-temp-addr= or temp-addr which
Is applicable to all of the nodes defined in the notification.

The notification can only be triggered if an address is requested and alloc= ated then found to
Be invalid, e.g. it fails DAD, so this couldn=E2=80=99t happen if the clien= t doesn=E2=80=99t implement IA_NA/IA_TA
(And has the relevant feature enabled).]

>
>=C2=A0 =C2=A0 =C2=A0notification transmission-failed {
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0[...]
>=C2=A0 =C2=A0 =C2=A0 =C2=A0leaf failure-type {
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0type enumeration {
>
> (side note?) I get antsy about not leaving an extension point for othe= r
> types of (re)transmission failure, but I also don't have any speci= fic
> scenario in mind that's not already covered, so.

[if - I think that all of the client message transmission failures can be b= oiled down to
=E2=80=98I tried/retried sending this type of message and didn=E2=80=99t ge= t an answer=E2=80=99 which is what=E2=80=99s
Covered in the notification. We could add an other/unspecified to the enum,= but I also
Can=E2=80=99t think of what would trigger this.]

>
>=C2=A0 =C2=A0 =C2=A0notification unsuccessful-status-code {
>=C2=A0 =C2=A0 =C2=A0 =C2=A0description
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"Notification sent when the clie= nt receives a message that
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0includes an unsuccessful Status Code = option.";
>
> As for the other notifications on failure, is this a potential DoS
> vector?

[if - I don=E2=80=99t think so. For Netconf notifications, the network mana= gement system
Creates a session and subscribes to the notifications from the DHCP client.=
If one (or many) DHCP clients were generating too many notifications, then = the NMS would
Close the session and stop receiving the DHCP client=E2=80=99s notification= s.]

>
> Section 5
>
> It's probably worth mentioning the risk of notifications turning i= nto a
> DoS vector (absent rate-limiting) here.

[if - This is surely a problem with Netconf notifications overall, rather t= han specifically
For the DHCP modules? I=E2=80=99ve checked through RFC5277 (Netconf event n= otifications) and
There is nothing on rate-limiting messages or in the Security Consideration= s section
on this subject.]

>
> Can a misconfigured client cause problems for a (honest) server, e.g.,=
> by sending a lot of requests for a lot of things, very quickly?

[if - I=E2=80=99m sure that it would be possible. RFC8415 only places requi= rements
On clients to limit the rate for messages that they send, but not on a serv= er
To limit the rate of received messages it will try and process.

>From a little research, I see that some DHCP server implementations have configuration for this, but others do not. It=E2=80=99s feasible that this = could also be
Done through e.g. ip6tables rules on a host.

I would see this as being a feature that should be configured (if available= ) through the
Implementation specific YANG module or possibly the ACL YANG (RFC8519)]

>
>=C2=A0 =C2=A0All data nodes defined in the YANG modules which can be cr= eated,
>=C2=A0 =C2=A0modified, and deleted (i.e., config true, which is the def= ault) are
>=C2=A0 =C2=A0considered sensitive.=C2=A0 Write operations (e.g., edit-c= onfig) to these
>=C2=A0 =C2=A0data nodes without proper protection can have a negative e= ffect on
>=C2=A0 =C2=A0network operations.
>
> Do we want to go further and give some broad treatment of how the
> negative effects would come about (e.g., by disrupting address
> allocation and the routability of addresses/prefixes that clients
> attempt to use)?
>
>=C2=A0 =C2=A0An attacker with read/write access the DHCPv6 relay can un= dertake
>=C2=A0 =C2=A0various attacks, such as:
>
>=C2=A0 =C2=A0*=C2=A0 Modifying the relay's "destination-addres= s" to send messages to a
>=C2=A0 =C2=A0 =C2=A0 rogue DHCPv6 server.
>
>=C2=A0 =C2=A0*=C2=A0 Deleting information about a client's delegate= d prefix, causing a
>=C2=A0 =C2=A0 =C2=A0 denial of service attack as traffic will no longer= be routed to
>=C2=A0 =C2=A0 =C2=A0 the client.
>
> I'd considering reiterating the "full denial of service"= capability
> (which is currently implicit in "send messages to a rouge DHCPv6 = server"
> combined with the list of attacks that a compromised server can
> undertake).

[if - I=E2=80=99ve updated the examples as follows:

Server:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Denial of service attacks, such as disabling th= e DHCP=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 server sevice, or removing address/prefi= x pool=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 configuration.=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Various attacks based on re-configuring the con= tents=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 of DHCPv6 options, leading to several ty= pes of security or=C2=A0 =C2=A0
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 privacy threats.=C2=A0 For example, chan= ging the address of a=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 DNS server supplied in a DHCP option to = point=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 to a rogue server.=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0


And for the relay

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Denial of service attacks, based on disabling t= he=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 DHCP relay function, or modifying the re= lay's=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "destination-address" to a non= -existant address.=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Modifying the relay's "destination-add= ress" to send=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 messages to a rogue DHCPv6 server.=C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Deleting information about a client's deleg= ated=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 prefix, causing a denial of service atta= ck as traffic=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 will no longer be routed to the client.= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0

]


>
>=C2=A0 =C2=A0Some of the readable data nodes in this YANG module may be= considered
>=C2=A0 =C2=A0sensitive or vulnerable in some network environments.=C2= =A0 Therefore, it
>=C2=A0 =C2=A0is important to control read access (e.g., only permitting= get, get-
>=C2=A0 =C2=A0config, or notifications) to these data nodes.=C2=A0 These= subtrees and
>=C2=A0 =C2=A0data nodes can be misused to track the activity of a host:=
>
> First off, thank you for stating this consideration so clearly.
>
> Second, there may be an additional consideration for read-only access = --
> knowledge of what pools of addresses are available for allocation migh= t
> facilitate network reconaissance (viz. RFC 7707).

[if - I=E2=80=99ve added the following text:

=C2=A0 =C2=A0Information about a server's configured address and prefix= pools may=C2=A0
=C2=A0 =C2=A0be used by an attacker for network reconnaissance [RFC7707].= =C2=A0 The=C2=A0 =C2=A0
=C2=A0 =C2=A0following subtrees and data nodes could be used for this purpo= se:=C2=A0 =C2=A0

=C2=A0 =C2=A0*=C2=A0 Information about client address allocation ranges: (d= hc6-srv/=C2=A0 =C2=A0
=C2=A0 =C2=A0 =C2=A0 allocation-ranges/allocation-range/address-pools/ addr= ess-pool/=C2=A0 =C2=A0
=C2=A0 =C2=A0 =C2=A0 pool-prefix)=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0

=C2=A0 =C2=A0*=C2=A0 Information about client prefix allocation ranges: (dh= c6-srv/=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0
=C2=A0 =C2=A0 =C2=A0 allocation-ranges/allocation-range/prefix-pools/ prefi= x-pool/pool-
=C2=A0 =C2=A0 =C2=A0 prefix)=C2=A0 =C2=A0
]

>
>=C2=A0 =C2=A0[RFC7824] covers privacy considerations for DHCPv6 and is = applicable
>=C2=A0 =C2=A0here.
>
> I'd suggest mentioning the RFC 7844 privacy profile as a partial > mitigation that is sometimes applicable.

[if - Do you mean that RFC7844 can provide partial mitigation of the server=
Privacy issues in RFC7824?]

>
> Section 9.2
>
> RFC 8987 is used as in a few YANG reference stanzas, but is not
> mentioned in the preface before the containing YANG module.=C2=A0 It c= ould
> arguably be classified as normative based on that usage.

[if - I=E2=80=99ve added
"The RPCs in the module are taken from requirements defined [RFC8987].= =E2=80=9D

To the preface before the relay tree diagram. RFC8987 is now normative.]
>
> Appendix D
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0case user-class-option-id {
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0description
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"Client class sele= ction based on the value of the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0OPTION_USER_CLASS(15) a= nd its user-class-data field.";
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0leaf user-class-data {
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0type string;
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0mandatory true;
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0description
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"Value of t= he enterprise-number field.";
>
> This description doesn't look right.

[if - Changed to =E2=80=9CUser Class value to match=E2=80=9D]

>
> NITS
>
> We might check the spelling of "grouping message-stats" (vs = "grouping
> message-statistics") across modules.

[if - now uses =E2=80=98message-statistics=E2=80=99 throughout]

>
> Section 4.2
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0leaf rapid-commit {
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0type boolean;
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0description
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"When set to 'true= 9;, Specifies that the pool supports
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0client-server exchanges involv= ing two messages.";
>
> This is in the "grouping resource-config" that may or may no= t be used
> within a "pool" container.=C2=A0 A more generic phrasing mig= ht be in order.

[if - Changed to
"When set to 'true', Specifies that client-server exchanges in= volving
two messages is supported.=E2=80=9D;]

>
>=C2=A0 =C2=A0 =C2=A0grouping sol-max-rt-option-group {
>=C2=A0 =C2=A0 =C2=A0 =C2=A0[...]
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0leaf sol-max-rt-value {
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0type dhc6:timer-seconds32;
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0description
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"sol max rt value&= quot;;
>
> That's a pretty sparse description.

[if - Changed to:
"Maximum Solicit timeout value.=E2=80=9D]

>
>=C2=A0 =C2=A0 =C2=A0grouping inf-max-rt-option-group {
>=C2=A0 =C2=A0 =C2=A0 =C2=A0[...]
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0leaf inf-max-rt-value {
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0type dhc6:timer-seconds32;
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0description
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"inf max rt value&= quot;;
>
> (ditto)

[if - Changed to:
"Maximum Information-request timeout value.=E2=80=9D]

>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0leaf max-address= -utilization {
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0type dhc6= :threshold;
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0descripti= on
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0&q= uot;Maximum amount of the addresses in the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0po= ol which can be simultaneously allocated,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0ca= lculated as a percentage of the available
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0ad= dresses (end-address minus start-address plus
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0on= e).";
>
> The analogous prefix-allocation node has "rounded up" stated=
> explicitly.=C2=A0 Should we do so here as well?

[if - added]

>
> Section 4.3
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0leaf reply-sent-count {
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0type uint32;
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0config "false";
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0description
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"Number of Reply (7) mess= ages received.";
>=C2=A0 =C2=A0 =C2=A0 =C2=A0}
>=C2=A0 =C2=A0 =C2=A0 =C2=A0leaf release-received-count {
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0type uint32;
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0config "false";
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0description
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"Number of Release (8) me= ssages sent.";
>=C2=A0 =C2=A0 =C2=A0 =C2=A0}
>=C2=A0 =C2=A0 =C2=A0 =C2=A0leaf decline-received-count {
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0type uint32;
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0config "false";
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0description
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"Number of Decline (9) me= ssages sent.";
>
> The descriptions seem out of sync about sent vs received, here.

[if - fixed]

>
> Section 5
>
>=C2=A0 =C2=A0As the RPCs for deleting/clearing active address and prefi= x entries
>=C2=A0 =C2=A0in the server and relay modules are particularly sensitive= , these use
>=C2=A0 =C2=A0'nacm:default-deny-all'.
>
> This looks like a comma splice.

[if - Reworded to:

The RPCs for deleting/clearing active address and prefix=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0
=C2=A0 =C2=A0 =C2=A0 =C2=A0 entries in the server and relay modules are par= ticularly=C2=A0 =C2=A0 =C2=A0 =C2=A0
=C2=A0 =C2=A0 =C2=A0 =C2=A0 sensitive. These RPCs use 'nacm:default-den= y-all'.=C2=A0 =C2=A0 ]

>
>=C2=A0 =C2=A0An attacker with read/write access the DHCPv6 server can u= ndertake
>=C2=A0 =C2=A0various attacks, such as:
>=C2=A0 =C2=A0[...]
>=C2=A0 =C2=A0An attacker with read/write access the DHCPv6 relay can un= dertake
>=C2=A0 =C2=A0various attacks, such as:
>
> s/access/access to/

[if - fixed]

>
>=C2=A0 =C2=A0Some of the readable data nodes in this YANG module may be= considered
>=C2=A0 =C2=A0sensitive or vulnerable in some network environments.=C2= =A0 Therefore, it
>=C2=A0 =C2=A0is important to control read access (e.g., only permitting= get, get-
>=C2=A0 =C2=A0config, or notifications) to these data nodes.=C2=A0 These= subtrees and
>
> This doesn't match the template at
> https://trac.ietf.org/trac/ops/wiki= /yang-security-guidelines , where the
> parenthetical is "(e.g., via get, get-config, or notification)&qu= ot; -- the
> meaning is different!

[if - Changed to =E2=80=98via=E2=80=99]

>
> Appendix A.1
>
>=C2=A0 =C2=A0The 'max-pd-space-utilization' is set to 80 so tha= t a 'prefix-pool-
>=C2=A0 =C2=A0utilization-threshold-exceeded' notification will be r= aised if the
>=C2=A0 =C2=A0number of prefix allocations exceeds this.
>
> the max-pd-space-utilitization is a percentage, so the "number of= prefix
> allocations" needs a unit conversion to be comparable to it.

[if - added 'percent' to the description]

>
> Appendix C
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0container lease-storage {
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0description
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"Configures how th= e server will stores leases.";
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0choice storage-type {
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0description
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"The type s= torage that will be used for lease
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0information.&quo= t;;
>
> s/type storage/type of storage/

[if - fixed]

>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0case mysql {
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0leaf mysql-name = {
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0type stri= ng;
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0descripti= on
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0&q= uot;Name of the database.";
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0}
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0[...]
>
> This seems to not have provision for configuring mandatory TLS usage f= or
> connection to the mysql server.
> (Same for the postgres case.)

[if - I=E2=80=99ve just found draft-ietf-netconf-tls-client-server-26 which= covers this and
Would seem to be the right way to do this.

However, importing this module and its dependencies and using the tis-clien= t-grouping for
Mysql and Postgres results in the tree diagram growing from 49 lines to
401 with the TLS configuration, which somewhat detracts from the point of t= he example.

Given that this is provided as an example module for a theoretical implemen= tation,
Would it make more sense to remove the mysql-host choice and add text in The mysql-host configuration description to say that the database must be r= unning
On the localhost? This could be noted in the Appendix descriptive text as w= ell.]

>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0leaf mysql-port = {
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0type inet= :port-number;
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0default 5= 432;
>
> mysql's registered port seems to be 3306 (5432 is assigned for
> postgres).

[if - changed]

>
> Appendix D
>
>=C2=A0 =C2=A0classifying clients.=C2=A0 So this standard does not try t= o provide full
>=C2=A0 =C2=A0specification for class selection, it only shows an exampl= e how it
>=C2=A0 =C2=A0could be defined.
>
> s/example/example of/

[if - changed]

>
>=C2=A0 =C2=A0 =C2=A0grouping client-class-id {
>=C2=A0 =C2=A0 =C2=A0 =C2=A0description
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"Definitions of client message c= lassification for
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0authorization and assignment purposes= .";
>=C2=A0 =C2=A0 =C2=A0 =C2=A0leaf client-class-name {
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0type string;
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0description
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"Unique Identifier for cl= ient class identification list
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0entries.";
>
> Shouldn't this be mandatory if it's going to be the only way w= e refer to
> class IDs?=C2=A0 I guess the grouping is currently only used in one pl= ace,
> and it's a list key there (so implicitly mandatory), but I still w= onder
> if the grouping is more reusable with "mandatory true".

[if - Added mandatory true]

>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0leaf relay-interface {
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0type string;
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0description
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"Reference = to the interface entry for the incoming
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0DHCPv6 message.&= quot;;
>
> Whatever we do in the main module for the encoding of the interface > entry should be reflected here as well.

[if - Changed the descriptions to align with the interface-id option text i= n the relay module:

=C2=A0 =C2=A0 =C2=A0 case relay-interface-id {=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0
=C2=A0 =C2=A0 =C2=A0 =C2=A0 description=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "Client class selection based on a = received instance of=C2=A0 =C2=A0 =C2=A0 =C2=A0
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 OPTION_INTERFACE_ID (18).";=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0
=C2=A0 =C2=A0 =C2=A0 =C2=A0 leaf relay-interface {=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 type string;=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <= br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 description=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "An opaque value of arbitrar= y length generated by the=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 relay agent to identify one of th= e relay agent's=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 interfaces.=E2=80=9D;=C2=A0 =C2= =A0
]


>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0leaf vendor-class-data = {
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0type string;
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0mandatory true;<= br> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0description
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"Ven= dor class data to match.";
>
> (likewise)

[if - Changed to:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 container vendor-class-option-data {=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 description=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "Vendor class option data co= ntainer.";=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 leaf enterprise-number {=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 type uint32;=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <= br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 description=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "The vendor's reg= istered Enterprise Number as=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 maintained by IANA.";= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 }=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 leaf vendor-class-data-id {=C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 type uint8;=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 description=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "Vendor class data ID= ";=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 }=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 leaf vendor-class-data {=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 type string;=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <= br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 description=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "Opaque field for mat= ching the client's vendor class=C2=A0 =C2=A0 =C2=A0
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 data.";=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 }=C2=A0

]

>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0leaf remote-id {
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0type string;
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0mandatory true;<= br> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0description
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"Rem= ote-ID data to match.";
>
> (and here)

[if - The remote-id option case in the class selction example module was le= ft over from a previous version of the draft.
As remote-id is not defined in RFC8415 it=E2=80=99s no longer modelled in t= his doc, so I=E2=80=99ve removed it from the example.]

>
>
>

--000000000000b35c0e05d6173511-- From nobody Fri Jan 21 05:19:44 2022 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 716FD3A1F97 for ; Fri, 21 Jan 2022 05:19:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=qacafe.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PewpMMqBbkyE for ; Fri, 21 Jan 2022 05:19:38 -0800 (PST) Received: from mail-lj1-x236.google.com (mail-lj1-x236.google.com [IPv6:2a00:1450:4864:20::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DC2DF3A1FA0 for ; Fri, 21 Jan 2022 05:19:37 -0800 (PST) Received: by mail-lj1-x236.google.com with SMTP id w7so133531ljw.11 for ; Fri, 21 Jan 2022 05:19:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=qacafe.com; s=google; h=mime-version:from:date:message-id:subject:to; bh=TeWg4UXaVbfZLUUSdhg4oxHTTR/Ish5UF/2k9agVqHA=; b=CkWbQ7l0v6OC59o41BZy0yJiaSk5KMoUhZvzB9vRjZPriNzoMoNk+IgmzqE72ZlEvO I0iMnBHNoC9ZDdYQGOIUJ075m87hMIssGKeYpV84a2fzxAksGSzKPTA06IdBixgcnmKZ Xx+ivHoRfVtDudA0EeFok9cVHfwkIzw9ODC7Q= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=TeWg4UXaVbfZLUUSdhg4oxHTTR/Ish5UF/2k9agVqHA=; b=8HCcW1rodyrs3K84Y4hMuEzrJgR3fHV3W01zgTXIIy1buPdsZLwasIu4I1ioCQZnZN ahrNXj7u5d2G6nKwMXlZzvfd/mvnGmzNM1wWWm9ZpGOLShInCB81GZmbYixb1pkDuVDJ 3AdJxxoYvkxsM5eRv7eYJGVj0uQqt0nAwmXGY/s0OLyK/f5jWV9iwHa76yCl0bNIC5al GYfF1UdHB3+x4RgrsvaCr5ARIcpCqYaMnsQerFFhxOGNq+fq8amRD8WzftRYnRLqbKUY 9P4TbPA14OZdu7C0VVK8wmNCxV3lIWpmzDymJ5BCx2N+e1paoD2ypnxFsxEcX5pfPRlc k6rg== X-Gm-Message-State: AOAM531yPGkwA5aLz5CqeGMF9s7OP/LbN9LnXF/9WTiwZxKGlJ9shC8E SpeMX0xNBmUdJLjZjK3hHjZFZbFAZMHGQBuaWWLCcUKNoB0/GQ== X-Google-Smtp-Source: ABdhPJyWkgXCJmnkAMrcdHqvqcZ2AKaF+hunMu2sExzi9WOzmJ4SvolmRcrNvA4mOuwLFASxSveOh7EeeGtUgWfca9Q= X-Received: by 2002:a2e:9b17:: with SMTP id u23mr3191266lji.330.1642771174782; Fri, 21 Jan 2022 05:19:34 -0800 (PST) MIME-Version: 1.0 From: Timothy Winters Date: Fri, 21 Jan 2022 08:19:23 -0500 Message-ID: To: dhcwg Content-Type: multipart/alternative; boundary="000000000000521bd605d6177832" Archived-At: Subject: [dhcwg] DHC WG Meeting IETF 113 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Dynamic Host Configuration List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jan 2022 13:19:43 -0000 --000000000000521bd605d6177832 Content-Type: text/plain; charset="UTF-8" Hello, Bernie and I are leaning towards not having a DHC WG meeting at IETF 113, but having one at IETF 114. As of writing this we only have one working group document ( https://datatracker.ietf.org/doc/draft-ietf-dhc-dhcpv6-yang/) that is in IESG Review. We will be starting work on Advancing 8415, which we'll be sending some information out about shortly. If someone does need us to reconsider requesting a DHC WG session for IETF 113, please contact the chairs promptly (the IETF deadline to request a session is February 4) . In general, new potential work should be initiated by submitting an individual-submission draft and sending details to the DHC WG mailing list. Thanks Everyone! ~Tim --000000000000521bd605d6177832 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello,

Bernie and I are leaning towards not having = a DHC WG meeting at IETF 113, but having one at IETF 114.

As of writ= ing this we only have one working group document (
https://datatracker.iet= f.org/doc/draft-ietf-dhc-dhcpv6-yang/) that is in IESG Review.

=
We will be starting work on Advancing 8415, which we'll be s= ending some information out about shortly.

If someone does need= us to reconsider requesting a DHC WG session for IETF
113, please conta= ct the chairs promptly (the IETF deadline to request a
session is Februa= ry 4) . In general, new potential work should be
initiated by submitting= an individual-submission draft and sending details
to the DHC WG mailin= g list.

Thanks Everyone!

~Tim
--000000000000521bd605d6177832-- From nobody Mon Jan 24 05:38:42 2022 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87B423A003D; Mon, 24 Jan 2022 05:38:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_MSPIKE_H5=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gmx.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tAr9yb5EqXzN; Mon, 24 Jan 2022 05:38:31 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4BF253A003C; Mon, 24 Jan 2022 05:38:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1643031502; bh=PAWqKZcyG+LMhJyNkKKOGG+1WUkQWBgwdh3c2uz4bio=; h=X-UI-Sender-Class:Subject:From:In-Reply-To:Date:Cc:References:To; b=OWFLDnzng7e7x1vs8RtyEnsGaVgosq5bll0eGYAtgZaaZNr0sL5opXsKlRNRHZwKw QqFaXop1vjW5SGCAXV6hTeUATXFwh4flayjDyOEdLGVFtpGOg1tpDzpdgsSf9LqkPg czdq5acD05cFSTReRoSNE693OKtbcGytfxxRJ/Po= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from smtpclient.apple ([78.35.54.88]) by mail.gmx.net (mrgmx005 [212.227.17.184]) with ESMTPSA (Nemesis) id 1Ma24s-1mowtm05ci-00Vz31; Mon, 24 Jan 2022 14:38:22 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 15.0 \(3693.40.0.1.81\)) From: ianfarrer@gmx.com In-Reply-To: <163952318471.6405.13202229024853663670@ietfa.amsl.com> Date: Mon, 24 Jan 2022 14:38:19 +0100 Cc: The IESG , draft-ietf-dhc-dhcpv6-yang@ietf.org, dhc-chairs@ietf.org, dhcwg@ietf.org, Timothy Winters Content-Transfer-Encoding: quoted-printable Message-Id: <3D6F4EEB-C01A-4E38-8AC2-6A3AE64CFBC2@gmx.com> References: <163952318471.6405.13202229024853663670@ietfa.amsl.com> To: Roman Danyliw X-Mailer: Apple Mail (2.3693.40.0.1.81) X-Provags-ID: V03:K1:y0B2OiMgzfxysB9//wjdfD/Ds9zsdwFxF8ieseTStsbtrZpIVeL IkNqR80Tt+QnfZu/ptLo88rW3MDIe7DcoKsPXID5AesMMKxFuJbkyGACbROy31sKu8Pb6gT 9e1PdwbLflyRl4Kb3zmZydRyEGG6fWp139L/1acBkLJQSPDVVAmPNiLz1jyDoWryidE+y9X yh6rssGpmj0rOSTUUTY7A== X-UI-Out-Filterresults: notjunk:1;V03:K0:THWsQ+LX+j4=:/uZE7FaXvsH0z/pVyKcDAs KS3vnVm35j9VJvJSMS2+vqj2ORSUGZsWY0mcJSfPLXDE6urGtsg1CUUKmu0cVXUYJXfC3iB6B YeC40AGygepYYRq68LhxgYc1/9CjHySzgFs7VLhjpJHwNo3QP4jSkUuSCiita+B382ifOcJMA JXys6qLjnwypzsoik1sYQJRd3I+lEvfN0QmjeFFDQ1MfKPTIMuGAW+6XGUFAuayryobdQP7aW CJawur0Z81Go0B4vc1eZ1+HHJHLLBo1emPmldgn52yNWRlME6q3AxHGzHc7jOzhtHBjkl9xIu HRaBTvmPUh0guD7PHbZf2hgpQnobQLZiDK4bDVkY1oB4TZo4tXbMgBUEPGQGYMht4xlzyHWIx e3dCRgqnEue47fhlUiUPAHxcQFgFoKkhNRUH5/5eBt91cSneEdJJEk488RpFWIh5P8I0vCU5O +fOfgJX/qqISZ9qXQyJHqCUv2+G5FO7ADr4diiBWlpfMD3q/HTHrGekGTWLL1gw8BmiATxUmf jOjIgLhjSLb55tnlzv8dnD6X9QR1ucvufqHzJyehzU8e0mvqEf20NkWIvg7olAwdl3vXBxQQx ers0ywRL6p5nXI4ueM17f2O1/E/GElzHZrjXYkRIGcw+KSaU+0HHPvA+p9wQl+1CdG6HaHHqa kZRVLf26+S2HemmGuZ6IzMRQpsH0KaDCN4zbdOxa8Ui6L2q+Vi0Y6q2bACU5Jg/jXK4xF92l1 VcBebvBYC0A3APQZuGIDWKiDL9Q2iXNH9S3PJlS8EF7urU4frMVaEa01aJn84mO4K2oixt1n9 BZkSL4yI9Lsig6Dcd19I9PVowmOCD3TGRguoDbi9713QUxduXDoKMUABwtRYJF/z0h55k/mXX g/1QRuw6cS2i6c2lDeNT91y9lOB7z/ug2WVG6gxIeIPYFM/TWslBJEKjujGg5p48x5Am6hZzC Q8RX6pcW2NgRjpheCFleaoOftHYRcKi7HM+K8LdSJzc/e+F3hcGb1VzYunYJUPdHUutwjbf3g G8y5OANJGFSUQU4xX7JQ8VtNF9sDCUld0eMdx320uuI+FMOq7Emt9xFmGh/vHexM3oZl+F6lc Q+5urQmk2vAW1o= Archived-At: Subject: Re: [dhcwg] Roman Danyliw's No Objection on draft-ietf-dhc-dhcpv6-yang-24: (with COMMENT) X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Dynamic Host Configuration List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jan 2022 13:38:34 -0000 Hi Roman, First of all, many thanks for the detailed review and my apologies that = it=E2=80=99s taken so long for me to reply. Please see inline below. Thanks, Ian > On 15. Dec 2021, at 00:06, Roman Danyliw via Datatracker = wrote: >=20 > Roman Danyliw has entered the following ballot position for > draft-ietf-dhc-dhcpv6-yang-24: No Objection >=20 > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut = this > introductory paragraph, however.) >=20 >=20 > Please refer to = https://www.ietf.org/blog/handling-iesg-ballot-positions/ > for more information about how to handle DISCUSS and COMMENT = positions. >=20 >=20 > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-dhc-dhcpv6-yang/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > Thank you to Vincent Roca for the SECDIR review. >=20 > ** (Editorial) Regex constraining hex strings. When I first read the = pattern > constraining typedef duid-base (and the same is true in other places), = I didn=E2=80=99t > appreciate that this regex was operating on a string containing a hex > representation of octets. [if - I=E2=80=99ve added the following text to the =E2=80=98duid-base=E2=80= =99 description: Type 'string' is used to represent the hexadecimal DUID value so that = pattern constraints can be applied.] >=20 > ** There are a few places in the three yang modules where it appears = that > human-readable messages are being returned. What is the expected = approach (if > any) for conveying a language tag per the guidance in Section 4.2 of = BCP18? An > incomplete list of these places are: >=20 > -- Section 4.1. grouping status and status-code-option-group has a = leaf message >=20 > -- Section 4.2. rpc delete-address-lease and delete-prefix-lease = return a leaf > return-message >=20 > -- Section 4.3. leaf return-message in the rpcs [if - I=E2=80=99ve updated each occurrence of =E2=80=98return-message=E2=80= =99 (2 instances in the server module and 3 in Relay) with the following: description =20= "Response message from the server. If available, a language =20= identifier should be included in the message."; =20= reference "BCP 14 (RFC 2277) IETF Policy on Character Sets = =20 and Languages, Section 4.2."; =20 RFC2277 has been added to the normative references.] >=20 > ** Section 4.1. grouping status has a leaf message which is explicitly > described as of =E2=80=9Ctype string=E2=80=9D and is clarified as = being a =E2=80=9CUTF-8 encoded string > ... that isn=E2=80=99t null-terminated=E2=80=9D. No issues with that = guidance. I=E2=80=99m wonder > whether the other strings mentioned in the previous comment should = also be > described in this way. [if - The requirement for the status-message format is taken directly = from RFC8415 sec. 21.13. However, the return-messages as described above are not defined or = mentioned in RFC8415, As they are implementation specific, no format (or even their = availability) can be assumed.] >=20 > ** Section 5. Additionally threats to document would be: >=20 > -- Generalize the threat of redirecting clients to services under the > attackers=E2=80=99 control (e.g., DNS server or WPAP). Say: >=20 > OLD > * Various attacks based on re-configuring the contents of DHCPv6 > options, leading to several types of security or privacy threats. > For example, changing the address of a DNS server supplied in a > DHCP option to point to a rogue server. >=20 > NEW > * Various attacks based on re-configuring the contents of DHCPv6 = options, > leading to several types of security or privacy threats. These = options could > redirect clients to services under an attacker=E2=80=99s control. For = example, changing > the address of a DNS server supplied in a DHCP option to point to a = rogue > server. [if - Changed] >=20 > -- Ability to read the leases from the Server or Relay could help the = attacker > fingerprint device types. >=20 > OLD > These subtrees and > data nodes can be misused to track the activity of a host: >=20 > NEW > These subtrees and data nodes can be misused to track the activity or > fingerprint the device type of the host: [if - Changed] >=20 >=20 >=20 From nobody Mon Jan 24 06:30:06 2022 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3109B3A0ACC; Mon, 24 Jan 2022 06:29:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.898 X-Spam-Level: X-Spam-Status: No, score=-6.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gmx.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LfLcn3cICOji; Mon, 24 Jan 2022 06:29:51 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 609983A0ACA; Mon, 24 Jan 2022 06:29:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1643034585; bh=/twAnVVodXNwvkNiNnd31UPiLynj6kMghYfaiUejV/Q=; h=X-UI-Sender-Class:Subject:From:In-Reply-To:Date:Cc:References:To; b=cqhN3Tt5lSGY85ifPnEOPVZNRUA06GSJsrm8R8t7SGodNO1o6fM3u1e+52y1Q/Udr gzGcRzV+TDsX0FcESu4AdottqFPS1GIkfwFcVFmW88B825anTy8xZ04aDlT3StAtlX TJy6iwn89gg6y5UR5d6PdId0VXfLHE4duoba4nnY= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from smtpclient.apple ([78.35.54.88]) by mail.gmx.net (mrgmx104 [212.227.17.174]) with ESMTPSA (Nemesis) id 1MkHQX-1mRuy02S1B-00kepK; Mon, 24 Jan 2022 15:29:45 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 15.0 \(3693.40.0.1.81\)) From: ianfarrer@gmx.com In-Reply-To: <163962893754.31155.10776710383187465752@ietfa.amsl.com> Date: Mon, 24 Jan 2022 15:29:41 +0100 Cc: The IESG , dhc-chairs@ietf.org, draft-ietf-dhc-dhcpv6-yang@ietf.org, dhcwg@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <674ED3ED-215B-4EEC-98FC-21B3C12F0820@gmx.com> References: <163962893754.31155.10776710383187465752@ietfa.amsl.com> To: Erik Kline X-Mailer: Apple Mail (2.3693.40.0.1.81) X-Provags-ID: V03:K1:t48WSXO0YmvPg8Lhez78dgm8jwFqGrdUucwDYtRtBrJLhHe9jqB 8PmQoFwfoGmvLS0nphHU1UuCX7Gi1pdx8s2J7Pece8PVjSdP7QuB8CYZHc9ikFbjIlkX194 lSTcUaqsVK39YvMlAzZwTFwD/3tS0GGsvKHYLkkTxMe5719ZjfY62W55wHaj4behhNImEtz nxe9eIlueArPl4wEMBM+w== X-UI-Out-Filterresults: notjunk:1;V03:K0:ARTuPgEwBtw=:a9hivg9OuHYfA5zzVsBgJm f4rO8guKupqoMFdaavbDvIcbTVpbi7//d5ZAm2DTTslmpKkG+DCQY+4zUtvK8irrb0Q3UYRwL rSw7MuZJZapoGKjuBjsxBR17j5Y0K8OfKdxMN/L+s/td1eB97tDB7L6gyc2/VTuP07i5jnvhI nlh+aaMAxLiXFAx8KKLFdWyQbTcS79V0xRdlVHqSGsU5F2mTch76Ods7k6GZSx+lYeTQwF5Q7 rhmTWLLDWXXScM4aH6XcQFYMDi/LJxKdVrsMNmMxTUUHP9k99OGtcYIqgwehTey5QlOKKHu55 LJG716owCSnxKAfHMHWyXqYM/yRcAfSuKYDW1wd3M7l09+sW+ZsX9BqBNo98qrnmGAJUMQC1Y X6EJjlZkbcNjW9d6Ulone9TeoAjbV3Pib9mBHnbOFgUn6kfUfBce/BSaKjdmlHDDragPO+c1+ 7nHOnsXxTjLS5FXItlR9GorhzFQGcFJYyaOdkzgMgb4WULecluU/KGIuTYw7n2dDZgHt8qLTT JD+6cOnh1guyAsmIAKmzCuGZKGgB1R3HzWCWVQ3RXPtql/mj4OzjT+1De/XlNId4WkgirYNG+ jS0HITXnfn7ydw0hEDPr9MlXOblyM17/dDRAjYZ4ylfr4jUNX7o35/PrFGlyYP+Q6KkbU9fQh AwbF9myFkKRwH33bdcqNs4Kjyl9JIHuAjTxPSewTe7OP77YImhEsCnMk74oXV9bBk1UUaMphG Bwcj1mKiVDT4qGPZnBaHVhZy85lfkUKKp18xjvatY6UKTOFZGiLeWFBwiJLE1g6K8ByYb152C sNFj9USKFqwB0+qstzLvtm8vzU5wGi915ZYpg3OgvJjh3DrWPG//3VFgGn+RUYUWZhsDKD+XK DOWpmH6dF2SeEPlAuWRESreqSjVwffLFkiS5Q4SCuZH/HxS2qH92y4isF02dF7lkK3Y0Ehm+I +2PIEUtAM/nCFzkcWdmJWVyxpdQGIel9rQy44B3XAdjSCfRBgy2FgOFMha2sB83pUbu3moAhr G+gchpr8K1GqQNMkh+h2hab0pU3Xv5LMslBw5oLp/4UBLXhxwUG6HWGgJFIdPLoJQjnE5IgDH c5KzG5/YvRrX6k= Archived-At: Subject: Re: [dhcwg] Erik Kline's No Objection on draft-ietf-dhc-dhcpv6-yang-24: (with COMMENT) X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Dynamic Host Configuration List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jan 2022 14:29:54 -0000 Hi Erik, First of all, many thanks for your review and my apologies that it=E2=80=99= s taken so long for me to reply. Please see inline below. @Bernie/@Tim, please can you give me your view on the anonymity profile = suggestion below. Thanks, Ian > On 16. Dec 2021, at 05:28, Erik Kline via Datatracker = wrote: >=20 > Erik Kline has entered the following ballot position for > draft-ietf-dhc-dhcpv6-yang-24: No Objection >=20 > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut = this > introductory paragraph, however.) >=20 >=20 > Please refer to = https://www.ietf.org/blog/handling-iesg-ballot-positions/ > for more information about how to handle DISCUSS and COMMENT = positions. >=20 >=20 > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-dhc-dhcpv6-yang/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > [S1.2; nit] >=20 > * s/demonstrate how this is can be/demonstrate how this can be/ [if - done] >=20 > [S3.1; nit] >=20 > * s/for an failure/for a failure/ [if - done] >=20 > [S3.2, S4.3] >=20 > * Should RFC 4649 remote-id be included here? Or, perhaps, did RFC = 8415 > S21.18 OPTION_INTERFACE_ID effectively obsolete OPTION_REMOTE_ID use > cases (or perhaps I'm just confused)? [if - Both OPTION_REMOTE_IS and OPTION_INTERFACE_ID are still current Options (and about 50/50 available in commercial implementations IME).=20= But we restricted the scope of the doc to only contain options defined = in RFC8415, So RFC4649 options will be in a future doc.] >=20 > [S3.3, 4.4; question] >=20 > * For the user class and vendor class options, should they be = annotated as > "not anon-profile"? I'm curious about these elements w.r.t. to > RFC7844 S4.8. [if - Good point, but it=E2=80=99s a SHOULD NOT rather than a MUST NOT = requirement in RFC7844, so I don=E2=80=99t think the YANG module should prevent it=E2=80=99= s configuration. @Bernie/Tim, do you have a view on this? Suggest adding the following text to the descriptions for user/vendor = class options:=20 Please note that if the DHCPv6 anonymity profile is in use, then this = option=20 Should not be included. And adding a ref to RFC 7844 sec 4.8.] >=20 >=20 >=20 > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg From nobody Mon Jan 24 06:49:38 2022 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 373553A0C77; Mon, 24 Jan 2022 06:49:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gmx.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mV3vtbElwNRy; Mon, 24 Jan 2022 06:49:32 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8A4DB3A0C7D; Mon, 24 Jan 2022 06:49:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1643035767; bh=s9uW8I95GhhsBXnci/9RLu4EtQeU8HrtAFJ9VUDuOnI=; h=X-UI-Sender-Class:Subject:From:In-Reply-To:Date:Cc:References:To; b=DHHEgwjRLzEHLb1Rn8oxvp3ZfG4Z7d5ffB8f/FycL+2orQDR+Bv+/YesTaiN+wHWv N5vsGSVi4sKkazrK9LVhdplzejWWVq/FNmkx3eHDjabCkQoaSc98W40ffRt5iTsnLj JMUvaO2Rh5nrBzMrCe96g4PXDq3Fyro0FfaNY048= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from smtpclient.apple ([78.35.54.88]) by mail.gmx.net (mrgmx004 [212.227.17.184]) with ESMTPSA (Nemesis) id 1Mf07E-1meIjV0Fkw-00gXA2; Mon, 24 Jan 2022 15:49:27 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 15.0 \(3693.40.0.1.81\)) From: ianfarrer@gmx.com In-Reply-To: <163955145413.10392.15987440783848564312@ietfa.amsl.com> Date: Mon, 24 Jan 2022 15:49:26 +0100 Cc: The IESG , dhc-chairs@ietf.org, draft-ietf-dhc-dhcpv6-yang@ietf.org, dhcwg@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <163955145413.10392.15987440783848564312@ietfa.amsl.com> To: Murray Kucherawy X-Mailer: Apple Mail (2.3693.40.0.1.81) X-Provags-ID: V03:K1:gjr3Tq3w8mDJx35ZhLIP9FclTTzCdKx6eD7NcCWW55NcOJCJxdp aDLrfFCO7L0bVb7o0gF1Ikevl3WwwEgyTnAkPR177amLHkMJUWXnLsuQyu/TWjhaUFFhceo qCR1bM6t1entimfESk118IMXa+cqbMigeOXoxyeKy9VYn0r6VtbI/hCiY6VAsWfMXfuiSdi rnIkVJ9YZanN65LLRvetQ== X-UI-Out-Filterresults: notjunk:1;V03:K0:BmsGVemIDLI=:2M5WDVwefDcRpowGSV42hn fo1qd4LpJtvHYhTaYSE9BEgTC07nfUATMgSHYhvXwSbVF1digg+kbon2dqPfXERFMZXq3pbaq sur+tyVG86lu9Dwyf/K7JpF0l9dqQNa1HCweWql4ar525YgQo430BYzYX2ACHk1Q3OVS//YkY gBSDR3KjvZCl5XpaJjqLvL4X/WVbI9opvTg4zx/PayD8AhAMgYwhMVOFDeNMbsaRt7S4cQFOR jmG1YTCrd9vKLdmtzp4sZHsNLinjEbf5mcx423SHoE3I4EAaMtraIRn7BF+Q7fr+jRDpmZOv4 uix9Ds6DA75XDbqM4WfkqdthhZJWAH5sfX/1ux4R+GO4tkqCihXVLcO0qGRmKLwBjv98wUp9O kk5t7BK+6duAN0K5yDGrH7ymOOk/xpdeXnKezlfK1hdlJU60rGpuvZVuANxM7l1YXfFFTVvJg Ngmhhsw3GUIhjRFb5nzThWbqPBIPY+cnArU59rn+/niFsc1GeJ7sJZGwwr9nNjy+mjOLKAgRW c5/yO3AG1xtUEs2WkB4ETSoX0MOOVjdo9w3146vkJ/trfKDd8LLnuLO7R8MyQtTBr31PdbmUT fFo/OK64I89zjxqXDQFt2Zwt969Il1KppVva0HR1yxdrJkO5q/42mCdcJDWj8xZKC7uN+TgS2 fbeJDOJ95jKJ1HoZ8j/2qasu10RPm2YiENKxCjqCBHnivUCF/rCQ+kIAjUX5oEa9bkY+FKGig wKHFUo6fyxdOrC40JwBpjkNSGto0JAyMjVT8xQUxZ0fpDrhuimDjCoBC+ACz1WxsZdaOEyFhe MOw0r9BX3uAgmr5U+YWPBijsbj2Zc5pMNgQiOrI9sX4B3xhkOrNXXRHUnVU0IClgdlVfiqS5f EDHssHGNP0qIddxQ/ULqtzZCGl/DWr1y+p3YS5uQvL15u0g887ovVaRcgH2DUY1lSV+4c3hNt 6qcGpPFvgQpQ4bzZNjuyb+MUzvxEzCyPACjb/dyiyE/1TExVBB197vZWS8lPKtpvPAMzBvf2B DJlxW5TCPFoRigfCpwcyilTPaM9+3cTcRK0kEDpkho1uEWuv++50ajJgW8uydDG6JAQeelZKg a8t7bUq5LoCg3Q= Archived-At: Subject: Re: [dhcwg] Murray Kucherawy's Discuss on draft-ietf-dhc-dhcpv6-yang-24: (with DISCUSS and COMMENT) X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Dynamic Host Configuration List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jan 2022 14:49:36 -0000 Hi Murray, First of all, many thanks for your review and my apologies that it=E2=80=99= s taken so long for me to reply. Please see inline below. Thanks, Ian > On 15. Dec 2021, at 07:57, Murray Kucherawy via Datatracker = wrote: >=20 > Murray Kucherawy has entered the following ballot position for > draft-ietf-dhc-dhcpv6-yang-24: Discuss >=20 > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut = this > introductory paragraph, however.) >=20 >=20 > Please refer to = https://www.ietf.org/blog/handling-iesg-ballot-positions/ > for more information about how to handle DISCUSS and COMMENT = positions. >=20 >=20 > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-dhc-dhcpv6-yang/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- >=20 > This should be easy to resolve, but we have to ask as it's pretty = important: >=20 > Question 7 of the shepherd writeup, about the authors and BCP 78/79, = appears > not to have been answered. Were these declarations made? >=20 >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > I suggest breaking Section 6 into two subsections, one for each batch = of > registry operations. [if - done] >=20 > A possibly ignorant question about YANG modules: Since RFCs 3319 and = 8987 are > referenced from within the module itself, shouldn't they be normative > references? [if - RFC3319 is only referenced as it is used by an example module = showing how Additional DHCPv6 options can be modelled and augmented. As this is in = the appendices, I think It=E2=80=99s right to be informative. RFC8987 does need to be implemented by the relay and is referenced in = the ietf-dhcpv6-relay Module, so this is now a normative reference.] >=20 >=20 >=20 > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg From nobody Mon Jan 24 06:53:18 2022 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCA973A0CBD; Mon, 24 Jan 2022 06:53:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.895 X-Spam-Level: X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gmx.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2dDe-L2HsG80; Mon, 24 Jan 2022 06:53:12 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 41C4A3A0CB1; Mon, 24 Jan 2022 06:53:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1643035988; bh=xxvEtVb9EvtvJdRM9OhWSfNF5OMVgnjba+VKxV9s9YA=; h=X-UI-Sender-Class:From:Subject:Date:In-Reply-To:Cc:To:References; b=L0fxfDD95rXt95rEuoc9Aprvnoby/oY4bVwR4RIdVI6SLuXUeXt2nJr4VJqs0BkWh jFfnauKdne+Xv6ekj4WedbDLw4t6oI5fqDzupah3Oses8F4LXIPPP9vgvzeyZEFEWg q02Ad3oQucvroTaFibQ16f/K70gRFD/8lc8Z4wuI= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from smtpclient.apple ([78.35.54.88]) by mail.gmx.net (mrgmx005 [212.227.17.184]) with ESMTPSA (Nemesis) id 1MJVHe-1msGuS2ceG-00JtyB; Mon, 24 Jan 2022 15:53:08 +0100 From: ianfarrer@gmx.com Message-Id: <6274DE4F-76A7-4F62-896E-EB1F8AAA7614@gmx.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_AD970E9D-E45B-43DA-92B1-5C4910531605" Mime-Version: 1.0 (Mac OS X Mail 15.0 \(3693.40.0.1.81\)) Date: Mon, 24 Jan 2022 15:53:08 +0100 In-Reply-To: <163964407096.2614.7647317623574217061@ietfa.amsl.com> Cc: The IESG , draft-ietf-dhc-dhcpv6-yang@ietf.org, dhc-chairs@ietf.org, dhcwg , Timothy Winters To: Zaheduzzaman Sarker References: <163964407096.2614.7647317623574217061@ietfa.amsl.com> X-Mailer: Apple Mail (2.3693.40.0.1.81) X-Provags-ID: V03:K1:35lr+KKmZPP7ee1jpxja6nfH6Va6N3+k9H2FSfFX9p9X49GZK/e CifR9ACClIgexEQ6E3ymUwy32Oa17jKb9SpqJD+Ra/SPL25kHxvDGZWStIVbupXX/gR9scg u2AhikvHS6ZYHgCQ9yAllU8Xj3ucM0Px1MaYS9E25bg2AEPBm9/gByPABISGbdr+0FbN/ax bLICkTbwSCuVvIJwiWZbg== X-UI-Out-Filterresults: notjunk:1;V03:K0:p3LtVkw6iis=:IpunpYmJvmbrTdrtiHApZ3 r4Ca/UxeULeFlibd/q06PgQtU2Ze7jyKE3+RLVpzbkTn016pIjnBFikZtstFAum5kfy3Drw63 T4n0qyrVAFZDxNwzCe1O34r8CQNzVOIRXT23YZqPP8rE+TukMGxWu2b6OuePT5AQNy99GLnye qnNLDKKDDmzUKWEDuP5Ge3ub819G80jXvDegsxqrzf5N62aSB9D2LubygvPt7FwLEHz6zozcV 9nLrLYfa1TbUN2Qry5vlsRDFQe/xTfNMT0ItzUyIy1MDMN+aHHi27/ehmzKaVNw2OtdJswd3j XAFX91UrQ6unGzPelc5CaX/+X5m40kgH0m/cZQopbfU28O1XvihnigU2Yi+rlKvPhJX2fgI9+ 2Pv/5swsk8All67oRKZgHfsicDUB32+RZQH3dGGdcfIDsHZxJkFO9u9XPz5uHlnzKKyJJ7vcQ kRVLtNTfyW4bCSVIza84BU+R8so2IcXNc3B+jrSkX3gdmNYo9J19ApdBDARoCqcWigZFb8aG3 oQTcV1a+A2K3O9FpjasAfuynE6g41X4FF/IXOs4el+cS1RvKLd8nxcudxztLH0csdC9LWWtUM C8xDqutdy6qpH9xqj52NjITglBANAQoVOLzU+j0zDi0UVFNb6Kys9WKCUU4BoGMWTM/pYJxvX 5o++VZYXs8gzLvOrnrbXNouP+grDtJ9FsRJZYVI5ukPrPa8C0JeQLv+S5HneVKTTdqpMtg8WL N01HKOqrfsIqQqHTBx4hL+BTwtsA4ogocu1XHGaS7LqAjVZmYUEn4ty8v2KEO9YkDNeztmdyT CQ3yLlfwxqfA1mtYajhZzTwIoSWQx/crMoO1k3zMUdoIFrMBUCblEWdzpjvEJSKUhYGuusGIJ Lrr/H02SrE2fF48eCpCGBepq7Z1vy/d5ef+YHMww5T03pB6GOKzxCD7s0nVKpyi+sS1PzvU+E hdvL9MhX4Gfs4u9gf00JkyV8BLfnqGRmMdgbisQmiXtlDq33iBxnVBcvrA7o80ef9kgXxynXU kR8Cj7EjNS8jSowVGjUVdcjoBQ/CClMb5Boh+MCHBVcqPK2EhbN7wl03BkwUNDkZTHW8icDOS gG1jjM24Vclu/k= Archived-At: Subject: Re: [dhcwg] Zaheduzzaman Sarker's No Objection on draft-ietf-dhc-dhcpv6-yang-24: (with COMMENT) X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Dynamic Host Configuration List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jan 2022 14:53:17 -0000 --Apple-Mail=_AD970E9D-E45B-43DA-92B1-5C4910531605 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Zaheduzzaman, First of all, many thanks for your review and my apologies that it=E2=80=99= s taken so long for me to reply. To your point below, RFC8987 will be included as a normative reference = in the next update. Thanks, Ian > On 16. Dec 2021, at 09:41, Zaheduzzaman Sarker via Datatracker = wrote: >=20 > Zaheduzzaman Sarker has entered the following ballot position for > draft-ietf-dhc-dhcpv6-yang-24: No Objection >=20 > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut = this > introductory paragraph, however.) >=20 >=20 > Please refer to = https://www.ietf.org/blog/handling-iesg-ballot-positions/ > for more information about how to handle DISCUSS and COMMENT = positions. >=20 >=20 > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-dhc-dhcpv6-yang/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > Thanks to the authors for their diligent efforts on this document. I = really get > impressed by all the YANG model documents I review. I don't think I = have much > to comment to improve this specification or something that I am = worried about. >=20 > I however, think RFC 8987 should be in the normative reference as it = is > referenced from the "RPCs" section. You can let me know it should not. >=20 >=20 >=20 --Apple-Mail=_AD970E9D-E45B-43DA-92B1-5C4910531605 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Hi = Zaheduzzaman,

First of all, many = thanks for your review and my apologies that it=E2=80=99s taken so long = for me to reply.

To your = point below, RFC8987 will be included as a normative reference in the = next update.

Thanks,
Ian


On 16. Dec 2021, at 09:41, Zaheduzzaman = Sarker via Datatracker <noreply@ietf.org> wrote:

Zaheduzzaman Sarker has entered the following ballot position = for
draft-ietf-dhc-dhcpv6-yang-24: No Objection

When responding, please keep the subject line = intact and reply to all
email addresses included in the To = and CC lines. (Feel free to cut this
introductory = paragraph, however.)


Please = refer to https://www.ietf.org/blog/handling-iesg-ballot-positions/for more information about how to handle DISCUSS and = COMMENT positions.


The = document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-dhc-dhcpv6-yang/



---------------------------------------------------------------= -------
COMMENT:
---------------------------------------------------------------= -------

Thanks to the authors for their = diligent efforts on this document. I really get
impressed = by all the YANG model documents I review. I don't think I have much
to comment to improve this specification or something that I = am worried about.

I however, think RFC 8987 = should be in the normative reference as it is
referenced = from the "RPCs" section. You can let me know it should not.




= --Apple-Mail=_AD970E9D-E45B-43DA-92B1-5C4910531605-- From nobody Fri Jan 28 06:54:59 2022 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC8063A11AF; Fri, 28 Jan 2022 06:54:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gmx.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CnW3DotRdg96; Fri, 28 Jan 2022 06:54:20 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8103D3A11D5; Fri, 28 Jan 2022 06:54:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1643381653; bh=9/diFugNoalQyNaPjmLoAcwjaqfsfPhsNMzYmuEXcUw=; h=X-UI-Sender-Class:Subject:From:In-Reply-To:Date:Cc:References:To; b=QerCUl6KpesYWYJRYqAdC1HeeLXmgaWUEcELYwLwCe/uCsFxPcc0uVJOU4MZ3Oeef yB3e4StIZwZzy7BuDdfqvajMupjTqxD14o68zmhVbJaNJpsqjmZ4qclPQvNJ6M2wB+ 08k3x2gqdkk6vJTtbGPqGGUihx5M4X/cBlpHnzQk= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from smtpclient.apple ([78.35.54.88]) by mail.gmx.net (mrgmx104 [212.227.17.174]) with ESMTPSA (Nemesis) id 1MowGU-1mSugU3RYk-00qRnm; Fri, 28 Jan 2022 15:54:12 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 15.0 \(3693.40.0.1.81\)) From: ianfarrer@gmx.com In-Reply-To: <163966610986.326.18125841975372071697@ietfa.amsl.com> Date: Fri, 28 Jan 2022 15:54:10 +0100 Cc: The IESG , dhc-chairs@ietf.org, draft-ietf-dhc-dhcpv6-yang@ietf.org, dhcwg@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <163966610986.326.18125841975372071697@ietfa.amsl.com> To: Robert Wilton X-Mailer: Apple Mail (2.3693.40.0.1.81) X-Provags-ID: V03:K1:P/bYfWO9ytKy5Z7m/NRk+wazzWyxTwDRGttXYiLtJXsBpur8Uym TL4+3pYRiKdRnwP8zGe5n/YHcf5T3OFmPeg48Iv4lIbRE20s3RFJxM+6aGzu3CRAQfHAFYE M295mPlfswYMzPuz+g5WRs+TtRpWKjfKCjcgfTQcp92O0SVAT/Y7z7ARkmsQgQGQpah+5cx IZ3Lfftzdk1ZVuuU1b9sg== X-UI-Out-Filterresults: notjunk:1;V03:K0:Chfr26/LiNg=:98TajsNpU3qB33D3GyY0Cl 6gbYksonwWvp2ybRH3jl4STLKSxp2M0OwCLqhSFT9xrAXI56pnXb5qwZO3PBgU7kQPP7QpQ0J LafvII2kzCm/5pYf8yvz8kCJ/Pah+KEm/IWDQZARGlUP2UojcPVOyJzWWAprUJovyv5h6Ydl4 pypdp0szIakPVRPVXypRAktWy/DVoaOkH9xXyveCDaW4YO+L1BhA7Fkmfvc79AKZkrwLU7Kdn /WEVSm58JibPz7v/D+Gz0CGAru7QIDEfIWRpxqQkehqumnVz9pbmD47Ym/4HVqkGkEaqkQdf0 ZW0XH2cUVc37DjqKLXOtBjpxf58WttoXUmafnMezTEVz1RcfNBYH24U/arsEd5zVVFNzSgFgD NVgVr9KLYYpxQQLikO2KUbHYNy7M7BfnoOw9qee7ufpwie1o4lQ1sUAR2M332zwYxsQ+3vfP+ bss/mobUfgFhd3UnwsTD+CIg/jzEqCB23atuMxqUbgbBIY7GcRRw8eDl7RUcKsxpkp0N1Jqe5 hLmu/3jsD8rJt8n5fWpTFYDDmoO2sNLlBT0LJkVrnGvlqUHtcGnrXDwuTJfhEpPcalNWeONaJ 0X+7r7UESRfrtmxGG+b+SwcpkyeIz4qz/Nc+Kgb+Xgl8D7iSXf76y7jkfc2A5yV18j7c2ARIL fUWCXuEVK2dpDfeBJuM396bOuD7/WEIKYGFfpt+g8VU6eHlQmQbsms3OB19qMcfEkgU7g6O2H dNTF+N0x8I/9Vj+K2474BNv9lNZ4aSPLxYEpsdjCJnpTfAoBa2qoYLtKYLkoj0ATmkknZGCgt J93GnsgWuE6HC2VOR4aslyAGv3z99jtS3ihq0Qyrb/HvAEIwrsEXkCFpTnkzidY/WyofK9/xk e693nh2hWVQ9NpO/JZDzRpH6GhSYtDAjhbBlrH0qNGNB5OCoZDyCyYfjRqfLfaaHXr5ix9KaA E0p5k6tD81gitNaxq6VyAkO3fe8T2pGOqOUxxjqkK0G7vTqClmnjGVslEGMu5D7/iSXSuTDr2 QNpuj0FhKC2J8HpdUP81NyfyMCpJfpO+HcWx+wk851IBP2HpCOQXijK/wEWhZBoxRCwd609vl otCNlPzycigbVc= Archived-At: Subject: Re: [dhcwg] Robert Wilton's No Objection on draft-ietf-dhc-dhcpv6-yang-24: (with COMMENT) X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Dynamic Host Configuration List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jan 2022 14:54:25 -0000 Hi Rob, First of all, many thanks for your review and my apologies that it=E2=80=99= s taken so long for me to reply. The suggestion you have made will be in the next update. Thanks, Ian > On 16. Dec 2021, at 15:48, Robert Wilton via Datatracker = wrote: >=20 > Robert Wilton has entered the following ballot position for > draft-ietf-dhc-dhcpv6-yang-24: No Objection >=20 > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut = this > introductory paragraph, however.) >=20 >=20 > Please refer to = https://www.ietf.org/blog/handling-iesg-ballot-positions/ > for more information about how to handle DISCUSS and COMMENT = positions. >=20 >=20 > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-dhc-dhcpv6-yang/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > Thanks for publishing another YANG module. >=20 > I found this document well written, and in particular I thought that = the > section on options extensibility and examples in the appendix to be = thoughtful > and helpful. I =E2=80=8Bonly have a few minor (non blocking) comments = on the structure > of the YANG module that you may wish to consider: >=20 > 1. You may want to consider putting the counters under a container to = group > them together, and perhaps to make it easier for a targeted telemetry > subscription. [if - Added statistics containers for client/server and relay (global = and per-interface)] >=20 > 2. The paths on your RPCs and top level Notifications are using = relative paths > - it would probably be clearer to use absolute paths here. [if - Changed to absolute.] >=20 > 3. I would remove "container" from the Option description strings, to = improve > help string readability. [if - removed] >=20 > 4. Please make sure that you fix the 3 idnits YANG warnings (e.g., = alignment of > the revision-date to the extracted file date). [if - Fixed] >=20 > Perhaps in a future draft the IETF will manage to standardize common > configuration for the class selection function since that will help = interop but > I can appreciate that is tricky to get consensus on if the existing = models/CLIs > are far apart, and you seem to have taken a pragmatic approach here. >=20 > Regards, > Rob >=20 >=20 >=20 > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg From nobody Fri Jan 28 06:57:05 2022 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0AF3E3A16D9; Fri, 28 Jan 2022 06:57:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gmx.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4cSjXFnqK4kf; Fri, 28 Jan 2022 06:56:57 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E91923A16D6; Fri, 28 Jan 2022 06:56:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1643381807; bh=c5Iid3LWgjate280v1FVxYOQFb+f/ALvMjB4GqAGQsk=; h=X-UI-Sender-Class:Subject:From:In-Reply-To:Date:Cc:References:To; b=fSULaK1bJWsmIbMHDYbp7ORrSg41gIkNsS43q2RXoFVGP6PajrA01oQ/FSYaSlqfD PB6AOhoCz+2wtLEr/ZWdKVZbuiueyyUC0U6bMYcF00dlFhqJo5Dj6+6w5gSvdDLGHD GVWzinrz0GY7jMPuG8b7EyEscd2D9GLwZCyuq/NQ= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from smtpclient.apple ([78.35.54.88]) by mail.gmx.net (mrgmx104 [212.227.17.174]) with ESMTPSA (Nemesis) id 1Mn2aN-1mVMPw2aXf-00k6mS; Fri, 28 Jan 2022 15:56:47 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 15.0 \(3693.40.0.1.81\)) From: ianfarrer@gmx.com In-Reply-To: <164271160981.14773.8936457326359214955@ietfa.amsl.com> Date: Fri, 28 Jan 2022 15:56:46 +0100 Cc: yang-doctors@ietf.org, dhcwg@ietf.org, draft-ietf-dhc-dhcpv6-yang.all@ietf.org, last-call@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <6E8F4879-E8BA-4EC7-972E-528A0F932D76@gmx.com> References: <164271160981.14773.8936457326359214955@ietfa.amsl.com> To: Acee Lindem X-Mailer: Apple Mail (2.3693.40.0.1.81) X-Provags-ID: V03:K1:7qZFVLFQj4pujisivCOnJ9Z07IOLlzHVen2n2Yd8MEvD8gWwHgs +NY+chbLosANR6RNfArWu0dHUSJwcKeC2CBLyimMz3v4DPLcG1Gq0pRup97rHlGeew3LDsa MqZD1FqijmOFrZq64ceq4xxUpz9fsLdqGpT0gjsmAfyxOb8oZxvWmyx2RiEMdwBy8yVGcDu gjz9HJSP2d+FRGQZ0FuPw== X-UI-Out-Filterresults: notjunk:1;V03:K0:DmA3mcp7L6o=:mmwt8T7bKO++xisOQyFrBd hcgc5P10CH0qD3vY75RgrdJIkyv/GumXeVUjeFp6uMd9DGYLAQ6LIIpNrSxY9y+Ql+TQXp0Bm ONSRNyFH+VWRDOsMYB92ukZy1Hags9Z2EPLRX3lXDICi6d234l4vrwYhmLB/02nSPRelVLhyz ijUieenDP29ZQBWUiTykWEBgcTC1PXKBELLpojaIUsUGpPbtMOIzySe9nBgeaNmVLKyCEMQgU 425Xrl2uHDhVSQMGsBo1n+UCQFS/EfMvE4Hl5yIw+0E6spJAQXyFRhamj87gR5rh6locp8lhN uRTAEMFBKnn5vGhdaiRqr2M2/62C0ClqMZ1o9bXsFjzgKc+nMSORwfNSFdwsZWaw9Wr+0+a3s +hNcsnZMutzUbehwzaU6ub5ppcUGQzw4HqLJGHavtkeJGqPjirwyJWKLbLgjPzS/JeVeNS5Yi t+akVWaKhe7a1EL9rMowE/t/iBlzDqBDwtNM7cVFCIw/RFW86T16uC+8bwSZQGTHJ9cX0uLtS jrtdWILHFFn3KCF3YS/y8a5Nb3AdqtFAy+hjEjHqPoJFzx+7GZNisqUjO2JeAQ8RS97q6NDJ1 RzP4VCq/4THJ6UvOcwIo5VWzMYaaWCgN5RRqxzDFLy8GoiA9zkoJXbqrMZOIEYOensLyq3Lr6 iRAJABko/pGUquHNKKnynEdYFX/vvk48OQ9LqPfc5O3PCTkPMqSjxVVaV6GruPX7yZ5icNaCV JEjwzFftx7r+dVY8wsrCJ4pzuG7mqQBV8RLyoTFjRulCtamVwzLKdAFbSZmy2uBgm6pw7wB13 uiAIsAyRlXuHid8aXV4m3GtJjYMUr0kiAbgEBPCXWA0HgOk5NqAXlYCoMEr5bYFnCxHq0+IdJ 1UC1nfVyXkgloJ5BJu7nPsVePFpi4jgA7JlgL5Qm9B/4y/pXrz1gB9dCb7VJwjqpDWe/ZGYi5 WYXxtjL49jNU0O8cCn+5VNqXyT3RSqtJm4xNch/04Mhz7GvP0gWciHZ96C4D0YZs+nJ7gKeJE e32sNxDZwvFfGzbC3w5dhtoPt9Dappj07GIdMdq4B2CcL/aEmNAEoryOvUrsPdk2ikxdVdz4N PV39bDYUJ7rc0E= Archived-At: Subject: Re: [dhcwg] Yangdoctors telechat review of draft-ietf-dhc-dhcpv6-yang-24 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Dynamic Host Configuration List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jan 2022 14:57:02 -0000 Hi Acee, They=E2=80=99ll be fixed on the next update. Thanks, Ian > On 20. Jan 2022, at 21:46, Acee Lindem via Datatracker = wrote: >=20 > Reviewer: Acee Lindem > Review result: Ready with Nits >=20 > Please fix YANG error: >=20 > yanglint SO 1.6.7: yanglint --verbose -p {tmplib} -p {rfclib} -p = {draftlib} -p > {ianalib} -p {cataloglib} {model} -i: warn: File name > "ietf-dhcpv6-common@2021-11-18.yang" does not match module revision > "2021-10-25". >=20 > Thank you for fixing the comments from my early review. >=20 >=20 > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg