Re: [dhcwg] WGLC for draft-ietf-dhc-dhcpv6-unknown-msg-03 - Respond by Dec 2, 2013

Qiong <bingxuere@gmail.com> Tue, 03 December 2013 00:39 UTC

Return-Path: <bingxuere@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 7FC1B1ADFDD for <dhcwg@ietfa.amsl.com>; Mon, 2 Dec 2013 16:39:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 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, HTML_MESSAGE=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 8cHE4UIqVJOg for <dhcwg@ietfa.amsl.com>; Mon, 2 Dec 2013 16:39:42 -0800 (PST)
Received: from mail-ve0-x232.google.com (mail-ve0-x232.google.com [IPv6:2607:f8b0:400c:c01::232]) by ietfa.amsl.com (Postfix) with ESMTP id BF0191ADFDC for <dhcwg@ietf.org>; Mon, 2 Dec 2013 16:39:41 -0800 (PST)
Received: by mail-ve0-f178.google.com with SMTP id c14so9774471vea.9 for <dhcwg@ietf.org>; Mon, 02 Dec 2013 16:39:39 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=IBUxi49dudaGzE2Ljebhxgv0N1M3bcN2cqUlZTY99RY=; b=MKtWgoECm4j/Wi4ZcmizNb8w2A0jUbzxEp9AGCDxjr+popDAQrISjiWhjX1XK8KxzT rtrAIVxYDa83/VjMPm0wBF6C1MvbOB50G0rLEw8DsT6a70VA6FWbe5TmZqjafCVtgOSW sfQcW/pvDxRJ40pp/hxjdZRoKfXDVNR0fR/UEUuZaao+40adTbPDygWVXVBytHOqymSZ zyQRlFbiqesM9JV+zeV4A8WuvjqPLHaVNWZiMMYaT/MSSO6UMWnmB46CFhwjQgzfopSf 7tuPExAHiBTiyOJl+ThPitSKoqcNwGwIsdvpM/w3AaQieIeCjGe7Z98ETrB6FGzOxPpm Dn3g==
X-Received: by 10.221.29.8 with SMTP id rw8mr54492vcb.56.1386031179120; Mon, 02 Dec 2013 16:39:39 -0800 (PST)
MIME-Version: 1.0
Received: by 10.220.93.6 with HTTP; Mon, 2 Dec 2013 16:38:59 -0800 (PST)
In-Reply-To: <489D13FBFA9B3E41812EA89F188F018E1ADC8C82@xmb-rcd-x04.cisco.com>
References: <489D13FBFA9B3E41812EA89F188F018E1AD98DE0@xmb-rcd-x04.cisco.com> <489D13FBFA9B3E41812EA89F188F018E1ADC2A5B@xmb-rcd-x04.cisco.com> <CAFGoqUMh-xT+GsJQNHGUcisqcphAVFZXnQ6ac+GXq76wBBiyYw@mail.gmail.com> <AC25F22F-A27C-40FC-B4AF-9EA886D973A6@gmail.com> <CAFGoqUOtzad1iNMrqs5vyy5wqewxw445Q_iAiKgYjgLvocR5EQ@mail.gmail.com> <DEEB7D15-5356-4A9C-A899-9CBC6B14C326@gmail.com> <CAFGoqUPoth6VbdX8hPZaeN4Hh5Fi7eBJXBhcO8NmqirQqePSvg@mail.gmail.com> <489D13FBFA9B3E41812EA89F188F018E1ADC8C82@xmb-rcd-x04.cisco.com>
From: Qiong <bingxuere@gmail.com>
Date: Tue, 3 Dec 2013 08:38:59 +0800
Message-ID: <CAH3bfACQzYqc4CY=OiW2BTUOe93FrLLVkj2KsS_XU4XKd6mbkw@mail.gmail.com>
To: "Bernie Volz (volz)" <volz@cisco.com>
Content-Type: multipart/alternative; boundary=001a1133951014503804ec968898
Cc: "dhcwg@ietf.org" <dhcwg@ietf.org>
Subject: Re: [dhcwg] WGLC for draft-ietf-dhc-dhcpv6-unknown-msg-03 - Respond by Dec 2, 2013
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, 03 Dec 2013 00:39:45 -0000

Dear all,

This document is short but useful for DHCPv6 when new types of messages are
defined.
An editorial suggestion: The doc should be consistent with 'to', 'toward'
and 'towards'.

Thanks
Qiong


On Mon, Dec 2, 2013 at 10:47 PM, Bernie Volz (volz) <volz@cisco.com> wrote:

