Subject: [dhcwg] *DRAFT* WG meeting minutes from Minneapolis

From: Ralph Droms <[email-masked]>
Date: Mon, 8 Dec 2008 12:26:35 -0500

Attached are draft minutes from the recent WG meeting.  Please respons  
with adds/changes/deletes by Fri, Dec 12.

- Ralph

-----DHC Working group
Thursday, November 20, 2008

Thanks to Ted Lemon for taking notes at the meeting, on which these
minutes are based.

[Agenda]

Alper asked about the DHC Auth analysis.   John will give status update.

[DHC WG I-D status]

draft-ietf-dhc-subnet-alloc
---------------------------
Richard Johnson is confused because there were comments on subnet
alloc draft which he hasn't addressed yet, he thinks he needs to do a
revision before it goes to IESG.   They were mostly nitpicks, he
says.
Ralph: let's take a note of that and deal with that offline.

draft-ietf-dhc-vpn-option
-------------------------

Kim Kinnear: I revised the draft based on the comments in the previous
previous last call, there were only one set of minor comments from
Bernie that said we didn't have to do anything about them, I figured
I'd fold them in if there were any other comments from last call, they
were mostly textual.  I think it's ready for review now.
Ralph: didn't get enough review last time.  Bernie Volz agreed to
review the draft.  Ted agreed to do it; you'd better hassle him about
it later.  David Hankins also agreed to review the draft, in absentia.
Kim: what we have now is ready for review, there are three textual
comments, one minor possible misunderstanding, I'm sure there will be
other similar comments, so not planning to review the draft again
until this review is complete.

draft-ietf-dhc-dhcpv6-reconfigure-rebind
----------------------------------------
Bernie, Richard and Ted Lemon agreed to review during a new WG last
call.

draft-ietf-dhc-relay-id-suboption
---------------------------------
Bernie, Kim and Ted agreed to review during a new WG last call.

draft-ietf-dhc-l2ra, draft-miles-dhc-dhcpv6-ldra
------------------------------------------------
These two drafts need to be correlated so that boilerplate describing
problem space is the same or similar, even though mechanisms are
different.   Ralph is asking everyone to read the docs together so
that we can discuss on mailing list.   Ralph will kick off
discussion.

DHCP Auth analysis
------------------
John reports that we're slightly behind schedule.  The review team has
completed its preliminary review/analysis, and is currently planning
on giving a draft version of that analysis to Jari Arkko (dhc WG
Internet AD) in January.  At that point the review team is going to
determine the next step based on whether we get a revised version of
the draft.  We want to make sure the analysis we do is accurate with
respect to the new revision.

[Reviews of dhc WG I-Ds]

DHCPv6 Remote Boot Options <draft-zimmer-dhc-dhcpv6-remote-boot- 
options-01>
---------------------------------------------------------------------------
Vincent Zimmer from Intel.  He's working on EFI in the UEFI forum.
PXE is evolving within UEFI, and the latest UEFI spec has IPv6.
Problem: what will the boot paradigm scenarios look like on IPv6?  We
can define APIs but on the wire we felt it was best to come to the
IETF and work those.

Question: Who will manage the "processor architecture type"?  Make it
an expert-reviewed IANA managed list.

DHCPv6 option for network boot <draft-ietf-dhc-dhcpv6-opt-netboot-02>
---------------------------------------------------------------------
(no presentation)
Discussion of previous two drafts: Question for the group: how should
the authors of the two drafts work together?
Bernie: Is the next-server option was a good idea given that the URI
option already contains that info?
Ted: Is the PXE stuff was driving idiosyncracies in the protocol.
Ralph wants them to try to reconcile the two drafts offline.

DHCPv4 Vendor-specific Message <draft-volz-dhc-dhcpv4-vendor- 
message-00>,
DHCP Vendor-specific Message <draft-volz-dhc-dhcpv6-vendor-message-01>
------------------------------------------------------------------------
Both drafts were dsicussed together.
Kim: Leasequery had a message ID, but it got stepped on.   If we're
going to let people try things and see if they work, and standardize
real work, could be really valuable.
The consensus at the meeting was to accept these drafts as WG work
items; acceptance will be confirmed on the WG mailing list.

