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@xxxxxxxxx> > To: "Spencer Dawkins" <spencer@xxxxxxxxxxxxxxxxx>; "Subbaiah Venkata" > <svenkata@xxxxxxxxxx>; "Danny McPherson" <danny@xxxxxxx>; "Carlos Pignataro > (cpignata)" <cpignata@xxxxxxxxx> > Cc: <ietf@xxxxxxxx>; "General Area Review Team" <gen-art@xxxxxxxx>; "Ross > Callon" <rcallon@xxxxxxxxxxx>; "Acee Lindem" <acee@xxxxxxxxxxx>; "Abhay Roy > (akr)" <akr@xxxxxxxxx> > 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@xxxxxxxxxxxxxxxxx] > Sent: Friday, June 12, 2009 3:55 AM > To: Subbaiah Venkata; Sanjay Harwani (sharwani); Danny McPherson > Cc: ietf@xxxxxxxx; 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@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf