Re: [Gen-art] Gen-ART review of draft-ietf-ospf-dynamic-hostname-03
"Spencer Dawkins" <spencer@wonderhamster.org> Fri, 12 June 2009 19:23 UTC
Return-Path: <spencer@wonderhamster.org>
X-Original-To: gen-art@core3.amsl.com
Delivered-To: gen-art@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DAB033A6C8D; Fri, 12 Jun 2009 12:23:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.37
X-Spam-Level:
X-Spam-Status: No, score=-2.37 tagged_above=-999 required=5 tests=[AWL=0.228, BAYES_00=-2.599, STOX_REPLY_TYPE=0.001]
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 WfYYp-HRop0g; Fri, 12 Jun 2009 12:23:18 -0700 (PDT)
Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by core3.amsl.com (Postfix) with ESMTP id 6CB923A6C9B; Fri, 12 Jun 2009 12:23:18 -0700 (PDT)
Received: from S73602b (w173.z064002096.dfw-tx.dsl.cnc.net [64.2.96.173]) by mrelay.perfora.net (node=mrus0) with ESMTP (Nemesis) id 0MKp8S-1MFCKh44l9-000fqT; Fri, 12 Jun 2009 15:22:46 -0400
Message-ID: <9844EB26F9BC47038F15F5B3184C179B@china.huawei.com>
From: Spencer Dawkins <spencer@wonderhamster.org>
To: Carlos Pignataro <cpignata@cisco.com>
References: <CA58015D3E7448B79071CC084809C49A@china.huawei.com> <2D9DC4E509A67045894D4EA745FCA398517C90@XMB-BGL-416.cisco.com> <C8B52946990942779C8822716826864F@china.huawei.com> <4A327475.40706@cisco.com>
Date: Fri, 12 Jun 2009 14:22:16 -0500
MIME-Version: 1.0
Content-Type: text/plain; format="flowed"; charset="iso-8859-1"; reply-type="original"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.5512
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579
X-Provags-ID: V01U2FsdGVkX1+5ptGRR5rweRR7tM8kW+B/yD6y0LVaBW0L/1x gbpUG7Axv2BRwP3Nwl1W9Sn5evsD6nTp0tzbMOQNt0tua7rreZ XnP1DDmmAfGuBGsVtrogdvGQiz8j77Wc7o5McvzJwE=
Cc: "Sanjay Harwani (sharwani)" <sharwani@cisco.com>, 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>
Subject: Re: [Gen-art] Gen-ART review of draft-ietf-ospf-dynamic-hostname-03
X-BeenThere: gen-art@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <gen-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/gen-art>
List-Post: <mailto:gen-art@ietf.org>
List-Help: <mailto:gen-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 12 Jun 2009 19:23:20 -0000
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 >> >> >
- [Gen-art] Gen-ART review of draft-ietf-ospf-dynam… Spencer Dawkins
- Re: [Gen-art] Gen-ART review of draft-ietf-ospf-d… Sanjay Harwani (sharwani)
- Re: [Gen-art] Gen-ART review of draft-ietf-ospf-d… Spencer Dawkins
- Re: [Gen-art] Gen-ART review of draft-ietf-ospf-d… Carlos Pignataro
- Re: [Gen-art] Gen-ART review of draft-ietf-ospf-d… Spencer Dawkins
- Re: [Gen-art] Gen-ART review of draft-ietf-ospf-d… Carlos Pignataro
- [Gen-art] Gen-ART review of draft-ietf-ospf-dynam… Spencer Dawkins
- Re: [Gen-art] Gen-ART review of draft-ietf-ospf-d… Carlos Pignataro (cpignata)