Skip to main content

Advertising IPv4 Network Layer Reachability Information (NLRI) with an IPv6 Next Hop
RFC 8950

Revision differences

Document history

Date Rev. By Action
2020-11-19
06 (System)
Received changes through RFC Editor sync (created alias RFC 8950, changed title to 'Advertising IPv4 Network Layer Reachability Information (NLRI) with an IPv6 Next …
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)
2020-11-19
06 (System) RFC published
2020-11-02
06 (System) RFC Editor state changed to <a href="http://www.rfc-editor.org/auth48/rfc8950">AUTH48</a> from RFC-EDITOR
2020-10-08
06 (System) IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor
2020-10-08
06 (System) IANA Action state changed to Waiting on RFC Editor from In Progress
2020-10-08
06 (System) IANA Action state changed to In Progress from Waiting on Authors
2020-09-15
06 (System) RFC Editor state changed to RFC-EDITOR from EDIT
2020-09-08
06 (System) IANA Action state changed to Waiting on Authors from In Progress
2020-09-03
06 (System) RFC Editor state changed to EDIT
2020-09-03
06 (System) IESG state changed to RFC Ed Queue from Approved-announcement sent
2020-09-03
06 (System) Announcement was received by RFC Editor
2020-09-03
06 (System) IANA Action state changed to In Progress
2020-09-03
06 Amy Vezza IESG state changed to Approved-announcement sent from Approved-announcement to be sent
2020-09-03
06 Amy Vezza IESG has approved the document
2020-09-03
06 Amy Vezza Closed "Approve" ballot
2020-09-03
06 Martin Vigoureux IESG state changed to Approved-announcement to be sent from IESG Evaluation::AD Followup
2020-09-03
06 Martin Vigoureux Ballot approval text was generated
2020-09-01
06 Murray Kucherawy
[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 …
[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.
2020-09-01
06 Murray Kucherawy [Ballot Position Update] Position for Murray Kucherawy has been changed to No Objection from Discuss
2020-09-01
06 Tim Chown Request for Telechat review by INTDIR Completed: Ready. Reviewer: Tim Chown. Sent review to list.
2020-09-01
06 Stephane Litkowski New version available: draft-ietf-bess-rfc5549revision-06.txt
2020-09-01
06 (System) New version approved
2020-09-01
06 (System)
Request for posting confirmation emailed to previous authors: Stephane Litkowski <slitkows@cisco.com>, Swadesh Agrawal <swaagraw@cisco.com>, Keyur Patel <keyur@arrcus.com>, krishnaswamy ananthamurthy …
Request for posting confirmation emailed to previous authors: Stephane Litkowski <slitkows@cisco.com>, Swadesh Agrawal <swaagraw@cisco.com>, Keyur Patel <keyur@arrcus.com>, krishnaswamy ananthamurthy <kriswamy@cisco.com>
2020-09-01
06 Stephane Litkowski Uploaded new revision
2020-08-31
05 (System) Sub state has been changed to AD Followup from Revised ID Needed
2020-08-31
05 (System) IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed
2020-08-31
05 Stephane Litkowski New version available: draft-ietf-bess-rfc5549revision-05.txt
2020-08-31
05 (System) New version approved
2020-08-31
05 (System)
Request for posting confirmation emailed to previous authors: Stephane Litkowski <slitkows@cisco.com>, krishnaswamy ananthamurthy <kriswamy@cisco.com>, Keyur Patel <keyur@arrcus.com>, Swadesh Agrawal …
Request for posting confirmation emailed to previous authors: Stephane Litkowski <slitkows@cisco.com>, krishnaswamy ananthamurthy <kriswamy@cisco.com>, Keyur Patel <keyur@arrcus.com>, Swadesh Agrawal <swaagraw@cisco.com>
2020-08-31
05 Stephane Litkowski Uploaded new revision
2020-08-27
04 Cindy Morgan IESG state changed to IESG Evaluation::Revised I-D Needed from IESG Evaluation
2020-08-27
04 Éric Vyncke
[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 …
[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
2020-08-27
04 Éric Vyncke Ballot comment text updated for Éric Vyncke
2020-08-27
04 Éric Vyncke
[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 …
[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
2020-08-27
04 Éric Vyncke [Ballot Position Update] New position, No Objection, has been recorded for Éric Vyncke
2020-08-26
04 Murray Kucherawy
[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 …
[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.
2020-08-26
04 Murray Kucherawy Ballot comment text updated for Murray Kucherawy
2020-08-26
04 Barry Leiba [Ballot comment]
I agree with Murray’s DISCUSS and Warren’s comment.
2020-08-26
04 Barry Leiba [Ballot Position Update] New position, No Objection, has been recorded for Barry Leiba
2020-08-26
04 Deborah Brungard [Ballot Position Update] New position, No Objection, has been recorded for Deborah Brungard
2020-08-26
04 Warren Kumari
[Ballot comment]
I found this document really hard to review - not because the document itself was unclear, but rather because I had to keep …
[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...
2020-08-26
04 Warren Kumari [Ballot Position Update] New position, No Objection, has been recorded for Warren Kumari
2020-08-26
04 Murray Kucherawy
[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 …
[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.
2020-08-26
04 Murray Kucherawy
[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 …
[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?"
2020-08-26
04 Murray Kucherawy [Ballot Position Update] New position, Discuss, has been recorded for Murray Kucherawy
2020-08-25
04 Martin Duke [Ballot Position Update] New position, No Objection, has been recorded for Martin Duke
2020-08-25
04 Amanda Baber IANA Review state changed to IANA OK - Actions Needed from IANA - Not OK
2020-08-25
04 Alissa Cooper [Ballot Position Update] New position, No Objection, has been recorded for Alissa Cooper
2020-08-24
04 Roman Danyliw [Ballot Position Update] New position, No Objection, has been recorded for Roman Danyliw
2020-08-24
04 Benjamin Kaduk
[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 …
[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.
2020-08-24
04 Benjamin Kaduk [Ballot Position Update] New position, No Objection, has been recorded for Benjamin Kaduk
2020-08-24
04 Alvaro Retana
[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 …
[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
2020-08-24
04 Alvaro Retana [Ballot Position Update] New position, No Objection, has been recorded for Alvaro Retana
2020-08-16
04 Erik Kline
[Ballot comment]
[[ comments ]]

[ section 3 ]

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

[ section …
[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"
2020-08-16
04 Erik Kline [Ballot Position Update] New position, No Objection, has been recorded for Erik Kline
2020-08-13
04 Bernie Volz Request for Telechat review by INTDIR is assigned to Tim Chown
2020-08-13
04 Bernie Volz Request for Telechat review by INTDIR is assigned to Tim Chown
2020-08-13
04 Éric Vyncke Requested Telechat review by INTDIR
2020-08-12
04 Cindy Morgan Placed on agenda for telechat - 2020-08-27
2020-08-12
04 Martin Vigoureux IESG state changed to IESG Evaluation from Waiting for Writeup
2020-08-12
04 Martin Vigoureux Ballot has been issued
2020-08-12
04 Martin Vigoureux [Ballot Position Update] New position, Yes, has been recorded for Martin Vigoureux
2020-08-12
04 Martin Vigoureux Created "Approve" ballot
2020-08-12
04 Martin Vigoureux Ballot writeup was changed
2020-08-12
04 Martin Vigoureux Ballot writeup was changed
2020-08-06
04 Tero Kivinen Closed request for Last Call review by SECDIR with state 'Overtaken by Events'
2020-08-06
04 Tero Kivinen Request for Last Call review by SECDIR Completed: Has Nits. Reviewer: Radia Perlman. Submission of review completed at an earlier date.
2020-07-26
04 Tero Kivinen Request for Last Call review by SECDIR Completed: Has Nits. Reviewer: Radia Perlman.
2020-07-24
04 Gunter Van de Velde Closed request for Last Call review by OPSDIR with state 'Overtaken by Events'
2020-07-21
04 (System) IESG state changed to Waiting for Writeup from In Last Call
2020-07-17
04 (System) IANA Review state changed to IANA - Not OK from IANA - Review Needed
2020-07-17
04 Sabrina Tanamal
(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 …
(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
2020-07-16
04 Tero Kivinen Request for Last Call review by SECDIR is assigned to Radia Perlman
2020-07-16
04 Tero Kivinen Request for Last Call review by SECDIR is assigned to Radia Perlman
2020-07-16
04 Carlos Pignataro Assignment of request for Last Call review by OPSDIR to Carlos Pignataro was rejected
2020-07-16
04 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Carlos Pignataro
2020-07-16
04 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Carlos Pignataro
2020-07-14
04 Adam Montville Assignment of request for Last Call review by SECDIR to Adam Montville was rejected
2020-07-10
04 Tero Kivinen Request for Last Call review by SECDIR is assigned to Adam Montville
2020-07-10
04 Tero Kivinen Request for Last Call review by SECDIR is assigned to Adam Montville
2020-07-09
04 Christer Holmberg Request for Last Call review by GENART Completed: Almost Ready. Reviewer: Christer Holmberg. Sent review to list.
2020-07-09
04 Jean Mahoney Request for Last Call review by GENART is assigned to Christer Holmberg
2020-07-09
04 Jean Mahoney Request for Last Call review by GENART is assigned to Christer Holmberg
2020-07-07
04 Cindy Morgan IANA Review state changed to IANA - Review Needed
2020-07-07
04 Cindy Morgan
The following Last Call announcement was sent out (ends 2020-07-21):<br><br>From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
CC: Matthew Bocci <matthew.bocci@nokia.com …
The following Last Call announcement was sent out (ends 2020-07-21):<br><br>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.




2020-07-07
04 Cindy Morgan IESG state changed to In Last Call from Last Call Requested
2020-07-07
04 Martin Vigoureux Last call was requested
2020-07-07
04 Martin Vigoureux Last call announcement was generated
2020-07-07
04 Martin Vigoureux Ballot approval text was generated
2020-07-07
04 Martin Vigoureux Ballot writeup was generated
2020-07-07
04 Martin Vigoureux IESG state changed to Last Call Requested from AD Evaluation::AD Followup
2020-07-07
04 Martin Vigoureux This document now replaces draft-litkowski-bess-rfc5549revision instead of draft-litkowski-bess-vpnv4-ipv6-nh-handling, draft-litkowski-bess-rfc5549revision
2020-07-07
04 Matthew Bocci
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 …
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.
2020-07-07
04 (System) Sub state has been changed to AD Followup from Revised ID Needed
2020-07-07
04 Stephane Litkowski New version available: draft-ietf-bess-rfc5549revision-04.txt
2020-07-07
04 (System) New version approved
2020-07-07
04 (System)
Request for posting confirmation emailed to previous authors: Keyur Patel <keyur@arrcus.com>, Swadesh Agrawal <swaagraw@cisco.com>, krishnaswamy ananthamurthy <kriswamy@cisco.com>, Stephane Litkowski …
Request for posting confirmation emailed to previous authors: Keyur Patel <keyur@arrcus.com>, Swadesh Agrawal <swaagraw@cisco.com>, krishnaswamy ananthamurthy <kriswamy@cisco.com>, Stephane Litkowski <slitkows@cisco.com>
2020-07-07
04 Stephane Litkowski Uploaded new revision
2020-07-07
03 Matthew Bocci This document now replaces draft-litkowski-bess-vpnv4-ipv6-nh-handling, draft-litkowski-bess-rfc5549revision instead of None
2020-07-07
03 Martin Vigoureux IESG state changed to AD Evaluation::Revised I-D Needed from AD Evaluation
2020-06-22
03 Martin Vigoureux IESG state changed to AD Evaluation from Publication Requested
2020-02-11
03 Amy Vezza Changed consensus to Yes from Unknown
2020-02-11
03 Amy Vezza Intended Status changed to Proposed Standard from None
2020-02-11
03 Matthew Bocci
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 …
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.
2020-02-11
03 Matthew Bocci Responsible AD changed to Martin Vigoureux
2020-02-11
03 Matthew Bocci IETF WG state changed to Submitted to IESG for Publication from WG Consensus: Waiting for Write-Up
2020-02-11
03 Matthew Bocci IESG state changed to Publication Requested from I-D Exists
2020-02-11
03 Matthew Bocci IESG process started in state Publication Requested
2020-02-11
03 Matthew Bocci Tag Doc Shepherd Follow-up Underway cleared.
2020-02-11
03 Matthew Bocci
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 …
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.
2020-02-11
03 Matthew Bocci
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 …
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.
2020-02-11
03 Stephane Litkowski New version available: draft-ietf-bess-rfc5549revision-03.txt
2020-02-11
03 (System) New version approved
2020-02-11
03 (System)
Request for posting confirmation emailed to previous authors: Stephane Litkowski <slitkows@cisco.com>, Keyur Patel <keyur@arrcus.com>, Swadesh Agrawal <swaagraw@cisco.com>, krishnaswamy ananthamurthy …
Request for posting confirmation emailed to previous authors: Stephane Litkowski <slitkows@cisco.com>, Keyur Patel <keyur@arrcus.com>, Swadesh Agrawal <swaagraw@cisco.com>, krishnaswamy ananthamurthy <kriswamy@cisco.com>
2020-02-11
03 Stephane Litkowski Uploaded new revision
2020-02-10
02 Stephane Litkowski New version available: draft-ietf-bess-rfc5549revision-02.txt
2020-02-10
02 (System) New version approved
2020-02-10
02 (System)
Request for posting confirmation emailed to previous authors: Stephane Litkowski <slitkows@cisco.com>, krishnaswamy ananthamurthy <kriswamy@cisco.com>, bess-chairs@ietf.org, Swadesh Agrawal <swaagrawa@cisco.com>, …
Request for posting confirmation emailed to previous authors: Stephane Litkowski <slitkows@cisco.com>, krishnaswamy ananthamurthy <kriswamy@cisco.com>, bess-chairs@ietf.org, Swadesh Agrawal <swaagrawa@cisco.com>, Keyur Patel <keyur@arrcus.com>
2020-02-10
02 Stephane Litkowski Uploaded new revision
2020-01-20
01 Matthew Bocci IETF WG state changed to WG Consensus: Waiting for Write-Up from WG Document
2020-01-20
01 Matthew Bocci Tag Doc Shepherd Follow-up Underway set.
2020-01-20
01 Matthew Bocci Notification list changed to Matthew Bocci <matthew.bocci@nokia.com>
2020-01-20
01 Matthew Bocci Document shepherd changed to Matthew Bocci
2020-01-17
01 Stephane Litkowski New version available: draft-ietf-bess-rfc5549revision-01.txt
2020-01-17
01 (System) New version approved
2020-01-17
01 (System)
Request for posting confirmation emailed to previous authors: Stephane Litkowski <slitkows@cisco.com>, krishnaswamy ananthamurthy <kriswamy@cisco.com>, Swadesh Agrawal <swaagrawa@cisco.com>, Keyur Patel …
Request for posting confirmation emailed to previous authors: Stephane Litkowski <slitkows@cisco.com>, krishnaswamy ananthamurthy <kriswamy@cisco.com>, Swadesh Agrawal <swaagrawa@cisco.com>, Keyur Patel <keyur@arrcus.com>
2020-01-17
01 Stephane Litkowski Uploaded new revision
2020-01-06
00 Stephane Litkowski New version available: draft-ietf-bess-rfc5549revision-00.txt
2020-01-06
00 (System) WG -00 approved
2020-01-06
00 Stephane Litkowski Set submitter to "Stephane Litkowski <slitkows@cisco.com>", replaces to (none) and sent approval email to group chairs: bess-chairs@ietf.org
2020-01-06
00 Stephane Litkowski Uploaded new revision