BGPsec Algorithms, Key Formats, and Signature Formats
draft-ietf-sidrops-bgpsec-algs-rfc8208-bis-05

[Ballot comment]
Hi

if this obsoletes 8208 then the iana registry looks fine.
If it is an update I see no reason to change the reference from 8208 to This Document for the identifiers 8208 had defined.

-m

[Ballot discuss]
Thanks to everyone who worked on this document.

This issue should be trivial to fix, but it's still a blocker.

§2.1:

>    Special-Use algorithm IDs span from 0xFA (250) to 0xFE (254).

§7:

>  In addition IANA is asked to register the following address space for
>  "Special-Use":
>
>    Algorithm  Digest          Signature      Specification
>    Suite      Algorithm      Algorithm      Pointer
>    Identifier
>  +------------+---------------+--------------+-----------------------+
>  | 0xFB-0xFE  | Special-Use  | Special-Use  | This Document        |
>  +------------+---------------+--------------+-----------------------+


The ranges here do not match ([0xFA-0xFE] != [0xFB-0xFE]). Presuming that the
text in Section 2.1 is what was intended, this issue impacts all of
the tables in section 7.

[Ballot discuss]
Thanks to everyone who worked on this document.

This issue should be trivial to fix, but it's still a blocker.

§2.1:

>    Special-Use algorithm IDs span from 0xFA (250) to 0xFE (254).

§7:

>  In addition IANA is asked to register the following address space for
>  "Special-Use":
>
>    Algorithm  Digest          Signature      Specification
>    Suite      Algorithm      Algorithm      Pointer
>    Identifier
>  +------------+---------------+--------------+-----------------------+
>  | 0xFB-0xFE  | Special-Use  | Special-Use  | This Document        |
>  +------------+---------------+--------------+-----------------------+


The ranges here do not match ([0xFA - 0xFE] != [0xFB-0xFE]). Presuming that the
text in Section 2.1 is what was intended, this issue impacts all of
the tables in section 7.

[Ballot comment]
I agree with Alexey's discuss.

---------------------------------------------------------------------------

§7:

>  To be modified to:
>
>    Algorithm  Digest          Signature      Specification
>    Suite      Algorithm      Algorithm      Pointer
>    Identifier
>  +------------+---------------+--------------+-----------------------+
>  | 0x2-0xFA  | Unassigned    | Unassigned  |                      |
>  +------------+---------------+--------------+-----------------------+

Nit: The prose has been updated to use "0x02" rather than "0x2". It would be
nice if the IANA section matched this update.

[Ballot comment]
Thanks for providing a BGPsec IPv6 example. I think it would be better if the next hop address comes out of the documentation range instead of the benchmarking range.

[Ballot comment]
Section 2.2.1

  Hash algorithms are not identified by themselves in certificates or
  BGPsec UPDATE messages.  They are represented by an OID that combines
  the hash algorithm with the digital signature algorithm as follows:

  o  The ecdsa-with-SHA256 OID [RFC5480] MUST appear in the Public-Key
      Cryptography Standards #10 (PKCS #10) signatureAlgorithm field
      [RFC2986] or in the Certificate Request Message Format (CRMF)
      POPOSigningKey algorithm field [RFC4211]; where the OID is placed
      depends on the certificate request format generated.

The first paragraph talks of "certificates" but this last sentence talks
about "certificate request"s.  Are we trying to talk about both?

Section 7

The IANA considerations are perhaps not as accurate as they could be.
For example, we could say that the BGPsec Algorithm Suite Registry was
originally created by RFC 8208 and has been updated to refer to this
document, and similarly for the P256-SHA256 codepoint.
(Just moving the references over would seem to be even more appropriate
if this document were fully Obsoleting 8208.)

Appendix A

Do we want to note that the certificates are expired but the examples
are still useful within that constraint?  (They were valid at the time
RFC 8208 was published but it seems imprudent to try to assume that the
examples would always be valid, when writing a document such as this.)

[Ballot comment]
Thank you for this easy to read update to RFC8208.  Below are a few editorial comments:

(1) Section 1. Editorial nit.
s/BGPsec uses a different algorithm [RFC6090] [DSS] as compared to the rest of the RPKI by using a different algorithm that provides similar security with smaller keys making the certificates smaller;/
BGPsec uses a different algorithm [RFC6090] [DSS] as compared to the rest of the RPKI that provides similar security with smaller keys making the certificates smaller;/

