Subject: Re: WG Last Call: a batch of draft-ietf-v6ops-ipv4survey-*01 documents

From: Brian E Carpenter <[email-masked]>
Date: Mon, 11 Aug 2003 16:19:21 +0200

Hi,

This is important work and IMHO it's almost ready to ship.

1. draft-ietf-v6ops-ipv4survey-intro-01.txt

Section 1.1 is too editorial, and section 1.2 is irrelevant.
I would simply delete them. If a historical reference is wanted,
use RFC 1752.

The second and third paragraphs of Section 1.3 are also irrelevant,
and should be removed, and tossed over the fence to the Problem WG.
[I happen to agree with these paragraphs, but they don't belong here.]

The rest of this draft is excellent.

2. draft-ietf-v6ops-ipv4survey-subip-01.txt     

No comments

3. draft-ietf-v6ops-ipv4survey-ops-01.txt       

No substantive comments.

s/depreciated/deprecated/ (at least twice)
   
     Brian

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Brian E Carpenter 
Distinguished Engineer, Internet Standards & Technology, IBM 

NEW ADDRESS <[email-masked]> PLEASE UPDATE ADDRESS BOOK

Pekka Savola wrote:
> 
> Hi all,
> 
> This is a WG Last Call for comments on sending the following first three
> "Survey of IPv4 Addresses in Currently Deployed IETF Standards" documents
> to the IESG for consideration as Informational RFCs:
> 
> Introduction to the Survey of IPv4 Addresses in Currently
> Deployed IETF Standards
>   http://www.ietf.org/internet-drafts/draft-ietf-v6ops-ipv4survey-intro-01.txt
> 
> Survey of IPv4 Addresses in Currently Deployed IETF Sub-IP Area Standards
>   http://www.ietf.org/internet-drafts/draft-ietf-v6ops-ipv4survey-subip-01.txt
> 
> Survey of IPv4 Addresses in Currently Deployed IETF Operations &
> Management Area Standards
>   http://www.ietf.org/internet-drafts/draft-ietf-v6ops-ipv4survey-ops-01.txt
> 
> Please review these documents carefully, and send your feedback to the
> list (editorial modifications may also be sent to the editor, Andreas).
> Please also indicate whether or not you believe that this document is
> ready to go to the IESG.  Silence does NOT indicate consent.  Unless
> sufficient support is demonstrated on the list, the documents will not be
> send to the IESG.
> 
> Please note that the first document ("introduction") includes the summary
> of all the results, which are subject to change; please ignore the details
> of section 3 when reviewing it.
> 
> The last call will end in 3 weeks, on 12th August.
> 
> Pekka, Margaret & Bob

---

From: Pekka Savola <[email-masked]>
Date: Wed, 13 Aug 2003 10:13:58 +0300 (EEST)

Hello all,

Thanks to those who have sent feedback (both on and off-list).

However, a couple of people reading through them is not enough.

PLEASE review the documents ASAP and provide feedback.  We NEED stronger 
support and acknowledgement from the WG that these have actually been 
read!

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: "Alan E. Beard" <[email-masked]>
Date: Wed, 13 Aug 2003 13:39:20 -0400 (EDT)

Folks:

Hereinafter a few comments on

per Pekka's request below. I'll review the other documents queued for last
call within a few days.

AEB

> support and acknowledgement from the WG that these have actually been

The comments below pertain to section 1.1 of  -ipv4survey-intro-01.
Further comments on this document, mostly concerning section 4, will
follow.

Most of the comments are changes in text for enhanced readability and for
clarification of ambiguous terms.  Changes which do not effect substantial
modification in the meaning of the original (as interpreted by this
reader) are interpolated into the body of the text, with original wording
shown in brackets immediately following the replacement text.

In a few cases suggesting for alternative wording are given which may
alter the substantive meaning of the original: these changes are given in
brackets immediately following the paragraph in which the original text
appears, along with some explanation of the reasoning which prompted the
suggested changes.

I will be interested to learn the reactions of the WG participants to the
changes suggested below.  Comments are welcome; also flames, within
reason. ;-)

Herewith the suggestions:

1.1 Short Historical Perspective

