Host Router Support for OSPFv2
draft-ietf-ospf-ospfv2-hbit-12

[Ballot comment]
I'm going to complain about some wording in Section 5 that Ben already called out, but I'll try to put in some specific suggestions for corrections here:

  In normal operation, there is no guarantee that the RI LSA will reach
  all routers in an area in a timely manner, which may result in
  forwarding loops in partial deployments.

This wording makes it sound exactly the opposite of what you mean, that if the RI LSA *does* reach all routers in a timely manner it can cause forwarding loops.  I suggest this:

NEW
  In normal operation, it is possible that the RI LSA will fail to
  reach all routers in an area in a timely manner.  That can result
  in forwarding loops in partial deployments.
END

  For example, if a new
  router joins an area, which previously had only H-bit capable routers
  with H-bit set then it may take some time for the RI to propagate to
  all routers.

First, change "area, which" to "area that" (no comma).  That fixes a usage problem.

But second, Ben and I are both unsure whether you mean that the new router does or doesn't support the H bit, or whether it matters.  Maybe the right approach here is to say a little more about what happens.  Something like this (adjust as needed to make it correct):

NEW
  For example, if a new
  router joins an area that previously had only H-bit capable routers
  with H-bit set then it may take some time for the RI to propagate to
  all routers.  While it is propagating, the area as a whole is unsure of
  the status of the new router, and that can cause
END

  o  All routers, with the H-bit set, MUST advertise all of the
      router's non-stub links with a metric equal to MaxLinkMetric

Both commas need to be removed here.

  o  All routers supporting H-Bit MUST check all the RI LSAs of nodes
      in the area before actively running the modified SPF to account
      for the H-bit in order to verify that all routers are in routing
      capability.

This is very awkwardly worded and is really hard to decipher.  I *think* you mean to say this:

NEW
  o  All routers supporting the H-Bit MUST check the RI LSAs of all
      nodes in the area to verify that all nodes support the H-Bit before
      actively using the H-Bit feature.
END

Did I get that right?

[Ballot comment]
Abstract

  The Open Shortest Path First Version 2 (OSPFv2) does not have a
  mechanism for a node to repel transit traffic if it is on the
  shortest path.  This document defines a bit (Host-bit) that enables a

nit: I suggest to add "protocol" after "(OSPFv2)" to match the definite
article "The".

Section 1

  The OSPFv2 specifies a Shortest Path First (SPF) algorithm that

(same nit about adding "protocol")

  This functionality is particularly useful for a number of use cases:

nit: "this functionality" seems to refer to "the SPF algorithm that
identifies transit verticies based on their adjacencies", so I suggest
rewording to "such functionality would be useful" or "A mechanism to
move traffic away from the shortest path" or similar.

Section 4

I suggest noting that the (lettered) sub-procedures of step (2) remain
unchanged.

Section 5

  In normal operation, there is no guarantee that the RI LSA will reach
  all routers in an area in a timely manner, which may result in
  forwarding loops in partial deployments.  For example, if a new
  router joins an area, which previously had only H-bit capable routers
  with H-bit set then it may take some time for the RI to propagate to
  all routers.

It's currently only implicit that this new router does not support the
H-bit; shall we make it explicit?

  o  All routers supporting H-Bit MUST check all the RI LSAs of nodes
      in the area before actively running the modified SPF to account
      for the H-bit in order to verify that all routers are in routing
      capability.  If any router does not advertise the Host Router

nit: the grammar here is a little wonky, particularly for "all routers
are in routing capability" but perhaps also for "to account for the
H-bit".

Section 6

  When calculating the path to an OSPF AS-External-LSA or NSSA-LSA
  [RFC3101] with a Type-2 metric, [...]

nit: is this saying "calculating the path to [an LSA]"?  That's not a
usage I'm familiar with; can the AS-External-LSA or NSSA-LSA really
serve as a destination in this sense?

Section 7

Thank you for phrasing this as "this document requests the IANA to
assign", since until these specific values are officially assigned we
are technically "squatting" on them.  (The respective registration
policies of Standards Action and IETF Review give us pretty good control
that nothing else is going to swoop in on them, though.)

[Ballot comment]
Thank you for the work put into this document. The short document is easy to read even if I wonder whether it is useful to spend time on IPv4-only protocol ;-)

The deployment issue (section 5) had raised a DISCUSS of mine and I appreciated your reply, so, I have cleared this DISCUSS.

Feel free to ignore my COMMENTs and NIT.

== COMMENTS ==

-- Generic --
Mentioning that the H-bit of OSPFv2 is the reverse of the R-bit of OSPFv3 would be useful.

-- Section 1 --
A description of "Closet Switches" would be welcome.

-- Section 3 --
Isn't the wording "host router" an oxymoron ?


== NITS ==

-- Section 8 --
I recommend reading and following the suggestions of RFC 8126 (how to write the IANA considerations)

[Ballot comment]
Three comments/questions:

1) This sentence in section 3:
"An OSPFv2 router advertising a router-LSA with the H-bit
  set indicates that it MUST NOT be used as a transit router (see
  Section 4) by other OSPFv2 routers in the area supporting the
  functionality."
Isn't the MUST here too restrictive? What if the router is the part of the only path to a certain host?
Or is the assumption that this host is some kind of endhost/deadend, but then it should never be on the shortest path anyway, or?

Later on you say
"When the H-bit is set, the OSPFv2 router is a Host (non-transit)
  router and is incapable of forwarding transit traffic."
However, there might also be routers that don't understand the H bit and therefore will route traffic over this host anyway, no?

2) Shouldn't this document update RFC2328, given section 4 and this sentence in section 2:
"If the H-bit is set then the calculation of the shortest-
  path tree for an area, as described in section 16.1 of [RFC2328], is
  modified by including a check to verify that transit vertices DO NOT
  have the H-bit set (see Section 4)."
(And why is DO NOT in upper letters?)

3) Is there an attack that by spoofing the H-bit an attacker could influence the routing such that traffic is router over a malicious node instead? I guess there are multiple ways to impact the routing that way and this might not be specific to the H bit but maybe still worth thinking about it once more...?

Nit:
Section 5: "The RI LSA MUST be area-scoped.  Bit:" -> I guess the "Bit:" should be removed.

[Ballot discuss]
Thank you for the work put into this document. The short document is easy to read even if I wonder whether it is useful to spend time on IPv4-only protocol ;-)

The deployment issue (section 5) has raised a DISCUSS of mine and I would appreciate a reply on this DISCUSS.

Regards,

-éric

== DISCUSS ==

-- Section 5 --
The risk of having inconsistent view of the topology with H-bit aware and unaware routers seems possible to me (albeit perhaps only transient). Has this feature been tested / simulated in large scale networks?

