Re: [dhcwg] Benjamin Kaduk's Discuss on draft-ietf-dhc-dhcpv6-yang-24: (with DISCUSS and COMMENT) Tue, 01 February 2022 19:30 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B852D3A0856; Tue, 1 Feb 2022 11:30:25 -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, 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] 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 Mp-XxKETmqwA; Tue, 1 Feb 2022 11:30:20 -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 5C33B3A089A; Tue, 1 Feb 2022 11:30:20 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;; s=badeba3b8450; t=1643743816; bh=eboJw6/QGdDF05y08TJe/6aWyeq0P3DNCE1q4xa1vpI=; h=X-UI-Sender-Class:From:Subject:Date:In-Reply-To:Cc:To:References; b=f4XkEW10eGF+zj9ldXGLt7MSPM+MZWhVgTbPHFOWf3PpFvm61tFZu8tyx1FrZdwv6 o8X8ZEs5gS4ogCDjydBeEoFIjreQUjZ3b5WVl4IGOQeWHzspVitHCg0bQSOb/F2DlZ KplH7admdHBKjmgK/ZskFzQvO2jzQINbgKtT5+TY=
X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c
Received: from ([]) by (mrgmx004 []) with ESMTPSA (Nemesis) id 1MxUs7-1mHFbK2wCP-00xvPm; Tue, 01 Feb 2022 20:30:15 +0100
Message-Id: <>
Content-Type: multipart/alternative; boundary="Apple-Mail=_EC6C2424-F00B-40E5-B1F4-4042300DDDA6"
Mime-Version: 1.0 (Mac OS X Mail 15.0 \(3693.\))
Date: Tue, 01 Feb 2022 20:30:13 +0100
In-Reply-To: <>
Cc: The IESG <>,,,
To: Benjamin Kaduk <>
References: <>
X-Mailer: Apple Mail (2.3693.
X-Provags-ID: V03:K1:q5alHN1PzykcXcBx+qWSVwgHcbOT75I2TnnOMKBOQNVn5UeLmLr NJezema/0UEyd0ChZrFB/d2qWJ6EEnjKd/i82j3GusulcxIIC8dvlMtjYWig7B3P7M6HK9N YZNya2/ZXoq+lQt4YSJGH/RQRS2uG+r1kAL84u7wl9VWc0RidrSoP0IsCEh5gM1V4sCJvEu u+dY7Sd0QfYJZluE7Bjlw==
X-UI-Out-Filterresults: notjunk:1;V03:K0:9qi8WOgqW+4=:s5clrnLFDinRcQsenCCAG5 T55vBxZc5gWQO/WXCBAtzKYspAxS6GGC+tQTSMw53+T4X4kkQwRd0HnOvai2JKMQPjj8ZlFBr J6BTub3yN7mNRv5e1+AKd3Cp6EAkxRkQAaInvWaC2aw7UO2OFBKZ43Ec8FJSATcBRvq92B9c7 d9tE6/nI9hWyODfYMM0wq5ivedoe9f/PDV0vd4KB//7J0tSKlnVHlRtTXUFsiT38dQ+N+Yn9Z 9XGyfvD3WCeVgWINNF43hhmT6kZ/AbXSYP60GjKAljWzZtiqAVzrJNRZa+fDkN6YEA998JruJ egVwxWeS/cpjlOEd8uCdmzJE451wjkUahzchWQg60tzoF+DMcZfQBFjQsClIMje+91x/wGdYz 12Yk1XTLwkqUTIYTrEr7J+H1T6hbuzCJ8fV+9CW/rXtsL4t9nWCqbg7MYE6ZaMqS+lyouudMt 2M8ivH7ay1/7NEPd/ESWpQ3gewoI5oC6Zesy/EYpReNIOXHMwgixf1atmuI2eGxl/w3WkB0qj A8r+8P3iMYrXVmGHxNOLe09XsBPaz1UbO5WDA2htK8sNSGw2/Nl48OZQSnB07C7Ui3ucdLUHl HKqoEzQ1hKih9EiY/qKL8KeTUOm06A1fYWjsUfz0RE8OKLic6o+ZzN7HR0HOUwGWkZ2A2+oyE vSzjkuCqv06u580mNwklX27EQOp7Xm/JdW3blD+PTEbn43RRBm0+X9SWmFCnOZQjTj80Bx0Py hIEwXyj66QQHm4TVYgcdD19Tf/MldyDPtSdcax9sSgwFO7cFP4y1Bk8bFGWkdo3s9TujyqvYh AR8n/VsCICoOGZ8URs9Bb1Ta8STe12704LlYUsk1obr1o+ujeOihsQB4YQlPSEpxJukCtaX8W dKtZKJUHasGdFugzGvOTLJAYAK8DJLYSQ+/lssTx37Y4wb02kwBGSXxt4s2zRJe8FK5hndLTs v6AHTQg5XQb0BhQruqp50lfz6RnmCX/bqahlRImLPyoOHbFLWvKrMnW5y1V0kj+5EVVBbthX0 rPeDwMS4xxPP23TZmiipeUnO1hqWJ73LytqKECmWSODqbvDTtrZy15K5Hzf3DV9Ipy9ocm4n2 tXJZleU+FrwSFw=
Archived-At: <>
Subject: Re: [dhcwg] Benjamin Kaduk's Discuss on draft-ietf-dhc-dhcpv6-yang-24: (with DISCUSS and 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: Tue, 01 Feb 2022 19:30:26 -0000

Hi Benjamin,

Please see inline below.


> On 15. Dec 2021, at 01:07, Benjamin Kaduk via Datatracker <> 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
> for more information about how to handle DISCUSS and COMMENT positions.
> The document, along with other ballot positions, can be found here:
> ----------------------------------------------------------------------
> ----------------------------------------------------------------------
> 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 - In each of the cases that you identified (5 in total), the types have been changed to ‘binary’. I’ve checked through the models and you have identified all of the relevant instances in your review.

Here is a summary of the changes that have been made:

This is now modelled with a choice for the protocol type (conf-token or rkap). In both cases the relevant leaves (token-auth-information and auth-info-value respectively) are type binary.

sub-option-data -> binary

interface-id -> binary

-> user-class-data

-> vendor-class-data

For reference, here are the associated review comments:

    grouping auth-option-group {
      container auth-option {
        leaf auth-information {
          type string;
            "The authentication information, as specified by the
            protocol and algorithm used in this Authentication

This should probably be binary, not a string.  Or, if it needs to be a
string, it should specify an encoding (e.g., hex).


            leaf sub-option-data {
              type string {
                pattern '([0-9a-fA-F]{2}){0,}';
                "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


Section 4.3

    grouping interface-id-option-group {
       leaf interface-id {
          type string;
            "An opaque value of arbitrary length generated by the
            relay agent to identify one of the relay agent's

I think this is better as a YANG "binary" type than a string.  If not,
we should say something about the encoding.


    grouping user-class-option-group {
          leaf user-class-data {
            type string;
              "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;
                "Opaque field representing a vendor class of which
                the client is a member.";

(likewise here)