CC to
core@
I think that scheme registrations go to media-types@ ML, but I have to
verify.
I wonder how much justification the document needs to have, vs how much
just needs to be in the email.
--
Michael Richardson. o O ( IPv6 IøT consulting )
Sandelman Software Works Inc, Otta
Thank you for very much for the reply.
Jan Lindblad wrote:
> I had a look at your test example. The example is invalid, but pyang
> fails to detect the error and overwrites some internal structures, with
> the result below. The root cause of the problem is this:
...
> Each one
Jan Lindblad wrote:
> I'll make a sketch here, let me know if you have questions.
Thank you.
So I think we have our augments slightly wrong, and maybe we have it wrong in
RFC8995 too, and I'll have to get fully caffeinated and check it all out.
--
Michael Richardson. o O ( IPv6
r-cert? binary
+--rw prior-signed-voucher-request? binary
So I got the entries and the augment from ietf-voucher-request-constrained,
but not those from ietf-voucher-request-prm!
--
Michael Richardson. o O ( IPv6 IøT consulting )
Sandelman Software Works Inc,
.
The BRSKI Design team thinks we should just do bug-fix and in the process we
should advance it to Internet Standard.
https://www.ietf.org/rfcdiff?url1=rfc8366=draft-ietf-anima-rfc8366bis-00=--html
--
Michael Richardson. o O ( IPv6 IøT consulting )
Sandelman Software Works Inc, Ottawa
, that we could
define something like jpy.arpa. That's clearly a hack though, just a hack of
a different type.
--
Michael Richardson. o O ( IPv6 IøT consulting )
Sandelman Software Works Inc, Ottawa and Worldwide
signature.asc
Description: PGP signature
Fries, Steffen wrote:
> Thank you for the clarification. This means we don't have to change
> anything in either BRSKI-PRM and constraint voucher, resp. in the
> general approach we use the voucher.
Yes!
I was worred that there were dragons in the future, but seems not.
-
tion. {It might need an RFC for
trade agreement reasons though}
--
Michael Richardson , Sandelman Software Works
-= IPv6 IoT consulting =-
signature.asc
Description: PGP signature
___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima
C . . . . > D
If we want D to augment from two origins (B and C), does that even work?
Or does D have to augment A again, repeating the additions that B and C
did?
I will see if I can have this conversation in person using the technology of
back-of-napkins.
--
Michael Richardson , Sandel
h would may change things slightly and which we should
include.
I think that there is still interest in proceeding.
One question is how this should/could interact with rfc8366bis.
--
Michael Richardson , Sandelman Software Works
-= IPv6 IoT consulting =-
signature.asc
Descript
I posted a slide for rfc8366bis.
Your (PPTX?!) chair slides did not mention it well enough.
--
Michael Richardson , Sandelman Software Works
-= IPv6 IoT consulting =-
signature.asc
Description: PGP signature
___
Anima mailing list
Anima@ietf.org
ink it would be appropriate to review for WG Adoption.
I think that the document should Updates (Amends) RFC7030 and RFC8995 and
RFC9148.
It is normatively referenced by:
anima-brski-cloud
acme-intergrations
anima-brski-prm
anima-brski-ae
--
Michael Richardson , Sandelman Software Wo
I'll send a status slide tonight.
Summary: was starved of CPU due to real time interrupts.
--
Michael Richardson , Sandelman Software Works
-= IPv6 IoT consulting =-
signature.asc
Description: PGP signature
___
Anima mailing list
Anima@ietf.org
es during
> chair slot. Otherwise, please feel free to ask for a slot, we still have
time
> on the Agenda.
We thought that brski-cloud was ready for WGLC last time.
https://datatracker.ietf.org/meeting/113/materials/slides-113-anima-brski-cloud-registrar-status-00
--
Michael Richard
Toerless Eckert wrote:
> I saw uploaded slides from Michael for constrainned-proxy, but none for
> constrained-voucher, so for now i have designated the 10 minute slot for
> constrained-proxy, but if you want another slot for constrained proxy,
let me
> know, otherwise i'll see
ges:
https://datatracker.ietf.org/meeting/114/materials/slides-114-anima-constrained-join-proxy-changes-from-ad-and-review-comments-00
--
Michael Richardson. o O ( IPv6 IøT consulting )
Sandelman Software Works Inc, Ottawa and Worldwide
signature.asc
Description: PGP signat
nyway, all I was really suggesting is that the Security Considerations
> need to explain why there is no vulnerability due to obtaining the list
> of pledges via mDNS.
okay.
--
Michael Richardson. o O ( IPv6 IøT consulting )
Sandelman Software Works Inc, Ot
Michael Richardson wrote:
> Note: We have three anchors that we might like to deploy.
> 1) the key that signs the RFC8366/constrained-voucher objects. Could
> be a RPK.
> 2) the key that signs the IDevID certificates in the devices. Most
> likely a RFC5
containing end
points with semantics that we control/define.
We already have /.well-known/brski, with IANA rules, so we should do it
there.
I'm sorry if this sounded like crying wolf :-)
--
Michael Richardson. o O ( IPv6 IøT consulting )
Sandelman Software Works Inc, Ottawa
e that the keypad does not activate the doors itself.
Rather, it securely communicates the keycodes to the authenticator.
(And BRSKI provided the keypad with trust anchors to make this possible)
So since you haven't got a keycode... what would you do?
--
Michael Richardson. o O ( IPv6 Iø
...
but, perhaps I don't understand your question well enough.
--
] 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[
ust anchor, and #1 and #2 might be
provided via subordinate CAs, and only #3 needs to be transfered.
(#1 is an EE certificate)
draft-richardson-anima-masa-considerations actually discusses some of the
options here.
--
Michael Richardson. o O ( IPv6 IøT consulting )
Sandelma
o do more.
This is not surprising in RFC8995(BRSKI), as it typically creates a
provisional TLS connection to the Registrar, which is *later* authorized by
an RFC8366 voucher.
Can we do this with supplicants?
I imagine so, but the write-up in the document could be challenging.
--
Michael Richardson. o O (
Topic/Title: EAP defaults for devices that need to onboard
Name of Presenter(s): Michael Richardson (with Alan DeKok)
Length of time requested: 5 minutes (new work)
Document If applicable:
https://datatracker.ietf.org/doc/draft-richardson-emu-eap-onboarding/
Alan and I have written a -00
on the pledge that I really prefer to avoid having time/date parsing
code present.
--
Michael Richardson. o O ( IPv6 IøT consulting )
Sandelman Software Works Inc, Ottawa and Worldwide
signature.asc
Description: PGP signature
___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima
3) should RFC8366bis gather up voucher-request, BRSKI-PRM needs?
4) yang:date-and-time vs CBOR Tag<1>. Should RFC8366bis do something?
5) interop efforts at NCCoE.
--
Michael Richardson. o O ( IPv6 IøT consulting )
Sandelman Software Works Inc, Ottawa and Wor
onable.
I'm curious what COSE people say.
KID is annoyingly use case specific :-(
--
Michael Richardson. o O ( IPv6 IøT consulting )
Sandelman Software Works Inc, Ottawa and Worldwide
signature.asc
Description: PGP signature
___
Anim
thing that translates to/from the ascii date representation as an *OPTION*
is just a non-starter.
I'm okay with some extension to SID to inform the encoder/decoder.
I started a thread in cbor@, and I think that we should do the work in cbor@
--
Michael Richardson , Sandelman Software Works
-= IPv6
nly the base types, not derived
> types.
So, do you think that auxiliary drafts could/should be written to deal with
special
encoding of derived times?
--
Michael Richardson. o O ( IPv6 IøT consulting )
Sandelman Software Works Inc, Ottawa and Worldwide
signature.asc
D
think we'd have to do that first)
--
Michael Richardson. o O ( IPv6 IøT consulting )
Sandelman Software Works Inc, Ottawa and Worldwide
signature.asc
Description: PGP signature
___
Anima mailing list
Anima@ietf.org
https://www.ie
Michael Richardson wrote:
> 2. The other thing we ran into was that the CBOR implementation I'm
using, when given a
> DateTime object naturally produces a RFC 8949 Section 3.4.2 compliant
"tag 1" marked Epoch-Based
> Date/Time. And demarshalls this. So I
Michael Richardson wrote:
> 2. The other thing we ran into was that the CBOR implementation I'm
using, when given a
> DateTime object naturally produces a RFC 8949 Section 3.4.2 compliant
"tag 1" marked Epoch-Based
> Date/Time. And demarshalls this. So I
ng-cbor-20.html#name-representing-yang-data-type
is silent about date and time formats.
https://github.com/core-wg/yang-cbor/issues/144
3. the third interop issue is a fault of mine where I encoded a binary object
as a string. Oops.
--
Michael Richardson. o O ( IPv6 IøT consulting )
ery of
Registrar, but we left AN_Proxy as empty string.
> (Comment: We didn't design GRASP for constrained environments and
> saving every possible bit on the wire. GRASP-lite, anyone?)
We can make it smaller only really by omitting things/features.
M_FLOODs fit into single 802.15.4
quot;very brief RFCs"...
Well, I think we should it down somewhere.
But, back to my second part:
> b) Why waste so many bytes when a small integer would do!
I can't see any reason why objective-value should be a string.
I don't think we are very constrained here, such that "DTLS"
hat BRSKI-PRM will need a new value too.
Note that I thought about a XxY mesh of objective-values such that the
Registry could say what kind of voucher-requests it supported, but I decided
that we had already decided that Registrars' had to lump it, and that pledges
should just try, and if th
power.
If so, a network operator can turn that off by changing parameters on the
Registrar.
--
Michael Richardson. o O ( IPv6 IøT consulting )
Sandelman Software Works Inc, Ottawa and Worldwide
signature.asc
Description: PGP signature
___
his can happen.
> While doing bad things to the registrar is one aspect, there is also
> the aspect of doing bad things to pledges, no?
Yes, they could, and the could do this directly using unencrypted LL packets.
--
Michael Richardson. o O ( IPv6 IøT consulting )
rs, then the attackers can *already*
>> do this kind of thing.
> This sounds a bit like "other protocols have weak security so we do
> not have to do better than that". It could be that my expectations are
> a bit over the top, but that is a decision
with RH3 headers, then the attackers can *already*
do this kind of thing.
--
Michael Richardson. o O ( IPv6 IøT consulting )
Sandelman Software Works Inc, Ottawa and Worldwide
signature.asc
Description: PGP signature
___
Anima mai
use case.
--
Michael Richardson. o O ( IPv6 IøT consulting )
Sandelman Software Works Inc, Ottawa and Worldwide
signature.asc
Description: PGP signature
___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima
specific work. The last messages to these lists where from
> 2018/2017, and they have long since survived their intended purpose.
> To be able to track the work of the WG it is a lot better to have all
> communications happen on the single WG mailing list anima@ietf.org.
Th
is, we use CoAP Block modes. This is also described in RFC9148.
--
Michael Richardson , Sandelman Software Works
-= IPv6 IoT consulting =-
signature.asc
Description: PGP signature
___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima
accessible network. Pascal might have some
things to say about 6BBR and DETNET here. But, this could be a Security
Consideration only.
> 4. We add a note to the Constrained BRSKI security considerations on
> this and leave it up to the implementer?
Let's describe the problem.
--
Michael Richa
code in the scenarios (network configurations) you
mention.
Please propose a solution, ideally in the form of pull requests, or at least
issues on the document repos themselves.
--
Michael Richardson. o O ( IPv6 IøT consulting )
Sandelman Software Works Inc, Ottawa and Worldwide
strar (across >= 1 L3 hop) ? If there is some mandatory support
> not only for unicast DNS (requests) but also automatically working
GRASP SRV.est?
>> If not for the above, I think that we would not have split RFC9148 out.
> What do you men with "split out" ?
est-co
rk layer IP multicast
> However, in fairness, the part of GRASP that relays discovery multicasts
> from one L2 segment to another is probably the most complex bit of the
> GRASP core. My code is 5 years old, and I've fixed two bugs in it
more complex than RFC7731? I doubt that.
--
Mich
ot exist in the mayority of target deployments of constrained proxy.
I agree that multicast is unlikely in many LLNs.
I don't agree that we need to do something for GRASP outside of ACP.
> 9. In result, i would suggest:
Not sure how this differs from #6.
> Logic for Pledge is simple: I
I think that we would not have split RFC9148 out.
--
] 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[
--
Michae
or
> discovery would need to be reinvented. And of course big proxies could
run all those
> protocols in parallel.
I'm worried about implying things which might not turn out to be true, and
which IESG members will jump on implying some kind of magic forward
compatibility with things not yet
I think that we actually need to fill them all in.
--
Michael Richardson. o O ( IPv6 IøT consulting )
Sandelman Software Works Inc, Ottawa and Worldwide
signature.asc
Description: PGP signature
___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima
hat mean"? I wrote an explanation, that I don't think
you read.
The "standard" interface from a join proxy to the pledge (if it's DTLS) is to
use CoAP over DTLS, on the port given. The details of how it gets back to
the Registrar is irrelevant to the pledge.
(If it'
now than later.
--
Michael Richardson. o O ( IPv6 IøT consulting )
Sandelman Software Works Inc, Ottawa and Worldwide
signature.asc
Description: PGP signature
___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo
95? That
> seems easier.
I thought we were going to extend AN_join_registrar.
--
Michael Richardson. o O ( IPv6 IøT consulting )
Sandelman Software Works Inc, Ottawa and Worldwide
signature.asc
Description: PGP signature
___
Anima
perate in the face of those
> devices seemingly being able to freely pick stateful and/or stateless
> mode of operations ?
Because, we defined the proxy to have a standard interface.
(Except for CoAP/OSCORE vs CoAPS above)
How the join proxy keeps state (in memory or in the network) is a p
ditor.org/rfc/rfc9031#name-statelessness-of-the-jp
but in the case of RFC9031, the security layer (OSCORE) is inside of CoAP,
so one can use the CoAP token to store the state.
In our case, the CoAP is *inside* the security layer (DTLS), so we can't do
that.
--
Michael Richardson , Sandelman Softwa
e difference between storing and non_storing Modes of
Operations (MOP) in RPL {{RFC6550}}. In the stateful method, the
return forward state is stored in the join proxy. In the stateless
method, the return forward state is stored in the network.
--
] Never tell me the odds!
again after being away from them for a few weeks.
--
Michael Richardson. o O ( IPv6 IøT consulting )
Sandelman Software Works Inc, Ottawa and Worldwide
signature.asc
Description: PGP signature
___
Anima mailing list
Anima@ie
Once a connection to the Registrar is found, then the question becomes: can
the pledge do CMP as well as EST? If so, it might need to discover if the
Registrar can do that.
I haven't opened another issue yet,because I'm not sure what to write yet.
--
Michael Richardso
Toerless Eckert wrote:
>> 6.5.1. Discovery
>>
>> The Pledge discovers an IP address and port number that connects to
>> the Registrar (possibly via a Join Proxy), and it establishes a DTLS
>> connection.
> This is very terse and possibly not completely correct.
>
Michael Richardson wrote:
> internet-dra...@ietf.org wrote:
>> Title : Constrained Bootstrapping Remote Secure Key
Infrastructure (BRSKI)
>> Filename: draft-ietf-anima-constrained-voucher-17.txt
>> A diff from the previous
I hadn't updated my
desktop yet when I submitted.
In the diff section 14.2: "IDevID security in Pledge" was filled in.
Section 5 "Updates to RFC8366 and RFC8995" has been filled out.
(I see one formatting goof that I'll fix)
--
Michael Richardson. o O ( IPv6 IøT consulti
ren't too many join proxies.
It's only when we play stupid L2 games, joining many links into a "LAN" that
the problem of too many join proxies becomes a concern :-)
--
Michael Richardson. o O ( IPv6 IøT consulting )
Sandelman Software Works Inc, Ottawa and Worldwide
rt on an IPv6 LL address), either may be switched in/out by the
network operator aka "installation engineer"
--
] Never tell me the odds! | ipv6 mesh networks [
] Michael Richardson, Sandelman Software Works|IoT architect [
] m...@sandelman
s going to be part of a deployable
infrastructure. (Not IETF Specification!)
--
Michael Richardson. o O ( IPv6 IøT consulting )
Sandelman Software Works Inc, Ottawa and Worldwide
signature.asc
Description: PGP signature
___
Anima
licability statement for the Join
> Proxy solution.
more later.
--
] Never tell me the odds! | ipv6 mesh networks [
] Michael Richardson, Sandelman Software Works|IoT architect [
] m...@sandelman.ca http://www.sandelman.ca/| ruby
arameters/brski-parameters.xhtml#brski-well-known-uris
Thank you.
--
Michael Richardson. o O ( IPv6 IøT consulting )
Sandelman Software Works Inc, Ottawa and Worldwide
signature.asc
Description: PGP signature
___
Anima mailing list
Anima
be establishing a registry or not?
--
] 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[
--
Michael Richardson
internet-dra...@ietf.org wrote:
> A new version of I-D,
draft-richardson-anima-registrar-considerations-05.txt
> has been successfully submitted by Michael Richardson and posted to the
> IETF repository.
> Name: draft-richardson-anima-registrar-co
send requests to anima-cha...@ietf.org.
Copy anima@ietf.org if you like.
Topic/Title
Name of Presenter(s)
Length of time requested
If applicable: name of draft(s) discussed
Topic: RFC8366bis
Presenter: Michael Richardson
Time requested: 15 minutes
Drafts: draft-ietf-anima
e.
There is often nothing IoT specific about many things.
There is however a community of people who understand the set of tradeoff in
deploying systems at large scale that have no human at the helm.
--
Michael Richardson. o O ( IPv6 IøT consulting )
Sandelman Software Works Inc, O
Hannes Tschofenig wrote:
> Based on what you wrote below I was actually wondering if the use of
> TLS or DTLS at the application layer wouldn’t even be a better
It took me a few moments to realize you meant ATLAS.
There is also, now, oblivious HTTP/TLS.
--
Michael Richardson
Have the SECDISPATCH chairs put it on the
agenda, or is there any agreement that maybe IOTOPS should dispatch it?
Hannes: what do you think?
--
Michael Richardson. o O ( IPv6 IøT consulting )
Sandelman Software Works Inc, Ottawa and Worldwide
signature
mcharl...@gmail.com wrote:
> You have been invited to the following event.
> Title: BRSKI design team 1Q2022
I was asked to repost this with a new name, because apparently some calendars
delete the entire sequence when one meeting is cancelled.
--
Michael Richardson. o O
e Secure Key
> Infrastructure (BRSKI) Authors : Michael Richardson Peter van der Stok
> Panos Kampanakis Esko Dijk Filename :
> draft-ietf-anima-constrained-voucher-16.txt Pages : 77 Date :
> 2022-02-14
...
> A diff from the previous version is available at:
>> like
>> TCP, UDP, SCTP, ESP, ...
>> Has IANA *already* registered port 7123 then?
> It's not an IP protocol. It's a service that listens on TCP 7123, I
> registered with IANA based on a previous version of the document,
> before I turned it
ey *aren't* what IANA would call "IP protocols", which would be things like
TCP, UDP, SCTP, ESP, ...
Has IANA *already* registered port 7123 then?
--
Michael Richardson. o O ( IPv6 IøT consulting )
Sandelman Software Works Inc, Ottawa and Worldwide
he wrong entries listed so I have
>> just reported this as an errata to RFC 8995 (https://www.rfc-
>> editor.org/errata/eid6834).
Ben: I agree with this errata.
Errata ID: 6834
also Errata ID: 6642 should maybe be verified.
Errata ID: 6648
Errata ID: 6649
--
Michael Richard
ce X".
Or now we think we can replace this with aodv-rpl.
I'm wondering if anyone has any thoughts on about to express this metric?
Is a metric the right thing to do? I doubt that this has utility in sensor
LLNs, but I think that RFC8994 ACPs would definitely like to have this.
--
Michael R
Internet Standard.
Do those documents Obsolete what they replace?
I wonder if the WG is onboard with going to IS.
--
Michael Richardson. o O ( IPv6 IøT consulting )
Sandelman Software Works Inc, Ottawa and Worldwide
signature.asc
Description: PGP
Sheng Jiang wrote:
> [1] "I am not aware of any IPR against this document"
___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima
ike
a bit more assurance that moving from RESTCONF->RFC8791 would be considered an
acceptable bug fix when going from Proposed Standard to Internet Standard.
--
Michael Richardson. o O ( IPv6 IøT consulting )
Sandelman Software Works Inc, Ottawa and Worldwide
signature.asc
wrote:
>> https://github.com/anima-wg/voucher/pull/18
> [Med] Thanks. Please consider running "pyang -f yang --keep-comments"
> for both modules.
Since we process the inputs for -MM-DD I guess that I can insert that
into the pipeline.
--
Michael Richards
proposal have been fully
> accepted and implemented.
It seems like a good thing to reduce amount of work for IANA, but I'm unclear
what, if anything, I need to do.
--
Michael Richardson. o O ( IPv6 IøT consulting )
Sandelman Softw
> Yes, that's true. On the other hand, I'd hardly like to encourage IPv4
> ACPs.
> I said 8992 and I think you saw 8994...
Yeah, I get that :-)
But, no point in advertising in GRASP (over an ACP) an objective that only be
satisfied by going to the dataplane to do IPv4.
--
Michae
r opinion.
> I don't think we have an installed base to worry about, and the
> difference for an implementor is not very big.
Yes, that's true. On the other hand, I'd hardly like to encourage IPv4 ACPs.
--
Michael Richardson. o O ( IPv6 IøT consulting )
Sandelman Sof
8) Consider adding an appendix to list the main changes vs. 8366.
I will add this after adoption comments.
--
Michael Richardson. o O ( IPv6 IøT consulting )
Sandelman Software Works Inc, Ottawa and Worldwide
signature.asc
Descript
to use
sx:augment-structure.
I will test this yang modules with our draft-ietf-anima-constrained-voucher
to understand if it results in changes to the SID generation or not.
I would like your opinion as to whether this change is small enough to fit
into going to Internet Standard for RFC8366.
--
M
d a new enum value? Does it make sense to change
> voucher-assertion typedef into identity data type.
Yes, we expect that new documents will Extend it.
I don't know what an identity data type is here I thought we did the
right thing, so I do not quite understand what you are proposi
t;mailto:kwat...@juniper.net>
> Author: Max Pritikin
> <mailto:priti...@cisco.com>
> Author: Michael Richardson
> <mailto:mcr+i...@sandelman.ca>
> Author: Toerless Eckert
> <mailto:tte+i...@cs.fau.de>";
> NEW:
> orga
ifferent
deployment scenarios (section 10)
9) add text explaining when to look for new trust anchor CA via /crts #186
10) clarify that the Registrar certificate can be self-signed #181
11) clarification of RFC4210 Root CA key change, close #163 issue-for-wg
--
Michael Richardson. o O
YANG module for the voucher
> itself, only for the voucher-request. To my understanding we do not
> need an augmentation for the voucher, as agent-proximity is already
> included in draft RFC 8366bis.
I think that is correct.
--
Michael Richardson. o O
.
I think that it's now future proof.
--
Michael Richardson. o O ( IPv6 IøT consulting )
Sandelman Software Works Inc, Ottawa and Worldwide
signature.asc
Description: PGP signature
___
Anima mailing list
Anima@ietf.org
https://www
(security) sense.
Also, in general, I'd rather we had fewer discovery methods on the
unprotected side.
(I also dislike "unprotected" to describe it.
This goes back decades as to whether the Internet or the LAN side of a
firewall is "red"...)
--
Michael Richardson
shortly be RFC 9164 , not in AUTH48).
It would cost 1 byte more.
if we don't, we concluded, for family to use:
https://www.iana.org/assignments/address-family-numbers/address-family-numbers.xhtml
--
] Never tell me the odds! | ipv6 mesh networks [
] Michael
f we have a DNS-SD method as well, then
that would just be an additional method inside an ACP.
--
Michael Richardson , Sandelman Software Works
-= IPv6 IoT consulting =-
signature.asc
Description: PGP signature
___
Anima mailing list
Anima@ietf.org
htt
.
Toerless: I think that this is the major change.
Qiufang Ma did the bulk of the YANG work here, and with the blessing of the
WG chairs, I'd like to add her as a co-author.
--
Michael Richardson. o O ( IPv6 IøT consulting )
Sandelman Software Works Inc, Ottawa and Worldwide
details : { ip : bstr,
port: int,
family : int,
index : int },
payload : bstr
]
{please forgive my poor CDDL here}
--
Michael Richardson , Sandelman Software Works
-= IPv6 IoT consulting =-
signature.as
/should we say this in RFC8366bis?
--
] 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
ined-join-proxy/pull/8
--
Michael Richardson , Sandelman Software Works
-= IPv6 IoT consulting =-
signature.asc
Description: PGP signature
___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima
201 - 300 of 1078 matches
Mail list logo
