OSPF Database Exchange Summary List Optimization
RFC 5243

[Ballot discuss]
This is a "discuss-discuss" and I expect to move to a Yes position after
the telechat. The document says:

  The Database Exchange summary list optimization is defined by
  modifying Section 10.6 (Receiving Database Description Packets) of
  RFC 2328 as follows.  The second-to-last paragraph of Section 10.6 is
  replaced with the following

I'm wondering how we do this procedurally. This is an Informational
document, expecting to update the procedures in an existing standards
track RFC (STD 54).

At the very least Updates: header should appear at the front.

But in general, I'm very supportive of optimizations like this. Is
there a reason why this couldn't be a Proposed Standard?

[Ballot discuss]
This is a "discuss-discuss" and I expect to move to a Yes position after
the telechat. The document says:

  The Database Exchange summary list optimization is defined by
  modifying Section 10.6 (Receiving Database Description Packets) of
  RFC 2328 as follows.  The second-to-last paragraph of Section 10.6 is
  replaced with the following

I'm wondering how we do this procedurally. This is an Informational
document, expecting to update the procedures in an existing standards
track RFC (STD 54).

At the very least Updates: header should appear at the front.

But in general, I'm very supporting of optimizations like this. Is
there a reason why this couldn't be a Proposed Standard?

[Ballot comment]
Expand first use of acronym LSA in the abstract.

> The second-to-last paragraph of Section 10.6 is
> replaced with the following augmented paragraph:

After the "second-to-last" and "last" paragraphs in 10.6 of RFC 2328 there
are a few bullet items. You may want to be more precise which paragraph
you actually mean.

[Ballot discuss]
This is a "discuss-discuss" and I expect to move to a Yes position after
the telechat. The document says:

  The Database Exchange summary list optimization is defined by
  modifying Section 10.6 (Receiving Database Description Packets) of
  RFC 2328 as follows.  The second-to-last paragraph of Section 10.6 is
  replaced with the following

I'm wondering how we do this procedurally. This is an Informational
document, expecting to update the procedures in an existing Standard
RFC.

At the very least Updates: header should appear at the front.

But in general, I'm very supporting of optimizations like this. Is
there a reason why this couldn't be a Proposed Standard?

[Ballot comment]
Expand first use of acronym LSA in the abstract.

> The second-to-last paragraph of Section 10.6 is
> replaced with the following augmented paragraph:

After the "second-to-last" and "last" paragraphs in 10.6 there
are a few bullet items. You may want to be more precise which paragraph
you actually mean.

PROTO writeup by Acee Lindem: 


  1. Have the chairs personally reviewed this version of the Internet
    Draft (ID), and in particular, do they believe this ID is ready
    to forward to the IESG for publication?

    Yes

  2. Has the document had adequate review from both key WG members and
    key non-WG members?

    Yes - I've reviewed it myself several times. There are no key non-WG
    members.

    Do you have any concerns about the depth or
    breadth of the reviews that have been performed?
   
    No

  3. Do you have concerns that the document needs more review from a
    particular (broader) perspective (e.g., security, operational
    complexity, someone familiar with AAA, etc.)?

    No

  4. Do you have any specific concerns/issues with this document that
    you believe the ADs and/or IESG should be aware of? For example,
    perhaps you are uncomfortable with certain parts of the document,
    or have concerns whether there really is a need for it. In any event,
    if your issues have been discussed in the WG and the WG has
    indicated it that it still wishes to advance the document, detail
    those concerns in the write-up.

    No

  5. How solid is the WG consensus behind this document? Does it represent
    the strong concurrence of a few individuals, with others being silent,
    or does the WG as a whole understand and agree with it?

    Those that understand it agree though I'm sure many had wished they'd
    thought of it themselves.

  6. Has anyone threatened an appeal or otherwise indicated extreme
    discontent? If so, please summarise the areas of conflict
    in separate email to the Responsible Area Director.

    No

  7. Have the chairs verified that the document adheres to all
    of the ID Checklist items ?
idnits 2.04.07

tmp/draft-ietf-ospf-dbex-opt-01.txt:

  Checking boilerplate required by RFC 3978 and 3979, updated by RFC 4748:
  ----------------------------------------------------------------------------

    No issues found here.

  Checking nits according to http://www.ietf.org/ietf/1id-guidelines.txt:
  ----------------------------------------------------------------------------

    No issues found here.

  Checking nits according to http://www.ietf.org/ID-Checklist.html:
  ----------------------------------------------------------------------------

    No issues found here.

  Miscellaneous warnings:
  ----------------------------------------------------------------------------

    No issues found here.

  Checking references for intended status: Informational
  ----------------------------------------------------------------------------

    No issues found here.

    No nits found.
--------------------------------------------------------------------------------



  8. Is the document split into normative and informative references?

    Yes but there are ONLY normative references in this document.

    Are there normative references to IDs, where the IDs are not
    also ready for advancement or are otherwise in an unclear state? (note
    here that the RFC editor will not publish an RFC with normative
    references to IDs, it will delay publication until all such IDs
    are also ready for publication as RFCs.)

    No

  9. What is the intended status of the document? (e.g., Proposed Standard,
    Informational?)

    Informational

10. For Standards Track and BCP documents, the IESG approval announcement
    includes a write-up section with the following sections:

    * Technical Summary
    * Working Group Summary
    * Protocol Quality

    Informational - Not applicable