[Ballot comment]
Feel free to ignore my COMMENTs and NIT.

== COMMENTS ==

-- Generic --
Mentioning that the H-bit of OSPFv2 is the reverse of the R-bit of OSPFv3 would be useful.

-- Section 1 --
A description of "Closet Switches" would be welcome.

-- Section 3 --
Isn't the wording "host router" an oxymoron ?


== NITS ==

-- Section 8 --
I recommend reading and following the suggestions of RFC 8126 (how to write the IANA considerations)

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of draft-ietf-ospf-ospfv2-hbit-10. If any part of this review is inaccurate, please let us know.

The IANA Functions Operator understands that, upon approval of this document, there are two actions which we must complete.

First, in the OSPFv2 Router Properties Registry on the Open Shortest Path First v2 (OSPFv2) Parameters registry page located at:

https://www.iana.org/assignments/ospfv2-parameters/

a single, new value is to be registered as follows:

Value: 0x80
Description: Host (H-bit)
Reference: [ RFC-to-be ]

Second, in the OSPF Router Informational Capability Bits registry on the Open Shortest Path First (OSPF) Parameters registry page located at:

https://www.iana.org/assignments/ospf-parameters/

a single, new registration will be made as follows:

Bit Number: 7
Capability Name: OSPF Host Router
Reference: [ RFC-to-be ]

The IANA Functions Operator understands that these are the only actions required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

Thank you,

Sabrina Tanamal
Senior IANA Services Specialist

The following Last Call announcement was sent out (ends 2019-11-07):

From: The IESG
To: IETF-Announce
CC: Yingzhen Qu , draft-ietf-ospf-ospfv2-hbit@ietf.org, aretana.ietf@gmail.com, lsr-chairs@ietf.org, yingzhen.ietf@gmail.com, lsr@ietf.org
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (Host Router Support for OSPFv2) to Proposed Standard


The IESG has received a request from the Link State Routing WG (lsr) to
consider the following document: - 'Host Router Support for OSPFv2'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2019-11-07. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


  The Open Shortest Path First Version 2 (OSPFv2) does not have a
  mechanism for a node to repel transit traffic if it is on the
  shortest path.  This document defines a bit (Host-bit) that enables a
  router to advertise that it is a non-transit router."  It also
  describes the changes needed to support the H-bit in the domain.  In
  addition, this document updates RFC 6987 to advertise type-2 External
  and NSSA LSAs with a high cost in order to repel traffic effectively.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-ospf-ospfv2-hbit/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-ospf-ospfv2-hbit/ballot/


No IPR declarations have been submitted directly on this I-D.

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet
    Standard, Informational, Experimental, or Historic)? Why is this the
    proper type of RFC? Is this type of RFC indicated in the title page
    header?

      A Standards Track RFC is being requested and is indicated in the
      title page header.

(2) The IESG approval announcement includes a Document Announcement
    Write-Up.  Please provide such a Document Announcement Write-Up.
    Recent examples can be found in the "Action" announcements for
    approved documents. The approval announcement contains the following
    sections:

Technical Summary:
   
    This document defines a new router-LSA bit known as the Host Bit or the H-bit.
    An OSPFv2 router advertising a router-LSA with the H-bit set indicates to other
    OSPFv2 routers in the area supporting the functionality that it MUST NOT be used
    as a transit router. 

Working Group Summary:
 
    The Working Group has reached consensus that this document is useful and should
    be published.
     
Document Quality:
     
      This is a straight forward draft, and similar function exists in ISIS and OSPFv3. Some nits to be fixed.
      There are review comments from AD to be addressed.

Personnel:

      Yingzhen Qu is the Document Shepherd.
      Alvaro Retana is the Responsible Area Director.

(3) Briefly describe the review of this document that was performed by
    the Document Shepherd. If this version of the document is not ready
    for publication, please explain why the document is being forwarded
    to the IESG.

    The document shepherd has reviewed each revision of the document
    and followed the discussion on the OSPF/LSR mailing lists.


(4) Does the document Shepherd have any concerns about the depth or
    breadth of the reviews that have been performed?

      No.

(5) Do portions of the document need review from a particular or from
    broader perspective, e.g., security, operational complexity, AAA,
    DNS, DHCP, XML, or internationalization? If so, describe the review
    that took place.

      No.

(6) Describe any specific concerns or issues that the Document Shepherd
    has with this document that the Responsible Area Director and/or
    the IESG should be aware of? For example, perhaps he or she is
    uncomfortable with certain parts of the document, or has concerns
    whether there really is a need for it. In any event, if the WG has
    discussed those issues and has indicated that it still wishes to
    advance the document, detail those concerns here.

      None.

(7) Has each author confirmed that any and all appropriate IPR
    disclosures required for full conformance with the provisions of BCP
    78 and BCP 79 have already been filed. If not, explain why?

    Yes, they all confirmed.

(8) Has an IPR disclosure been filed that references this document? If
    so, summarize any WG discussion and conclusion regarding the IPR
    disclosures.
 
    No.

(9) 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?

      There is consensus from the WG that this document can progress.

(10) Has anyone threatened an appeal or otherwise indicated extreme
    discontent?  If so, please summarise the areas of conflict in
    separate email messages to the Responsible Area Director. (It
    should be in a separate email because this questionnaire is
    publicly available.)

      No.

(11) Identify any ID nits the Document Shepherd has found in this
    document.  (See http://www.ietf.org/tools/idnits/ and the
    Internet-Drafts Checklist).  Boilerplate checks are not enough;
    this check needs to be thorough.

      Nits are all resolved.

(12) Describe how the document meets any required formal review
    criteria, such as the MIB Doctor, media type, and URI type reviews.

      Not applicable.

(13) Have all references within this document been identified as either
    normative or informative?

      Yes.

(14) Are there normative references to documents that are not ready for
    advancement or are otherwise in an unclear state? If such
    normative references exist, what is the plan for their completion?
 
      No.

(15) Are there downward normative references references (see RFC 3967)?
    If so, list these downward references to support the Area Director
    in the Last Call procedure.

      RFC 6987 should be a Downward Normative References.

(16) Will publication of this document change the status of any existing
    RFCs?  Are those RFCs listed on the title page header, listed in
    the abstract, and discussed in the introduction? If the RFCs are
    not listed in the Abstract and Introduction, explain why, and point
    to the part of the document where the relationship of this document
    to the other RFCs is discussed. If this information is not in the
    document, explain why the WG considers it unnecessary.

When implementing this document, the SPF calculation defined
in RFC 2328 needs to be changed. This needs to be clearly stated
in the document.

