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

"Bernie Volz (volz)" <volz@cisco.com> Mon, 02 December 2013 14:48 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 9B36F1AE482 for <dhcwg@ietfa.amsl.com>; Mon, 2 Dec 2013 06:48:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.502
X-Spam-Level:
X-Spam-Status: No, score=-9.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, 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 5pbKIdrPgHVU for <dhcwg@ietfa.amsl.com>; Mon, 2 Dec 2013 06:48:06 -0800 (PST)
Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) by ietfa.amsl.com (Postfix) with ESMTP id 8618D1AE335 for <dhcwg@ietf.org>; Mon, 2 Dec 2013 06:48:04 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7300; q=dns/txt; s=iport; t=1385995682; x=1387205282; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=itYU/g0U6dQqrffRXEHO/LbCcq5LgmqDbEC+M/LUJHc=; b=L0OKv+gR6Txh0YvZ5EAhYSz75K2iDVhqMdwcazTzQOXziwxHGdxWlUsH +JBAA82GxeA2XVQOxThJS6K50C9exs1n6rF3NPMyKzc/sfZZbvK8N5Mjt DnOxy6gbuGB69VHC4ejxJUJQi3MrhTkC0GyFpYRzhaeAP2bN7+8/sk+gH M=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgcFAHSdnFKtJV2a/2dsb2JhbABZgwc4U4J6tWcYgQ0WdIIlAQEBBAEBASAROgQHDAQCAQYCDgMEAQEBAgIGHQMCAgIfBgsUAQgIAQEEAQ0FCIdnAw8NlAqbYYhVDYc0EwSBKYtOgWAxBwaCZTWBEwOWKY5FhTmBa4E+gio
X-IronPort-AV: E=Sophos;i="4.93,811,1378857600"; d="scan'208";a="3651079"
Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by alln-iport-8.cisco.com with ESMTP; 02 Dec 2013 14:47:43 +0000
Received: from xhc-aln-x08.cisco.com (xhc-aln-x08.cisco.com [173.36.12.82]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id rB2ElgFA000342 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 2 Dec 2013 14:47:43 GMT
Received: from xmb-rcd-x04.cisco.com ([169.254.8.232]) by xhc-aln-x08.cisco.com ([173.36.12.82]) with mapi id 14.03.0123.003; Mon, 2 Dec 2013 08:47:42 -0600
From: "Bernie Volz (volz)" <volz@cisco.com>
To: Marcin Siodelski <msiodelski@gmail.com>, Qi Sun <sunqi.csnet.thu@gmail.com>
Thread-Topic: [dhcwg] WGLC for draft-ietf-dhc-dhcpv6-unknown-msg-03 - Respond by Dec 2, 2013
Thread-Index: Ac7kgW5Zu29batgdRjKYwweN6OdP2gHNcU1QAOKQ87oAEqMiAAAAZx4AAAlkqmA=
Date: Mon, 2 Dec 2013 14:47:41 +0000
Message-ID: <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>
In-Reply-To: <CAFGoqUPoth6VbdX8hPZaeN4Hh5Fi7eBJXBhcO8NmqirQqePSvg@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.86.252.96]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
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: Mon, 02 Dec 2013 14:48:08 -0000

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