Subject: Martin Duke's Discuss on draft-ietf-6man-ipv6-alt-mark-08: (with DISCUSS and COMMENT)

From: Martin Duke via Datatracker <[email-masked]>
Date: Mon, 09 Aug 2021 17:11:22 -0700

Martin Duke has entered the following ballot position for
draft-ietf-6man-ipv6-alt-mark-08: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-6man-ipv6-alt-mark/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

I have some concerns about this approach, plus some points of confusion that
hopefully will clear up quickly.

I support Lars's first two DISCUSS points.

(1) I am unclear about the relationship between limited domains and the
prohibition against modifying either option before the destination. Is the
intent that (a) this is only used for traffic that begins and ends in the
domain; (b) user traffic is encapsulated with an outer IPv6 header that is
removed prior to domain exit; or (c) the "destination" actually means the
egress point from the domain?

(2) Relatedly, if the source nodes are  user-generated packets, how is this in
practice a limited domain? Source nodes have enormous power to degrade the
measurement by sending packets that fill the entire FlowMon space with only 1M
packets, which not only consumes router resources but also pollutes every
single measurement in the domain.

(3) The draft informatively references the (Experimental) RFCs 8321 and 8889
and covers some of the same ground, but as a Proposed Standard. Is part of the
purpose here to update these RFCs? For other measurement techniques, we've had
a generic measurement draft in IPPM and encapsulations in the appropriate
protocol-specific groups like 6man. Why was that approach not taken here? Will
future encapsulations of alternate marking refer to this one normatively on how
to conduct the measurement?

(4) Are there any restrictions on FlowMon IDs? Need these be pseudorandom, or
can they encode information in the clear?

(5) I don't understand the basic motivation for using HBH options if these can
result in the packet being diverted to the slow path on intermediate nodes.
This seems like a major drawback for a delay measurement!

(6) Sec 5.1: When using timer-based batches, I gather you use times well in
excess of potential reordering. If using a counter-based method, how does the
measurement account for potential reordering? There could easily be a very
large instantaneous burst followed by a path change that lowered the latency.

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thanks to Yoshi for the TSVART review.

---

From: Giuseppe Fioccola <[email-masked]>
Date: Tue, 10 Aug 2021 14:27:45 +0000

Dear Martin,
Thank you for your review. 
Please find my answers inline tagged as [GF].

Regards,

Giuseppe

-----Original Message-----
From: Martin Duke via Datatracker <[email-masked]> 
Sent: Tuesday, August 10, 2021 2:11 AM
To: The IESG <[email-masked]>
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Martin Duke's Discuss on draft-ietf-6man-ipv6-alt-mark-08: (with DISCUSS and COMMENT)

When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.)

I have some concerns about this approach, plus some points of confusion that hopefully will clear up quickly.

(1) I am unclear about the relationship between limited domains and the prohibition against modifying either option before the destination. Is the intent that (a) this is only used for traffic that begins and ends in the domain; (b) user traffic is encapsulated with an outer IPv6 header that is removed prior to domain exit; or (c) the "destination" actually means the egress point from the domain?

[GF]: Yes, (a) is correct. AltMark is used to monitor live traffic without adding an additional header. The destination may be the egress point of the domain but it may also be an internal point of the domain, in case you want to monitor a portion of the network within the controlled domain.

(2) Relatedly, if the source nodes are  user-generated packets, how is this in practice a limited domain? Source nodes have enormous power to degrade the measurement by sending packets that fill the entire FlowMon space with only 1M packets, which not only consumes router resources but also pollutes every single measurement in the domain.

[GF]: I see your point. But it is important to clarify that the implementation of the method is not done on the end node since it is not fully managed and therefore it does not belong to the controlled domain. Indeed the method could be implemented starting from the first node (e.g. CPE) able to filter and drop packets. I can surely clarify this point and mention in the security section that the end nodes may consume router resources by maliciously using the HbH Option, but this can be mitigated by filtering these packets at the controlled domain boundary. This can be done because the end node does not belong to the controlled domain and it is not supposed to add the AltMark HbH Option, so it can be recognized.

