Distributed Denial-of-Service Open Threat Signaling (DOTS) Data Channel Specification
draft-ietf-dots-data-channel-31

[Ballot discuss]
Thank you for a well written document. It was a pleasure to read.

I have a small set of issues that I would like to be fixed before recommending approval of this document.

1) resolved

2)

5.1.  Registering DOTS Clients

  In order to make use of DOTS data channel, a DOTS client MUST
  register to its DOTS server(s) by creating a DOTS client ('dots-
  client') resource.  To that aim, DOTS clients SHOULD send a POST
  request (shown in Figure 11).

    POST /restconf/data/ietf-dots-data-channel:dots-data HTTP/1.1
    Host: {host}:{port}
    Content-Type: application/yang-data+json
    {
      "ietf-dots-data-channel:dots-client": [
        {
          "cuid": "string"
        }
      ]
    }

Your example is syntactically invalid, as you need an empty line after the Content-Type header field (before the payload).

The same issue is pretty much in every example in your document.

3) resolved

[Ballot comment]
In 7.1 (on page 49):

    Content-Type: application/yang-data+json
    {
    "ietf-dots-data-channel:capabilities": {

This is not a valid response. Firstly, the status-line is missing Secondly, you are missing the empty line before the payload.

[Ballot discuss]
I support Suresh's discuss that the process of how it is indicated if a 1 or 2 byte mask is used is not clear. However, I would additionally like to discuss why this bit mask is needed at all. The TCP flags field in RFC8519 is already defined as bits. Storing these bits in a signal 8 bit field and applying a matching operation is implementation specific only and doesn't require any changes to the YANG model.

I would also quickly like to discuss the use of keep-alives as described in Section 3.1:
"While the communication to the DOTS server is
  quiescent, the DOTS client MAY probe the server to ensure it has
  maintained cryptographic state.  Such probes can also keep alive
  firewall and/or NAT bindings.  A TLS heartbeat [RFC6520] verifies
  that the DOTS server still has TLS state by returning a TLS message."
I understood that multiple requests can and should be send in the same connection, however, I would expect that those requests are send basically right after each other, such as a look-up and then change of the config. I don't see a need to keep up the connection for a long time otherwise. Especially any action performed are (other than in the signal channel case) not time critical. Therefore I would rather recommend to close and reopen connections and not recommend to use keep-alives at all.

[Ballot comment]
Editorial comment: As alias and migration-scope (in the signal channel document) have the same fields, wouldn't it make sense to only definite it once somewhere?

[Ballot comment]

Thanks to everyone who worked on this document. Alexey covered all of my
substantive comments, and I support his DISCUSS; I only have a few editorial
nits to suggest.

---------------------------------------------------------------------------

ID Nits reports:

  ** There is 1 instance of too long lines in the document, the longest one
    being 5 characters in excess of 72.

---------------------------------------------------------------------------

§3.4:

>  its own information (e.g., server names, literal IP addresses) is
>  present in the "Via" header of a DOTS message it receives:

Nit: "...header field..."

>    header, the DOTS gateway MUST NOT forward the DOTS message.

Nit: "...header field..."

>  error-info:      : A copy of the Via header when

Nit: "...header field..."

>  o  Otherwise, the DOTS agent MUST update or insert the "Via" header
>    by appending its own information.

Nit: "...header field..."

>  DOTS client domain SHOULD remove the previous "Via" header
>  information after checking for a loop before forwarding.  This

Nit: "...header field..."

[Ballot discuss]
* Section 4.3

The processing requirements for the tcp flags bitmask is not at all clear. Specifically how should an implementation use the values in the flags, operator and the bitmask fields in the tcp subtree to figure out if a given packet matches. An example here could be very helpful.

"Bitmask values can be encoded as a 1- or 2-byte bitmask."

How? The bitmask field is a uint16. How would a client indicate a 1 byte bitmask?

[Also note that there are *nine* flags defined for TCP including the experimental NS bit that occurs as bit 7 of Octet 12 and a 1 byte bitmask will not catch them all]

[Ballot comment]
How does the flags field in the ipv4 match subtree interact with the bits in the fragment side? I can easily see that someone can make a mistake due to this redundancy and come up with something that is not coherent. e.g. bit "more" under flags is set and bit "lf" under fragment-> type is also set .

[Ballot comment]
Thank you for writing this - I found it useful and interesting.

I do have a few comments / suggestions to try improve the document further.

1:  "In most cases, sufficient scale can be achieved by compromising enough end-hosts and using those infected hosts to perpetrate and amplify the attack."
This is somewhat misleading - it sounds somewhat like the reflectors which get used for amplification attacks (e.g DNS servers) have been compromised. Perhaps "In most cases, sufficient scale can be achieved by compromising enough end-hosts or using amplification attacks" - in the grand scheme of things this isn't super important, but because it is so close to the beginning of the document it would be nice to set the tone correctly...

2: "After discovering the RESTCONF API root, a DOTS client uses this value as the initial part of the path in the request URI, in any subsequent request to the DOTS server."
The commas seem superfluous, and make reading this hard.

3: "It is RECOMMENDED that DOTS clients and gateways support means to alert administrators about loop errors so that appropriate actions are undertaken."
Truly a nit, but I had to reread this sentence multiple times before I got it -- I would suggest s/means/methods/ (or "provide methods").

4: TCP flags. It is really common to match on "Established" sessions (or packets with or without the SYN flag -- I think it would be **really** helpful to describe how this is done / have an example, etc. While readers should be able to figure this out, it would be helpful to have this so people can find it in a panic. Actually, more examples in the Appendix would be generally useful...

5: "The DOTS gateway, that inserted a ’cdid’ in a PUT request, MUST strip the ’cdid’ parameter in the corresponding response before forwarding the response to the DOTS client."
Extra commas...

[Ballot discuss]
Thank you for a well written document. It was a pleasure to read.

I have a small set of issues that I would like to be fixed before recommending approval of this document.

1) In 3.1:

  DOTS data channel configuration information as well as state
  information can be retrieved with the GET method.  An HTTP status-
  line header field is returned for each request to report success or

I know this text is copied from RFC 8040, but "status-line header field"
is not correct. It is either "status-line" or "header field".
(A header field always has ":" in it and HTTP status-line doesn't).
I think you meant the former.

If I misundestood and this is a part of payload itself, then your document should have an example.

  failure for RESTCONF operations (Section 5.4 of [RFC8040]).  The
  "error-tag" provides more information about encountered errors
  (Section 7 of [RFC8040]).

2)

5.1.  Registering DOTS Clients

  In order to make use of DOTS data channel, a DOTS client MUST
  register to its DOTS server(s) by creating a DOTS client ('dots-
  client') resource.  To that aim, DOTS clients SHOULD send a POST
  request (shown in Figure 11).

    POST /restconf/data/ietf-dots-data-channel:dots-data HTTP/1.1
    Host: {host}:{port}
    Content-Type: application/yang-data+json
    {
      "ietf-dots-data-channel:dots-client": [
        {
          "cuid": "string"
        }
      ]
    }

Your example is syntactically invalid, as you need an empty line after the Content-Type header field (before the payload).

The same issue is pretty much in every example in your document.

3) In the same section 5.1:

  DOTS servers can identify the DOTS client domain using the 'cdid'
  parameter or using the client's DNS name specified in the Subject
  Alternative Name extension's dNSName type or SRV-ID in the client
  certificate.

SRV-ID needs a Normative reference to RFC 6125.

Also, can you give an example of how SRV-ID is going to be used?

[Ballot comment]
In 6.1:

  name:  Name of the alias.

      This is a mandatory attribute.

Are there any restrictions on which characters can appear in aliases?

In 7.1 (on page 49):

    Content-Type: application/yang-data+json
    {
    "ietf-dots-data-channel:capabilities": {

This is not a valid response. Firstly, the status-line is missing Secondly, you are missing the empty line before the payload.

In 7.2 (on page 52):

  The DOTS server indicates the result of processing the POST request
  using the status-line header.

Again, drop "header" after status-line. For clarity you can say "the HTTP status-line".

[Ballot comment]
As in the signal-channel document, there are a couple of nits in the text about
using FQDNs as mitigation targets:

Section 10

  When FQDNs are used as targets, the DOTS server MUST rely upon DNS
  privacy enabling protocols (e.g., DNS over TLS [RFC7858], DoH
  [RFC8484]) to prevent eavesdroppers from possibly identifying the
  target resources protected by the DDoS mitigation service and means
  to ensure the target FQDN resolution is authentic (e.g., DNSSEC 
  [RFC4034]). 

nits: "DNS over TLS or DoH" ("or" instead of comma, but keep the
references as-is); comma before "and means to ensure", since the DOTS
server has to do both of those (as opposed to the DOTS server using DoT/DoH
which provides both eavesdropping protection and data authenticity, which
is what the current text says).

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of draft-ietf-dots-data-channel-27. If any part of this review is inaccurate, please let us know.

The IANA Services Operator understands that, upon approval of this document, there are two actions which we must complete.

First, in the ns registry on the IETF XML Registry page located at:

https://www.iana.org/assignments/xml-registry/

a single, new namespace will be registered as follows:

ID: yang:ietf-dots-data-channel
URI: urn:ietf:params:xml:ns:yang:ietf-dots-data-channel
Filename: [ TBD-at-Registration ]
Reference: [ RFC-to-be ]

As this document requests registrations in a Specification Required (see RFC 8126) registry, we will initiate the required Expert Review via a separate request. Expert review will need to be completed before your document can be approved for publication as an RFC.

Second, in the YANG Module Names registry on the YANG Parameters registry page located at:

https://www.iana.org/assignments/yang-parameters/

a single, new YANG module will be registered as follows:

Name: ietf-dots-data-channel
File: [ TBD-at-Registration ]
Maintained by IANA? N
Namespace: urn:ietf:params:xml:ns:yang:ietf-dots-data-channel
Prefix: data-channel
Module:
Reference: [ RFC-to-be ]

While the YANG module name will be registered after the IESG approves the document, the YANG module file will be posted after the RFC Editor notifies us that the document has been published.

The IANA Services Operator understands that these are the only actions required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

Thank you,

Sabrina Tanamal
Senior IANA Services Specialist

The following is the shepherd write-up for draft-ietf-dots-data-channel-22.

1. Summary

The document shepherd is Roman Danyliw. The responsible Area Director is Benjamin Kaduk.

This document specifies the DOTS data channel, one of two protocols (the other being the DOTS signal channel – draft-ietf-dots-signal-channel) that enables the exchange of information necessary to mitigate a DDoS attack.  This data channel protocol allows the exchange of information that is not appropriate to send under attack conditions.

The WG has reached consensus to publish this protocol specification as a Proposed Standard.  It has been subjected to substantial review from the community of interest and implementations.

2. Review and Consensus
=====================
The WG adopted this draft in April 2017 (-00) from an individual submission which was first published in August 2016.  This draft has evolved through design and implementation feedback to the current -22 version.

There have been three implementations of the draft, one open source and two proprietary from the following vendors:
** go-dots (NTT) -- https://github.com/nttdots/go-dots
** NCC Group
** Huawei

Older versions of the draft were used in interops at the Hackathons of IETF 100 and 101 to enable end-to-end testing for DOTS agents.  At the IETF 102 Hackathon, there was an inter-op specifically focused on testing between these three implementations per the -16 of the draft.  Identified issues were fixed in draft versions -17 and -18.  The full results of the inter-op can be seen here:
https://datatracker.ietf.org/meeting/102/materials/slides-102-dots-ietf-102-hackathon-interop-report-00.  Final issues were identified and resolved at the IETF 103 Interop, https://datatracker.ietf.org/meeting/103/materials/slides-103-dots-interop-report-from-ietf-103-hackathon-00.

The WG convened a WGLC on -18 of the draft from August 10 – 27, 2018 (https://www.ietf.org/mail-archive/web/dots/current/msg02547.html).  Robust feedback occurred which resulted in the publication of -19, -20 and -21.

Feedback during the shepherding preparation produced -22 to address editorial issues.

This data channel protocol has a companion signal channel protocol (draft-ietf-dots-signal-channel) in DOTS which has also been submitted for publications.

This draft has seen extensive review from the WG and from implementers.  There was early coordination with the NETCONF WG on ACL YANG modules.  The WG believes it is ready for publication.

3. Intellectual Property
===================
Each author has confirmed conformance with BCPs 78 and 79 on the DOTS mailing list:

** Mohammed Boucadair -- https://www.ietf.org/mail-archive/web/dots/current/msg02699.html
** Tirumal Reddy -- https://www.ietf.org/mail-archive/web/dots/current/msg02702.html
** Kaname Nishizuka -- https://www.ietf.org/mail-archive/web/dots/current/msg02700.html
** Liang Xia -- https://www.ietf.org/mail-archive/web/dots/current/msg02701.html
** Prashanth Patil – https://www.ietf.org/mail-archive/web/dots/current/msg02704.html
** Andrew Mortensen – https://www.ietf.org/mail-archive/web/dots/current/msg02705.html
** Nik Teague -- https://www.ietf.org/mail-archive/web/dots/current/msg02703.html

There are no IPR disclosures on the document.

4. Other Points
============

Idnits reports the following issues which do not require action:

(** error **)  “The abstract seems to contain references”  The abstract does contain these references but only in guidance to the RFC Editor who will remove them prior to publication.

(== warnings ==) The four “xx has weird spacing” instances are pointing to an figure depicting a YANG model and can be ignored

(-- comments --) The four “Looks like a reference” instances are pointing to an example and can be ignored.

The yang modules in the draft were validated as having no errors using www.yangvalidator.com (that was configured as follows -- validator version: 0.3.1, xym version: 0.4, pyang version: 1.7.3 confdc version: confd-6.5.3 , yanglint version: yanglint 0.14.69)

There are two actions for IANA:

(1) Registration of a new URI, urn:ietf:params:xml:ns:yang:ietf-dots-data-channel, in the “IETF XML Registry"; and
(2) Registration of new YANG module, ietf-dots-data-channel, in the “YANG Module Names” registry

No early expert review has been requested for the above IANA allocation.

The following Last Call announcement was sent out (ends 2019-03-13):

From: The IESG
To: IETF-Announce
CC: rdd@cert.org, dots@ietf.org, Roman Danyliw , dots-chairs@ietf.org, draft-ietf-dots-data-channel@ietf.org, kaduk@mit.edu
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Distributed Denial-of-Service Open Threat Signaling (DOTS) Data Channel Specification) to Proposed Standard


The IESG has received a request from the DDoS Open Threat Signaling WG (dots)
to consider the following document: - 'Distributed Denial-of-Service Open
Threat Signaling (DOTS) Data
  Channel Specification'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2019-03-13. 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


  The document specifies a Distributed Denial-of-Service Open Threat
  Signaling (DOTS) data channel used for bulk exchange of data that
  cannot easily or appropriately communicated through the DOTS signal
  channel under attack conditions.

  This is a companion document to the DOTS signal channel
  specification.

Editorial Note (To be removed by RFC Editor)

  Please update these statements within the document with the RFC
  number to be assigned to this document:

  o  "This version of this YANG module is part of RFC XXXX;"

  o  "RFC XXXX: Distributed Denial-of-Service Open Threat Signaling
      (DOTS) Data Channel Specification";

  o  reference: RFC XXXX

  Please update the "revision" date of the YANG module.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-dots-data-channel/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-dots-data-channel/ballot/


No IPR declarations have been submitted directly on this I-D.

Request for posting confirmation emailed to previous authors: Andrew Mortensen , Kaname Nishizuka , Nik Teague , Mohamed Boucadair , dots-chairs@ietf.org, Reddy K , Prashanth Patil , Liang Xia

Request for posting confirmation emailed to previous authors: Kaname Nishizuka , Nik Teague , Andrew Mortensen , Mohamed Boucadair , dots-chairs@ietf.org, Reddy K , Prashanth Patil , Liang Xia

Request for posting confirmation emailed to previous authors: Kaname Nishizuka , Nik Teague , Andrew Mortensen , Mohamed Boucadair , Reddy K , Prashanth Patil , Liang Xia

Request for posting confirmation emailed to previous authors: Kaname Nishizuka , Nik Teague , Andrew Mortensen , Mohamed Boucadair , Reddy K , Prashanth Patil , Liang Xia

Request for posting confirmation emailed to previous authors: Kaname Nishizuka , Nik Teague , Andrew Mortensen , Mohamed Boucadair , Reddy K , Prashanth Patil , Liang Xia

The following is the shepherd write-up for draft-ietf-dots-data-channel-22.

1. Summary

The document shepherd is Roman Danyliw. The responsible Area Director is Benjamin Kaduk.

This document specifies the DOTS data channel, one of two protocols (the other being the DOTS signal channel – draft-ietf-dots-signal-channel) that enables the exchange of information necessary to mitigate a DDoS attack.  This data channel protocol allows the exchange of information that is not appropriate to send under attack conditions.

The WG has reached consensus to publish this protocol specification as a Proposed Standard.  It has been subjected to substantial review from the community of interest and implementations.

2. Review and Consensus
=====================
The WG adopted this draft in April 2017 (-00) from an individual submission which was first published in August 2016.  This draft has evolved through design and implementation feedback to the current -22 version.

There have been three implementations of the draft, one open source and two proprietary from the following vendors:
** go-dots (NTT) -- https://github.com/nttdots/go-dots
** NCC Group
** Huawei

Older versions of the draft were used in interops at the Hackathons of IETF 100 and 101 to enable end-to-end testing for DOTS agents.  At the IETF 102 Hackathon, there was an inter-op specifically focused on testing between these three implementations per the -16 of the draft.  Identified issues were fixed in draft versions -17 and -18.  The full results of the inter-op can be seen here:
https://datatracker.ietf.org/meeting/102/materials/slides-102-dots-ietf-102-hackathon-interop-report-00

The WG convened a WGLC on -18 of the draft from August 10 – 27, 2018 (https://www.ietf.org/mail-archive/web/dots/current/msg02547.html).  Robust feedback occurred which resulted in the publication of -19, -20 and -21.

Feedback during the shepherding preparation produced -22 to address editorial issues.

This data channel protocol has a companion signal channel protocol (draft-ietf-dots-signal-channel) in DOTS which has also been submitted for publications.

This draft has seen extensive review from the WG and from implementers.  There was early coordination with the NETCONF WG on ACL YANG modules.  The WG believes it is ready for publication.

3. Intellectual Property
===================
Each author has confirmed conformance with BCPs 78 and 79 on the DOTS mailing list:

** Mohammed Boucadair -- https://www.ietf.org/mail-archive/web/dots/current/msg02699.html
** Tirumal Reddy -- https://www.ietf.org/mail-archive/web/dots/current/msg02702.html
** Kaname Nishizuka -- https://www.ietf.org/mail-archive/web/dots/current/msg02700.html
** Liang Xia -- https://www.ietf.org/mail-archive/web/dots/current/msg02701.html
** Prashanth Patil – https://www.ietf.org/mail-archive/web/dots/current/msg02704.html
** Andrew Mortensen – https://www.ietf.org/mail-archive/web/dots/current/msg02705.html
** Nik Teague -- https://www.ietf.org/mail-archive/web/dots/current/msg02703.html

There are no IPR disclosures on the document.

4. Other Points
============

Idnits reports the following issues which do not require action:

(** error **)  “The abstract seems to contain references”  The abstract does contain these references but only in guidance to the RFC Editor who will remove them prior to publication.

(== warnings ==) The four “xx has weird spacing” instances are pointing to an figure depicting a YANG model and can be ignored

(-- comments --) The four “Looks like a reference” instances are pointing to an example and can be ignored.

The yang modules in the draft were validated as having no errors using www.yangvalidator.com (that was configured as follows -- validator version: 0.3.1, xym version: 0.4, pyang version: 1.7.3 confdc version: confd-6.5.3 , yanglint version: yanglint 0.14.69)

There are two actions for IANA:

(1) Registration of a new URI, urn:ietf:params:xml:ns:yang:ietf-dots-data-channel, in the “IETF XML Registry"; and
(2) Registration of new YANG module, ietf-dots-data-channel, in the “YANG Module Names” registry

No early expert review has been requested for the above IANA allocation.

Request for posting confirmation emailed to previous authors: Kaname Nishizuka , Nik Teague , Andrew Mortensen , Mohamed Boucadair , Reddy K , Prashanth Patil , Liang Xia

Request for posting confirmation emailed to previous authors: Kaname Nishizuka , Nik Teague , Andrew Mortensen , Mohamed Boucadair , Tirumaleswar Reddy , Prashanth Patil , Liang Xia

Request for posting confirmation emailed to previous authors: Kaname Nishizuka , Nik Teague , Andrew Mortensen , Mohamed Boucadair , Tirumaleswar Reddy , Prashanth Patil , Liang Xia

Request for posting confirmation emailed to previous authors: Kaname Nishizuka , Nik Teague , Andrew Mortensen , Mohamed Boucadair , Tirumaleswar Reddy , Prashanth Patil , Liang Xia

Request for posting confirmation emailed to previous authors: Kaname Nishizuka , Nik Teague , Andrew Mortensen , Mohamed Boucadair , Tirumaleswar Reddy , Prashanth Patil , Liang Xia

Request for posting confirmation emailed to previous authors: Kaname Nishizuka , Nik Teague , Andrew Mortensen , Mohamed Boucadair , Tirumaleswar Reddy , Prashanth Patil , Liang Xia

Request for posting confirmation emailed to previous authors: Kaname Nishizuka , Nik Teague , Andrew Mortensen , Mohamed Boucadair , Tirumaleswar Reddy , Prashanth Patil , Liang Xia

Request for posting confirmation emailed to previous authors: Kaname Nishizuka , Nik Teague , Andrew Mortensen , Mohamed Boucadair , Tirumaleswar Reddy , Prashanth Patil , Liang Xia

Request for posting confirmation emailed to previous authors: Kaname Nishizuka , Nik Teague , Andrew Mortensen , Mohamed Boucadair , Tirumaleswar Reddy , Prashanth Patil , Liang Xia

Request for posting confirmation emailed to previous authors: Kaname Nishizuka , Nik Teague , Andrew Mortensen , Mohamed Boucadair , Tirumaleswar Reddy , Prashanth Patil , Liang Xia

Request for posting confirmation emailed to previous authors: Kaname Nishizuka , Nik Teague , Andrew Mortensen , Mohamed Boucadair , Tirumaleswar Reddy , Prashanth Patil , Liang Xia

Request for posting confirmation emailed to previous authors: Kaname Nishizuka , Nik Teague , Andrew Mortensen , Mohamed Boucadair , Tirumaleswar Reddy , Prashanth Patil , Liang Xia

Request for posting confirmation emailed to previous authors: Kaname Nishizuka , Nik Teague , Andrew Mortensen , Mohamed Boucadair , Tirumaleswar Reddy , Prashanth Patil , Liang Xia

Request for posting confirmation emailed to previous authors: Kaname Nishizuka , Nik Teague , Andrew Mortensen , Mohamed Boucadair , Tirumaleswar Reddy , Prashanth Patil , Liang Xia

Request for posting confirmation emailed to previous authors: Kaname Nishizuka , Nik Teague , Andrew Mortensen , Mohamed Boucadair , Tirumaleswar Reddy , Prashanth Patil , Liang Xia

Request for posting confirmation emailed to previous authors: Kaname Nishizuka , Nik Teague , Andrew Mortensen , Mohamed Boucadair , Tirumaleswar Reddy , Prashanth Patil , Liang Xia

Request for posting confirmation emailed to previous authors: Kaname Nishizuka , Nik Teague , Andrew Mortensen , Mohamed Boucadair , Tirumaleswar Reddy , Prashanth Patil , Liang Xia

Request for posting confirmation emailed to previous authors: Kaname Nishizuka , Nik Teague , Andrew Mortensen , Mohamed Boucadair , Tirumaleswar Reddy , Prashanth Patil , Liang Xia

Request for posting confirmation emailed to previous authors: Kaname Nishizuka , Nik Teague , Andrew Mortensen , Mohamed Boucadair , Tirumaleswar Reddy , Prashanth Patil , Liang Xia

Request for posting confirmation emailed to previous authors: Kaname Nishizuka , Nik Teague , Andrew Mortensen , Mohamed Boucadair , Tirumaleswar Reddy , Prashanth Patil , Liang Xia

Request for posting confirmation emailed to previous authors: Kaname Nishizuka , Nik Teague , Andrew Mortensen , Mohamed Boucadair , Tirumaleswar Reddy , Prashanth Patil , Liang Xia

Request for posting confirmation emailed to previous authors: Kaname Nishizuka , Nik Teague , Andrew Mortensen , Mohamed Boucadair , Tirumaleswar Reddy , Prashanth Patil , Liang Xia