(17) Describe the Document Shepherd's review of the IANA considerations
    section, especially with regard to its consistency with the body of
    the document.  Confirm that all protocol extensions that the
    document makes are associated with the appropriate reservations in
    IANA registries. Confirm that any referenced IANA registries have
    been clearly identified. Confirm that newly created IANA registries
    include a detailed specification of the initial contents for the
    registry, that allocations procedures for future registrations are
    defined, and a reasonable name for the new registry has been
    suggested (see RFC 5226).

This document requires an allocation of Host(H-bit) in OSPF
router-LSA bit registry.
It also requires to define a new Router Functional Capability
(RFC7770), the Host Support Functional Capability, from the Router
Functional Capability Bits TLV.

(18) List any new IANA registries that require Expert Review for future
    allocations. Provide any public guidance that the IESG would find
    useful in selecting the IANA Experts for these new registries.

      None.

(19) Describe reviews and automated checks performed by the Document
    Shepherd to validate sections of the document written in a formal
    language, such as XML code, BNF rules, MIB definitions, etc.

      Not applicable.

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet
    Standard, Informational, Experimental, or Historic)? Why is this the
    proper type of RFC? Is this type of RFC indicated in the title page
    header?

      A Standards Track RFC is being requested and is indicated in the
      title page header.

(2) The IESG approval announcement includes a Document Announcement
    Write-Up.  Please provide such a Document Announcement Write-Up.
    Recent examples can be found in the "Action" announcements for
    approved documents. The approval announcement contains the following
    sections:

Technical Summary:
   
    This document defines a new router-LSA bit known as the Host Bit or the H-bit.
    An OSPFv2 router advertising a router-LSA with the H-bit set indicates to other
    OSPFv2 routers in the area supporting the functionality that it MUST NOT be used
    as a transit router. 

Working Group Summary:
 
    The Working Group has reached consensus that this document is useful and should
    be published.
     
Document Quality:
     
      The document has been implemented by xxxx.

Personnel:

      Yingzhen Qu is the Document Shepherd.
      Alvaro Retana is the Responsible Area Director.

(3) Briefly describe the review of this document that was performed by
    the Document Shepherd. If this version of the document is not ready
    for publication, please explain why the document is being forwarded
    to the IESG.

    The document shepherd has reviewed each revision of the document
    and followed the discussion on the OSPF/LSR mailing lists.


(4) Does the document Shepherd have any concerns about the depth or
    breadth of the reviews that have been performed?

      No.

(5) Do portions of the document need review from a particular or from
    broader perspective, e.g., security, operational complexity, AAA,
    DNS, DHCP, XML, or internationalization? If so, describe the review
    that took place.

      No.

(6) Describe any specific concerns or issues that the Document Shepherd
    has with this document that the Responsible Area Director and/or
    the IESG should be aware of? For example, perhaps he or she is
    uncomfortable with certain parts of the document, or has concerns
    whether there really is a need for it. In any event, if the WG has
    discussed those issues and has indicated that it still wishes to
    advance the document, detail those concerns here.

      None.

(7) Has each author confirmed that any and all appropriate IPR
    disclosures required for full conformance with the provisions of BCP
    78 and BCP 79 have already been filed. If not, explain why?

    Yes, they all confirmed.

(8) Has an IPR disclosure been filed that references this document? If
    so, summarize any WG discussion and conclusion regarding the IPR
    disclosures.
 
    No.

(9) 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?

      There is consensus from the WG that this document can progress.

(10) Has anyone threatened an appeal or otherwise indicated extreme
    discontent?  If so, please summarise the areas of conflict in
    separate email messages to the Responsible Area Director. (It
    should be in a separate email because this questionnaire is
    publicly available.)

      No.

(11) Identify any ID nits the Document Shepherd has found in this
    document.  (See http://www.ietf.org/tools/idnits/ and the
    Internet-Drafts Checklist).  Boilerplate checks are not enough;
    this check needs to be thorough.

      Nits are all resolved.

(12) Describe how the document meets any required formal review
    criteria, such as the MIB Doctor, media type, and URI type reviews.

      Not applicable.

(13) Have all references within this document been identified as either
    normative or informative?

      Yes.

(14) Are there normative references to documents that are not ready for
    advancement or are otherwise in an unclear state? If such
    normative references exist, what is the plan for their completion?
 
      No.

(15) Are there downward normative references references (see RFC 3967)?
    If so, list these downward references to support the Area Director
    in the Last Call procedure.

      No.

(16) Will publication of this document change the status of any existing
    RFCs?  Are those RFCs listed on the title page header, listed in
    the abstract, and discussed in the introduction? If the RFCs are
    not listed in the Abstract and Introduction, explain why, and point
    to the part of the document where the relationship of this document
    to the other RFCs is discussed. If this information is not in the
    document, explain why the WG considers it unnecessary.

The publication of this document will update RFC 2328. This
information has been listed on the title page header,
the Abstract, and Introduction.

(17) Describe the Document Shepherd's review of the IANA considerations
    section, especially with regard to its consistency with the body of
    the document.  Confirm that all protocol extensions that the
    document makes are associated with the appropriate reservations in
    IANA registries. Confirm that any referenced IANA registries have
    been clearly identified. Confirm that newly created IANA registries
    include a detailed specification of the initial contents for the
    registry, that allocations procedures for future registrations are
    defined, and a reasonable name for the new registry has been
    suggested (see RFC 5226).

This document requires an allocation of Host(H-bit) in OSPF
router-LSA bit registry.
It also requires to define a new Router Functional Capability
(RFC7770), the Host Support Functional Capability, from the Router
Functional Capability Bits TLV.

(18) List any new IANA registries that require Expert Review for future
    allocations. Provide any public guidance that the IESG would find
    useful in selecting the IANA Experts for these new registries.

      None.

(19) Describe reviews and automated checks performed by the Document
    Shepherd to validate sections of the document written in a formal
    language, such as XML code, BNF rules, MIB definitions, etc.

      Not applicable.

Internet Engineering Task Force                                    Y. Fu
Internet-Draft                                                    CNNIC
Intended status: Standards Track                                S. Jiang
Expires: December 19, 2015                                        B. Liu
                                            Huawei Technologies Co., Ltd
                                                                J. Dong
                                                                Y. Chen
                                                    Tsinghua University
                                                          June 17, 2015

                Definitions of Managed Objects for MAP-E
                    draft-ietf-softwire-map-mib-04

Abstract

  This memo defines a portion of the Management Information Base (MIB)
  for using with network management protocols in the Internet
  community.  In particular, it defines managed objects for MAP
  encapsulation mode.

Status of This Memo

  This Internet-Draft is submitted in full conformance with the
  provisions of BCP 78 and BCP 79.

  Internet-Drafts are working documents of the Internet Engineering
  Task Force (IETF).  Note that other groups may also distribute
  working documents as Internet-Drafts.  The list of current Internet-
  Drafts is at http://datatracker.ietf.org/drafts/current/.

  Internet-Drafts are draft documents valid for a maximum of six months
  and may be updated, replaced, or obsoleted by other documents at any
  time.  It is inappropriate to use Internet-Drafts as reference
  material or to cite them other than as "work in progress."

  This Internet-Draft will expire on December 19, 2015.

