Subject: [sidr] Terry Manderson's No Objection on draft-ietf-sidr-delta-protocol-07: (with COMMENT)

From: "Terry Manderson" <[email-masked]>
Date: Wed, 15 Feb 2017 18:03:19 -0800

Terry Manderson has entered the following ballot position for
draft-ietf-sidr-delta-protocol-07: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-sidr-delta-protocol/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thank you for this work, it is clear and well written. While I have never
(ever) been enamoured by RSYNC, and I much prefer this direction on a
personal level, the updates to the existing RFCs regarding RSYNC does two
things. The first is it demotes RSYNC to 'just another access mechanism',
and the second is it appears to remove the quality of a mandatory to
implement retrieval mechanism. Am I reading that correctly? If this is
intentional and has workgroup consensus so be it and onwards we move..

---

From: Tim Bruijnzeels <[email-masked]>
Date: Thu, 16 Feb 2017 16:17:33 +0100

Hi Terry, all,

> On 16 Feb 2017, at 03:03, Terry Manderson <[email-masked]> wrote:
> 

Initially this was written as an additional protocol, next to rsync. The idea was that rsync would be replaced altogether at some point, but the way to get there was intentionally left out of this document because we felt it should just focus on protocol.

The changes you mention were made following AD review comments on 7 January. The intent as I understood it was to defer the question which retrieval mechanism is mandatory to another document, but leave the specifications generic. 

In itself I understood that this is okay. Because current deployment can follow the unaltered specifications. It does leave the question of defining this better for future implementation though - to make RRDP formally usable. I am not sure how to deal with this and would value direction :)

I believe we need 'something' saying that:

- currently:
  = rsync is mandatory
  = RRDP is allowed as an additional mechanism

- on date x:
  = RRDP is mandatory and rsync is no longer allowed
  = at this point we will also need to address the "URI" in the publication protocol

I am not sure if that A) needs to be described in one migration document with a time line, or that B) it would be better to do something similar to RFC7935 (defining algorithms and key sizes) and have a document that describes the "currently" required and allowed retrieval mechanisms and update it in due time. And I may be missing options C, D, etc here.

Myself I am leaning to doing B in sidr-ops, but again pointers are appreciated.

Thanks
Tim

> 
> 
> _______________________________________________
> sidr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sidr

---

From: "Alvaro Retana (aretana)" <[email-masked]>
Date: Fri, 17 Feb 2017 14:56:41 +0000

Hi!

I just want to provide a little bit more background on the topic below – and ask the Chairs to take an action to confirm with the WG.

During the discussion resulting from my AD review of this document [1], the topic of whether the intent of the document was to replace rsync or not came up (see M16 in my review) – after some discussion we came to a way forward [2], which was to formally Update in RFC6480, RFC6481, and RFC7730 to change the mandatory to implement requirement for rsync and leave instead “a retrieval mechanism(s) consistent with the accessMethod element value(s)”.

Even though this discussion happened on the sidr list, I sent a message to the WG asking for review of the changes [3]…but no reply was received.

As Terry mentions below, these changes removed “the quality of a mandatory to implement retrieval mechanism”: rsync is no longer mandatory to implement, but neither is RRDP.  I personally think that is ok because it also allows to more flexibility; rsync or RRDP (or anything else “consistent with the accessMethod element value(s)”), or both can be implemented as primary and/or backup.

**Chairs**:  Given that this is a significant change, and that the WG may have not been focused on the discussion, and that we now have a little more time given the fact that the IESG review of this document was deferred until Mar/2…  Please explicitly ask the WG to review the Updates to RFC6480, RFC6481 and RFC7730.  I think that a week of discussion on the list should be enough.

Thanks!!

Alvaro.

[1] https://mailarchive.ietf.org/arch/msg/sidr/u1WO8jNlvn-JzoVduhpPOKHjMfI/?qid=61717c3126a62454b45c426ced5d3344
[2] https://mailarchive.ietf.org/arch/msg/sidr/a6kQUe7y456oLmTDrvrBqwR5oRI/?qid=61717c3126a62454b45c426ced5d3344
[3] https://mailarchive.ietf.org/arch/msg/sidr/2d_dDJ5Ck2PMptK_N2tRGQNEDBk/?qid=61717c3126a62454b45c426ced5d3344

