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

Ted Lemon <Ted.Lemon@nominum.com> Thu, 18 September 2008 05:40 UTC

Return-Path: <dhcwg-bounces@ietf.org>
X-Original-To: dhcwg-archive@megatron.ietf.org
Delivered-To: ietfarch-dhcwg-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 884C628C327; Wed, 17 Sep 2008 22:40:51 -0700 (PDT)
X-Original-To: dhcwg@core3.amsl.com
Delivered-To: dhcwg@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 511663A6ADF for <dhcwg@core3.amsl.com>; Wed, 17 Sep 2008 22:40:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.139
X-Spam-Level:
X-Spam-Status: No, score=-6.139 tagged_above=-999 required=5 tests=[AWL=0.460, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g2S7DNf-+xY8 for <dhcwg@core3.amsl.com>; Wed, 17 Sep 2008 22:40:49 -0700 (PDT)
Received: from exprod7og109.obsmtp.com (exprod7og109.obsmtp.com [64.18.2.171]) by core3.amsl.com (Postfix) with ESMTP id 555CF3A6A93 for <dhcwg@ietf.org>; Wed, 17 Sep 2008 22:40:49 -0700 (PDT)
Received: from source ([64.89.228.229]) (using TLSv1) by exprod7ob109.postini.com ([64.18.6.12]) with SMTP; Wed, 17 Sep 2008 22:41:03 PDT
Received: from webmail.nominum.com (webmail.nominum.com [64.89.228.50]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (Client CN "webmail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 18CEB1B80A6 for <dhcwg@ietf.org>; Wed, 17 Sep 2008 22:41:09 -0700 (PDT)
Received: from [10.0.0.252] (71.32.40.139) by exchange-01.win.nominum.com (64.89.228.50) with Microsoft SMTP Server (TLS) id 8.1.291.1; Wed, 17 Sep 2008 22:41:02 -0700
Message-ID: <861903DA-24EB-4329-B41C-BB4D9ADBF49C@nominum.com>
From: Ted Lemon <Ted.Lemon@nominum.com>
To: DHC WG <dhcwg@ietf.org>
In-Reply-To: <31D55C4D55BEED48A4459EB64567589A0C95C7D8FF@BLRKECMBX02.ad.infosys.com>
MIME-Version: 1.0 (Apple Message framework v928.1)
Date: Wed, 17 Sep 2008 22:41:01 -0700
References: <46EDFFB40E4ABC4BB72D47CF34B186E30C84900A1B@BLRKECMBX02.ad.infosys.com> <31D55C4D55BEED48A4459EB64567589A0C95C7D8FB@BLRKECMBX02.ad.infosys.com>, <8E8BCEF6-E08F-43C5-9091-AF6E056A3211@nominum.com>, <31D55C4D55BEED48A4459EB64567589A0C95C7D8FD@BLRKECMBX02.ad.infosys.com> <31D55C4D55BEED48A4459EB64567589A0C95C7D8FF@BLRKECMBX02.ad.infosys.com>
X-Mailer: Apple Mail (2.928.1)
Subject: Re: [dhcwg] FW: Discussion of draft-ietf-dhc-l2ra-01.txt prior to dhc WG last call
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <dhcwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/dhcwg>
List-Post: <mailto:dhcwg@ietf.org>
List-Help: <mailto:dhcwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: dhcwg-bounces@ietf.org
Errors-To: dhcwg-bounces@ietf.org

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.


> 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>

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.

> 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>

Thanks!

> 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>

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.


_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www.ietf.org/mailman/listinfo/dhcwg