Copyright Notice

  Copyright (c) 2015 IETF Trust and the persons identified as the
  document authors.  All rights reserved.

  This document is subject to BCP 78 and the IETF Trust's Legal
  Provisions Relating to IETF Documents
  (http://trustee.ietf.org/license-info) in effect on the date of
  publication of this document.  Please review these documents
  carefully, as they describe your rights and restrictions with respect

Fu, et al.              Expires December 19, 2015              [Page 1]
Internet-Draft      draft-ietf-softwire-map-mib-04            June 2015

  to this document.  Code Components extracted from this document must
  include Simplified BSD License text as described in Section 4.e of
  the Trust Legal Provisions and are provided without warranty as
  described in the Simplified BSD License.

  This document may contain material from IETF Documents or IETF
  Contributions published or made publicly available before November
  10, 2008.  The person(s) controlling the copyright in some of this
  material may not have granted the IETF Trust the right to allow
  modifications of such material outside the IETF Standards Process.
  Without obtaining an adequate license from the person(s) controlling
  the copyright in such materials, this document may not be modified
  outside the IETF Standards Process, and derivative works of it may
  not be created outside the IETF Standards Process, except to format
  it for publication as an RFC or to translate it into languages other
  than English.

Table of Contents

  1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .  2
  2.  The Internet-Standard Management Framework  . . . . . . . . .  3
  3.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .  3
  4.  Structure of the MIB Module . . . . . . . . . . . . . . . . .  3
    4.1.  The mapMIBObjects . . . . . . . . . . . . . . . . . . . .  3
      4.1.1.  The mapRule Subtree . . . . . . . . . . . . . . . . .  3
      4.1.2.  The mapSecurityCheck Subtree  . . . . . . . . . . . .  3
    4.2.  The mapMIBConformance Subtree . . . . . . . . . . . . . .  4
  5.  Definitions . . . . . . . . . . . . . . . . . . . . . . . . .  4
  6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  10
  7.  Security Considerations . . . . . . . . . . . . . . . . . . .  11
  8.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  11
  9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  11
    9.1.  Normative References  . . . . . . . . . . . . . . . . . .  11
    9.2.  Informative References  . . . . . . . . . . . . . . . . .  12
  Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  12

1.  Introduction

  MAP [I-D.ietf-softwire-map] is a stateless mechanism for running IPv4
  over IPv6-only infrastructure.  In particular, it includes two mode,
  translation mode or encapsulation mode.  For the encapsulation mode,
  it provides an automatic tunnelling mechanism for providing IPv4
  connectivity service to end users over a service provider's IPv6
  network

  This document defines a portion of the Management Information Base
  (MIB) for use with network management protocols in the Internet

Fu, et al.              Expires December 19, 2015              [Page 2]
Internet-Draft      draft-ietf-softwire-map-mib-04            June 2015] to support backward compatibility.  The modified OSPFv2
125  router-LSA format is:

[minor] "...MUST NOT be used as a transit router"  Put a forward reference
to §4.

[nit] The text keeps making reference to the R-bit.  Even though there is a
relationship, the H-bit is an independent feature.  IOW, I don't think
there's a need to explain the relationship to OSPFv3.

[minor] On the same topic:  The comparison to OSPFv3 is made and the
"reverse" bit setting is justified "to support backward compatibility", but
that is not explained anywhere.  I was hoping that §5 (Auto Discovery and
Backward Compatibility) would say something, but it doesn't.

127        0                  1                  2                  3
128        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
129      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
130      |            LS age            |    Options  |      1      |
131      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
132      |                        Link State ID                          |
133      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
134      |                    Advertising Router                        |
135      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
136      |                    LS sequence number                        |
137      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
138      |        LS checksum          |            length            |
139      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
140      |H|0|0|N|W|V|E|B|        0      |            # links            |
141      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
142      |                          Link ID                              |
143      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
144      |                        Link Data                            |
145      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
146      |    Type      |    # TOS    |            metric            |
147      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
148      |                              ...                              |
149      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
150      |      TOS      |        0      |          TOS  metric          |
151      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
152      |                          Link ID                              |
153      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
154      |                        Link Data                            |
155      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
156      |                              ...                              |

158      bit H
159          When set, an OSPFv2 router is a non-transit router and is
160          incapable of forwarding transit traffic.

[nit] Please label the figure: Figure 1...

[minor] Even though it seems obvious from the figure, please be explicit in
saying that the H-bit is the first bit (or however that bit is
identified)...

162  When the H-bit is set, an OSPFv2 router is a non-transit router and
163  should not be used to forward transit traffic.  In this mode, the
164  other OSPFv2 routers in the area SHOULD NOT use the originating
165  OSPFv2 router for transit traffic, but MAY use the OSPFv2 router for
166  local traffic destined to that OSPFv2 router.

[minor] The first/second sentences seem redundant: "should not be used to
forward transit traffic...SHOULD NOT use the originating OSPFv2 router for
transit traffic".

[major] When would the non-transit router be used for transit?  IOW, why
use "SHOULD NOT" and not "MUST NOT"?

[major] "MAY use the OSPFv2 router for local traffic destined to that
OSPFv2 router"  I'm not sure what behavior is being specified here.  The
text sounds as if it was optional to even consider the router as a traffic
destination.  Is that the intent?  Why?  What would make a network operator
decide one way or the other?

168  An OSPFv2 router originating a router-LSA with the H-bit set SHOULD
169  advertise all its non-local router links with a link cost of
170  MaxLinkMetric as defined in Section 3 of [RFC6987].  This is to
171  increase the applicability of the H-bit to partial deployments where
172  it is the responsibility of the operator to ensure that OSPFv2
173  routers not supporting the H-bit do not install routes causing
174  routing loops.

[major] When would a router not advertise MaxLinkMetric?  IOW, why use
SHOULD and not MUST?

[major] What are "non-local router links"?  I always thought of links to be
local to the router...what am I missing?

[nit] s/advertise all its non-local router links with a link cost of
MaxLinkMetric as defined in Section 3 of [RFC6987]/advertise all its
non-local router links with a link cost of MaxLinkMetric [RFC6987]