(3) The draft informatively references the (Experimental) RFCs 8321 and 8889 and covers some of the same ground, but as a Proposed Standard. Is part of the purpose here to update these RFCs? For other measurement techniques, we've had a generic measurement draft in IPPM and encapsulations in the appropriate protocol-specific groups like 6man. Why was that approach not taken here? Will future encapsulations of alternate marking refer to this one normatively on how to conduct the measurement?

[GF]: Since this is a Proposed Standard, it was suggested by ADs and 6MAN chairs to avoid to normatively refer to an Experimental document for the methodology description. The solution was to informatively refer to RFC 8321 and RFC 8889 and describe the full methodology in this document. There are no new techniques introduces in this draft. They are the same as explained in RFC 8321 and RFC 8889. For future drafts, I guess we can normatively refer to this one or it is possible to follow the same approach.

(4) Are there any restrictions on FlowMon IDs? Need these be pseudorandom, or can they encode information in the clear?

[GF]: The FlowMonID field is to uniquely identify a monitored flow within the measurement domain. The field can be set in two ways: it can be assigned by the central controller or it can be generated by the source node, that can set it pseudo-randomly. FlowMonID field may allow a flow tracking type of attack, but the application to a controlled domain helps to mitigate this issue as well.

(5) I don't understand the basic motivation for using HBH options if these can result in the packet being diverted to the slow path on intermediate nodes.
This seems like a major drawback for a delay measurement!

[GF]: It is important to highlight that the definition of the HbH Options is designed to minimize throughput impact. Indeed, the three high-order bits of the Options Header are 000 and, in theory, as per RFC 8200, this means "skip if do not recognize and data do not change en route".  RFC 8200 also mentions that the nodes only examine and process the HbH Options header if explicitly configured to do so.  For these reasons, this HbH Option should not affect the throughput.  However, in practice, the things may be different and it can happen that packets with HbH are forced onto the slow path. This is a general issue, as also explained in draft-hinden-6man-hbh-processing. In this regard there is some discussion in 6MAN WG on how to redefine HBH procedures to make HBH options more practical. This document could also leverage the outcome of the ongoing work in draft-hinden-6man-hbh-processing.

(6) Sec 5.1: When using timer-based batches, I gather you use times well in excess of potential reordering. If using a counter-based method, how does the measurement account for potential reordering? There could easily be a very large instantaneous burst followed by a path change that lowered the latency.

[GF]: Yes, you got the point. The method based on a fixed timer is preferable because it is more deterministic than the method based on fixed number of packets. It is always possible to use a counter-based method but it needs some heuristic to find the value that can be valid for all the network condition.

---

From: Martin Duke <[email-masked]>
Date: Tue, 10 Aug 2021 15:47:45 -0700

Replies inline.

On Tue, Aug 10, 2021 at 7:27 AM Giuseppe Fioccola <
[email-masked]> wrote:

> Cc: [email-masked]; [email-masked];
> [email-masked]; [email-masked]; [email-masked];
> [email-masked]
> [GF]: Yes, (a) is correct. AltMark is used to monitor live traffic without
> adding an additional header. The destination may be the egress point of the
> domain but it may also be an internal point of the domain, in case you want
> to monitor a portion of the network within the controlled domain.
>

OK

> (2) Relatedly, if the source nodes are  user-generated packets, how is
> this in practice a limited domain? Source nodes have enormous power to
> degrade the measurement by sending packets that fill the entire FlowMon
> space with only 1M packets, which not only consumes router resources but
> also pollutes every single measurement in the domain.
>
> [GF]: I see your point. But it is important to clarify that the
> implementation of the method is not done on the end node since it is not
> fully managed and therefore it does not belong to the controlled domain.
> Indeed the method could be implemented starting from the first node (e.g.
> CPE) able to filter and drop packets. I can surely clarify this point and
> mention in the security section that the end nodes may consume router
> resources by maliciously using the HbH Option, but this can be mitigated by
> filtering these packets at the controlled domain boundary. This can be done
> because the end node does not belong to the controlled domain and it is not
> supposed to add the AltMark HbH Option, so it can be recognized.
>

