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

[Qiong <[e-mail]>]

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) <[e-mail]> 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:[e-mail]] On Behalf Of Marcin Siodelski
> Sent: Monday, December 02, 2013 7:38 AM
> To: Qi Sun
> Cc: [e-mail]; 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 <[e-mail]> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dhcwg
> _______________________________________________
> dhcwg mailing list
> [e-mail]
> 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/> *
===============================================