Re: [dhcwg] AD Evaluation: draft-ietf-dhc-dhcpv6-unknown-msg

Qi Sun <sunqi.csnet.thu@gmail.com> Sun, 02 February 2014 14:53 UTC

Return-Path: <sunqi.csnet.thu@gmail.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 D151B1A00DE for <dhcwg@ietfa.amsl.com>; Sun, 2 Feb 2014 06:53:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] 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 wRLmHRC92tEl for <dhcwg@ietfa.amsl.com>; Sun, 2 Feb 2014 06:53:14 -0800 (PST)
Received: from mail-pa0-x22a.google.com (mail-pa0-x22a.google.com [IPv6:2607:f8b0:400e:c03::22a]) by ietfa.amsl.com (Postfix) with ESMTP id DD5561A00E5 for <dhcwg@ietf.org>; Sun, 2 Feb 2014 06:53:10 -0800 (PST)
Received: by mail-pa0-f42.google.com with SMTP id kl14so6206652pab.1 for <dhcwg@ietf.org>; Sun, 02 Feb 2014 06:53:06 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=PvSSUMHcihn7NDQ+E91NWs9Tcmkk+tlp4CxlKdS8Py0=; b=hDPjR2xb51JV8xUGzf0JEe9dHHiChBAZv72VX4vO7ISYdlWdB3N9moMugH2oKEBnIu xXuVKTPwNise57KcsrgXIpG4Na1tO2A6LJ2SUTIsh/suEMTXOkcBGa6UvjXDAiKaYc/L k7zcy7jKirr9GwwjWMUSxkG/rMCvl/zWGRdHn3Lp+8XVmbwD5ci9GqtrSYZLReHe/tlS ZmAunpwYXR8klsKYxzQwZ1gds0wGAbCcqd/guQojWo7FtARsSmw6sDuWw9HUZkX1Q0z3 0BSOWlp2BWr8ePD7ENEzqqYibvee6tUZC7QRre+VDuLmg+1TrzQPMhx4Ws+opWvrk8FW kXuA==
X-Received: by 10.68.185.1 with SMTP id ey1mr32444296pbc.33.1391352786565; Sun, 02 Feb 2014 06:53:06 -0800 (PST)
Received: from [192.168.0.109] ([27.213.251.185]) by mx.google.com with ESMTPSA id i10sm120563862pat.11.2014.02.02.06.53.03 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 02 Feb 2014 06:53:06 -0800 (PST)
Mime-Version: 1.0 (Apple Message framework v1085)
Content-Type: text/plain; charset=utf-8
From: Qi Sun <sunqi.csnet.thu@gmail.com>
In-Reply-To: <CFA19E62-0F9A-4358-AB7C-E4A910BF4874@nominum.com>
Date: Sun, 2 Feb 2014 22:52:55 +0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <63DDD593-2421-4A18-A893-C2BEAF836243@gmail.com>
References: <52EBC3EA.1020104@innovationslab.net> <CFA19E62-0F9A-4358-AB7C-E4A910BF4874@nominum.com>
To: Ted Lemon <ted.lemon@nominum.com>, Brian Haberman <brian@innovationslab.net>
X-Mailer: Apple Mail (2.1085)
Cc: "dhcwg@ietf.org WG" <dhcwg@ietf.org>, draft-ietf-dhc-dhcpv6-unknown-msg@tools.ietf.org
Subject: Re: [dhcwg] AD Evaluation: draft-ietf-dhc-dhcpv6-unknown-msg
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: Sun, 02 Feb 2014 14:53:17 -0000

Dear Brian & Ted,

Thank you so much for your evaluation/suggestions! I think the comments/changes are very helpful to make the text clearer. 

I will do the updates asap. Thank you again!

//Sorry for late response because of the Chinese Spring Festival. 

Best Regards,
Qi



On 2014-2-2, at 下午9:33, Ted Lemon wrote:

