Re: [dhcwg] Roman Danyliw's No Objection on draft-ietf-dhc-dhcpv6-yang-24: (with COMMENT) Mon, 24 January 2022 13:38 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 87B423A003D; Mon, 24 Jan 2022 05:38:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.896
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: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id tAr9yb5EqXzN; Mon, 24 Jan 2022 05:38:31 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 4BF253A003C; Mon, 24 Jan 2022 05:38:30 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;; 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 ([]) by (mrgmx005 []) 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.\))
In-Reply-To: <>
Date: Mon, 24 Jan 2022 14:38:19 +0100
Cc: The IESG <>,,,, Timothy Winters <>
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <>
To: Roman Danyliw <>
X-Mailer: Apple Mail (2.3693.
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-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’s taken so long for me to

Please see inline below.


> On 15. Dec 2021, at 00:06, Roman Danyliw via Datatracker <> wrote:
> Roman Danyliw 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
> for more information about how to handle DISCUSS and COMMENT positions.
> The document, along with other ballot positions, can be found here:
> ----------------------------------------------------------------------
> ----------------------------------------------------------------------
> Thank you to Vincent Roca for the SECDIR review.
> ** (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’t
> appreciate that this regex was operating on a string containing a hex
> representation of octets.

[if - I’ve added the following text to the ‘duid-base’ description:

Type 'string' is used to represent the hexadecimal DUID value so that pattern constraints can be applied.]

> ** 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:
> -- Section 4.1. grouping status and status-code-option-group has a leaf message
> -- Section 4.2. rpc delete-address-lease and delete-prefix-lease return a leaf
> return-message
> -- Section 4.3. leaf return-message in the rpcs

[if - I’ve updated each occurrence of ‘return-message’ (2 instances in the server module and 3 in
Relay) with the following:

          "Response message from the server. If available, a language   
          identifier should be included in the message.";               
        reference "BCP 14 (RFC 2277) IETF Policy on Character Sets         
          and Languages, Section 4.2.";   

RFC2277 has been added to the normative references.]

> ** Section 4.1. grouping status has a leaf message which is explicitly
> described as of “type string” and is clarified as being a “UTF-8 encoded string
> ... that isn’t null-terminated”.  No issues with that guidance.  I’m 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.]

> ** Section 5.  Additionally threats to document would be:
> -- Generalize the threat of redirecting clients to services under the
> attackers’ control (e.g., DNS server or WPAP).  Say:
> * 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.
> * 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’s control. For example, changing
> the address of a DNS server supplied in a DHCP option to point to a rogue
> server.

[if - Changed]

> -- Ability to read the leases from the Server or Relay could help the attacker
> fingerprint device types.
> These subtrees and
>   data nodes can be misused to track the activity of a host:
> These subtrees and data nodes can be misused to track the activity or
> fingerprint the device type of the host:

[if - Changed]