Subject: [dhcwg] WGLC: draft-ietf-dhc-leasequery-by-remote-id

From: Ted Lemon <[email-masked]>
Date: Tue, 28 Sep 2010 08:31:34 -0700

It was my impression that this had passed WGLC, but it turns out that nobody said anything in favor of the draft during the WGLC.   There was substantial review, and the document is pretty good, but it hasn't actually passed WGLC.   I think there is substantial support for the document, but we need to actually see that support on the mailing list.

So if you want the draft to proceed to the IESG, please indicate your support for it here on the mailing list.   If you object, please indicate that as well.   The original WGLC was at the end of June, and nobody registered any objections then, so if I don't hear any objections by close of business on Friday, and I do hear substantial support, I'm going to call that consensus.

Please accept my apologies for the confusion around this issue--I should have noticed this and issued a new WGLC a lot sooner, but for some reason the bit got set in my mind that it had passed WGLC, and so it was just waiting for me or John to do a final review before doing the shepherd writeup; it was during that review that I noticed the lack of responses to the WGLC.

---

From: Niall O'Reilly <[email-masked]>
Date: Tue, 28 Sep 2010 16:53:58 +0100

On 28/09/10 16:31, Ted Lemon wrote:
> if I don't hear any objections by close of business on Friday, and I do hear substantial support, I'm going to call that consensus.

	support++
	Niall

---

From: Stephen Jacob <[email-masked]>
Date: Tue, 28 Sep 2010 17:40:06 -0700

In the words of Niall O'Reilly:  support++

I had comments on the draft back in July, but they were addressed to my
satisfaction.

Please add my +1 to this.

Regards,
Stephen

On Tue, Sep 28, 2010 at 08:31:34AM -0700, Ted Lemon wrote:
> It was my impression that this had passed WGLC, but it turns out that
> nobody said anything in favor of the draft during the WGLC.   There
> was substantial review, and the document is pretty good, but it hasn't
> actually passed WGLC.   I think there is substantial support for the
> document, but we need to actually see that support on the mailing
> list.
> 
> So if you want the draft to proceed to the IESG, please indicate your
> support for it here on the mailing list.   If you object, please
> indicate that as well.   The original WGLC was at the end of June, and
> nobody registered any objections then, so if I don't hear any
> objections by close of business on Friday, and I do hear substantial
> support, I'm going to call that consensus.
> 
> Please accept my apologies for the confusion around this issue--I
> should have noticed this and issued a new WGLC a lot sooner, but for
> some reason the bit got set in my mind that it had passed WGLC, and so
> it was just waiting for me or John to do a final review before doing
> the shepherd writeup; it was during that review that I noticed the
> lack of responses to the WGLC.

-- 
 Stephen Jacob | [email-masked] | +1 650 381 6051
 Nominum, Inc. |  http://www.nominum.com/  | +1 650 381 6000

---

From: Ted Lemon <[email-masked]>
Date: Tue, 28 Sep 2010 19:44:01 -0700

> In the words of Niall O'Reilly:  support++

Thanks!

BTW, I did actually have one minor suggestion.   If there's strong resistance I'll withdraw it, but if nobody objects I think it'll be a win: the draft currently requires the server to respond with a remote-id option even if it wasn't requested.  I think it would be better to place the burden on the access concentrator to request the option, and if it doesn't, all bets are off.  This would eliminate the need for a bit of special code in the server to check for the missing option in the ORO.

---

From: Stephen Jacob <[email-masked]>
Date: Tue, 28 Sep 2010 20:29:03 -0700

On Tue, Sep 28, 2010 at 07:44:01PM -0700, Ted Lemon wrote:
> On Sep 28, 2010, at 5:40 PM, Stephen Jacob <[email-masked]> wrote:
> BTW, I did actually have one minor suggestion.   If there's strong resistance
> I'll withdraw it, but if nobody objects I think it'll be a win: the draft
> currently requires the server to respond with a remote-id option even if it
> wasn't requested.  I think it would be better to place the burden on the
> access concentrator to request the option, and if it doesn't, all bets are
> off.  This would eliminate the need for a bit of special code in the server
> to check for the missing option in the ORO.

Oh! Very good suggestion.

Strong +1 re Ted's suggestion. :)  Especially in a new specification,
I really like the idea of putting the onus on the access concentrator.

I'd like to see it made explicit, if the change you suggest is made,
that it must be requested in the ORO so as to avoid implementors of
the access concentrator missing that and DHCP server implementors
having to add the special code anyway to work around that.

Regards,
Stephen

---

From: Pavan Kurapati <[email-masked]>
Date: Wed, 29 Sep 2010 10:23:53 +0530

I think the point of discussion has come from the section 4.3 of the
draft "In the case where more than one IP address has been involved in
a DHCP message exchange with the client specified by the Remote ID,
then the list of all those IP addresses MUST be returned in the
associated-ip option, whether or not that option was requested as part
of the Parameter Request List option."

Associated-IP option is returned only when there is more than one IP
address involved. But Access concentrator has no way to know that
there is going to be more than one IP address for the remote-ID, hence
making it a MUST in access concentrator's parameter request list may
not be feasible IMO.

I have one question. If an option is requested in parameter-request
list, should DHCP server return that option as a MUST? RFC 2132 is not
worded very clearly in this respect. RFC 2132 says " The client MAY
list the options in order of preference.  The DHCP
   server is not required to return the options in the requested
order, but MUST try to insert the requested options in the order
requested by the client", but it doesnt say that DHCP server MUST
return the options listed in the parameter request list? If this
condition is relaxed, then we may make parameter-request list
mandatory in Access concentrator with option 82 and parameter request
list option as a MUST.

Thanks,
Pavan

On Wed, Sep 29, 2010 at 8:59 AM, Stephen Jacob
<[email-masked]> wrote:
> _______________________________________________
> dhcwg mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dhcwg
>

---

From: Mukund Kamath <[email-masked]>
Date: Wed, 29 Sep 2010 16:44:21 +0530

I am in support of the document.

Regards,
Mukund Kamath
________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Ted Lemon [[email-masked]]
Sent: Tuesday, September 28, 2010 11:31 AM
To: DHC Working Group
Subject: [dhcwg] WGLC: draft-ietf-dhc-leasequery-by-remote-id

_______________________________________________
dhcwg mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dhcwg
**************** CAUTION - Disclaimer *****************
This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended solely 
for the use of the addressee(s). If you are not the intended recipient, please 
notify the sender by e-mail and delete the original message. Further, you are not 
to copy, disclose, or distribute this e-mail or its contents to any other person and 
any such actions are unlawful. This e-mail may contain viruses. Infosys has taken 
every reasonable precaution to minimize this risk, but is not liable for any damage 
you may sustain as a result of any virus in this e-mail. You should carry out your 
own virus checks before opening the e-mail or attachment. Infosys reserves the 
right to monitor and review the content of all messages sent to or from this e-mail 
address. Messages sent to or from this e-mail address may be stored on the 
Infosys e-mail system.
***INFOSYS******** End of Disclaimer ********INFOSYS***

---

From: Ted Lemon <[email-masked]>
Date: Wed, 29 Sep 2010 06:05:22 -0700

On Sep 28, 2010, at 9:53 PM, "Pavan Kurapati" <[email-masked]> wrote:

> return the options listed in the parameter request list?

The server doesn't have to return an option to the client if there's no option to return, regardless of the contents of the prl.