Received changes through RFC Editor sync (created alias RFC 8950, changed title to 'Advertising IPv4 Network Layer Reachability Information (NLRI) with an IPv6 Next Hop', changed abstract to 'Multiprotocol BGP (MP-BGP) specifies that the set of usable next-hop address families is determined by the Address Family Identifier (AFI) and the Subsequent Address Family Identifier (SAFI). The AFI/SAFI definitions for the IPv4 address family only have provisions for advertising a next-hop address that belongs to the IPv4 protocol when advertising IPv4 Network Layer Reachability Information (NLRI) or VPN-IPv4 NLRI.

This document specifies the extensions necessary to allow the advertising of IPv4 NLRI or VPN-IPv4 NLRI with a next-hop address that belongs to the IPv6 protocol. This comprises an extension of the AFI/SAFI definitions to allow the address of the next hop for IPv4 NLRI or VPN-IPv4 NLRI to also belong to the IPv6 protocol, the encoding of the next hop to determine which of the protocols the address actually belongs to, and a BGP Capability allowing MP-BGP peers to dynamically discover whether they can exchange IPv4 NLRI and VPN-IPv4 NLRI with an IPv6 next hop. This document obsoletes RFC 5549.', changed pages to 12, changed standardization level to Proposed Standard, changed state to RFC, added RFC published event at 2020-11-19, changed IESG state to RFC Published, created obsoletes relation between draft-ietf-bess-rfc5549revision and RFC 5549)

[Ballot comment]
[DISCUSS cleared]

Thanks for this document.  It was easy to read even for people like me who don't get involved in routing too much.

Thank you also for the shepherd writeup, which (unlike most lately) actually answered the question "Why is this the proper type of RFC?"

I also concur with Warren's suggestion.

[Ballot comment]
Thank you for the work put into this document. I share Warren Kumari's point about the readability of the text.

About the lack of the 'bis' delta. I had to use https://tools.ietf.org/rfcdiff?url2=draft-ietf-bess-rfc5549revision-04.txt&url1=https://tools.ietf.org/rfc/rfc5549.txt to see them :-)

OTOH, it is easier for a new implementation to simply read the 'bis' document without going back and forth between the obsolete document and apply the diff.

-éric

[Ballot comment]
Thank you for the work put into this document. I partially share Warren Kumari's point about the readability of the text but lack of the 'bis' difference. I had to use
https://tools.ietf.org/rfcdiff?url2=draft-ietf-bess-rfc5549revision-04.txt&url1=https://tools.ietf.org/rfc/rfc5549.txt to see them :-)

OTOH, it is easier for a new implementation to simply read the 'bis' document without going back and forth between the obsolete document and apply the diff.

-éric

[Ballot comment]
Thanks for this document.  It was easy to read even for people like me who don't get involved in routing too much.

Thank you also for the shepherd writeup, which (unlike most lately) actually answered the question "Why is this the proper type of RFC?"

I also concur with Warren's suggestion.

[Ballot comment]
I found this document really hard to review - not because the document itself was unclear, but rather because I had to keep going back and forth between it and RFC5549.
Passing it though 'diff' helped some, but a few sentences explaining the differences would have helped immensely; it would also help RFC5549 implementers understand what they need to change to be compliant...

[Ballot discuss]
An easy one, but necessary IMHO:

I'm confused by the IANA Considerations section.  It looks like a verbatim copy from RFC 5549 which made the original registration for "Extended Next Hop Encoding", but this isn't actually a new registration.  Shouldn't this therefore be something like the following?

NEW:

RFC 5549 added "Extended Next Hop Encoding" to the Capability Codes registry, which was created by [RFC5492].  IANA is requested to update the definition of that entry to refer instead to this document.

[Ballot comment]
Thanks for this document.  It was easy to read even for people like me who don't get involved in routing too much.

Thank you also for the shepherd writeup, which (unlike most lately) actually answered the question "Why is this the proper type of RFC?"

[Ballot comment]
The IANA Considerations need to be updated to reflect that this is a
"bis" of 5549, and is not making the allocation de novo.  I.e., it
should be "update the reference for the existing registration".

RFC 5549 says that the "Length of Next Hop Address" field for AFI/SAFI
1/128 is "16 or 32", but this document says that it is "24 or 48", which
has no overlap.  Is this a breaking change?  Ah, I guess this is
essentially errata report 5253
(https://www.rfc-editor.org/errata/eid5253).  I'd suggest that we note
that this update includes addressing that errata report.

I would also suggest a brief note that the main nature of the update is
to add support for AFI/SAFI 1/129 (as that seems to be the bulk of the
diff between RFC 5549 and this document); I believe Alvaro has asked for
something similar as well.

Other than that, just a few very minor comments for your consideration
(and for which no reply is necessary).

Section 1

  There are situations such as those described in [RFC4925] and in
  [RFC5565] where carriers (or large enterprise networks acting as

nit: the transition into this paragraph is a bit abrupt, wth the
previous paragraphs talking about existing AFI/SAFIs that already are
flexible about IPv4 vs IPv6 based on length, but now we're back into
describing a problem statement for which the solution looks quite
similar.

Section 4

I'm happy to see that the format of the Capability Value field
explicitly indicates the NLRI AFI/SAFI and nexthop AFI triples
supported, so there is no deployability concern about using the same
capability code value to indicate support for new SAFI types.

Section 5

  When a next hop address needs to be passed along unchanged (e.g., as
  a Route Reflector (RR) would do), its encoding MUST NOT be changed.
  If a particular RR client cannot handle that encoding (as determined
  by the BGP Capability Advertisement), then the NLRI in question
  cannot be distributed to that client.  For sound routing in certain
  scenarios, this will require that all the RR clients be able to
  handle whatever encodings any of them may generate.

This is good advice; I wonder if it is worth a brief mention in the
security considerations as well.

Section 10.1

In my reading, the places where we reference RFC 4291 do not require it
to be a normative reference.

Section 10.2

I agree with Alvaro about draft-ietf-idr-dynamic-cap.

[Ballot comment]
(1) Security Considerations

The use of an IPv6 Next Hop opens up the possibility of diverting the traffic: there is no provision in this draft, or rfc2545, to validate or somehow verify that the address is "correct".  IOW, a rogue BGP speaker may use a Next Hop address to redirect the traffic elsewhere.  Traffic diversion is a known vulnerability, but I would still like to see something in this document about it.

Suggestion (borrowing from draft-ietf-idr-tunnel-encaps)>

  As [RFC4272] discusses, BGP is vulnerable to traffic diversion attacks.
  The ability to advertise an IPv6 Next Hop adds a new means by which an
  attacker could cause traffic to be diverted from its normal path.  Such an
  attack differs from pre-existing vulnerabilities in that traffic could be
  forwarded to a distant target across an intervening network infrastructure
  (e.g. an IPv6 core), allowing an attack to potentially succeed more
  easily, since less infrastructure would have to be subverted.  Potential
  consequences include "hijacking" of traffic or denial of service.



(2) §4:

  The Extended Next Hop Encoding capability MAY be dynamically updated
  through the use of the Dynamic Capability capability and associated
  mechanisms defined in [I-D.ietf-idr-dynamic-cap].

This text creates a Normative dependence on I-D.ietf-idr-dynamic-cap.  However, that document expired more than 8 years ago.  Please remove this paragraph.



(3) It would be very nice if a section summarizing the changes between this document and rfc5549 was included.


(4) rfc5549 was written more than 10 years ago...what qualified then as "current" and "new" doesn't anymore.  It would be nice to update some of that language.


(5) [nits]

s/IPV4/IPv4/g

s/allows advertising with [RFC4760] of an MP_REACH_NLRI with/allows advertising the MP_REACH_NLRI attribute [RFC4760] with this content

[Ballot comment]
[[ comments ]]

[ section 3 ]

* Perhaps "8-octet RD is set to zero" -> "8-octet RD set to zero"

[ section 4 ]

* Perhaps "for which there is already solution" ->
  "for which there is already a solution"

* "from the onset" -> "from the outset", I think

[ section 6.2 ]

* "IPV4" -> "IPv4"

[ section 6.3 ]

* "IPV4" -> "IPv4"

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

The IANA Functions Operator has completed its review of draft-ietf-bess-rfc5549revision-04. If any part of this review is inaccurate, please let us know.

The IANA Functions Operator has a question about one of the actions requested in the IANA Considerations section of this document.

The IANA Functions Operator understands that, upon approval of this document, there is a single action which we must complete.

In section 7 of the current draft, the IANA Considerations section states:

"This document defines, in Section 4, a new Capability Code to indicate the Extended Next Hop Encoding capability in the [RFC5492] Capabilities Optional Parameter. The value for this new Capability Code is 5, which is in the range set aside for allocation using the "IETF Review" policy defined in [RFC8126]."

IANA Question --> in the Capability Codes registry located at:

https://www.iana.org/assignments/capability-codes/

there is an existing registration for value: 5 (Extended Next Hop Encoding). Should the reference for this registration be changed to [ RFC-to-be ], or should [ RFC-to-be ] be added to the existing reference [RFC5549]?

The IANA Functions Operator understands that this is the only action 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 2020-07-21):

From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
CC: Matthew Bocci <matthew.bocci@nokia.com>, martin.vigoureux@nokia.com, matthew.bocci@nokia.com, bess-chairs@ietf.org, draft-ietf-bess-rfc5549revision@ietf.org, bess@ietf.org
Reply-To: last-call@ietf.org
Sender: <iesg-secretary@ietf.org>
Subject: Last Call: <draft-ietf-bess-rfc5549revision-04.txt> (Advertising IPv4 Network Layer Reachability Information with an IPv6 Next Hop) to Proposed Standard


The IESG has received a request from the BGP Enabled ServiceS WG (bess) to
consider the following document: - 'Advertising IPv4 Network Layer
Reachability Information with an IPv6
  Next Hop'
  <draft-ietf-bess-rfc5549revision-04.txt> 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 2020-07-21. 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


  Multiprotocol BGP (MP-BGP) specifies that the set of usable next-hop
  address families is determined by the Address Family Identifier (AFI)
  and the Subsequent Address Family Identifier (SAFI).  The current
  AFI/SAFI definitions for the IPv4 address family only have provisions
  for advertising a Next Hop address that belongs to the IPv4 protocol
  when advertising IPv4 Network Layer Reachability Information (NLRI)
  or VPN-IPv4 NLRI.  This document specifies the extensions necessary
  to allow advertising IPv4 NLRI or VPN-IPv4 NLRI with a Next Hop
  address that belongs to the IPv6 protocol.  This comprises an
  extension of the AFI/SAFI definitions to allow the address of the
  Next Hop for IPv4 NLRI or VPN-IPv4 NLRI to also belong to the IPv6
  protocol, the encoding of the Next Hop to determine which of the
  protocols the address actually belongs to, and a new BGP Capability
  allowing MP-BGP Peers to dynamically discover whether they can
  exchange IPv4 NLRI and VPN-IPv4 NLRI with an IPv6 Next Hop. This
  document obsoletes RFC5549.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-bess-rfc5549revision/



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

draft-ietf-bess-rfc5549revision-03.txt

Document Shepherd Write-Up

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

  Standards Track.
 
  This is appropriate as the draft describes a set of new procedures for advertising
  IPv4 network layer reachability with an IPv6 next hop. In addition to the procedures
  which must be followed for interoperability, it request a new protocol code point.

  The intended status is properly indicated.

(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

Multiprotocol BGP (MP-BGP) specifies that the set of usable
  next-hop address families is determined by the Address Family
  Identifier (AFI) and the Subsequent Address Family Identifier (SAFI).
  The current AFI/SAFI definitions for the IPv4 address family only
  have provisions for advertising a Next Hop address that belongs to
  the IPv4 protocol when advertising IPv4 Network Layer Reachability
  Information (NLRI) or VPN-IPv4 NLRI.  This document specifies the
  extensions necessary to allow advertising IPv4 NLRI or VPN-IPv4 NLRI
  with a Next Hop address that belongs to the IPv6 protocol.  This
  comprises an extension of the AFI/SAFI definitions to allow the
  address of the Next Hop for IPv4 NLRI or VPN-IPv4 NLRI to also belong
  to the IPv6 protocol, the encoding of the Next Hop to determine which
  of the protocols the address actually belongs to, and a new BGP
  Capability allowing MP-BGP Peers to dynamically discover whether they
  can exchange IPv4 NLRI and VPN-IPv4 NLRI with an IPv6 Next Hop.

Working Group Summary

  The document was developed as a response to an observed gap in the current specifications
  that did not reflect deployed implementations.
  The ability to advertise an IPv6 next hop in an IPv4/VPN-IPv4 NLRI is something
  that has been implemented and deployed and this document reflects the need to
  standardise the procedures to ensure future interoperability. It also introduces
  a new capability advertisement for this.
 
  This document was coordinated with the chairs of the IDR working group. It was progressed
  in the BESS working group since most applications for it reside within the charter
  of BESS.
   
  There are no IPR declarations on the draft .

     
Document Quality
   
  I have no concerns about the quality of the document. I believe it represents
  WG consensus, and it has been widely reviewed and discussed both on the list and in
  face-to-face meetings.

  The document does not specify any MIB changes or additions which would need
  review.

   
Personnel

  The document shepherd is Matthew Bocci (matthew.bocci@nokia.com).
  The responsible Area Director is Martin Vigoureux (martin.vigoureux@nokia.com).

(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 reviewed v01 of the document. I had no significant technical
  comments, but I did make some editorial comments that were resolved in
  version 02.

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

  No concerns. The document has received adequate review.

(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 further review required.

(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.

  No specific concerns.

(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.

  Each author listed in the Authors Addresses section has personally indicated that
  they are not aware of any IPR that has not already been declared in accordance
  with BCP 78 and 79.

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

  There are no IPR declarations on the draft.


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

    I am comfortable that the document represents WG consensus and has
    been reviewed by a reasonable number of active WG participants. It received a
    number of comments and significant discussion at IETF meetings. There were no
    objections during last call, and comments were constructive and supportive of moving
    the draft forward.
   
   

(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.)

  None indicated.

(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.

      ID-Nits passes.


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

  There are no relevant formal review criteria.

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

  Yes. All references are explicitly identified as informative or normative.

(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.

  This document obsoletes RFC 5549. It is properly indicated in the
  document header, the abstract and the 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).

  There are no IANA actions.

(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.

  There are no IANA actions.

(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.

  There are no sections containing formal language that needs reviewing.

draft-ietf-bess-rfc5549revision-03.txt

Document Shepherd Write-Up

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

  Standards Track.
 
  This is appropriate as the draft describes a set of new procedures for advertising
  IPv4 network layer reachability with an IPv6 next hop. In addition to the procedures
  which must be followed for interoperability, it request a new protocol code point.

  The intended status is properly indicated.

(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

Multiprotocol BGP (MP-BGP) specifies that the set of usable
  next-hop address families is determined by the Address Family
  Identifier (AFI) and the Subsequent Address Family Identifier (SAFI).
  The current AFI/SAFI definitions for the IPv4 address family only
  have provisions for advertising a Next Hop address that belongs to
  the IPv4 protocol when advertising IPv4 Network Layer Reachability
  Information (NLRI) or VPN-IPv4 NLRI.  This document specifies the
  extensions necessary to allow advertising IPv4 NLRI or VPN-IPv4 NLRI
  with a Next Hop address that belongs to the IPv6 protocol.  This
  comprises an extension of the AFI/SAFI definitions to allow the
  address of the Next Hop for IPv4 NLRI or VPN-IPv4 NLRI to also belong
  to the IPv6 protocol, the encoding of the Next Hop to determine which
  of the protocols the address actually belongs to, and a new BGP
  Capability allowing MP-BGP Peers to dynamically discover whether they
  can exchange IPv4 NLRI and VPN-IPv4 NLRI with an IPv6 Next Hop.

Working Group Summary

  The document was developed as a response to an observed gap in the current specifications
  that did not reflect deployed implementations.
  The ability to advertise an IPv6 next hop in an IPv4/VPN-IPv4 NLRI is something
  that has been implemented and deployed and this document reflects the need to
  standardise the procedures to ensure future interoperability. It also introduces
  a new capability advertisement for this.
 
  This document was coordinated with the chairs of the IDR working group. It was progressed
  in the BESS working group since most applications for it reside within the charter
  of BESS.
   
  There are no IPR declarations on the draft .

     
Document Quality
   
  I have no concerns about the quality of the document. I believe it represents
  WG consensus, and it has been widely reviewed and discussed both on the list and in
  face-to-face meetings.

  The document does not specify any MIB changes or additions which would need
  review.

   
Personnel

  The document shepherd is Matthew Bocci (matthew.bocci@nokia.com).
  The responsible Area Director is Martin Vigoureux (martin.vigoureux@nokia.com).

(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 reviewed v01 of the document. I had no significant technical
  comments, but I did make some editorial comments that were resolved in
  version 02.

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

  No concerns. The document has received adequate review.

(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 further review required.

(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.

  No specific concerns.

(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.

  Each author listed in the Authors Addresses section has personally indicated that
  they are not aware of any IPR that has not already been declared in accordance
  with BCP 78 and 79.

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

  There are no IPR declarations on the draft.


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

    I am comfortable that the document represents WG consensus and has
    been reviewed by a reasonable number of active WG participants. It received a
    number of comments and significant discussion at IETF meetings. There were no
    objections during last call, and comments were constructive and supportive of moving
    the draft forward.
   
   

(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.)

  None indicated.

(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.

      ID-Nits passes.


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

  There are no relevant formal review criteria.

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

  Yes. All references are explicitly identified as informative or normative.

(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.

  This document does not change the status of any existing RFCs.

(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).

  There are no IANA actions.

(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.

  There are no IANA actions.

(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.

  There are no sections containing formal language that needs reviewing.

draft-ietf-bess-rfc5549revision-03.txt

Document Shepherd Write-Up

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

  Standards Track.
 
  This is appropriate as the draft describes a set of new procedures for advertising
  IPv4 network layer reachability with an IPv6 next hop. In addition to the procedures
  which must be followed for interoperability, it request a new protocol code point.

  The intended status is properly indicated.

(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

Multiprotocol BGP (MP-BGP) specifies that the set of usable
  next-hop address families is determined by the Address Family
  Identifier (AFI) and the Subsequent Address Family Identifier (SAFI).
  The current AFI/SAFI definitions for the IPv4 address family only
  have provisions for advertising a Next Hop address that belongs to
  the IPv4 protocol when advertising IPv4 Network Layer Reachability
  Information (NLRI) or VPN-IPv4 NLRI.  This document specifies the
  extensions necessary to allow advertising IPv4 NLRI or VPN-IPv4 NLRI
  with a Next Hop address that belongs to the IPv6 protocol.  This
  comprises an extension of the AFI/SAFI definitions to allow the
  address of the Next Hop for IPv4 NLRI or VPN-IPv4 NLRI to also belong
  to the IPv6 protocol, the encoding of the Next Hop to determine which
  of the protocols the address actually belongs to, and a new BGP
  Capability allowing MP-BGP Peers to dynamically discover whether they
  can exchange IPv4 NLRI and VPN-IPv4 NLRI with an IPv6 Next Hop.

Working Group Summary

  The document was developed as a response to an observed gap in the current specifications
  that did not reflect deployed implementations.
  The ability to advertise an IPv6 next hop in an IPv4/VPN-IPv4 NLRI is something
  that has been implemented and deployed and this document reflects the need to
  standardise the procedures to ensure future interoperability. It also introduces
  a new capability advertisement for this.
 
  This document was coordinated with the chairs of the IDR working group. It was progressed
  in the BESS working group since most applications for it reside within the charter
  of BESS.
   
  There are no IPR declarations on the draft .

     
Document Quality
   
  I have no concerns about the quality of the document. I believe it represents
  WG consensus, and it has been widely reviewed and discussed both on the list and in
  face-to-face meetings.

  The document does not specify any MIB changes or additions which would need
  review.

   
Personnel

  The document shepherd is Matthew Bocci (matthew.bocci@nokia.com).
  The responsible Area Director is Martin Vigoureux (martin.vigoureux@nokia.com).

(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 reviewed v01 of the document. I had no significant technical
  comments, but I did make some editorial comments that were resolved in
  version 02.

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

  No concerns. The document has received adequate review.

(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 further review required.

(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.

  No specific concerns.

(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.

  Each author listed in the Authors Addresses section has personally indicated that
  they are not aware of any IPR that has not already been declared in accordance
  with BCP 78 and 79.

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

  There are no IPR declarations on the draft.


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

    I am comfortable that the document represents WG consensus and has
    been reviewed by a reasonable number of active WG participants. It received a
    number of comments and significant discussion at IETF meetings. There were no
    objections during last call, and comments were constructive and supportive of moving
    the draft forward.
   
   

(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.)

  None indicated.

(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.

      ID-Nits passes.


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

  There are no relevant formal review criteria.

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

  Yes. All references are explicitly identified as informative or normative.

(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.

  This document does not change the status of any existing RFCs.

(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).

  There are no IANA actions.

(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.

  There are no IANA actions.

(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.

  There are no sections containing formal language that needs reviewing.

draft-ietf-bess-rfc5549revision-03.txt

Document Shepherd Write-Up

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

  Standards Track.
 
  This is appropriate as the draft describes a set of new procedures for advertising
  IPv4 network layer reachability with an IPv6 next hop. In addition to the procedures
  which must be followed for interoperability, it request a new code point from a
  registry with an IETF review policy (requiring IETF Last Call).

  The intended status is properly indicated.

(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

Multiprotocol BGP (MP-BGP) specifies that the set of usable
  next-hop address families is determined by the Address Family
  Identifier (AFI) and the Subsequent Address Family Identifier (SAFI).
  The current AFI/SAFI definitions for the IPv4 address family only
  have provisions for advertising a Next Hop address that belongs to
  the IPv4 protocol when advertising IPv4 Network Layer Reachability
  Information (NLRI) or VPN-IPv4 NLRI.  This document specifies the
  extensions necessary to allow advertising IPv4 NLRI or VPN-IPv4 NLRI
  with a Next Hop address that belongs to the IPv6 protocol.  This
  comprises an extension of the AFI/SAFI definitions to allow the
  address of the Next Hop for IPv4 NLRI or VPN-IPv4 NLRI to also belong
  to the IPv6 protocol, the encoding of the Next Hop to determine which
  of the protocols the address actually belongs to, and a new BGP
  Capability allowing MP-BGP Peers to dynamically discover whether they
  can exchange IPv4 NLRI and VPN-IPv4 NLRI with an IPv6 Next Hop.

Working Group Summary

  The document was developed as a response to an observed gap in the current specifications
  that did not reflect deployed implementations.
  The ability to advertise an IPv6 next hop in an IPv4/VPN-IPv4 NLRI is something
  that has been implemented and deployed and this document reflects the need to
  standardise the procedures to ensure future interoperability. It also introduces
  a new capability advertisement for this.
 
  This document was coordinated with the chairs of the IDR working group. It was progressed
  in the BESS working group since most applications for it reside within the charter
  of BESS.
   
  There are no IPR declarations on the draft .

     
Document Quality
   
  I have no concerns about the quality of the document. I believe it represents
  WG consensus, and it has been widely reviewed and discussed both on the list and in
  face-to-face meetings.

  The document does not specify any MIB changes or additions which would need
  review.

   
Personnel

  The document shepherd is Matthew Bocci (matthew.bocci@nokia.com).
  The responsible Area Director is Martin Vigoureux (martin.vigoureux@nokia.com).

(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 reviewed v01 of the document. I had no significant technical
  comments, but I did make some editorial comments that were resolved in
  version 02.

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

  No concerns. The document has received adequate review.

(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 further review required.

(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.

  No specific concerns.

(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.

  Each author listed in the Authors Addresses section has personally indicated that
  they are not aware of any IPR that has not already been declared in accordance
  with BCP 78 and 79.

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

  There are no IPR declarations on the draft.


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

    I am comfortable that the document represents WG consensus and has
    been reviewed by a reasonable number of active WG participants. It received a
    number of comments and significant discussion at IETF meetings. There were no
    objections during last call, and comments were constructive and supportive of moving
    the draft forward.
   
   

(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.)

  None indicated.

(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.

      ID-Nits passes.


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

  There are no relevant formal review criteria.

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

  Yes. All references are explicitly identified as informative or normative.

(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.

  This document does not change the status of any existing RFCs.

(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).

  There are no IANA actions.

(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.

  There are no IANA actions.

(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.

  There are no sections containing formal language that needs reviewing.