I see. So IIUC by "source" and "destination" you don't mean the IP
addresses but ingress and egress points for the domain, which are inserting
these headers. But doesn't that violate Section 4 of RFC8200? (where these
are not inserted or deleted except by the source and destination IPs?

I guess I could use a little more clarity on the use case. One alternative
reading of your answers is that a customer end node generates a packet, the
operator-controlled CPE inserts the header *if and only if* the destination
IP happens to be the domain. I don't know if this is right, but an
explanation of this nature would be useful in the text.

>
> (3) The draft informatively references the (Experimental) RFCs 8321 and
> 8889 and covers some of the same ground, but as a Proposed Standard. Is
> part of the purpose here to update these RFCs? For other measurement
> techniques, we've had a generic measurement draft in IPPM and
> encapsulations in the appropriate protocol-specific groups like 6man. Why
> was that approach not taken here? Will future encapsulations of alternate
> marking refer to this one normatively on how to conduct the measurement?
>
> [GF]: Since this is a Proposed Standard, it was suggested by ADs and 6MAN
> chairs to avoid to normatively refer to an Experimental document for the
> methodology description. The solution was to informatively refer to RFC
> 8321 and RFC 8889 and describe the full methodology in this document. There
> are no new techniques introduces in this draft. They are the same as
> explained in RFC 8321 and RFC 8889. For future drafts, I guess we can
> normatively refer to this one or it is possible to follow the same approach.
>

On the contrary, I think the correct document action is to update or
obsolete these documents, if you are elevating their contents to PS.

>
> (4) Are there any restrictions on FlowMon IDs? Need these be pseudorandom,
> or can they encode information in the clear?
>
> [GF]: The FlowMonID field is to uniquely identify a monitored flow within
> the measurement domain. The field can be set in two ways: it can be
> assigned by the central controller or it can be generated by the source
> node, that can set it pseudo-randomly. FlowMonID field may allow a flow
> tracking type of attack, but the application to a controlled domain helps
> to mitigate this issue as well.
>

I didn't phrase my question clearly enough. As a source node or controller,
can I really just do whatever when picking a FlowMon? Can I just increment
by one through the space? Can I use structured bits in the flowmon to
indicate what sort of processing I want, the type of application, or
whatever? If so, what are the security and privacy implications of this
choice? Or does it have to appear random to observers?

>
> (5) I don't understand the basic motivation for using HBH options if these
> can result in the packet being diverted to the slow path on intermediate
> nodes.
> [GF]: It is important to highlight that the definition of the HbH Options
> is designed to minimize throughput impact. Indeed, the three high-order
> bits of the Options Header are 000 and, in theory, as per RFC 8200, this
> means "skip if do not recognize and data do not change en route".  RFC 8200
> also mentions that the nodes only examine and process the HbH Options
> header if explicitly configured to do so.  For these reasons, this HbH
> Option should not affect the throughput.  However, in practice, the things
> may be different and it can happen that packets with HbH are forced onto
> the slow path. This is a general issue, as also explained in
> draft-hinden-6man-hbh-processing. In this regard there is some discussion
> in 6MAN WG on how to redefine HBH procedures to make HBH options more
> practical. This document could also leverage the outcome of the ongoing
> work in draft-hinden-6man-hbh-processing.
>

OK

>
> (6) Sec 5.1: When using timer-based batches, I gather you use times well
> in excess of potential reordering. If using a counter-based method, how
> does the measurement account for potential reordering? There could easily
> be a very large instantaneous burst followed by a path change that lowered
> the latency.
>
> [GF]: Yes, you got the point. The method based on a fixed timer is
> preferable because it is more deterministic than the method based on fixed
> number of packets. It is always possible to use a counter-based method but
> it needs some heuristic to find the value that can be valid for all the
> network condition.
>

