Deterministic Networking Use Cases
draft-ietf-detnet-use-cases-20
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2019-05-09
|
20 | (System) | RFC Editor state changed to AUTH48-DONE from AUTH48 |
2019-04-11
|
20 | (System) | RFC Editor state changed to AUTH48 from RFC-EDITOR |
2019-03-27
|
20 | (System) | RFC Editor state changed to RFC-EDITOR from AUTH |
2019-03-08
|
20 | (System) | RFC Editor state changed to AUTH from EDIT |
2019-01-08
|
20 | (System) | RFC Editor state changed to EDIT |
2019-01-08
|
20 | (System) | IESG state changed to RFC Ed Queue from Approved-announcement sent |
2019-01-08
|
20 | (System) | Announcement was received by RFC Editor |
2019-01-08
|
20 | (System) | IANA Action state changed to No IANA Actions |
2019-01-08
|
20 | Cindy Morgan | IESG state changed to Approved-announcement sent from Approved-announcement to be sent::Point Raised - writeup needed |
2019-01-08
|
20 | Cindy Morgan | IESG has approved the document |
2019-01-08
|
20 | Cindy Morgan | Closed "Approve" ballot |
2019-01-08
|
20 | Cindy Morgan | Ballot approval text was generated |
2019-01-08
|
20 | Cindy Morgan | Ballot writeup was changed |
2018-12-19
|
20 | Ethan Grossman | New version available: draft-ietf-detnet-use-cases-20.txt |
2018-12-19
|
20 | (System) | New version approved |
2018-12-19
|
20 | (System) | Request for posting confirmation emailed to previous authors: Ethan Grossman |
2018-12-19
|
20 | Ethan Grossman | Uploaded new revision |
2018-10-25
|
19 | Cindy Morgan | IESG state changed to Approved-announcement to be sent::Point Raised - writeup needed from IESG Evaluation |
2018-10-25
|
19 | Mirja Kühlewind | [Ballot comment] I unfortunately did not have the time to read this doc in detail which is the main reason for my abstain. However, having … [Ballot comment] I unfortunately did not have the time to read this doc in detail which is the main reason for my abstain. However, having a quick look at the doc, I'm also not convinced that all described use cases are actually relevant for detnet (while these use case are important in general) or could be addressed with much simpler solutions (like an appropriate diffserv configuration in an controlled network) instead. |
2018-10-25
|
19 | Mirja Kühlewind | [Ballot Position Update] New position, Abstain, has been recorded for Mirja Kühlewind |
2018-10-25
|
19 | Ignas Bagdonas | [Ballot Position Update] New position, No Objection, has been recorded for Ignas Bagdonas |
2018-10-25
|
19 | Deborah Brungard | Changed consensus to Yes from Unknown |
2018-10-25
|
19 | Spencer Dawkins | [Ballot comment] Most of my comments have appeared in other AD's ballot positions, which is always handy when I ballot an hour and a half … [Ballot comment] Most of my comments have appeared in other AD's ballot positions, which is always handy when I ballot an hour and a half before a telechat, but when I noticed that Section 6 (almost in its entirety) and Section 10.3 are describing 3GPP environments, and I hadn't seen any traffic on the 3gpp-ietf-coordination mailing list about this draft, I checked last night with Georg Meyer, the 3GPP liaison to IETF, and he said he remembered discussions about this draft in SA2, but wasn't remembering recent discussions. He's in a meeting this week, and said he would check the draft next week. I don't think there's any reason for me to expect a problem, but given that Georg had been quite clear in previous discussions on Netslicing that 3GPP didn't have requirements for the IETF yet, it seemed helpful to make sure that 3GPP agrees with what's being said about 3GPP networks in IETF documents. I'm actually fine publishing this draft in archival form, because if there are SDOs that AREN'T worried about any of these use cases, I sure can't think of them, so I'd expect that this would be useful in coordinating with other SDOs, and more broadly with implementers and operators who don't participate in the IETF, and I'm not Deferring or Discussing, because I'm sure the right thing will happen, whether the draft is approved today or not. But I thought I should ask now, rather than 5 minutes after the RFC is announced :-) |
2018-10-25
|
19 | Spencer Dawkins | [Ballot Position Update] New position, No Objection, has been recorded for Spencer Dawkins |
2018-10-25
|
19 | Alissa Cooper | [Ballot comment] This document has useful content but I'm not convinced of its archival value. Consistent with the IESG statement on supporting documents , I … [Ballot comment] This document has useful content but I'm not convinced of its archival value. Consistent with the IESG statement on supporting documents , I am abstaining. Notably, the detnet charter states: "WG sustaining/informational documents may include: These documents may not necessarily be published, but may be maintained in a draft form or on a collaborative Working Group wiki to support the efforts of the Working Group and help new comers: Problem statement and (constrained) deployment environments User-driven use cases" So I would not have expected this document to be published as an RFC. I also could not find any other WG documents referencing this normatively. There are a few places in the document that are particularly problematic for an archival document: 4.2.1 "There are many field protocols used today; some are standards-based and others are proprietary (see standards [lontalk], [modbus], [profibus] and [flnet])." I would suggest s/today/at the time of this writing/ 5.1.2 "Note: Current WG discussion indicates that some peer-to-peer communication must be assumed, i.e. the PCE may communicate only indirectly with any given device, enabling hierarchical configuration of the system." This seems like it could be rendered out of date. I would suggest deleting "Current WG discussion indicates that." 12.4 "Current WG consensus is that this item won't be directly supported by the DetNet architecture, for example because it implies guarantee of in-order delivery of packets which conflicts with the core goal of achieving the lowest possible latency." Same comment as above. I would suggest deleting "Current WG consensus is that." |
2018-10-25
|
19 | Alissa Cooper | [Ballot Position Update] New position, Abstain, has been recorded for Alissa Cooper |
2018-10-25
|
19 | Adam Roach | [Ballot comment] I agree with Ben's point regarding formal archival value, and would encourage the working group to at least briefly consider the guidance for … [Ballot comment] I agree with Ben's point regarding formal archival value, and would encourage the working group to at least briefly consider the guidance for alternate formats described in the final paragraph of https://www.ietf.org/blog/support-documents-ietf-working-groups/ I don't object to publication of this document, as it was added to the DETNET charter prior to the IESG's guidance on the topic. I simply want to make sure the working group considered and ruled out alternate forms of making the use cases available in light of their goals. On a casual examination, the goals stated in the Introduction of this document would appear to be satisfied by any of the three concrete suggestions given in the IESG guidance I cite above. |
2018-10-25
|
19 | Adam Roach | [Ballot Position Update] New position, No Objection, has been recorded for Adam Roach |
2018-10-24
|
19 | Alvaro Retana | [Ballot comment] There's a lot of interesting and useful information in this document. Thanks to all who put work into getting it done! It is … [Ballot comment] There's a lot of interesting and useful information in this document. Thanks to all who put work into getting it done! It is not hard to tell that sections were written by different authors -- in itself, that is a good thing because it highlights the diversity of the scenarios considered and the applicability of the DetNet technology. However, the result is an uneven treatment of the different use cases, from how they are described (some include more details and others get a higher level description), to even the number of references used. This last point is what I would like to call out as a point of improvement: basically starting in Section 7, none of the use cases have a single reference in them...even when explicitly pointing at a resource, for example: "see the IETF99 Network Slicing BOF session agenda and materials" (§10.6). It would increase the value of the document if relevant references were added. |
2018-10-24
|
19 | Alvaro Retana | [Ballot Position Update] New position, No Objection, has been recorded for Alvaro Retana |
2018-10-24
|
19 | Suresh Krishnan | [Ballot comment] * Section 6.1.5 3GPP networks have some form of admission control to get access to these time sensitive streams. I think that it … [Ballot comment] * Section 6.1.5 3GPP networks have some form of admission control to get access to these time sensitive streams. I think that it is important to mention that here * Section 6.2.1. How does CPRI fit the narrative here for the fronthaul? Do you think it falls under the proprietary protocol and framing category? * Section 7.4 What does burstless mean (especially in the context of low packet loss)? * Section 10.3 A reference to 3GPP TS 23.501 could be useful here to describe the 5G slicing. * Section 12 I did not see much value in this but I am assuming this was put in to keep track of out of scope items during the WG process. Could this be moved to an Appendix? * References The reference for 3GPP TR 38.801 wrongly cites it as an IEEE spec. Please fix this. Typo: * Section 9.1.3. s/todayt/today/ |
2018-10-24
|
19 | Suresh Krishnan | [Ballot Position Update] New position, No Objection, has been recorded for Suresh Krishnan |
2018-10-24
|
19 | Ben Campbell | [Ballot comment] I appreciate the work that went into this draft, and am balloting "No Objection". I also greatly appreciate the fact the draft has … [Ballot comment] I appreciate the work that went into this draft, and am balloting "No Objection". I also greatly appreciate the fact the draft has text to explain why it would have archival value as an RFC. However, I'm not sure I'm convinced. Much of its value is as input to other WG efforts, which I assume will eventually complete. The remaining value seems to be to provide design context to future users or the technology. While I can sort of accept that, it's an argument that could apply to almost any WG input document. (Note: I don't really expect a change due to this comment.) Other than that, I have some specific comments: *** Substantive *** §2.1.1: Would it be worthwhile to discuss whether Forward Error Correction (FEC) is helpful here? §5.1: "For example, a 1% cost reduction in some areas could save $100B" I really hope the math if off. $100B is 1% of $10T. §9.1.2: "The challenge of blockchain network operation is not overall data rates, since the volume from both block and item stays between hundreds of bytes to a couple of mega bytes per second, but is in transporting the blocks with minimum latency to maximize efficiency of the blockchain consensus process." That needs elaboration. What is the impact of latency on the consensus process? It's not obvious to me from the text how this is more impacted the ''average" application. §17: Are there really no normative references? Please keep in mind that any reference that must be read for the reader to fully understand the draft should be normative. *** Editorial *** - General: -- There are a number of assertions that refer to the current state of technology. Words like "currently" tend to age badly in RFCs. I suggest qualifying those with something to the effect of "At the time of publication...". -- There seems to be some overlap between use cases. I wonder why things like "Wireless for Industrial Applications" and "Mining Industry", which describes an industrial application of wireless, are treated separately. §3.1.1.4: "The IEC (International Electrotechnical Commission) has recently published...": Will not age well. §5, title: "Industrial" is not a noun. I suggest "Wireless for Industrial Applications". §7, title: Please expand M2M in the section title. §7.3: First sentence is a fragment. §8.2, third paragraph: Please define "leaky feeder" §9 and subsections: This section needs proofreading for missing articles and plurals. §9.1.1: s/ "amount of items"/"number of items" §9.1.2: - 2nd paragraph: "initiates" is a transitive verb. A node either initiates _something_, or a node is initiated. - 3rd paragraph: 2nd sentence has multiple comma splices. §9.1.3: typo: "todayt" §10.3, first paragraph: "currently under development" will not age well. |
2018-10-24
|
19 | Ben Campbell | [Ballot Position Update] New position, No Objection, has been recorded for Ben Campbell |
2018-10-24
|
19 | Eric Rescorla | [Ballot comment] Rich version of this review at: https://mozphab-ietf.devsvcdev.mozaws.net/D3472 COMMENTS S 3.1.1.1.5. > | Availability … [Ballot comment] Rich version of this review at: https://mozphab-ietf.devsvcdev.mozaws.net/D3472 COMMENTS S 3.1.1.1.5. > | Availability | 99.9999 | > | precise timing required | Yes | > | Recovery time on node failure | less than 50ms - hitless | > | performance management | Yes, Mandatory | > | Redundancy | Yes | > | Packet loss | 0.1% | Where do these packet loss numbers come from? It seems like if you had a .1% chance of systems damage, that would be bad, S 3.3.2.2. > physical networks leveraging different technologies across the > country: an optical network and a microwave network for instance. > Each protection and automatism system between two points has two > telecommunications circuits, one on each network. Path diversity > between two substations is key. Regardless of the event type > (hurricane, ice storm, etc.), one path shall stay available so the You may want to say "needs to" S 3.3.3. > concepts of: > > o Integrity : data cannot be altered undetectably > > o Authenticity : the telecommunications parties involved must be > validated as genuine FWIW, we typically refer to this as "data origin authentication" and obviously it's kind of inseparable from integrity S 5.1. > These networks may also contain very large numbers of devices, for > example for factories, "big data" acquisition, and the IoT. Given > the large numbers of devices installed, and the potential > pervasiveness of the IoT, this is a huge and very cost-sensitive > market. For example, a 1% cost reduction in some areas could save > $100B This seems like a surprisingly high number given that 100B/.01 ~= 10 trillion and the entire US GDP is 20 trillion. S 7.2.1. > "n", then the next cycle ("n+1") must be lossless). After two or > more consecutive packet losses the network may be considered to be > "down" by the Application. > > As network downtime may impact the whole production system the > required network availability is rather high (99,999%). Nit: you are using period-based decimals elswehre. S 8.1. > where the final product (e.g. Copper) is obtained. Although the > operation is autonomous, the tracks are remotely monitored from a > central facility. > > In pit mines, the monitoring of the tailings or mine dumps is > critical in order to avoid any environmental pollution. In the past, Not a networking issue, but my understanding is that pit mines in practice generate quite a bit of pollution. S 9.1.1. > 9.1.1. Blockchain Operation > > A 'block' runs as a container of a batch of primary items such as > transactions, property records etc. The blocks are chained in such a > way that the hash of the previous block works as the pointer header > of the new block, where confirmation of each block requires a This is not maximally clear. The relevant point is that block N+1 transitively vouches for blocks N and before. S 9.1.2. > items and the blocks to the other nodes. > > When a node initiates, it first requests the other nodes' address > from a specific entity such as DNS, then it creates persistent > connections each of with other nodes. If node A confirms an item, it > sends the item to the other nodes via the persistent connections. This is certainly one design, but it's not the only one. S 9.3. > 9.3. Private Blockchain Future > > Blockchain system performance can be greatly improved through > deterministic networking service primarily because it would > accelerate the consensus process. It would be valuable to be able to > design a private blockchain network with the following properties: Hmm... I'm not sure how persuaded I am by this. Generally the rate of block generation is quite low, compared to any plausible network. S 11.1.8. > > 11.1.8. Mix of Deterministic and Best-Effort Traffic > > DetNet is intended to support coexistance of time-sensitive > operational (OT) traffic and information (IT) traffic on the same > ("unified") network. This seems potentially inconsistent with 11.1.6. Perhaps you mean that 11.1.6 only applies to OT? S 11.5. > addition to arriving with the data content as intended, the data must > also arrive at the expected time. This may present "new" security > challenges to implementers, and must be addressed accordingly. There > are other security implications, including (but not limited to) the > change in attack surface presented by packet replication and > elimination. Do these requirements impose new requirements on the cryptographic algorithms used to verify traffic? |
2018-10-24
|
19 | Eric Rescorla | [Ballot Position Update] New position, No Objection, has been recorded for Eric Rescorla |
2018-10-24
|
19 | Phillip Hallam-Baker | Request for Last Call review by SECDIR Completed: Ready. Reviewer: Phillip Hallam-Baker. Sent review to list. |
2018-10-18
|
19 | Pete Resnick | Request for Telechat review by GENART Completed: Ready. Reviewer: Pete Resnick. Sent review to list. |
2018-10-15
|
19 | Jonathan Hardwick | Closed request for Last Call review by RTGDIR with state 'Withdrawn' |
2018-10-11
|
19 | Jean Mahoney | Request for Telechat review by GENART is assigned to Pete Resnick |
2018-10-11
|
19 | Jean Mahoney | Request for Telechat review by GENART is assigned to Pete Resnick |
2018-10-08
|
19 | (System) | IANA Review state changed to IANA OK - Actions Needed from Version Changed - Review Needed |
2018-10-08
|
19 | (System) | IANA Review state changed to Version Changed - Review Needed from IANA OK - No Actions Needed |
2018-10-08
|
19 | Ethan Grossman | New version available: draft-ietf-detnet-use-cases-19.txt |
2018-10-08
|
19 | (System) | New version approved |
2018-10-08
|
19 | (System) | Request for posting confirmation emailed to previous authors: Ethan Grossman |
2018-10-08
|
19 | Ethan Grossman | Uploaded new revision |
2018-10-05
|
18 | Cindy Morgan | Placed on agenda for telechat - 2018-10-25 |
2018-10-05
|
18 | Deborah Brungard | IESG state changed to IESG Evaluation from Waiting for Writeup |
2018-10-05
|
18 | Deborah Brungard | Ballot has been issued |
2018-10-05
|
18 | Deborah Brungard | [Ballot Position Update] New position, Yes, has been recorded for Deborah Brungard |
2018-10-05
|
18 | Deborah Brungard | Created "Approve" ballot |
2018-10-05
|
18 | Deborah Brungard | Ballot writeup was changed |
2018-10-04
|
18 | Pete Resnick | Request for Last Call review by GENART Completed: Ready with Nits. Reviewer: Pete Resnick. Sent review to list. |
2018-10-03
|
18 | (System) | IESG state changed to Waiting for Writeup from In Last Call |
2018-09-25
|
18 | (System) | IANA Review state changed to IANA OK - No Actions Needed from IANA - Review Needed |
2018-09-25
|
18 | Sabrina Tanamal | (Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs: The IANA Functions Operator has reviewed draft-ietf-detnet-use-cases-18, 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-detnet-use-cases-18, 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 |
2018-09-21
|
18 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Sarah Banks |
2018-09-21
|
18 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Sarah Banks |
2018-09-20
|
18 | Jean Mahoney | Request for Last Call review by GENART is assigned to Pete Resnick |
2018-09-20
|
18 | Jean Mahoney | Request for Last Call review by GENART is assigned to Pete Resnick |
2018-09-20
|
18 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Phillip Hallam-Baker |
2018-09-20
|
18 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Phillip Hallam-Baker |
2018-09-19
|
18 | Amy Vezza | IANA Review state changed to IANA - Review Needed |
2018-09-19
|
18 | Amy Vezza | The following Last Call announcement was sent out (ends 2018-10-03): From: The IESG To: IETF-Announce CC: detnet@ietf.org, db3546@att.com, Lou Berger , draft-ietf-detnet-use-cases@ietf.org, … The following Last Call announcement was sent out (ends 2018-10-03): From: The IESG To: IETF-Announce CC: detnet@ietf.org, db3546@att.com, Lou Berger , draft-ietf-detnet-use-cases@ietf.org, detnet-chairs@ietf.org, lberger@labn.net Reply-To: ietf@ietf.org Sender: Subject: Last Call: (Deterministic Networking Use Cases) to Informational RFC The IESG has received a request from the Deterministic Networking WG (detnet) to consider the following document: - 'Deterministic Networking Use Cases' 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 2018-10-03. 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 draft documents use cases in several diverse industries to establish multi-hop paths for characterized flows with deterministic properties. In this context deterministic implies that flows can be established which provide guaranteed bandwidth and latency which can be established from either a Layer 2 or Layer 3 (IP) interface, and which can co-exist on an IP network with best-effort traffic. Additional use case properties include optional redundant paths, very high reliability paths, time synchronization, and clock distribution. Industries considered include professional audio, electrical utilities, building automation systems, wireless for industrial, cellular radio, industrial machine-to-machine, mining, private blockchain, and network slicing. For each case, this document will identify the application, identify representative solutions used today, and the improvements IETF DetNet solutions may enable. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-detnet-use-cases/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-detnet-use-cases/ballot/ The following IPR Declarations may be related to this I-D: https://datatracker.ietf.org/ipr/2710/ |
2018-09-19
|
18 | Amy Vezza | IESG state changed to In Last Call from Last Call Requested |
2018-09-19
|
18 | Deborah Brungard | Last call was requested |
2018-09-19
|
18 | Deborah Brungard | Ballot approval text was generated |
2018-09-19
|
18 | Deborah Brungard | Ballot writeup was generated |
2018-09-19
|
18 | Deborah Brungard | IESG state changed to Last Call Requested from Publication Requested |
2018-09-19
|
18 | Deborah Brungard | Last call announcement was generated |
2018-09-18
|
18 | Jonathan Hardwick | Request for Last Call review by RTGDIR is assigned to Yingzhen Qu |
2018-09-18
|
18 | Jonathan Hardwick | Request for Last Call review by RTGDIR is assigned to Yingzhen Qu |
2018-09-18
|
18 | Deborah Brungard | Requested Last Call review by RTGDIR |
2018-09-18
|
18 | Lou Berger | > As required by RFC 4858, this is the current template for the Document > Shepherd Write-Up. > > Changes are expected over time. … > 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)? Informational > Why is this the proper type of RFC? This document provides context for the DetNet WG and has guided the development of other WG documents. > 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 > > 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. > This document describes a number of uses cases for Deterministic Networking (DetNet). It notably identify the application, identify representative solutions used today, and the improvements IETF DetNet solutions may enable. > 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? Nothing particular worth noting. > 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? > The document is on of the foundation documents for other DetNet WG activities. It notably has had contributions from end-user part of the market. > Personnel > > Who is the Document Shepherd? Lou Berger > Who is the Responsible Area Director? Deborah Brungard > > (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 reread this document as it progressed as well as in its final form. All significant comments have been addressed. The document is ready for publication. > (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. > No. > (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. This document is ready to be published. > > (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 Authors/contributors know of none, see https://mailarchive.ietf.org/arch/msg/detnet/GlAxebB3EFCIPgn5CIAq4kmPvCQ > > (8) Has an IPR disclosure been filed that references this document? > If so, summarize any WG discussion and conclusion regarding the IPR > disclosures. > There is an IPR disclosure from a non-wg participant on the pre-WG ID: https://datatracker.ietf.org/ipr/search/?submit=draft&id=draft-ietf-detnet-use-cases There were no concerns raised during WG acceptance of the document. > (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? Very solid. The document is mature and has been discussed sufficiently. It was not published earlier in order to ensure that this document was aligned with other WG documents. Those documents has progressed to the point that publications of this document makes sense. > > (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.) > N/A > (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. Real identified IDnits have been addressed. There is one report due to an idnits bug: == There are 1 instance of lines with non-RFC2606-compliant FQDNs in the document. There is no error-ed FQDN. > > (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? > 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, N/A. > (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, N/A. > (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, N/A. > (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). N/A > > (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. > The only automated review was idnits. |
2018-09-18
|
18 | Lou Berger | Responsible AD changed to Deborah Brungard |
2018-09-18
|
18 | Lou Berger | IETF WG state changed to Submitted to IESG for Publication from WG Consensus: Waiting for Write-Up |
2018-09-18
|
18 | Lou Berger | IESG state changed to Publication Requested |
2018-09-18
|
18 | Lou Berger | IESG process started in state Publication Requested |
2018-09-18
|
18 | Lou Berger | Tag Revised I-D Needed - Issue raised by WGLC cleared. |
2018-09-18
|
18 | Lou Berger | IETF WG state changed to WG Consensus: Waiting for Write-Up from Waiting for WG Chair Go-Ahead |
2018-09-18
|
18 | Lou Berger | Changed document writeup |
2018-09-17
|
18 | Ethan Grossman | New version available: draft-ietf-detnet-use-cases-18.txt |
2018-09-17
|
18 | (System) | New version approved |
2018-09-17
|
18 | (System) | Request for posting confirmation emailed to previous authors: Ethan Grossman |
2018-09-17
|
18 | Ethan Grossman | Uploaded new revision |
2018-09-04
|
17 | Lou Berger | need to address current idnits |
2018-09-04
|
17 | Lou Berger | Tag Revised I-D Needed - Issue raised by WGLC set. |
2018-09-04
|
17 | Lou Berger | IETF WG state changed to Waiting for WG Chair Go-Ahead from WG Consensus: Waiting for Write-Up |
2018-09-04
|
17 | Lou Berger | Changed document writeup |
2018-07-05
|
17 | Lou Berger | LC Complete - https://mailarchive.ietf.org/arch/msg/detnet/frwzEFE8AP4eZrmikHI4d4qsP98 LC comment updates: https://mailarchive.ietf.org/arch/browse/detnet/?q=use-cases&gbt=1 |
2018-07-05
|
17 | Lou Berger | IETF WG state changed to WG Consensus: Waiting for Write-Up from In WG Last Call |
2018-06-26
|
17 | Ethan Grossman | New version available: draft-ietf-detnet-use-cases-17.txt |
2018-06-26
|
17 | (System) | New version approved |
2018-06-26
|
17 | (System) | Request for posting confirmation emailed to previous authors: Ethan Grossman |
2018-06-26
|
17 | Ethan Grossman | Uploaded new revision |
2018-06-08
|
16 | Lou Berger | Notification list changed to Lou Berger <lberger@labn.net> |
2018-06-08
|
16 | Lou Berger | Document shepherd changed to Lou Berger |
2018-05-17
|
16 | Lou Berger | see https://mailarchive.ietf.org/arch/msg/detnet/zOsFwFQlr9ZbvN5lOZWcGzDPINU |
2018-05-17
|
16 | Lou Berger | IETF WG state changed to In WG Last Call from WG Document |
2018-05-15
|
16 | Ethan Grossman | New version available: draft-ietf-detnet-use-cases-16.txt |
2018-05-15
|
16 | (System) | New version approved |
2018-05-15
|
16 | (System) | Request for posting confirmation emailed to previous authors: Ethan Grossman |
2018-05-15
|
16 | Ethan Grossman | Uploaded new revision |
2018-05-11
|
15 | Lou Berger | now with the url ;-) https://mailarchive.ietf.org/arch/msg/detnet/XlnnoAeeetyUcfF-5_fEA2DbJZI |
2018-05-11
|
15 | Lou Berger | Mail regarding handling of missing IPR statement |
2018-05-11
|
15 | Lou Berger | Pre LC IPR call: https://mailarchive.ietf.org/arch/msg/detnet/GlAxebB3EFCIPgn5CIAq4kmPvCQ Still waiting on: zhayiyong at huawei.com: Received: spis at intracom-telecom.com:https://www.ietf.org/mail-archive/web/detnet/current/msg01475.html Stojsavljevic, Petra : https://mailarchive.ietf.org/arch/msg/detnet/Is0Cj5MzMWtNrVhHBdCHF9OP6GE raymond.jean at hydro.qc.ca … Pre LC IPR call: https://mailarchive.ietf.org/arch/msg/detnet/GlAxebB3EFCIPgn5CIAq4kmPvCQ Still waiting on: zhayiyong at huawei.com: Received: spis at intracom-telecom.com:https://www.ietf.org/mail-archive/web/detnet/current/msg01475.html Stojsavljevic, Petra : https://mailarchive.ietf.org/arch/msg/detnet/Is0Cj5MzMWtNrVhHBdCHF9OP6GE raymond.jean at hydro.qc.ca: https://www.ietf.org/mail-archive/web/detnet/current/msg01419.html |
2018-04-27
|
15 | Lou Berger | Pre LC IPR call: Still waiting on: petra.vizarreta at lkn.ei.tum.de: raymond.jean at hydro.qc.ca: spis at intracom-telecom.com: zhayiyong at huawei.com: Received: franz-josef.goetz … Pre LC IPR call: Still waiting on: petra.vizarreta at lkn.ei.tum.de: raymond.jean at hydro.qc.ca: spis at intracom-telecom.com: zhayiyong at huawei.com: Received: franz-josef.goetz at siemens.com: https://mailarchive.ietf.org/arch/msg/detnet/6jLU_a65CWESUnCDayLpFwclPcQ |
2018-04-13
|
15 | Lou Berger | Pre LC IPR call: Still waiting on: franz-josef.goetz at siemens.com: petra.vizarreta at lkn.ei.tum.de: raymond.jean at hydro.qc.ca: spis at intracom-telecom.com: zhayiyong … Pre LC IPR call: Still waiting on: franz-josef.goetz at siemens.com: petra.vizarreta at lkn.ei.tum.de: raymond.jean at hydro.qc.ca: spis at intracom-telecom.com: zhayiyong at huawei.com: Responses: gengxuesong at huawei.com: https://mailarchive.ietf.org/arch/msg/detnet/f7ERaiog8M8jBkzO4QvEwkCfte0 huang.guangping at zte.com.cn: https://www.ietf.org/mail-archive/web/detnet/current/msg01384.html |
2018-04-02
|
15 | Ethan Grossman | New version available: draft-ietf-detnet-use-cases-15.txt |
2018-04-02
|
15 | (System) | New version approved |
2018-04-02
|
15 | (System) | Request for posting confirmation emailed to previous authors: Ethan Grossman |
2018-04-02
|
15 | Ethan Grossman | Uploaded new revision |
2018-03-22
|
14 | Lou Berger | Added to session: IETF-101: detnet Fri-0930 |
2018-02-23
|
14 | Ethan Grossman | New version available: draft-ietf-detnet-use-cases-14.txt |
2018-02-23
|
14 | (System) | New version approved |
2018-02-23
|
14 | (System) | Request for posting confirmation emailed to previous authors: Xuesong Geng , Maik Seewald , Spiros Spirou , Xavier Vilajosana , Petra Vizarreta , Ethan Grossman … Request for posting confirmation emailed to previous authors: Xuesong Geng , Maik Seewald , Spiros Spirou , Xavier Vilajosana , Petra Vizarreta , Ethan Grossman , Balazs Varga , Yu Kaneko , Patrick Wetterwald , Craig Gunther , detnet-chairs@ietf.org, Pascal Thubert , Jouni Korhonen , Diego Dujovne , Yiyong Zha , Franz-Josef Goetz , Juergen Schmitt , Janos Farkas , Subir Das , Jean Raymond , Daniel Huang , Toktam Mahmoodi |
2018-02-23
|
14 | Ethan Grossman | Uploaded new revision |
2018-02-20
|
13 | Lou Berger | Pre LC IPR call: Still waiting on: franz-josef.goetz at siemens.com: gengxuesong at huawei.com: huang.guangping at zte.com.cn: petra.vizarreta at lkn.ei.tum.de: raymond.jean … Pre LC IPR call: Still waiting on: franz-josef.goetz at siemens.com: gengxuesong at huawei.com: huang.guangping at zte.com.cn: petra.vizarreta at lkn.ei.tum.de: raymond.jean at hydro.qc.ca: spis at intracom-telecom.com: zhayiyong at huawei.com: Responses: balazs.a.varga at ericsson.com: https://mailarchive.ietf.org/arch/msg/detnet/nrKa4yUajr0hGd0fW1JgRqEXlLA craig.gunther at harman.com: https://mailarchive.ietf.org/arch/msg/detnet/VLAyzMKUYP9W7WcuvjJbhTsy3BI juergen.jues.schmitt at siemens.com: https://mailarchive.ietf.org/arch/msg/detnet/U56LuNqDH7DvsLYSW7I7IU2FtvE maseewal at cisco.com: https://mailarchive.ietf.org/arch/msg/detnet/cZN1_QcyNjDFfN68qz0wOg0x6Ts sdas at appcomsci.com: https://mailarchive.ietf.org/arch/msg/detnet/qf52FwKtkPPWbcoYu8eywZ7jDZY toktam.mahmoodi at kcl.ac.uk: https://mailarchive.ietf.org/arch/msg/detnet/kamAZUT4J1HYvjjMw-myFisW_hE jouni.nospam at gmail.com: https://mailarchive.ietf.org/arch/msg/detnet/VFghexkqerYn4maClk42uoc-3XI |
2018-02-15
|
13 | Lou Berger | Pre LC IPR call: https://mailarchive.ietf.org/arch/msg/detnet/GlAxebB3EFCIPgn5CIAq4kmPvCQ Still waiting on: balazs.a.varga at ericsson.com craig.gunther at harman.com franz-josef.goetz at siemens.com gengxuesong at huawei.com huang.guangping at zte.com.cn jouni.nospam … Pre LC IPR call: https://mailarchive.ietf.org/arch/msg/detnet/GlAxebB3EFCIPgn5CIAq4kmPvCQ Still waiting on: balazs.a.varga at ericsson.com craig.gunther at harman.com franz-josef.goetz at siemens.com gengxuesong at huawei.com huang.guangping at zte.com.cn jouni.nospam at gmail.com juergen.jues.schmitt at siemens.com maseewal at cisco.com petra.vizarreta at lkn.ei.tum.de raymond.jean at hydro.qc.ca sdas at appcomsci.com spis at intracom-telecom.com toktam.mahmoodi at kcl.ac.uk zhayiyong at huawei.com Responses: diego.dujovne at mail.udp.cl: https://mailarchive.ietf.org/arch/msg/detnet/fFuE0iIl06QoORl1iHienbYzhR0 ethan.grossman at dolby.com: https://mailarchive.ietf.org/arch/msg/detnet/Q9A_zxKTwnxafp_ssk0GMihX-kw janos.farkas at ericsson.com: https://mailarchive.ietf.org/arch/msg/detnet/gK7sdybfloUSSKPSGwlhE-SCjsk pthubert at cisco.com: https://mailarchive.ietf.org/arch/msg/detnet/YgjU-WGoHf0xOxIx_b3ROUyL89w pwetterw at cisco.com: https://mailarchive.ietf.org/arch/msg/detnet/u9cL3xysjHrLOespOHbUZlrq2tY xvilajosana at worldsensing.com: https://mailarchive.ietf.org/arch/msg/detnet/Nvm-25OuVECK2hrBQAJeCvqXVB0 yu1.kaneko at toshiba.co.jp: https://mailarchive.ietf.org/arch/msg/detnet/I0bP-LJao6fvQ8OGd9zKGBo9224 |
2018-02-14
|
13 | Lou Berger | Pre LC IP Call, waiting on: ethan.grossman@dolby.com craig.gunther@harman.com pthubert@cisco.com pwetterw@cisco.com raymond.jean@hydro.qc.ca jouni.nospam@gmail.com yu1.kaneko@toshiba.co.jp sdas@appcomsci.com zhayiyong@huawei.com balazs.a.varga@ericsson.com janos.farkas@ericsson.com franz-josef.goetz@siemens.com juergen.jues.schmitt@siemens.com xvilajosana@worldsensing.com toktam.mahmoodi@kcl.ac.uk spis@intracom-telecom.com petra.vizarreta@lkn.ei.tum.de huang.guangping@zte.com.cn gengxuesong@huawei.com … Pre LC IP Call, waiting on: ethan.grossman@dolby.com craig.gunther@harman.com pthubert@cisco.com pwetterw@cisco.com raymond.jean@hydro.qc.ca jouni.nospam@gmail.com yu1.kaneko@toshiba.co.jp sdas@appcomsci.com zhayiyong@huawei.com balazs.a.varga@ericsson.com janos.farkas@ericsson.com franz-josef.goetz@siemens.com juergen.jues.schmitt@siemens.com xvilajosana@worldsensing.com toktam.mahmoodi@kcl.ac.uk spis@intracom-telecom.com petra.vizarreta@lkn.ei.tum.de huang.guangping@zte.com.cn gengxuesong@huawei.com diego.dujovne@mail.udp.cl maseewal@cisco.com |
2018-02-14
|
13 | Lou Berger | Intended Status changed to Informational from None |
2017-11-07
|
13 | Lou Berger | Added to session: IETF-100: detnet Thu-0930 |
2017-09-18
|
13 | Ethan Grossman | New version available: draft-ietf-detnet-use-cases-13.txt |
2017-09-18
|
13 | (System) | New version approved |
2017-09-18
|
13 | (System) | Request for posting confirmation emailed to previous authors: Balazs Varga , Juergen Schmitt , Pascal Thubert , Janos Farkas , Patrick Wetterwald , Xavier Vilajosana … Request for posting confirmation emailed to previous authors: Balazs Varga , Juergen Schmitt , Pascal Thubert , Janos Farkas , Patrick Wetterwald , Xavier Vilajosana , Subir Das , Yu Kaneko , Jouni Korhonen , Craig Gunther , Yiyong Zha , detnet-chairs@ietf.org, Franz-Josef Goetz , Jean Raymond , Petra Vizarreta , Ethan Grossman , Toktam Mahmoodi |
2017-09-18
|
13 | Ethan Grossman | Uploaded new revision |
2017-04-03
|
12 | Ethan Grossman | New version available: draft-ietf-detnet-use-cases-12.txt |
2017-04-03
|
12 | (System) | New version approved |
2017-04-03
|
12 | (System) | Request for posting confirmation emailed to previous authors: =?utf-8?q?J=C3=BCrgen_Schmitt?= , Balazs Varga , Pascal Thubert , Janos Farkas , Patrick Wetterwald , Spiros Spirou , … Request for posting confirmation emailed to previous authors: =?utf-8?q?J=C3=BCrgen_Schmitt?= , Balazs Varga , Pascal Thubert , Janos Farkas , Patrick Wetterwald , Spiros Spirou , Xavier Vilajosana , Subir Das , Yu Kaneko , Jouni Korhonen , Craig Gunther , Yiyong Zha , detnet-chairs@ietf.org, Franz-Josef Goetz , Jean Raymond , Petra Vizarreta , Ethan Grossman , Toktam Mahmoodi |
2017-04-03
|
12 | Ethan Grossman | Uploaded new revision |
2016-10-03
|
11 | Ethan Grossman | New version available: draft-ietf-detnet-use-cases-11.txt |
2016-10-03
|
11 | (System) | New version approved |
2016-10-03
|
11 | (System) | Request for posting confirmation emailed to previous authors: "Balazs Varga" , "Craig Gunther" , "Juergen Schmitt" , "Pascal Thubert" , "Ethan Grossman" , "Jouni Korhonen" … Request for posting confirmation emailed to previous authors: "Balazs Varga" , "Craig Gunther" , "Juergen Schmitt" , "Pascal Thubert" , "Ethan Grossman" , "Jouni Korhonen" , "Jean Raymond" , "Janos Farkas" , "Patrick Wetterwald" , "Subir Das" , "Yu Kaneko" , "Yiyong Zha" , detnet-chairs@ietf.org, "Franz-Josef Goetz" |
2016-10-03
|
11 | Ethan Grossman | Uploaded new revision |
2016-07-04
|
10 | Ethan Grossman | New version available: draft-ietf-detnet-use-cases-10.txt |
2016-03-21
|
09 | Ethan Grossman | New version available: draft-ietf-detnet-use-cases-09.txt |
2016-03-07
|
08 | Ethan Grossman | New version available: draft-ietf-detnet-use-cases-08.txt |
2016-03-05
|
07 | Ethan Grossman | New version available: draft-ietf-detnet-use-cases-07.txt |
2016-03-04
|
06 | Ethan Grossman | New version available: draft-ietf-detnet-use-cases-06.txt |
2016-02-23
|
05 | Ethan Grossman | New version available: draft-ietf-detnet-use-cases-05.txt |
2016-02-22
|
04 | Ethan Grossman | New version available: draft-ietf-detnet-use-cases-04.txt |
2016-02-16
|
03 | Ethan Grossman | New version available: draft-ietf-detnet-use-cases-03.txt |
2016-02-10
|
02 | Ethan Grossman | New version available: draft-ietf-detnet-use-cases-02.txt |
2016-02-09
|
01 | Ethan Grossman | New version available: draft-ietf-detnet-use-cases-01.txt |
2015-12-15
|
00 | Lou Berger | This document now replaces draft-grossman-detnet-use-cases instead of None |
2015-12-15
|
00 | Ethan Grossman | New version available: draft-ietf-detnet-use-cases-00.txt |