176  When the H-bit is set, IPv4 prefixes associated with local interfaces
177  in other areas MAY be advertised in summary LSAs.  Non-local IPv4
178  prefixes, e.g., those advertised by other routers and installed
179  during the SPF computation, MAY be advertised in summary-LSAs if
180  configured by policy.  Likewise, when the H-bit is set, only IPv4
181  prefixes associated with local interfaces MAY be advertised in AS-
182  external LSAs.  Non-local IPv4 prefixes, e.g., those exported from
183  other routing protocols, MUST NOT be advertised in AS-external-LSAs.
184  Finally, when the H-bit is set, an Area Border Router (ABR) MUST
185  advertise a consistent H-bit setting in its self-originated router-
186  LSAs for all attached areas.

[minor] Some of the behavior specified in this paragraph may be non
intuitive -- for example: "When the H-bit is set, IPv4 prefixes associated
with local interfaces in other areas MAY be advertised in summary LSAs."
During normal operation (aka rfc2328), these prefixes are always
advertised (assuming normal areas, etc.)...and given that these are local
to the router, it can be argued that one is not using the router as
transit...on the other hand, going to a different area can be interpreted
as transit.  In either case, it would be nice if more was said about the
optional nature of including these prefixes in the summary LSA.  What are
the operational considerations?

[minor] The same comment for "prefixes associated with local interfaces MAY
be advertised in AS-external LSAs".

[major] "Non-local IPv4 prefixes...MAY be advertised in summary-LSAs if
configured by policy."  Doesn't advertising result in the router being
transit?  Doesn't it defeats the purpose of setting the H-bit?  But there
may be operational reasons to do so -- e.g. if the router is the only ABR...

[major] "Non-local IPv4 prefixes...MUST NOT be advertised in
AS-external-LSAs."  This behavior seems consistent with the purpose of the
H-bit, but not with the rest of the paragraph.  Again, why is this
different (operationally) than transiting for non-external inter-area
prefixes.

[major] "...an Area Border Router (ABR) MUST advertise a consistent H-bit
setting in its self-originated router-LSAs for all attached areas."  What
do you mean by "consistent"?  Do you mean "the same", i.e. be non-transit
for all areas?  Do you mean "compatible", i.e. so that the setting avoids
potential loops or black holes?  Please be specific.  And please explain
why -- again, what are the operational considerations?


...
214 5.  Auto Discovery and Backward Compatibility

216  To avoid the possibility of any routing loops due to partial
217  deployment, this document defines a OSPF Router-Information LSA
218  functional capability bit known as the Host Support capability.

[minor] A reference to rfc7770 would be nice.

[mayor] I'm guessing that the RI LSA MUST be area-scoped, right?  Please be
specific.

220  Auto Discovery via announcement of the Host Support Functional
221  Capability ensures that the H-bit functionality and its associated
222  SPF changes SHOULD only take effect if all the routers in a given
223  OSPF area support this functionality.

[major] When can the functionality take effect even if not all routers in
the area support it?  Or maybe it is that it won't take effect even if all
routers support it...  IOW, why SHOULD and not MUST?

[major] There's no guarantee that the RI LSA will reach a router before the
route-carrying LSAs -- which I think implies that SPF could be run before
verifying full H-bit support.  The result may be a loop...or a loop may
exist until the lack of area-wide support is verified... IOW, it seems to
me that this auto discovery mechanism may not work as expected.  Migration
is an important Deployment Consideration.

[major] What is the process to verify area-wide support?  Should the router
build a tree...run SPF...inspect the LSAs...??  I'm assuming/hoping that
this is a common enough operation that it is specified already somewhere
else...

225  Implementations are encouraged to provide a configuration parameter
226  to manually override enforcement of the H-bit functionality in
227  partial deployments where the topology guarantees that OSPFv2 routers
228  not supporting the H-bit do not compute routes resulting in routing
229  loops.  More precisely, the advertisement of MaxLinkMetric for the
230  router's non-local links will prevent OSPFv2 routers not supporting
231  the H-bit from attempting to use it for transit traffic.

[minor] The text seems to indicate what the second sentence is a
clarification of the first one: "Implementations are encouraged to... More
precisely..."  But in reality you are talking about two different things:
the ability to consider the H-bit even in partial deployments, *and*,
advertising MaxLinkMetric.  Please consider rewording to clarify.

233 6.  OSPF AS-External-LSAs/NSSA LSAs with Type 2 Metrics

235  When calculating the path to an OSPF AS-External-LSA or NSSA-LSA with
236  a Type-2 metric, the advertised Type-2 metric is taken as more
237  significant than the OSPF intra-area or inter-area path.  Hence,
238  advertising the links with MaxLinkMetric as specified in [RFC6987]
239  does not discourage transit traffic when calculating AS external or
240  NSSA routes.  Consequently, OSPF routers implementing [RFC6987] or
241  this specification should advertise a Type-2 metric of LSInfinity for
242  any self-originated AS-External-LSAs or NSSA-LSAs in situations when
243  the OSPF router is acting as a stub router [RFC6987] or implementing
244  this specification.

[major] Should there be Normative language in this paragraph?

[major] This paragraph talks about what a stub router (rfc6987) should do.
In order to do that, this document should be tagged to Update rfc6987.  Is
that the intent?

246 7.  IANA Considerations

248  IANA is requested to create the OSPF Router-LSA bit registry with the
249  following assignments:

251        Value  Description                                Reference
252        0x01    Area Border Router (B-bit)                  [RFC2328]
253        0x02    AS Boundary Router (E-bit)                  [RFC2328]
254        0x04    Virtual Link Endpoint (V-bit)              [RFC2328]
255        0x08    Historic (W-bit)                            [RFC1584]

[major] Even though rfc1584 is classified as Historic, that doesn't mean
that the bit is as well, or that it has been deprecated (at least I didn't
see that in rfc5110).  Please put a name to it -- "wild-card multicast"?

256        0x10    Unconditional NSSA Translator (Nt-bit)      [RFC3101]
257        0x20    Unassigned
258        0x40    Unassigned
259        0x80    Host (H-bit)                            This Document

[major] What should be the assignment policy (rfc8126)?

[minor] Besides the 8 bits above, the Router-LSA (rfc2328) has another 8
bits (to the right) that seem unassigned...should they be included in this
registry as well?

[major nit] I couldn't find where rfc2328 talks about the value of these
bits being 0 and what to do if they are not.  By creating this new
registry, you have the opportunity to (at least) clarify that.

261  This document also defines a new Router Functional Capability
262  [RFC7770] known as the Host Support Functional Capability.  This
263  document requests IANA to allocate the value of this capability from
264  the Router Functional Capability Bits TLV.

[minor] s/TLV/Registry

266 8.  Security Considerations