I don't see how a heuristically derived value solves the problem. Say I run
something and decide that N = 5000. But if packets 5000 and 5001 arrive in
reverse order, I have the ambiguity problem, no? This is a trivial case,
but larger cases of reordering would be indistinguishable from packet loss.

---

From: Giuseppe Fioccola <[email-masked]>
Date: Wed, 11 Aug 2021 08:55:35 +0000

Dear Martin,
Please find my replies inline tagged as [GF].

Regards,

Giuseppe

From: Martin Duke <[email-masked]>
Sent: Wednesday, August 11, 2021 12:48 AM
To: Giuseppe Fioccola <[email-masked]>
Cc: The IESG <[email-masked]>; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: Martin Duke's Discuss on draft-ietf-6man-ipv6-alt-mark-08: (with DISCUSS and COMMENT)

Replies inline.

On Tue, Aug 10, 2021 at 7:27 AM Giuseppe Fioccola <[email-masked]<mailto:[email-masked]>> wrote:

-----Original Message-----
From: Martin Duke via Datatracker <[email-masked]<mailto:[email-masked]>>
Sent: Tuesday, August 10, 2021 2:11 AM
To: The IESG <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Martin Duke's Discuss on draft-ietf-6man-ipv6-alt-mark-08: (with DISCUSS and COMMENT)

OK

