Subject: Re: [Dhcpv6bis] first email thoughts/edits on my read through

From: Tomek Mrugalski <[email-masked]>
Date: Wed, 15 Jun 2016 21:55:49 +0200

On 11.05.2016 18:48, Michael Richardson wrote:
> Is a version of xml2rfc newer than 2.5.1, which maybe permits
> <street> to be omitted?  I had to add <street></street> to Tim
> Winter's address to get xml2rfc to pass.  I didn't find a version
> newer than 2.5.1.
> 
> Please forgive this stream-of-consciousness email, I haven't made 
> edits for all of my comments, because some of them I don't know
> what to do. I can turn them into tickets if desired.
> 
> Also, the .xml file has lots of trailing whitespace which is
> generally a bad idea in git, as it sees that as gratuitous
> changes. Commit: 5117803 cleans that up.
Hi Michael,

Thanks a lot for your review and your comments. It's really easy to
work through the changes once they're in git, especially since you put
each of them on separate commit. That's VERY useful.

I did go through your commits and merged many of them to master.
Couple were redundant (after resolving conflicts there was nothing to
merge). Couple Bernie had objections and there were a couple that I
have concerns with.

eb8116146f593627acaaeccd2890e9aba76baa3d - the change proposes to
clarify what to do when a message is received with options it must not
contain, received message with mandatory options missing or otherwise
receive messages that are considered invalid. The updated text says
"Clients and servers MAY choose either to extract information from
such a message if the information is of use to the recipient, or to
ignore such message completely and just discard it.". In my opinion
this is too vague. Let's say the client receives an Advertise that is
somehow broken, for example contains two server-ids. Can it proceed to
send Request or should it retransmit Solicit? I think both behaviors
are allowed according to that text. I'm not objecting the change per
se, but this requires further clarification in my opinion before it
goes to master.

225ca0efc1569f4d4361a64acda69f52173b00d1 - The new text says "The
client SHOULD be suspicious of the Reconfigure message (they may be
faked), and it MUST NOT abandon any resources it might have already
obtained.". I'm not sure this is the text I would like to have. What
does it mean suspicious? Do extra checks and accept it if they pass?
That's exactly what reconfigure key mechanism does - extra checks that
whoever sent the message has the reconfigure-key. Maybe 'suspicious'
as in assume they are fake and discard them? In my opinion this
statement would weaken the reconfigure mechanism significantly.

1c9dab05562ce2417fce20234ffdfb2eb1142a68 - This patch does not apply
anymore. It's about cleaning up Advertise collection explanation.
There's nothing wrong with it, I simply ran out of time to do proper
merge of it.

53a85d49e53f3f98f020aceb499d0a84f50d16a7 - The text "DHCP servers
SHOULD NOT care if the layer-2 address used was multicast or not, as
long as the layer-3 address was correct.". I have two concerns here.
First, isn't that none of our business to determine that? This is up
to the underlying OS to determine whether the packet is sane and
should be passed to the application or not. The second concern here is
that we're using layer-2 and layer-3 names. It's better to say IPv6
address, rather than layer-3 address. Not sure how to best reference
layer-2 address, though.

I have also opened ticket #163 to not forget about those comments.
Let's keep it open until we conclude the discussion about those issues
above and the ones Bernie raised on May 11th.

Tomek

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Wed, 15 Jun 2016 20:16:19 +0000

A few comments below (BV>).

Thanks for doing this Tomek! And, again Michael, thanks for doing the review.

- Bernie

-----Original Message-----
From: Dhcpv6bis [mailto:[email-masked]] On Behalf Of Tomek Mrugalski
Sent: Wednesday, June 15, 2016 3:56 PM
To: [email-masked]
Subject: Re: [Dhcpv6bis] first email thoughts/edits on my read through

On 11.05.2016 18:48, Michael Richardson wrote:
> Is a version of xml2rfc newer than 2.5.1, which maybe permits <street> 
> to be omitted?  I had to add <street></street> to Tim Winter's address 
> to get xml2rfc to pass.  I didn't find a version newer than 2.5.1.
> 
> edits for all of my comments, because some of them I don't know what 
> to do. I can turn them into tickets if desired.
> 
> Also, the .xml file has lots of trailing whitespace which is generally 
> a bad idea in git, as it sees that as gratuitous changes. Commit: 
> 5117803 cleans that up.
Hi Michael,

Thanks a lot for your review and your comments. It's really easy to work through the changes once they're in git, especially since you put each of them on separate commit. That's VERY useful.

I did go through your commits and merged many of them to master.
Couple were redundant (after resolving conflicts there was nothing to merge). Couple Bernie had objections and there were a couple that I have concerns with.

eb8116146f593627acaaeccd2890e9aba76baa3d - the change proposes to clarify what to do when a message is received with options it must not contain, received message with mandatory options missing or otherwise receive messages that are considered invalid. The updated text says "Clients and servers MAY choose either to extract information from such a message if the information is of use to the recipient, or to ignore such message completely and just discard it.". In my opinion this is too vague. Let's say the client receives an Advertise that is somehow broken, for example contains two server-ids. Can it proceed to send Request or should it retransmit Solicit? I think both behaviors are allowed according to that text. I'm not objecting the change per se, but this requires further clarification in my opinion before it goes to master.

BV> I'm also concerned by this change (sorry if I missed what it entailed). I think we must be clear that there is no obligation on clients (or servers) to necessarily check for this (beyond what is in Section 15 [RFC 3315]). For example, if there are two server-ids, I would think a client would just use the "first" and ignore the second (would never look for it). Also, there is the UnspecFail status code which a server could send in response to a clearly malformed request. I wouldn't want to see someone building test cases based on this text to determine whether clients or servers are failing the messages (beyond what is in section 15).

225ca0efc1569f4d4361a64acda69f52173b00d1 - The new text says "The client SHOULD be suspicious of the Reconfigure message (they may be faked), and it MUST NOT abandon any resources it might have already obtained.". I'm not sure this is the text I would like to have. What does it mean suspicious? Do extra checks and accept it if they pass?
That's exactly what reconfigure key mechanism does - extra checks that whoever sent the message has the reconfigure-key. Maybe 'suspicious'
as in assume they are fake and discard them? In my opinion this statement would weaken the reconfigure mechanism significantly.

BV> Agree with Tomek. I think saying that a client continues to use what it has previously received until it has successful reconfigured is appropriate. I also think that this is already pretty clear as the Reconfigure triggers a Renew or Rebind (or Information-Request) and the implication there is that these allow a client to continue to use what it already has (until the updated information is received).

1c9dab05562ce2417fce20234ffdfb2eb1142a68 - This patch does not apply anymore. It's about cleaning up Advertise collection explanation.
There's nothing wrong with it, I simply ran out of time to do proper merge of it.

53a85d49e53f3f98f020aceb499d0a84f50d16a7 - The text "DHCP servers SHOULD NOT care if the layer-2 address used was multicast or not, as long as the layer-3 address was correct.". I have two concerns here.
First, isn't that none of our business to determine that? This is up to the underlying OS to determine whether the packet is sane and should be passed to the application or not. The second concern here is that we're using layer-2 and layer-3 names. It's better to say IPv6 address, rather than layer-3 address. Not sure how to best reference
layer-2 address, though.

BV> Agree with Tomek ... I don't think we want servers to deal with layer-2 addresses and validation.

I have also opened ticket #163 to not forget about those comments.
Let's keep it open until we conclude the discussion about those issues above and the ones Bernie raised on May 11th.

Tomek

_______________________________________________
Dhcpv6bis mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dhcpv6bis