Re: [dhcwg] Mail regarding draft-ietf-dhc-addr-notification

Jen Linkova <furry13@gmail.com> Mon, 22 January 2024 13:56 UTC

Return-Path: <furry13@gmail.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 BCE22C14CEFD for <dhcwg@ietfa.amsl.com>; Mon, 22 Jan 2024 05:56:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.858
X-Spam-Level:
X-Spam-Status: No, score=-1.858 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, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EVfAL_ukcsua for <dhcwg@ietfa.amsl.com>; Mon, 22 Jan 2024 05:56:24 -0800 (PST)
Received: from mail-lj1-x232.google.com (mail-lj1-x232.google.com [IPv6:2a00:1450:4864:20::232]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5EB3EC14F70F for <dhcwg@ietf.org>; Mon, 22 Jan 2024 05:56:24 -0800 (PST)
Received: by mail-lj1-x232.google.com with SMTP id 38308e7fff4ca-2cd0f4797aaso29880321fa.0 for <dhcwg@ietf.org>; Mon, 22 Jan 2024 05:56:24 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1705931782; x=1706536582; darn=ietf.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=HBFtX5f+oBAhV1O0fQS+knL9NqOn2OQVnltgjsx8oaE=; b=MHnD8Jg+aau6eG0DKyCkG1lduLDYbkfez85mNjVskEkxkhiyJQ4YhE3FjZVQ5vEq2T xJTOvLKXHfP6GBj08cmc4cNvKjMgIqPSvAjZK2IiqajHkd5Hn2E/ukCYKyAX0k1C3HDQ scCCUgslaL1pii4GrNVN5jEql0TJ49ZG2Qczitf+WNdbKR7jxr/RRr5F7CwHWCkfmwiu 5Hb162g5aKxhsk2ha3fMHD7dwcgU7kGz6oJLthbWR9m3HybgcuppUs93wPw//32fWhNj Zhtw/o+piiirqgOUxJ4Y2UXsqUqG1xyi8jbGKujDivOgMdC95wl+lSjUoguNCNqnVIjW PKOw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1705931782; x=1706536582; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=HBFtX5f+oBAhV1O0fQS+knL9NqOn2OQVnltgjsx8oaE=; b=LfCcsVtyJWnFK/m6jA7SW+IMhezSKjgamLmHqOoBQc5H590TrXQcEtIROaq0PTD7Rz 4PxPzzR3mDChF29haLc7LdoHWG29lnv1jVmPZ3c47Q95JQNtyO+fYPkgsjfMRkKhsrN6 RqZhasjeG3HuEEkRTfISDszHipp8FMKhY5sOf8SjiQmvYKvsXwPeYCWRncagzfYNKR40 cZpgACSiZ8Jb5YQJ0Ru+vcNZSoPuJuvbrNS9RAFsQuHmct2COFlbv9rbqZoRLskZVFgS 47E99bkf0UdQWlzBziRYBy2KnNco5y4/UZCQtbVxybB6I6ti7vFDYn090w/YsjZ6oryv TAnw==
X-Gm-Message-State: AOJu0YxMPdglrEZp00a+lQbJ89yblcSvl+Z1Sn2zbjAF+2v/zFB9fgDv iD3CT71gkaqAHGjS2BWozG7aiKfHbIDiyT4T+tQQXBEbla7B2b2XYlgweM5KaXafWz5MhwqqW9h EzT+g0mXDTUu4BOY2VL4DdcZKWdQmv2OBaD0=
X-Google-Smtp-Source: AGHT+IHDFOnePSx1Eix5MRuor4rgNKIX59gIBXHQYoKqgwX5+3K8ArfRGyLKa/lAzfXD62vj4GDIf5ildtWVDnMkS1Q=
X-Received: by 2002:a05:651c:124b:b0:2cc:b9c2:1b50 with SMTP id h11-20020a05651c124b00b002ccb9c21b50mr1342268ljh.106.1705931782389; Mon, 22 Jan 2024 05:56:22 -0800 (PST)
MIME-Version: 1.0
References: <MN0PR21MB3240FBA9937882A154298231F6662@MN0PR21MB3240.namprd21.prod.outlook.com>
In-Reply-To: <MN0PR21MB3240FBA9937882A154298231F6662@MN0PR21MB3240.namprd21.prod.outlook.com>
From: Jen Linkova <furry13@gmail.com>
Date: Mon, 22 Jan 2024 14:56:10 +0100
Message-ID: <CAFU7BASSbOnVnYuKPMQU_M6vVRD67rDX479m72TqJYEfpYvYmQ@mail.gmail.com>
To: Aditi Patange <Aditi.Patange=40microsoft.com@dmarc.ietf.org>
Cc: "dhcwg@ietf.org" <dhcwg@ietf.org>, "draft-ietf-dhc-addr-notification@ietf.org" <IMCEAUNDEFINED-draft-ietf-dhc-addr-notification+40ietf+2Eorg@namprd21.prod.outlook.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/dhcwg/q6HHvUw10WgQNoukLpHrnjEkuA0>
Subject: Re: [dhcwg] Mail regarding draft-ietf-dhc-addr-notification
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Dynamic Host Configuration <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: Mon, 22 Jan 2024 13:56:24 -0000

Hi Aditi,

Sorry, I missed your comments and didn't address them in the last
version submitted on Jan 16.
The text will be added to the next version.

On Fri, Jan 5, 2024 at 3:31 AM Aditi Patange
<Aditi.Patange=40microsoft.com@dmarc.ietf.org> wrote:
> I am Aditi Patange from Microsoft. I recently came across ‘Registering Self-generated IPv6 Addresses using DHCPv6’ draft and I would like to surface some questions on behalf of the Windows DHCP client team.

> Nitpick – There is a typing error in Section 4.2.1 Bullet 5 “If there is already a binding between the registered address and another another client, the server SHOULD log the fact and update the binding.” The word “another” is duplicated. 😊

Thanks, will fix it in the next version.

> Section 4.3 doesn’t clarify client behavior if the ADDR-REG-REPLY is discarded. Is the client expected to retransmit ADDR-REG-INFORM until an acceptable ADDR-REG-REPLY is received?

I believe Section 4.5 addresses that:
"To reduce the effects of packet loss on registration, the client
SHOULD retransmit the registration message. Retransmissions SHOULD
follow the standard retransmission logic specified by section 15 of
[RFC8415]....If an ADDR-REG-REPLY message is received for the address
being registered, the client MUST stop retransmission."

So the client retransmits using RFC8415 logic (MRC = 3, so 3
retransmissions), but stops if the reply is received before 3
retransmissions are sent.
Do you think the text is unclear?

> Section 4.5 “However, the client cannot rely on the server acknowledging receipt of the registration message, because the server might not support address registration.”
>
> I am confused by this statement. The client started the registration process because the server responded with OPTION_ADDR_REG_ENABLE indicating that it supports this address registration mechanism. Can you please clarify this statement in the draft?

Oh sorry, this is a leftover from the previous version, where the
client wasn't actively discovering the server-side support. Will
remove the text.

-- 
Cheers, Jen Linkova