> Hi:
>
> Also, should we perhaps clean up (b) as to what exactly constitutes
> 'target of the message'? One determination of 'target' might be that IPv6
> destination address in the packet is one of the relay's unicast addresses.
> Another would be the message type? I think this definition is primarily
> based on message type??
>
>
> Here's a bunch of nits / suggestions for the document:
>
> Regarding the section 4.1 issue:
>
>    In the case that a new type of relay message is sent to a relay agent
>    but the relay agent doesn't recognize it, the message is put into a
>    Relay-forward message and sent to the server.  Then the server knows
>    the relay agent doesn't support the new message.
>
> How about:
>
>    This definition of what constitutes a 'valid message' for the relay will
>    avoid the need for changes to relay agents when new client/server
>    message types are defined. However, changes to relay agents will be
>    required when a new message type not intended to be forwarded
>    towards the server is defined (and this cannot be avoided as the relay
>    needs the logic to process that message anyway).
>
> ---
>
> 3.  Problem Statement
>
>    The relay agent is bound to send a message either to the server or to
>    the client.  But RFC3315 doesn't explicitly describe how the relay
>    agent can find out it should send a message towards the server or
>    towards the client.
>
>    Another issue is that, it's not specific in RFC3315 about what a
>    relay agent should do if it doesn't recognize the received messages.
>    The relay agent isn't required to relay the messages, nor advised to
>    drop them.
>
>    In addition, there is no specific requirement of the client or server
>    on dealing with an unknown message in RFC3315.
>
> How about:
>
>    The relay agent is bound to send a message either to the server or to
>    the client.  But RFC3315 doesn't explicitly describe how the relay
>    agent can find out if it should send a message towards the server or
>    towards the client.
>
>    Another issue is that RFC3315 is not specific about what a
>    relay agent should do if it does not recognize a received message;
>    the relay agent is not required to relay the message, nor advised to
>    drop the message.
>
>    In addition, there is no specific requirement for dealing with
>    unknown messages by the client or server in RFC3315.
>
> And what about adding:
>
>     And it is expected that most future DHCPv6 messages will not be
>     used to communicate directly with relay agents (though they may
>     need to be relayed by relay agents).
>
>
> In the rest of the document (as Sheng outlined), please replace n't with
> not (i.e., doesn't should be replaced by does not).
>
> - Bernie
>
> -----Original Message-----
> From: dhcwg [mailto:dhcwg-bounces@ietf.org] On Behalf Of Marcin Siodelski
> Sent: Monday, December 02, 2013 7:38 AM
> To: Qi Sun
> Cc: dhcwg@ietf.org; Bernie Volz (volz)
> Subject: Re: [dhcwg] WGLC for draft-ietf-dhc-dhcpv6-unknown-msg-03 -
> Respond by Dec 2, 2013
>
> On Mon, Dec 2, 2013 at 1:26 PM, Qi Sun <sunqi.csnet.thu@gmail.com> wrote:
> >
> > Hi Marcin,
> >
> > On 2013-12-2, at 下午5:32, Marcin Siodelski wrote:
> >
> >>>> ISSUE 2
> >>>> In this sentence:
> >>>>
> >>>> "In the case that a new type of relay message is sent to a relay
> >>>> agent  but the relay agent doesn't recognize it, the message is put
> >>>> into a  Relay-forward message and sent to the server."
> >>>>
> >>>> Why "new type of relay message", not "new type of message"? I don't
> >>>> quite understand what the relay message is in this context.
> >>>
> >>> [Qi] A new type of relay message targets at the relay agent. If a
> relay agent recognizes the message, then it should consume the message.
> Otherwise, the relay just sends the message to the server (in a
> Relay-forward message), so that the server gets the information that this
> relay doesn't support the new relay agent message.
> >>> In Bullet (b), the message doesn't take the relay agent as the target.
> >>> If this part isn't clear enough, we can improve it.
> >>>
> >>
> >> Thanks for this explanation. Let me rephrase my question, because I
> >> was asking about slightly different thing....
> >>
> >> Would it still be ok if we had this text: "In the case that a new
> >> type of message is sent to a relay agent..... ", instead of "In the
> >> case that a new type of relay message is sent to a relay agent..."?
> >> Simply removed "relay". I don't understand how "relay message" is
> >> different from the "message" or "valid message".
> >>
> >
> > Thanks for your patience. What I wanted to say was that the new type of
> message targets at the relay agent rather than the client/server. IMHO, if
> remove "relay", the relationship between this paragraph and the bullet (b)
> might be a little confusing.
> > How about this:
> >
> >    In the case that a new type of message targets at a relay agent
> >    but the relay agent does not recognize it, ...
> >
> > Would the expression be better?
> >
>
> IMHO, that is much better. In the former case, the verb "send" makes it
> ambiguous - message sent to a relay agent doesn't have to be necessarily
> consumed/processed by relay, it could be forwarded. At least this is how I
> read it. :-)
>
> Marcin
> _______________________________________________
> dhcwg mailing list
> dhcwg@ietf.org
> https://www.ietf.org/mailman/listinfo/dhcwg
> _______________________________________________
> dhcwg mailing list
> dhcwg@ietf.org
> https://www.ietf.org/mailman/listinfo/dhcwg
>



-- 
==============================================
Qiong Sun
China Telecom Beijing Research Institude


Open source code:
lightweight 4over6: *http://sourceforge.net/projects/laft6/
<http://sourceforge.net/projects/laft6/>*
PCP-natcoord:* http://sourceforge.net/projects/pcpportsetdemo/
<http://sourceforge.net/projects/pcpportsetdemo/> *
===============================================