On 2/16/17, 10:17 AM, "iesg on behalf of Tim Bruijnzeels" <[email-masked]<mailto:[email-masked]> on behalf of [email-masked]<mailto:[email-masked]>> wrote:

On 16 Feb 2017, at 03:03, Terry Manderson <[email-masked]<mailto:[email-masked]>> wrote:

---

From: Steve KENT <[email-masked]>
Date: Fri, 17 Feb 2017 17:26:47 +0000

Alvaro,

Sorry I faukled to rely when  you posted you comment on this topic to the SIDR list. I don't support revising 6480, 6481, and 7730 to remove mandatory support for rsynch, at this time. The issue, for me, is not whether rysnc is better or worse than the delta protocol. The issue is that if we have no MTI protocol for disseminating RPKI repository data, we fail to ensure interoperability between repositories and relying parties. Given the fact that the delta protocol is still quite new, it seems more appropriate to retain rsync as MTI for now, and to generate another doc establishing a timeline for transition to the delta protocol. This is analogous to what we did in RFC 6489 and RFC 6916, where we specified an orderly transition process for key rollover and algorithm agility, respectively.

Steve

________________________________
From: sidr <[email-masked]> on behalf of Alvaro Retana (aretana) <[email-masked]>
Sent: Friday, February 17, 2017 9:56:41 AM
To: Tim Bruijnzeels; Terry Manderson; [email-masked]; [email-masked]; [email-masked]
Cc: [email-masked]; The IESG; [email-masked]
Subject: Re: [sidr] Terry Manderson's No Objection on draft-ietf-sidr-delta-protocol-07: (with COMMENT)

Hi!

Thanks!!

Alvaro.

---

From: Randy Bush <[email-masked]>
Date: Sat, 18 Feb 2017 11:18:17 +0700

> As Terry mentions below, these changes removed “the quality of a
> mandatory to implement retrieval mechanism”: rsync is no longer
> mandatory to implement, but neither is RRDP.

this is gonna work out really well for distributed clients and
distributed servers where every client must to talk to every server.

not.

randy

---

From: Tim Bruijnzeels <[email-masked]>
Date: Mon, 20 Feb 2017 16:08:02 +0100

Hi Steve, all,

> On 17 Feb 2017, at 18:26, Steve KENT <[email-masked]> wrote:
> 
> Alvaro,
> 

To make it abundantly clear let me re-state: I have no problem with this path.

I believe that Alvaro's suggestions were well-intended to make a future transition document easier, but I don't see any reason why this could not be done later. Having RRDP as an allowed additional mechanism, whilst still requiring rsync as well, will allow us to use it and gain experience. In other words I don't think that a migration document is not a requirement for finishing the RRDP protocol document itself.

I would suggest that a possible rsync phase-out is discussed in sidr-ops. More than willing to provide text or participate otherwise, provided that working group wants to take on the work.

Tim

> [1] https://mailarchive.ietf.org/arch/msg/sidr/u1WO8jNlvn-JzoVduhpPOKHjMfI/?qid=61717c3126a62454b45c426ced5d3344 <https://mailarchive.ietf.org/arch/msg/sidr/u1WO8jNlvn-JzoVduhpPOKHjMfI/?qid=61717c3126a62454b45c426ced5d3344>
> [2] https://mailarchive.ietf.org/arch/msg/sidr/a6kQUe7y456oLmTDrvrBqwR5oRI/?qid=61717c3126a62454b45c426ced5d3344 <https://mailarchive.ietf.org/arch/msg/sidr/a6kQUe7y456oLmTDrvrBqwR5oRI/?qid=61717c3126a62454b45c426ced5d3344>
> [3] https://mailarchive.ietf.org/arch/msg/sidr/2d_dDJ5Ck2PMptK_N2tRGQNEDBk/?qid=61717c3126a62454b45c426ced5d3344 <https://mailarchive.ietf.org/arch/msg/sidr/2d_dDJ5Ck2PMptK_N2tRGQNEDBk/?qid=61717c3126a62454b45c426ced5d3344>
>  
> On 2/16/17, 10:17 AM, "iesg on behalf of Tim Bruijnzeels" <[email-masked] <mailto:[email-masked]> on behalf of [email-masked] <mailto:[email-masked]>> wrote:
>  
> 
> On 16 Feb 2017, at 03:03, Terry Manderson <[email-masked] <mailto:[email-masked]>> wrote:
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html <https://www.ietf.org/iesg/statement/discuss-criteria.html>
> https://datatracker.ietf.org/doc/draft-ietf-sidr-delta-protocol/ <https://datatracker.ietf.org/doc/draft-ietf-sidr-delta-protocol/>