I see. So IIUC by "source" and "destination" you don't mean the IP addresses but ingress and egress points for the domain, which are inserting these headers. But doesn't that violate Section 4 of RFC8200? (where these are not inserted or deleted except by the source and destination IPs?

[GF]: Of course, extension headers are not inserted by any node other than the source of the packet. I meant the outer IPv6 header (e.g. an SR domain ingress router encapsulating a received packet in an outer IPv6 header)

I guess I could use a little more clarity on the use case. One alternative reading of your answers is that a customer end node generates a packet, the operator-controlled CPE inserts the header if and only if the destination IP happens to be the domain. I don't know if this is right, but an explanation of this nature would be useful in the text.

[GF]: If the end node does not belong to the controlled domain, the only possible application scenario is the operator-controlled underlay network. As you said, it is inserted the outer IPv6 header if the destination is within the domain. I will definitely clarify the usage scenarios in the next version.

On the contrary, I think the correct document action is to update or obsolete these documents, if you are elevating their contents to PS.

[GF]: As said, it was agreed to include the detailed description of the methodology in RFC8321 also in this document to enable the informative reference. In this way there is no strict dependency. Note that we are not elevating the contents to PS. The fact is that the experiment is done (https://datatracker.ietf.org/doc/html/rfc8321#section-5.1) and the description of the methodology in RFC 8321 and RFC 8889 is already general and protocol agnostic to be applicable to different protocols.

I didn't phrase my question clearly enough. As a source node or controller, can I really just do whatever when picking a FlowMon? Can I just increment by one through the space? Can I use structured bits in the flowmon to indicate what sort of processing I want, the type of application, or whatever? If so, what are the security and privacy implications of this choice? Or does it have to appear random to observers?

[GF]: As for now, these uses of FlowMonID are out of scope. FlowMonID only needs to appear random to observers that should only read it to identify the monitoring flow.

OK

I don't see how a heuristically derived value solves the problem. Say I run something and decide that N = 5000. But if packets 5000 and 5001 arrive in reverse order, I have the ambiguity problem, no? This is a trivial case, but larger cases of reordering would be indistinguishable from packet loss.

[GF]: I meant that, for counter-based batches, it is more difficult to find a mathematical formulation as we explained for timer-based batches. The issue is that it is hard to find a relation between the number of packets and network delay / clock error, which are responsible of reordering events. For this reason, the only possible way is to identify a reasonable value, large enough to be conservative.

---

From: Martin Duke <[email-masked]>
Date: Wed, 11 Aug 2021 11:02:57 -0700

On Wed, Aug 11, 2021 at 1:55 AM Giuseppe Fioccola <
[email-masked]> wrote:

> *From:* Martin Duke <[email-masked]>
> *Sent:* Wednesday, August 11, 2021 12:48 AM
> *To:* Giuseppe Fioccola <[email-masked]>
> *Cc:* The IESG <[email-masked]>; [email-masked];
> [email-masked]; [email-masked]; [email-masked];
> [email-masked]
> *Subject:* Re: Martin Duke's Discuss on draft-ietf-6man-ipv6-alt-mark-08:
> (with DISCUSS and COMMENT)
>
>
>
> Replies inline.
>
>
>
> [GF]: Of course, extension headers are not inserted by any node other than
> the source of the packet. I meant the outer IPv6 header (e.g. an SR domain
> ingress router encapsulating a received packet in an outer IPv6 header)
>

Alright, so the answer to my original question is actually (b) for most
hybrid measurements. You are adding an encapsulating IPv6 header to user
packets to include this option. This is not clear at all in the current
draft.

<snip>

> [GF]: As said, it was agreed to include the detailed description of the
> methodology in RFC8321 also in this document to enable the informative
> reference. In this way there is no strict dependency. Note that we are not
> elevating the contents to PS. The fact is that the experiment is done (
> https://datatracker.ietf.org/doc/html/rfc8321#section-5.1) and the
> description of the methodology in RFC 8321 and RFC 8889 is already general
> and protocol agnostic to be applicable to different protocols.
>

I can't reconcile this reply with the one to Alvaro, that says an Update is
the best path forward.

> I didn't phrase my question clearly enough. As a source node or
> controller, can I really just do whatever when picking a FlowMon? Can I
> just increment by one through the space? Can I use structured bits in the
> flowmon to indicate what sort of processing I want, the type of
> application, or whatever? If so, what are the security and privacy
> implications of this choice? Or does it have to appear random to observers?
>
>
>
> [GF]: As for now, these uses of FlowMonID are out of scope. FlowMonID only
> needs to appear random to observers that should only read it to identify
> the monitoring flow.
>

I'm not asking you to specify encodings, I'm asking you to put bounds on
what is acceptable, so this CANNOT be "out of scope". If the requirement is
that the FlowMon ID be pseudo-random, then please put that in the document.
If there is no such requirement, there are additional security and privacy
considerations that you must evaluate.

For example, in the APN BoF there has been a huge battle about identifying
applications with a tag. What's to stop a source node in this draft from
using part of the FlowMon ID to identify the application?

<snip>

> I don't see how a heuristically derived value solves the problem. Say I
> run something and decide that N = 5000. But if packets 5000 and 5001 arrive
> in reverse order, I have the ambiguity problem, no? This is a trivial case,
> [GF]: I meant that, for counter-based batches, it is more difficult to
> find a mathematical formulation as we explained for timer-based batches.
> The issue is that it is hard to find a relation between the number of
> packets and network delay / clock error, which are responsible of
> reordering events. For this reason, the only possible way is to identify a
> reasonable value, large enough to be conservative.
>

Again, I don't agree that there is any value that is sufficiently
conservative. Time based-windows suffer from latency ambiguity, but  can be
large enough to exceed any conceivable change in latency. Counter-based
windows are ambiguous in the case of large burst losses, but I don't see
that the network imposes the same kind of limits on how large a burst loss
can be.

---

From: Giuseppe Fioccola <[email-masked]>
Date: Wed, 11 Aug 2021 19:36:10 +0000

Dear Martin,
Please see my replies inline with [GF].

Regards,

Giuseppe

Sent: Wednesday, August 11, 2021 8:03 PM

On Wed, Aug 11, 2021 at 1:55 AM Giuseppe Fioccola <[email-masked]<mailto:[email-masked]>> wrote:
Dear Martin,
Please find my replies inline tagged as [GF].

Regards,

Giuseppe

From: Martin Duke <[email-masked]<mailto:[email-masked]>>
Sent: Wednesday, August 11, 2021 12:48 AM
To: Giuseppe Fioccola <[email-masked]<mailto:[email-masked]>>
Cc: The IESG <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: Martin Duke's Discuss on draft-ietf-6man-ipv6-alt-mark-08: (with DISCUSS and COMMENT)

Replies inline.

-----Original Message-----
From: Martin Duke via Datatracker <[email-masked]<mailto:[email-masked]>>
Sent: Tuesday, August 10, 2021 2:11 AM
To: The IESG <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Martin Duke's Discuss on draft-ietf-6man-ipv6-alt-mark-08: (with DISCUSS and COMMENT)

OK

Alright, so the answer to my original question is actually (b) for most hybrid measurements. You are adding an encapsulating IPv6 header to user packets to include this option. This is not clear at all in the current draft.

[GF]: I agree. I will clarify the usage scenarios in the next version of the document.

<snip>

I can't reconcile this reply with the one to Alvaro, that says an Update is the best path forward.

[GF]: I think that no actions are needed because of the informative reference. As said, the description of the methodology in RFC 8321 and RFC 8889 is protocol agnostic to be applicable to different protocols. Also, not all the techniques described in RFC 8321 and RFC 8889 are applicable in this document for IPv6. But, if the IESG decides to Update or Obsolete the original RFCs, my suggestion is to Update.

I'm not asking you to specify encodings, I'm asking you to put bounds on what is acceptable, so this CANNOT be "out of scope". If the requirement is that the FlowMon ID be pseudo-random, then please put that in the document. If there is no such requirement, there are additional security and privacy considerations that you must evaluate.

For example, in the APN BoF there has been a huge battle about identifying applications with a tag. What's to stop a source node in this draft from using part of the FlowMon ID to identify the application?

[GF]: Sure, the document mentions that FlowMonID is pseudorandomly generated. I will clarify it better. There is the possibility that the FlowMonID is generated by the Controller but in this case it only verifies that there is no ambiguity between different pseudorandomly generated FlowMonIDs on the same path. The security section also highlights the flow tracking type of attack, but the application to a controlled domain helps to mitigate this issue.

<snip>

Again, I don't agree that there is any value that is sufficiently conservative. Time based-windows suffer from latency ambiguity, but  can be large enough to exceed any conceivable change in latency. Counter-based windows are ambiguous in the case of large burst losses, but I don't see that the network imposes the same kind of limits on how large a burst loss can be.

[GF]: Agree. There is no definitive rule for counter-based window, differently from timer-based batches. I only meant that in particular cases a conservative value can be found but, of course, you can never be 100% sure. For this reason, the method based on a fixed timer is preferable. I can add some considerations on this aspect as well.

---

From: Martin Duke <[email-masked]>
Date: Wed, 11 Aug 2021 16:25:56 -0700

Just one thing:

On Wed, Aug 11, 2021 at 12:36 PM Giuseppe Fioccola <
[email-masked]> wrote:

> Dear Martin,
>
>
>
> [GF]: Sure, the document mentions that FlowMonID is pseudorandomly
> generated. I will clarify it better. There is the possibility that the
> FlowMonID is generated by the Controller but in this case it only verifies
> that there is no ambiguity between different pseudorandomly generated
> FlowMonIDs on the same path. The security section also highlights the flow
> to mitigate this issue.
The text says this:

      * It can be uniformly assigned by the central controller.  Since
      the controller knows the network topology, it can set the value
      properly to avoid or minimize ambiguity and guarantee the
      uniqueness.

 I initially took this to mean most likely implemented as a simple counter.
If this is meant to be pseudo-random as well, it should not only say so,
but IMO it should be a MUST.

---

From: Giuseppe Fioccola <[email-masked]>
Date: Thu, 12 Aug 2021 09:11:18 +0000

Hi Martin,
Please see inline with [GF].

Regards,

Giuseppe

Sent: Thursday, August 12, 2021 1:26 AM

Just one thing:

On Wed, Aug 11, 2021 at 12:36 PM Giuseppe Fioccola <[email-masked]<mailto:[email-masked]>> wrote:
Dear Martin,

      uniqueness.
 I initially took this to mean most likely implemented as a simple counter. If this is meant to be pseudo-random as well, it should not only say so, but IMO it should be a MUST.

[GF]: Agree. I was already thinking to clarify this in the next version. It is always pseudorandomly generated.