A Framework for Large-Scale Measurement of Broadband Performance (LMAP)
draft-ietf-lmap-framework-14
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2015-09-11
|
14 | (System) | RFC Editor state changed to AUTH48-DONE from AUTH48 |
2015-07-13
|
14 | (System) | RFC Editor state changed to AUTH48 from RFC-EDITOR |
2015-07-06
|
14 | (System) | RFC Editor state changed to RFC-EDITOR from EDIT |
2015-07-02
|
14 | Jean Mahoney | Closed request for Telechat review by GENART with state 'No Response' |
2015-04-30
|
14 | Amy Vezza | IESG state changed to RFC Ed Queue from Approved-announcement sent |
2015-04-30
|
14 | (System) | RFC Editor state changed to EDIT |
2015-04-30
|
14 | (System) | Announcement was received by RFC Editor |
2015-04-29
|
14 | (System) | IANA Action state changed to No IC from In Progress |
2015-04-29
|
14 | (System) | IANA Action state changed to In Progress |
2015-04-29
|
14 | Amy Vezza | IESG state changed to Approved-announcement sent from Approved-announcement to be sent::Point Raised - writeup needed |
2015-04-29
|
14 | Amy Vezza | IESG has approved the document |
2015-04-29
|
14 | Amy Vezza | Closed "Approve" ballot |
2015-04-29
|
14 | Amy Vezza | Ballot approval text was generated |
2015-04-29
|
14 | Amy Vezza | Ballot writeup was changed |
2015-04-29
|
14 | Philip Eardley | New version available: draft-ietf-lmap-framework-14.txt |
2015-04-17
|
13 | Philip Eardley | IANA Review state changed to Version Changed - Review Needed from IANA OK - No Actions Needed |
2015-04-17
|
13 | Philip Eardley | New version available: draft-ietf-lmap-framework-13.txt |
2015-04-09
|
12 | Gunter Van de Velde | Request for Last Call review by OPSDIR Completed: Has Issues. Reviewer: Sarah Banks. |
2015-04-09
|
12 | Cindy Morgan | IESG state changed to Approved-announcement to be sent::Point Raised - writeup needed from IESG Evaluation |
2015-04-09
|
12 | Stephen Farrell | [Ballot comment] - general: Thanks for the significant consideration of privacy, the draft has a quite good analysis. I want to check though that the … [Ballot comment] - general: Thanks for the significant consideration of privacy, the draft has a quite good analysis. I want to check though that the plan is that other lmap drafts, esp protocol drafts, will in fact describe (and maybe mandate) ways to meet privacy goals, and will not simply refer to section 8 of this and tell developers to go figure it out. If that latter was the plan/expectation, then we'd be better off discussing that now, rather than as a late surprise for the WG. I assume though that the plan is rather to try make the lmap protocol something that can really be used in a privacy sensitive manner and that defaults to that where possible, in which case we'll not have that problem. - One way in which it might be possible to provide evidence that a system respects user privacy would be to have some kind of auditor entity as part of the framework. For example, an MA could be setup to send some selection of reports/instructions to (or encrypted for) the auditor as well as to the normal destination. Did the WG consider such an entity? (This is not a DISCUSS as I can see pros and cons in the auditor-approach, so I'm not sure if it'd be a good idea in the end.) - Thanks for section 8, one suggestion - I'd argue that "privacy respecting/friendly" ought be a bullet at the end of section 1, as if the system is not, then it'll eventually be turned off, one way or another. If you agree, I'd be happy. If not, I'll not get in the way. - 5.4 (and elsewhere) I'm not sure a Group-ID by itself is sufficient to hide identity (timing and soure addressing may expose it anyway). That should be noted, and that lmap protocols should be analysed to see what turns out to be the case. I'm not sure talking about "anonymising" is really correct as anonymity is a very very hard thing to achieve. - section 8: I'm not that keen on considering the privacy of organisations at the same level as that of people. I can see why you might do it but that is also often done as a way to minimise the privacy of people. - section 8: I didn't spot considerations related to re-identification, which can be significant. E.g. if I can see other traffic that identifies a person and the re-identify that person based on LMAP trafic later on (or elsewhere). Did the WG consider that? - section 8: I'm not sure that the "user consent" thing is really of that much benefit here (and it's ubiquitously abused on the Internet today). It would have been welcome had the WG come up with something better, but then since I don't have a solution to hand, I can't insist that you do;-) |
2015-04-09
|
12 | Stephen Farrell | [Ballot Position Update] New position, No Objection, has been recorded for Stephen Farrell |
2015-04-09
|
12 | Alia Atlas | [Ballot Position Update] New position, No Objection, has been recorded for Alia Atlas |
2015-04-09
|
12 | Jari Arkko | [Ballot Position Update] New position, No Objection, has been recorded for Jari Arkko |
2015-04-09
|
12 | Barry Leiba | [Ballot Position Update] New position, No Objection, has been recorded for Barry Leiba |
2015-04-08
|
12 | Kathleen Moriarty | [Ballot comment] Thank you for your very careful and detailed attention to security and privacy, with options suggested to protect privacy in practice through group … [Ballot comment] Thank you for your very careful and detailed attention to security and privacy, with options suggested to protect privacy in practice through group ids instead of ones that identify an individual. I just have one question. The security considerations section has a lower case 'must' for providing session encryption, but then the privacy section warns that monitoring can be possible when sessions are not encrypted. When I saw the privacy considerations, I went back to the security section to make sure active attacks against session traffic that was not encrypted was addressed as I didn't see this same 'must' and by that time needed to go back to make sure something as in place. I'm wondering why these weren't just addressed together since more security things could happen too if sessions were not encrypted (in other words, there could be less text, unless I am missing something and we need more on the security side). Thanks! |
2015-04-08
|
12 | Kathleen Moriarty | [Ballot Position Update] New position, No Objection, has been recorded for Kathleen Moriarty |
2015-04-08
|
12 | Ben Campbell | [Ballot comment] Section 1, paragraph starting with "Broadly speaking there are two types of Measurement Method. " s / Method / Methods Figures: Several figures … [Ballot comment] Section 1, paragraph starting with "Broadly speaking there are two types of Measurement Method. " s / Method / Methods Figures: Several figures that start at the top of the page have the first line out of alignment. Figure numbers might be useful. (For example, had there been numbers I could have referenced the figures with the alignment problem :-) ) |
2015-04-08
|
12 | Ben Campbell | [Ballot Position Update] New position, No Objection, has been recorded for Ben Campbell |
2015-04-08
|
12 | Terry Manderson | [Ballot Position Update] New position, No Objection, has been recorded for Terry Manderson |
2015-04-08
|
12 | Deborah Brungard | [Ballot Position Update] New position, No Objection, has been recorded for Deborah Brungard |
2015-04-08
|
12 | Joel Jaeggli | [Ballot Position Update] New position, No Objection, has been recorded for Joel Jaeggli |
2015-04-08
|
12 | Alvaro Retana | [Ballot comment] This document provides a framework, as such it is not defining the specific final pieces. Section 2 reads: Other LMAP specifications will … [Ballot comment] This document provides a framework, as such it is not defining the specific final pieces. Section 2 reads: Other LMAP specifications will define an information model, the associated data models, and select/extend one or more protocols for the secure communication: . . . I believe there are at least 2 superfluous forward references that the document can live without. 1. Information Model. For example, in Section 5: The protocol model is closely related to the Information Model [I-D.ietf-lmap-information-model], which is the abstract definition of the information carried by the protocol. (If there is any difference between this document and the Information Model, the latter is definitive, since it is on the standards track.) The purpose of both is to provide a protocol and device independent view, which can be implemented via specific protocols. LMAP defines a specific Control Protocol and Report Protocol, but others could be defined by other standards bodies or be proprietary. However it is important that they all implement the same Information Model and protocol model, in order to ease the definition, operation and interoperability of large-scale Measurement Systems. Reference is made to Information Model work in progress that could match this document. Given the disclaimer in the text about potential differences, I think that leaving a reference in the text could cause confusion. IOW, I'm suggesting you take out the reference and the disclaimer, and just let the Information Model draft speak for itself. 2. Registry for Performance Metrics. Section 5.2.2: o the Measurement Task configurations, each of which needs: * the Metric, specified as a URI to a registry entry; it includes the specification of a Measurement Method. The registry could be defined by the IETF [I-D.ietf-ippm-metric-registry], locally by the operator of the Measurement System or perhaps by another standards organisation. The framework is leaving the door open for multiple ways to define a registry, but is making reference to a specific one (still WIP)..it just causes confusion. Neither of these comments are major, not do they take away from the technical value of the document. Mostly suggestions to improve the clarity of what the framework is proposing. |
2015-04-08
|
12 | Alvaro Retana | [Ballot Position Update] New position, No Objection, has been recorded for Alvaro Retana |
2015-04-06
|
12 | Spencer Dawkins | [Ballot Position Update] New position, No Objection, has been recorded for Spencer Dawkins |
2015-04-02
|
12 | Jean Mahoney | Request for Telechat review by GENART is assigned to Tom Taylor |
2015-04-02
|
12 | Jean Mahoney | Request for Telechat review by GENART is assigned to Tom Taylor |
2015-03-23
|
12 | Benoît Claise | Ballot has been issued |
2015-03-23
|
12 | Benoît Claise | [Ballot Position Update] New position, Yes, has been recorded for Benoit Claise |
2015-03-23
|
12 | Benoît Claise | Created "Approve" ballot |
2015-03-23
|
12 | Benoît Claise | Ballot writeup was changed |
2015-03-23
|
12 | Benoît Claise | 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. It's in the page header. (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 Measuring broadband service on a large scale requires a description of the logical architecture and standardization of the key protocols that coordinate interactions between the components. The document presents an overall framework for large-scale measurements. It also defines terminology for LMAP (large-scale measurement platforms). Working Group Summary The Working Group process was serious and a relative large number of participants participated. Some of the points that required clarification and further editing were related to passive monitoring and to privacy. ll ended in consensus behind the document as it was forwarded for approval and publication. Document Quality The document was very carefully reviewed and discussed by a large number of participants in the WG, because it contains key information concerning the scope, architecture and components of the recommended solutions. Several issues were debated for many months, the resulting document includes a strong consensus of the participants about the goals (and non goals) of LMAP and the path to be taken by the IETF to provide a standard solution. Personnel Who is the Document Shepherd? Who is the Responsible Area Director? Dan Romascanu is the document shepherd. Benoit Claise is the responsible Area Director. (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 have reviewed in detail every version of this document including the one that is now submitted. (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? No. (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. There is a broad industry interest for this work, and for this purpose liaison statements were exchanged with other organizations such as the BBF and the IEEE 802. We recommend sending the IETF Last Call announcement to these organizations and invite them to participate. (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 concern. (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 IPR disclosures have been submitted. (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? The consensus is solid and the participation base is healthy in numbers. (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. No problems. idnits complains about one date-in-the past, three false alarms on references, and one updated reference. (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews. no need (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. (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 (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 (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. N/A |
2015-03-13
|
12 | Benoît Claise | Placed on agenda for telechat - 2015-04-09 |
2015-03-13
|
12 | Benoît Claise | IESG state changed to IESG Evaluation from Waiting for Writeup |
2015-03-13
|
12 | Benoît Claise | Changed consensus to Yes from Unknown |
2015-03-12
|
12 | Tero Kivinen | Request for Last Call review by SECDIR Completed: Ready. Reviewer: Radia Perlman. |
2015-03-12
|
12 | Naveen Khan | New revision available |
2015-03-09
|
11 | (System) | IESG state changed to Waiting for Writeup from In Last Call |
2015-03-02
|
11 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Radia Perlman |
2015-03-02
|
11 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Radia Perlman |
2015-03-01
|
11 | (System) | IANA Review state changed to IANA OK - No Actions Needed from IANA - Review Needed |
2015-03-01
|
11 | Amanda Baber | IESG/Authors/WG Chairs: IANA has reviewed draft-ietf-lmap-framework-11, which is currently in Last Call, and has the following comments: We understand that this document doesn't require … IESG/Authors/WG Chairs: IANA has reviewed draft-ietf-lmap-framework-11, which is currently in Last Call, and has the following comments: We understand that this document doesn't require any IANA actions. While it is helpful for the IANA Considerations section of the document to remain in place upon publication, if the authors prefer to remove it, IANA doesn't object. If this assessment is not accurate, please respond as soon as possible. |
2015-03-01
|
11 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Sarah Banks |
2015-03-01
|
11 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Sarah Banks |
2015-02-25
|
11 | Jean Mahoney | Request for Last Call review by GENART is assigned to Tom Taylor |
2015-02-25
|
11 | Jean Mahoney | Request for Last Call review by GENART is assigned to Tom Taylor |
2015-02-23
|
11 | Amy Vezza | IANA Review state changed to IANA - Review Needed |
2015-02-23
|
11 | Amy Vezza | The following Last Call announcement was sent out: From: The IESG To: IETF-Announce CC: Reply-To: ietf@ietf.org Sender: Subject: Last Call: (A framework for Large-Scale Measurement … The following Last Call announcement was sent out: From: The IESG To: IETF-Announce CC: Reply-To: ietf@ietf.org Sender: Subject: Last Call: (A framework for Large-Scale Measurement of Broadband Performance (LMAP)) to Informational RFC The IESG has received a request from the Large-Scale Measurement of Broadband Performance WG (lmap) to consider the following document: - 'A framework for Large-Scale Measurement of Broadband Performance (LMAP)' 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 2015-03-09. 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 Measuring broadband service on a large scale requires a description of the logical architecture and standardisation of the key protocols that coordinate interactions between the components. The document presents an overall framework for large-scale measurements. It also defines terminology for LMAP (Large-Scale Measurement of Broadband Performance). The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-lmap-framework/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-lmap-framework/ballot/ No IPR declarations have been submitted directly on this I-D. |
2015-02-23
|
11 | Amy Vezza | IESG state changed to In Last Call from Last Call Requested |
2015-02-23
|
11 | Benoît Claise | Last call was requested |
2015-02-23
|
11 | Benoît Claise | Last call announcement was generated |
2015-02-23
|
11 | Benoît Claise | Ballot approval text was generated |
2015-02-23
|
11 | Benoît Claise | Ballot writeup was generated |
2015-02-23
|
11 | Benoît Claise | IESG state changed to Last Call Requested from AD Evaluation::AD Followup |
2015-02-22
|
11 | Marcelo Bagnulo | New version available: draft-ietf-lmap-framework-11.txt |
2015-01-14
|
10 | Philip Eardley | New version available: draft-ietf-lmap-framework-10.txt |
2014-12-15
|
09 | Benoît Claise | Notification list changed to dromasca@avaya.com, draft-ietf-lmap-framework.all@tools.ietf.org, lmap-chairs@tools.ietf.org, lmap@ietf.org from lmap-chairs@tools.ietf.org, draft-ietf-lmap-framework@tools.ietf.org |
2014-12-12
|
08 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2014-12-12
|
09 | Philip Eardley | New version available: draft-ietf-lmap-framework-09.txt |
2014-11-20
|
08 | Tero Kivinen | Request for Early review by SECDIR Completed: Has Nits. Reviewer: Radia Perlman. |
2014-11-19
|
08 | Benoît Claise | IESG state changed to AD Evaluation::Revised I-D Needed from AD Evaluation |
2014-11-13
|
08 | Tero Kivinen | Request for Early review by SECDIR is assigned to Radia Perlman |
2014-11-13
|
08 | Tero Kivinen | Request for Early review by SECDIR is assigned to Radia Perlman |
2014-10-29
|
08 | Benoît Claise | IESG state changed to AD Evaluation from Publication Requested |
2014-09-18
|
08 | Dan Romascanu | 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. It's in the page header. (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 Measuring broadband service on a large scale requires a description of the logical architecture and standardization of the key protocols that coordinate interactions between the components. The document presents an overall framework for large-scale measurements. It also defines terminology for LMAP (large-scale measurement platforms). 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? Document Quality The document was very carefully reviewed and discussed by a large number of participants in the WG, because it contains key information concerning the scope, architecture and components of the recommended solutions. Several issues were debated for many months, the resulting document includes a strong consensus of the participants about the goals (and non goals) of LMAP and the path to be taken by the IETF to provide a standard solution. Personnel Who is the Document Shepherd? Who is the Responsible Area Director? Dan Romascanu is the document shepherd. Benoit Claise is the responsible Area Director. (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 have reviewed in detail every version of this document including the one that is now submitted. (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? No. (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. There is a broad industry interest for this work, and for this purpose liaison statements were exchanged with other organizations such as the BBF and the IEEE 802. We recommend sending the IETF Last Call announcement to these organizations and invite them to participate. (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 concern. (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 IPR disclosures have been submitted. (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? The consensus is solid and the participation base is healthy in numbers. (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. No problems. idnits complains about one date-in-the past, three false alarms on references, and one updated reference. (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews. no need (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. (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 (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 (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. N/A |
2014-09-18
|
08 | Dan Romascanu | State Change Notice email list changed to lmap-chairs@tools.ietf.org, draft-ietf-lmap-framework@tools.ietf.org |
2014-09-18
|
08 | Dan Romascanu | IETF WG state changed to Submitted to IESG for Publication from WG Document |
2014-09-18
|
08 | Dan Romascanu | IESG state changed to Publication Requested |
2014-09-18
|
08 | Dan Romascanu | IESG process started in state Publication Requested |
2014-09-18
|
08 | Dan Romascanu | Changed document writeup |
2014-09-18
|
08 | Dan Romascanu | Document shepherd changed to Dan Romascanu |
2014-09-18
|
08 | Dan Romascanu | Intended Status changed to Informational from None |
2014-08-08
|
08 | Philip Eardley | draft-ietf-lmap-framework-08.txt |
2014-06-24
|
07 | Philip Eardley | New version available: draft-ietf-lmap-framework-07.txt |
2014-06-13
|
06 | Philip Eardley | |
2014-05-13
|
05 | Philip Eardley | New version available: draft-ietf-lmap-framework-05.txt |
2014-03-31
|
04 | Philip Eardley | New version available: draft-ietf-lmap-framework-04.txt |
2014-02-24
|
03 | Benoît Claise | This document now replaces draft-folks-lmap-framework instead of None |
2014-02-24
|
03 | Benoît Claise | Shepherding AD changed to Benoit Claise |
2014-01-21
|
03 | Philip Eardley | New version available: draft-ietf-lmap-framework-03.txt |
2013-12-06
|
02 | Philip Eardley | New version available: draft-ietf-lmap-framework-02.txt |
2013-10-21
|
01 | Philip Eardley | New version available: draft-ietf-lmap-framework-01.txt |
2013-10-03
|
00 | Philip Eardley | New version available: draft-ietf-lmap-framework-00.txt |