Subject: Re: [sidr] upcoming wg calls

From: "Sriram, Kotikalapudi" <[email-masked]>
Date: Thu, 2 Dec 2010 17:37:32 -0500

I support the last call of the following WG documents.

draft-ietf-sidr-roa-format-10
 draft-ietf-sidr-rpki-rtr-02
 draft-ietf-sidr-keyroll-04
 draft-ietf-sidr-res-certs-20
 draft-ietf-sidr-repos-struct-06
 draft-ietf-sidr-rescerts-provisioning-09
 draft-ietf-sidr-rpki-algs-04
 draft-ietf-sidr-rpki-manifests-09
 draft-ietf-sidr-roa-validation-10
 draft-ietf-sidr-signed-object-01
 draft-ietf-sidr-ta-06
 draft-ietf-sidr-arch-11

I support the adoption of the following items.

draft-rgaglian-sidr-algorithm-agility-00
draft-ymbk-ghostbusters-01
draft-ymbk-rpki-origin-ops-00

This draft is not ready for last call: draft-ietf-sidr-pfx-validate
Please see comments:
http://www.ietf.org/mail-archive/web/sidr/current/msg02204.html
I also request that it be an Informational RFC (rather than a standards track RFC)
just as draft-ietf-sidr-roa-validation already is. 
Please see comment (my reasons explained):
http://www.ietf.org/mail-archive/web/sidr/current/msg02203.html

Sriram

---

From: Randy Bush <[email-masked]>
Date: Fri, 03 Dec 2010 07:47:46 +0900

> http://www.ietf.org/mail-archive/web/sidr/current/msg02204.html

authors are looking at this

> I also request that it be an Informational RFC (rather than a
> standards track RFC) just as draft-ietf-sidr-roa-validation already
> is.

like hell.  it specifies what running code MUST do in routers.

randy

---

From: "Sriram, Kotikalapudi" <[email-masked]>
Date: Thu, 2 Dec 2010 19:46:06 -0500

Changed the subject title to refer to the document WGLC.
Please see comments inline. Thanks.

Sriram
> -----Original Message-----
> From: Randy Bush [mailto:[email-masked]]
> Sent: Thursday, December 02, 2010 5:48 PM
> 

Mapping the updates to Valid, Invalid, etc. based on ROA objects is 
an intermediate step to a final step of making a decision about path selection.
Both steps are internal to the router. If an ISP has leeway in the final step, 
then why should anything prevent it from having some leeway in the first step as well
(primarily during partial deployment)?
I am wondering what is lost if this is an Informational RFC?

---

From: Randy Bush <[email-masked]>
Date: Fri, 03 Dec 2010 10:00:31 +0900

> (primarily during partial deployment)?

when we move bgp best path decision to informational

1 2 3 4 5 6 7 8 9 10
1 2 3 4 5 6 7 8 9 10
1 2 3 4 5 6 7 8 9 10
1 2 3 4 5 6 7 8 9 10

nope.  didn't work.  sigh

randy

---

From: Sandra Murphy <[email-masked]>
Date: Tue, 7 Dec 2010 07:51:42 -0500 (Eastern Standard Time)

Sandy, speaking as Joan Q private citizen, wg member only, in civilian 
mufti:

With all due respect Sriram, I disagree.

On Thu, 2 Dec 2010, Sriram, Kotikalapudi wrote:

> Both steps are internal to the router.

There needs to be a common standard understanding of what the ROA means, 
in order for the signers to know what it means to produce a ROA.

>                                        If an ISP has leeway in the final step,

If the router has one degree of freedom in its action, is anything gained 
by having two?

> I am wondering what is lost if this is an Informational RFC?

Recognize that there is precedent for this - RFC 4271 standardizes the 
router's *internal* best path decision process.  I expect that the 
reasoning is the same - the decision process is standard so that those who 
are constructing BGP packets are operating with a standard understanding 
of what those packets mean.

--Sandy, with no particular ceremonial vestments or badges of rank donned.