Subject: Re: WG Last Call: three draft-ietf-v6ops-ipv4survey-*01 documents (fwd)

From: "Tom Petch" <[email-masked]>
Date: Mon, 8 Sep 2003 18:30:20 +0100

> How can we work for improve the document?

Um, redraft it in a different format?

What is the document trying to achieve for whom?

I appreciate that a lot of work has produced a long list of places
where IPv4 addresses are used but so what?  The list is a mixture of
current standards, RFC that may have been useful once but are now all
but dead, RFC that have been superseded etc all mixed up together and
then divided into eight.  When there was one document, I could at
least search it, now I cannot even do that.

To be useable, I think that related information should be brought
together, so
that there is a single discussion of eg BGPv4 or SNMPv1 including
information from all the relevant RFC.  And there should be an
index, a separate document,  in  RFC order listing those documents
that have been worked on,
stating
whether or not there is a IPv4 dependency apparent in each and giving
cross-references to which part of which of the eight or more IDs  in
which I can then find the discussion thereof.

This is a complex area eg when a MIB RFC imports Textual
Conventions which give address formats from another, or where BGP is
extended to encompass other 'address' formats
As it stands, the output does not do justice to the work put in and I
do not feel inclined to refine it with detailed comments on particular
RFC (or
ID).

I do not think it/they are ready to be forwarded.

Tom Petch
**********************************
Madrid 2003 Global IPv6 Summit
Presentations and videos on line at:
http://www.ipv6-es.com

This electronic message contains information which may be privileged
or confidential. The information is intended to be for the use of the
individual(s) named above. If you are not the intended recipient be
aware that any disclosure, copying, distribution or use of the
contents of this information, including attached files, is prohibited.

_______________________________________________
routing-discussion mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/routing-discussion

_______________________________________________
routing-discussion mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/routing-discussion

---

From: Pekka Savola <[email-masked]>
Date: Mon, 8 Sep 2003 21:04:14 +0300 (EEST)

> Um, redraft it in a different format?

Not reasonable.
 
> What is the document trying to achieve for whom?

My personal view on what the documents are trying to achieve:

1. Document and archive the information about the RFCs (excluding Info and
BCP) which seem to have IPv4 dependencies.

2. Give pointers whether those dependencies have already been dealt with, 
are being taken up, or what.

The target audience are those writing the RFCs.
 
> where IPv4 addresses are used but so what?  

For archival purposes, and to figure out whether there are any RFCs which 
should have been updated but have fallen through the cracks.

> The list is a mixture of

Note: we're currently removing Historic documents, and replacing Obsoleted 
ones with newer ones, because that seemed like a reasonably small task, 
which would increase the relevance of the work a lot (i.e., a good 
cost/benefit ratio).

That being said, there has been a strong pushback to one giant
specification.  Nobody would read it, as very few people are interested in
all kinds of RFCs.  For searching, grepping through all the seven drafts
shouldn't be too much of a task.

> together, so that there is a single discussion of eg BGPv4 or SNMPv1
> including information from all the relevant RFC.  

The problem is that defining these superclasses is a non-trivial task;
even splitting the RFCs to areas was not easy.

> And there should be an
> index, a separate document, in RFC order listing those documents that
> have been worked on, stating whether or not there is a IPv4 dependency
> apparent in each and giving cross-references to which part of which of
> the eight or more IDs in which I can then find the discussion thereof.

In the previous version of the introduction document we brought together
all the RFCs which still had issues.  This didn't seem like a useful
approach, and very difficult to keep in sync; people are referred to the
area-specific documents instead.
 
> As it stands, the output does not do justice to the work put in 

The general outline is the same as work put in it.  Do I see volunteers
wishing to edit all the seven documents to a completely new format?  This
would be a huge undertaking.  Nope..

> and I

Thanks anyway for your comments.

-- 
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: Curtis Villamizar <[email-masked]>
Date: Mon, 08 Sep 2003 17:02:55 -0400

In message <[email-masked]>, Pekka Savola w
> > Um, redraft it in a different format?

Then don't bother producing the draft.

Curtis

---

From: Curtis Villamizar <[email-masked]>
Date: Mon, 08 Sep 2003 17:02:55 -0400

Curtis

---

From: Pekka Savola <[email-masked]>
Date: Mon, 8 Sep 2003 21:04:14 +0300 (EEST)

Not reasonable.

---

From: "John G. Scudder" <[email-masked]>
Date: Tue, 9 Sep 2003 09:50:43 +0200

>The target audience are those writing the RFCs.

...and the feedback you've received so far (that I've seen) indicates 
that the document in its present form does not effectively 
communicate to that audience.  Sorry.

I'd also like to associate myself with the substance of Curtis' and 
Tom's comments.

Regards,

--John

---

From: "John G. Scudder" <[email-masked]>
Date: Tue, 9 Sep 2003 09:50:43 +0200

Regards,

--John

---

From: Pekka Savola <[email-masked]>
Date: Tue, 9 Sep 2003 10:55:54 +0300 (EEST)

> communicate to that audience.  Sorry.

Strange that the only strong pushback for a model like this we've received 
has been from the routing area?  No other areas have had strong complaints 
about this approach.

