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

From: "Spencer Dawkins" <[email-masked]>
Date: Thu, 11 Jun 2009 17:24:38 -0500

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/

   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.

   DNS is used as the centralized mapping table, a network operator may
   desire a different name mapping than the existing in the DNS, or new
   routers may not yet be in DNS.

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.

---

From: "Sanjay Harwani (sharwani)" <[email-masked]>
Date: Fri, 12 Jun 2009 10:08:31 +0530

Adding in Carlos who holds the pen for us, Please see inline starting
with SH:

-----Original Message-----
From: Spencer Dawkins [mailto:[email-masked]] 
Sent: Friday, June 12, 2009 3:55 AM
To: Subbaiah Venkata; Sanjay Harwani (sharwani); Danny McPherson
Cc: [email-masked]; 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).

2.  Possible solutions

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>

3.  Implementation

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.

Regards
Sanjay

---

From: "Spencer Dawkins" <[email-masked]>
Date: Fri, 12 Jun 2009 05:24:26 -0500

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)" <[email-masked]>
To: "Spencer Dawkins" <[email-masked]>; "Subbaiah Venkata" 
<[email-masked]>; "Danny McPherson" <[email-masked]>; "Carlos Pignataro 
(cpignata)" <[email-masked]>
Cc: <[email-masked]>; "General Area Review Team" <[email-masked]>; "Ross 
Callon" <[email-masked]>; "Acee Lindem" <[email-masked]>; "Abhay Roy 
(akr)" <[email-masked]>
Sent: Thursday, June 11, 2009 11:38 PM
Subject: RE: Gen-ART review of draft-ietf-ospf-dynamic-hostname-03

-----Original Message-----
From: Spencer Dawkins [mailto:[email-masked]]
Sent: Friday, June 12, 2009 3:55 AM
To: Subbaiah Venkata; Sanjay Harwani (sharwani); Danny McPherson
Cc: [email-masked]; General Area Review Team; Ross Callon; Acee Lindem;
Abhay Roy (akr)

2.  Possible solutions

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.

3.  Implementation

   <snip>

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.

Regards
Sanjay

---

From: Carlos Pignataro <[email-masked]>
Date: Fri, 12 Jun 2009 11:29:57 -0400

Hi Spencer,

Thank you for your review, please see inline.

> Spencer (nit): s/its/it's/

Ack -- fixed in the working copy.

> 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]

> hostname. the beautiful thing about last call comments is that you guys get 

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.

---

From: "Spencer Dawkins" <[email-masked]>
Date: Fri, 12 Jun 2009 14:22:16 -0500

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" <[email-masked]>
To: "Spencer Dawkins" <[email-masked]>
Cc: "Sanjay Harwani (sharwani)" <[email-masked]>; "Subbaiah Venkata" 
<[email-masked]>; "Danny McPherson" <[email-masked]>; <[email-masked]>; 
"General Area Review Team" <[email-masked]>; "Ross Callon" 
<[email-masked]>; "Acee Lindem" <[email-masked]>; "Abhay Roy (akr)" 
<[email-masked]>
Sent: Friday, June 12, 2009 10:29 AM
Subject: Re: Gen-ART review of draft-ietf-ospf-dynamic-hostname-03

>> mapping

---

From: Carlos Pignataro <[email-masked]>
Date: Fri, 12 Jun 2009 15:52:17 -0400

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