Bulk DHCPv4 Lease Query <draft-kinnear-dhc-dhcpv4-bulk-leasequery-01>
---------------------------------------------------------------------
The consensus at the meeting was to accept this draft as a WG work
item; acceptance will be confirmed on the WG mailing list.

DHCP options for Access Point Name and attach type indication
<draft-patil-dhc-apn-attachtype-options-00>
-------------------------------------------------------------
Jari: Where does this work belong?  Authors and WG chairs will work
together to find a home for the work.
Bernie: better in mip6?
John: have you presented elsewhere?   There may be a parent wg that is
aligned with your tech, and you would consult us for details around
the actual protocol, so we're going to talk to Jari and see if there's
a WG for which this would be appropriate.
Raj: Ralph has looked at NetLMM
Ralph: I appreciate the compliment, but our model of operation is that
options like this that are not fundamental to operation of protocol
have to come from parent wg that has requirement for the option; our
job is to provide input to make sure the option is compatible with
DHCP architecture and options guidelines.
Bernie: are these options always expected to appear together?   Would
a mobile node ever send just APN?   [yes]  In that case is there a
presumed attachment type?
Raj: By default, the access network will assume it is an initial
network entry unless it has other information from another access
router.
Bernie: might want to simplify other option, maybe all you need to say
is here's the APN as one option, and this is a handoff as opposed to
non-handoff.
John: Should this option carry a name or an IP address?
Alper: you referred to APN which is a 3GPP term, but this draft also
applies to WiMAX, terminal can select attaching to visited CSM
vs. home CSM.   So its applicability goes beyond what the terminology
suggests. It also applies to non-mobile IP scenarios: in WiMax we
support mobile IP and non-mobile-IP attachment, which still
needs network selection.
??: why not use old solution
Raj: when you already have l2 mechanism you can use that, but there
are other technologies, e.g. Wifi which doesn't have capability at Mac
layer to send APN info.   In such scenarios you would indicate home
agent, you have to do at higher layer, in this case DHCP.
??: more applicable to wifi?
Raj: applicable to generic networks which do not have this capability  
at l2.
[additional discussion elided]
Ralph: this is why this option needs to be presented elsewhere.

Service Identfiers Option for DHCPv6 <draft-deng-dhc-service- 
identifiers-03>
----------------------------------------------------------------------------
Observation by several sources: this seems to be out of scope for the
WG.   Need to talk after the WG meeting to discover exactly what the
motivation is, what the customer WG might be, whether the work belongs
here.

Scenario and Solution: Simple IP Multi-homing of the Host
<draft-hui-ip-multiple-connections-01>
---------------------------------------------------------
Ralph: the IPv6 side of this should go to 6man, probably.
Ted: Regarding IPv4, it's not clear whether the dhc WG is qualified to
comment on this on a technical level in terms of routing.
Ralph: will talk to ADs.
Hiu: Jari allowed to present here to get feedback.
Bernie: seems to me a respin of RFC3442, which is the classless static
routing option, except this adds ToS.
Jari, John, Ralph, Hui will discuss where the work belongs

Guidelines for Creating New DHCP Options <draft-ietf-dhc-option- 
guidelines-03>
------------------------------------------------------------------------------
Ted: provided comments to list (wordsmithing)
Consensus at the meeting is that the draft is ready for WG last call.