---

From: Pekka Savola <[email-masked]>
Date: Tue, 9 Sep 2003 10:55:54 +0300 (EEST)

---

From: Curtis Villamizar <[email-masked]>
Date: Tue, 09 Sep 2003 12:25:39 -0400

In message <[email-masked]>, Pekka Savola 
> has been from the routing area?  No other areas have had strong complaints 

Maybe its because you managed to get it so wrong in the initial
sections of the document for the routing area.

I do have another suggestion that may represent an compromise
acceptable to both sides.

Instead of removing the front sections you could keep them but correct
the inaccuracies in your statements there and in the summary section
caused by looking at a document in isolation that in practice is never
implemented in isolation and at this point is not intended to be
implemented in isolation.  You could also put forward references to
your later mention of the documents some of which provide full support
for IPv6 and are implemented and working.  For example, BGP4 would say
that the base BGP-4 document does not support IPv6, but RFC-2858
(MP-BGP) provides multiprotocol support and RFC-2545 provides explicit
support for IPv6 using BGP-4.  You would then also put references to
the section of your document describing RFC-2858 and RFC-2545 and
their relevance to IPv6.

This would allow you to keep your document organization to remain
consistent with other areas but remove the problem that document
organization causes at least for the routing area.

If you continue to insist on making statement in the front of the
document and in the section entitled "Summary" which are completely
wrong, you'll continue to hear objections.

Curtis

---

From: Curtis Villamizar <[email-masked]>
Date: Tue, 09 Sep 2003 12:25:39 -0400

Curtis

---

From: Pekka Savola <[email-masked]>
Date: Tue, 9 Sep 2003 19:45:24 +0300 (EEST)

note: I think the mibs mailing list is out of scope for this discussion, 
so please strip it out for the next messages (keeping it here just for 
informative purposes).

> sections of the document for the routing area.

Agreed.  The "A new EGP must be defined" is particularly amusing.. so far
it's no longer even funny :-).

Now, we've received a suggestion to reword the documents like:

Old:

4.1  RFC 1771 A Border Gateway Protocol 4 (BGP-4)

   This RFC defines a protocol used for exchange of IPv4 routing
   information and does not support IPv6.  A new EGP must be defined for
   the exchange of IPv6 routing information.

New:

4.1  RFC 1771 A Border Gateway Protocol 4 (BGP-4)

   This RFC defines a protocol used for exchange of IPv4 routing
   information and does not support IPv6.

[I think one should also add a more detailed description of which
particular details of the protocol are not IPv6-capable or non-extendable,
without further recommendations in this particular section]

.. and in section 7.x.y, look at how the problem has been fixed by MP-BGP
(and friends), but still a few more or less irrelevant things remain, such
as AGGREGATOR field which is 4 octets, and the work-in-progress on the
router-id.

This seems like a reasonable suggestion to me.

I guess that the description and advice was put in sections 3-6 to give 
more information right out to the reader.. too bad that the information 
was just plain wrong.. :-)
 
> the inaccuracies in your statements there 

yep

> and in the summary section
> implemented in isolation.  

Note that the summary sections are *not* meant to be described in
isolation.  If it seems like that, that's a bug which needs to be fixed
ASAP.  For example, the *summary* BGP section should list all the stuff
you describe below, including forward references:

> You could also put forward references to

I think this is mostly in line with the proposition above.

It seems we're converging, which is good.

Perhaps it will be best to ask the document editor to try to make these
adjustments himself, and get back to us with a newer version (which likely
still includes a large number of errors), which can be tuned to enhance
the wording so that it's correct and useful?  Unless folks want to spend
time with the current document?

Note: I think it should be pretty safe to work at least on the summary
(7.x.y) sections at the moment, as those are unlikely to get much better
by our document editor's treatment on sections 3-6.

Does this sound good?

---

From: Pekka Savola <[email-masked]>
Date: Tue, 9 Sep 2003 19:45:24 +0300 (EEST)

Old:

New:

 

yep

Does this sound good?

---

From: Jeffrey Haas <[email-masked]>
Date: Tue, 9 Sep 2003 12:56:08 -0400

Pekka,

> without further recommendations in this particular section]

Might I suggest something along the following?

: 4.1  RFC 1771 A Border Gateway Protocol 4 (BGP-4)
: 
:    This RFC defines the base BGP-4 protocol used for exchange of IPv4 routing
:    information and does not support IPv6.
:    
:    RFC 2858 extends BGP to support multi-protocol extensions that allows
:    routing informatino for other address families to be exchanged.
:    
:    RFC 2545 further extends RFC 2858 for full support of exchanging
:    IPv6 routing information and additionally clarifies support of the
:    extended BGP-4 protocol using TCP+IPv6 as a transport mechanism.
:    
:    Note that all three RFC's must be supported in order to provide
:    full IPv6 support.

Since the document is organized by RFC number, further note the
spots for RFC 2545 and 2858 to see section 4.1.

> time with the current document?

This is a general issue with IETF documents.  Even for RFC's, it is
not clear from looking at our so-called canonical index (1rfcindex.txt)
what documents are related - only what documents replace other
documents.

