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

From: "Liubing (Leo)" <[email-masked]>
Date: Mon, 2 Dec 2013 01:22:10 +0000

Hi, All

I support moving forward this document.

Best Regards,
Bing

From: dhcwg [mailto:[email-masked]] On Behalf Of Bernie Volz (volz)
Sent: Thursday, November 28, 2013 5:31 AM
To: [email-masked]
Subject: Re: [dhcwg] WGLC for draft-ietf-dhc-dhcpv6-unknown-msg-03 - Respond by Dec 2, 2013

This is friendly reminder that we need responses by end of day (anywhere in the world) December 2nd. Sorry for the 'late' reminder for those in the US enjoying Thanksgiving.

So far, there has only been Sheng's (document shepherd) comments.

<WG Co-Chair Hat OFF>
I add my support for this document (with Sheng's comments addressed as he captured my nits and more).

-        Bernie

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Bernie Volz (volz)
Sent: Monday, November 18, 2013 12:15 PM
To: [email-masked]<mailto:[email-masked]>
Subject: [dhcwg] WGLC for draft-ietf-dhc-dhcpv6-unknown-msg-03 - Respond by Dec 2, 2013

Folks, the authors of draft-ietf-dhc-dhcpv6-unknown-msg-03 (http://tools.ietf.org/html/draft-ietf-dhc-dhcpv6-unknown-msg-03) believe it is ready for working group last call. Please review this draft and indicate whether or not you feel it is ready to be published. Your input is important! Please respond by Dec 2nd, 2013.

At the time of this writing, there is no IPR reported against this draft.

Thanks,

-        Tomek & Bernie

---

From: Marcin Siodelski <[email-masked]>
Date: Mon, 2 Dec 2013 10:32:43 +0100

>> 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,
Marcin

---

From: Qi Sun <[email-masked]>
Date: Mon, 2 Dec 2013 20:26:28 +0800

Hi Marcin,

> 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?

Thanks, 
Qi

---

From: Marcin Siodelski <[email-masked]>
Date: Mon, 2 Dec 2013 13:38:00 +0100

> 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

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Mon, 2 Dec 2013 14:47:41 +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:[email-masked]] On Behalf Of Marcin Siodelski
Sent: Monday, December 02, 2013 7:38 AM
To: Qi Sun
Cc: [email-masked]; 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 <[email-masked]> wrote:
>>>> "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."
>>>>
>> 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".
>>
>

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
[email-masked]
https://www.ietf.org/mailman/listinfo/dhcwg

---

From: Qiong <[email-masked]>
Date: Tue, 3 Dec 2013 08:38:59 +0800

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) <[email-masked]> 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??
>
>
> 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
>
> >>> [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.
> > 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:
> >
> 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

-- 
==============================================
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/> *
===============================================

---

From: Tomek Mrugalski <[email-masked]>
Date: Tue, 03 Dec 2013 20:59:58 +0100

On 18.11.2013 18:15, Bernie Volz (volz) wrote:
> Folks, the authors of draft-ietf-dhc-dhcpv6-unknown-msg-03
> (http://tools.ietf.org/html/draft-ietf-dhc-dhcpv6-unknown-msg-03)
> believe it is ready for working group last call. Please review this
> draft and indicate whether or not you feel it is ready to be published.
> Your input is important! Please respond by Dec 2^nd , 2013.

I strongly support this document moving forward after the comments below
are addressed.

1. Abstract. The full name of the protocol is "Dynamic Host
Configuration Protocol for IPv6", not "Dynamic Host Configuration
Protocol version 6". (That is also used in section 1) .There is no such
thing as DHCPv6 function node. I propose to update the abstract as:

   Dynamic Host Configuration Protocol for IPv6 (DHCPv6) isn't specific
   about handling messages with unknown types.  This memo describes the
   problems and defines how a DHCPv6 entities node should behave when
   receiving unknown messages. This document updates RFC 3315.

2. Section 3: "Another issue is that, it's not specific in RFC3315 about
what a relay agent... " => "Another issue is that RFC3315 does not
specify what a relay agent..."

3. Section 4.1 "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.". The last
sentence is not true. The server can't really distinguish if the relay
supports the message or not, as in both cases the reaction (forward
towards the server) would be the same.

I think removing the last sentence would be helpful here.

Alternatively, perhaps you wanted to discuss the case where the new
message is sent to the relay by the server, relay doesn't support it, so
it forwards it back to the server. That is a worthy thing to mention,
but the current text does not reflect that situation. You may address
that by extending the first sentence a bit: "In the case that a new type
of relay message is sent by the server 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.".

If you don't have any preference, I would prefer the first approach
(remove second sentence) as it is more generic.

4. Section 4.2 "If the relay agent received messages other than
Relay-forward and Relay-reply, it MUST forward them as is described in
Section 20.1.1 of [RFC3315].". This sentence is incorrect. See RFC6977
and the Reconfigure-reply message definition. Relays are often have
requestor capability, so they are likely to receive LEASEQUERY-REPLY,
LEASEQUERY-DATA and LEASEQUERY-DONE messages as well (See RFC5007 and
5460). There may be other message types that are are targeted at the
relay agent itself (and not expected to be relayed).

Anyway, I think the right thing to say here is:

   If the relay agent received a Relay-forward message, Section 20.1.2
   of [RFC3315] defines the related behavior.  If the relay agent
   received messages other than Relay-forward and Relay-reply and the
   relay agent does not recognize its message type, it MUST forward
   them as is described in Section 20.1.1 of [RFC3315].

Thank you for doing this work. It is very useful clarification.

Tomek

---

From: Ted Lemon <[email-masked]>
Date: Tue, 3 Dec 2013 15:02:49 -0500

By the way, I recently learned about this resource:

https://www.rfc-editor.org/rfc-style-guide/abbrev.expansion.txt

This is a list of all the abbreviations the RFC editor is aware of, with the ones that need not be expanded marked with an asterisk.   DHCP is marked with an asterisk.   So you don't need to write it out—just write DHCP, and the reader is expected to know what it stands for.

---

From: Cong Liu <[email-masked]>
Date: Wed, 4 Dec 2013 17:12:11 +0800

Dear all,

I support this document moving forward.

Best Regards,
Cong

2013/12/4 Ted Lemon <[email-masked]>

> This is a list of all the abbreviations the RFC editor is aware of, with
> the ones that need not be expanded marked with an asterisk.   DHCP is
> marked with an asterisk.   So you don't need to write it out—just write
> DHCP, and the reader is expected to know what it stands for.
>