Use Cases for Localized Versions of the RPKI
draft-ietf-sidrops-lta-use-cases-06
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2023-05-23
|
06 | (System) | Document has expired |
2023-05-22
|
06 | Warren Kumari | After discussions with author and some ADs, marking this as dead / overtaken by events. |
2023-05-22
|
06 | Warren Kumari | IESG state changed to Dead from IESG Evaluation::Revised I-D Needed |
2021-04-22
|
06 | Lars Eggert | [Ballot discuss] Taking over Alissa's DICSUSS, as a reminder to check this when a new revision becomes available: > I do not believe we should … [Ballot discuss] Taking over Alissa's DICSUSS, as a reminder to check this when a new revision becomes available: > I do not believe we should publish this document with the term "socially > acceptable data," because it endorses others' determinations of what is > socially acceptable in a blanket fashion. I would recommend "other resources." > > Comment (2019-05-01) I support the DISCUSS ballots of Roman and Mirja and > Benjamin's first three DISCUSS points. |
2021-04-22
|
06 | Lars Eggert | [Ballot Position Update] New position, Discuss, has been recorded for Lars Eggert |
2019-08-26
|
06 | Gunter Van de Velde | Assignment of request for Last Call review by OPSDIR to Tim Wicinski was marked no-response |
2019-05-09
|
06 | Jean Mahoney | Closed request for Last Call review by GENART with state 'Overtaken by Events' |
2019-05-06
|
06 | Pete Resnick | Assignment of request for Last Call review by GENART to Pete Resnick was rejected |
2019-05-03
|
06 | Tero Kivinen | Closed request for Last Call review by SECDIR with state 'Withdrawn' |
2019-05-02
|
06 | Éric Vyncke | [Ballot comment] Thank you for writing this short document. I liked your 'suggested reading' section ;-) Text is sometimes a little too casual though such … [Ballot comment] Thank you for writing this short document. I liked your 'suggested reading' section ;-) Text is sometimes a little too casual though such as in section 4 "not to condone borrowing" ;-) |
2019-05-02
|
06 | Éric Vyncke | [Ballot Position Update] New position, No Objection, has been recorded for Éric Vyncke |
2019-05-02
|
06 | Cindy Morgan | IESG state changed to IESG Evaluation::Revised I-D Needed from IESG Evaluation |
2019-05-02
|
06 | Magnus Westerlund | [Ballot Position Update] New position, No Objection, has been recorded for Magnus Westerlund |
2019-05-02
|
06 | Ignas Bagdonas | [Ballot Position Update] New position, No Objection, has been recorded for Ignas Bagdonas |
2019-05-02
|
06 | Martin Vigoureux | [Ballot Position Update] New position, No Objection, has been recorded for Martin Vigoureux |
2019-05-01
|
06 | Alissa Cooper | [Ballot discuss] I do not believe we should publish this document with the term "socially acceptable data," because it endorses others' determinations of what is … [Ballot discuss] I do not believe we should publish this document with the term "socially acceptable data," because it endorses others' determinations of what is socially acceptable in a blanket fashion. I would recommend "other resources." |
2019-05-01
|
06 | Alissa Cooper | [Ballot comment] I support the DISCUSS ballots of Roman and Mirja and Benjamin's first three DISCUSS points. |
2019-05-01
|
06 | Alissa Cooper | [Ballot Position Update] New position, Discuss, has been recorded for Alissa Cooper |
2019-05-01
|
06 | Benjamin Kaduk | [Ballot discuss] I have strong misgivings about publishing this document in its current form. The review comment on its predecessor in sidr, "it is written … [Ballot discuss] I have strong misgivings about publishing this document in its current form. The review comment on its predecessor in sidr, "it is written like af able, not an RFC" really sticks with me, and while the style plays a role in my misgivings, I think there are some substantive concerns in play as well. I agree with Roman that there is strong qualitative overlap with situations like TLS MiTM, akin to a violation of the end-to-end principle. I also agree with Mirja that "re-routing to acceptable content" is questionable, and smacks of endorsing censorship. (And yes, I know that one person's censorship is another's parental controls.) My main concern, though, seems to be that this document presents a narrow slice of a broad issue, and does not lay clear the technical facts of the broader situation. Specifically, it lays out some examples where some parties may believe that it is desired to inject additional local information into a local view of the RPKI (or, roughly equivalently, to suppress such information). There are important details about what the two "local"s mean, who is authorized to impose such additional information, etc., but I think it is possible to write a useful document that does not reach a clearn answer on any of those questions. To be useful, though, we need to consider the consequences of having the capability to perform such local injection. There is new attack surface that must be protected from network attack, and a need for permissions/consent (contractual or otherwise) for the systems that are affected by the local view of the RPKI to trust the party/parties that are injecting the local view. Furthermore, there is a sizeable chance that the technical solutions to resolve these use cases will be technically unconstrained, allowing for the "local view" to fully override any and all of the RPKI, so the risk of granting such consent is potentially quite sizeable. I'm also a little concerned about the level of review that this document received; the responsible AD had to send it back to the WG once due to lack of evidence for consensus (https://mailarchive.ietf.org/arch/msg/sidrops/5IBDpQZdsqJeYrxIsSI37c8QxRw), and I did not see a great deal of additional feedback after that. (Perhaps I was looking in the wrong place?) |
2019-05-01
|
06 | Benjamin Kaduk | [Ballot comment] Abstract The phrasing "needs to" is very strong and implies that there is an absolute judgment that can be made as to the … [Ballot comment] Abstract The phrasing "needs to" is very strong and implies that there is an absolute judgment that can be made as to the validity of the operation, when my impression is that the topic remains rather controversial. The wording "will want to" used in the Introduction seems to be more accurate. (The word "critical" in "critical circumstances", present in both Abstract and Introduction, is also prone to criticisms of hyperbolism.) Section 1 This document attempts to lay out a few of those use cases. It is not intended to be authoritative, complete, or to become a standard. It is informative laying out a few critical examples to help frame the issues. I appreciate that this document does not intend to be authoritative or complete. But to say that it is "help[ing] frame the issues" borders on irresponsible -- it presents *a* framing in which these use cases are cast favorably, but (per the Discuss point) does not include in that framing some significant points that cause the use cases to be cast less favorably. Section 4 Carol, a resource holder (Local Internet Registry (LIR), Provider Independent address space (PI) holder, ...), operates outside of the country in which her Regional Internet Registry (RIR) is based. Is "legal jurisdiction" more on topic than "country", for the purposes of this example? Someone convinces the RIR's local court to force the RIR to remove or modify some or all of Carol's certificates, ROAs, etc. or the resources they represent, and the operational community wants to retain the ability to route to Carol's network(s). [...] It seems unlikely to me that this is a matter on which the operational community would achieve full consensus. Perhaps "a subset of" is appropriate? Alice is responsible for the trusted routing for a large organization, commercial or geo-political, in which management requests routing engineering to redirect their competitors' prefixes to socially acceptable data. [...] Both "competitors' prefixes" and "socially acceptable" have been mentioned already as potentially problematic phrasing, IIRC, but I will mention them again. (Also, I don't really understand what "geo-political organization" is intended to mean, but maybe that's just as well.) Section 5 One wants to reproduce only as much of the Global RPKI as needed. Replicating more than is needed would amplify tracking and maintenance. The text would probably benefit from a bit more about what is being tracked and by whom. (I assume it is not users being tracked by a surveilance state, though I can't quite exclude that possibility given just the text at hand.) One can not reissue down from the root trust anchor at the IANA or from the RIRs' certificates because one does not have the private keys required. So one has to create a new trust anchor which, for ease of use, will contain the new/modified certificates and ROAs as well as the unmodified remainder of the Global RPKI. I'm not really sure what sense "trust anchor" is being used in, here. It does not seem to match up with the one described in Section 2.4 of RFC 6480, for example. Because Alice, Bob, and Carol want to be able to archive, reproduce, and send to other operators the data necessary to reproduce their modified view of the global RPKI, there will need to be a formally defined set of data which is input to a well-defined process to take an existing Global RPKI tree and produce the desired modified re- anchored tree. This feels very incompletely described. (Yes, I know, "not intended to be complete". But there's a level of incompleteness that seems to not be worth publishing, and we may be close to it.) I also don't have a great sense of whether there's supposed to be a single "re-anchored tree" or a forest of trees, and whether the full global RPKI tree is a subtree of this re-anchored tree, or a replacement/copied version is present therein. Simplified Local Internet Number Resource Management with the RPKI (SLURM), [RFC8416], addresses many, but not all, of these issues and approaches. This document was originally a gating requirements document for SLURM and other approaches. The phrasing of this last sentence feels very unusual to me for an archival document. Section 6 "patching of trust" seems like a phrase without a clear meaning. Though, a large part of that is probably because "trust" itself is so hard to nail down... Modification 'recipes' may lack authentication. E.g., if modifications to the tree are passed around a la SLURM files, see [RFC8416], what was object security becomes, at best, transport security, or authentication by other trust domains such as PGP. Expounding on this with a couple more sentences would probably be worth the effort. |
2019-05-01
|
06 | Benjamin Kaduk | [Ballot Position Update] New position, Discuss, has been recorded for Benjamin Kaduk |
2019-05-01
|
06 | Alvaro Retana | [Ballot Position Update] New position, No Objection, has been recorded for Alvaro Retana |
2019-05-01
|
06 | Alvaro Retana | This document now replaces draft-ietf-sidr-lta-use-cases instead of None |
2019-05-01
|
06 | Roman Danyliw | [Ballot discuss] I had a few questions about use case #3. (1) I want to discuss what I see as a dissonance between use case … [Ballot discuss] I had a few questions about use case #3. (1) I want to discuss what I see as a dissonance between use case #3 (Section 4, “Alice is responsible for the trusted routing for a large organization …”) and the Security Considerations. It appears that use case #3 is explicitly describing an on-path attack per RFC3552. Is use case #3 a use case or an attack against RPKI? There seems to me to be an analog between use case #3 and the TLS/web MitM discussions where the consensus was not to standardize these features despite their existence. In what way do you see RPKI as different? (2) Thanks for the additional background in in [1]. More to clarity along the lines of Mirja’s DISCUSS, I’m trying to unpack the use case #3 text in Section 4. Original Text: “Alice is responsible for the trusted routing for a large organization, commercial or geo-political, in which management requests to redirect their competitors' prefixes to socially acceptable data.” If Alice is “(us|china|uk|justabouteverybody)” per [1], who is the “management” in the context of a government? Furthermore, “competitor’s” is confusing to me because it seems odd to characterize the networks of objectionable content as competitors to other governments. I would have read this text as “Alice is a network operator who has been directed to inspect and redirect select prefixes to …”. [1] https://mailarchive.ietf.org/arch/msg/sidrops/qGulOfrDPxXgMC9HLJWpXYeBOi4 |
2019-05-01
|
06 | Roman Danyliw | [Ballot comment] A few editorial nits: (1) Section 3. Editorial Nit. s/There are critical uses of the RPKI where a local administrative and/or routing domain, … [Ballot comment] A few editorial nits: (1) Section 3. Editorial Nit. s/There are critical uses of the RPKI where a local administrative and/or routing domain, e.g. an end-user site, a particular ISP or content provider, an organization, a geo-political region, ... may wish to have a specialized view of the RPK./ There are critical uses of the RPKI where a local administrative and/or routing domain (e.g., an end-user site, a particular ISP or content provider, an organization, a geo-political region) may wish to have a specialized view of the RPK./ (2) Section 4. Editorial Nit. s/(LIR, PI holder, …)/(e.g., LIR, PI holder)/ |
2019-05-01
|
06 | Roman Danyliw | [Ballot Position Update] New position, Discuss, has been recorded for Roman Danyliw |
2019-04-30
|
06 | Suresh Krishnan | [Ballot Position Update] New position, No Objection, has been recorded for Suresh Krishnan |
2019-04-30
|
06 | Amanda Baber | IANA Review state changed to IANA OK - No Actions Needed from Version Changed - Review Needed |
2019-04-30
|
06 | (System) | IANA Review state changed to Version Changed - Review Needed from IANA OK - No Actions Needed |
2019-04-30
|
06 | Randy Bush | New version available: draft-ietf-sidrops-lta-use-cases-06.txt |
2019-04-30
|
06 | (System) | New version approved |
2019-04-30
|
06 | (System) | Request for posting confirmation emailed to previous authors: Randy Bush |
2019-04-30
|
06 | Randy Bush | Uploaded new revision |
2019-04-29
|
05 | Adam Roach | [Ballot comment] Thanks for the work on this document. I have two minor editorial suggestions. --------------------------------------------------------------------------- Please expand the following acronyms upon first use and … [Ballot comment] Thanks for the work on this document. I have two minor editorial suggestions. --------------------------------------------------------------------------- Please expand the following acronyms upon first use and in the title; see https://www.rfc-editor.org/materials/abbrev.expansion.txt for guidance. - RPKI - LIR - PI - RIR - CA --------------------------------------------------------------------------- ID Nits reports: ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 177: '...eds. Hence they MUST be implemented t...' Please consider adding the boilerplate specified in RFC 8174. |
2019-04-29
|
05 | Adam Roach | [Ballot Position Update] New position, No Objection, has been recorded for Adam Roach |
2019-04-29
|
05 | Deborah Brungard | [Ballot Position Update] New position, No Objection, has been recorded for Deborah Brungard |
2019-04-29
|
05 | Mirja Kühlewind | [Ballot discuss] 1) I’m not sure I really understand the following use case..? Also is “re-routing to acceptable content” actually a use case we want … [Ballot discuss] 1) I’m not sure I really understand the following use case..? Also is “re-routing to acceptable content” actually a use case we want to endorse in an RFC? "Alice is responsible for the trusted routing for a large organization, commercial or geo-political, in which management requests routing engineering to redirect their competitors' prefixes to socially acceptable data. 2) This sentence in the security considerations section uses normative language without having the respective disclaimer in the document: “Hence they MUST be implemented to assure the local constraint.” However, I also don’t understand what such a normative statement is supposed to say. I’m not sure if local trust actors are the only solution to the stated use case/problems; if that’s what the sentence tries to say, I disagree, however, in any case it doesn’t seem to make sense to use normative wording here. 3) Also, this sentence in the security consideration section, needs probably more explanation: “Authentication of modification 'recipes' will be needed.” What is “will be needed” supposed to mean? How can this be achieved? What happens if it’s not implemented? |
2019-04-29
|
05 | Mirja Kühlewind | [Ballot Position Update] New position, Discuss, has been recorded for Mirja Kühlewind |
2019-04-22
|
05 | Barry Leiba | [Ballot Position Update] New position, No Objection, has been recorded for Barry Leiba |
2019-04-18
|
05 | Stewart Bryant | Request for Last Call review by RTGDIR Completed: Has Nits. Reviewer: Stewart Bryant. Sent review to list. |
2019-04-17
|
05 | Min Ye | Request for Last Call review by RTGDIR is assigned to Stewart Bryant |
2019-04-17
|
05 | Min Ye | Request for Last Call review by RTGDIR is assigned to Stewart Bryant |
2019-04-15
|
05 | Cindy Morgan | Placed on agenda for telechat - 2019-05-02 |
2019-04-15
|
05 | Warren Kumari | IESG state changed to IESG Evaluation from Waiting for Writeup |
2019-04-15
|
05 | Warren Kumari | Changed consensus to Yes from Unknown |
2019-04-15
|
05 | Warren Kumari | Ballot has been issued |
2019-04-15
|
05 | Warren Kumari | [Ballot Position Update] New position, Yes, has been recorded for Warren Kumari |
2019-04-15
|
05 | Warren Kumari | Created "Approve" ballot |
2019-04-15
|
05 | Warren Kumari | Ballot writeup was changed |
2019-04-11
|
05 | (System) | IESG state changed to Waiting for Writeup from In Last Call |
2019-04-09
|
05 | (System) | IANA Review state changed to IANA OK - No Actions Needed from IANA - Review Needed |
2019-04-09
|
05 | Sabrina Tanamal | (Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs: The IANA Functions Operator has reviewed draft-ietf-sidrops-lta-use-cases-05, which is currently in Last Call, and has the following comments: We … (Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs: The IANA Functions Operator has reviewed draft-ietf-sidrops-lta-use-cases-05, which is currently in Last Call, and has the following comments: We understand that this document doesn't require any registry actions. While it's often helpful for a document's IANA Considerations section to remain in place upon publication even if there are no actions, if the authors strongly prefer to remove it, we do not object. If this assessment is not accurate, please respond as soon as possible. Thank you, Sabrina Tanamal Senior IANA Services Specialist |
2019-04-08
|
05 | Luc André Burdet | Request for Last Call review by RTGDIR is assigned to Ron Bonica |
2019-04-08
|
05 | Luc André Burdet | Request for Last Call review by RTGDIR is assigned to Ron Bonica |
2019-04-03
|
05 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Tim Wicinski |
2019-04-03
|
05 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Tim Wicinski |
2019-04-03
|
05 | Min Ye | Request for Last Call review by RTGDIR is assigned to Emmanuel Baccelli |
2019-04-03
|
05 | Min Ye | Request for Last Call review by RTGDIR is assigned to Emmanuel Baccelli |
2019-03-28
|
05 | Jean Mahoney | Request for Last Call review by GENART is assigned to Pete Resnick |
2019-03-28
|
05 | Jean Mahoney | Request for Last Call review by GENART is assigned to Pete Resnick |
2019-03-22
|
05 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Alexey Melnikov |
2019-03-22
|
05 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Alexey Melnikov |
2019-03-22
|
05 | Min Ye | Request for Last Call review by RTGDIR is assigned to John Scudder |
2019-03-22
|
05 | Min Ye | Request for Last Call review by RTGDIR is assigned to John Scudder |
2019-03-21
|
05 | Alvaro Retana | Requested Last Call review by RTGDIR |
2019-03-21
|
05 | Cindy Morgan | The following Last Call announcement was sent out (ends 2019-04-11): From: The IESG To: IETF-Announce CC: sidrops-chairs@ietf.org, sidrops@ietf.org, draft-ietf-sidrops-lta-use-cases@ietf.org, Chris Morrow , … The following Last Call announcement was sent out (ends 2019-04-11): From: The IESG To: IETF-Announce CC: sidrops-chairs@ietf.org, sidrops@ietf.org, draft-ietf-sidrops-lta-use-cases@ietf.org, Chris Morrow , warren@kumari.net, morrowc@ops-netman.net Reply-To: ietf@ietf.org Sender: Subject: Last Call: (Use Cases for Localized Versions of the RPKI) to Informational RFC The IESG has received a request from the SIDR Operations WG (sidrops) to consider the following document: - 'Use Cases for Localized Versions of the RPKI' as Informational RFC 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 2019-04-11. 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 There are a number of critical circumstances where a localized routing domain needs to augment or modify its view of the Global RPKI. This document attempts to outline a few of them. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-sidrops-lta-use-cases/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-sidrops-lta-use-cases/ballot/ No IPR declarations have been submitted directly on this I-D. |
2019-03-21
|
05 | Cindy Morgan | IANA Review state changed to IANA - Review Needed |
2019-03-21
|
05 | Cindy Morgan | The following Last Call announcement was sent out (ends 2019-04-04): From: The IESG To: IETF-Announce CC: sidrops-chairs@ietf.org, sidrops@ietf.org, draft-ietf-sidrops-lta-use-cases@ietf.org, Chris Morrow , … The following Last Call announcement was sent out (ends 2019-04-04): From: The IESG To: IETF-Announce CC: sidrops-chairs@ietf.org, sidrops@ietf.org, draft-ietf-sidrops-lta-use-cases@ietf.org, Chris Morrow , warren@kumari.net, morrowc@ops-netman.net Reply-To: ietf@ietf.org Sender: Subject: Last Call: (Use Cases for Localized Versions of the RPKI) to Informational RFC The IESG has received a request from the SIDR Operations WG (sidrops) to consider the following document: - 'Use Cases for Localized Versions of the RPKI' as Informational RFC 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 2019-04-11. 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 There are a number of critical circumstances where a localized routing domain needs to augment or modify its view of the Global RPKI. This document attempts to outline a few of them. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-sidrops-lta-use-cases/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-sidrops-lta-use-cases/ballot/ No IPR declarations have been submitted directly on this I-D. |
2019-03-21
|
05 | Cindy Morgan | IESG state changed to In Last Call from Last Call Requested |
2019-03-21
|
05 | Cindy Morgan | Last call announcement was changed |
2019-03-21
|
05 | Warren Kumari | Last call was requested |
2019-03-21
|
05 | Warren Kumari | Last call announcement was generated |
2019-03-21
|
05 | Warren Kumari | Ballot approval text was generated |
2019-03-21
|
05 | Warren Kumari | Ballot writeup was generated |
2019-03-21
|
05 | Warren Kumari | IESG state changed to Last Call Requested from Publication Requested |
2019-03-10
|
05 | 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? Informational (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. "There are a number of critical circumstances where a localized routing domain needs to augment or modify its view of the Global RPKI. This document attempts to outline a few of them." 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? This document went through both SIDR and SIDROPS (where it is today). It's gotten significant re-write and revisions in SIDR, and has decent consensus to move forward in SIDROPS. 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? no new implementations here. pls drive thru! Personnel Who is the Document Shepherd? Who is the Responsible Area Director? Shepherd: Chris Morrow - morrowc@ops-netman.net AD: Warren Kumari - warren@kumari.net (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. Document was reviewed in it's original several forms, and through SIDR's time with it, as well as a final read before WGLC in SIDROPS. (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. nope (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 IPR (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. no (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? good enough. (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 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. Nits says nothing to be concerned with, there are some references which will auto-update upon editor workage. (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews. no review 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 (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). no considerations to review. (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. none (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. none required. |
2019-03-10
|
05 | Chris Morrow | IESG state changed to Publication Requested from AD is watching |
2019-03-10
|
05 | Randy Bush | New version available: draft-ietf-sidrops-lta-use-cases-05.txt |
2019-03-10
|
05 | (System) | New version approved |
2019-03-10
|
05 | (System) | Request for posting confirmation emailed to previous authors: Randy Bush |
2019-03-10
|
05 | Randy Bush | Uploaded new revision |
2019-01-12
|
04 | Warren Kumari | IESG state changed to AD is watching from Publication Requested |
2019-01-03
|
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? Informational (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. "There are a number of critical circumstances where a localized routing domain needs to augment or modify its view of the Global RPKI. This document attempts to outline a few of them." 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? This document went through both SIDR and SIDROPS (where it is today). It's gotten significant re-write and revisions in SIDR, and has decent consensus to move forward in SIDROPS. 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? no new implementations here. pls drive thru! Personnel Who is the Document Shepherd? Who is the Responsible Area Director? Shepherd: Chris Morrow - morrowc@ops-netman.net AD: Warren Kumari - warren@kumari.net (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. Document was reviewed in it's original several forms, and through SIDR's time with it, as well as a final read before WGLC in SIDROPS. (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. nope (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 IPR (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. no (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? good enough. (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 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. Nits says nothing to be concerned with, there are some references which will auto-update upon editor workage. (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews. no review 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 (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). no considerations to review. (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. none (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. none required. |
2019-01-03
|
04 | Chris Morrow | Responsible AD changed to Warren Kumari |
2019-01-03
|
04 | Chris Morrow | IETF WG state changed to Submitted to IESG for Publication from WG Document |
2019-01-03
|
04 | Chris Morrow | IESG state changed to Publication Requested from I-D Exists |
2019-01-03
|
04 | Chris Morrow | IESG process started in state Publication Requested |
2019-01-03
|
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? Informational (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. "There are a number of critical circumstances where a localized routing domain needs to augment or modify its view of the Global RPKI. This document attempts to outline a few of them." 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? This document went through both SIDR and SIDROPS (where it is today). It's gotten significant re-write and revisions in SIDR, and has decent consensus to move forward in SIDROPS. 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? no new implementations here. pls drive thru! Personnel Who is the Document Shepherd? Who is the Responsible Area Director? Shepherd: Chris Morrow - morrowc@ops-netman.net AD: Warren Kumari - warren@kumari.net (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. Document was reviewed in it's original several forms, and through SIDR's time with it, as well as a final read before WGLC in SIDROPS. (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. nope (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 IPR (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. no (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? good enough. (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 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. Nits says nothing to be concerned with, there are some references which will auto-update upon editor workage. (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews. no review 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 (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). no considerations to review. (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. none (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. none required. |
2019-01-03
|
04 | Chris Morrow | Intended Status changed to Informational from None |
2019-01-03
|
04 | Chris Morrow | Notification list changed to Chris Morrow <morrowc@ops-netman.net> |
2019-01-03
|
04 | Chris Morrow | Document shepherd changed to Chris Morrow |
2018-10-01
|
04 | Randy Bush | New version available: draft-ietf-sidrops-lta-use-cases-04.txt |
2018-10-01
|
04 | (System) | New version approved |
2018-10-01
|
04 | (System) | Request for posting confirmation emailed to previous authors: Randy Bush |
2018-10-01
|
04 | Randy Bush | Uploaded new revision |
2018-04-10
|
03 | Randy Bush | New version available: draft-ietf-sidrops-lta-use-cases-03.txt |
2018-04-10
|
03 | (System) | New version approved |
2018-04-10
|
03 | (System) | Request for posting confirmation emailed to previous authors: Randy Bush |
2018-04-10
|
03 | Randy Bush | Uploaded new revision |
2017-11-14
|
02 | Chris Morrow | Added to session: IETF-100: sidrops Wed-1330 |
2017-10-16
|
02 | Randy Bush | New version available: draft-ietf-sidrops-lta-use-cases-02.txt |
2017-10-16
|
02 | (System) | New version approved |
2017-10-16
|
02 | (System) | Request for posting confirmation emailed to previous authors: Randy Bush |
2017-10-16
|
02 | Randy Bush | Uploaded new revision |
2017-04-15
|
01 | Randy Bush | New version available: draft-ietf-sidrops-lta-use-cases-01.txt |
2017-04-15
|
01 | (System) | New version approved |
2017-04-15
|
01 | (System) | Request for posting confirmation emailed to previous authors: Randy Bush |
2017-04-15
|
01 | Randy Bush | Uploaded new revision |
2016-12-29
|
00 | Randy Bush | New version available: draft-ietf-sidrops-lta-use-cases-00.txt |
2016-12-29
|
00 | (System) | WG -00 approved |
2016-12-29
|
00 | Randy Bush | Set submitter to "Randy Bush ", replaces to (none) and sent approval email to group chairs: sidrops-chairs@ietf.org |
2016-12-29
|
00 | Randy Bush | Uploaded new revision |