Re: Gen-ART review of draft-ietf-ospf-dynamic-hostname-03
Carlos Pignataro <cpignata@cisco.com> Fri, 12 June 2009 19:52 UTC
Return-Path: <cpignata@cisco.com>
X-Original-To: ietf@core3.amsl.com
Delivered-To: ietf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7A72E3A67F4; Fri, 12 Jun 2009 12:52:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level:
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[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 SsQYWs0DB30N; Fri, 12 Jun 2009 12:52:15 -0700 (PDT)
Received: from av-tac-rtp.cisco.com (hen.cisco.com [64.102.19.198]) by core3.amsl.com (Postfix) with ESMTP id E08473A65A6; Fri, 12 Jun 2009 12:52:14 -0700 (PDT)
X-TACSUNS: Virus Scanned
Received: from rooster.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-rtp.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id n5CJqIH6009413; Fri, 12 Jun 2009 15:52:18 -0400 (EDT)
Received: from [10.116.85.226] (rtp-cpignata-8711.cisco.com [10.116.85.226]) by rooster.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id n5CJqHVr019944; Fri, 12 Jun 2009 15:52:17 -0400 (EDT)
Message-ID: <4A32B1F1.1090809@cisco.com>
Date: Fri, 12 Jun 2009 15:52:17 -0400
From: Carlos Pignataro <cpignata@cisco.com>
Organization: cisco Systems, Inc.
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.21) Gecko/20090302 Thunderbird/2.0.0.21 Mnenhy/0.7.6.0
MIME-Version: 1.0
To: Spencer Dawkins <spencer@wonderhamster.org>
Subject: Re: Gen-ART review of draft-ietf-ospf-dynamic-hostname-03
References: <CA58015D3E7448B79071CC084809C49A@china.huawei.com> <2D9DC4E509A67045894D4EA745FCA398517C90@XMB-BGL-416.cisco.com> <C8B52946990942779C8822716826864F@china.huawei.com> <4A327475.40706@cisco.com> <9844EB26F9BC47038F15F5B3184C179B@china.huawei.com>
In-Reply-To: <9844EB26F9BC47038F15F5B3184C179B@china.huawei.com>
X-Enigmail-Version: 0.95.7
X-Face: *3w8NvnQ|kS~V{&{U}$?G9U9EJQ8p9)O[1[1F'1i>XIc$5FR!hdAIf5}'Xu-3`^Z']h0J* ccB'fl/XJYR[+, Z+jj`4%06nd'y9[ln&ScJT5S+O18e^
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Cc: ietf@ietf.org, General Area Review Team <gen-art@ietf.org>, Acee Lindem <acee@redback.com>, Danny McPherson <danny@tcb.net>, Ross Callon <rcallon@juniper.net>, Subbaiah Venkata <svenkata@google.com>, "Abhay Roy (akr)" <akr@cisco.com>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 12 Jun 2009 19:52:16 -0000
Hi Spencer, Thanks for your review, we've make these changes for the next (post-IETF LC) revision. Thanks, -- Carlos. On 6/12/2009 3:22 PM, Spencer Dawkins wrote: > Hi, Carlos, > > Both of your proposed issue resolutions work for me (and I agree about > putting the duplicated hostname note in the Security Considerations section, > and not in Section 3). > > Thanks, > > Spencer > > ----- Original Message ----- > From: "Carlos Pignataro" <cpignata@cisco.com> > To: "Spencer Dawkins" <spencer@wonderhamster.org> > Cc: "Sanjay Harwani (sharwani)" <sharwani@cisco.com>; "Subbaiah Venkata" > <svenkata@google.com>; "Danny McPherson" <danny@tcb.net>; <ietf@ietf.org>; > "General Area Review Team" <gen-art@ietf.org>; "Ross Callon" > <rcallon@juniper.net>; "Acee Lindem" <acee@redback.com>; "Abhay Roy (akr)" > <akr@cisco.com> > Sent: Friday, June 12, 2009 10:29 AM > Subject: Re: Gen-ART review of draft-ietf-ospf-dynamic-hostname-03 > > >> Hi Spencer, >> >> Thank you for your review, please see inline. >> >> On 6/12/2009 6:24 AM, Spencer Dawkins wrote: >>> Hi, Sanjay, >>> >>> please see inline starting with SD: >>> >>> And thanks for a quick response (before I leave for vacation today). >>> >>> Spencer >>> >>> ----- Original Message ----- >>> From: "Sanjay Harwani (sharwani)" <sharwani@cisco.com> >>> To: "Spencer Dawkins" <spencer@wonderhamster.org>; "Subbaiah Venkata" >>> <svenkata@google.com>; "Danny McPherson" <danny@tcb.net>; "Carlos >>> Pignataro >>> (cpignata)" <cpignata@cisco.com> >>> Cc: <ietf@ietf.org>; "General Area Review Team" <gen-art@ietf.org>; "Ross >>> Callon" <rcallon@juniper.net>; "Acee Lindem" <acee@redback.com>; "Abhay >>> Roy >>> (akr)" <akr@cisco.com> >>> Sent: Thursday, June 11, 2009 11:38 PM >>> Subject: RE: Gen-ART review of draft-ietf-ospf-dynamic-hostname-03 >>> >>> >>> Adding in Carlos who holds the pen for us, Please see inline starting >>> with SH: >>> >>> -----Original Message----- >>> From: Spencer Dawkins [mailto:spencer@wonderhamster.org] >>> Sent: Friday, June 12, 2009 3:55 AM >>> To: Subbaiah Venkata; Sanjay Harwani (sharwani); Danny McPherson >>> Cc: ietf@ietf.org; General Area Review Team; Ross Callon; Acee Lindem; >>> Abhay Roy (akr) >>> Subject: Gen-ART review of draft-ietf-ospf-dynamic-hostname-03 >>> >>> I have been selected as the General Area Review Team (Gen-ART) reviewer >>> for this draft (for background on Gen-ART, please see >>> http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html). >>> >>> Please resolve these comments along with any other Last Call comments >>> you may receive. >>> >>> Document: draft-ietf-ospf-dynamic-hostname-03 >>> Reviewer: Spencer Dawkins >>> Review Date: 2009-06-11 >>> IETF LC End Date: 2009-06-16 >>> IESG Telechat date: (not known) >>> >>> Summary: This document is almost ready for publication as a Proposed >>> Standard. I identified two minor issues listed below. >>> >>> 2. Possible solutions >>> >>> Another approach is having a centralized location where the name-to- >>> Router ID mapping can be kept. DNS can be used for the same. A >>> disadvantage with this centralized solution is that its a single >>> >>> Spencer (nit): s/its/it's/ >> Ack -- fixed in the working copy. >> >>> point of failure; and although enhanced availability of the central >>> mapping service can be designed, it may not be able to resolve the >>> hostname in the event of reachability or network problems. Also, the >>> response time can be an issue with the centralized solution, which >>> can be particularly problematic in times of problem resolution. If >>> >>> Spencer (minor): good point on response times, but I'd also think you'd >>> point out that looking up attributes on a centralized mapping table is >>> exactly the wrong thing to do when you're resolving problems with >>> routing - the centralized resource may not even be reachable. >>> >>> SH: I think we already have it covered just above in the same paragraph. >>> (single point of failure) >>> <snip> >>> A disadvantage with this centralized solution is that its a >>> single >>> point of failure; and although enhanced availability of the central >>> mapping service can be designed, it may not be able to resolve the >>> hostname in the event of reachability or network problems. >>> </snip> >>> >>> SD: I'll call for my eye exam appointment when they open :-). What I >>> liked >>> about the response time text was that it clearly called out the impact on >>> problem resolution - if it was possible for this to be clearly stated for >>> reachability, that seems helpful to me. If I was suggesting text, it >>> might >>> be something like: >>> >>> SD: A disadvantage with this centralized solution is that it's a single >>> point of failure; and although enhanced availability of the central >>> mapping >>> service can be designed, it may not be able to resolve the hostname in >>> the >>> event of reachability or network problems, which can be particularly >>> problematic in times of problem resolution. Also, the response time can >>> be >>> an issue with the centralized solution, which can be equally problematic. >>> >> I think this text improves the paragraph. It is a very subtle (surgical) >> change, but it highlights and emphasizes the impact on problem >> resolution for both reachability and response time. Thanks for the >> suggestion. >> [Authors: change made in the working copy, let me know if other >> suggestions] >> >> >>> 3. Implementation >>> >>> The Dynamic Hostname TLV (see Section 3.1) is OPTIONAL. Upon receipt >>> of the TLV a router may decide to ignore this TLV, or to install the >>> symbolic name and Router ID in its hostname mapping table. >>> >>> Spencer (minor): I'm suspecting that if this attribute becomes widely >>> deployed, network operators would train themselves to read the hostname >>> and pay very little attention to the numeric router ID, so I'm wondering >>> if it's worth saying anything (either here or in an Operations and >>> Management Considerations section <ducks> :-) about the possibility that >>> two different routers may both insist they are "routerXYZ". >>> >>> That would be a misconfiguration, and the text as written allows the >>> router to ignore the second attempt to claim the name "routerXYZ", but >>> it would be irritating to troubleshoot a problem looking at logs that >>> conflate two disjoint "routerXYZ" routers. I'm not a router guy, so I >>> don't know what other responses might be appropriate - I don't think >>> you'd declare an error for a perfectly good next-hop who's confused >>> about its hostname, and I don't know if suggesting that this be SNMP >>> TRAPped would make sense - but you guys would be the right ones to >>> suggest an appropriate response. >>> >>> SH: This is a mis-configuration issue. Network Administrators need to be >>> careful while configuring hostnames on the routers. I think we have text >>> around this in >>> >>> <snip> >>> 5. Security Considerations >>> >>> Since the hostname-to-Router ID mapping relies on information >>> provided by the routers themselves, a misconfigured or compromised >>> router can inject false mapping information. >>> </snip> >>> >>> However I am open to the idea of elaborating it somewhere else too if >>> every body else feels its needed. >>> >>> SD: I actually saw THAT text :-). I was hoping for an explicit mention of >>> the possibility that two routers might both insist they had the same >>> hostname. the beautiful thing about last call comments is that you guys >>> get >>> to do the right thing. >> How about adding it explicitly at the end of the paragraph that Sanjay >> copied? "false mapping information, including a duplicate hostname for >> different Router IDs". I'm not sure text too specific on this point >> would fit in S3 (as that section is rather high-level), and the current >> text in the document, as Spencer pointed out, allows a router to ignore. >> Spencer, authors, what do you think? >> >> [Spencer: Enjoy your vacation] >> >> Thanks, >> >> -- Carlos. >> >> >>> Regards >>> Sanjay >>> >>> > > > _______________________________________________ > Ietf mailing list > Ietf@ietf.org > https://www.ietf.org/mailman/listinfo/ietf >
- Gen-ART review of draft-ietf-ospf-dynamic-hostnam… Spencer Dawkins
- RE: Gen-ART review of draft-ietf-ospf-dynamic-hos… Sanjay Harwani (sharwani)
- Re: Gen-ART review of draft-ietf-ospf-dynamic-hos… Spencer Dawkins
- Re: Gen-ART review of draft-ietf-ospf-dynamic-hos… Carlos Pignataro
- Re: Gen-ART review of draft-ietf-ospf-dynamic-hos… Spencer Dawkins
- Re: Gen-ART review of draft-ietf-ospf-dynamic-hos… Carlos Pignataro