Skip to main content

Last Call Review of draft-ietf-6renum-gap-analysis-05

Request Review of draft-ietf-6renum-gap-analysis
Requested revision No specific revision (document currently at 08)
Type Last Call Review
Team General Area Review Team (Gen-ART) (genart)
Deadline 2013-04-10
Requested 2013-03-28
Authors Bing Liu , Brian E. Carpenter , Sheng Jiang , Stig Venaas , Wesley George
I-D last updated 2013-04-01
Completed reviews Genart Last Call review of -05 by Robert Sparks (diff)
Genart Telechat review of -07 by Robert Sparks (diff)
Assignment Reviewer Robert Sparks
State Completed
Request Last Call review on draft-ietf-6renum-gap-analysis by General Area Review Team (Gen-ART) Assigned
Reviewed revision 05 (document currently at 08)
Result Not ready
Completed 2013-04-01
I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at


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 


For instance, the abstract claims a gap analysis is presented following 

a renumbering

event procedure summary, but neither appear in the draft. There are a 

few places

in the text that say "this is a gap", but usually it's not clear what 

"this" means.

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. While addressing that, it would help more to provide some
sense of the relative importance of addressing each of the gaps identified.

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 


rather than send the reader off to read it.

RFC4076 seems to say very similar things to this document. Should it 

have been referenced?

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?

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.

Text needing clarity (more than nits):

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 


document" from the sentence it appears in.

Section 5.1: This sentence "Using these flags, the two separated address 


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 


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 


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 


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 


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 


(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


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.