Skip to main content

The RPKI Repository Delta Protocol (RRDP)
draft-ietf-sidr-delta-protocol-08

Revision differences

Document history

Date Rev. By Action
2017-06-23
08 (System) RFC Editor state changed to AUTH48-DONE from AUTH48
2017-05-22
08 (System) RFC Editor state changed to AUTH48 from RFC-EDITOR
2017-05-10
08 (System) RFC Editor state changed to RFC-EDITOR from REF
2017-05-05
08 (System) RFC Editor state changed to REF from EDIT
2017-03-30
08 (System) RFC Editor state changed to EDIT from MISSREF
2017-03-16
08 (System) IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor
2017-03-16
08 (System) IANA Action state changed to Waiting on RFC Editor from Waiting on Authors
2017-03-15
08 (System) IANA Action state changed to Waiting on Authors from In Progress
2017-03-14
08 (System) IANA Action state changed to In Progress
2017-03-14
08 (System) RFC Editor state changed to MISSREF
2017-03-14
08 (System) IESG state changed to RFC Ed Queue from Approved-announcement sent
2017-03-14
08 (System) Announcement was received by RFC Editor
2017-03-14
08 Cindy Morgan IESG state changed to Approved-announcement sent from Approved-announcement to be sent
2017-03-14
08 Cindy Morgan IESG has approved the document
2017-03-14
08 Cindy Morgan Closed "Approve" ballot
2017-03-14
08 Alvaro Retana IESG state changed to Approved-announcement to be sent from IESG Evaluation::AD Followup
2017-03-14
08 Alvaro Retana Ballot approval text was generated
2017-03-14
08 Alexey Melnikov [Ballot comment]
Thank you for addressing my DISCUSS.
2017-03-14
08 Alexey Melnikov [Ballot Position Update] Position for Alexey Melnikov has been changed to Yes from Discuss
2017-03-13
08 (System) Sub state has been changed to AD Followup from Revised ID Needed
2017-03-13
08 (System) IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed
2017-03-13
08 Oleg Muravskiy New version available: draft-ietf-sidr-delta-protocol-08.txt
2017-03-13
08 (System) New version approved
2017-03-13
08 (System) Request for posting confirmation emailed to previous authors: Rob Austein , Tim Bruijnzeels , Bryan Weber , Oleg Muravskiy
2017-03-13
08 Oleg Muravskiy Uploaded new revision
2017-03-08
07 Alvaro Retana IESG state changed to IESG Evaluation::Revised I-D Needed from IESG Evaluation - Defer::AD Followup
2017-03-02
07 Jean Mahoney Request for Last Call review by GENART Completed: Ready with Nits. Reviewer: Orit Levin.
2017-03-02
07 Cindy Morgan IESG state changed to IESG Evaluation - Defer::AD Followup from IESG Evaluation - Defer
2017-03-02
07 Chris Morrow
As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up.

Changes are expected over time. This version is dated …
As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up.

Changes are expected over time. This version is dated 24 February 2012.

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)?  Why
is this the proper type of RFC?  Is this type of RFC indicated in the
title page header?

Proposed Standard

(2) 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

  Relevant content can frequently be found in the abstract
  and/or introduction of the document. If not, this may be
  an indication that there are deficiencies in the abstract
  or introduction.

"In the Resource Public Key Infrastructure (RPKI), certificate
  authorities publish certificates, including end entity certificates,
  Certificate Revocation Lists (CRL), and RPKI signed objects to
  repositories.  Relying Parties (RP) retrieve the published
  information from those repositories.  This document specifies a delta
  protocol which provides relying parties with a mechanism to query a
  repository for incremental updates, thus enabling the RP to keep its
  state in sync with the repository."

Working Group Summary

  Was there anything in WG process that is worth noting? For
  example, was there controversy about particular points or
  were there decisions where the consensus was particularly
  rough?

The WG process was as most SIDR process goes... long, but generally good in the end.

Document Quality

  Are there existing implementations of the protocol? Have a
  significant number of vendors indicated their plan to
  implement the specification? Are there any reviewers that
  merit special mention as having done a thorough review,
  e.g., one that resulted in important changes or a
  conclusion that the document had no substantive issues? If
  there was a MIB Doctor, Media Type or other expert review,
  what was its course (briefly)? In the case of a Media Type
  review, on what date was the request posted?

There are 2 different protocol implementations to date.
One from RipeLabs, one from Dragon Research Group.

Personnel

  Who is the Document Shepherd? Who is the Responsible Area
  Director?

Shepherd: morrowc@ops-netman.net - Chris Morrow (me)
AD: Alvaro Retana - aretana@cisco.com

(3) Briefly describe the review of this document that was performed by
the Document Shepherd.  If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.

the shepherd read the document during it's lifecycle, it has lived up to expectations.

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

no concerns.

