Resource Public Key Infrastructure (RPKI) Objects Issued by IANA
draft-ietf-sidr-iana-objects-03

[Ballot discuss]
For administrative reasons I am adopting Alexey's Discuss

========

I am planning to ballot Yes on this document once my issues are discussed.

I have a couple of discussion point for IESG which might or might result in some
actions for editors.

2) DISCUSS DISCUSS

5.  Reserved Resources

  Reserved IPv4 and IPv6 resources are held back for various reasons by
  IETF action.  Generally such resources are not intended to be
  globally routed.  An example of such a reservation is 127.0.0.0/8
  [RFC5735].

  IANA SHOULD issue an AS0 ROA for all reserved IPv4 and IPv6 resources
  not intended to be routed.

Is IANA clear on where (in which RFCs) all such resources are described?
The reference to [RFC5735] makes me think that it is only one example.

  There are a small number of reserved resources which are intended to
  be routed, for example 192.88.99.0/24 [RFC3068].

As above.

  IANA MUST NOT issue any ROAs (AS0 or otherwise) for reserved
  resources that are expected to be globally routed.

Comment (2011-03-17)

I feel much better about approving this document after reading draft-ietf-sidr-
arch-12.txt. So I am moving my DISCUSS DISCUSS # 1 to the Comment section:

1) DISCUSS DISCUSS:

This document has lots of normative references to documents, some of which are
not yet in IETF LC. I do feel that all of them actually need to be reviewed
before approving this document, so I find it strange that this document is in
IESG review first.

I understand that I've done similar out-of-order IESG processing for some of my
documents, so I don't claim to have a high moral ground here. However I would
like to hear some explanation of why such exception is Ok in this case.

=======

[Ballot comment]
What kind of change/CRL/processing load is expected from certification of unallocated space at IANA, as that space keeps changing (in the case IPv6)?

From Ari Keränen's review:

8.  Multicast

  IANA MUST NOT issue any ROAs (AS0 or otherwise) for any other
  multicast addresses unless directed.

Directed by whom? Need to have, e.g., IESG Approval?

[Ballot discuss]
Section 8 has a MUST (see below for more details) that is not fully specified.  The document should make it clear who can make exceptions on making ROAs for multicast addresses.

[Ballot comment]
From Ari Keränen's review:

8.  Multicast

  IANA MUST NOT issue any ROAs (AS0 or otherwise) for any other
  multicast addresses unless directed.

Directed by whom? Need to have, e.g., IESG Approval?

[Ballot discuss]
I am planning to ballot Yes on this document once my issues are discussed.

I have a couple of discussion point for IESG which might or might result in some actions for editors.

2) DISCUSS DISCUSS

5.  Reserved Resources

  Reserved IPv4 and IPv6 resources are held back for various reasons by
  IETF action.  Generally such resources are not intended to be
  globally routed.  An example of such a reservation is 127.0.0.0/8
  [RFC5735].

  IANA SHOULD issue an AS0 ROA for all reserved IPv4 and IPv6 resources
  not intended to be routed.

Is IANA clear on where (in which RFCs) all such resources are described?
The reference to [RFC5735] makes me think that it is only one example.

  There are a small number of reserved resources which are intended to
  be routed, for example 192.88.99.0/24 [RFC3068].

As above.

  IANA MUST NOT issue any ROAs (AS0 or otherwise) for reserved
  resources that are expected to be globally routed.

[Ballot comment]
I feel much better about approving this document after reading draft-ietf-sidr-arch-12.txt. So I am moving my DISCUSS DISCUSS # 1 to the Comment section:

1) DISCUSS DISCUSS:

This document has lots of normative references to documents, some of which are not yet in IETF LC. I do feel that all of them actually need to be reviewed before approving this document, so I find it strange that this document is in IESG review first.

I understand that I've done similar out-of-order IESG processing for some of my documents, so I don't claim to have a high moral ground here. However I would like to hear some explanation of why such exception is Ok in this case.

[Ballot discuss]
I have a couple of discussion point for IESG which might or might result in some actions for editors.

2) DISCUSS DISCUSS

5.  Reserved Resources

  Reserved IPv4 and IPv6 resources are held back for various reasons by
  IETF action.  Generally such resources are not intended to be
  globally routed.  An example of such a reservation is 127.0.0.0/8
  [RFC5735].

  IANA SHOULD issue an AS0 ROA for all reserved IPv4 and IPv6 resources
  not intended to be routed.

Is IANA clear on where (in which RFCs) all such resources are described?
The reference to [RFC5735] makes me think that it is only one example.

  There are a small number of reserved resources which are intended to
  be routed, for example 192.88.99.0/24 [RFC3068].

As above.

  IANA MUST NOT issue any ROAs (AS0 or otherwise) for reserved
  resources that are expected to be globally routed.

[Ballot comment]
I support Alexey's DISCUSS and I have one supplementary question concerning the following paragraph in Section 5:

>    IANA SHOULD issue an AS0 ROA for all reserved IPv4 and IPv6 resources
  not intended to be routed.

Why is this a should? Why not a MUST? If there are exceptions does IANA know and understand all cases when they apply?

[Ballot comment]
A document providing "specific direction to IANA" (and for which an interop statement is never going to make sense) would fit better as a BCP - why was PS chosen instead?