---

From: Rob Austein <[email-masked]>
Date: Mon, 20 Feb 2017 11:02:30 -0500

FWIW, I would prefer to leave rsync's status alone for now (i.e. still mandatory) and handle the transition later via separate docs, probably in SIDROPS, per the original plan.
-- 
Sent from a phone, please excuse brevity and typos.

---

From: "Alvaro Retana (aretana)" <[email-masked]>
Date: Thu, 23 Feb 2017 20:25:07 +0000

Tim:

Hi!

Given the feedback so far on the list, I think we should roll back the updates in preparation for next week’s IESG Telechat.

Thanks!

Alvaro.

On 2/17/17, 9:56 AM, "sidr on behalf of Alvaro Retana (aretana)" <[email-masked]<mailto:[email-masked]> on behalf of [email-masked]<mailto:[email-masked]>> wrote:

> **Chairs**:  Given that this is a significant change, and that the WG may have not been
> focused on the discussion, and that we now have a little more time given the fact that the
> IESG review of this document was deferred until Mar/2…  Please explicitly ask the WG to
> review the Updates to RFC6480, RFC6481 and RFC7730.  I think that a week of discussion
> on the list should be enough.

---

From: Oleg Muravskiy <[email-masked]>
Date: Mon, 27 Feb 2017 09:24:57 +0000

Hi everybody,

> On 23 Feb 2017, at 20:25, Alvaro Retana (aretana) <[email-masked]> wrote:
> 
> Tim:
>  
> Hi!
>  

Currently RFC7730 (TAL format) only allows rsync URIs in there.

In order to allow RRDP in TAL, I think we have to keep the update to RFC7730 in draft-ietf-sidr-delta-protocol, namely this part of the draft:

============================================================================
4.3.  Updates to RFC7730

4.3.1.  Update in Section 2.1, Trust Anchor Locator Format

   OLD:

      where the URI section is comprised of one of more of the ordered
      sequence of:

         1.1) an rsync URI [RFC5781],

         1.2) a <CRLF> or <LF> line break.

   NEW:

      where the URI section is comprised of one of more of the ordered
      sequence of:

         1.1) a URI [RFC3986],

         1.2) a <CRLF> or <LF> line break.

4.3.2.  Update in Section 2.2, TAL and Trust Anchor Certificate
        Considerations

   OLD:

      Each rsync URI in the TAL MUST reference a single object.  It MUST
      NOT reference a directory or any other form of collection of
      objects.

      ...

      Where the TAL contains two or more rsync URIs, then the same self-
      signed CA certificate MUST be found at each referenced location.

   NEW:

      Each URI in the TAL MUST reference a single object.  It MUST NOT
      reference a directory or any other form of collection of objects.

      ...

      Where the TAL contains two or more URIs, then the same self-signed
      CA certificate MUST be found at each referenced location.

4.3.3.  Update in Section 5.1, Normative References

   Remove the reference to RFC5781, "The rsync URI Scheme".

   Add a reference to RFC3986, "Uniform Resource Identifier (URI):
   Generic Syntax".

============================================================================

What do you think?

Oleg

>  
> Thanks!
>  
> Alvaro.
>  
> On 2/17/17, 9:56 AM, "sidr on behalf of Alvaro Retana (aretana)" <[email-masked] on behalf of [email-masked]> wrote:
>

---

From: Tim Bruijnzeels <[email-masked]>
Date: Tue, 28 Feb 2017 15:25:49 +0100

Hi all,

> On 27 Feb 2017, at 10:24, Oleg Muravskiy <[email-masked]> wrote:
> 
> Hi everybody,
> 

While I share my co-author's enthusiasm to update the TAL document, I propose to do this as a separate effort so that the delta protocol doesn't depend on this. It's not needed by the protocol after all, but would help scale access to Trust Anchor certificates.

Also when we go here I believe we will have to allow HTTPS specifically as an alternative scheme. And we may have discussions whether it should be allowed in addition or even instead of rsync (which I believe may be a lot simpler than phasing out rsync everywhere else).

Tim