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

["Spencer Dawkins" <[e-mail]>]

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" <[e-mail]>
To: "Spencer Dawkins" <[e-mail]>
Cc: "Sanjay Harwani (sharwani)" <[e-mail]>; "Subbaiah Venkata" 
<[e-mail]>; "Danny McPherson" <[e-mail]>; <[e-mail]>; 
"General Area Review Team" <[e-mail]>; "Ross Callon" 
<[e-mail]>; "Acee Lindem" <[e-mail]>; "Abhay Roy (akr)" 
<[e-mail]>
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)" <[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
>>
>>
>