uldn't there be more stern words in 9031 about allowing
> a new key to be used with the same EUI-64 (considering that the device
> may not get a short identifier)?
The EUI-64 goes into the key schedule.
Different EUI-64s get different keys, even if the counter is the same.
--
see inline
On 10/09/15 09:45, Miguel Angel Reina Ortega wrote:
Let me forward you the Call for Expertise that has been recently sent
out from ETSI for the upcoming 2^nd 6TiSCH Plugtests that will be held
from 2^nd to 4^th February 2016 in Paris.
Thank you again for organizing this.
Do you kno
etter now than later.
--
Michael Richardson. o O ( IPv6 IøT consulting )
Sandelman Software Works Inc, Ottawa and Worldwide
signature.asc
Description: PGP signature
___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/lis
Yeah, that's reasonable to me.
I just couldn't defend 6tisch in the hallway.
--
Michael Richardson , Sandelman Software Works
-= IPv6 IoT consulting =-
signature.asc
Description: PGP signature
___
6tisch mailing list
6tisch@ietf.org
https:
works [
] Michael Richardson, Sandelman Software Works| network architect [
] m...@sandelman.ca http://www.sandelman.ca/| ruby on rails[
signature.asc
Description: PGP signature
___
6tisch mailing list
6tisch@ietf.org
CoJP worked very very hard to keep it at one round trip.
This is due to congestion concerns further up the RPL tree.
I don't perceive that these other technologies have this problem to the same
degree.
--
] Never tell me the odds! | ipv6 mesh networks [
] M
ed (i.e., which bits are supposed to be used?
> )?
The calculation is
a) a suggestion on how the control plane should initialize itself by default.
b) done once in the 6LBR, so any truncation is acceptable.
I.e. it doesn't matter how it's done.
Communicating the NetworkID dow
,
it must coordinate with (re-)keying , which the IEEE is not responsible for.
I don't know what else I could say in enhanced beacon about this.
The topic of selective jamming is a bit distant from this document.
--
] Never tell me the odds! | ipv6 mesh
local keys, or might just mean pulling some keys
out of NVRAM, and synchrozing to the schedule), then the node can receive
DIOs (possibly from many other possible parents), and run the normal parent
selection algorithm.
But, it can't see multiple PANs.
https://datatracker.ietf.org/meeting/101/m
>>
> Could some variation of those three sentences appear in the document as
> clarifying text?
I'm going to let this conversation happen in the thread that is here:
https://mailarchive.ietf.org/arch/msg/6tisch/1x8vWueTsj1l8g5UNzhEkXJSn_U
--
Michael Richardson
ttribute.
I think that 80% of operators still have no idea how to set it :-)
We don't know how to *set* the value, but we *do* know how to interpret
different values.
--
Michael Richardson , Sandelman Software Works
-= IPv6 IoT consulting =-
signature.asc
Description: PGP signature
__
r in their
>> diversity than this value. +How this value will be used in practice
>> is the subject of future research, and this part of the structure +is
>> considered experimental.
> This makes it sound like the actual structure might change, whic
t I have dealt with all issues raised.
--
Michael Richardson , Sandelman Software Works
-= IPv6 IoT consulting =-
signature.asc
Description: PGP signature
___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch
> note missing space before [)
already edited, i hope you it will make more sense.
--
Michael Richardson , Sandelman Software Works
-= IPv6 IoT consulting =-
signature.asc
Description: PGP signature
___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch
e won't get to the Join Proxy at all, since it will not have a workable
TSCH schedule.
> Nit: "Although However, even in this case, a" - typo / redundancy.
> Please also see Qin Wu's Opsdir review
>
(https://datatracker.ietf.org/doc/review-ietf-6ti
ork".
edited.
> Section 3
>The sensitivity of each field is describe within the description of
> each field.
> nit: s/describe/described/
>visible. Encrypting the schedule does not prevent an attacker from
&
to DODAG-Identity.
I will cite RFC6550 here.
--
] Never tell me the odds! | ipv6 mesh networks [
] Michael Richardson, Sandelman Software Works| network architect [
] m...@sandelman.ca http://www.sandelman.ca/| ruby on rails[
--
Michae
, but doesn't mention it. - It
> might be good to summarize these issues in the Security Considerations
> as well.
I asked the WG if they wanted the issues in the main body or the Security
Considerations, and there was a preference to put the description in with the
body nex
here?
There are aspects of this, and aspects that are certain.
How to tune/calculate the values is the subject of research.
How to intepret them is clear.
> The sentence "This value MUST be ignored by pledges..." is a comma
> splice.
Fixed.
> Under "pan p
t are richer in their diversity than this value.
+How this value will be used in practice is the subject of future research, and
this part of the structure
+is considered experimental.
+
--
] Never tell me the odds! | ipv6 mesh networks [
] Michael Richardson, Sandelma
ctions explain the problem being solved, which
> justify carrying the join and enrollement information in the EB."
will be done in -14.
--
Michael Richardson , Sandelman Software Works
-= IPv6 IoT consulting =-
signature.asc
Description: PGP signature
___
s! | ipv6 mesh networks [
] Michael Richardson, Sandelman Software Works| network architect [
] m...@sandelman.ca http://www.sandelman.ca/| ruby on rails[
signature.asc
Description: PGP signature
__
d he is happy.
> -- Abstract. Per “Nodes in the TSCH network typically frequently
> transmit …”, likely only “typically” or “frequently” is needed.
Both have been removed.
> -- Typo. s/the the/the/g
thank you.
--
] Never tell me the odds!
remove First :-)
> There are also many acronyms that should be expanded at first use (I
> stopped commenting about those).
okay, I'll check again and make sure.
--
] Never tell me the odds! | ipv6 mesh networks [
]
the
IEEE IE
Subtype registry. I
--
] Never tell me the odds! | ipv6 mesh networks [
] Michael Richardson, Sandelman Software Works| network architect [
] m...@sandelman.ca http://www.sandelman.ca/| ruby on rails[
signature.asc
Michael Richardson wrote:
>> This document defines a new IETF IE subtype
>> Please expand “IE” here.
Oops, I expanded it in the wrong spot.
I've fixed my copy.
--
Michael Richardson , Sandelman Software Works
-= IPv6 IoT consulting =-
signature.asc
Descripti
The Enhanced Beagon
> Typo...
Yup. fixed.
>validate the beacon, providing them with a trusted
> The end of that sentence is missing.
Sorry, the result of a previous edit, now removed.
--
] Never tell me the odds! | ipv6 mesh n
ole.
_Operational Considerations for Interstellar Wormholes_}
The changes from Pat are now at:
https://bitbucket.org/6tisch/6tisch-join-enhanced-beacon/commits/8b18e8ae818c80f09b9b598bde8504f8d566a0d7
--
] Never tell me the odds! | ipv6 mesh networks [
] Mich
d to the field
definitions.
--
] Never tell me the odds! | ipv6 mesh networks [
] Michael Richardson, Sandelman Software Works| network architect [
] m...@sandelman.ca http://www.sandelman.ca/| ruby on rails[
signature.asc
Descrip
lation of
6TiSCH Join and Enrollment Information
> Authors : Diego Dujovne (editor)
> Michael Richardson
> Filename: draft-ietf-6tisch-enrollment-enhanced-beacon-10.txt
> Pages : 9
> Date: 2020-02-13
> Abstract:
derations section.
--
] Never tell me the odds! | ipv6 mesh networks [
] Michael Richardson, Sandelman Software Works|IoT architect [
] m...@sandelman.ca http://www.sandelman.ca/| ruby on rails[
signature.asc
Description: PGP
Never tell me the odds! | ipv6 mesh networks [
] Michael Richardson, Sandelman Software Works|IoT architect [
] m...@sandelman.ca http://www.sandelman.ca/| ruby on rails[
signature.asc
Description: PGP signature
___
, I'm saying that it's architecturally impossible to encrypt.
It's not a choice.
Anything you plan to put into the beacon has to take this into account.
I take your point about explaining why the contents are not sensitive though.
--
Michael Richardson , Sandelman Software Wo
and frequencies
on which communication will occur.
Knowledge of this can help an attacker to more efficiently jam
communications, although there is future work being considered to make some
of the schedule less visible.
--
Michael Richardson , Sandelman Software Works
-= IPv6 IoT consulting =-
name in the protocol header
> matches the description for it. For example, "Proxy priority (proxy prio)"
okay.
> In Section 4,
> "An interloper with a radio sniffer would be able to use the network
> ID to map out the extend of the mesh network."
e would be good (in the draft) :-)
>>
>> Hi, we had a long discussion about setting DSCP points on upward and
downward
>> traffic. We had said that these code point would *not* cause 6P to add
bandwidth.
>> Where did we say that? I feel like that the ref
uld *not* cause 6P to add
bandwidth.
Where did we say that? I feel like that the reference has gone away.
--
Michael Richardson , Sandelman Software Works
-= IPv6 IoT consulting =-
signature.asc
Description: PGP signature
___
6tisch mailing list
52) but not for all. Why is
>>> that?
>>
>> We got pushback about relying on 7252 defaults, because what if they
changed.
> That’s fine but the you need to add all values!
Malisa?
--
] Never tell me the odds! | i
tually think that the bandwidth and
scheduling of the update is probably the critical part.
SUIT has the security done... so we have the HOW. We just have the WHEN.
--
Michael Richardson , Sandelman Software Works
-= IPv6 IoT consulting =-
signature.asc
Descr
hrough the process.
--
Michael Richardson , Sandelman Software Works
-= IPv6 IoT consulting =-
signature.asc
Description: PGP signature
___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch
On 2019-10-31 2:24 a.m., Benjamin Kaduk via Datatracker wrote:
--
COMMENT:
--
There are some seriously low-hanging fruit for traffic analysis with
some of these
Carles Gomez via Datatracker wrote:
> I did not identify technical problems. (There are comments below that do
have a
> technical side, but the issues might just be editorial.)
> There is a number of suggestions provided below, mostly editorial and
about
> presentation.
>
pecification.
I've used your changed text.
I believe that we had a discussion about the presence of the interface that
you reference. I believe that this is not mandated by older IEEE 802.15.4
API specifications. However, many OSes (Contiki,RIOTOS,OpenWSN...) do not
actually use the IEEE APIs, so
it works better somewhere else.
I've a paragraph to added it to 8.1.1, and I've clarified that the
Parameter Update should have a Uri-Host value of 6tisch.arpa.
--
Michael Richardson , Sandelman Software Works
-= IPv6 IoT consulting =-
signature.asc
D
e.
This isolates the "/j" from any other uses of CoAP on the node.
If that's not acceptable, then we could live with .well-known, as the 6LR
has already joined, and it can negotiate for bandwidth, etc.
--
Michael Richardson , Sandelman Software Works
-= IPv6 IoT consulting =-
si
27;s requirements of specifying "the
> rules for how the subdomain is administered." I would suggest something
> like:
> "No subdomains are expected, and addition of any such subdomains
> requires the publication of an IETF standards-track RFC."
I used y
000" pin.”, please provide a citation and
> short explanation.
previously removed, but, I give you:
title: "What is the default PIN on a bluetooth headset"
"https://www.answers.com/Q/What_is_the_default_PIN_on_a_bluetooth_headset";
nt. You might similarly consider the
> subsequent sentence. In any case, I do wonder whether 7554 and 8180
> should be normative.
I moved all three references to normative.
--
Michael Richardson , Sandelman Software Works
-= IPv6 IoT
ence added.
> 3) Sec 5: Maybe just to be absolutely clear: OLD: "When sending frames
> during the join process, the pledge sends unencrypted and
> unauthenticated frames." NEW: "When sending frames during the join
> process, the pledge sends unencry
This document is part of the enhanced beacon process.
Comments appreciated to *ADOPT*.
--- Begin Message ---
Dear all,
We extend this WG adoption call until 10 September.
It would be nice to have your opinion on this.
Thank you very much in advance,
Ines and Peter.
On Thu, Aug 8, 2019 at 4:1
ajor concern?
I understood the ASN advances every 10ms in many networks, sometimes as slow
as 50ms. So let's call it 2^6/s? So the ASN rolls over after 544 years?
2^(40-6) / (86400 * 365) = 544.
I guess the point is that we don't have to rekey for cryptographic of ASN
e been fixed by Pascal
and I.
--
] Never tell me the odds! | ipv6 mesh networks [
] Michael Richardson, Sandelman Software Works|IoT architect [
] m...@sandelman.ca http://www.sandelman.ca/| ruby on rails[
signature.asc
Descriptio
tinations.
--
] Never tell me the odds! | ipv6 mesh networks [
] Michael Richardson, Sandelman Software Works| network architect [
] m...@sandelman.ca http://www.sandelman.ca/| ruby on rails[
signature.asc
Description: PGP
in was designed to (optionally)
enroll devices with certificates so that one can use 802.15.9
(now rolled into 802.15.4, I'm told) to do per-pair keying.
--
] Never tell me the odds! | ipv6 mesh networks [
] Michael Richardson, Sandelman Software Works| networ
Michael Richardson wrote:
> Pascal Thubert (pthubert) wrote:
>> I'm looking for a consensus on how to address the following review
>> comment on the 6TiSCH Architecture by Benjamin:
> a) I don't think that any details about the Join Proxy belon
entire network.
I'm not sure what's in the Architecture document about this, but I'd
rather that it just said less.
--
Michael Richardson , Sandelman Software Works
-= IPv6 IoT consulting =-
signature.asc
Description: PGP signature
___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch
chitecture document is out of control, and I said that in
my review a few months ago :-)
It says way too much, anticipates way too much incomplete work,
and therefore has too many informative references, and thus we get into
the trouble we are here.
--
] Never tell me the odds!
Pascal Thubert (pthubert) wrote:
> Authors: please confirm whether 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. You may for
> instance answer with "I'm not aware of a
finish reading the
thread first}
--
] Never tell me the odds! | ipv6 mesh networks [
] Michael Richardson, Sandelman Software Works|IoT architect [
] m...@sandelman.ca http://www.sandelman.ca/| ruby on rails[
signature.asc
Tero Kivinen wrote:
> Michael Richardson writes:
>> > Implementations MUST use different L2 keys when using different MIC
>> > lengths, as using same key with different MIC lengths might be
>> unsafe > (i.e., using same key for both MIC-32 and MIC
hat there performance or power tradeoffs to using the longer MIC
lengths, other than there are more check bytes?
--
Michael Richardson , Sandelman Software Works
-= IPv6 IoT consulting =-
signature.asc
Description: PGP signature
___
6tisch mailing l
of replaying old beacons forever.
Agreed.
{If the attacker is this good at finding non-overlapping bandwidth, then
attacker could instead make fast offer network optimization services :-)}
--
] Never tell me the odds! | ipv6 mesh networks [
] Michael Richardson,
the NCE usage by untrusted nodes so that we have space for as many
registered nodes.
I think you are agreeing with me above.
I believe that the issue that Jen is describing would for unaware leaves that
were sleepy.
--
Michael Richardson , Sandelman Software Works
-= IPv6 IoT consulting =-
re any new state in
the end device, as they don't even have to listen for the ECHO REPLY.
Let me suggest a different hack: use stateful DHCPv6.
--
Michael Richardson , Sandelman Software Works
-= IPv6 IoT consulting =-
signature.asc
Description: PGP signature
___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch
d!
> --
> SY, Jen Linkova aka Furry
>
> IETF IPv6 working group mailing list
> i...@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> -------
packet we send here, be it DIS or 6P, they need to have
> special handling in terms of L2 security… Is DIS mandatory to send upon
> preferred parent selection?
I think that we can do nothing.
Maybe the replayed beacon attack (and solution: wait for another beacon)
belongs in the Secu
. Still, I hate to special case this as being
authenticated only.
Doesn't that have to happen first?
Is the DIS unicast or multicast. Hmm.
How do we put something unique in it that has to be replied to proving the
freshness of the ASN against a reply attack.
--
Michael Richardson
t. I know you didn't ask
yet. I think it's useful enough to make it part of the base architecture!
--
Michael Richardson , Sandelman Software Works
-= IPv6 IoT consulting =-
signature.asc
Description: PGP signature
___
6tisch mailing
time at the JRC.
Also so that the many unicast conversations needed to do the rekey can be spread
across a large amount of time, letting the JRC reach out to even very sleepy
nodes.
--
Michael Richardson , Sandelman Software Works
-= IPv6 IoT consulting =-
signature.asc
Description: P
after the keys are changed.
--
Michael Richardson , Sandelman Software Works
-= IPv6 IoT consulting =-
signature.asc
Description: PGP signature
___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch
hedule?
--
] Never tell me the odds! | ipv6 mesh networks [
] Michael Richardson, Sandelman Software Works|IoT architect [
] m...@sandelman.ca http://www.sandelman.ca/| ruby on rails[
___
6tisch mailing list
ent?
The issue Marco is that use of the new key is signaled by receipt of a packet
that uses the new key. The sending node will have already switched to a new
permuation, while the receiving node will still be on the old schedule.
--
Michael Richardson , Sandelman Software Work
affic encrypted with the new
key, and won't change over themselves. Authenticated enhanced beacons would
perhaps help here. Maybe I'm wrong about this problem.
--
Michael Richardson , Sandelman Software Works
-= IPv6 IoT consulting =-
signature.
w, please go ahead, but I'd prefer if you waited three
weeks.
--
Michael Richardson , Sandelman Software Works
-= IPv6 IoT consulting =-
signature.asc
Description: PGP signature
___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch
Example
>Here will be three examples of processing.
> ?
> Do you intend to fill that section?
At this point, I have no example packets, so I will remove that section.
I have posted -02 with these changes.
What lacks now is only a decision on how much text to put in the int
fers to this as just
"registrar". Within [I-D.ietf-anima-reference-model] this is
refered to as the "join registrar autonomic service agent". Other
communities use the abbreviation "JRC".
--
Michael Richardson , Sandelman Software W
ve discussed this a lot over the last year+, and I think we need to
just proceed.
> Title : IEEE802.15.4 Informational Element encapsulation of
6tisch Join and Enrollment Information
> Authors : Diego Dujovne (editor)
> Michael Richardson
> Filename
to the IESG publication queue soon. Would this
MISSREF
mcr> be acceptable?
> [PT>] I'll make the reference. We'll sort out the normative vs; not during
> the IESG review...
okay.
--
Michael Richardson , Sandelman Software Works
-= IPv6 IoT consulting =-
signature
ion queue soon. Would this MISSREF
be acceptable?
I am continuing to read/edit-for-grammar, but I thought I'd send this email
to gather some feedback.
--
Michael Richardson , Sandelman Software Works
-= IPv6 IoT consulting =-
signature.asc
Description: PGP signature
___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch
ascal Thubert
> (pthubert)
> Sent: mardi 11 décembre 2018 23:47
> To: Mališa Vučinić
> Cc: Michael Richardson ; tisch
> <6tisch@ietf.org>
> Subject: Re: [6tisch] POST WGLC: draft-ietf-6tisch-architecture-18.txt
>
> Many Thanks Malisa!
>
> I’m a few hours east
t to
renew the liason process from their end.
Rüst will be speaking at the https://iotsfconference.com/.
I am also presenting, my slides are at:
http://www.sandelman.ca/SSW/talks/iotsf2018-brski/
--
] Never tell me the odds! | ipv6 mesh networks [
] Michael
might allow other things that
need to be baked in uniquely to be described. I am thinking about a
connection to the hash-based signature work that the SUIT WG cares about.
--
Michael Richardson , Sandelman Software Works
-= IPv6 IoT consulting =-
signature.asc
Description: PGP signature
t;.
I think that we need to understand the tradeoffs, so let's discuss
(also in the ROLL WG!). Perhaps a compromise is that the rank priority can
be forced to maximum value on networks that want to keep the information
private.
--
Michael Richardson , Sandelman Software Works
-= IPv6 IoT co
missing from the list, please let me know.
thanks for making that list... that's a lot of work.
I will step through them and see what I can do.
--
Michael Richardson , Sandelman Software Works
-= IPv6 IoT consulting =-
signature.asc
Description: PGP signature
as not yet started a WG adoption call.
(Alternatively, 6tisch could instead adopt this, consulting on with ROLL for
IETF Review, as the allocation rules for Control Message Options specify in
6550 section 20.4)
--
Michael Richardson , Sandelman Software Works
-= IPv6 IoT consulting =-
signatu
ver tell me the odds! | ipv6 mesh networks [
] Michael Richardson, Sandelman Software Works| network architect [
] m...@sandelman.ca http://www.sandelman.ca/| ruby on rails[
signature.asc
Descri
u mean to say “…many unicast RAs may be sent in response.”
I'm not sure what belongs here.
I was going to say, many->MAY, but I think the whole paragraph needs
adjustments.
--
] Never tell me the odds! | ipv6 mesh networks [
] Michael Richardson
Pascal Thubert (pthubert) wrote:
> Also it appears that this draft aims artproposed standard rather than
> info, doesn't it?
I agree that it needs to be proposed standard.
The document says Informational, which I agree is wrong, and I'll fix it.
--
Michael Richar
al draft.
I think that you mean:
https://datatracker.ietf.org/doc/draft-richardson-6tisch-enrollment-enhanced-beacon/
-??
--
Michael Richardson , Sandelman Software Works
-= IPv6 IoT consulting =-
signature.asc
Description: PGP signature
___
6t
with an RPL nodes present.
Once you've done that, then we can sort out the EB policy.
I can't understand how it could work right now.
2) I think that the EB rank issue is a subject for
draft-ietf-6tisch-enrollment-enhanced-beacon, assuming it was in fact
adopted
e, but if you
don't need that and aren't going to be synchronizing, the contents of this
IE can still be used.
--
Michael Richardson , Sandelman Software Works
-= IPv6 IoT consulting =-
signature.asc
Description: PGP signature
___
6tisch
> the draft.
> I kind of liked the 6tisch.arpa "thing", but no argument with ~13-byte
> savings :-).
I don't think we need it.
--
] Never tell me the odds! | ipv6 mesh networks [
] Michael Richardson, Sandelman Software Works
? It would be good
to start an internet-draft to collect things.
--
] Never tell me the odds! | ipv6 mesh networks [
] Michael Richardson, Sandelman Software Works| network architect [
] m...@sandelman.ca http://www.sandelman.ca/| ruby on rails
say: coap://[fe80::1234]/j, which the Join Proxy
forwards to coap://[fde4:8dba:82e1::1234]/j (of ourse, using OSCORE).
--
] Never tell me the odds! | ipv6 mesh networks [
] Michael Richardson, Sandelman Software Works| network architect [
] m...@sand
dn't think of it as working like that,
but in my model all traffic that the JP receives via that channel
goes to the JRC: it has a single purpose.
In your model, the JP could proxy traffic to any place, I guess, but I didn't
really want that to happen.
--
] Never tell me the
enrolled?
>> How would it get the IP address of the PCE?
> [PT>] The string could be a real DNS name. The question is whether the
> instance of the proxy is dedicated to join or not...
--
] Never tell me the odds! | ipv6 mesh network
ould it talk to get that?
Wouldn't the node already have enrolled?
How would it get the IP address of the PCE?
--
] Never tell me the odds! | ipv6 mesh networks [
] Michael Richardson, Sandelman Software Works| network architect [
]
Michael Richardson wrote:
> Mališa Vučinić wrote:
>> Thanks Tero for this feedback! Could you check if this commit takes
>> care of it:
>> https://bitbucket.org/6tisch/draft-ietf-6tisch-minimal-security/commits/
>> dee6cf8074f2
>> The
e_and_algorithm as one octect for first few algorithms.
Or, if the value is a CBOR array, then it's [key_usage, algorithm] rather
than key_usage.
--
Michael Richardson , Sandelman Software Works
-= IPv6 IoT consulting =-
signature.asc
Description: PGP signature
___
nd if it is not
> present the IEEE802154-AES-CCM-128 algorithm is assumed. Apart from the
is there a reason you used negative numbers for algorithms?
--
Michael Richardson , Sandelman Software Works
-= IPv6 IoT consulting =-
signature.asc
Descript
1 - 100 of 280 matches
Mail list logo
