Deterministic Networking Use Cases
draft-ietf-detnet-use-cases-20

[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.

[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 :-)

[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."

[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.

[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.

[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/

[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.

[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?

(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

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/

> 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.

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

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

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

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

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

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

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

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

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

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"