[Dhcpv6bis] 2014-01-22 meeting minutes

[Tomek Mrugalski <[e-mail]>]

We had a very good WebEx meeting today and made several decisions. I
took some notes during the meeting. Here's the cleaned up version of
them. Please correct if I missed or misunderstood anything.

Note: All tickets numbers refer to the tickets in out issue tracker:
http://trac.tools.ietf.org/group/dhcpv6bis/

Thanks to Bernie for organizing this call.

Attendees:
Bernie
Marcin
Michael
Sheng
Tomek

Andrew couldn't make it this time, because of a trip. He asked some
tasks be assigned to him.

1. Confirm that XML for 3315 is done.
The only outstanding item was to implement soft cross-references. Bernie
did that this week (thanks!). We closed tickets #1,#2,#3 and #4.

2. Confirm that XML for 3633 is done.
Confirmed. Closing #5.

3. Get over a list of proposed RFCs/drafts to merge.

RFC7083 - SOL_MAX_RT and INF_MAX_RT
Decision: Add a text that SOL_MAX_RT and INF_MAX_RT should be processed
by clients even if status code indicates failure. Incorporate the text
and obsolete 7083.

RFC6977 - Triggered reconfigure
We initially thought that it's about making explicit the currently
implicit assumption that the relays do not modify client's messages and
based on that info we decided to include clarification that relays do
not modify any relayed message (regardless if the message goes up or
down). Unfortunately, that is the clarification done in RFC6422. So the
decision we made is not valid and this topic will have to be revisited.

RFC3736 - stateless DHCPV6
Decision: Add new section for minimal stateless implemention should be.
Then obsolete 3736.

RFC6355 - DUID-UUID
Decision: Include code type 4, reference 6355, do NOT obsolete 6355.

RFC6644 - rebind in reconfigure
Decision: Incorporate everything. My may discuss with Ted whether to
obsolete it, but it seems that the 6644 text will still be technically
valid, so we can leave it.

RFC6422 - relay supplied options
Decision is postponed, as nobody on the call knew what exactly that RFC
changes (it updates 3315).

draft-ietf-dhc-stateful-issues -
The tentative decision was to include all the changes, assuming it
progresses (it is in WGLC right now). Tomek will create each section 4.x
in issue tracker.

draft-ietf-dhc-dhcpv6-unknown-msg - handling by relays
Decision was to include the text. It's a relatively simple clarification
that relays must forward unknown messages.

Bernie proposed to add a section (appendix?) for "Changes from
3315/3633". This will be used by people who are familiar with 3315 and
want to see what's changed (e.g. implementors, document authors).

5. Decide on next steps

- go over reported issues in the tracker. Segregate them into:
  a) obvious/easy to do => apply them before merge
  b) widely supported, but harder to do => apply them after merge
  c) awaiting-consensus => leave them for discussion on DHC WG

- apply/close issues marked as a)
- upload new revision
- merge
- upload new revision
- apply/close issues makred as b)
- request adoption in DHC
- discuss issues from c) group on DHC WG, get consensus on them,
  apply or reject on a per case basis
- WGLC once all issues are closed

Marcin asked whether we could start discussions on DHC earlier. Sheng
was a bit concerned that WG may say that it did not agree to something.
The general conclusion was that it is ok to discuss on DHC whenever we want.

6. Come up with the merge 3633/3315 strategy.
This looks like a too big task for a single person, so we'll probably
try to split this work among two volunteers. Haven't given much thought
about how to do this, but each person being responsible for moving
roughly a half of the 3633 sections seems like a good idea.

This is to PLAN the merge (what terminology to use, i.e. Requesting
Router = DHCPv6 Client for PD) and what will need to be updated in RFC
3315 (new sections to add, sections to update, etc.). Note also that
stateful issues draft changes some PD related items so be mindful of
this (though those are not yet 'approved').

Michael volunteered for this task and we agreed that this would be also
good task for Andrew to help with.

7. Go over reported issues in issue tracker and split into groups.
Unfortunately we ran out of time. So Tomek will go over some of the
tickets and assign them to interested folks, so everyone will have
something to do for the next week or two.

Action items:
Bernie to submit tickets from bake-offs.
Tomek to submit tickets for RFCs/drafts (see agenda item 3 above).
Tomek to submit tickets from stateful-issues
Tomek to go over existing tasks and assign a couple to every bis team
member.
Tomek will create milestones (a-trivial/do-now b-larger/do after merge,
c-awaiting-consensus, will discuss on DHC)

We made a good progress today. Thank you all and safe travels to Andrew!

Tomek