Re: [dhcwg] New draft for leasequery extension

[Bharat Joshi <bharat_joshi at infosys.com>]

Hi Andre,

   Please see my response in line.

Thanks,
Bharat

> General Question:
> 
> I think this draft should mention that it would be preferable that the 
> Access Concentrator be able to emit LeaseQueries on its own via some 
> management IP address as this would place its behaviour completely under 
> RFC 4388.
> 

Though as discussed during WG meeting, it may not be used at all but we
can add a note saying that if there is an option of using a management
address in Layer 2 Access Nodes [which can be used to communicate with
DHCP server and can receive packets from L3 Relay Agent] than that can
also be used for DHCP Leasequery messages.

> 
> Section 4.1:
> 
> Should those MAYs be capital MAYs, or just simple "may"s?  This may be a 
> style question, but it seems to imply to me that with a "MAY" it is a 
> directive to Access Concentrator implementors to perform that 
> behaviour.  As opposed to "may" which would imply to me that this is 
> simply information of interest about what the Access Concentrator might 
> be doing with this information.
> 

Yeah, we can change them to 'may'. It sounds more logical to use 'may'
instead of MAY here.

> 
> Section 5.1:
> 
> I think the option is overspecified.  It should probably be:  Code + Len 
> + hwaddr.  Specifying the length of the hwaddr is unnecessary (can be 
> inferred by the overall length of the option), and using a fixed-size 
> hwaddr field will be wasting 10 bytes (in most cases) of the DHCP packet.
> 
> 

Why we added it like this is to make it compatible with DHCP header
which has these fields defined for a hardware address.

But we agree that it can use a variable length which can be used to
identify the hardware address length. So the option may look as follows:

code     len   [Hardware address details]
+------+------+------------+-------------+
|  X   |  Y   |  htype (1) | hwaddr (Z)  |
+------+------+------------+-------------+

Where Y = Z + 1

> Point #2: That should be "Access concentrators which can receive a 
> unicast reply...", or "Access concentrators which may receive unicast 
> replies...".   And why MUST it be the last option?  Why would it be 
> positionally dependent at all?
> 

This was added to make DHCP Server and L3 Relay Agent 's life a little
easier. It need not be position dependent and so we can replace this
"MUST" with "SHOULD" or "MAY" here.

> Also, does this also mean that DHCP servers MUST NOT send this option 
> back to "normal" DHCP clients?  Because if it does, how will the Access 
> Concentrator be able to distinguish between this option is the one that 
> was reflected back to the AC, vs. this option is the data that is being 
> returned as LeaseQuery data?
> 
> 

Actually clients are not supposed to add this option at all. We can add
a statement saying that "L2 relay agent must treat all its subscriber
ports as untrusted entities. A DHCP packet coming from an untrusted
entity with access-concentrator-hw-addr added MUST be silently
discarded. If L2 relay agent is located farther to Access Node, access
node must not act as a relay agent for that line". 



> _______________________________________________
> dhcwg mailing list
> dhcwg at ietf.org
> https://www1.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***

_______________________________________________
dhcwg mailing list
dhcwg at ietf.org
https://www1.ietf.org/mailman/listinfo/dhcwg