268  This document introduces no new security considerations beyond those
269  already specified in [

  community.  This MIB module would be used for monitoring the devices
  in the MAP scenario, especially, for the encapsulation mode.

2.  The Internet-Standard Management Framework

  For a detailed overview of the documents that describe the current
  Internet-Standard Management Framework, please refer to section 7 of
  [RFC3410].

  Managed objects are accessed via a virtual information store, termed
  the Management Information Base or MIB.  MIB objects are generally
  accessed through the Simple Network Management Protocol (SNMP).
  Objects in the MIB are defined using the mechanisms defined in the
  Structure of Management Information (SMI).  This memo specifies a MIB
  module that is compliant to the SMIv2, which is described in
  [RFC2578], [RFC2579] and [RFC2580].

3.  Terminology

  The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
  "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
  "OPTIONAL" in this document are to be interpreted as described in
  [RFC2119].

4.  Structure of the MIB Module

  The MAP-E MIB provides a way to configure and monitor the devices in
  MAP encapsulation mode through SNMP.

  MAP-E MIB is configurable on a per-interface basis.  It depends on
  several parts of the IF-MIB[RFC2863].

4.1.  The mapMIBObjects

4.1.1.  The mapRule Subtree

  The mapRule subtree describes managed objects used for managing the
  multiple mapping rules in the MAP encapsulation mode.

  According to the MAP specification, the mapping rules are divided
  into two categories, which are BMR (Basic Mapping Rule), and FMR
  (Forwarding Mapping Rule).

4.1.2.  The mapSecurityCheck Subtree

  The mapSecurityCheck subtree is to statistic the number of invalid
  packets that have been identified.  There are two kind of invalid
  packets which are defined in the MAP specification as the following.

Fu, et al.              Expires December 19, 2015              [Page 3]
Internet-Draft      draft-ietf-softwire-map-mib-04            June 2015

  - The BR MUST perform a validation of the consistency of the source
  IPv6 address and source port number for the packet using BMR.

  - The CE SHOULD check that MAP received packets' transport-layer
  destination port number is in the range configured by MAP for the CE.

4.2.  The mapMIBConformance Subtree

  The mapMIBConformance subtree provides conformance information of MIB
  objects.

5.  Definitions

    MAP-E-MIB DEFINITIONS  ::=  BEGIN

      IMPORTS
        MODULE-IDENTITY, OBJECT-TYPE, transmission,
        Integer32, Unsigned32, Counter64
            FROM SNMPv2-SMI
        ifIndex
            FROM IF-MIB
        InetAddressType, InetAddress,
        InetAddressPrefixLength
            FROM INET-ADDRESS-MIB
        OBJECT-GROUP, MODULE-COMPLIANCE
            FROM SNMPv2-CONF;

      mapMIB MODULE-IDENTITY
      LAST-UPDATED "201506170000Z"
      ORGANIZATION
        "IETF Softwire Working Group"
      CONTACT-INFO
        "Yu Fu
          CNNIC
          No.4 South 4th Street, Zhongguancun
          Beijing, P.R. China 100190
          EMail: fuyu@cnnic.cn

          Sheng Jiang
          Huawei Technologies Co., Ltd
          Huawei Building, 156 Beiqing Rd., Hai-Dian District
          Beijing, P.R. China 100095
          EMail: jiangsheng@huawei.com

          Bing Liu
          Huawei Technologies Co., Ltd
          Huawei Building, 156 Beiqing Rd., Hai-Dian District
          Beijing, P.R. China 100095

Fu, et al.              Expires December 19, 2015              [Page 4]
Internet-Draft      draft-ietf-softwire-map-mib-04            June 2015

          EMail: leo.liubing@huawei.com

          Jiang Dong
          Tsinghua University
          Department of Computer Science, Tsinghua University
          Beijing  100084
          P.R. China
          Email: knight.dongjiang@gmail.com

          Yuchi Chen
          Tsinghua University
          Department of Computer Science, Tsinghua University
          Beijing  100084
          P.R. China
          Email: chenycmx@gmail.com"

      DESCRIPTION
        "The MIB module is defined for management of objects in the
        MAP-E BRs or CEs."
      REVISION    "201506170000Z"
      DESCRIPTION
        "Initial version. Published as RFC xxxx."
      --RFC Ed.: RFC-edtitor pls fill in xxxx
      ::=  {  transmission xxx  }
      --xxx to be replaced withIANA-assigned value

      mapMIBObjects OBJECT IDENTIFIER ::= {mapMIB 1}

      mapRule  OBJECT IDENTIFIER
        ::=  { mapMIBObjects 1 }

      mapSecurityCheck  OBJECT IDENTIFIER
        ::=  { mapMIBObjects 2 }

      mapRuleTable OBJECT-TYPE
        SYNTAX    SEQUENCE OF MapRuleEntry
        MAX-ACCESS  not-accessible
        STATUS    current
        DESCRIPTION
            "The (conceptual) table containing rule Information of
            specific mapping rule. It can also be used for row
            creation."
        ::=  { mapRule 1 }

      mapRuleEntry OBJECT-TYPE
        SYNTAX    MapRuleEntry
        MAX-ACCESS  not-accessible
        STATUS    current

Fu, et al.              Expires December 19, 2015              [Page 5]
Internet-Draft      draft-ietf-softwire-map-mib-04            June 2015

        DESCRIPTION
            "Each entry in this table contains the information on a
            particular mapping rule."
            INDEX  { mapRuleID }
        ::=  { mapRuleTable 1 }

      MapRuleEntry  ::=
        SEQUENCE {
          mapRuleID                  Integer32,
          mapRuleIPv6PrefixType      InetAddressType,
          mapRuleIPv6Prefix          InetAddress,
          mapRuleIPv6PrefixLen        InetAddressPrefixLength,
          mapRuleIPv4PrefixType      InetAddressType,
          mapRuleIPv4Prefix          InetAddress,
          mapRuleIPv4PrefixLen        InetAddressPrefixLength,
          mapRulePSID                Integer32,
          mapRulePSIDLen              Integer32,
          mapRuleOffset              Unsigned32,
          mapRuleEALen                Integer32,
          mapRuleType                Integer32
      }

      mapRuleID OBJECT-TYPE
          SYNTAX Integer32 (1..2147483647)
          MAX-ACCESS not-accessible
          STATUS current
          DESCRIPTION
            "An identifier used to distinguish the multiple mapping
              rule which is unique with each CE in the same BR."
          ::= { mapRuleEntry 1 }

      mapRuleIPv6PrefixType OBJECT-TYPE
          SYNTAX    InetAddressType
          MAX-ACCESS read-create
          STATUS    current
          DESCRIPTION
            "In this object, it MUST be set to the value of 2 to
              present IPv6 type. It complies the textule convention
              of IPv6 address defined in [RFC4001]."
          ::= { mapRuleEntry 2 }

      mapRuleIPv6Prefix OBJECT-TYPE
          SYNTAX    InetAddress
          MAX-ACCESS read-create
          STATUS    current
          DESCRIPTION
            "The IPv6 prefix defined in mapping rule which will be
              assigned to CE ."

Fu, et al.              Expires December 19, 2015              [Page 6]
Internet-Draft      draft-ietf-softwire-map-mib-04            June 2015

          ::= { mapRuleEntry 3 }

      mapRuleIPv6PrefixLen OBJECT-TYPE
          SYNTAX    InetAddressPrefixLength
          MAX-ACCESS read-create
          STATUS    current
          DESCRIPTION
            "The length of the IPv6 prefix defined in the mapping rule.
              As a parameter for mapping rule, it will be also assigned
              to CE."
          ::= { mapRuleEntry 4 }

      mapRuleIPv4PrefixType OBJECT-TYPE
          SYNTAX    InetAddressType
          MAX-ACCESS read-create
          STATUS    current
          DESCRIPTION
            "In this object, it MUST be set to the value of 1 to
              present IPv4 type. It complies the textual convention
              of IPv6 address defined in [RFC4001]."
          ::= { mapRuleEntry 5 }

      mapRuleIPv4Prefix OBJECT-TYPE
          SYNTAX    InetAddress
          MAX-ACCESS read-create
          STATUS    current
          DESCRIPTION
            " The IPv4 prefix defined in mapping rule which will be
              assigned to CE."
          ::= { mapRuleEntry 6 }

      mapRuleIPv4PrefixLen OBJECT-TYPE
          SYNTAX    InetAddressPrefixLength
          MAX-ACCESS read-create
          STATUS    current
          DESCRIPTION
            "The length of the IPv4 prefix defined in the mapping
              rule. As a parameter for mapping rule, it will be also
              assigned to CE."
          ::= { mapRuleEntry 7 }

      mapRulePSID  OBJECT-TYPE
          SYNTAX    Integer32
          MAX-ACCESS read-create
          STATUS    current
          DESCRIPTION
            "The PSID value algorithmically identifies a set of
              ports assigned to a CE."

Fu, et al.              Expires December 19, 2015              [Page 7]
Internet-Draft      draft-ietf-softwire-map-mib-04            June 2015

          ::= { mapRuleEntry 8 }

      mapRulePSIDLen  OBJECT-TYPE
          SYNTAX    Integer32
          MAX-ACCESS read-create
          STATUS    current
          DESCRIPTION
            "The bit length value of the number of significant bits in
              the PSID field. When it is set to 0, the PSID
              field is to be ignored.."
          ::= { mapRuleEntry 9 }

      mapRuleOffset OBJECT-TYPE
          SYNTAX    Unsigned32(0..15)
          MAX-ACCESS read-create
          STATUS    current
          DESCRIPTION
            "Bit length value of the number of significant bits in
              the PSID field. When it is set to 0, the PSID
              field is to be ignored.."
          ::= { mapRuleEntry 10 }

      mapRuleEALen OBJECT-TYPE
          SYNTAX    Integer32
          MAX-ACCESS read-create
          STATUS    current
          DESCRIPTION
            "The length of the Embedded-Address (EA) defined in
              mapping rule which will be assigned to CE."
          ::= { mapRuleEntry 11 }

      mapRuleType OBJECT-TYPE
          SYNTAX    Integer32
          MAX-ACCESS read-create
          STATUS    current
          DESCRIPTION
            "The type of the mapping rule. A value of 0 means it
              is a BMR; a non-zero value means it is a FMR."
          ::= { mapRuleEntry 12 }

      mapSecurityCheckTable OBJECT-TYPE
        SYNTAX    SEQUENCE OF MapSecurityCheckEntry
        MAX-ACCESS  not-accessible
        STATUS    current
        DESCRIPTION
            "The (conceptual) table containing information on
            MAP security checks. This table can be used to statistic
            the number of invalid packets that been identified"

Fu, et al.              Expires December 19, 2015              [Page 8]
Internet-Draft      draft-ietf-softwire-map-mib-04            June 2015

        ::=  { mapSecurityCheck 1 }

      mapSecurityCheckEntry OBJECT-TYPE
        SYNTAX    MapSecurityCheckEntry
        MAX-ACCESS  not-accessible
        STATUS    current
        DESCRIPTION
            "Each entry in this table contains the information on a
            particular MAP SecurityCheck."
            INDEX  { ifIndex }
        ::=  { mapSecurityCheckTable 1 }

      MapSecurityCheckEntry  ::=
        SEQUENCE {
          mapSecurityCheckInvalidv4      Counter64,
          mapSecurityCheckInvalidv6      Counter64

      }

      mapSecurityCheckInvalidv4 OBJECT-TYPE
          SYNTAX    Counter64
          MAX-ACCESS accessible-for-notify
          STATUS    current
          DESCRIPTION
            "The CE SHOULD check that MAP received packets'
              transport-layer destination port number is in the range
              configured by MAP for the CE. So this object indicate
              the number of the invalid IPv4 packets received by the
              MAP."
          ::= { mapSecurityCheckEntry 1 }

      mapSecurityCheckInvalidv6 OBJECT-TYPE
          SYNTAX    Counter64
          MAX-ACCESS accessible-for-notify
          STATUS    current
          DESCRIPTION
            "The BR MUST perform a validation of the consistency of
              the source IPv6 address and source port number for the
              packet using BMR. So this object indicate the number of
              the invalid IPv6 packets received by the BR."
          ::= { mapSecurityCheckEntry 2 }

      -- Conformance Information
      mapMIBConformance OBJECT IDENTIFIER ::= {mapMIB 2}
      mapMIBCompliances OBJECT IDENTIFIER ::= { mapMIBConformance 1 }
      mapMIBGroups OBJECT IDENTIFIER ::= { mapMIBConformance 2 }

      -- compliance statements

Fu, et al.              Expires December 19, 2015              [Page 9]
Internet-Draft      draft-ietf-softwire-map-mib-04            June 2015

      mapMIBCompliance MODULE-COMPLIANCE
        STATUS current
        DESCRIPTION
            " Describes the minimal requirements for conformance
              to the MAP-E MIB."
        MODULE -- this module
            MANDATORY-GROUPS { mapMIBRuleGroup , mapMIBSecurityGroup }
        ::= { mapMIBCompliances 1 }

      -- Units of Conformance
      mapMIBRuleGroup OBJECT-GROUP
        OBJECTS {
                mapRuleIPv6PrefixType,
                mapRuleIPv6Prefix,
                mapRuleIPv6PrefixLen,
                mapRuleIPv4PrefixType,
                mapRuleIPv4Prefix,
                mapRuleIPv4PrefixLen,
                mapRulePSID,
                mapRulePSIDLen,
                mapRuleOffset,
                mapRuleEALen,
                mapRuleType  }
        STATUS current
        DESCRIPTION
            &RFC6987], [RFC2328], and [RFC5340].