> On Jan 31, 2014, at 10:40 AM, Brian Haberman <brian@innovationslab.net> wrote:
>>    I have done my AD Evaluation of draft-ietf-dhc-dhcpv6-unknown-msg
>> (since Ted is listed as a co-author).  I only have a few points of
>> discussion on this document before we move it along in the publication
>> process.  I am by no means a DHCP expert, so let me know if I have gone
>> off in the weeds...
>> 
>> 1. I would like to see a little more clarity in the purpose of this
>> document.  It does a good job clarifying what a relay agent should do
>> with existing messages, but I think it would be useful to spell out that
>> is document is also dictating how future documents that define new DHCP
>> messages should specify relay behavior.
> 
> This is a good suggestion (actually, these are all good suggestions!).   I think the right solution to this is twofold.   First, the following change should be made at the end of 4.1 (this also addresses your point 2):
> 
> OLD:
>   In the case that a new type of message is sent by the server to a
>   relay agent but the relay agent does not recognize it, the message is
>   put into a Relay-forward message and sent to the server.
> NEW:
>   New DHCP message types may be defined in future that are intended to
>   convey information from DHCP servers to relay agents.   Relay agents
>   that do not implement these messages will not recognize that such
>   messages are intended for them.   A relay agent that implements this
>   specification will necessarily forward such messages to the DHCP
>   servers to which it is configured to relay client messages.
> 
>   At this time, no messages of this variety have been specified.
>   If such a message is specified in the future, the specification could
>   include text something like the following:
> 
>      DHCP servers that send this new message type MAY, when they
>      receive a relayed message of this type, mark the relay agent to
>      which the message was sent as not implementing messages of this
>      type.   In this case, the DHCP server MAY implement a strategy
>      of probing the relay agent occasionally to see if it has been
>      updated.
> 
>   However, this is not strictly necessary, since DHCP does not provide
>   a signaling message for rejecting unexpected message types, and
>   therefore DHCP servers are not expected to respond to such messages.
> 
>   Documents specifying new message types should use different types for
>   communicating *to* relay agents than are used for communicating *from*
>   relay agents, so that no confusion can occur where a message sent to
>   a relay agent is sent back to the DHCP server, which then tries to
>   process it as if it came from a relay agent.
> 
> In addition to this change, I'd propose the following change to the abstract:
> 
> OLD:
>   DHCPv6 is not specific about handling messages with unknown types.
>   This memo describes the problems and defines how a DHCPv6 server,
>   client or relay agent should behave when receiving unknown DHCPv6
>   messages.  This document updates RFC3315.
> 
> NEW:
>   DHCPv6 is not specific about handling messages with unknown types.
>   This memo describes the problems and defines how a DHCPv6 server,
>   client or relay agent should behave when receiving unknown DHCPv6
>   messages.  This document also provides advice for authors of future
>   documents defining new messages sent from DHCP servers to DHCP relay
>   agents, and should be read by potential authors of such documents.
>   This document updates RFC3315.
> 
>> 2. In section 4.1, the text talks about targeting a message based on its
>> message type.  To me, that suggests that a relay must know about all
>> DHCP message types.  I thought (feel free to correct me) that relay
>> agents were mostly stateless and would forward all messages not
>> addressed to them to the configured DHCP server.  This assumes that all
>> Relay-Reply messages are addressed to the relay directly.
> 
> That is the general effect of 4.1, but I hope the text above makes clearer what the issues are, both to you and to other future readers of the document.
> 
>> 3. After having an exchange with Ralph Droms, I want to ask about
>> messages from servers to clients.  If those messages are *not* in a
>> Relay-Reply message, but are received by a relay, should those messages
>> be dropped?  If a server->client message is forwarded to a server by the
>> relay, should it be dropped by the server?
> 
> If this happens, it's an implementation bug: the DHCP server is not in conformance with RFC3315.   I therefore think that we don't need to address it, although it would certainly break things if an implementation were to erroneously do that.   I think such an implementation would never make it to the field, because it simply wouldn't work.
> 
>> 4. Is there a need to specifically discuss the behavior of single
>> devices that have both a relay agent and a client running at the same time?
> 
> Hm.   We generally treat these as two separate implementations that happen to be running on the same hardware.   Also I think usually it's a client and a server, not a relay agent and a server.   We could add text addressing this, but I don't really see this coming up in practice.   There isn't similar text in RFC3315, for instance, and we haven't seen evidence of implementors getting this wrong.
> 
>> 5. Also from Ralph... Could section 5 simply be written as "A client or
>> server MUST silently discard any received DHCPv6 message with an unknown
>> message type."?
> 
> Yes, I think this is a good edit.   Qi, do you have time to do these edits?
> 
> _______________________________________________
> dhcwg mailing list
> dhcwg@ietf.org
> https://www.ietf.org/mailman/listinfo/dhcwg