Subject: Re: [dhcwg] WG last calls on several WG documents

From: Said Ouissal <[email-masked]>
Date: Mon, 20 Nov 2006 00:45:39 +0100

Ralph,

At 12:15 16-11-2006, Ralph Droms wrote:
>draft-ietf-dhc-subnet-alloc-04
>   Subnet Allocation Option
>   Need to review IPR claims related to this document

One action item which remains open with regards to this draft was the 
discussion (and decision) of merging this draft with the micro-block 
allocation draft (draft-shen-dhc-block-alloc-00.txt).

To refresh your mind, the view carried by the authors of the 
micro-block allocation draft is that while 
draft-ietf-dhc-subnet-alloc-04 addresses the ability to assign a 
subnet to a dhcp client, it does not well enough address the ability 
to assign a subnet to a DHCP proxy or a "remote DHCP server", which 
in turn can re-assign single IPs to clients. Especially if this DHCP 
proxy is co-located within an edge router, it allows for more 
efficient provisioning and network routing information annoucement 
for reachability reasons.

To be more precise, draft-ietf-dhc-subnet-alloc-04 does address the 
ability to request a subnet (as a client) so that it can be then 
servicing (mentioned in the draft as hierarchical DHCP servers) other 
clients, the main difference is that for Micro-Block the mode of 
operation is based around an intermediate DHCP proxy agent who 
leverages option 82 field and piggy-backs on a true client DHCP IP 
address assignment process. This is a more simple mode of operation 
and does not require a DHCP client operating on the intermediate router/agent.

Tx,
Said.  

_______________________________________________
dhcwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dhcwg

---

From: Said Ouissal <[email-masked]>
Date: Mon, 20 Nov 2006 00:50:52 +0100

Ralph,

Tx,
Said.

---

From: "Brzozowski, John" <[email-masked]>
Date: Tue, 21 Nov 2006 06:59:42 -0500

I support WG last call for the following:

draft-ietf-dhc-dhcpv6-agentopt-delegate-01
  DHCPv6 Relay Agent Assignment Notification (RAAN) Option

draft-ietf-dhc-dhcpv6-srsn-option-00
  DHCPv6 Server Reply Sequence Number Option

draft-ietf-dhc-dhcpv6-ero-00
  DHCPv6 Relay Agent Echo Request Option

draft-ietf-dhc-dhcvp6-leasequery-00
  DHCPv6 Leasequery

Thanks and sorry the delayed response,

John

-----Original Message-----
From: Ralph Droms [mailto:[email-masked]] 
Sent: Tuesday, November 21, 2006 6:31 AM
To: dhcwg
Cc: Stig Venaas
Subject: [dhcwg] WG last calls on several WG documents

2nd try - I know this is a holiday week in the US; so far, we've only
received one response.  If we don't hear more support for these drafts,
we will have to abandon them

- Ralph

=====

We need to confirm WG consensus in support of holding WG last calls on
several dhc WG documents that were discussed at the WG meeting in San
Diego.

The first four of these documents are:

draft-ietf-dhc-dhcpv6-agentopt-delegate-01
  DHCPv6 Relay Agent Assignment Notification (RAAN) Option

draft-ietf-dhc-dhcpv6-srsn-option-00
  DHCPv6 Server Reply Sequence Number Option

draft-ietf-dhc-dhcpv6-ero-00
  DHCPv6 Relay Agent Echo Request Option

draft-ietf-dhc-dhcvp6-leasequery-00
  DHCPv6 Leasequery

If you have any objections to a WG last call for any of these documents,
please respond to the mailing list.  If you are in agreement that these
documents are ready for WG last call, send a positive ACK to the mailing
list so we can assess support for those last calls.  We will review the
responses received by Mon, Nov 27 and initiate the supported WG last
calls at that time.

There are two other documents that were discussed at the WG meeting,
which are not quite ready for WG consensus on last call:

draft-ietf-dhc-dhcpv6-reconfigure-rebind-00
  Rebind Capability in DHCPv6 Reconfigure Messages
  Requires editorial update to indicate it revises RFC 3315

- Ralph

---

From: "Bernie Volz \(volz\)" <[email-masked]>
Date: Tue, 21 Nov 2006 11:29:51 -0500

I do to ... But then I'm a co-author on all 4 so I'm not sure if that
counts.

- Bernie 

-----Original Message-----
From: Brzozowski, John [mailto:[email-masked]] 
Sent: Tuesday, November 21, 2006 7:00 AM
To: Ralph Droms (rdroms); dhcwg
Cc: Stig Venaas
Subject: RE: [dhcwg] WG last calls on several WG documents

John

-----Original Message-----
From: Ralph Droms [mailto:[email-masked]] 
Sent: Tuesday, November 21, 2006 6:31 AM
To: dhcwg
Cc: Stig Venaas
Subject: [dhcwg] WG last calls on several WG documents

- Ralph

=====

- Ralph

---

From: "Bernie Volz \(volz\)" <[email-masked]>
Date: Wed, 22 Nov 2006 18:09:55 -0500

David:

>I would like to again thank the authors of the leasequery draft
>for not only simplifying the message compared to the previous
>version, but /over/simplifying it beyond what I thought was
>reasonable to ask for (a defined drop order minus the bulk query,
>and only one or two fewer query types would have been OK by me).
>
>Anyway, my day job's work backlog thanks you.

The problem was that:
- QUERY_BY_LINK was a bulk query. So, it clearly had to go without some
means to return lots of data.
- QUERY_BY_PREFIX, as defined, was also capable of returning many
clients worth of data. And, the QUERY_BY_ADDRESS that remains now will
return the client that either has been delegated the prefix containing
the query address or was statefully assigned the address. This was a
beneficial change for Relay Agents that might need to restore
information after a reboot, since they're more likely to see traffic for
an address and need to know whether a client has it (or a prefix)
leased.
- QUERY_BY_REMOTE_ID could probably have stayed, but one concern is that
if the remote id isn't unique to a client (for example, it is a switch
port, which could have different clients plugged into it at different
times), we're back to the multiple client issue.
- QUERY_BY_DEVICE_ID required another draft which was never submitted
and has been dropped at this time. So, without that other work, it
didn't make sense to include it. Depending on the device id and its
uniqueness, it too potentially could return multiple clients.

That leaves QUERY_BY_CLIENTID and given that we were also asked to keep
the usage model to DHCPv6 devices (aka relay agents), it hardly seemed
likely that these devices would need that query.

Note that we didn't cut as much as we could have since the underlying
structure to add additional queries in the future does still exist. So,
if someone wants to add some back, write a draft ...

- Bernie 

-----Original Message-----
From: David W. Hankins [mailto:[email-masked]] 
Sent: Tuesday, November 21, 2006 12:19 PM
To: [email-masked]
Subject: Re: [dhcwg] WG last calls on several WG documents

> draft-ietf-dhc-dhcvp6-leasequery-00

I have read and support taking these three drafts to WG last
call.

Note that I have omitted the SRSN draft, which I have not had time
to read carefully through its revisions.

I would like to again thank the authors of the leasequery draft
for not only simplifying the message compared to the previous
version, but /over/simplifying it beyond what I thought was
reasonable to ask for (a defined drop order minus the bulk query,
and only one or two fewer query types would have been OK by me).

Anyway, my day job's work backlog thanks you.

-- 
David W. Hankins	"If you don't do it right the first time,
Software Engineer		you'll just have to do it again."
Internet Systems Consortium, Inc.	-- Jack T. Hankins