[major]  [*]

This section says nothing!  rfc6987 has no Security Considerations to speak
of (sorry!)...rfc2328's Security Considerations only talk about
authentication, and there's no mention of rfc5709 or rfc7474...and rfc5340
doesn't apply because this document is not about OSPFv3 -- also, rfc5340
doesn't have specific Security Considerations related to the R-bit.



[*] I don't really have a SecDir hat...just pretending I do.

Suggestion: tell the reader why there are no new security considerations.
"This document introduces functionality to do a, b, and c...  Non of that
affects security..."  Of course, more words would be nice.

There is one specific item that I think should be mentioned as a risk.  §5
talks about using Auto Discovery "to avoid the possibility of any routing
loops due to partial deployment".  Even with proper authentication, there
is the possibility that a (rogue) router can advertise the Host Support
capability without really supporting it (there's no way to verify!!).  The
result can be a loop...  I don't think this issue can be mitigated, but
mentioning it would go a long way in demonstrating that you at least
thought about the issues.


...
279 10.1.  Normative References
...
290  [RFC3101]  Murphy, P., "The OSPF Not-So-Stubby Area (NSSA) Option",
291              RFC 3101, DOI 10.17487/RFC3101, January 2003,
292              ;.

294  [RFC5340]  Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF
295              for IPv6", RFC 5340, DOI 10.17487/RFC5340, July 2008,
296              ;.

[minor] These 2 references can be Informative.


...
307 10.2.  Informative References
...
319  [RFC6987]  Retana, A., Nguyen, L., Zinin, A., White, R., and D.
320              McPherson, "OSPF Stub Router Advertisement", RFC 6987,
321              DOI 10.17487/RFC6987, September 2013,
322              ;.

[major] Because of the specification of the use of MaxLinkMetric, this
reference has to be Normative.  rfc6987 is already in the DownRef registry.

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet
    Standard, Informational, Experimental, or Historic)? Why is this the
    proper type of RFC? Is this type of RFC indicated in the title page
    header?

      A Standards Track RFC is being requested and is indicated in the
      title page header.

