Re: [Gen-art] Gen-ART review of draft-ietf-ospf-dynamic-hostname-03
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) sharw...@cisco.com To: Spencer Dawkins spen...@wonderhamster.org; Subbaiah Venkata svenk...@google.com; Danny McPherson da...@tcb.net; Carlos Pignataro (cpignata) cpign...@cisco.com Cc: i...@ietf.org; General Area Review Team gen-art@ietf.org; Ross Callon rcal...@juniper.net; Acee Lindem a...@redback.com; Abhay Roy (akr) a...@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:spen...@wonderhamster.org] Sent: Friday, June 12, 2009 3:55 AM To: Subbaiah Venkata; Sanjay Harwani (sharwani); Danny McPherson Cc: i...@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/ 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. 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
Re: [Gen-art] review of draft-ietf-pce-monitoring-04.txt
Here you are, the new revision addressing all Gen-art review comments has been posted. Many Thanks. JP. On May 28, 2009, at 9:47 PM, Ross Callon wrote: Last call is over. Please respin (I see the most recent version dated January 2009). thanks, Ross -Original Message- From: JP Vasseur [mailto:jvass...@cisco.com] Sent: 28 April 2009 01:37 To: Ross Callon Cc: Francis Dupont; General Area Review Team; JP Vasseur; Jean-Louis Le Roux; y.ikej...@ntt.com Subject: Re: review of draft-ietf-pce-monitoring-04.txt Ah yes, I thought the IETF LC was ended. Will respin right after that. Thanks Ross. JP. On Apr 25, 2009, at 7:10 AM, Ross Callon wrote: You need to wait for the IETF last call to end before respinning. Once the IETF last call ends, then yes please respin. Thanks, Ross -Original Message- From: JP Vasseur [mailto:jvass...@cisco.com] Sent: 24 April 2009 02:05 To: Francis Dupont; Ross Callon Cc: General Area Review Team; JP Vasseur; Jean-Louis Le Roux; y.ikej...@ntt.com Subject: Re: review of draft-ietf-pce-monitoring-04.txt Many Thanks Francis. Ross, do you want me to address those comments and respin ? Thanks. JP. On Apr 23, 2009, at 11:46 PM, Francis Dupont 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 resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-pce-monitoring-04.txt Reviewer: Francis Dupont Review Date: 2009-04-22 IETF LC End Date: 2009-04-27 IESG Telechat date: unknown Summary: Not Ready Major issues: none but some minor issues which should need another cycle. Minor issues: - 1 page 5: as the PCReq/PCReq seem to come from nowhere in 3.1 page 8 IMHO it is the right place to introduce them, for instance (it should be hard to be simpler) add after the first path computation request the comment (PCReq message). Perhaps this is not the right thing but it should be clear from the introduction the document both specifies new messages and new objects, and these new objects can be used in PCReq/PCRep too. - 4.1 page 12: incompatible requirement There SHOULD NOT be more than one instance of the MONITORING object with PCRep syntax (response-list) - 4.1 page 13: even if MONITORING object has no optional TLV currently defined, the format of these TLVs must be specified. I propose the PCEP generic TLV format, RFC 5440 7.1. - 4.3 page 16: the variance of time is a squared time. I propose to switch to standard deviation (ecart type in French, the square root of the variance) - 8.6 page 23: CONGESTION object has no defined flag. (this is not editorial because of IANA review/processing) Nits/editorial comments: - Abstract page 2 is in one block, I suggest to insert a line break before In PCE-based - Requirements Language page 2 should be moved in the terminology section - ToC page 3 / 8.3 page 21: New Error-Type and Error-Values - New Error-Values - ToC page 3 and 10 page 23: Acknowledgements - Acknowledgments - 1 page 4: IGP - Interior Gateway Protocol (IGP) - 1 page 4: troubeshooting - troubleshooting - 1 page 4: more than one PCE is - are? - 1 page 4: BRPC - Backward Recursive PCE-based Computation (BRPC) - 1 page 5: bolean - boolean - 1 page 5: By In band - By in band - 1 page 5 and many other places: e.g. - e.g., - 3 page 6: PCEMonReq - PCMonReq - 3 page 6: too many in this document (wording) - 3.1 page 8: insert a line break between: svec-list::=SVEC[svec-list] request-list::=request[request-list] - 3.1 page 8: Section 4.2.) - Section 4.2) - 3.1 page 8: charaterize - characterize - 3.1 page 9: PCMonreq - PCMonReq - 3.2 page 11: PROC-TIME and CONGESTION are defined further (8. [56]). where NO-PATH is defined? - 4.1 page 13: choose between Monitoring-id-number and monitoring- id- number - 4.1 page 13: a wrap back to one is unclear, 0x + 1 == 0, not 1. If the value zero is reserved this should be more explicit. - 4.3 page 15 1): Min, Average, Max and Variance - minimum, maximum, average and variance - 4.2 page 15 2): Procesing-time - Processing-time - 4.4 page 17: currently defined: - currently defined. - 6 page 18: value=Reception of an unacceptable number of unknown PCEP message. - value=5 Reception of an unacceptable number of unrecognized PCEP message. (i.e., put the reason value and correct meaning with a closing , BTW there are two occurrences to fix) - 6 page 19: in the next hop PCE: such next-hop choose between next-hop and next hop (I prefer the second). - 6 page 19: extra Upon receiving a PCMonRep message - 6 page 19: carrries - carries - 6 page 19: Multi-destination - multi-destination - 8.2 page 20 (last line): are defined in this document. - are defined in this document: - 8.3 page 21: as it doesn't define new error-type(s) I propose: New Error-Type and Error-Values - New Error-Values - 8.3
Re: [Gen-art] Gen-ART LC Review of draft-hollenbeck-rfc4933bis-01
-Original Message- From: Ben Campbell [mailto:b...@estacado.net] Sent: Thursday, June 11, 2009 5:28 PM To: Hollenbeck, Scott; General Area Review Team Cc: Alexey Melnikov; Chris Newman; i...@ietf.org Subject: Gen-ART LC Review of draft-hollenbeck-rfc4933bis-01 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-hollenbeck-rfc4933bis-01 Reviewer: Ben Campbell Review Date: 2009-06-11 IETF LC End Date: 2009-06-11 IESG Telechat date: (if known) Summary: This draft is ready for publication as a full standard. Note: The LC announcement mentions an implementation report at http://www.ietf.org/IESG/implementation.html . If there is in fact a report there for this draft, I did not find it. The implementation report that was submitted when RFC 3733 (an earlier version of the document) was considered for publication as a draft standard can be found here: http://www.ietf.org/IESG/Implementations/RFCs3730-3734_implem.txt -Scott- ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
Re: [Gen-art] Gen-ART LC Review of draft-hollenbeck-rfc4933bis-01
On Jun 12, 2009, at 7:27 AM, Hollenbeck, Scott wrote: Note: The LC announcement mentions an implementation report at http://www.ietf.org/IESG/implementation.html . If there is in fact a report there for this draft, I did not find it. The implementation report that was submitted when RFC 3733 (an earlier version of the document) was considered for publication as a draft standard can be found here: http://www.ietf.org/IESG/Implementations/RFCs3730-3734_implem.txt -Scott- Ah, sorry, I did not think to look under the old RFC name. I withdraw the comment. Thanks! Ben. ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] Gen-ART LC Review of draft-ietf-pce-inter-layer-frwk-10.txt
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-pce-inter-layer-frwk-10.txt Reviewer: Sean Turner Review Date: 2009-06-09 IETF LC End Date: 2009-06-16 IESG Telechat date: (not known) Summary: This draft is basically ready for publication (informational with no RFC 2119 requirements terminology), but has nits that should be fixed before publication. I ran it through ID-nits: - is a pre-5378 disclaimer needed? - draft-ietf-pce-brpc has been published as RFC 5441 - draft-ietf-pce-path-key has been published as RFC 5520 In 5.1, there's missing reference: PCEP [ a href='RFC5440] ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
Re: [Gen-art] 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) sharw...@cisco.com To: Spencer Dawkins spen...@wonderhamster.org; Subbaiah Venkata svenk...@google.com; Danny McPherson da...@tcb.net; Carlos Pignataro (cpignata) cpign...@cisco.com Cc: i...@ietf.org; General Area Review Team gen-art@ietf.org; Ross Callon rcal...@juniper.net; Acee Lindem a...@redback.com; Abhay Roy (akr) a...@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:spen...@wonderhamster.org] Sent: Friday, June 12, 2009 3:55 AM To: Subbaiah Venkata; Sanjay Harwani (sharwani); Danny McPherson Cc: i...@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
Re: [Gen-art] Gen-ART review of draft-ietf-ospf-dynamic-hostname-03
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 cpign...@cisco.com To: Spencer Dawkins spen...@wonderhamster.org Cc: Sanjay Harwani (sharwani) sharw...@cisco.com; Subbaiah Venkata svenk...@google.com; Danny McPherson da...@tcb.net; i...@ietf.org; General Area Review Team gen-art@ietf.org; Ross Callon rcal...@juniper.net; Acee Lindem a...@redback.com; Abhay Roy (akr) a...@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) sharw...@cisco.com To: Spencer Dawkins spen...@wonderhamster.org; Subbaiah Venkata svenk...@google.com; Danny McPherson da...@tcb.net; Carlos Pignataro (cpignata) cpign...@cisco.com Cc: i...@ietf.org; General Area Review Team gen-art@ietf.org; Ross Callon rcal...@juniper.net; Acee Lindem a...@redback.com; Abhay Roy (akr) a...@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:spen...@wonderhamster.org] Sent: Friday, June 12, 2009 3:55 AM To: Subbaiah Venkata; Sanjay Harwani (sharwani); Danny McPherson Cc: i...@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
Re: [Gen-art] Gen-ART review of draft-ietf-ospf-dynamic-hostname-03
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 cpign...@cisco.com To: Spencer Dawkins spen...@wonderhamster.org Cc: Sanjay Harwani (sharwani) sharw...@cisco.com; Subbaiah Venkata svenk...@google.com; Danny McPherson da...@tcb.net; i...@ietf.org; General Area Review Team gen-art@ietf.org; Ross Callon rcal...@juniper.net; Acee Lindem a...@redback.com; Abhay Roy (akr) a...@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) sharw...@cisco.com To: Spencer Dawkins spen...@wonderhamster.org; Subbaiah Venkata svenk...@google.com; Danny McPherson da...@tcb.net; Carlos Pignataro (cpignata) cpign...@cisco.com Cc: i...@ietf.org; General Area Review Team gen-art@ietf.org; Ross Callon rcal...@juniper.net; Acee Lindem a...@redback.com; Abhay Roy (akr) a...@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:spen...@wonderhamster.org] Sent: Friday, June 12, 2009 3:55 AM To: Subbaiah Venkata; Sanjay Harwani (sharwani); Danny McPherson Cc: i...@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.
