Subject: Re: [sidr] A Publication Protocol for the Resource Public Key Infrastructure -> WG

From: Christopher Morrow <[email-masked]>
Date: Tue, 14 Sep 2010 15:09:31 -0400

today is graveyard day...

Could the WG mailing-list folks discuss this for adoption please,
given no more discussion in the next 14 days we'll move ahead with
adopting it, I think.

-Chris
(wg-co-chair tie on)

On Sat, Jul 31, 2010 at 10:28 AM, Warren Kumari <[email-masked]> wrote:
> Hi there all,
>
> I am asking   that
> A Publication Protocol for the Resource Public Key Infrastructure
> (RPKI)
> draft-weiler-sidr-publication-00.txt ( http://tools.ietf.org/html/draft-weiler-sidr-publication-00 )
>
> become a working group item.
>
> W
> _______________________________________________
> sidr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sidr
>

---

From: Randy Bush <[email-masked]>
Date: Tue, 14 Sep 2010 15:14:36 -0400

> Could the WG mailing-list folks discuss this for adoption please,

i think we have been here before.  but clearly this should be a wg
draft.

randy

---

From: Warren Kumari <[email-masked]>
Date: Tue, 14 Sep 2010 15:23:31 -0400

Support (obviously)

W

---

From: Stephen Kent <[email-masked]>
Date: Wed, 15 Sep 2010 02:24:57 -0400

>given no more discussion in the next 14 days we'll move ahead with

I support adoption.

Steve

p.s.  Wow, a tie, how formal!

---

From: Andy Newton <[email-masked]>
Date: Wed, 15 Sep 2010 13:40:28 +0000

> today is graveyard day...

Since reanimation seems to be the theme, is draft-ietf-sidr-arch dead or undead? Its status is marked as expired.

Trying to get people to pay attention to the RPKI by referring to an expired draft is unhelpful. Is there another draft that is to take its place?

-andy

---

From: Andy Newton <[email-masked]>
Date: Wed, 15 Sep 2010 14:09:02 +0000

Forgive me if this is a bit naive, but I was under the impression that the use of rsync gave us this type of capability for free. It is not evident to me what benefit this protocol provides unless there is some desire to mesh together structures.

Additionally, from the operations considerations in Section 4:

   Placeholder section to talk about nesting children under parents in
   the sameso repository, to allow for a single rsync to fetch both
   (observing that the rsync setup times tends to dominate over the sync
   time).  And, more distressingly, talk about the access control
   impacts of that nesting.

Why isn't the rsync observation a general concern? Or is this statement an indication that this protocol is needed to get around a problem with rsync? If the latter is true, wouldn't it be better to address the cause of the problem rather than to route around it?

-andy

---

From: Samuel Weiler <[email-masked]>
Date: Wed, 15 Sep 2010 10:50:37 -0400 (EDT)

On Wed, 15 Sep 2010, Andy Newton wrote:

> Forgive me if this is a bit naive, but I was under the impression 
> that the use of rsync gave us this type of capability for free. It 
> is not evident to me what benefit this protocol provides unless 
> there is some desire to mesh together structures.

This is about consolidating publication points and (for some) avoiding 
running an rsync server.  It also reduces the number of rsync sessions 
needed to retrieve the whole PRKI.  Meshing structures, by which I 
assume you mean putting objects in a common directory structure, is 
necessary to the end, but isn't so much a goal in and of itself.

> Why isn't the rsync observation a general concern? Or is this 
> statement an indication that this protocol is needed to get around a 
> problem with rsync? If the latter is true, wouldn't it be better to 
> address the cause of the problem rather than to route around it?

rsync setup times are not a general concern because we're expecting to 
reduce the number of rsync sessions a relying party much use to fetch 
the whole RPKI down to something manageable.  Consolidating 
publication points serves several purposes and would probably be 
desirable even if the rsync problem were fixed.

>From an engineering standpoint, I think Rob, et. al. have taken the 
view that rsync is a take-it-or-leave it thing, slow setup included, 
and moving to an entirely different transport isn't worth the effort.

-- Sam

---

From: Christopher Morrow <[email-masked]>
Date: Wed, 15 Sep 2010 11:16:14 -0400

> Since reanimation seems to be the theme, is draft-ietf-sidr-arch dead or undead? Its status is marked as expired.

I think this fell down due to some other issues the authors were
chasing down Steve/Matt could confirm.

> Trying to get people to pay attention to the RPKI by referring to an expired draft is unhelpful. Is there another draft that is to take its place?

I believe this is supposed to not have expired, it was in WGLC...
there are 2 outstanding issues which I think require some conversation
between Geoff/Terry and the authors. Hopefully matt/stephen can work
those out, the last message on the WGLC call from Geoff ends with:

"Tickets #2, #6, #14 and #15 contain a record of the issues that have
been raised in these responses

I would like to request the document's authors to respond to these
issues, either in the tracker on on the mailing list, and revise the
document as considered necessary to address these review comments.

A further WGLC will be made on a revised version of this draft."

Stephen/Matt ? (it does seem that an architecture doc is required, and
this seems to just have slipped in priority)

-Chris

---

From: Rob Austein <[email-masked]>
Date: Wed, 15 Sep 2010 14:24:16 -0400

We're using rsync in read-only mode to pull data from repositories.
As far as I know nobody has seriously proposed using rsync to modify
repositories.  The publication protocol Sam documented is the one that
my implementation uses to add ("publish") and remove ("withdraw")
signed objects from a repository; most of the mechanism has to do with
access control, one way or another.

---

From: Andy Newton <[email-masked]>
Date: Thu, 16 Sep 2010 10:20:04 +0000

On Sep 15, 2010, at 10:50 AM, Samuel Weiler wrote:

> This is about consolidating publication points and (for some) avoiding running an rsync server.  It also reduces the number of rsync sessions needed to retrieve the whole PRKI.  Meshing structures, by which I assume you mean putting objects in a common directory structure, is necessary to the end, but isn't so much a goal in and of itself.

Thanks. That answers my question.

> rsync setup times are not a general concern because we're expecting to reduce the number of rsync sessions a relying party much use to fetch the whole RPKI down to something manageable.  Consolidating publication points serves several purposes and would probably be desirable even if the rsync problem were fixed.
> 
> From an engineering standpoint, I think Rob, et. al. have taken the view that rsync is a take-it-or-leave it thing, slow setup included, and moving to an entirely different transport isn't worth the effort.

I was simply trying to understand the observation, not restart the rsync vs. http discussion.

However, as I recall the stated reason for staying with rsync was that http would be less efficient. That is why I am surprized to see text stating there is a problem with rsync.

-andy