[Ballot discuss]
I have a couple of discussion point for IESG which might or might result in some actions for editors.

1) DISCUSS DISCUSS:

This document has lots of normative references to documents, some of which are not yet in IETF LC. I do feel that all of them actually need to be reviewed before approving this document, so I find it strange that this document is in IESG review first.

I understand that I've done similar out-of-order IESG processing for some of my documents, so I don't claim to have a high moral ground here. However I would like to hear some explanation of why such exception is Ok in this case.

2) DISCUSS DISCUSS

5.  Reserved Resources

  Reserved IPv4 and IPv6 resources are held back for various reasons by
  IETF action.  Generally such resources are not intended to be
  globally routed.  An example of such a reservation is 127.0.0.0/8
  [RFC5735].

  IANA SHOULD issue an AS0 ROA for all reserved IPv4 and IPv6 resources
  not intended to be routed.

Is IANA clear on where (in which RFCs) all such resources are described?
The reference to [RFC5735] makes me think that it is only one example.

  There are a small number of reserved resources which are intended to
  be routed, for example 192.88.99.0/24 [RFC3068].

As above.

  IANA MUST NOT issue any ROAs (AS0 or otherwise) for reserved
  resources that are expected to be globally routed.

[Ballot discuss]
I have a couple of discussion point for IESG which might or might result in some actions for editors.

1) DISCUSS DISCUSS:

This document has lots of normative references to document, some of which are not yet in IETF LC. I do feel that all of them actually need to be reviewed before approving this document, so I find it strange that this document is in IESG review first.

2) DISCUSS DISCUSS

5.  Reserved Resources

  Reserved IPv4 and IPv6 resources are held back for various reasons by
  IETF action.  Generally such resources are not intended to be
  globally routed.  An example of such a reservation is 127.0.0.0/8
  [RFC5735].

  IANA SHOULD issue an AS0 ROA for all reserved IPv4 and IPv6 resources
  not intended to be routed.

Is IANA clear on where (in which RFCs) all such resources are described?
The reference to [RFC5735] makes me think that it is only one example.

  There are a small number of reserved resources which are intended to
  be routed, for example 192.88.99.0/24 [RFC3068].

As above.

  IANA MUST NOT issue any ROAs (AS0 or otherwise) for reserved
  resources that are expected to be globally routed.

IANA notes that the IANA Actions related to this document have been
reviewed in detail with IANA staff. IANA also understands that, upon
approval of this document, the instructions contained in the body of
this document represent all of the IANA Actions required upon approval
of this draft.

IANA understands that there are no other actions required upon approval
of this document.

State changed to In Last Call from Last Call Requested.

The following Last Call Announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Subject: Last Call:  (RPKI Objects issued by IANA) to Proposed Standard


The IESG has received a request from the Secure Inter-Domain Routing WG
(sidr) to consider the following document:
- 'RPKI Objects issued by IANA'
  as a 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 2011-03-03. 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.

The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-sidr-iana-objects/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-sidr-iana-objects/

This draft has the following downrefs:


  ** Downref: Normative reference to an Informational draft:
    draft-ietf-sidr-arch (ref. 'I-D.ietf-sidr-arch')

  ** Downref: Normative reference to an Informational draft:
    draft-ietf-sidr-roa-validation (ref. 'I-D.ietf-sidr-roa-validation')

  ** Downref: Normative reference to an Informational RFC: RFC 2860

  ** Downref: Normative reference to an Informational RFC: RFC 3849

  ** Downref: Normative reference to an Informational RFC: RFC 5180

  ** Downref: Normative reference to an Informational RFC: RFC 5736

(1.a) Chris Morrow is the document shephard for this document. I have
personally reviewed this version of the document and, I believe this
version is ready for forwarding to the IESG for publication.

(1.b) The document has had adequate review both from key WG members
and from key non-WG members? The Document Shepherd does not have
any concerns about the depth or breadth of the reviews that
have been performed?

(1.c) The Document Shepherd does not have concerns that the document
needs more review from a particular or broader perspective.

(1.d) The Document Shepherd does not have any specific concerns or
issues with this document that the Responsible Area Director
and/or the IESG should be aware of.

(1.e) The WG consensus seems solid for this document.

(1.f) No one has threatened an appeal or otherwise indicated extreme
discontent.

(1.g) The Document Shepherd personally verified that the
document satisfies all ID nits. (NOTE: however the nits doc archive
seems to be back a few revs on some docs, I show rsync'd copies
of the subject drafts at the proper revisions, however.)

(1.h) The document has split its references into normative and
informative. There are a few down-rev references, all of which
are for documents either in IESG review or headed there shortly.

(1.i) The Document Shepherd has verified that the document IANA
consideration section exists and is consistent with the body
of the document.

(1.j) The Document Shepherd has verified that sections of the
document that are written in a formal language, such as XML
code, BNF rules, MIB definitions, etc., validate correctly in
an automated checker.

(1.k) 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 provides specific direction to IANA as to the Resource
Public Key Infrastructure (RPKI) objects it should issue.

Working Group Summary
Nothing of note happened in the WG discussion of this document.

Document Quality
The document seems fine, the IANA function will have some work to do
as a direct result of this document and the RPKI system as a whole.
(this is expected and required behavior though)