Subject: [sidr] WGLC - draft-manderson-iana-objects-03.txt

From: Christopher Morrow <[email-masked]>
Date: Wed, 9 Feb 2011 19:38:35 -0500

<wg-co-chair-airplane-seat == on>
Since no one else spoke up, let's make this quick:

WGLC, to end Feb 11 2011 23:59 UTC

please make your feelings known quickly, this seems like a
non-controversial document, so quick reaction/turn-around would be
helpful.

-Chris
</wg-co-chair-airplane-seat == off>

---

From: Stephen Kent <[email-masked]>
Date: Thu, 10 Feb 2011 13:32:00 -0500

></wg-co-chair-airplane-seat == off>

I'm in favor (but, then, I'm a co-author ...).

Steve

---

From: Terry Manderson <[email-masked]>
Date: Thu, 10 Feb 2011 15:30:50 -0800

with author hat stylishly tilted to one side.

The doc can be found at:

http://tools.ietf.org/html/draft-ietf-sidr-iana-objects-00

Cheers
Terry

---

From: Sean Turner <[email-masked]>
Date: Thu, 10 Feb 2011 20:31:28 -0500

Lots of hats in this WG... With my nit-noid checker hat on ;)

- Should this be a BCP or standards track?

- Expand RPKI in abstract and introduction

- Sec 2: r/description od/description of

- Sec 3: r/, [I-D.ietf-sidr-rpki-manifests]./
            , and [I-D.ietf-sidr-rpki-manifests].

- Add informative references to IPv4 [RFC793] and IPv6 [RFC2460] either 
in Section 2 or 4.

[RFC791] Postel, J. (ed.), "Internet Protocol - DARPA Internet
          Program Protocol Specification", RFC 791, September 1981.

[RFC2460] Deering, S., and R. Hinden, "Internet Protocol, Version
           6 (IPv6) Specification," RFC 2460, December 1998.

- It might be worth noting why this draft uses non-RFC 3849/5735/5771 
compliant addresses.  It'll stop somebody who uses the nit checker from 
asking the question and possibly slowing down publication (think genart, 
secdir, or IESG member).  From the nit checker:

  == There are 2 instances of lines with non-RFC5735-compliant IPv4
     addresses in the document.  If these are example addresses, they
     should be changed.

  == There are 4 instances of lines with multicast IPv4 addresses in the
     document.  If these are generic example addresses, they should be
     changed to use the 233.252.0.x range defined in RFC 5771

  == There are 1 instance of lines with non-RFC3849-compliant IPv6
     addresses in the document.  If these are example addresses, they
     should be changed.

- Sec 5: Missing some periods:
          r/[RFC5735]/[RFC5735].
          r/routed/routed.
          r/[RFC3068]/[RFC3068].

- Sec 5: r/IANA should/IANA SHOULD

- Sec 6/7/8: Should "IANA MUST refrain" be "IANA MUST NOT"?

- Sec 7: r/[RFC5180]/[RFC5180].

- Sec 10: If IANA is going to stand up the CA it's going to need to 
write the CPS that says how it does all the things the CP says it needs to.

spt

On 2/10/11 6:30 PM, Terry Manderson wrote:
> On 10/02/11 10:38 AM, "Christopher Morrow"<[email-masked]>
> wrote:
>
> _______________________________________________
> sidr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sidr
>

---

From: Terry Manderson <[email-masked]>
Date: Thu, 10 Feb 2011 18:14:27 -0800

Hi Sean,

Thank you for your careful review.

> - Should this be a BCP or standards track?

To me this sits in BCP space, it really describes the best action IANA
should follow for dealing with issuing RPKI objects for the unallocated,
reserved, and special use blocks. It doesn't define or redefine any existing
RPKI structures.

>             , and [I-D.ietf-sidr-rpki-manifests].

Thanks, Will fix.

>            6 (IPv6) Specification," RFC 2460, December 1998.

Thanks, will add.

>      addresses in the document.  If these are example addresses, they

None of the addresses are example addresses. They are specific to the
resources and the expected RPKI objects in question.

> - Sec 5: Missing some periods:

Thanks. Will fix.

> - Sec 7: r/[RFC5180]/[RFC5180].

Thanks. Will fix.

> write the CPS that says how it does all the things the CP says it needs to.

Correct. Although my take on that is it's an acquired effort of running the
RPKI Unallocated/reserved/special-use CA and need not be specified here. I
also didn't see the need to refer to one of the CPS templates.

Is my thinking misaligned here?

Apart from the last open item, would you be ok if I made the changes prior
to IESG submission instead of cutting another revision.

Cheers
Terry

---

From: Sean Turner <[email-masked]>
Date: Fri, 11 Feb 2011 10:39:55 -0500

> Thank you for your careful review.

Purely selfish on my part ;)  Turns out to be less email now rather than 
later.

> On 11/02/11 11:31 AM, "Sean Turner"<[email-masked]>  wrote:
>

ack - second para of 2026.

..snip

> resources and the expected RPKI objects in question.

Yep that's my point.  If you put something in like:

NOTE: The addresses used in this document are not example addresses 
therefore they are not compliant with RFC 3849, 5735, and 5771.  This is 
intentional as the practices described in this document affect real 
world addresses.

Or something like that.  But then again maybe that's clear to everybody 
and I'm in the rough.

..snip

> Is my thinking misaligned here?

Yeah I was just trying to complete the list of things they'd need to do, 
but I guess that list is quite long and when complying with the CP 
they'll need to do a CPS.  Since the CP reference is already in there 
then there's probably nothing more that needs to be added about the CPS.

> to IESG submission instead of cutting another revision.

That's fine by me.

spt

---

From: Christopher Morrow <[email-masked]>
Date: Fri, 11 Feb 2011 21:19:15 -0500

>> to IESG submission instead of cutting another revision.

alright... so once these changes are done I think we're out of WGLC,
eh? (I presume terry sends a sample set back to sean, but that's
hidden from us, and fine).

Terry/Sean please let us know when the sausage is made?

-Chris
</co-chair-socks == off>