Re: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-yang-18.txt
tom petch <ietfa@btconnect.com> Tue, 23 March 2021 11:38 UTC
Return-Path: <ietfa@btconnect.com>
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 A93223A0F4A for <dhcwg@ietfa.amsl.com>; Tue, 23 Mar 2021 04:38:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_MSPIKE_H2=-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=btconnect.onmicrosoft.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 2nRtMF_DU1HK for <dhcwg@ietfa.amsl.com>; Tue, 23 Mar 2021 04:38:29 -0700 (PDT)
Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-eopbgr150123.outbound.protection.outlook.com [40.107.15.123]) (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 AE2D63A0F41 for <dhcwg@ietf.org>; Tue, 23 Mar 2021 04:38:28 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=khrvLUUp9JIRzctucuR9F3UduPUHaqbnhV2Lsi5EQ/AwPjF/0bHYSHbxGvGXb3MJ4cZPuV7P4tzNjh4t/9j05GW0kILpC3SEy9tt/HvwcDeSy8bCI8cS/6iW3bPJ17Km9f3XP5umsbErGpoflfruzPNqPQyv+790Jt8JzFARRgSPuVe3Xm3s1yc9IQy/ko0RroX6CyoT9ro4pXN8vkeeEqUY1Mwa1XruJ4MK7pw0pw3JmbY9KEt8cuR8miChbO5NEqciN8rSLLhdTbdCZLyt/uV+QkPa0+x7gA/G5A8fPnkTrYZ9dNez1sHlApNySOvrG03lPx6h4/JmBLU0Yu0Qwg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=oxaPjJwL9UeOsbu3JEM74+/KKNx/Zdeiki1w2HbyAH8=; b=GEesdG52Cdsurb3unl/IYjF6SKh9Jpc2tc+cw1HmWAGgBUG362v5xhxt39VzGj5/DXeWO8cKp1MWMt1W0ZhdjBY3xTcYaR4Z3b3KY1OGH5uhKHn6iDzes7z+HTEyC/v+e2039gpuQtgeaOBtspbMaD/Oze/kI9KlhV/SNBhHJVqbZHiSe3qA1pebIPNQTb46dDngugRFlLjm0eRP/yNEHKyciRxso48++S7f7f6MD6wOVYZbgVA5zvcjoABxb4HrpS5Nj4JUbiACosmrlMOgTNE5Ub4NdYF1dqF9+YNCd29kSQHNcwIabsQBV5/CagBOGu2WRDO+mmFQlR+ZdsYpsg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=btconnect.com; dmarc=pass action=none header.from=btconnect.com; dkim=pass header.d=btconnect.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btconnect.onmicrosoft.com; s=selector2-btconnect-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=oxaPjJwL9UeOsbu3JEM74+/KKNx/Zdeiki1w2HbyAH8=; b=GnIEBLLu1yjnSjwyiVmbhWeMelC3/F43V6WbWdQ3RgJKrLVdkHfX82FrwZJJrGt8yw/Vp/AJniWp/LEDme7Qo63YHo23Rk0ekIs0obdO5VbW5NDXJAgRh7TnbfMscjXFnIx45bVGbL4lMNG4HNcFd6IiGB3N4+m2aLWQQ9gqD78=
Received: from DB7PR07MB5546.eurprd07.prod.outlook.com (2603:10a6:10:73::23) by DB7PR07MB4105.eurprd07.prod.outlook.com (2603:10a6:5:9::31) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3977.9; Tue, 23 Mar 2021 11:38:23 +0000
Received: from DB7PR07MB5546.eurprd07.prod.outlook.com ([fe80::e5d9:cd75:1ebc:a236]) by DB7PR07MB5546.eurprd07.prod.outlook.com ([fe80::e5d9:cd75:1ebc:a236%4]) with mapi id 15.20.3977.024; Tue, 23 Mar 2021 11:38:23 +0000
From: tom petch <ietfa@btconnect.com>
To: "ianfarrer@gmx.com" <ianfarrer@gmx.com>
CC: dhcwg <dhcwg@ietf.org>
Thread-Topic: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-yang-18.txt
Thread-Index: AQHXD2E4C4r5dtHlj0KTwU8szLGhbqpzyA0AgBRzaICACVYnHg==
Date: Tue, 23 Mar 2021 11:38:23 +0000
Message-ID: <DB7PR07MB55464BEC59F099DA8F6BCB2CA2649@DB7PR07MB5546.eurprd07.prod.outlook.com>
References: <6019394A.8010303@btconnect.com> <603E3235.10501@btconnect.com> <6040D4FC.2020903@btconnect.com>, <4C148BE5-19FB-47E7-92D3-C4870A174BE7@gmx.com>
In-Reply-To: <4C148BE5-19FB-47E7-92D3-C4870A174BE7@gmx.com>
Accept-Language: en-GB, en-US
Content-Language: en-GB
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: gmx.com; dkim=none (message not signed) header.d=none;gmx.com; dmarc=none action=none header.from=btconnect.com;
x-originating-ip: [86.146.121.140]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 67c52b1e-0e01-43ad-edfb-08d8edf02a81
x-ms-traffictypediagnostic: DB7PR07MB4105:
x-microsoft-antispam-prvs: <DB7PR07MB4105737AE91333A8A05AD55BA2649@DB7PR07MB4105.eurprd07.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:8273;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: XFzyeDYRTmNQZy5ZcP1O78qUai3S/BQn1Ml3vPWGy57Xk2RPt8/JbGZbxcsBblSiiiNxpNBpSVpKmFaEiFldUyGF/eS/1cG8tpFjLIzkyab8k8HRGa0bztsfqbVw50w6eiufL+YbmeOdKH8bhX2DpGBr6gwzE/P0ncCSBXRaGIvItgr/jOmgzDORm6HsD3rXJ1BVVmsG7DFAV50pVIUtOs7/x1nRYYBx7QBkBwi5/Nx8KEoSG2PMj3VgU2GdcqHO3Kt+YB9J7nBe/a7m6SbRd73Lb6Ej6qQKlDEPpC6uVb1XGgc3P0BDNvdowGwAwTWfo2Ph1AL/9VxvsCwLSlQpz6IKC5qlswNdes3cju5p4qK8HGCFwqcbmUISUQr33GXnirAcMfLbJY1kbkZDBSgPpfpJu/9mC7P8GHXEM3YzkuSX+wq3jtV/r+RcPU3o90xsUjkg7mJ88DkfWokgrcLDD1scOLvsQjpr6KMGK+UOjyVwfFHW8FGQfJKlWTVBPC0JSmualm+jPgUG4VIGXAwq8jEbCrO907TX7mFZokyrP62qkisF3NZRDLpINqcREtVLoAsMX/yeQxW393wQ2ZjCJAsLDP0kJcQrTEyS6RyvZ+mynw1QrpOOTul90no29LW9CvT0l1OOG6HQhB7lgRhMRB1VblFVxTwzpLjpSx+B6Qidu2c/XQbO8Mj827qNxtz9
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DB7PR07MB5546.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(136003)(346002)(376002)(396003)(39860400002)(366004)(76116006)(66556008)(186003)(91956017)(66446008)(53546011)(66476007)(66946007)(64756008)(52536014)(26005)(8676002)(6506007)(71200400001)(33656002)(316002)(86362001)(2906002)(4326008)(7696005)(6916009)(55016002)(5660300002)(83380400001)(30864003)(9686003)(478600001)(8936002)(38100700001)(518174003); DIR:OUT; SFP:1102;
x-ms-exchange-antispam-messagedata: A+8XPOjwTZ5y1C4l/YP4MhU+lWhYWAC3WRGIHVBjQwN+MidfQwb+L5fYRTMJmIa+4SjofeNEK5H1kiq+8thGly42HgIwpdcuK2PiIvwUc5aK1jOtSgbtoV4VarGNRJdeApgzeCnyJrnnCwrmNSwkZjMuBpwouwfnDIZncXI1HUzfd9odcon+DAPrvjgkkY4BztrKOu8GnhmJs09wRLji+r11nDOx2kMPIr41oQNfVz6z/sL9u5oqBoDsb54zek897Hjf96Q8MjsJWwXs44IAB8QPA79MwvcSJTEv6qeNarAE5GBCZ+H0DQU8M9sWrPuwFNb4ur0LVgp0sMzIoQbLTcKgQuUQSYWh4qY1vKlrJ+aQqqkXtP2r0wNr+ffcISlhTIlwVnkZQ0HKOrlL6KldMFb4NFfHSctbBi8iu3yTF0AJjO6+sd/1SyZ8TVqloO/79rLBQT3XkJvXsTqFPjTN5taoCR8Ruqyl9VpCMbbEfhtv/Jl9mOXzhbhTWnQrAiH+vr27GzlMMLY62GGSL1x9Muwc1ha42P78Vtp1QPM6J2Jio5dnXKSESPrRDki043SVzIWZaRfIUxAMrRSD44QNYLWA85wukdpe7UM4iA+VttjPAP2NIS5IwFXcxDRSmCm2z+lfS+KJMzbnbEgUrQn0K7AkEfx/3zuxcecx8TB9XZF7yP5MNTzhu5l8E/pihq6XoSWRROdtKdYuvcxv6E95qOF0oJOnX5Xx95jkRAcbfQw=
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: btconnect.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: DB7PR07MB5546.eurprd07.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 67c52b1e-0e01-43ad-edfb-08d8edf02a81
X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Mar 2021 11:38:23.2088 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: cf8853ed-96e5-465b-9185-806bfe185e30
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: +MapWkWSRgIiPxKIzFqCvkOu06YGEZK73bOqJzN38G83Nbjrg+IN+P8RKHYh88q5dT11NoPEOUnMSRXN1VYFcA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB7PR07MB4105
Archived-At: <https://mailarchive.ietf.org/arch/msg/dhcwg/eNvXBitmh9urvSjhcacAbDzbVx0>
Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-yang-18.txt
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <dhcwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dhcwg/>
List-Post: <mailto:dhcwg@ietf.org>
List-Help: <mailto:dhcwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 23 Mar 2021 11:38:34 -0000
From: ianfarrer@gmx.com <ianfarrer@gmx.com> Sent: 17 March 2021 12:57 Tom, Thanks for your review. I’ve just posted -version -19, please see inline below for details on the changes in this version. <tp> Looks good. On the question of auth information, some use string, some use binary, some use hex, It is a question of what users are used to and how much entropy you can pack into a given space. So, leave it as it is unless someone demands a change. One small point. In two places you have end-address minus start-address for the total number. Should that be 'plus one'? ie is 10.1.0.0 to 10.1.0.255 255 or 256? Tom Petch Ian > On 4. Mar 2021, at 13:39, t petch <ietfa@btconnect.com> wrote: > > On 02/03/2021 12:40, t petch wrote: >> Ian > > Ian > > I have now been through all four modules and have the following comments in addition to my last message. (A bad habit of mine that I seem unable to break is that I never see everything the first time, or the second, or.... but this is all I have so far:-) > > Carrying on with dhcpv6-server, there are parts that I do not understand. Several relate to threshold as defined in common as an integer percentage but I do not know how it is calculated. > > leaf max-address-count > maximum number of addresses > but it is type threshold not a count, a number and how is it calculated? something over (end-address less start address plus one)? [if - Renamed and description updated: leaf max-address-utilization { type dhcpv6-common:threshold; mandatory true; 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)."; } > > leaf-max-pd-space-utilization > if the pool prefix is /48 and client-prefix-length /56, then how do you arrive at an integer percentage if e.g. 173 prefix out of 256 are in use? round up, round down? [if - Reworded description as: leaf max-pd-space-utilization { type dhcpv6-common:threshold; mandatory true; description "Maximum amount of the prefixes in the pool which can be simultaneously allocated, calculated as a percentage of the available prefixes, rounded up."; } ] > > two notification for 'threshold-exceeded' one for address, one for prefix. > For address, you have three counts, total, max, allocated; how do these relate to the objects defined earlier under address-pools? [if - Reworked: notification address-pool-utilization-threshold-exceeded { description "Notification sent when the address pool utilization exceeds the threshold configured in max-address-utilization."; leaf pool-id { type leafref { path "/dhcpv6-server/network-ranges/network-range/" + "address-pools/address-pool/pool-id"; } mandatory true; description "Leafref to the address pool that the notification is being generated for."; } leaf total-pool-addresses { type uint64; mandatory true; description "Total number of addresses in the pool (end-address minus start-address)."; } leaf max-allocated-addresses { type uint64; mandatory true; description "Maximum number of addresses that can be simultaneously allocated from the pool. This value may be less than count of total addresses. Calculated as the max-address-utilization (percentage) of the total-pool-addresses, rounded up."; } leaf allocated-address-count { type uint64; mandatory true; description "Number of addresses allocated from the pool."; } } ] > For prefix, you have max-pd which does point to an earlier definition which is a threshold ie percentage but pd-space-utilization is uint64 and so clearly not a percentage > I see inconsistency of names and of the objects used in the notifications which so I am confused > [if - Reworked: notification prefix-pool-utilization-threshold-exceeded { if-feature prefix-delegation; description "Notification sent when the prefix pool utilization exceeds the threshold configured in max-pd-space-utilization."; leaf pool-id { type leafref { path "/dhcpv6-server/network-ranges/network-range/" + "prefix-pools/prefix-pool/pool-id"; } mandatory true; description "Unique identifier for the pool."; } leaf total-pool-prefixes { type uint64; mandatory true; description "Total number of prefixes in the pool."; } leaf max-allocated-prefixes { type uint64; mandatory true; description "Maximum number of prefixes that can be simultaneously allocated from the pool. This value may be less than count of total prefixes. Calculated as the max-precfix-utilization (percentage) of the total-pool-prefixes, rounded up."; } leaf allocated-prefixes-count { type uint64; mandatory true; description "Number of prefixes allocated from the pool."; } } ] > invalid-client-detected > I assume this is the result of a message in which case message type would be useful. [if - Added an enumeration for the message type] > > delete-address-lease > should this point to an entry in the database? > I see that objects named -lease are state data not configuration so I am unclear what is being deleted > [if - Now modelled as: leaf lease-address-to-delete { type leafref { path "../../dhcpv6-server/network-ranges/network-range" + "/address-pools/address-pool/active-leases/active-lease" + "/leased-address"; } ] > delete-prefix-lease > ditto [if - Now modelled as: leaf lease-prefix-to-delete { type leafref { path "../../dhcpv6-server/network-ranges/network-range" + "/prefix-pools/prefix-pool/active-leases/active-lease" + "/leased-prefix"; } I’ve also added a leafier in the relay module for the clear-prefix-entry roc: leaf lease-prefix { type leafref { path "/dhcpv6-relay/relay-if/prefix-delegation/pd-leases/" + "ia-pd-prefix"; } ] > > > dhcpv6-relay > > feature prefix-delegation > I think 6.3 a better reference > [if - done] > leaf link-address > RFC s.9.1 appears to specify 16 octet, not binary 0..16 [if - now modelled as: leaf link-address { type string { pattern '[0-9a-fA-F]{32}'; } ] > > notification relay-event > the description of this would seem to make it applicable to servers as well as relays [if - The configuration of the implementation specific elements of server configuration (including listening interfaces) is only given as an example module in the appendix. Notifications related to server interface / topology changes would be part of this.] > > clear-prefix-entry > the reference is now RFC8987 which needs to be in the I-D references; this appears in other reference clauses [if - updated] > > clear-interface-prefixes > should the input interface-ref be to part of the DHCP configuration rather than to any interface? [if - changed to path "../../dhcpv6-relay/relay-if/if-name”; ] > > > dhcpv6-client > > list user-class-data > list plural, entry singular, but I wonder how many AD know their Latin? [if - The list has been renamed to user-class-data-instances with user-class-data-id and user-class-data.] > > container-ia-na-options > perhaps client may send, rather than will [if -changed] > > container-ia-ta-options > ditto > [if -changed] > invalid-ia-detected > I cannot find this in s.18.2.10.1 nor does it seem right to me. This is client module so how does a client find itself to be invalid? > The description does not help me either! [if - It was meant to be for address conflicts. I’ve reworded the description as: notification invalid-ia-address-detected { description "Notification sent when an address received in an identity association option can be proved to be invalid. Possible conditions include a duplicate or otherwise illegal address."; reference "RFC 8415: Dynamic Host Configuration Protocol for IPv6 (DHCPv6), Section 18.2.10.1”; The rest of the notification has also been re-worked to contain the rest of the info in the address allocation (timers etc.).] > > MRC-exceeded > MRD-exceeded > s.7.6 offers a choice for each of these for different counts/timers so I think that the data notification should be more explicit and a message type would help as it would with many such notification [if - I’ve reworked the notification as follows: notification transmission-failed { description "Notification sent when the transmission or retransmission of a message fails."; reference "RFC 8415: Dynamic Host Configuration Protocol for IPv6 (DHCPv6), Section 7.6"; leaf failure-type { type enumeration { enum "solicit-timeout" { description "Max Solicit timeout value (SOL_MAX_RT) exceeded."; } enum "request-timeout" { description "Max Request timeout value (REQ_MAX_RT) exceeded."; } enum "request-retries-exceeded" { description "Max Request retry attempts (REC_MAX_RC) exceeded."; } enum "confirm-duration-exceeded" { description "Max Confirm duration (CNF_MAX_RD) exceeded."; } enum "renew-timeout" { description "Max Renew timeout value (REN_MAX_RT) exceeded."; } enum "rebind-timeout" { description "Max Rebind timeout value (REB_MAX_RT) exceeded."; } enum "info-request-timeout" { description "Max Information-request timeout value (INF_MAX_RT) exceeded."; } enum "release-retries-exceeded" { description "Max Release retry attempts (REL_MAX_RC) exceeded."; } enum "decline-retries-exceeded" { description "Max Decline retry attempts (DEC_MAX_RT) exceeded."; } } mandatory true; description "Description of the failure."; } leaf description { type string; description "Information related to the failure, such as number of retries and timer values."; } } ] > > server-duid-changed > a good case for a notification but I cannot see it described in the RFC [if - I’ve updated the description and the reference: notification server-duid-changed { description "Notification sent when the client receives a lease from a server with different DUID to the one currently stored by the client, e.g. in response to a Rebind message."; reference "RFC 8415: Dynamic Host Configuration Protocol for IPv6 (DHCPv6), Section 18.2.5”; ] > > Tom Petch > > >> I put your last e-mail to me somewhere safe, too safe for me to find >> just now. So, I am going through -18 and thoughts so far >> >> I like the treatment of DUID. >> >> IANA status codes needs adding to the I-D references [if - Done] >> >> server-module (part-reviewed) >> prefix-delegation >> 6.3 would seem a better reference than 6.2 >> [if -Changed] >> rapid commit >> 5.1 might be better than 5.2 >> [if - Changed] >> leaf id >> Equivalent to subnet ID >> I do not understand this, nor do the RFC uses of subnet enlighten me [If - Description now reads: "Unique identifier for the network range.”] >> >> >> common module >> You have a MUST in the common module which means you should have the >> RFC8174 text in the module as well [if - Included] >> >> duid-base >> why a length of 260? RFC allows 128 which sort of suggests two-byte >> character sets! [If - Replaced the length statement with pattern '^([0-9a-fA-F]{2}){3,130}$’; The length is 130 to include the 2 octet type as well. ] >> >> between 1 and 128 bytes >> RFC has octets so I think that better [if - changed] >> >> duid-unstructured >> I do not understand what the pattern is doing here [if - The pattern allows you to define any set of values except ones with 0001-0004 in the DUID-Type field which need to follow the formats for their corresponding defined type type] >> >> OPTION_AUTH >> the RFC references auth-namespaces so I think that this should too here >> and in I-D references [if - Added references] >> >> I note that this uses HMAC-MD5; I do not know how Security ADs view >> this; it may need a note in the Security Considerations >> [If - I’ve checked RFC8415 and it isn’t mentioned in the Sec. Section there. I’ll add something if it’s flagged at the review stage] >> auth-information >> string or binary? [if - The format of the contents depends on the authentication protocol that’s being used. Is binary a better choice here?] >> >> sub-optiondata >> again string or binary? RFC does not help me here >> I note that there is a two octet length field ie 65535 max [If - I’ve left it as string and reworked as; type string { pattern '([0-9a-zA-F]{2}){,65535}’; ] >> >> More to come. >> >> Tom Petch >>
- [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-yang-17… internet-drafts
- Re: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-yan… ianfarrer
- Re: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-yan… t petch
- Re: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-yan… ianfarrer
- Re: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-yan… t petch
- Re: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-yan… t petch
- Re: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-yan… ianfarrer
- Re: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-yan… tom petch
- Re: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-yan… ianfarrer