(2) Section 2.  Editorial nit.
s/This section addresses BGPsec algorithms; for example, these algorithms are used by BGPsec routers to sign and verify BGPsec UPDATE messages./
This section addresses the algorithms used by BGPSec [RFC6090] [DSS].  For examples, these algorithms are used by BGPSec routers to sign and verify BGPsec UPDATE messages./

(3) Section 2.  The sentence “To identify which algorithm is used, the BGPsec UPDATE message contains the corresponding algorithm ID in each Signature_Block of the BGPsec UPDATE message” seems redundant given that the first sentence of Section 2.1 says something very similar.

(4) Section 2.1. Editorial nit.  Make the use of constants here consistent with the description of “special-use Algo ID”.  s/0x00 and 0xFF/0x00 (0) and 0xFF (255)/

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

The IANA Functions Operator has completed its review of draft-ietf-sidrops-bgpsec-algs-rfc8208-bis-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.

The BGPsec Algorithm Suite Registry on the Resource Public Key Infrastructure (RPKI) registry page located at:

https://www.iana.org/assignments/rpki/

is to be modified.

Currently, the unassigned range in the registry is from 0x2-0xEF. This is to be changed to 0x2-0xFA.

A single assignment is to be made as follows:

Algorithm Suite Identifier: 0xFB-0xFE
Digest Algorithm: Special-use
Signature Algorithm: Special-use
Reference: [ RFC-to-be ]

The value 0xFF remains reserved and the reference is changed to [ RFC-to-be ].

[ RFC-to-be ] is to be added to the references for the only registration in the registry: 0x01 SHA-256.

IANA Question --> Are there any other places where the reference [RFC8208] should be changed/amended to [ RFC-to-be ]?

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 2019-03-18):

From: The IESG
To: IETF-Announce
CC: morrowc@ops-netman.net, draft-ietf-sidrops-bgpsec-algs-rfc8208-bis@ietf.org, sidrops@ietf.org, sidrops-chairs@ietf.org, Chris Morrow , warren@kumari.net
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (BGPsec Algorithms, Key Formats, and Signature Formats) to Proposed Standard


The IESG has received a request from the SIDR Operations WG (sidrops) to
consider the following document: - 'BGPsec Algorithms, Key Formats, and
Signature Formats'
  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