This issue is far worse with ID's.

-- 
Jeff Haas 
NextHop Technologies

---

From: Jeffrey Haas <[email-masked]>
Date: Tue, 9 Sep 2003 12:56:08 -0400

Pekka,

-- 
Jeff Haas 
NextHop Technologies

---

From: Pekka Savola <[email-masked]>
Date: Tue, 9 Sep 2003 20:04:41 +0300 (EEST)

Hi,

> spots for RFC 2545 and 2858 to see section 4.1.

I'd prefer to put the last three paragraphs to the analysis section only
("the logical separation between analysing RFC 1771, and analyzing the
consequences of no support in RFC 1771"), and keep 4.1 bare-bones.

In addition, the second paragraph would be useful under 5.x under RFC 2858
and, the third paragraph under 5.x under RFC 2545.

This should avoid forward-references and incorrect advice in sections 3-6,
but put the full and accurate analysis in section 7.

Would you agree to such a document organization?   (I belive this was what 
Curtis proposed in his last message.)

---

From: Pekka Savola <[email-masked]>
Date: Tue, 9 Sep 2003 20:04:41 +0300 (EEST)

Hi,

---

From: Curtis Villamizar <[email-masked]>
Date: Tue, 09 Sep 2003 14:02:42 -0400

In message <[email-masked]>, Pekka Savola 
>    information and does not support IPv6.

Then add to that:

   RFC-2858 adds multiprotocol support to BGP-4.  RFC-2545 adds
   explicit support for IPv6 building upon RFC-2858.

Also add forward references.

Optionally add:

   draft-ietf-idr-bgp-identifier-02.txt documents a current practice
   that can be used to support IPv6 only routers.

> as AGGREGATOR field which is 4 octets, and the work-in-progress on the

The router-id thing (draft-ietf-idr-bgp-identifier-02.txt) is nothing
more than a BCP.  It is documenting a technique that can be used today
with no change in software.

The AGGREGATOR is entirely optional, is informational only, and is
virtually unused in practice in IPv4 so won't be missed by IPv6.  Even
if you wanted to use it, the 4 bytes is the BGP Identifier.  If BGP
Identifier need not be an IPv4 address, then there is no problem with
AGGREGATOR.

The only purpose that AGGREGATOR ever could serve is calling the NOC
responsible for a problem aggregation, obtained by knowing the AS
number, and then telling them which router was causing the problem if
that was any further help.  The BGP Identifier would still serve that
purpose, if it were ever used.

> > the inaccuracies in your statements there 

We're making progress.

> you describe below, including forward references:

Good.  I think this makes more sense.

> It seems we're converging, which is good.

Yes.  I agree that we are converging.  Thanks for proposing new text.

> time with the current document?

The document editor is supposed to be reading this and if we follow
the normal IETF processes must eventually respond to comments and
reflect WG (or area) consensus if they want the document advanced.

> by our document editor's treatment on sections 3-6.

I think we're chipping away at inaccuracies.

A few more comments.

CIDR is a change to the way addresses are handled in IPv4, removing
the notion of class-{A,B,C} networks and fixed boundaries on the
network and host part of the address.  IPv6 was designed without such
boundaries therefore documenting change from prior practice is not
nessecary.  The document still has some relevance because it documents
address allocation problems such as multihoming that have yet to be
satisfactorily addressed in IPv6.

Once again, rfc-1745 is historic.

The primary author/editor has not agreed to remove historic and
obsoleted documents.  The author/editor has not agreed to either
eliminate experimental RFCs or note that they are just that
(experimental) and can be addressed when and if they transition from
experimental to proposed standard, or ignored if they transition to
historic instead.

Curtis

---

From: Curtis Villamizar <[email-masked]>
Date: Tue, 09 Sep 2003 14:02:42 -0400

Then add to that:

Optionally add:

We're making progress.

A few more comments.

Curtis

---

From: Pekka Savola <[email-masked]>
Date: Tue, 9 Sep 2003 22:25:58 +0300 (EEST)

note: tailed down the cc: list a bit.

>    that can be used to support IPv6 only routers.

I think you stated in the earlier message (or so I read it anyway) that 
you would not require forward references in sections 3-6, as long as 
they'd be reasonably present in section 7.

> purpose, if it were ever used.

Yep.
 
> reflect WG (or area) consensus if they want the document advanced.

The document is a v6ops WG draft.  Reflecting routing area rough consensus 
is desirable, though. :-)

Note that one appropriate response to comments is producing an updated 
draft.
 
> > by our document editor's treatment on sections 3-6.

[ snipped some details ]

> experimental to proposed standard, or ignored if they transition to

It may not have been clear, but as I'm v6ops co-chair, and the document
being a v6ops WG document, I'm reprenting the document editor to a degree,
as far as trying to figure out how we should evolve the document.

I don't think there has been consensus to remove Experimental documents at
this stage, but the historical/obsoleted documents should be a done deal.

Thanks

---

From: Pekka Savola <[email-masked]>
Date: Tue, 9 Sep 2003 22:25:58 +0300 (EEST)

Yep.

 

[ snipped some details ]

Thanks