Received changes through RFC Editor sync (changed abstract to 'This document describes an extension to Open Shortest Path First (OSPF) in order to define independent IP topologies called Multi- Topologies (MTs). The Multi-Topologies extension can be used for computing different paths for unicast traffic, multicast traffic, different classes of service based on flexible criteria, or an in- band network management topology.

An optional extension to exclude selected links from the default topology is also described. [STANDARDS-TRACK]')

[Ballot comment]
My no-obj is based on the assumption David's discuss is addressed.  I
strongly agree that ruling the forwarding plane issues out of scope is
a bad idea.  I think the routing area really needs to sign up to
dealing with the forwarding considerations for this and for the
similar ISIS document.

[Ballot comment]
Comments received the Ops Directorate by Pekka Savola:

Some editorial comments:
- The document should state that it Updates the OSPF spec, RFC 2328.
- Abstract also mentions 'different classes of service based on
  flexible criteria, or an in-band network management [topologies]'
  which are not mentioned anymore later in the draft; this should
  probably be removed from the abstract or applicability expanded in
  Introduction or some suitable section.
- "[M-ISIS] describes a similar mechanism for ISIS." after talking
  about ToS as multi-topology hasn't been even mentioned yet; better
  place would be after the second paragraph of Introduction.

[Ballot discuss]
I agree with the following review that I received from Pekka Savola from the Ops Directorate:

-----
I believe there are a couple of problems with this specification.
Apart from the second issue below these should be easy to solve; the
2nd issue may require a bit further though and a closer look of
security area and routing directorate would likely be a good idea.

First of all, section 3.7 defines the MT-ID values for the whole
1-byte space without establishing an IANA registry.  If the IETF
wanted to define a new MT-ID values for whatever reasons, this would
become rather complex and there would not be up-to-date registry
anywhere.  If there is no strong reason for the current approach, I'd
suggest putting the existing list under IANA stewardship and defining
a part of MT-ID space as assignable under some policy, e.g., Standards
Action.

Second, I'm not sure the security considerations is adequate.  As
evidenced by the abstract, the intent is to use this e.g., for in-band
network management which clearly seeks the security 'benefit' of
restricting in-band access from 'default'.  The forwarding plane
matching implications were decreed out of scope of this memo (section
3.8).  Presumably implementations are going to use something like the
source or destination IP addresses to determine which packets belong
to which topology.  (Non-specified) classifying packets to multiple
forwarding and control planes seems to change the security assumptions
of OSPF.  At the very least, I'd like to see some discussion about the
security properties of forwarding function separation (s3.8) and its
implications such as packets getting forwarded to a wrong topology.
-----

Proposed fix:

Follow Pekka's advise for the first issue.
For the second issue: this document has potential operational issues and ruling them out of scope is not how one deals solves this issue.
This document really needs an operational considerations section
on how to deal with the seperation in the real world and an expanded security consideration section.

[Ballot comment]
1. It would be useful that the statement in the Introduction 'TOS based routing as described in [TOS-OSPF] was never deployed and was subsequently deprecated.' is backed-up by a reference. The appropriate reference is I believe Annex G.10 in RFC2178

2. I am surprised by the absence of a Manageability and Operations Considerations section, or of any reference to such considerations in the document. There are at least two good reasons beyond the usual ones for such consideration to be included:

- the document lists the creation of a dedicated topology for network management as one of the principal applications of OSPF MT routing

- the PROTO write-up mentions that 'there may be implications on the MIB'

IANA Last Call Comments :

As described in the IANA Considerations section this
document redefines the T-bit for a router's TOS capability
as the MT-bit. The T-bit does not appear in a registry
maintained by IANA.

The TOS field in OSPF 2 for Router-LSAs, Summary-LSAs,
NSSA-LSAs and AS-External LSAs is redefined by this
document at MT-ID. The TOS field does not appear in a
registry maintained by IANA.

IANA understands that it has no IANA Actions upon approval
of this document.

Proto answers from Acee:

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?

  I have reviewed every version of the document and, in fact, have
acted as editor. Rohit and I have discussed the document (he can speak
for his own level of review).

2. Has the document had adequate review from both key WG members and
key non-WG members? Do you have any concerns about the depth or breadth
of the reviews that have been performed?

  Non-OSPF WG members do not normally review OSPF drafts. Comments were
received on the revisions of the document.  Since I reviewed and edited
the document I have no concerns with the quality of review.

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. There may be implications on the MIB. However, OSPF MIB
enhancements have typically followed functional enhancements.

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. Alex Zinin has said several times that the forwarding issues with
MTR need to be documented but my understanding is
  that we agreed that this would go in a separate document. If people
would be happier, something very similar to section 12
  of the M-ISIS draft could be added. However, I'm against since
inadequately covering a subject is worse than saying that the
  subject is beyond the scope of the document.

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?

  The draft was accepted as a WG document and sufficient opportunity has
been given to disagree of comment on it. When the document
was initially accepted as a WG document, OSPF implementors from multiple
vendors agreed that it should be accepted.

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 <http://www.ietf.org/ID-Checklist.html> ?
  When I took over editing of the document, I converted it to xml2rfc.
Hence, I believe all the nits are satisfied. Please let me know if they
are not.

8. Is the document split into normative and informative references? 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.)

  There are normative/informative references and none of the normative
references will hold up the document. The M-ISIS draft has not advanced
to RFC state but it is an informative reference.

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

Proposed Standard.

Pick up dropped ball - there's an open ticket requesting that this draft advance from April.  I suspect the lack of a clear action-requesting subject line caused it to be overlooked.