Subject: [dhcwg] FW: Discussion of draft-ietf-dhc-l2ra-01.txt prior to dhc WG last call

From: Bharat Joshi <[email-masked]>
Date: Thu, 18 Sep 2008 10:33:01 +0530

Hi All,

    Here are some suggestions received from Ted with my replies.

Thanks,
Bharat

------------------------------------------------------------------
From: Ted Lemon [[email-masked]]
Sent: Thursday, September 18, 2008 1:57 AM
To: Bharat Joshi
Cc: pavan_kurapati
Subject: Re: [dhcwg] Discussion of draft-ietf-dhc-l2ra-01.txt prior to dhc WG   last call

Sorry, the notes were on my OLPC, which I don't normally use when I'm
at home, so I kept meaning to fetch them and then getting sidetracked.

This is what I wrote in my notes when I reviewed it:

l2ra

It seems broken that the relay agents broadcast the DHCP message on
all ports - that's revealing information to subscribers about each
other that needn't be revealed.

<Bharat>
A normal layer 2 switch [acting as relay agen as well] may not be configured with a Up-link port or a port which leads to the router. In this case, it needs to broadcast the DHCP message on all ports. We included this in the text to show the need and importance of identifying the Up-Link port.
</Bharat>

4.1.1 seems to go into too much detail about the actual DHCP protocol.

<Bharat>
We had started with minimal set of explanation but few internal reviewers and one external reviewer specifically asked few questions because of which we end up explaning everything here. I think this way it looks complete and does not left anything question open.
</Bharat>

4.1.2, part 2, DHCP reply messages sounds like a protocol message.
It would be better to say "in responses to unicast messages from the
client".
<Bharat>
Yes. I can fix this.
</Bharat>

4.2.2 seems broken.   Not sure what to do here - the proposed solution
is probably least likely to break badly.

<Bharat>
I did not get your point here. We have mentioned the issues due to introduction of L2 RA. Did you see any issue with the text here?
</Bharat>

Mostly the draft seems way too verbose.   You have to read it closely
to see all the issues that are brought out.   It might be more
readable/usable if as much repetition of information from the DHCP
protocol spec as possible were removed.

<Bharat>
As mentioned above, this was done mostly to not leave any open question on how L2 RA handle a specific message. Let me look at it again and will try to remove some obvious things.
</Bharat>

**************** 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
[email-masked]
https://www.ietf.org/mailman/listinfo/dhcwg

---

From: Ted Lemon <[email-masked]>
Date: Wed, 17 Sep 2008 22:41:01 -0700

On Sep 17, 2008, at 10:03 PM, Bharat Joshi wrote:
> <Bharat>
> A normal layer 2 switch [acting as relay agen as well] may not be  
> configured with a Up-link port or a port which leads to the router.  
> In this case, it needs to broadcast the DHCP message on all ports.  
> We included this in the text to show the need and importance of  
> identifying the Up-Link port.
> </Bharat>

Okay, thanks.

> We had started with minimal set of explanation but few internal  
> reviewers and one external reviewer specifically asked few questions  
> because of which we end up explaning everything here. I think this  
> way it looks complete and does not left anything question open.
> </Bharat>

This is a common problem.   The solution isn't to add text to your  
draft, though - it's to refer to the RFC that defines the behavior in  
question.   If the reader is not familiar with that RFC, they can go  
get it.   The problem is that the more language from RFC A that we  
stuff into RFC B, the more likely it is that we will get it wrong and  
accidentally advice an implementor to do something that we claim RFC A  
said to do, but that it did not actually say to do.

So I'd really like to see you address this problem that way, rather  
than with all this explanatory text.   Remember that the purpose of a  
standards-track RFC is to specify how to implement a protocol - it is  
not to act as an introductory text.

> It would be better to say "in responses to unicast messages from the

Thanks!

> I did not get your point here. We have mentioned the issues due to  
> introduction of L2 RA. Did you see any issue with the text here?
> </Bharat>

No.   It's just an unsolved problem that makes me somewhat  
uncomfortable.   But I don't see a way around it, and I'm not  
proposing that you drop your proposal because of this problem.   :'}

> <Bharat>
> As mentioned above, this was done mostly to not leave any open  
> question on how L2 RA handle a specific message. Let me look at it  
> again and will try to remove some obvious things.
> </Bharat>

Thanks.

---

From: Bharat Joshi <[email-masked]>
Date: Thu, 18 Sep 2008 11:39:56 +0530

Ted,

> not to act as an introductory text.

Yes. I completely agree with you on this.

Though the text which we have put up in this draft repeats some of the text already available in parent RFC but this is required here to set the context to describe a particular DHCP message handling in L2 RA.

Let me look at the text again and as I mentioned earlier, I will try to remove the extra text which is obvious and taken as it is from parent RFC.

Does this sound ok to you?

Thanks,
Bharat