There are many challenges that face the Internet Engineering community.
The foremost of these challenges has been the scaling issue: how to grow a
network that was envisioned to handle thousands of hosts to one that will
handle tens of millions of networks with billions of hosts.  Over the
years this scaling problem has been overcome with changes to the network
layer and to routing protocols.  (Although largely ignored in the changes
to network layer and routing protocols, the tremendous advances in
computational hardware during the past two decades have been of
significant benefit in managment of scaling problems encountered thus
far.)

[Alternative text for sentence 2 of the paragraph above:

Over the years this scaling issue has been managed, with varying degrees
of success, by changes made to the network layer and to routing protocols.

Reasoning: In light of our current discussions, it seems to me that the
scaling issue (in actuality, a group of entangled issues) is still with
us; we have so far avoided the worst of the postulated adverse effects by
changes to routing protocols, network layer conventions, operational
techniques described in later paragraphs of the extant draft.  Given the
nature and extent of current activities which purport to address "the
scaling issue", I don't think we have "overcome" the problem; it seems to
me that scaling issues will be a fact of life in the IP world for the
foreseeable future, although we now have a limited set of tools and
techniques for dealing with some of the more pernicious effects, and it is
within our capability to develop more such tools.]

The first "modern" transition to the network layer occurred in during the
early 1980's from the Network Control Protocol (NCP) to IPv4.  This
culminated in the famous "flag day" of January 1, 1983.  IP Version 4
originally specified an 8 bit network and 24 bit host addresses, as
documented in RFC 760.  A year later IPv4 was updated in RFC 791 to
include the famous A, B, C, D, & E class system.

[note: much of the above paragraph has been re-written, but, I think,
without any substantive change in meaning. AEB]

Networks were growing in such a way that it was clear that a convention
for [original text: ...a need for...] breaking networks into smaller
pieces was needed.  In October of 1984 RFC 917 was published formalizing
the practice of subnetting.

By the late 1980's it was clear that the current exterior routing protocol
used by the Internet (EGP) was insufficiently robust to [original: was not
sufficient to] scale with the growth of the Internet.  The first version
of BGP was documented in 1989 in RFC 1105.

Yet another scaling issue, exhaustion of the Class B address space, became
apparent in the early 1990s. [original text: The next scaling issues to
became apparent in the early 1990's was the exhaustion of the Class B
address space.] The growth and commercialization of the Internet
stimulated organizations to request IP [original text: ...Internet had
organizations requesting IP...] addresses in alarming numbers. By May
[original text: In May...] of 1992 over 45% of the Class B space was
allocated.  In early 1993 RFC 1466 was published directing assignment of
blocks of Class Cs to be given out in lieu of Class B allocations.
[original text: ...Class C's be given out instead of Class B's.] This
solved the problem of address space exhaustion but had significant impact
of the routing infrastructure.

[In the last sentence above, perhaps the word "solved" might be replaced
by any of these words or phrases: "palliated" or "temporarily
circumvented" or "alleviated" or "delayed the most pernicious effects of".
The problem of exhaustion of IPv4 address space is still with us, and is
likely to be extant until a substantial proportion of existing IPv4
networks migrate to IPv6 and surrender their v4 allocations. This appears
as a suggestion because the wording change also effects a significant
alteration in the meaning of the original text: this extends well beyond
a mere clarification.]

The number of entries in the "core" routing tables began to grow
exponentially as a result of RFC 1466.  This led to the implementation
of BGP4 and CIDR prefix addressing.  This may have solved the problem
for the present but there are still potential scaling issues.

[Again, regarding the last sentence above, perhaps a more accurate reading
of the current state of the technology would substitute for the word
"solved" any of the following: "alleviated" or "circumvented".  This
appears as a suggestion because the wording change also effects a
significant change in meaning.]

Growth in the population of Internet hosts since the mid-1980s would
have long overwhelmed the IPv4 address space if industry had not supplied
a solution in the form of Network Address Translators (NATs).[original
text: Current Internet growth would have long overwhelmed the current
address space if industry didn't supply a solution in Network Address
Translators (NATs).] To do this the Internet has sacrificed the underlying
"End-to-End" principle.

