Re: Gen-ART review of draft-ietf-ospf-dynamic-hostname-03

[Carlos Pignataro <[e-mail]>]

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)" <[e-mail]>
> To: "Spencer Dawkins" <[e-mail]>; "Subbaiah Venkata" 
> <[e-mail]>; "Danny McPherson" <[e-mail]>; "Carlos Pignataro 
> (cpignata)" <[e-mail]>
> Cc: <[e-mail]>; "General Area Review Team" <[e-mail]>; "Ross 
> Callon" <[e-mail]>; "Acee Lindem" <[e-mail]>; "Abhay Roy 
> (akr)" <[e-mail]>
> 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:[e-mail]]
> Sent: Friday, June 12, 2009 3:55 AM
> To: Subbaiah Venkata; Sanjay Harwani (sharwani); Danny McPherson
> Cc: [e-mail]; 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 
> 
>