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

Thanks for the validation, Spencer. We did discuss the level (I.e.,  
case) of the recommendation, and agreed in the lowercase "really good  
idea" qualified with "strongly".

Thanks,

--
Thumb typed by Carlos Pignataro.

On Jun 30, 2009, at 12:41 PM, "Spencer Dawkins" <spencer@wonderhamster.org 
 > wrote:

> 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 wait for direction from your document shepherd
> or AD before posting a new version of the draft.
>
> Document: draft-ietf-ospf-dynamic-hostname-04
> Reviewer: Spencer Dawkins
> Review Date: 30 June 2009
> IESG Telechat date: 02 July 2009
>
> Summary: This version of the draft addresses all of the issues I  
> identified with version 03. This document is ready for publication  
> as a Proposed Standard.
>
> There is some new text in Section 3.1 that I wanted to ask about:
>
>  The value field identifies the symbolic hostname of the router
>  originating the LSA.  This symbolic name can be the FQDN for the
>  router, it can be a subset of the FQDN, or it can be any string
>  operators want to use for the router.  The use of FQDN or a subset of
>  it is strongly recommended.
>
> This being a Proposed Standard (when approved) that uses 2119  
> language... did you mean "strongly RECOMMENDED", or just "a really  
> good idea"?
>
> But you guys can do the right thing without telling me what that  
> is ...
>
> Thanks,
>
> Spencer
>
>
>> 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" <cpignata@cisco.com 
>> >
>> To: "Spencer Dawkins" <spencer@wonderhamster.org>
>> Cc: "Sanjay Harwani (sharwani)" <sharwani@cisco.com>; "Subbaiah  
>> Venkata" <svenkata@google.com>; "Danny McPherson" <danny@tcb.net>; <ietf@ietf.org 
>> >; "General Area Review Team" <gen-art@ietf.org>; "Ross Callon" <rcallon@juniper.net 
>> >; "Acee Lindem" <acee@redback.com>; "Abhay Roy (akr)"  
>> <akr@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)" <sharwani@cisco.com 
>>>> >
>>>> To: "Spencer Dawkins" <spencer@wonderhamster.org>; "Subbaiah  
>>>> Venkata"
>>>> <svenkata@google.com>; "Danny McPherson" <danny@tcb.net>; "Carlos  
>>>> Pignataro
>>>> (cpignata)" <cpignata@cisco.com>
>>>> Cc: <ietf@ietf.org>; "General Area Review Team" <gen- 
>>>> art@ietf.org>; "Ross
>>>> Callon" <rcallon@juniper.net>; "Acee Lindem" <acee@redback.com>;  
>>>> "Abhay Roy
>>>> (akr)" <akr@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:spencer@wonderhamster.org]
>>>> Sent: Friday, June 12, 2009 3:55 AM
>>>> To: Subbaiah Venkata; Sanjay Harwani (sharwani); Danny McPherson
>>>> Cc: ietf@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
>>>>
>>>>
>>>
>>
>>
>> _______________________________________________
>> Gen-art mailing list
>> Gen-art@ietf.org
>> https://www.ietf.org/mailman/listinfo/gen-art
>
>