(2) The IESG approval announcement includes a Document Announcement
    Write-Up.  Please provide such a Document Announcement Write-Up.
    Recent examples can be found in the "Action" announcements for
    approved documents. The approval announcement contains the following
    sections:

Technical Summary:
   
    This document defines a new router-LSA bit known as the Host Bit or the H-bit.
    An OSPFv2 router advertising a router-LSA with the H-bit set indicates to other
    OSPFv2 routers in the area supporting the functionality that it MUST NOT be used
    as a transit router. 

Working Group Summary:
 
    The Working Group has reached consensus that this document is useful and should
    be published.
     
Document Quality:
     
      The document has been implemented by xxxx.

Personnel:

      Yingzhen Qu is the Document Shepherd.
      Alvaro Retana is the Responsible Area Director.

(3) Briefly describe the review of this document that was performed by
    the Document Shepherd. If this version of the document is not ready
    for publication, please explain why the document is being forwarded
    to the IESG.

    The document shepherd has reviewed each revision of the document
    and followed the discussion on the OSPF/LSR mailing lists.


(4) Does the document Shepherd have any concerns about the depth or
    breadth of the reviews that have been performed?

      No.

(5) Do portions of the document need review from a particular or from
    broader perspective, e.g., security, operational complexity, AAA,
    DNS, DHCP, XML, or internationalization? If so, describe the review
    that took place.

      No.

(6) Describe any specific concerns or issues that the Document Shepherd
    has with this document that the Responsible Area Director and/or
    the IESG should be aware of? For example, perhaps he or she is
    uncomfortable with certain parts of the document, or has concerns
    whether there really is a need for it. In any event, if the WG has
    discussed those issues and has indicated that it still wishes to
    advance the document, detail those concerns here.

      None.

(7) Has each author confirmed that any and all appropriate IPR
    disclosures required for full conformance with the provisions of BCP
    78 and BCP 79 have already been filed. If not, explain why?

    NA.

(8) Has an IPR disclosure been filed that references this document? If
    so, summarize any WG discussion and conclusion regarding the IPR
    disclosures.
 
    No.

(9) 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?

      There is consensus from the WG that this document can progress.

(10) Has anyone threatened an appeal or otherwise indicated extreme
    discontent?  If so, please summarise the areas of conflict in
    separate email messages to the Responsible Area Director. (It
    should be in a separate email because this questionnaire is
    publicly available.)

      No.

(11) Identify any ID nits the Document Shepherd has found in this
    document.  (See http://www.ietf.org/tools/idnits/ and the
    Internet-Drafts Checklist).  Boilerplate checks are not enough;
    this check needs to be thorough.

      Nits are all resolved.

(12) Describe how the document meets any required formal review
    criteria, such as the MIB Doctor, media type, and URI type reviews.

      Not applicable.

(13) Have all references within this document been identified as either
    normative or informative?

      Yes.

(14) Are there normative references to documents that are not ready for
    advancement or are otherwise in an unclear state? If such
    normative references exist, what is the plan for their completion?
 
      No.

(15) Are there downward normative references references (see RFC 3967)?
    If so, list these downward references to support the Area Director
    in the Last Call procedure.

      No.

(16) Will publication of this document change the status of any existing
    RFCs?  Are those RFCs listed on the title page header, listed in
    the abstract, and discussed in the introduction? If the RFCs are
    not listed in the Abstract and Introduction, explain why, and point
    to the part of the document where the relationship of this document
    to the other RFCs is discussed. If this information is not in the
    document, explain why the WG considers it unnecessary.

The publication of this document will update RFC 2328. This
information has been listed on the title page header,
the Abstract, and Introduction.

(17) Describe the Document Shepherd's review of the IANA considerations
    section, especially with regard to its consistency with the body of
    the document.  Confirm that all protocol extensions that the
    document makes are associated with the appropriate reservations in
    IANA registries. Confirm that any referenced IANA registries have
    been clearly identified. Confirm that newly created IANA registries
    include a detailed specification of the initial contents for the
    registry, that allocations procedures for future registrations are
    defined, and a reasonable name for the new registry has been
    suggested (see RFC 5226).

This document requires an allocation of Host(H-bit) in OSPF
router-LSA bit registry.
It also requires to define a new Router Functional Capability
(RFC7770), the Host Support Functional Capability, from the Router
Functional Capability Bits TLV.

(18) List any new IANA registries that require Expert Review for future
    allocations. Provide any public guidance that the IESG would find
    useful in selecting the IANA Experts for these new registries.

      None.

(19) Describe reviews and automated checks performed by the Document
    Shepherd to validate sections of the document written in a formal
    language, such as XML code, BNF rules, MIB definitions, etc.

      Not applicable.