ietf@ietf.org mailing lists by 2019-03-18. 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


  This document specifies the algorithms, algorithm parameters,
  asymmetric key formats, asymmetric key sizes, and signature formats
  used in BGPsec (Border Gateway Protocol Security).  This document
  updates RFC 8208 ("BGPsec Algorithms, Key Formats, and Signature
  Formats") by adding Special-Use Algorithm IDs and correcting the
  range of unassigned algorithms IDs to fill the complete range.

  This document also includes example BGPsec UPDATE messages as well as
  the private keys used to generate the messages and the certificates
  necessary to validate those signatures.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-sidrops-bgpsec-algs-rfc8208-bis/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-sidrops-bgpsec-algs-rfc8208-bis/ballot/


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

quot; attribute MUST be used to
      identify the registrant or contact object if and only if the given
      authInfo is associated with a registrant or contact object, and
      not the domain object itself.  If this element is not provided or
      if the authorization information is invalid, server policy
      determines if the command is rejected or if response information
      will be returned to the client.

Hollenbeck                  Standards Track                    [Page 11]
RFC 4931                EPP Domain Name Mapping                May 2007

  Example <info> command without authorization information:

  C:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
  C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
  C:  <command>
  C:    <info>
  C:      <domain:info
  C:      xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
  C:        <domain:name hosts="all">example.com</domain:name>
  C:      </domain:info>
  C:    </info>
  C:    <clTRID>ABC-12345</clTRID>
  C:  </command>
  C:</epp>

  Example <info> command with authorization information:

  C:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
  C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
  C:  <command>
  C:    <info>
  C:      <domain:info
  C:      xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
  C:        <domain:name hosts="all">example.com</domain:name>
  C:        <domain:authInfo>
  C:          <domain:pw>2fooBAR</domain:pw>
  C:        </domain:authInfo>
  C:      </domain:info>
  C:    </info>
  C:    <clTRID>ABC-12345</clTRID>
  C:  </command>
  C:</epp>

  When an <info> command has been processed successfully, the EPP
  <resData> element MUST contain a child <domain:infData> element that
  identifies the domain namespace.  Elements that are not OPTIONAL MUST
  be returned; OPTIONAL elements are returned based on client
  authorization and server policy.  The <domain:infData> element
  contains the following child elements:

  -  A <domain:name> element that contains the fully qualified name of
      the domain object.

  -  A <domain:roid> element that contains the Repository Object
      IDentifier assigned to the domain object when the object was
      created.

Hollenbeck                  Standards Track                    [Page 12]
RFC 4931                EPP Domain Name Mapping                May 2007

  -  Zero or more OPTIONAL <domain:status> elements that contain the
      current status descriptors associated with the domain.

  -  If supported by the server, one OPTIONAL <domain:registrant>
      element and one or more OPTIONAL <domain:contact> elements that
      contain identifiers for the human or organizational social
      information objects associated with the domain object.

  -  An OPTIONAL <domain:ns> element that contains the fully qualified
      names of the delegated host objects or host attributes (name
      servers) associated with the domain object.  See Section 1.1 for a
      description of the elements used to specify host objects or host
      attributes.

  -  Zero or more OPTIONAL <domain:host> elements that contain the
      fully qualified names of the subordinate host objects that exist
      under this superordinate domain object.

  -  A <domain:clID> element that contains the identifier of the
      sponsoring client.

  -  An OPTIONAL <domain:crID> element that contains the identifier of
      the client that created the domain object.

  -  An OPTIONAL <domain:crDate> element that contains the date and
      time of domain object creation.

  -  An OPTIONAL <domain:exDate> element that contains the date and
      time identifying the end of the domain object's registration
      period.

  -  An OPTIONAL <domain:upID> element that contains the identifier of
      the client that last updated the domain object.  This element MUST
      NOT be present if the domain has never been modified.

  -  An OPTIONAL <domain:upDate> element that contains the date and
      time of the most recent domain object modification.  This element
      MUST NOT be present if the domain object has never been modified.

  -  An OPTIONAL &As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up.

Changes are expected over time. This version is dated 24 February 2012.

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


PROPOSED Standard

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

Technical Summary


  This document specifies the algorithms, algorithm parameters,
  asymmetric key formats, asymmetric key sizes, and signature formats
  used in BGPsec (Border Gateway Protocol Security).  This document
  updates RFC 8208 ("BGPsec Algorithms, Key Formats, and Signature
  Formats") by adding Special-Use Algorithm IDs and correcting the
  range of unassigned algorithms IDs to fill the complete range.

  This document also includes example BGPsec UPDATE messages as well as
  the private keys used to generate the messages and the certificates
  necessary to validate those signatures.



Working Group Summary

  Was there anything in WG process that is worth noting? For
  example, was there controversy about particular points or
  were there decisions where the consensus was particularly
  rough?

There was nothing in the WG review which was notable.

Document Quality

  Are there existing implementations of the protocol? Have a
  significant number of vendors indicated their plan to
  implement the specification? Are there any reviewers that
  merit special mention as having done a thorough review,
  e.g., one that resulted in important changes or a
  conclusion that the document had no substantive issues? If
  there was a MIB Doctor, Media Type or other expert review,
  what was its course (briefly)? In the case of a Media Type
  review, on what date was the request posted?


This is an update to the existing document, there was nothing super special here.
It's the specification of algorithms and parameters to those algorithms to be used in the
BGPSec protocol.

Personnel

  Who is the Document Shepherd? Who is the Responsible Area
  Director?

Document Shepherd: Chris Morrow (morrowc@ops-netman.net)
Responsible AD: Warren Kumari (warren@kumari.net)

(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 shepherd has read the original document, and this BIS document during it's lifetime.

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

no concerns


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


no

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

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


Yes, confirmation received.

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

none required.

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

as solid as sidr/sidrops ever is, yes.

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

no threats.

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

There are no significant nits in the document.
There are 2 downrefs which will be dealt with in auth48 timelines.

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

not necessary

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


yes

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

I don't believe so.

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


yes:
  ** Downref: Normative reference to an Informational RFC: RFC 2986
  ** Downref: Normative reference to an Informational RFC: RFC 6090

And these:
  -- Possible downref: Non-RFC (?) normative reference: ref. 'DSS'
  -- Possible downref: Non-RFC (?) normative reference: ref. 'SHS'

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

It will make rfc8208 deprecated in favor of the -bis which this document is, I believe.


(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 is an IANA considerations document with content, I believe there are requests to IANA
for updates to the registry:
  "BGPsec Algorithm Suite Registry"

to create a special-use block inside the registry, this is detailed in the document and appears clear,
to the shepherd.

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

none

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

no automated reviews required.

As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up.

Changes are expected over time. This version is dated 24 February 2012.

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


PRPOSED Standard

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

Technical Summary


  This document specifies the algorithms, algorithm parameters,
  asymmetric key formats, asymmetric key sizes, and signature formats
  used in BGPsec (Border Gateway Protocol Security).  This document
  updates RFC 8208 ("BGPsec Algorithms, Key Formats, and Signature
  Formats") by adding Special-Use Algorithm IDs and correcting the
  range of unassigned algorithms IDs to fill the complete range.

  This document also includes example BGPsec UPDATE messages as well as
  the private keys used to generate the messages and the certificates
  necessary to validate those signatures.



Working Group Summary

  Was there anything in WG process that is worth noting? For
  example, was there controversy about particular points or
  were there decisions where the consensus was particularly
  rough?

There was nothing in the WG review which was notable.

Document Quality

  Are there existing implementations of the protocol? Have a
  significant number of vendors indicated their plan to
  implement the specification? Are there any reviewers that
  merit special mention as having done a thorough review,
  e.g., one that resulted in important changes or a
  conclusion that the document had no substantive issues? If
  there was a MIB Doctor, Media Type or other expert review,
  what was its course (briefly)? In the case of a Media Type
  review, on what date was the request posted?


This is an update to the existing document, there was nothing super special here.
It's the specification of algorithms and parameters to those algorithms to be used in the
BGPSec protocol.

Personnel

  Who is the Document Shepherd? Who is the Responsible Area
  Director?

Document Shepherd: Chris Morrow (morrowc@ops-netman.net)
Responsible AD: Warren Kumari (warren@kumari.net)

(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 shepherd has read the original document, and this BIS document during it's lifetime.

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

no concerns


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


no

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

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


Yes, confirmation received.

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

none required.

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

as solid as sidr/sidrops ever is, yes.

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

no threats.

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

There are no significant nits in the document.
There are 2 downrefs which will be dealt with in auth48 timelines.

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

not necessary

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


yes

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

I don't believe so.

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


yes:
  ** Downref: Normative reference to an Informational RFC: RFC 2986
  ** Downref: Normative reference to an Informational RFC: RFC 6090

And these:
  -- Possible downref: Non-RFC (?) normative reference: ref. 'DSS'
  -- Possible downref: Non-RFC (?) normative reference: ref. 'SHS'

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

It will make rfc8208 deprecated in favor of the -bis which this document is, I believe.


(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 is an IANA considerations document with content, I believe there are requests to IANA
for updates to the registry:
  "BGPsec Algorithm Suite Registry"

to create a special-use block inside the registry, this is detailed in the document and appears clear,
to the shepherd.

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

none

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

no automated reviews required.

As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up.

Changes are expected over time. This version is dated 24 February 2012.

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


Internet Standard

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

Technical Summary


  This document specifies the algorithms, algorithm parameters,
  asymmetric key formats, asymmetric key sizes, and signature formats
  used in BGPsec (Border Gateway Protocol Security).  This document
  updates RFC 8208 ("BGPsec Algorithms, Key Formats, and Signature
  Formats") by adding Special-Use Algorithm IDs and correcting the
  range of unassigned algorithms IDs to fill the complete range.

  This document also includes example BGPsec UPDATE messages as well as
  the private keys used to generate the messages and the certificates
  necessary to validate those signatures.



Working Group Summary

  Was there anything in WG process that is worth noting? For
  example, was there controversy about particular points or
  were there decisions where the consensus was particularly
  rough?

There was nothing in the WG review which was notable.

Document Quality

  Are there existing implementations of the protocol? Have a
  significant number of vendors indicated their plan to
  implement the specification? Are there any reviewers that
  merit special mention as having done a thorough review,
  e.g., one that resulted in important changes or a
  conclusion that the document had no substantive issues? If
  there was a MIB Doctor, Media Type or other expert review,
  what was its course (briefly)? In the case of a Media Type
  review, on what date was the request posted?


This is an update to the existing document, there was nothing super special here.
It's the specification of algorithms and parameters to those algorithms to be used in the
BGPSec protocol.

Personnel

  Who is the Document Shepherd? Who is the Responsible Area
  Director?

Document Shepherd: Chris Morrow (morrowc@ops-netman.net)
Responsible AD: Warren Kumari (warren@kumari.net)

(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 shepherd has read the original document, and this BIS document during it's lifetime.

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

no concerns


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


no

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

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


Yes, confirmation received.

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

none required.

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

as solid as sidr/sidrops ever is, yes.

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

no threats.

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

There are no significant nits in the document.
There are 2 downrefs which will be dealt with in auth48 timelines.

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

not necessary

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


yes

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

I don't believe so.

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


yes:
  ** Downref: Normative reference to an Informational RFC: RFC 2986
  ** Downref: Normative reference to an Informational RFC: RFC 6090

And these:
  -- Possible downref: Non-RFC (?) normative reference: ref. 'DSS'
  -- Possible downref: Non-RFC (?) normative reference: ref. 'SHS'

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

It will make rfc8208 deprecated in favor of the -bis which this document is, I believe.


(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 is an IANA considerations document with content, I believe there are requests to IANA
for updates to the registry:
  "BGPsec Algorithm Suite Registry"

to create a special-use block inside the registry, this is detailed in the document and appears clear,
to the shepherd.

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

none

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

no automated reviews required.

As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up.

Changes are expected over time. This version is dated 24 February 2012.

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


Internet Standard

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

Technical Summary


  This document specifies the algorithms, algorithm parameters,
  asymmetric key formats, asymmetric key sizes, and signature formats
  used in BGPsec (Border Gateway Protocol Security).  This document
  updates RFC 8208 ("BGPsec Algorithms, Key Formats, and Signature
  Formats") by adding Special-Use Algorithm IDs and correcting the
  range of unassigned algorithms IDs to fill the complete range.

  This document also includes example BGPsec UPDATE messages as well as
  the private keys used to generate the messages and the certificates
  necessary to validate those signatures.



Working Group Summary

  Was there anything in WG process that is worth noting? For
  example, was there controversy about particular points or
  were there decisions where the consensus was particularly
  rough?

There was nothing in the WG review which was notable.

Document Quality

  Are there existing implementations of the protocol? Have a
  significant number of vendors indicated their plan to
  implement the specification? Are there any reviewers that
  merit special mention as having done a thorough review,
  e.g., one that resulted in important changes or a
  conclusion that the document had no substantive issues? If
  there was a MIB Doctor, Media Type or other expert review,
  what was its course (briefly)? In the case of a Media Type
  review, on what date was the request posted?


This is an update to the existing document, there was nothing super special here.
It's the specification of algorithms and parameters to those algorithms to be used in the
BGPSec protocol.

Personnel

  Who is the Document Shepherd? Who is the Responsible Area
  Director?

Document Shepherd: Chris Morrow (morrowc@ops-netman.net)
Responsible AD: Warren Kumari (warren@kumari.net)

(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 shepherd has read the original document, and this BIS document during it's lifetime.

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

no concerns


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


no

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

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


Yes, confirmation received.

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

none required.

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

as solid as sidr/sidrops ever is, yes.

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

no threats.

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

There are no significant nits in the document.
There are 2 downrefs which will be dealt with in auth48 timelines.

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

not necessary

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


yes

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

I don't believe so.

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


yes:
  ** Downref: Normative reference to an Informational RFC: RFC 2986
  ** Downref: Normative reference to an Informational RFC: RFC 6090

And these:
  -- Possible downref: Non-RFC (?) normative reference: ref. 'DSS'
  -- Possible downref: Non-RFC (?) normative reference: ref. 'SHS'

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

It will make rfc8208 deprecated in favor of the -bis which this document is, I believe.


(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 is an IANA considerations document with content, I believe there are requests to IANA
for updates to the registry:
  "BGPsec Algorithm Suite Registry"

to create a special-use block inside the registry, this is detailed in the document and appears clear,
to the shepherd.

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

none

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

no automated reviews required.