[Regarding the first sentence in the paragraph immediately above: some of
the IPv6 WG members consider NAT not a solution at all; rather, they
proclaim NAT an unmitigatedly BAD THING (emphasis in the original) and,
even in the most generous and flattering of all possible interpretations,
not better than a crude kludge. Perhaps the word "solution" might be
replaced with "circumvention" for a reading more consistent with the
common wisdom concerning NAT.  Additionally, should we make some mention
of PNN address spaces (RFC 1918), without which NAT would probably not
have become as widely implemented as it is today?  Based on what we see
in enterprise implementations, either NAT or PNN alone would probably
have been insufficient to relieve, even temporarily, the demand for v4
address space arising from the rapid growth of IP host counts in business
and academic environments.]

In the early 1990's the IETF was aware of these potential problems and
began a long design process to create a successor to IPv4 that would
address these issues.  The outcome of that process was IPv6.

The purpose of this document is not to discuss the merits or problems of
IPv6.  That is a debate that is still ongoing and will eventually be
decided on how well the IETF defines transition mechanisms and how
industry accepts the solution.  The question is not "should," but
"when."

************

Now, what think ye all?

Regards,

AEB
-- 
Alan E. Beard <[email-masked]>
AEBeard Consulting; 4109 Chelsa Ln; Lakeland FL 33809
863.815.2529

---

From: Pekka Savola <[email-masked]>
Date: Fri, 15 Aug 2003 16:57:47 +0300 (EEST)

> per Pekka's request below. I'll review the other documents queued for last

Thanks.

> within our capability to develop more such tools.]

Agreed.
 
> without any substantive change in meaning. AEB]

Agreed.
 
> of the routing infrastructure.

Agreed.
 
> alteration in the meaning of the original text: this extends well beyond

I think "temporarily circumvented" would be both simple enough and to the 
point.
 
> significant change in meaning.]

Agree.  Solved is fine here, but a stronger wording is also fine, and 
perhaps better, e.g. alleviated.  It's clear that there is a scaling issue 
here.
 
> Translators (NATs).] To do this the Internet has sacrificed the underlying

Ok.
 
> and academic environments.]

I agree that mentioning private address space in conjunction with NAT 
would seem like the right thing to do.  "Solve" might not be optimal here 
either, but either way is fine with me.
 
> industry accepts the solution.  The question is not "should," but

Ok.

Very good suggestions, thanks :-)

---

From: Pekka Savola <[email-masked]>
Date: Sat, 16 Aug 2003 08:48:18 +0300 (EEST)

Hi,

I'd like to poll the WG on one bigger potential change to the Introduction 
document.

Personally I've started to think that section 3.1-3.4, i.e. the details of 
the results which have been copied all the other survey documents, should 
be removed from the document.

The reason for this would be that keeping these in sync is rather 
difficult, and people really should look at the area-specific documents if 
they want the details.

But I don't have firm opinions either way.

Thoughts on how to proceed with this?

---

From: "Alan E. Beard" <[email-masked]>
Date: Sun, 17 Aug 2003 13:43:16 -0400 (EDT)

Pekka:

I have reviewed the drafts enumerated below, and I find nothing
objectionable in either of them.  Additionally, I checked some of the
documents explictly referenced (both those listed as clean and those shown
with v4 dependencies): in each case, my findings agreed with those in the
drafts under review. I did not do a complete canvas, but the results of my
spot checks lead me to believe that the authors have probably done a
complete and substantially accurate survey. In short, these documents look
good to me; I think we can send these two to the IESG without risking
embarrasment. ;-)

> > to the IESG for consideration as Informational RFCs:
[...]
> > sufficient support is demonstrated on the list, the documents will not be

The Intro document, also part of the last call announcement, I reviewed
earlier, and some comments have been submitted. Additional comments on
section 4 of the Intro document will be forthcoming shortly.

Regards,

AEB

---

From: "Alan E. Beard" <[email-masked]>
Date: Sun, 17 Aug 2003 13:59:36 -0400 (EDT)

Pekka:

Responses inline.

AEB

> be removed from the document.
IMHO the information in section 3 is valuable to the reader, but the
information would be equally valuable if incorporated by reference to the
source documents rather than by being copied in.   This might present
logistical problems, but if we defer publication of the intro document
until the specific survey documents have been published...

> difficult, and people really should look at the area-specific documents if
Agreed.  This is sound logic.  And better we hear it straight from the
horse's mouth.

> Thoughts on how to proceed with this?
See above.  It seems not unreasonable that an intro document is published
after the survey documents enumerated therein; the contrary order would
result in a document of prophecy, rather than an introduction. ;-)

That's my $.02 worth.

AEB