Expert Review for Incident Object Description Exchange Format (IODEF) Extensions in IANA XML Registry
draft-ietf-mile-iodef-xmlreg-01
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2012-06-19
|
01 | Samuel Weiler | Request for Last Call review by SECDIR Completed: Ready. Reviewer: Carl Wallace. |
2012-06-13
|
01 | (System) | IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor |
2012-06-13
|
01 | (System) | IANA Action state changed to Waiting on RFC Editor from Waiting on Authors |
2012-06-12
|
01 | (System) | IANA Action state changed to Waiting on Authors from In Progress |
2012-06-12
|
01 | Amy Vezza | State changed to RFC Ed Queue from Approved-announcement sent |
2012-06-11
|
01 | (System) | IANA Action state changed to In Progress |
2012-06-11
|
01 | Amy Vezza | State changed to Approved-announcement sent from Approved-announcement to be sent |
2012-06-11
|
01 | Amy Vezza | IESG has approved the document |
2012-06-11
|
01 | Amy Vezza | Closed "Approve" ballot |
2012-06-11
|
01 | Amy Vezza | Ballot writeup was changed |
2012-06-07
|
01 | Cindy Morgan | State changed to Approved-announcement to be sent from IESG Evaluation |
2012-06-07
|
01 | Pete Resnick | [Ballot comment] This document defines no protocol, does not say how to implement a protocol, and does not have anything to do with a protocol … [Ballot comment] This document defines no protocol, does not say how to implement a protocol, and does not have anything to do with a protocol except for information about how an IANA registry is to be used. This should be BCP. |
2012-06-07
|
01 | Pete Resnick | [Ballot Position Update] Position for Pete Resnick has been changed to Abstain from Discuss |
2012-06-07
|
01 | Stewart Bryant | [Ballot Position Update] New position, No Objection, has been recorded for Stewart Bryant |
2012-06-06
|
01 | Ralph Droms | [Ballot Position Update] New position, No Objection, has been recorded for Ralph Droms |
2012-06-06
|
01 | Gonzalo Camarillo | [Ballot Position Update] New position, No Objection, has been recorded for Gonzalo Camarillo |
2012-06-05
|
01 | Pete Resnick | [Ballot discuss] This document defines no protocol, does not say how to implement a protocol, and does not have anything to do with a protocol … [Ballot discuss] This document defines no protocol, does not say how to implement a protocol, and does not have anything to do with a protocol except for information about how an IANA registry is to be used. Why is this going on the standards track? This should either be Informational, or more likely BCP. |
2012-06-05
|
01 | Pete Resnick | [Ballot Position Update] New position, Discuss, has been recorded for Pete Resnick |
2012-06-05
|
01 | Suresh Krishnan | Request for Last Call review by GENART Completed. Reviewer: Suresh Krishnan. |
2012-06-05
|
01 | Robert Sparks | [Ballot comment] Consider "designated by the IESG" instead of "designated by the IETF Security Area Directors." |
2012-06-05
|
01 | Robert Sparks | [Ballot Position Update] New position, No Objection, has been recorded for Robert Sparks |
2012-06-05
|
01 | Russ Housley | [Ballot comment] Please consider the editorial comments in the Gen-ART Review by Suresh Krishnan on 5-Jun-2012. The review can be found here: … [Ballot comment] Please consider the editorial comments in the Gen-ART Review by Suresh Krishnan on 5-Jun-2012. The review can be found here: http://www.ietf.org/mail-archive/web/gen-art/current/msg07483.html |
2012-06-05
|
01 | Russ Housley | [Ballot Position Update] New position, No Objection, has been recorded for Russ Housley |
2012-06-05
|
01 | Benoît Claise | [Ballot comment] Section 1, Introduction IODEF extensions via class extension through AdditionalData and RecordItem elements, as per section 5.2 of [RFC5070], generally … [Ballot comment] Section 1, Introduction IODEF extensions via class extension through AdditionalData and RecordItem elements, as per section 5.2 of [RFC5070], generally register their namespaces and schemas with the IANA XML Namespace registry at ... => remove "generally" - There is one nit catched by the nit checker: => The draft header indicates that this document updates RFC5070, but the abstract doesn't seem to mention this, which it should. |
2012-06-05
|
01 | Benoît Claise | Ballot comment text updated for Benoit Claise |
2012-06-05
|
01 | Benoît Claise | [Ballot comment] Section 1, Introduction IODEF extensions via class extension through AdditionalData and RecordItem elements, as per section 5.2 of [RFC5070], generally … [Ballot comment] Section 1, Introduction IODEF extensions via class extension through AdditionalData and RecordItem elements, as per section 5.2 of [RFC5070], generally register their namespaces and schemas with the IANA XML Namespace registry at ... => remove "generally" |
2012-06-05
|
01 | Benoît Claise | [Ballot Position Update] New position, No Objection, has been recorded for Benoit Claise |
2012-06-05
|
01 | Stephen Farrell | [Ballot Position Update] New position, No Objection, has been recorded for Stephen Farrell |
2012-06-05
|
01 | Barry Leiba | [Ballot Position Update] New position, No Objection, has been recorded for Barry Leiba |
2012-06-04
|
01 | Wesley Eddy | [Ballot Position Update] New position, No Objection, has been recorded for Wesley Eddy |
2012-06-04
|
01 | Pearl Liang | IANA has reviewed draft-ietf-mile-iodef-xmlreg-01 and has the following comments: IANA understands that, upon approval of this document, there is a single IANA action which must … IANA has reviewed draft-ietf-mile-iodef-xmlreg-01 and has the following comments: IANA understands that, upon approval of this document, there is a single IANA action which must be completed. The registration procedures for a subset of the IANA XML namespace registry are to be changed. IANA understands that the registry located at: http://www.iana.org/assignments/xml-registry/ns.html is to have its registration procedures changed as follows: Schema names beginning with "urn:ietf:params:xml:schema:iodef" are subject to an additional IODEF Expert Review, as defined by RFC 5226, for IODEF-correctness and -appropriateness. The IODEF expert(s) for these reviews will be designated by the IETF Security Area Directors. IANA understands that this is the only IANA action required by the 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. |
2012-06-04
|
01 | Ron Bonica | [Ballot Position Update] New position, No Objection, has been recorded for Ronald Bonica |
2012-06-04
|
01 | Brian Haberman | [Ballot Position Update] New position, No Objection, has been recorded for Brian Haberman |
2012-06-04
|
01 | Martin Stiemerling | [Ballot Position Update] New position, No Objection, has been recorded for Martin Stiemerling |
2012-06-01
|
01 | Adrian Farrel | [Ballot Position Update] New position, No Objection, has been recorded for Adrian Farrel |
2012-05-30
|
01 | Sean Turner | State changed to IESG Evaluation from Waiting for AD Go-Ahead |
2012-05-30
|
01 | (System) | State changed to Waiting for AD Go-Ahead from In Last Call |
2012-05-29
|
01 | Sean Turner | Ballot has been issued |
2012-05-29
|
01 | Sean Turner | [Ballot Position Update] New position, Yes, has been recorded for Sean Turner |
2012-05-29
|
01 | Sean Turner | Ballot writeup was changed |
2012-05-29
|
01 | Sean Turner | Created "Approve" ballot |
2012-05-18
|
01 | Samuel Weiler | Request for Last Call review by SECDIR is assigned to Carl Wallace |
2012-05-18
|
01 | Samuel Weiler | Request for Last Call review by SECDIR is assigned to Carl Wallace |
2012-05-17
|
01 | Jean Mahoney | Assignment of request for Last Call review by GENART to Miguel Garcia was rejected |
2012-05-17
|
01 | Jean Mahoney | Request for Last Call review by GENART is assigned to Suresh Krishnan |
2012-05-17
|
01 | Jean Mahoney | Request for Last Call review by GENART is assigned to Suresh Krishnan |
2012-05-17
|
01 | Jean Mahoney | Request for Last Call review by GENART is assigned to Miguel Garcia |
2012-05-17
|
01 | Jean Mahoney | Request for Last Call review by GENART is assigned to Miguel Garcia |
2012-05-16
|
01 | Sean Turner | Placed on agenda for telechat - 2012-06-07 |
2012-05-16
|
01 | Cindy Morgan | The following Last Call announcement was sent out: From: The IESG To: IETF-Announce CC: Reply-To: ietf@ietf.org Subject: Last Call: (Expert Review for IODEF Extensions in … The following Last Call announcement was sent out: From: The IESG To: IETF-Announce CC: Reply-To: ietf@ietf.org Subject: Last Call: (Expert Review for IODEF Extensions in IANA XML Registry) to Proposed Standard The IESG has received a request from the Managed Incident Lightweight Exchange WG (mile) to consider the following document: - 'Expert Review for IODEF Extensions in IANA XML Registry' 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 2012-05-30. 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 This document specifies restrictions on additions to the subset of the IANA XML Namespace and Schema registries, to require Expert Review for extensions to IODEF. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-mile-iodef-xmlreg/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-mile-iodef-xmlreg/ballot/ No IPR declarations have been submitted directly on this I-D. |
2012-05-16
|
01 | Cindy Morgan | State changed to In Last Call from Last Call Requested |
2012-05-16
|
01 | Sean Turner | Last call was requested |
2012-05-16
|
01 | Sean Turner | Ballot approval text was generated |
2012-05-16
|
01 | Sean Turner | State changed to Last Call Requested from AD Evaluation |
2012-05-16
|
01 | Sean Turner | Last call announcement was generated |
2012-05-16
|
01 | Sean Turner | State changed to AD Evaluation from Publication Requested |
2012-05-16
|
01 | Sean Turner | Ballot writeup was changed |
2012-05-16
|
01 | Sean Turner | This document is at -01, but it was originally part of draft-ietf-mile-template. I made them split out the IANA considerations from the templates draft because … This document is at -01, but it was originally part of draft-ietf-mile-template. I made them split out the IANA considerations from the templates draft because the updated IANA considerations was the only part of the templates draft that needed to be standards track. This one needs to be standards track to update RFC 5070. Also note the answer to #18 in the proto write-up. I'll add something similar in the IANA considerations section in the Ballot write-up. |
2012-05-16
|
01 | Sean Turner | Ballot writeup was generated |
2012-05-16
|
01 | Cindy Morgan | (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Standards Track, Updates RFC5070. Why is this … (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Standards Track, Updates RFC5070. Why is this the proper type of RFC? It provides an update to the IANA XML Registry for IODEF extensions and IODEF is standards track. Is this type of RFC indicated in the title page header? Yes. (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 'Expert Review for IODEF Extensions in IANA XML Registry' (draft-ietf-mile-iodef-xmlreg-01.txt) specifies restrictions on additions to the subset of the IANA XML Namespace and Schema registries, to require Expert Review for extensions to the Incident Object Description Exchange Format (IODEF). IODEF is specified in RFC5070. 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? No. The document requires and expert review on IODEF extensions, very straightforward from the WG perspective. 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? Yes, there are several implementations of RFC5070 and extensions. This document does not specify anything that requires implementation, just requires an expert review on any new extensions. Personnel: Who is the Document Shepherd? Kathleen Moriarty Who is the Responsible Area Director? Sean Turner (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. I read through the document, and am also very familiar with IODEF, so I had the necessary context. I looked through the idnits report and see the finding that RFC5070 is not mentioned. IODEF is specified in RFC5070, so this could be added after the IODEF reference if needed. It would be fine to do this in Auth48. (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. The WG reviewed this in the first WGLC and again after it was separated out from the template document in a second last call. In the second last call, I reviewed the document as did the Security AD. All comments were addressed. (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. (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? Solid consensus. The draft is straightforward. (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. (11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough. The idnits showed RFC5070 was not listed in the abstract. The abstract does mention IODEF, so this reference could easily be added following IODEF as that is RFC5070. (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews. N/A. (13) Have all references within this document been identified as either normative or informative? There are only normative references. (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. It updates RFC5070. It does not change the status of RFC5070 as the update is just to the IANA section to require an expert review on any extensions to RFC5070. (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). Confirmed, the IANA section looks good. It has been reviewed by the document shepherd, the Security AD, and working group members very familiar with IANA requirements. (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. The draft references an existing registry, adding a requirement for an expert review. The Security AD is responsible to assign an expert for the review. If the MILE WG is active at the time the request is made, the expert may be indentified in MILE. The registry is the IANA XML Registry and the request is to perform an IODEF Expert Review [RFC5226] on schemas with names beginning with 'urn:ietf:params:xml:schema:iodef', NOTE: There's no expectation that this expert will be an XML expert. This will mean there are two designated experts: one for the XML schema and one for the IODEF. We have had discussions with IANA about this and it seems like this will be doable. (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. There is no XML or other code. The registry location, URL, and namespaces were verified. |
2012-05-16
|
01 | Cindy Morgan | Note added 'Kathleen Moriarty (Kathleen.Moriarty@emc.com) is the document shepherd.' |
2012-05-16
|
01 | Cindy Morgan | Intended Status changed to Proposed Standard |
2012-05-16
|
01 | Cindy Morgan | IESG process started in state Publication Requested |
2012-05-16
|
01 | (System) | Earlier history may be found in the Comment Log for draft-trammell-mile-iodef-xmlreg |
2012-05-09
|
01 | Brian Trammell | New version available: draft-ietf-mile-iodef-xmlreg-01.txt |
2012-04-18
|
00 | Brian Trammell | New version available: draft-ietf-mile-iodef-xmlreg-00.txt |