he public (DNS) one!
--
] 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[
__
elieve in that case we also then do another lookup of the IDr
> in the forward to ensure it includes an A/ record to the IP we are
> connecting to.
What's happening to your document about this?
--
Michael Richardson , Sandelman Softwa
able.
I don't really see the difference except new people can get paid to
re-discover the last 30 years of mistakes in DNS implementations.
--
Michael Richardson , Sandelman Software Works
-= IPv6 IoT consulting =-
signature.asc
Description: PGP signature
Why did we skip
IKEv2_UNASSIGNED_17 = 17,
for IKEv2 Encryption Transforms?
https://www.iana.org/assignments/ikev2-parameters/ikev2-parameters.xhtml#ikev2-parameters-5
--
] Never tell me the odds! | ipv6 mesh networks [
] Michael Richardson, Sandelman
t needs to be a new state between
IKE_SA_INIT and IKE_AUTH.
> I agree. All of the DoS (cookie, etc.) defense and switch to TCP, and
> detection of NAT-T, etc. is in the IKE_SA_INIT, and so doing any kind of
> framentation in IKE_SA_INIT is a bad idea.
--
Michael Richardson , San
> bits)|
> The Fragment Counter is the same as in the RFC 7383 fragment payload,
> or zero if we are using the regular encrypted payload.
I think that #2 does a better job.
--
Michael Richardson , Sandelman Software Works
-= IPv6 IoT consulting =-
em.
> If you have comments (or objections) adding these new items to the
> charter send your comments as soon as possible.
I've read the new charter, and I think it's reasonable.
--
Michael Richardson , Sandelman Software Works
-= IPv6 IoT consulting =-
signatu
to the table to review.
I'd like to prioritize #2 as highest.
I think that #1 (Responder MOBIKE) may suffer from lack of actual
implementers being involved today.
--
Michael Richardson , Sandelman Software Works
-= IPv6 IoT consulting =-
signature.asc
Descri
, then I think that we can use this multi-level security
mechanism to advantage.
If the answer is yes (they can decrypt in real time), then we need to build
all the fragmentation protections into IKE_AUX anyway.
--
Michael Richardson , Sandelman Software Works
-= IPv6 IoT consulting =
ies for getting PLPMTUD enabled by default
everywhere. It would be nice if we could get a BCP out of them. Such
BCP could also bless PLPMTUD for everyone else. I was pushing for this
with RFC8200/STD86 but there was insufficient evidence of deployment.
--
Michael Richardson , Sandel
e problem of making the IKE responders stealthed seems like a different
problem entirely.
> Proposal is to add a shared secret and a PRF. These are added as an
> Michael Richardson: Smells like IKEv1 PSK with XAUTH. Unhappy about
> that. Seems that you're able to pro
at I was told. That's good for the network,
but
>> it removes them as strong allies for getting PLPMTUD enabled by default
>> everywhere. It would be nice if we could get a BCP out of them. Such
>> BCP could also bless PLPMTUD for ever
d. Having it
> as part of the TSi/TSr payloads makes that a lot more clear.
> Thoughts?
It has to be a traffic selector.
--
] Never tell me the odds! | ipv6 mesh networks [
] Michael Richardson, Sandelman Software Works| network architec
Michael Richardson wrote:
>> I think such an IPsec SA really conflates two different IPsec SA's. For
>> example, a service on a port where the IPsec SA is both for incoming and
>> outgoing connections are really two security contexts that can be split
&g
ever 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 signature
__
we can
more effectively test interoperability of fragmentation handling :-)
--
] Never tell me the odds! | ipv6 mesh networks [
] Michael Richardson, Sandelman Software Works| network architect [
] m...@sandelman.ca http://www.sandelman.ca/| r
ack isn't possible anymore.
--
Michael Richardson , Sandelman Software Works
-= IPv6 IoT consulting =-
signature.asc
Description: PGP signature
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
Tero Kivinen wrote:
> Anyways, I think proper fix would be to disable IKEv1 support
> completely, not to just disable RSA encryption mode...
+1
--
Michael Richardson , Sandelman Software Works
-= IPv6 IoT consulting =-
signature.asc
Description: PGP sig
tells whether door is
> now open or closed, and whether what transitions happened during last
> 30 seconds.
Good point, and this makes the packet the same size as well, and uses less code.
--
] Never tell me the odds! | ipv6 mesh networks [
] Micha
MPLS,
ATM, FrameRelay, and the newer L3VPN technologies that are sold as managed
solutions.
You need four IPsec SAs. They could be transport+GRE/IPIP tunnels rather
than IPsec Tunnel model SAs with a routing protocol on-top though.
--
Michael Richardson , Sandelman Software Works
-
ay's will find a way to attack client systems.)
--
Michael Richardson , Sandelman Software Works
-= IPv6 IoT consulting =-
signature.asc
Description: PGP signature
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
Michael Richardson wrote:
>> Presentation format includes things like comments, newlines,
>> whitespace etc.
>> That is the reason I do not like to have presentation format inside
>> the binary wire formats like IKE. We do not need to do string
{I think walled-garden DNS (whether for Enterprise use or IPTV) is security
threatre myself. IPv6 is here, use it, and stop building coconut networks.}
--
Michael Richardson , Sandelman Software Works
-= IPv6 IoT consulting =-
signature.asc
Description: PGP signature
___
ervice to have any
INTERNAL_DNS_DOMAIN, so it would be reasonable for a well configured client
to simply ignore such things.
(It's not like they have .internal or .corp for you...
Some of the services offer virtual corporation services, but that's really
a different kettle of fish)
--
d whatever
DNSSEC whitelisting is going to occur.
--
] 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
ppen. Each Enterprise can embed their IPv4 RFC1918 address space into
a unique IPv6 prefix, and can NAT64 to get to actual internal legacy services
if they have to.
--
] Never tell me the odds! | ipv6 mesh networks [
] Michael Richardson, Sandelman Sof
that's fine.
I think that letting CFRG pick two PAKEs for different purposes might
free up the log jam?
I also heard Dan offer to remain silent, and I just wanted to get that
on the record.
--
] Never tell me the odds! | ipv6 mesh networks [
] Michael Richardson
| 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
___
IPsec maili
o-site
inter-company VPNs. This is note for road-warrier accesss.
I would prefer that the PAKE method was not wrapped in EAP.
--
Michael Richardson , Sandelman Software Works
-= IPv6 IoT consulting =-
signature.asc
Description: PGP signature
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
Paul Wouters wrote:
> > Because I share Paul's view that the PSKs we care about are generally
> > identical in both directions
>
> I agree here.
>
> > , and this use is primarily about site-to-site
> > inter-company VPNs. This is note for road-warrier accesss.
>
> But not here. weak group PSK's
Paul Wouters wrote:
> > On Dec 10, 2018, at 19:51, Michael Richardson wrote:
> >
> >
> > Paul Wouters wrote:
> >>> Because I share Paul's view that the PSKs we care about are generally
> >>> identical in both directions
> >>
> &
Nico Williams wrote:
> On Mon, Dec 10, 2018 at 09:20:54PM -0500, Michael Richardson wrote:
> > Paul Wouters wrote:
> > > > yes, typo, "not for road-warrior"
> > >
> > > I understood. I disagree with the “not”. Road warriors using group psk is
&g
this was where ther was a weakness.
--
Michael Richardson , Sandelman Software Works
-= IPv6 IoT consulting =-
signature.asc
Description: PGP signature
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
Yoav Nir wrote:
> I don’t think the idea is to replace a 128-bit PSK derived from a properly
> seeded DRBG with “ip5ecmeRockz!” using a PAKE.
Please! The official PSK is "makemetastegoat"
--
Michael Richardson , Sandelman Software Works
-= IPv6 IoT consulting =-
signature
that maybe we forgot to tell IANA to deprecate anything that was
SHOULD NOT/MUST NOT, or that fell off the list. Maybe this can be clarified
as an IESG directive rather than as a new document.
--
Michael Richardson , Sandelman Software Works
-= IPv6 IoT consulting =-
sig
en the lawyers, and contributes to
widespread (weak) PSK usage.
--
Michael Richardson , Sandelman Software Works
-= IPv6 IoT consulting =-
signature.asc
Description: PGP signature
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
's way better than PSK.
> I think actual deployment, and what is specified in RFCs, at least in
> RFC 4945, has diverted quite a bit. I think 4945 needs to be updated.
> But that update would almost have to be "TLS compliant", so it
> basically comes down to
to
> start becoming out of order when they are sent encapsulated.
Can you explain why this is an issue?
--
] Never tell me the odds! | ipv6 mesh networks [
] Michael Richardson, Sandelman Software Works| network architect [
] m...@sandelm
the sender either uses it or does not.
--
] 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[
for the AS
that is sending the packets.
--
] 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[
si
Graham Bartlett (grbartle) wrote:
> From my limited experience the performance of many applications is
> degraded when traffic is received out of order.
If the flows are marked differently, then they are from different
applications, so it does not matter.
--
Michael Rich
ges to the IANA registries I'm
less clear about, but I believe it could also be done without a document.
--
Michael Richardson , Sandelman Software Works
-= IPv6 IoT consulting =-
signature.asc
Description: PGP signature
___
IPsec mailing
actually
pay attention to that.
I know that the Google Android team are aware of the lack, but it seems
that it is not a priority. This is sad, but the IETF works with carrots, not
sticks.
But, to be clear: I'd like the WG to adopt your document, and I'd like it to
be the basis for *so
I read this document.
It seems pretty straightforward, the reasoning makes sense.
I think that it might be useful for privacy VPNs as well.
--
Michael Richardson , Sandelman Software Works
-= IPv6 IoT consulting =-
signature.asc
Description: PGP signature
d to make more
> explicit
I'm not super enthusiastic about IKE_INTERMEDIATE, but I sure prefer it to
aux! Thank you for the change.
--
Michael Richardson , Sandelman Software Works
-= IPv6 IoT consulting =-
signature.asc
Description: PGP signature
___
er all the things not covered in the more
paul> specific notifies.
I would like some more fine-grained replies as well.
--
Michael Richardson , Sandelman Software Works
-= IPv6 IoT consulting =-
signature.asc
Description: PGP signature
___
oups would be bigger than with ECDH groups. }
--
Michael Richardson , Sandelman Software Works
-= IPv6 IoT consulting =-
signature.asc
Description: PGP signature
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
where n=number of
clients, m=number of suites.
--
Michael Richardson , Sandelman Software Works
-= IPv6 IoT consulting =-
signature.asc
Description: PGP signature
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
Christian Hopps wrote:
> Hi ipsecme and chairs,
> As discussed @IETF105 we need to update the charter in order to adopt
> the IPTFS draft, how does this look for addition to the charter?
Works for me.
> " The demand for Traffic Flow Confidentiality has been increasing in
> t
t should be that simple. The protocol shouldn't have to change, no new
> messages, no new payloads, no new nuthin. If I'm missing something please
> let me know.
As I understand you, it's basically PSK authentication, but the PSK is
no longer directly shared. Would
's marked IETF Review, so a document is needed (but necessarily standards
track).
What's your use case today? Surely not tm-rid?
--
] Never tell me the odds! | ipv6 mesh networks [
] Michael Richardson, Sandelman Software Works| network architect [
ask for an early allocation for you at this point,
alas.
--
] Never tell me the odds! | ipv6 mesh networks [
] Michael Richardson, Sandelman Software Works| network architect [
] m...@sandelman.ca http://www.sandelman.ca/| ru
I have read the document in a few iterations.
I think that it addresses an important need both for resistance to traffic
analysis, but also it has the potential to deal with the PMTU problems that
tunnels always seem to create.
Please adopt!
--
Michael Richardson , Sandelman Software Works
e difficult to do, but if
it's not hard to do, then don't forbid it.
(We also shouldn't forbid transporting Elephants in small clown cars, but I
don't recommend that either)
--
Michael Richardson , Sandelman Software Works
-= IPv6 IoT consulting =-
le to use it with transport mode could be
interesting, but I think that BEET mode is more likely.
I think that having a proper IP protocol number will simplify kernel
implementations.
--
] Never tell me the odds! | ipv6 mesh networks [
] Michael Richardso
ure. But I think it will help
> (and not harm), so I think we should just publish it for those who can
> use it as a lever to migrate more older setups to new. To be honest,
> the biggest gain will be that people stop using DH1024, DH1536 and SHA1
> that are defa
col would take care of the ::/0<->::/0
needs, not IPsec.
--
Michael Richardson , Sandelman Software Works
-= IPv6 IoT consulting =-
signature.asc
Description: PGP signature
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
> Michael: Yoav talked about the non-GRE case.
In the non-GRE case, then it's just IPIP-over-IPSEC-transport mode.
Which is literally the VTI case.
--
] Never tell me the odds! | ipv6 mesh networks [
] Michael Richardson, Sandelman Software Works
Yoav Nir wrote:
> The draft says “IPsec tunnel mode is required ”, so it’s not
> transport. What goes in the TS payloads?
TSi=HostA-LL/128, TSr=HostB-LL/128, Protocol = GRE(47) or IPIP(41)
>> On 26 Feb 2020, at 3:20, Michael Richardson
>> wrote:
>>
>> accurately: “indicated by an ASN.1 object AlgorithmIdentifier”
> Wouldn't it be more correct to say "indicated by a SubjectPublicKeyInfo
> (SPKI) ASN.1 object" ?
I have no opinion here.
--
] Never tell me the odds!
rk on acceptance/education
> prior to WGLC/IESG submission. And, however unlikely, if we find we
> cant allocate a protocol number, we can fall-back to using
> zero+ike/config without a lot of additional work.
And I agree with having the WG ask for early allocation.
--
Mich
don't think I see a problem with that description, but wanted to run it
>> by the WG for a quick sanity check before the document gets approved, in
>> case there's something I'm forgetting.
> Looks correct and appropriate to me.
I also agree.
--
Michael R
e hardware. (Cargo culting...) This was maybe 6 years ago.
I believe that we could remove it.
--
Michael Richardson , Sandelman Software Works
-= IPv6 IoT consulting =-
signature.asc
Description: PGP signature
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
x27;t how to fix or debug it either.
In short: as Tero has pointed out it's already SHOULD NOT, and making it MUST
NOT makes existing deployed products out of spec. I guess we don't have to
rush.
--
Michael Richardson , Sandelman Software Works
-=
to make GRE/tunnel fit into
your current situation, or if you are describing a new situation that would
handle in a new draft.
--
Michael Richardson , Sandelman Software Works
-= IPv6 IoT consulting =-
signature.asc
Description: PGP signature
___
IPsec
eed to clearly
articulate where the extension point is in this draft.
I will have to re-read the document, since it's been awhile since I read it.
--
Michael Richardson , Sandelman Software Works
-= IPv6 IoT consulting =-
signature.asc
Description: PGP signature
it.
I don't think it matters what cipher you use, although I can imagine trying
to bork this issue via some super-specific custom thing.
> My cursory review is not showing this is currently supported.
> Is it, our would I need to define a variant of the AES-GCM mode?
--
Michael R
ms, as
> that would most likely mean that this work does not belong to the
> IPsecME working group, but should be part of completely different
> area...
Let's assume that we might want to use this protocol with another secure
tunnel protocol which was not ESP. But,
cation.
Does your use case include situations where this is not an IPsec tunnel?
Tero's point was that when we are putting things into ESP, that we
effectively get an IPsec-specific protocol number space, and so maybe we
don't need a first-class protocol number.
--
Michael Richardson
A new IETF WG has been formed in the Transport Area. For additional
information, please contact the Area Directors or the WG Chairs.
Multiplexed Application Substrate over QUIC Encryption (masque)
---
Current status: Propos
.
If I ask for transport mode, and the other end does not agree to do it, I can
certainly drop the negotiation.
The ANIMA WG *can* write a stronger requirement, because that does not
contradict RFC7296. We can't make something optional that IPsec requires,
(such as ESP without authentic
at a profile should do.
How is this different than:
"request authentication with a RSA certificate known to this CA,
and refuse the connection if the other end is unwilling to use an appropriate
key"
--
Michael Richardson , Sandelman Software Works
-= IPv6 IoT consulting =-
Sigh. Again.
The Autonomic Control Plane is established by automatic mechanisms,
not by "administrators". That is, we have a protocol that acts as the
"administrator" in this case.
So, yes, we (ANIMA) can use BCP14 to say what the "configured" policy will be.
--
Mic
luding the root CA (TA) in the CERT
> payload. It is perfectly valid. There is a privacy/security risk of
> revealing the root your trust. But that's your risk to evaluate.
Good, we are in agreement here.
--
Michael Richardson , Sandelman Software Works
-= IPv6 IoT consulting =
AP as returned, that's a different
discussion as well.
--
Michael Richardson , Sandelman Software Works
-= IPv6 IoT consulting =-
signature.asc
Description: PGP signature
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
Michael Richardson wrote:
> But, we are not out of protocol numbers, and I think that if it comes to
recycling
> numbers, that maybe there are many low-hanging fruit as candidates.
> [13-16,18-26 comes easily to mind]
If I had to pick something, though, I'd
to match the certificate subject alt name or subject name to
> identity or information in the policy.
So, we've been forced to use otherName, and this will cause new code in some
of the IKEv2 daemon that we need to use :-(
--
Michael Richardson , Sandelman Software Works
-= IPv6 I
l cause new code in
some
>> of the IKEv2 daemon that we need to use :-(
> No, you are not forced to use anything. Your ID could be KEY_ID with
No, the ACP document has been forced to use otherName in it's
certificates. That's nothing to do with IPsec/IKEv2.
But, that tha
I agree with this model.
And I think that IKEv2 makes this significantly easier than IKEv1 did.
We are still relearning Photuris.
--
Michael Richardson , Sandelman Software Works
-= IPv6 IoT consulting =-
signature.asc
Description: PGP signature
___
with the one that works best for non-encrypted traffic, and
is easier to code/debug.
> As a matter of historical record, this was also a long debate for TCP.
> The default is leading, and there is a TCP option for trailing checksum.
> Might it be a non-default option n
ways) within the time B?
It seems that this is the only thing that would require state to be exchanged.
--
Michael Richardson , Sandelman Software Works
-= IPv6 IoT consulting =-
signature.asc
Description: PGP signature
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
just don't let the ticket be valid for longer
> than the creation time plus rekey time.
> It would be really nice if we can keep the server side to need to
> require zero state. If we ignore those two issues mentioned, we can
> do that.
I agree.
--
Michael Richardson , Sandelman Software Works
-= IPv6 IoT consulting =-
signature.asc
Description: PGP signature
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
round, then one has some state in which to store
per-user data.
--
Michael Richardson , Sandelman Software Works
-= IPv6 IoT consulting =-
signature.asc
Description: PGP signature
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
Hi, I finally got to watching your presentation on the IETF youtube
channel. the illustration at https://youtu.be/IrNsFAPhx-Q?t=3410, which
I guess is also at:
https://www.ietf.org/proceedings/108/slides/slides-108-ipsecme-proposed-improvements-to-esp-01
slide 3.
It is unfortunate that the y
Michael Richardson wrote:
> Hi, I finally got to watching your presentation on the IETF youtube
channel.
> the illustration at https://youtu.be/IrNsFAPhx-Q?t=3410, which I guess is
> also at:
>
https://www.ietf.org/proceedings/108/slides/slides-108-ipsecme-proposed-
in hardware. Hardware is not going to have more than two ciphers.
If as many as two.
Again, I suggest you write an Informational document, as for a code point,
and submit through ISE.
--
Michael Richardson. o O ( IPv6 IøT consulting )
infer the payload type some other way *has* to be
> seen as a hack. Why do we need a hack?
I don't understand either.
Can we just let these guys get on with their work?
--
Michael Richardson. o O ( IPv6 IøT consulting )
Sandelman Software Works Inc, Ottawa and Worl
nto subsubsubsection.
2.4.21: Maybe need to briefly explain circuit breakers to us
non-transport-types.
> If the SA back to the sender is a non-
>AGGFRAG_PAYLOAD enabled SA then an AGGFRAG_PAYLOAD empty payload
>(i.e., header only) is used to convey the information.
is this really worth
FS) and it's utility beyond
> that application is certainly a bonus -- the very recent name changes
I agree.
--
Michael Richardson. o O ( IPv6 IøT consulting )
Sandelman Software Works Inc, Ottawa and Worldwide
signature.asc
Descri
information.
>>
>> is this really worth supporting?
> It doesn't take much to continue to allow for unidirectional use at the
> lowest layer (ESP/SA). It isn't relevant once you get to IKE where
> bidirectionality is required.
I think that maybe this is in the MAY.
It's isn't clear to me if I need to support that or not.
--
Michael Richardson. o O ( IPv6 IøT consulting )
Sandelman Software Works Inc, Ottawa and Worldwide
signature.asc
Description: PGP signature
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
) How do I learn about traffic that was dropped?
I'm on about this, because I think that PMTU issues are among the biggest
problem for IPsec.
If we can auto-tune the tunnel size, that's really a killer use.
--
Michael Richardson. o O ( IPv6 IøT consulting )
Sandelman So
at's my PL?
I would know that it failed if I get a sender timestamp X (getting X+1),
that the oversize packet was lost.
--
Michael Richardson. o O ( IPv6 IøT consulting )
Sandelman Software Works Inc, Ottawa and Worldwide
signature.asc
Description: PGP signature
___
ntence is a claim, and I think that they
should point to references. That will make it much more impactful a
document in my opinion.
But, I'd rather publish it if adding such references is hard.
I think that the third paragraph (labelled IPsec) should be a new section
3.1.
--
Michael Richards
the byte counters.
The use of the word "octets" is traditional in MIB documents, going back to
the 1980s, when ASN.1 originated.
Some machines had 9-bit bytes and 36-bit words :-)
I also support adoption.
--
Michael Richardson , Sandelman Softwa
Paul Wouters wrote:
> On Sat, 13 Mar 2021, Michael Richardson wrote:
>> I'd *like* section 3 to enumerate the claims clearer (Maybe just new
>> paragraphs).
> You mean a textual change? like split out more, or bullet points?
Yes. I am imagine
ist. Since this is rather new, short messages in the vein of
> “Yeah, this is good. Ship it”, but substantive comments are, of course,
> even more welcome.
Re-read to be sure.
Ship it.
--
Michael Richardson. o O ( IPv6 IøT consulting )
Sandelman Software Works Inc,
I think you'll all be happier with a virtual interim meeting with no conflicts.
We can now use meetecho even.
--
Michael Richardson. o O ( IPv6 IøT consulting )
Sandelman Software Works Inc, Ottawa and Worldwide
signature.asc
Description: PGP sign
ot our area of
>> expertise, and we have already received approval from the experts for
>> the text that we have. Let’s stick with the approved text and make
>> clarifying modifications only.
I understand and agree.
Maybe clearly pointing at what text is involved w
document submitted to the IESG.
(And the IESG has become even more active, so it could still take many
revisions to get to publication)
--
Michael Richardson. o O ( IPv6 IøT consulting )
Sandelman Software Works Inc, Ottawa and Worldwide
signature.asc
Description: PGP
bullet
> list to make it more informal and not look like it is claiming a
> complete list of items.
Great.
--
Michael Richardson. o O ( IPv6 IøT consulting )
Sandelman Software Works Inc, Ottawa and Worldwide
signature.asc
Description: PGP signature
__
1 - 100 of 439 matches
Mail list logo