(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.

Quite possibly the XML bits:
  https://tools.ietf.org/html/draft-ietf-sidr-delta-protocol-04#section-3.5.4

should be reviewed again, I believe the authors already undertook some expert review.

(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the
IESG should be aware of? For example, perhaps he or she is uncomfortable
with certain parts of the document, or has concerns whether there really
is a need for it. In any event, if the WG has discussed those issues and
has indicated that it still wishes to advance the document, detail those
concerns here.

no concerns.

(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why.

yes, no issues.

(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

no IPR claims.

(9) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others
being silent, or does the WG as a whole understand and agree with it? 

solid consensus

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)

no appeal/etc threats.

(11) Identify any ID nits the Document Shepherd has found in this
document. (See https://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.

No substantive nits, all issues will be dealt with before RFC Editor time.

(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

No formal reviews required.

(13) Have all references within this document been identified as
either normative or informative?

yes

(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?

No

(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in
the Last Call procedure.

No.

(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are not
listed in the Abstract and Introduction, explain why, and point to the
part of the document where the relationship of this document to the
other RFCs is discussed. If this information is not in the document,
explain why the WG considers it unnecessary.

No other documents changed due to this document.

(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly
identified. Confirm that newly created IANA registries include a
detailed specification of the initial contents for the registry, that
allocations procedures for future registrations are defined, and a
reasonable name for the new registry has been suggested (see RFC 5226).

There is one item for IANA to accomplish, an update to a PKIX registry.

(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find
useful in selecting the IANA Experts for these new registries.

no new registries.

(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.

YES! xmllint and trang were used to validate the XML schema.
2017-03-02
07 Alexey Melnikov
[Ballot discuss]
I would be happy to ballot Yes on this document, as it is well written and is a useful piece of work. However …
[Ballot discuss]
I would be happy to ballot Yes on this document, as it is well written and is a useful piece of work. However I have one issue (and a few minor comments) that I would like to DISCUSS before doing so:

In Section 5.3 the document says:

  It is RECOMMENDED that Relying Parties and Publication Servers follow
  the Best Current Practices outlined in [RFC7525] on the use of HTTP
  over TLS (HTTPS) [RFC2818].

RFC 7525 is referencing RFC 6125 for server hostname validation. Unfortunately this is not detailed enough to perform hostname validation, because reference to RFC 6125 requires specifying answers to every question in section 3 of RFC 6125. (And there is no generic RFC that specifies how this is done for protocols using HTTP.) One example of how this might look like is in Section 9.2 of . For your convenience the relevant text is pasted below:

  Routers MUST also verify the cache's TLS server certificate, using
  subjectAltName dNSName identities as described in [RFC6125], to avoid
  man-in-the-middle attacks.  The rules and guidelines defined in
  [RFC6125] apply here, with the following considerations:

      Support for DNS-ID identifier type (that is, the dNSName identity
      in the subjectAltName extension) is REQUIRED in rpki-rtr server
      and client implementations which use TLS.  Certification
      authorities which issue rpki-rtr server certificates MUST support
      the DNS-ID identifier type, and the DNS-ID identifier type MUST be
      present in rpki-rtr server certificates.

      DNS names in rpki-rtr server certificates SHOULD NOT contain the
      wildcard character "*".

      rpki-rtr implementations which use TLS MUST NOT use CN-ID
      identifiers; a CN field may be present in the server certificate's
      subject name, but MUST NOT be used for authentication within the
      rules described in [RFC6125].

The only thing missing from the above is explicit mentioning that SRV-ID and URI-ID are not used. (I think the same should apply to your document.)
2017-03-02
07 Alexey Melnikov [Ballot comment]
In 3.2: HTTPS reference is out-of-date.

SHA-256 needs a reference.

The shepherding write up says that the schema was not validated. Why not?
2017-03-02
07 Alexey Melnikov [Ballot Position Update] Position for Alexey Melnikov has been changed to Discuss from No Record
2017-03-01
07 Alissa Cooper [Ballot Position Update] New position, No Objection, has been recorded for Alissa Cooper
2017-02-26
07 Alexey Melnikov
[Ballot comment]
In 3.2: HTTPS reference is out-of-date.

SHA-256 needs a reference.

<>

The shepherding write up says that the schema was not validated. Why …
[Ballot comment]
In 3.2: HTTPS reference is out-of-date.

SHA-256 needs a reference.

<>

The shepherding write up says that the schema was not validated. Why not?
2017-02-26
07 Alexey Melnikov Ballot comment text updated for Alexey Melnikov
2017-02-16
07 Alexey Melnikov Telechat date has been changed to 2017-03-02 from 2017-02-16
2017-02-16
07 Alexey Melnikov IESG state changed to IESG Evaluation - Defer from IESG Evaluation
2017-02-16
07 Stephen Farrell
[Ballot comment]
3.5.1.3: hard-coding a hash algorithm again? Why is that a good
idea? sha256 is the right hash to choose today, but having to …
[Ballot comment]
3.5.1.3: hard-coding a hash algorithm again? Why is that a good
idea? sha256 is the right hash to choose today, but having to
rev the rrdp version to move to some other hash alg seems like
a bad plan. I suggest you either add a "hashalg" attribute to
the xml or else use a ni schemed URI for the value of the uri
attribute (or something along those lines).
Same thing in 3.5.3.3.
2017-02-16
07 Stephen Farrell [Ballot Position Update] New position, No Objection, has been recorded for Stephen Farrell
2017-02-16
07 Benoît Claise
[Ballot comment]
Sue Harres' OPS DIR review:

I have reviewed this document as part of the Operational directorate's

ongoing effort to review all IETF documents …
[Ballot comment]
Sue Harres' OPS DIR review:

I have reviewed this document as part of the Operational directorate's

ongoing effort to review all IETF documents being processed by the
IESG.  These
comments were written with the intent of improving the operational
aspects of the
IETF drafts. Comments that are not addressed in last call may be
included in AD reviews
during the IESG review.  Document editors and WG chairs should treat
these comments
just like any other last call comments.

Status:  Ready with NITS –

Overall comment:  Thank you for creating this draft that helps the
SIDR RPKI repositories better.
What I’ve checked (for OPS-AD/NM-ADs):  Check texted, updates to other
protocols 

The details are belowl

Sue Hares
------------------------

Editorial NITS list:

Overall –comment: Each of these nits has a sub-status
a) Really needed – confusing – the document suffers from being
confusing unless you fix it
b) Style – your choice, but the style of the text made it a bit
confusing
c) Go Check – security section that is out of my depth as reviewer

#1 comment, 3.3.2 Publishing Updates, p. 6

Status:  really needed – confusing
Why: You are describing the delta files and then the handling of the
file is a different bullet.
        Please make it one format.

Old:/

  o  This delta file MUST be made available at a URL that is unique
to
      the current session_id and serial number, so that it can be
cached
      indefinitely.

  o  The format and caching concerns for delta files are explained
in
      more detail in Section 3.5.3.
/
New: /

  o  This delta file MUST be made available at a URL that is unique
to
      the current session_id and serial number, so that it can be
cached
      indefinitely. The format and caching concerns for delta files
are explained in
      more detail in Section 3.5.3.
/



#2, comment, 3.3.2, Publishing updates, p. 6

#2 Status; really needed – confusing
Why:  you are describing the snapshot and then the file handling.  It
should be one bullet.

Old:/
  o  The snapshot file MUST be made available at a URL that is
unique
      to this session and new serial, so that it can be cached
      indefinitely.

  o  The format and caching concerns for snapshot files are explained
      in more detail in Section 3.5.2.
/
New/

  o  The snapshot file MUST be made available at a URL that is
unique
      to this session and new serial, so that it can be cached
      indefinitely.  The format and caching concerns for snapshot
files are explained
      in more detail in Section 3.5.2.
/

#3, comment, 3.3.2, Publishing updates, p. 6

Status: really needed – confusing
Why: You are describing the notification files and then the file
format.

Old:/
  o  A new notification file MUST now be created by the repository
      server.  This new notification file MUST include a reference to
      the new snapshot file, and all delta files selected in the
      previous steps.

  o  The format and caching concerns for update notification files
are
      explained in more detail in Section 3.5.1.
/
New: /

  o  A new notification file MUST now be created by the repository
      server.  This new notification file MUST include a reference to
      the new snapshot file, and all delta files selected in the
      previous steps. The format and caching concerns for update
notification files are
      explained in more detail in Section 3.5.1.
/

#4 section 3.4.1:entire section

Status: style/confusing

Comment: The first paragraph is the description of how Relying Party
(RP) when it learns about a valid certificate with a SIA entry for the
RRDP protocol.  The section does not make it clear.

Easy fix: 

Old/this protocol as follows/
New/this protocol as follows:/

+ indent each paragraph as part of list

#5 page 8 section 3.4.2 –general comment

Status: really-needed

The last paragraph “RP SHOUD NOT Remove objects”, the sentences as
follows:

      The RP could use
      additional strategies to determine if an object is still
relevant
      for validation before removing it from its local storage.  In
      particular objects should not be removed if they are included in
a
      current validated manifest.

If you suggest this, I suspect that all of you know what your
implementations are doing.  However, the specification is for other
people who want to also implement this protocol or checks to this
protocol.  An example or a pointer to an example would be very useful.


It does not break the protocol, so this did not rise to the level of
“minor”.  However it is piece of the specification you could tie down
operationally. 

#6 page 14, section 3.5.3.3 – file format and validation

Status: style/nice to have – makes it easier for reader.

Old:/  Note that a formal RELAX NG specification of this file format
is
  included later in this document.  A RP MUST NOT process any delta
  file that is incomplete or not well-formed./

New:/  Note that a formal RELAX NG specification of this file format
is
  included in section 3.5.4 in this document.  A RP MUST NOT process
any delta
  file that is incomplete or not well-formed.
    /


#7 section 6, paragraph 3 status:

Status: Please check with security person

Paragraph: /
  Supporting both RRDP and rsync necessarily increases the number of
  opportunities for a malicious RPKI CA to perform denial of service
  attacks on relying parties, by expanding the number of URIs which
the
  RP may need to contact in order to complete a validation run.
  However, other than the relative cost of HTTPS versus rsync,
adding
  RRDP to the mix does not change this picture significantly: with
  either RRDP or rsync a malicious CA can supply an effectively
  infinite series of URIs for the RP to follow.  The only real
solution
  to this is for the RP to apply some kind of bound to the amount of
  work it is willing to do.  Note also that the attacker in this
  scenario must be an RPKI CA, since otherwise the normal RPKI
object
  security checks would reject the malicious URIs./

I’m really out of my depth to state how this works as security expert
or
As operational expert.  It just raised questions of “oh really.. “
2017-02-16
07 Benoît Claise Ballot comment text updated for Benoit Claise
2017-02-16
07 Benoît Claise
[Ballot comment]
I have reviewed this document as part of the Operational directorate's

ongoing effort to review all IETF documents being processed by the
IESG.  …
[Ballot comment]
I have reviewed this document as part of the Operational directorate's

ongoing effort to review all IETF documents being processed by the
IESG.  These
comments were written with the intent of improving the operational
aspects of the
IETF drafts. Comments that are not addressed in last call may be
included in AD reviews
during the IESG review.  Document editors and WG chairs should treat
these comments
just like any other last call comments.

Status:  Ready with NITS –

Overall comment:  Thank you for creating this draft that helps the
SIDR RPKI repositories better.
What I’ve checked (for OPS-AD/NM-ADs):  Check texted, updates to other
protocols 

The details are belowl

Sue Hares
------------------------

Editorial NITS list:

Overall –comment: Each of these nits has a sub-status
a) Really needed – confusing – the document suffers from being
confusing unless you fix it
b) Style – your choice, but the style of the text made it a bit
confusing
c) Go Check – security section that is out of my depth as reviewer

#1 comment, 3.3.2 Publishing Updates, p. 6

Status:  really needed – confusing
Why: You are describing the delta files and then the handling of the
file is a different bullet.
        Please make it one format.

Old:/

  o  This delta file MUST be made available at a URL that is unique
to
      the current session_id and serial number, so that it can be
cached
      indefinitely.

  o  The format and caching concerns for delta files are explained
in
      more detail in Section 3.5.3.
/
New: /

  o  This delta file MUST be made available at a URL that is unique
to
      the current session_id and serial number, so that it can be
cached
      indefinitely. The format and caching concerns for delta files
are explained in
      more detail in Section 3.5.3.
/



#2, comment, 3.3.2, Publishing updates, p. 6

#2 Status; really needed – confusing
Why:  you are describing the snapshot and then the file handling.  It
should be one bullet.

Old:/
  o  The snapshot file MUST be made available at a URL that is
unique
      to this session and new serial, so that it can be cached
      indefinitely.

  o  The format and caching concerns for snapshot files are explained
      in more detail in Section 3.5.2.
/
New/

  o  The snapshot file MUST be made available at a URL that is
unique
      to this session and new serial, so that it can be cached
      indefinitely.  The format and caching concerns for snapshot
files are explained
      in more detail in Section 3.5.2.
/

#3, comment, 3.3.2, Publishing updates, p. 6

Status: really needed – confusing
Why: You are describing the notification files and then the file
format.

Old:/
  o  A new notification file MUST now be created by the repository
      server.  This new notification file MUST include a reference to
      the new snapshot file, and all delta files selected in the
      previous steps.

  o  The format and caching concerns for update notification files
are
      explained in more detail in Section 3.5.1.
/
New: /

  o  A new notification file MUST now be created by the repository
      server.  This new notification file MUST include a reference to
      the new snapshot file, and all delta files selected in the
      previous steps. The format and caching concerns for update
notification files are
      explained in more detail in Section 3.5.1.
/

#4 section 3.4.1:entire section

Status: style/confusing

Comment: The first paragraph is the description of how Relying Party
(RP) when it learns about a valid certificate with a SIA entry for the
RRDP protocol.  The section does not make it clear.

Easy fix: 

Old/this protocol as follows/
New/this protocol as follows:/

+ indent each paragraph as part of list

#5 page 8 section 3.4.2 –general comment

Status: really-needed

The last paragraph “RP SHOUD NOT Remove objects”, the sentences as
follows:

      The RP could use
      additional strategies to determine if an object is still
relevant
      for validation before removing it from its local storage.  In
      particular objects should not be removed if they are included in
a
      current validated manifest.

If you suggest this, I suspect that all of you know what your
implementations are doing.  However, the specification is for other
people who want to also implement this protocol or checks to this
protocol.  An example or a pointer to an example would be very useful.


It does not break the protocol, so this did not rise to the level of
“minor”.  However it is piece of the specification you could tie down
operationally. 

#6 page 14, section 3.5.3.3 – file format and validation

Status: style/nice to have – makes it easier for reader.

Old:/  Note that a formal RELAX NG specification of this file format
is
  included later in this document.  A RP MUST NOT process any delta
  file that is incomplete or not well-formed./

New:/  Note that a formal RELAX NG specification of this file format
is
  included in section 3.5.4 in this document.  A RP MUST NOT process
any delta
  file that is incomplete or not well-formed.
    /


#7 section 6, paragraph 3 status:

Status: Please check with security person

Paragraph: /
  Supporting both RRDP and rsync necessarily increases the number of
  opportunities for a malicious RPKI CA to perform denial of service
  attacks on relying parties, by expanding the number of URIs which
the
  RP may need to contact in order to complete a validation run.
  However, other than the relative cost of HTTPS versus rsync,
adding
  RRDP to the mix does not change this picture significantly: with
  either RRDP or rsync a malicious CA can supply an effectively
  infinite series of URIs for the RP to follow.  The only real
solution
  to this is for the RP to apply some kind of bound to the amount of
  work it is willing to do.  Note also that the attacker in this
  scenario must be an RPKI CA, since otherwise the normal RPKI
object
  security checks would reject the malicious URIs./

I’m really out of my depth to state how this works as security expert
or
As operational expert.  It just raised questions of “oh really.. “
2017-02-16
07 Benoît Claise [Ballot Position Update] New position, No Objection, has been recorded for Benoit Claise
2017-02-16
07 Jari Arkko [Ballot Position Update] New position, No Objection, has been recorded for Jari Arkko
2017-02-16
07 Alexey Melnikov [Ballot comment]
I am very likely to defer this document, as it needs review from HTTP experts.
2017-02-16
07 Alexey Melnikov Ballot comment text updated for Alexey Melnikov
2017-02-16
07 Mirja Kühlewind [Ballot Position Update] New position, No Objection, has been recorded for Mirja Kühlewind
2017-02-16
07 Joel Jaeggli [Ballot Position Update] New position, No Objection, has been recorded for Joel Jaeggli
2017-02-15
07 Spencer Dawkins
[Ballot comment]
I’m not skilled in the art of RPKI, so perhaps I lack imagination, but I'm not understanding why these two SHOULDs aren't MUSTs. …
[Ballot comment]
I’m not skilled in the art of RPKI, so perhaps I lack imagination, but I'm not understanding why these two SHOULDs aren't MUSTs. I'm not asking for a change, but if the document included explanations of why an implementation might not do the SHOULDs, some readers might thank you.

    The RP SHOULD add all publish elements to a local storage and
      update its last processed serial number to the serial number of
      this delta file.

      The RP SHOULD NOT remove objects from its local storage solely
      because it encounters a "withdraw" element, because this would
      enable a publication server to withdraw any object without the
      signing Certificate Authority consent.  The RP could use
      additional strategies to determine if an object is still relevant
      for validation before removing it from its local storage.  In
      particular objects should not be removed if they are included in a
      current validated manifest.
2017-02-15
07 Spencer Dawkins [Ballot Position Update] New position, No Objection, has been recorded for Spencer Dawkins
2017-02-15
07 Ben Campbell
[Ballot comment]
- 3.4.1, 3rd paragraph: In a number of other protocols, a "User-Agent" header can be used for implementation fingerprinting, so that an attacker …
[Ballot comment]
- 3.4.1, 3rd paragraph: In a number of other protocols, a "User-Agent" header can be used for implementation fingerprinting, so that an attacker can guess what vulnerabilities might exist in that instance. Is that a concern here?

- 3.5.3.2, 2nd paragraph: The MAY sounds more like a statement of fact than permission.

- 5.2, 2nd paragraph: The RECOMMENDED sounds like a statement of fact as worded.
2017-02-15
07 Ben Campbell [Ballot Position Update] New position, No Objection, has been recorded for Ben Campbell
2017-02-15
07 Terry Manderson
[Ballot comment]
Thank you for this work, it is clear and well written. While I have never (ever) been enamoured by RSYNC, and I much …
[Ballot 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..
2017-02-15
07 Terry Manderson [Ballot Position Update] New position, No Objection, has been recorded for Terry Manderson
2017-02-15
07 Alia Atlas [Ballot Position Update] New position, No Objection, has been recorded for Alia Atlas
2017-02-15
07 Susan Hares Request for Last Call review by OPSDIR Completed: Has Nits. Reviewer: Susan Hares. Sent review to list.
2017-02-14
07 Suresh Krishnan [Ballot Position Update] New position, No Objection, has been recorded for Suresh Krishnan
2017-02-14
07 (System) IANA Review state changed to IANA OK - Actions Needed from Version Changed - Review Needed
2017-02-14
07 Kathleen Moriarty [Ballot Position Update] New position, No Objection, has been recorded for Kathleen Moriarty
2017-02-14
07 Deborah Brungard [Ballot Position Update] New position, No Objection, has been recorded for Deborah Brungard
2017-02-10
07 Oleg Muravskiy New version available: draft-ietf-sidr-delta-protocol-07.txt
2017-02-10
07 (System) New version approved
2017-02-10
07 (System) Request for posting confirmation emailed to previous authors: "Tim Bruijnzeels" , "Oleg Muravskiy" , "Bryan Weber" , "Rob Austein"
2017-02-10
07 Oleg Muravskiy Uploaded new revision
2017-02-10
06 Alvaro Retana IESG state changed to IESG Evaluation from Waiting for AD Go-Ahead::AD Followup
2017-02-10
06 Alvaro Retana Ballot has been issued
2017-02-10
06 Alvaro Retana [Ballot Position Update] New position, Yes, has been recorded for Alvaro Retana
2017-02-10
06 Alvaro Retana Created "Approve" ballot
2017-02-10
06 (System) Sub state has been changed to AD Followup from Revised ID Needed
2017-02-10
06 (System) IANA Review state changed to Version Changed - Review Needed from IANA - Not OK
2017-02-10
06 Oleg Muravskiy New version available: draft-ietf-sidr-delta-protocol-06.txt
2017-02-10
06 (System) New version approved
2017-02-10
06 (System) Request for posting confirmation emailed to previous authors: "Tim Bruijnzeels" , "Oleg Muravskiy" , "Bryan Weber" , "Rob Austein"
2017-02-10
06 Oleg Muravskiy Uploaded new revision
2017-02-02
05 Tero Kivinen Request for Last Call review by SECDIR Completed: Has Nits. Reviewer: David Mandelberg.
2017-02-01
05 Alvaro Retana IESG state changed to Waiting for AD Go-Ahead::Revised I-D Needed from Waiting for Writeup
2017-02-01
05 Alvaro Retana Ballot writeup was changed
2017-01-31
05 (System) IESG state changed to Waiting for Writeup from In Last Call
2017-01-30
05 (System) IANA Review state changed to IANA - Not OK from IANA - Review Needed
2017-01-30
05 Sabrina Tanamal
(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Services Operator has completed its review of draft-ietf-sidr-delta-protocol-05.txt. If any part of this review is inaccurate, please let …
(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Services Operator has completed its review of draft-ietf-sidr-delta-protocol-05.txt. If any part of this review is inaccurate, please let us know.

The IANA Services Operator understands that, upon approval of this document, there is a single action which we must complete.

In the SMI Security for PKIX Access Descriptor subregistry of the Structure of Management Information (SMI) Numbers (MIB Module Registrations) registry located at:

http://www.iana.org/assignments/smi-numbers/

a new entry will be registered as follows:

Decimal: [ TBD-at-registration ]
Description: id-ad-rpkiNotify
Reference: [ RFC-to-be ]

Because this registry requires Expert Review [RFC5226] for registration, we've contacted the IESG-designated expert in a separate ticket to request approval. Expert review should be completed before your document can be approved for publication as an RFC.

The IANA Services Operator understands that this is the only action required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is only to confirm what actions will be performed.

Thank you,

Sabrina Tanamal
IANA Services Specialist
PTI
2017-01-25
05 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Susan Hares
2017-01-25
05 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Susan Hares
2017-01-19
05 Jean Mahoney Request for Last Call review by GENART is assigned to Orit Levin
2017-01-19
05 Jean Mahoney Request for Last Call review by GENART is assigned to Orit Levin
2017-01-19
05 Tero Kivinen Request for Last Call review by SECDIR is assigned to David Mandelberg
2017-01-19
05 Tero Kivinen Request for Last Call review by SECDIR is assigned to David Mandelberg
2017-01-17
05 Cindy Morgan IANA Review state changed to IANA - Review Needed
2017-01-17
05 Cindy Morgan
The following Last Call announcement was sent out:

From: The IESG
To: "IETF-Announce"
CC: morrowc@ops-netman.net, sidr-chairs@ietf.org, "Chris Morrow" , sidr@ietf.org, draft-ietf-sidr-delta-protocol@ietf.org, …
The following Last Call announcement was sent out:

From: The IESG
To: "IETF-Announce"
CC: morrowc@ops-netman.net, sidr-chairs@ietf.org, "Chris Morrow" , sidr@ietf.org, draft-ietf-sidr-delta-protocol@ietf.org, aretana@cisco.com
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (RPKI Repository Delta Protocol) to Proposed Standard


The IESG has received a request from the Secure Inter-Domain Routing WG
(sidr) to consider the following document:
- 'RPKI Repository Delta Protocol'
  as 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 2017-01-31. 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.

Abstract


  In the Resource Public Key Infrastructure (RPKI), certificate
  authorities publish certificates, including end entity certificates,
  Certificate Revocation Lists (CRL), and RPKI signed objects to
  repositories.  Relying Parties (RP) retrieve the published
  information from those repositories.  This document specifies a
  protocol which provides relying parties with a mechanism to query a
  repository for incremental updates using the HTTP Over TLS (HTTPS)
  [RFC2818] protocol, thus enabling the RP to keep its state in sync
  with the repository using a secure transport channel.  This document
  updates [RFC6480], [RFC6481], and [RFC7730].




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-sidr-delta-protocol/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-sidr-delta-protocol/ballot/


No IPR declarations have been submitted directly on this I-D.


The document contains these normative downward references.
See RFC 3967 for additional information:
    rfc5781: The rsync URI Scheme (Informational - IETF stream)
    rfc2818: HTTP Over TLS (Informational - IETF stream)
    rfc6480: An Infrastructure to Support Secure Internet Routing (Informational - IETF stream)
All 3 references have been considered by the community before and are already listed in the acceptable
Downref Registry: https://trac.ietf.org/trac/iesg/wiki/DownrefRegistry
2017-01-17
05 Cindy Morgan IESG state changed to In Last Call from Last Call Requested
2017-01-17
05 Alvaro Retana Placed on agenda for telechat - 2017-02-16
2017-01-17
05 Alvaro Retana Changed consensus to Yes from Unknown
2017-01-17
05 Alvaro Retana Last call was requested
2017-01-17
05 Alvaro Retana Ballot approval text was generated
2017-01-17
05 Alvaro Retana Ballot writeup was generated
2017-01-17
05 Alvaro Retana IESG state changed to Last Call Requested from AD Evaluation::AD Followup
2017-01-17
05 Alvaro Retana Last call announcement was changed
2017-01-17
05 Alvaro Retana Last call announcement was generated
2017-01-16
05 (System) Sub state has been changed to AD Followup from Revised ID Needed
2017-01-16
05 Oleg Muravskiy New version available: draft-ietf-sidr-delta-protocol-05.txt
2017-01-16
05 (System) New version approved
2017-01-16
05 (System) Request for posting confirmation emailed to previous authors: "Tim Bruijnzeels" , "Oleg Muravskiy" , "Bryan Weber" , "Rob Austein"
2017-01-16
05 Oleg Muravskiy Uploaded new revision
2016-12-20
04 Alvaro Retana IESG state changed to AD Evaluation::Revised I-D Needed from AD Evaluation
2016-12-20
04 Alvaro Retana
===  AD Review of draft-ietf-sidr-delta-protocol-04 ===

I have several comments (please see below); I marked many of them as “Major”, some because of the use …
===  AD Review of draft-ietf-sidr-delta-protocol-04 ===

I have several comments (please see below); I marked many of them as “Major”, some because of the use of Normative language, but my main concern is that I think error conditions in the protocol are underspecified (see M7, M8, M10, below).  Along the same lines, I think that an Operations Considerations section would be of benefit (see M8 below); you might also want to take a look at RFC5706 (Guidelines for Considering Operations and Management of New Protocols and Protocol Extensions).

I would like to see the error conditions comments addressed before moving this document forward to IETF Last Call.

Thanks!!

Alvaro.


Major:

M1.  I assume that the id-ad-rpkiNotify value was assigned through the early allocation process.  Instead of pointing at the registry in Section 3.2, point at the IANA Consideration Section --- and there, please remind IANA of the early allocation and request the update.

M2. Section 3.2. (Certificate Authority Use): “Relying Parties that do not support this delta protocol MUST NOT reject a CA certificate merely because it has an SIA extension containing this new kind of AccessDescription.”  By definition, an RP that has never even considered this document will not support the delta protocol – IOW, trying to specify the behavior of RPs that may have never even seen this document makes no sense to me, and can’t be enforced.  What is the current behavior when an RP receives the extra SIA extension?

M3. Section 3.3.2. (Publishing Updates): “Whenever the repository server receives updates from a CA it SHOULD generate new snapshot and delta files.  However, if a publication server services a large number of CAs it MAY choose to combine updates from multiple CAs.  If a publication server combines updates in this way, it MUST NOT postpone publishing for longer than one minute.”  The “MUST NOT” at the end (making it mandatory to publish) doesn’t work with the “SHOULD” at the beginning, which has no time constraint and opens to the door to a situation where no publishing is done.  Suggestion:
NEW>
  Whenever the repository server receives updates from a CA it MUST
  generate new snapshot and delta.  If a publication
  server services a large number of CAs it MAY choose to combine
  updates from multiple CAs, but it MUST NOT postpone publishing for longer than one
  minute.

M4. From 3.3.2. (Publishing Updates): “The update notification file SHOULD be kept small…older delta files that…will result in total size of deltas exceeding the size of the snapshot, MUST be excluded.”  Here the “SHOULD” and the “MUST” are in contradiction: you either do it always (MUST) or there may be cases when you don’t (SHOULD).  s/SHOULD/should

M5. Section 3.4.1. (Processing the Update Notification File) says that “a Relying Party (RP)…SHOULD prefer to use this protocol as follows.”  I think you really want to be explicit: s/SHOULD prefer to use/SHOULD use

M6. 3.4.1. (Processing the Update Notification File): “The RP SHOULD download the update notification file, unless an update notification file was already downloaded and processed from the same location in this validation run.”  Is there any other reason for the file not to be downloaded?  Why would the RP decide not to (“SHOULD”)?  If there are no other reasons, then why isn’t the “SHOULD” a “MUST”?

M7. 3.4.1. (Processing the Update Notification File): “MUST issue an operator error”  What is an “operator error” and how do you issue one?  I didn’t see an error definition in the schema.

M8. 3.4.1. (Processing the Update Notification File): “If neither update notification file and one snapshot file or delta files could be processed…SHOULD use an alternate repository retrieval mechanism if it is available.”  This “SHOULD” doesn’t define anything normative with respect to the Delta Protocol.  I think that this document would benefit from a short Operation Considerations section; a place to indicate expectations of the operators, potential issues, the fact (as expressed in this piece of text) that an alternate mechanism should be enabled (or at least considered), other considerations related to logging errors for the operator (see above), etc.

M9. There are some places where non-normative and normative (RFC2119) language is used that may cause confusion.  For example, in 3.4.2: “should perform the following actions”, the actions contain a set of “MUSTs” and “SHOULDs”.  Please find an alternate way to write the lead-in header to avoid confusion.  Suggestion: s/it should perform the following actions/it performs the following actions.  [Note that the same construct if used in several different places…]

M10. In several places (related to verification, but in other places as well), “the file MUST be rejected” is used.  What does this mean exactly?  Are there actions that should be taken as a result?  An example of why I’m asking: an RP will download and process delta files based on information in a notification file – if a delta file is not well-formed (for example), then the validation will fail and the RP MUST reject it – there are multiple reasons why the file may not be well-formed, but the bottom line is that whatever information was there that the repository pointed to in the notification message is lost (?) – does this mean that the RP is now out of sync?  Should the RP now try and re-sync using the snapshot file?  What if that is also rejected?  Maybe the notification file was somehow corrupted and pointed at the wrong file(s)…should the relationship with the repository be reset/restarted?  It is not clear at all what should be done, or what the implications are of these error conditions; it just looks like we reject and go on. [See comment M8 above: it looks like only when “neither update notification file and one snapshot file or delta files could be processed” that we would abandon using RRDP.]

M11. From 3.4.3. (Processing Delta Files): “it is RECOMMENDED that a RP uses additional strategies to determine if an object is still relevant for validation before removing it from its local storage”.  Ok, like what?

M12. 3.5.1.2. (Update Notification File): “…the repository server MUST ensure that this file is not cached for longer than 1 minute.  An exception to this rule…”  Using “MUST” implies no exceptions.  s/MUST/SHOULD    s/then no/than no

M13. Why isn’t an IETF namespace [RFC3688] used in the XML schema?  I would strongly suggest that you use one and request it in the IANA Considerations Section.  Unlike the publication protocol, this document specifies version 1 – which of course doesn’t mean there isn’t a longer history behind it, so I’m open to keeping a non-IETF namespace if that is the case.

M14. 3.5.2.3: “Note that the publish element is defined in the publication protocol [I-D.ietf-sidr-publication]”  But the example doesn’t correspond to the definition in I-D.ietf-sidr-publication, even if it does comply with the schema in this document.  Should the publish element behave the same way as specified in I-D.ietf-sidr-publication?  It is good that the RRDP design goes back to the Publication Protocol, but if it doesn’t use the exact definition from there (including the schema), then the differences should be highlighted here.

M15. 3.5.3.3: “Note that the publish and withdraw elements are defined in the publication protocol [I-D.ietf-sidr-publication]”  Same comment as above.

M16. Section 5. (Security Considerations): “RRDP replaces the use of rsync by HTTPS…”. Given the statement in 3.4.1 about using “an alternate repository retrieval mechanism” and the rest of the text in this section, I would assume that the intent is not really to “replace the use of rsync” (with an update to RFC6480).  Maybe I’m reading too much into the phrase above, but please clarify.


Minor:

P1. In 3.3.1. (Initialisation): “Note that this snapshot file MAY contain zero publish elements at this point if no objects have been submitted for publication yet.”  This text is not describing an option: s/MAY/may

P2. Please expand RRDP in first use.

P3. Section 3.4.4. (Polling the Update Notification File) says: “A detailed description of the validation process itself is out of scope of this document.”  Isn’t that what is described in 3.4.1 and 3.5.1.3??

P4. “version 4 UUID”  Please provide a reference.

P5. 3.5.1.3: “The serial attribute must be…”  This is the only place where RFC2119 language is not used in this section.  Any special reason?

P6. 3.5.1.3: “If delta elements are included they MUST form a contiguous sequence of serial numbers…up to the serial number mentioned in the notification element.”  The example in this section lists the serial numbers in “reverse order” (3, 2) – is there an order requirement?  The text seems to imply it, but it could go either way.

P7. The following references should be Informative: IANA-AD-NUMBERS, RFC6481, RFC6486, RFC6488 should be made Informative.


Nits:

N1. In both 3.3.1/3.3.2, the notes about “format and caching concerns” would work better if they are part of the previous paragraph.

N2. s/are no no longer/are no longer
2016-12-19
04 Alvaro Retana IESG state changed to AD Evaluation from Publication Requested
2016-12-19
04 Alvaro Retana Notification list changed to "Chris Morrow" <morrowc@ops-netman.net>, aretana@cisco.com from "Chris Morrow" <morrowc@ops-netman.net>
2016-10-26
04 Chris Morrow
As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up.

Changes are expected over time. This version is dated …
As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up.

Changes are expected over time. This version is dated 24 February 2012.

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)?  Why
is this the proper type of RFC?  Is this type of RFC indicated in the
title page header?

Proposed Standard

(2) 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

  Relevant content can frequently be found in the abstract
  and/or introduction of the document. If not, this may be
  an indication that there are deficiencies in the abstract
  or introduction.

"In the Resource Public Key Infrastructure (RPKI), certificate
  authorities publish certificates, including end entity certificates,
  Certificate Revocation Lists (CRL), and RPKI signed objects to
  repositories.  Relying Parties (RP) retrieve the published
  information from those repositories.  This document specifies a delta
  protocol which provides relying parties with a mechanism to query a
  repository for incremental updates, thus enabling the RP to keep its
  state in sync with the repository."

Working Group Summary

  Was there anything in WG process that is worth noting? For
  example, was there controversy about particular points or
  were there decisions where the consensus was particularly
  rough?

The WG process was as most SIDR process goes... long, but generally good in the end.

Document Quality

  Are there existing implementations of the protocol? Have a
  significant number of vendors indicated their plan to
  implement the specification? Are there any reviewers that
  merit special mention as having done a thorough review,
  e.g., one that resulted in important changes or a
  conclusion that the document had no substantive issues? If
  there was a MIB Doctor, Media Type or other expert review,
  what was its course (briefly)? In the case of a Media Type
  review, on what date was the request posted?

There are 2 different protocol implementations to date.
One from RipeLabs, one from Dragon Research Group.

Personnel

  Who is the Document Shepherd? Who is the Responsible Area
  Director?

Shepherd: morrowc@ops-netman.net - Chris Morrow (me)
AD: Alvaro Retana - aretana@cisco.com

(3) Briefly describe the review of this document that was performed by
the Document Shepherd.  If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.

the shepherd read the document during it's lifecycle, it has lived up to expectations.

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

no concerns.

(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.

Quite possibly the XML bits:
  https://tools.ietf.org/html/draft-ietf-sidr-delta-protocol-04#section-3.5.4

should be reviewed again, I believe the authors already undertook some expert review.

(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the
IESG should be aware of? For example, perhaps he or she is uncomfortable
with certain parts of the document, or has concerns whether there really
is a need for it. In any event, if the WG has discussed those issues and
has indicated that it still wishes to advance the document, detail those
concerns here.

no concerns.

(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why.

yes, no issues.

(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

no IPR claims.

(9) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others
being silent, or does the WG as a whole understand and agree with it? 

solid consensus

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)

no appeal/etc threats.

(11) Identify any ID nits the Document Shepherd has found in this
document. (See https://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.

No substantive nits, all issues will be dealt with before RFC Editor time.

(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

No formal reviews required.

(13) Have all references within this document been identified as
either normative or informative?

yes

(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?

No

(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in
the Last Call procedure.

No.

(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are not
listed in the Abstract and Introduction, explain why, and point to the
part of the document where the relationship of this document to the
other RFCs is discussed. If this information is not in the document,
explain why the WG considers it unnecessary.

No other documents changed due to this document.

(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly
identified. Confirm that newly created IANA registries include a
detailed specification of the initial contents for the registry, that
allocations procedures for future registrations are defined, and a
reasonable name for the new registry has been suggested (see RFC 5226).

There is one item for IANA to accomplish, an update to a PKIX registry.

(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find
useful in selecting the IANA Experts for these new registries.

no new registries.

(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.

No automated checks made.
2016-10-26
04 Chris Morrow Responsible AD changed to Alvaro Retana
2016-10-26
04 Chris Morrow IETF WG state changed to Submitted to IESG for Publication from WG Document
2016-10-26
04 Chris Morrow IESG state changed to Publication Requested
2016-10-26
04 Chris Morrow IESG process started in state Publication Requested
2016-10-26
04 Chris Morrow Changed document writeup
2016-10-26
04 Chris Morrow Notification list changed to "Chris Morrow" <morrowc@ops-netman.net>
2016-10-26
04 Chris Morrow Document shepherd changed to Chris Morrow
2016-09-29
04 Tim Bruijnzeels New version available: draft-ietf-sidr-delta-protocol-04.txt
2016-09-29
04 Tim Bruijnzeels New version approved
2016-09-29
04 Tim Bruijnzeels Request for posting confirmation emailed to previous authors: "Tim Bruijnzeels" , "Oleg Muravskiy" , "Bryan Weber" , "Rob Austein"
2016-09-29
04 (System) Uploaded new revision
2016-07-14
03 Sandra Murphy Added to session: IETF-96: sidr  Thu-1000
2016-07-07
03 Tim Bruijnzeels New version available: draft-ietf-sidr-delta-protocol-03.txt
2016-03-21
02 Tim Bruijnzeels New version available: draft-ietf-sidr-delta-protocol-02.txt
2015-10-19
01 Tim Bruijnzeels New version available: draft-ietf-sidr-delta-protocol-01.txt
2015-03-21
00 Sandra Murphy Intended Status changed to Proposed Standard from None
2015-02-16
00 Tim Bruijnzeels New version available: draft-ietf-sidr-delta-protocol-00.txt