[dhcwg] draft-ietf-dhc-addr-registration

"Bernie Volz (volz)" <volz@cisco.com> Tue, 04 March 2014 10:36 UTC

Return-Path: <volz@cisco.com>
X-Original-To: dhcwg@ietfa.amsl.com
Delivered-To: dhcwg@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C7E81A0699 for <dhcwg@ietfa.amsl.com>; Tue, 4 Mar 2014 02:36:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.048
X-Spam-Level:
X-Spam-Status: No, score=-15.048 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
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 o6dCfmnwiOze for <dhcwg@ietfa.amsl.com>; Tue, 4 Mar 2014 02:36:52 -0800 (PST)
Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 61ECE1A0535 for <dhcwg@ietf.org>; Tue, 4 Mar 2014 02:36:48 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1030; q=dns/txt; s=iport; t=1393929405; x=1395139005; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=wNPhmDrlNP/NwHOrblJbYpocQJWarJCBrH6Xj6PjK+w=; b=E4IyvOc+W2NYsBBXh3T/3Z5DPG0Ke8UiXRLYhzD8OP35a//+nkg/b3RA x5IVt87joWwwk5q6gvJMMj7Vrv336acTbKl5/z2QcsZVNWcH/sapjNlEg QwaGzB5XK9z/O+qzo/2OGdGIvyLY0zV2/JN6Pxyg8pHwDsW8E7okr8hLw 4=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgcFANarFVOtJXHA/2dsb2JhbABagwbDHxZ0giw6UQE+QiYBBIgMnQSvOxeRfIEUBJg8kiuDLYFoBw
X-IronPort-AV: E=Sophos;i="4.97,584,1389744000"; d="scan'208";a="307887743"
Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-7.cisco.com with ESMTP; 04 Mar 2014 10:36:45 +0000
Received: from xhc-rcd-x15.cisco.com (xhc-rcd-x15.cisco.com [173.37.183.89]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id s24AajYW020641 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for <dhcwg@ietf.org>; Tue, 4 Mar 2014 10:36:45 GMT
Received: from xmb-rcd-x04.cisco.com ([169.254.8.97]) by xhc-rcd-x15.cisco.com ([173.37.183.89]) with mapi id 14.03.0123.003; Tue, 4 Mar 2014 04:36:44 -0600
From: "Bernie Volz (volz)" <volz@cisco.com>
To: "dhcwg@ietf.org" <dhcwg@ietf.org>
Thread-Topic: draft-ietf-dhc-addr-registration
Thread-Index: Ac83laNB+mvrPStcSXmFnTf8BRS8Bw==
Date: Tue, 4 Mar 2014 10:36:44 +0000
Message-ID: <29960C97-EAE7-4197-8BF2-437F6AC70F4C@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Content-Type: text/plain; charset="us-ascii"
Content-ID: <03CE80A388C42E41A317CF9FC9213704@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/dhcwg/ha9n0crU9ct6OM4GB_IFqQA0jDo
Subject: [dhcwg] draft-ietf-dhc-addr-registration
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.15
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: <http://www.ietf.org/mail-archive/web/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, 04 Mar 2014 10:36:55 -0000

co-Chair hat off ...

I think it is wrong to make the server's Reply (acknowledgement) optional - especially as this seems to be at the discretion of the server. A client has no way if knowing what the lack of response means (no server or server doesn't send Reply).

I think this must be fixed before we can move this document further.

I think the server should be required to send the Reply. Whether the client "waits" for the response, and potentially sends retransmissions, is up to the client.

This will also require specifying some of the retransmission values as per RFC3315 - time to wait, number of (re)transmissions, max retransmission time.

Also, should there be 3 possible server responses ... not supported, update queued, update complete? The last two may depend on queue depth or based on time? I am only suggesting one Reply - ie, not a queued followed by a complete one. If queued returned, client can always check dns to see if update done?

- Bernie (from iPad)