DHCPINFORM Message Clarifications <draft-dhankins-dhcpinform-clarify-00>
------------------------------------------------------------------------
Kim: I think clarifying this is a good idea.   I'm sure I don't agree
exactly with what's written here.   E.g., I don't recall any place
where we've looked at the source address of the DHCP packet, and I
wouldn't start now.   Or at least I'd think really hard before we
start.   Questions about where we send it back to are a good idea, I
don't think the current list is correct.   It's going to take some
work, I think it's worth it.
Hui: There is work on home network configuration using DHCPINFORM, I
support this work item, should I wait for it to finish?
Ralph: The nature of the draft that you're writing, does it overlap
the clarifications that are in this draft?   I don't understand where
there might be a conflict.
Hui: don't see conflict, just using DHCPINFORM.
Ralph: you're using it in draft in other WG.
Hiu: yes, to get configuration information for home network.
Ralph: that would be a good thing for us to look at here.
The consensus at the meeting was to accept this draft as a WG work
item; acceptance will be confirmed on the WG mailing list.

Dynamic Host Configuration Protocol Option for Softwires
<draft-dhankins-softwire-tunnel-option-01>
--------------------------------------------------------
Ted: shutting off DHCPv4 is a potential DoS attack.
Bernie: otherwise the option looks good.
Ted: really think you should just take out the thing about stopping
the DHCPv4 state machine.
Raj: is there a threat model that exists somewhere?   Explains the why
you would potentially have in-band security for DHCP?
Alper: there's a threat analysis draft that talked about that, but it  
expired years ago.
Ralph: history, we decided to do threat analysis, got a reasonable way
in, but didn't finish and didn't publish.   It's a draft of a threat
analysis, but if I remember final state, it was useful.
Paul Selkirk (ISC): presence of softwire option implies no IPv4?
Ted: if you have a network where you don't want IPv4, just don't set
up DHCPv4 server.
This draft will be considered as a softwire WG work item.

Bootstrapping RFC 3118
<draft-yegin-eap-boot-rfc3118-03>
<draft-salowey-dhc-eapkey-3118-00>
----------------------------------

Stefan: is operating wifi roaming, and is very interested in seeing
this draft move forward.  It is possible to rely on layer 1/2
security, but for universities we want people to communicate, so these
measures are not always appropriate.  Restina Foundation, etee (sic)
roaming consortium.
Stig Venaas: I agree with what Stefan said, but I'm involved in same
consortium.  Could be quite good as way to get 3118 deployed.  In
addition to security in L2, could give a touch of binding between
identity and IP address which some people are interested in.
Joe Salowey: we think approaches are similar, could merge.
Alper: going back to Raj's question, today there are various DHCP
deployments where L1 and L2 endpoints don't match DHCP endpoints, in
WiMax we are looking at running DHCP server not in local network but
some other operator's network.  When there's such a mismatch,
embedding DHCP security becomes more essential.  L1 and L2 endpoints
are not in a position to ensure security for signaling that goes
beyond their own domain.
Raj: agree that there are potential scenarios like that.  But there
should be transitive trust.
Alper: not as good.
Ted: would love to see this go forward.
Bernie: V6 as well?
Alper: yes.   we didn't mean to make a distinction between v4 and v6,
but RFC3118 is v4-only.
Bernie: when you respin, make it clear that these documents apply to
both RFC 3118 and RFC 3315.
Alper: will do.
Ralph: Joe: you've already discussed merge with Alper, is that a way  
forward?
Joe: I think that would be excellent.
Alper: agree.
Ralph: okay, we formally request that you do so, once we see draft
we'll review for taking on as WG work item, hope that we can review
that at next IETF.

Ralph: we're done.

Wrap-up
-------
Alper: what happened to DHCP EAP over DHCP?
John: we the analysis team where we stand is we're slightly behind on
delivering the analysis to ADs and WG, our plan right now is based on
the feedback of the conversation with WG meeting in Dublin, we'll
prepare draft based on preliminary analysis.   During DUblin gave
feedback to author, expectation was that there would be a revision, I
haven't seen one.   If one comes out, then we'll have to respin the
analysis to make sure that initial feedback is valid still.
Alper: is there going to be a draft?   What's the format?   I presume
draft, since there's no January meeting.
John: team has targeted based on January, assumption is it would be in
draft format and ultimately shared with WG.
Alper: good.
_______________________________________________
dhcwg mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dhcwg