Subject: [Dhcpv6bis] Slides for DHC presentation of the 3315bis work

From: Tomek Mrugalski <[email-masked]>
Date: Fri, 28 Feb 2014 14:07:01 +0100

Folks,
Here are the slides I'm planning to present on Monday morning in DHC
session. The first two slides are about what we did so far and what our
next steps are.

Majority of the slides are about selected tickets from C category. I
picked them somewhat arbitrarily. There's too many of them to discuss
each. We have 20 minutes slot. I don't plan to spend too much time on
stateful issues (slide 5), as Bernie has a separate presentation about
it. It's mentioned here to give people some context that be neglecting
stateful-issues they are really blocking bis work.

If you have your favourite ticket that you'd like to me to mention,
please let me know.

Feedback/comments are more then welcome.

Safe travels and see you in London!

Tomek

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Fri, 28 Feb 2014 13:46:52 +0000

Tomek:

In general, the slides look fine. Thanks for pulling this together!!

However, I do have some suggested changes:

Slide 5 (1. Stateful Issues), ticket #65 - can we remove "may attempt to get a lease back with Renew"? The way it is written (and the way one could interpret the text in the draft), this could mean client can release and then issue a renew for a lease which is NOT intended.

Comment - Slide 6 (2. Naming) - Answer is both (we define for PD RR and DR may to client/server). No change.

Slide 7, (2. ORO mandatory) - Should this be 3. ORO mandatory? BUT, I think we should REMOVE this issue from the slides. Reason is very simple - section 18.1.1 says in order to get options, client MUST put in ORO. 22.7 is different in saying that *IF* a client wants options it includes the ORO. Sure, we should improve the text in 22.7 to say something like the ORO is optional (MAY), but is required (MUST) to get options back. (It would be wrong to require an ORO for all packets - hence why 22.7 has a MAY add an ORO.)

Slide 9, (4. Singleton options) - As this has already been agreed on by the draft-ietf-dhc-option-guidelines, why is this an issue? I don't understand why we put this in the C category.

Slide 12, (7. Nested or encapsulated) - I think this also falls under the same category as Slide 9 above - this is one where we should fix and stick to using encapsulated.

Perhaps I am bring presumptuous that these have been "resolved", but as the option-guidelines was carefully worked on and discussed within the WG, I'd like to avoid the possibility of opening these issues up for discussion (and why waste people's time). If the conclusion ends up differently, then the option-guidelines would also need to be revised which I don't really think we want? If you do strongly feel that some of the above were not as strongly discussed and need that discussion, leave it in.

- Bernie

-----Original Message-----
From: Tomek Mrugalski [mailto:[email-masked]] 
Sent: Friday, February 28, 2014 8:07 AM
To: Bernie Volz (volz)
Cc: [email-masked]
Subject: Slides for DHC presentation of the 3315bis work

Folks,
Here are the slides I'm planning to present on Monday morning in DHC session. The first two slides are about what we did so far and what our next steps are.

Majority of the slides are about selected tickets from C category. I picked them somewhat arbitrarily. There's too many of them to discuss each. We have 20 minutes slot. I don't plan to spend too much time on stateful issues (slide 5), as Bernie has a separate presentation about it. It's mentioned here to give people some context that be neglecting stateful-issues they are really blocking bis work.

If you have your favourite ticket that you'd like to me to mention, please let me know.

Tomek