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

[Curtis Villamizar <[e-mail]>]

In message <[e-mail]>, Pekka Savola 
writes:
> 
> Again, are you volunteering to write better documents?  To edit the 
> current one?  To submit actual text updates which are in line with the 
> organization of the documents?

The organization of the document is flawed.  It has to be fixed.

> The document certainly needs quite a bit of work from the subject matter
> experts (routing folks).  Unfortunately, constructive feedback has been 
> slow in coming (but non-null, luckily -- thanks!).

OK lets start over with the comments.

> Please look at section 2, "Document Organization", in particular:
> 
>    Sections 3, 4, 5, and 6 each describe the raw analysis of Full,
>    Draft, and Proposed Standards, and Experimental RFCs.  Each RFC is
>    discussed in its turn starting with RFC 1 and ending with RFC 3247.
>    The comments for each RFC are "raw" in nature.  That is, each RFC is
>    discussed in a vacuum and problems or issues discussed do not "look 
>    ahead" to see if the problems have already been fixed.
> 
> .. this approach precludes "looking ahead".  On the other hand, "looking 
> ahead" is done in section 7, which states:

If you are going to make a reasonable document out of this, you going
to have to fix this first.

> > If the authors knew what was going on in the IETF and knew the
> > documents they'd know that consideration for IPv6 is in BGP-4 by way
> > of the extensions and would write that in the draft.
> 
> Agreed, but certainly the original author didn't, and chose a document
> organization which is not exactly intuitive.

Its more than not intuitive.  It doesn't make any sense in the context
of the way IETF produces documents.  Base specs are rarely updated to
fold in all extensions.  If they are it is generally only when the
base document is determined to be of no longer of any use without a
particular extension.  Instead the extensions are defined in separate
documents.  As a practical matter the base BGP4 document is very
mature and is not going to be updated to include IPv6 extensions any
time soon.  Neither is OSPFv2.

The other major routing protocol is ISIS.  The base spec is a now
obsolete OSI spec, with multiprotocol extensions for IPv4 in RFC-1195.
Neither of these base specs are likely to be updated for IPv6.  The
ISIS WG seems to work in a one feature per document mode.  The
existance of draft-ietf-isis-iso-interoperable-00.txt and
draft-ietf-isis-ip-interoperable-00.txt should tell you that RFC-1195
is substantially wrong but rather than fix RFC-1195, the ISIS WG is
writing a separate document to advise implementors of what is wrong
with RFC-1195.  While not relevant to IPv6, this does indicate how
unlikely it is that a rewrite of RFC-1195 will be undertaken to handle
IPv6 in the base document.  The IETF does not have the authority to
modify ISO 10589.

> > If the authors knew what they were doing they wouldn't reference
> > historic documents, particularly ones that have an "obsoleted by"
> > entry in the RFC index.
> 
> I agree the approach is not the best one, but it was the one given to us 
> by the person who did the initial work.  We're just trying to patch it up 
> to be ready for dissemination and use.

We can start with deleting any document classified as Historic since
Historic specifically means "don't use this".  We can also change any
entry for an obsoleted document to reflect the newer document plus any
"updated by" entries.

For example, RFC-1745 is not used.  It seemed like a good idea but it
never really was used in any deployment, was later declared to be
harmfull and was reclassified as historic.

> > The authors appear not to understand the IETF document process since
> > when looking at the set of full standards they ignored all of the
> > proposed standards which update them.  The full standards just reflect
> > our long experience with these base protocols and confidence in them
> > (or at least confidence that we understand their strengths and
> > limitations), as opposed to our more limited experience with more
> > recent extensions to them, such as extensions for IPv6 which are all
> > proposed standards for that reason.
> 
> Agreed.

Do you then agree that we need to reorganize the document?

As is you've got completely wrong statements in it that you are
attributing to the organization of the document.  As a result, the
summary in section 7 is completely misleading, with its statements:

  7. Summary of Results 

   In the initial survey of RFCs 25 positives were identified out of a 
   total of 53, broken down as follows: 

   Standards                 2 of  7 or 28.57% 

   Draft Standards           1 of  2 or 50.00% 

   Proposed Standards       17 of 33 or 51.52% 

   Experimental RFCs         5 of 11 or 45.45% 

The document is therefore close to useless because it is substantially
wrong up to section 7.1.  Since experimental protocols that are not
used need not be considered, the entire useful part of this document
fits easily on two pages, plus a references page (and boilerplate).

Other minor points:

It has long been recognized that RFC-1822 should be updated to better
reflect IPv4 router requirements and when that is done IPv6 can be
addressed in that update or IPv6 can be addressed in a separate
document.

You need not cover experimental RFCs.  If the protocol has been
experimental for a few years it generally means it is unused and could
be reclassified as historic.  Until such time as it is reclassified as
Proposed Standard, you can ignore it for the purpose of this document.

Curtis

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