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

[Carlos Pignataro <[e-mail]>]

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" <[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
>>>
>>>
> 
> 
> _______________________________________________
> Ietf mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ietf
>