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

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

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