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" <cpign...@cisco.com> > To: "Spencer Dawkins" <spen...@wonderhamster.org> > Cc: "Sanjay Harwani (sharwani)" <sharw...@cisco.com>; "Subbaiah Venkata" > <svenk...@google.com>; "Danny McPherson" <da...@tcb.net>; <i...@ietf.org>; > "General Area Review Team" <gen-art@ietf.org>; "Ross Callon" > <rcal...@juniper.net>; "Acee Lindem" <a...@redback.com>; "Abhay Roy (akr)" > <a...@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)" <sharw...@cisco.com> >>> To: "Spencer Dawkins" <spen...@wonderhamster.org>; "Subbaiah Venkata" >>> <svenk...@google.com>; "Danny McPherson" <da...@tcb.net>; "Carlos >>> Pignataro >>> (cpignata)" <cpign...@cisco.com> >>> Cc: <i...@ietf.org>; "General Area Review Team" <gen-art@ietf.org>; "Ross >>> Callon" <rcal...@juniper.net>; "Acee Lindem" <a...@redback.com>; "Abhay >>> Roy >>> (akr)" <a...@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:spen...@wonderhamster.org] >>> Sent: Friday, June 12, 2009 3:55 AM >>> To: Subbaiah Venkata; Sanjay Harwani (sharwani); Danny McPherson >>> Cc: i...@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 > i...@ietf.org > https://www.ietf.org/mailman/listinfo/ietf > _______________________________________________ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
