Subject: Gen-art review: draft-ietf-6renum-gap-analysis-05.txt

From: Robert Sparks <[email-masked]>
Date: Mon, 01 Apr 2013 15:46:49 -0500

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. 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 
acknowlegements
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 
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.

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 02 Apr 2013 10:58:13 +0100

Just picking a couple of points for further comment:

On 02/04/2013 08:46, Liubing (Leo) wrote:
> Hi, Robert
...

>> -----Original Message-----
>> From: Robert Sparks [mailto:[email-masked]]

...
> [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.

Robert is right, though, sending people to a long-expired draft is a bad idea.
Of course we have to acknowledge it, but maybe we should pull some of its text
into an Appendix.

Tim Chown, any opinion?

> [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. 

Yes, and check if it identifies any gaps that we should mention.

Bing: we should also add a reference to RFC 4085 "Embedding Globally-Routable
Internet Addresses Considered Harmful" which I missed for RFC 6866.

>> only to Enterprise Networks. The scope of this document is larger. 

As Bing said, the *intended* scope is enterprise networks. We should
add that in the Abstract and Introduction. Indeed, many of the points
are more general.

Thanks again Robert!

   Brian

---

From: "Liubing (Leo)" <[email-masked]>
Date: Tue, 2 Apr 2013 07:46:33 +0000

Hi, Robert

Thanks a lot for your careful and detailed review. It is very helpful to refine the draft.
Please see replies inline. 

> Sent: Tuesday, April 02, 2013 4:47 AM
> To: [email-masked]; [email-masked]
> Cc: [email-masked]; [email-masked]
> Subject: Gen-art review: draft-ietf-6renum-gap-analysis-05.txt
> 
> 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

[Bing] We'll make them more clear in the next version. 
 
> 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

[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.

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

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

[Bing] We'll also deal with the following clarity and nits comments in the next version. Thanks for the careful review.

Best regards,
Bing

---

From: "Liubing (Leo)" <[email-masked]>
Date: Tue, 2 Apr 2013 12:36:05 +0000

Hi, Brian

> > [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.
> 

[Bing] Ok, then we can hear some opinions from Tim.

> > [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.
> 

[Bing] Got it. I'll add it in the next version.

> add that in the Abstract and Introduction. Indeed, many of the points

[Bing] OK. Thanks.

---

From: Stig Venaas <[email-masked]>
Date: Tue, 02 Apr 2013 10:23:24 -0700

> Of course we have to acknowledge it, but maybe we should pull some of its text

I still think that old draft is fairly good, and a shame to let it all
just die. But there is no chance of getting that out as an RFC I guess?

Stig

---

From: Robert Sparks <[email-masked]>
Date: Tue, 30 Apr 2013 10:33:32 -0500

> Of course we have to acknowledge it, but maybe we should pull some of its text
The most recent version (and the one slated for the next telechat) still 
has this long-expired draft referenced.

RjS

---

From: joel jaeggli <[email-masked]>
Date: Tue, 30 Apr 2013 08:43:13 -0700

On 4/30/13 8:33 AM, Robert Sparks wrote:
>>> [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.
>>> 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.
I'm not sure I see that as worse than referring to Wikipedia, an expired 
draft has the property that it's not going to change. I have no problem 
with the idea that it would be an informative reference.   but yes it's 
a bit much to say go read this.
> The most recent version (and the one slated for the next telechat) 
> still has this long-expired draft referenced.
>
> RjS
>

---

From: Robert Sparks <[email-masked]>
Date: Tue, 30 Apr 2013 11:32:49 -0500

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 wait for direction from your document shepherd
or AD before posting a new version of the draft.

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: May 16, 2013

Summary: Ready with nits (that border on minor issues)

This update improved the readability significantly, and addressed my 
major concern about being able to build a list of the gaps. Thank you.

There are a few issues from my last call review that are still not 
addressed.
I have left the classification of minor issue vs nits the same as the 
original review to make referring to the earlier review easier,
but please consider all of these Nits. The IESG will need to decide 
whether to escalate them.

I've trimmed away the points that were addressed.

On 4/1/13 3:46 PM, Robert Sparks wrote:
> ----------------------
> Minor issues:
>
> The document currently references 
> draft-chown-v6ops-renumber-thinkabout several times.
This version still references that long expired draft. There was also 
conversation on apps-discuss
about making that reference normative. IMHO, this is not the right way 
to treat the RFC series, and
strongly encourage moving the text that you want to reference into 
something that will
become an RFC.
> without much explanation.
Afaict, this wasn't addressed at all. In particular, "we need a better 
mechanism" is still all that
section 8.2 says.

> being recast in terms of what needs to be done (what are the gaps?).
This text remains unmodified.
There were some changes, but mostly these still exist. I'll leave 
pressing this point further to the RFC Editor.
> hosts don't know which names are likely to resolve locally.
This text remained unchanged, and when coming back to the document for a 
re-review
(which is somewhat like coming back to an RFC you've read before just 
for reference),
it's even harder to understand what it's trying to say than it was when 
reading the document
linearly.

I think you are trying to say
"A notification mechanism may be needed to indicate _to_ hosts that a 
renumbering event has _changed how local recursive DNS servers will 
respond_. That mechanism may also need to indicate that such a change 
will happen at a specific time in the future."

>
> Section 7.1, third bullet - This isn't obviously about notification. 
> Why is it
This text was unchanged.
> Is this discussion in the wrong section of the document?
This is now section 10.3 and is mostly unchanged. It's still not clear 
why this discussion is in the "unsolvable gaps" section.