Hi, Robert Thanks a lot for your careful and detailed review. It is very helpful to refine the draft. Please see replies inline. > -----Original Message----- > From: Robert Sparks [mailto:rjsparks@xxxxxxxxxxx] > Sent: Tuesday, April 02, 2013 4:47 AM > To: 6renum@xxxxxxxx; draft-ietf-6renum-gap-analysis@xxxxxxxxxxxxxx > Cc: gen-art@xxxxxxxx; ietf@xxxxxxxx > Subject: Gen-art review: draft-ietf-6renum-gap-analysis-05.txt > > I am the assigned Gen-ART reviewer for this draft. For background on > Gen-ART, please see the FAQ at > > <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>. > > Please resolve these comments along with any other Last Call comments > you may receive. > > Document: draft-ietf-6renum-gap-analysis-05.txt > Reviewer: Robert Sparks > Review Date: April 1, 2013 > IETF LC End Date: April 10,2013 > IESG Telechat date: Not yet scheduled for a telechat > > Summary: This document is not ready for publication as an Informational > RFC. > It may be on the right track, but there issues both in substance > and form that need to be addressed. > > Major issues: > > The document doesn't provide what its title and abstract claim it will > provide. > For instance, the abstract claims a gap analysis is presented following > a renumbering > event procedure summary, but neither appear in the draft. [Bing] In fact the subtitles have the implication of a renumbering event procedure summary. But it is indeed not explicit in the main texts. We'll add some texts to represent it explicitly in the next version. > There are a few places > in the text that say "this is a gap", but usually it's not clear what > "this" means. [Bing] We'll make them more clear in the next version. > The stated intent is to identify missing capabilities (gaps) and the work > needed to provide them. The document should lay these out very clearly. > As the document is currently written, it is difficult to pull out a simple list of > identified gaps. [Bing] A good suggestion. We once had a summary subtitle in previous versions, but we deleted it since we thought it might be a little redundancy. Now we can add it back, it could be helpful for the readers. > While addressing that, it would help more to provide some > sense of the relative importance of addressing each of the gaps identified. [Bing] We used to divide the gaps into "solvable" and "unsolvable". Some important gaps might be unsolvable; while some of the solvable ones might not be so important. We'll consider to reflex the two dimensions in the next version. > There are several significant issues with clarity. I will point to the most > difficult in a section below. > > ---------------------- > Minor issues: > > The document currently references > draft-chown-v6ops-renumber-thinkabout > several times. > That document is long expired (2006). It would be better to simply > restate what is > important from that document here and reference it only once in the > acknowlegements > rather than send the reader off to read it. [Bing] draft-chown-v6ops-renumber-thinkabout is an important input for the gap analysis. Although the draft is expired, most of the content are still valid. draft-chown is a more comprehensive analysis, while the gap draft is focusing on gaps in enterprise renumbering. So it might not easy to abstract several points as important from draft-chown to this draft. We actually encourage people to read it. > RFC4076 seems to say very similar things to this document. Should it > have been referenced? [Bing] RFC4076 is a more specific case of stateless-DHCPv6 [RFC3736], which might not be common usage in enterprise. But sure we can consider reference it. > Section 5.3 punts discussion of static addresses off to RFC 6866. That > document was scoped > only to Enterprise Networks. The scope of this document is larger. Are > there gaps because > of that difference in scope that were missed? Would it make sense to > summarize any gaps > RFC 6866 identified that are relevant to this document here? [Bing] This document scope is also for enterprise (it is the 6renum WG scope). In fact the RFC6866 is a sub-document of this draft. We considered static address problem is an important topic that need a separated document to describe. We can consider add a brief summary there. > Should section 8 belong to some other document? It looks like > operational renumbering > advice/considerations, but doesn't seem to be exploring renumbering > gaps, except for > the very short section 8.2 which says "we need a better mechanism" > without much explanation. [Bing] The multicast and mobility in section 8 were considered as important standalone topics that need to be addressed. Since multicast is complex, we need more texts to describe the problem than describing the gaps directly. But we can make the gaps more clear. > ---------------------- > Text needing clarity (more than nits): [Bing] We'll also deal with the following clarity and nits comments in the next version. Thanks for the careful review. Best regards, Bing > Section 4.1, second paragraph: The first sentence needs to be > simplified. Something like > "Delegation routers may need to renumber themselves with new delegated > prefixes" perhaps. > The second sentence speaks of "the router renumbering issue" as if it's > clear which particular > issue you're actually talking about. Is there a gap here? If so, > consider replacing the entire > paragraph with an explicit description of the gap. > > Section 5.1, first bullet, 2nd paragraph: The third sentence (starting > "In ND protocol,") > makes no sense. The fourth sentence is also hard to parse. > > Section 5.1, first bullet. The list below "the impact of ambiguous M/O > flags" says things like > "there is no standard" and "it is unspecified". I think you are trying > to say that there is > ambiguity in what's written, not that nothing's written. This entire > list would benefit from > being recast in terms of what needs to be done (what are the gaps?). > > Section 5.2, last paragraph. It's not clear what you are trying to say > here. Is it simply > that the natural pressures in an ISP make it more likely that an ISP > would choose to use > DNS names as part of configuration than an enterprise would? If so, can > you list what some > of those pressures are? What gap is this discussion trying to identify? > > Section 6.1, first paragraph, first sentence (starting "For DNS records > update") - this sentence > does not parse. What is it trying to say, and what's the gap you are > trying to point to? > > Section 6.3, 6th paragraph. "So there's a big gap for configuration > aggregation" is > unclear. Is it that configuration isn't stored in one place, or that it > can't be > found through one place, or something different? > > Section 7.1 second bullet. Taking this partial quote from RFC4192 > destroyed the meaning > of the sentence. The original sentence said "The suggestion applies" - > this misquote says > "reducing the delay applies". There's no benefit to quoting 4192 > directly - say what you > mean and reference 4192. > > > ---------------------- > Nits/editorial comments: > > There are a few sentences ending with "etc." in the document. Please > consider deleting the > word from the list - it doesn't help each sentence make its point. > > Introduction: "Future efforts may be achieved in the future." doesn't > add anything > to the document. I suggest deleting the sentence. > > Section 3.2: Consider deleting "basically" from "an IPAM is basically used" > > Section 5.1: draft-ietf-dhc-host-gen-id is no longer new (and it > definitely will not be > new a few years after this is published as an RFC. Please remove "the > new IETF DHC WG > document" from the sentence it appears in. > > Section 5.1: This sentence "Using these flags, the two separated address > configuration > modes are somehow correlated." is not clear. ("somehow" isn't going to > help the reader > in any case). Are you trying to say "This flags provide some degree of > correlation in > the use of these separate configuration protocols"? Could you rewrite > this explicitly > identifying gaps? > > Section 5.1: Please delete "mainly" from "flags mainly includes" > > Section 5.2 (and other places): Is it really the case that router > operators have to > resort to restarting routers in order to pick up configuration changes > these days? > RFC2072 pointed to that, and in 1997 it may have been more routine to > restart, but > for modern systems, that action is more extreme. Surely for something as > basic as > a cache-clear, restarts are vanishingly rare. > > Section 5.3: Instead of "the static address issue" could you say > "discussing the > problems associated with renumbering hosts with static addresses"? > > Section 6, first paragraph: It's not clear what "the entries in the > site" means. > What's a site and what are entries in this case. I suggest "then any > configuration > or data store containing the previous number must be updated." as a > replacement, and > then say "Some examples include:" and list DNS records and ACLs. > Consider pointing > forward to the section on DNS Authority listed under "Gaps considered > unsolvable". > Note that some of those ACLS are going to be on machines under control > by another > authority, having the same problem you point to for DNS. > > Section 6.1: What do you mean by "the major DNS systems". Do you mean > the major > implementations like BIND? > > Section 6.2, first paragraph. This suffers from the ambiguity of the word > "records". You meant it as a verb (DNS writes something down) instead of > a noun (the DNS system contains DNS records). I suggest rewriting this > paragraph to avoid the ambiguity. "While DNS entries contain addresses" - > "Hosts are configured with" - "hosts must update these addreses" > > Section 6.2 second paragraph. Please be more clear what you mean by > "DNS lifetimes". You are not trying to refer to the time-to-live of > a DNS record. Rather, you are trying to say how long a bit of configuration > obtained through DHCP should be considered relevant. If there's a gap > (a need for more protocol), please be explicit. You will proabably want > to engage the DHC working group if you are thinking about asking that > DHCP tell you how long DNS server configuration value is good for if you > are really trying to decouple it from the lease time. (Is that what > you're suggesting? If not, then what's the problem?) > > Section 6.3, second bullet, second sub-bullet: What does "the entries" mean? > Please be specific. Do you mean "configured addresses or prefixes" or > something > else? Or is this intended to extend to updating things like DNS zone files? > As written, it is vague. > > Section 6.3, last sentence. "It is a big gap currently." What specifically > is the big gap. Is it a lack of a standard protocol for updating > configurations > so that there won't be some many vendor-private protocols deployed? > Please consider replacing "It" with something explicit. > > Seciton 7.1: The first bullet does not parse. If I guess its meaning > correctly > (that it would be benificial to tell hosts that local DNS has been > updated and > they may want to make fresh queries), please be careful with the > wording. The > hosts don't know which names are likely to resolve locally. > > Section 7.1, third bullet - This isn't obviously about notification. Why > is it > in this section? What's the gap this is trying to identify? > > Section 7.2 - how is this section helping the document? What are the gaps? > > Section 7.3 - again, how is this section helping the document acheive > its goal? > Would anyone working to close gaps do anything differently if this > section were > deleted? > > Section 9.4 - what is it about these that make them gaps, much less > unsolvable gaps. > Is this discussion in the wrong section of the document? > > Section 10 - The sentence starting "In the LAN" doesn't parse. Did you mean > "may be needed to"? > > Section 10, last paragraph: This sentence doesn't make sense. It would > make more > sense if you replaced "blocking access" with "protecting", but it would > be even > better to expand the discussion and explain what you mean by interruption.