> I actually have mostly written RFC's for both.
Please submit them as I-Ds:
https://datatracker.ietf.org/submit
Please make sure you agree with this:
https://tools.ietf.org/html/bcp78
> The price updates are hacked onto the update tlv as we aren't running
> the price extension I
> Interesting stuff - wireguard, fq_codel/sch_cake, babel with new
> metric that allows for cryptocurrency traffic billing.
Justin, could you please document the private TLVs that you're using and
register them with IANA? (I'm currently under pressure to make the TLV
allocation more onerous, and
> Interesting stuff - wireguard, fq_codel/sch_cake, babel with new
> metric that allows for cryptocurrency traffic billing.
Justin, could you please document the private TLVs that you're using and
register them with IANA? (I'm currently under pressure to make the TLV
allocation more onerous, and
> Interesting stuff - wireguard, fq_codel/sch_cake, babel with new
> metric that allows for cryptocurrency traffic billing.
Justin, could you please document the private TLVs that you're using and
register them with IANA? (I'm currently under pressure to make the TLV
allocation more onerous, and
Is there an IPv6 link-local address on the tun0 interface? Please show us
the output of
ip addr show dev tun0
If there's no link-local address (Linux kernel bug), then you should add
one manually:
ip addr add fe80::1/64 dev tun0
You should use different link-locals on the two sides of
> No, we are assuming that there are one or more homenet routers that either
> come with a delegated domain from the manufacturer (probably a very ugly
> one), or which that CPE's ISP will delegate via DHCPv6. (or both)
I see. (I still disagree with the technical choices, especially that of
>> Your turn now. Could you please describe the UI that you envision?
> The list of names (from the internal mDNS/DNS-SD, as well as DHCP hostnames)
> is presented to the house owner, they click on the ones that the want to
> be publically visible.
Are you assuming here there's a central
> It would seem your objection can be summarized as "we don't need this".
> Correct me if I'm wrong.
No, my objection is that I cannot see how that can work in a decentralised
manner -- with no central Homenet controller.
> To me is like saying we don't need a new routing protocol like BABEL,
> Actually, it's fatal, because you can't get a certificate for "boombox.local"
> so you can't secure it that way. So you always have to use the FQDN.
That sucks, of course, but the problem is completely unrelated to being
published in the global DNS -- the very same problem applies to names
> The front end naming architecture uses a primary and a secondary dns server to
> synchronize a zone.
People will recall that the need for a hidden primary hasn't been
established yet. Please see my unanswered e-mail of 21 November 2018.
>> I'm sending you this email to inform you that there isn't any
>> documentation about HMAC in the babel manual.
> Isn’t the code self-documenting?
Well, sure, it's beautifully written :-)
Still:
- the HMAC branch hasn't been merged into mainline yet;
- even in the HMAC branch, there
>> If there is a more complex HNCP network, then we could probably simulate
>> the L2 scenario with VXLAN, configured by HNCP.
> If memory serves, VXLAN requires support for multicast, which HNCP+Babel
> doesn't provide. There's a set of IBM (?) extensions to VXLAN that avoid
> the use of
> If there is a more complex HNCP network, then we could probably simulate
> the L2 scenario with VXLAN, configured by HNCP.
If memory serves, VXLAN requires support for multicast, which HNCP+Babel
doesn't provide. There's a set of IBM (?) extensions to VXLAN that avoid
the use of multicast, I'm
> prplMesh solves the wifi broadcast domain issue.
>https://prplfoundation.org/working-groups/prplmesh/
>From their website: « prplMesh is an open-source, carrier-grade and
certifiable implementation of the WiFi Alliance’s Multi-AP specification. »
That's a purely layer 2 solution that
>> Is there a command to check if babeld is working and which
>> nodes are in the topology?
> There is the `-d level` (level 1 is good enough) of babeld that
> shows neighbours and installed routes.
Uh-huh.
You can also:
- send a SIGUSR1 to babeld to get a dump;
- run babeld with '-g
Dear all,
The Babel meeting at IETF 104 will be this Thursday 28 March in room
Athens/Barcelona.
https://datatracker.ietf.org/meeting/agenda/
If you're in Prague, please come. If you're not in Prague, please attend
through the Internet :
https://www.ietf.org/how/meetings/104/remote/
The
> PIE [...] lends itself better for implementation in existing hardware,
> or hardware with small modification.
Could one of you please explain why?
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet
>> - we compute HMAC for each TLV, rather than just once for the whole
>> packet, which, again, makes us vulnerable to DoS;
> ugh.
Don't worry, it's an easy fix.
>> - we don't support key rotation.
> Sigh.
The data structures are designed so it'll be easy, the problem is
designing an
Hi,
I've finally gotten my act together, and reworked Clara's and Weronika's
implementation of Babel-HMAC. You can get the code by doing
git clone -b hmac --recurse-submodules https://github.com/jech/babeld
While this code is almost completely untested, it is meant to eventually
implement
>> I think that this work should be stalled until we have an implementation
>> to play with and make some in vivo experiments.
> I'm not sure if by "stalled" you mean sticking with the plan above, or
> something else
I'm concerned about two things:
- if you're not implementing yourself,
Hi Stephen,
Sorry if I'm repeating myself -- I've already expressed the opinions
below, both at the mike and on the list.
> (a) work on simple naming
I think that this work should be stalled until we have an implementation
to play with and make some in vivo experiments. (Experience shows that
> Yes, in this situation all neighbor stations enumerate. Everyone can ping
> everyone via 802.11s mesh.
You're running Babel over an 802.11s mesh? Why?
Both Babel and 802.11s are routing protocols (more exactly, 802.11s
contains a routing protocol). Running both in the same mesh is
> Both HNCP and Babel carry their control traffic over link-local IPv6, but
> they support both IPv4 and IPv6 with almost equal functionality.
> (The only significant difference is the treatment of border routers, which
> are assumed to be doing NAT in IPv4 and stateless routing
> I do remember that talk. CS grad students are not our target market.
First year undergrad, Ted. Eighteen year-old lass with no previous
networking experience.
-- Juliusz
___
homenet mailing list
homenet@ietf.org
Hi Stuart,
> I would much rather use babeld, and I had set it up with the default
> settings from OpenWRT, but the radios fell off the net (not a logfile
> issue).
What do you mean they "fell off the net"? Is the link layer associating?
Please run "iw dev wlan0 station dump" on each of the
>> It should be an easy fix, feel free to go ahead.
> The point of soliciting participation at hackathon is for us to gain
> collective experience on the easy or difficulty of deploying homenet in
> practice.
Oh, that's different, and not at all the motivation you give in your
previous mail.
>> Both HNCP and Babel carry their control traffic over link-local IPv6, but
>> they support both IPv4 and IPv6 with almost equal functionality.
>>
>> (The only significant difference is the treatment of border routers, which
>> are assumed to be doing NAT in IPv4 and stateless routing in IPv6.)
> Both HNCP and Babel carry their control traffic over link-local IPv6, but
> they support both IPv4 and IPv6 with almost equal functionality.
> in fact while what you are saying is technically true, in practice IPv4
> _is_ treated like a second-class citizen in the sense that if your
>
> What I meant is that homenet router protocols are v6 only.
No, they're not.
Both HNCP and Babel carry their control traffic over link-local IPv6, but
they support both IPv4 and IPv6 with almost equal functionality.
(The only significant difference is the treatment of border routers, which
are
> For BATMAN, I’m using LibreMesh.org and for BABEL, I’m trying to find a
> solution using OpenWRT and babeld but it is not a success… Does anybody know
> where I can find a simple solution using Babel protocol to implement on my
> routers with OpenWRT (or something similar)?
It is my opinion
> point it, it's already been applied - should i remove it or not?
It doesn't hurt, so if you'd rather not bother with a new upload, feel
free to leave it as it is.
Sorry again for the confusion,
-- Juliusz
> Debian (i think) ships dht
> https://salsa.debian.org/debian/transmission/blob/master/third-party/dht/CHANGES
> - what should we do here?
Debian's 2.94-1+b2 appears to be shipping 0.22, which is a rather old version.
There's no need to apply this patch to that version.
-- Juliusz
> in light of
> https://github.com/transmission/transmission/issues/782#issuecomment-450852432
> should
> https://salsa.debian.org/debian/transmission/blob/master/debian/patches/patch-vendored-libdht.patch
> be reverted?
dht-0.25 doesn't have the bug. The patch is harmless, but it doesn't
> See https://golang.org/cl/36022.
There's a terrifying sort of beauty to it, like a tarantula or a snake.
(And it most certainly deserves a comment in the source.)
-- Juliusz
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe
>> I think that the HMAC key should be generated automatically. I'd hope
>> that any actual production deployment of HMAC would generate HMAC keys
>> either randomly or by using a suitable KDF (or whatever the right acronym
>> is) and distribute it automatically.
> Should we pick a KDF? Not
> 'Cause I'd sent you a patch earlier for just e (240/4) and you didn't
> apply it? :)
I'm a bad man. Please double-check commit 19a442ba.
-- Juliusz
___
Babel-users mailing list
Babel-users@alioth-lists.debian.net
Thanks, applied.
___
Babel-users mailing list
Babel-users@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/babel-users
> This patch enables both class-e and multicast IP addresses to be
> carried within the babel protocol.
No objection to class E, but why multicast?
___
Babel-users mailing list
Babel-users@alioth-lists.debian.net
Thanks, applied.
___
Babel-users mailing list
Babel-users@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/babel-users
> I happen to really like timerfds but they are a linuxism.
How would they be used here?
___
Babel-users mailing list
Babel-users@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/babel-users
Great, I've been planning that for a long time.
> +.B neighbour-monitor
> +and
> +.BR neighbour-unmonitor ;
Please use the syntax "monitor neighbours" and "unmonitor neighbours".
Two keywords.
> +#define CONFIG_ACTION_NEIGHBOUR_MONITOR 6
> +#define CONFIG_ACTION_NEIGHBOUR_UNMONITOR 7
> +#define
> this illustrates how the taskqueue can be used and removes a little bit of
> code from the main loop
It would be more interesting to see how you can replace the mess that is
resend.c. That will require an interface for task cancellation.
-- Juliusz
Thanks for the code.
> The task queue allows to schedule tasks that happen in the future.
This implements a binary heap as a linked tree, which has very poor
locality. In order to improve locality and avoid memory allocations, we
should be implementing the heap as an array.
An alternative
> I find it difficult to read the babeld code
It was difficcult to write. I don't see why it should be easy to read ;-)
> I guess that reach is a bitmap of some kind, storing on which of the
> last 16 hellos the neighbour was reachable.
That's right. The logic is in update_neighbour, and
> I would like the bird and babel implementations to allow for and use
> BASE64 and hex encodings.
> This allows for a shorter, more human friendly representation of both
> cryptographically generated keys and the keys humans are more likely
> to remember and type without error. In the latter
Package: transmission-gtk
Version: 2.94-1
Severity: wishlist
Hi,
I've just released libdht version 0.26, which fixes a rather unpleasant
bug. I've filed a bug upstream:
https://github.com/transmission/transmission/issues/782
Since upstream hasn't done a release in a long time, I'm attaching
> This is the present babel conf file format:
> key id key1 type sha1 value deadbeefdeadbeefdeadbeefdeadbeefdeadbeef
> key id key2 type sha1 value dea2f0d01a57b0071057a11da7adeadbeeff
> interface enp7s0 unicast false hmac key1
> interface wg1 hmac key2
Right. It currently cannot be updated
> In glibc (not musl so far as I know) the clock_getttime lookup is
> incredibly fast because it just maps in the relevant kernel page and
> does the work without a syscall,
In musl too:
https://git.musl-libc.org/cgit/musl/tree/src/time/clock_gettime.c
Also, babeld doesn't make that many
Thanks, Christof.
I'm still dealing with exams and student defenses, I'll review all of your
proposals during the holidays.
Genuinely sorry for the delay,
-- Juliusz
___
Babel-users mailing list
Babel-users@alioth-lists.debian.net
> Setting that aside for the moment, having a standardized file format
> for babel keys would be a boon and boost interoperability between
> bird/babel and other possible implementations.
Have you looked at RFC 7210?
-- Juliusz
___
Babel-users mailing
> FWIW, for homenet the thought was to use HNCP to distribute keys amongst
> routers.
HNCP is not a good choice for symmetric key distribution, since it floods
all information across the HNCP domain. It's impossible to use HNCP to
distribute a key to some routers only while keeping it secret
> The "one interface per key" rule adds complexity but I think it also
> brings benefits by requiring such.
It's conceptually elegant and easy to explain. These are good features to have.
> About the only issue I see for an interchange like this is that you'd
> also need one ipv4 address per
> as keys (currently) protect each interface, not each router association...
Correct. Babel uses both unicast and multicast, and Babel-HMAC is
designed so that it can protect multicast traffic while remaining immune
to replay, even in the absence of persistent state or hardware clocks.
>
>> Where is Blake2S-based HMAC defined? RFC 7693 merely says
> Section 3.3 simply says:
>If a secret key is used (kk > 0), it is padded with zero bytes and
>set as d[0]. Otherwise, d[0] is the first data block. The final
>data block d[dd-1] is also padded with zero to "bb" bytes
>> (1) leave the document as it is;
>> (2) add a mention that implementation of Blake2S is RECOMMENDED (SHOULD);
>> (3) add a mention that implementation of Blake2B is RECOMMENDED;
>> (4) add a mention that implementation of both 2B and 2S is RECOMMENDED.
> I'm in favour of (2).
Where is
>> With these numbers, I withdraw my support of including anything else
>> than SHA256 as MTI. I think specifying Blake2B or 2S as well makes
>> sense (mostly for crypto robustness reasons for having alternative
>> that is specified) but making it MAY-SHOULD seems sensible to me.
> I can probably
> Why not? If it's not MTI you risk the case where you get to pick between
> "good performance on weak devices" and "interoperability with RFC-only
> implementations".
Is there any evidence that there are devices that can reasonably run Babel
and that are too weak to use SHA256 for protecting
> Dave had a good point as well though, comparing -2s and -2b performance
> on some set of hardware (e.g. arm, mips, intel) might be in order before
> picking between the two.
HMAC only protects the control traffic, not the data traffic. I'm not
convinced that performance is particularly
> I'm not sure if we *can* make [blake2s] MTI in the spec as well (does it
> need to be defined by a standards track RFC for us to do that?), but if
> we can, I think we should seriously consider it...
Opinions?
___
Babel-users mailing list
> Anyway, the default hash function is sha256 in the hmac-challenge
> branch. I approve, there's hardware support for it, and if someone
> breaks it, civilization collapses, so an alternate hmac is a "good to
> have", and what's in that branch... is ripemd160.
From a standardisation point of
Thanks for your reply, Daniel.
> If I understand correctly the question is why do we have a Homenet Naming
> Authority responsible to outsource the Homenet Zone to the Public
> Authoritative
> Servers ( Front End architecture) instead of having each device updating their
> data directly to the
Dear Daniel,
> I am planning to update the front end naming delegation draft [1] in the next
> weeks. Before revisiting the draft, I am collecting comments that need to be
> addressed.
After your talk at IETF-102, I asked what is the purpose of this rather
complex protocol, and why it is
>> Unless I've missed something -- they are not, assuming you have
>> a sufficiently strong random number generator. The challenge mechanism
>> rebuilds the shared state in a secure manner, and the index mechanism
>> ensures that an (index, seqno) pair is never reused.
> I had a really hard time
> - s2.5 Not sure what the ceremonies around flushing a neighbor are,
> but I'd make explicit signalling EOD at least a SHOULD? It seems more
> polite :-)
> I agree, I upgraded politeness to a SHOULD.
Note however that a neighbour is usually discarded when we loose too many
Hellos
> Yep, all of which speaks to some serious shortcomings of the
> HMAC-based protocol.
The scope of Babel-HMAC is deliberately limited. Babel-HMAC aims to
implement the strict minimum of features that make it useful.
Any deployment that needs features beyond what Babel-HMAC provides should
use
>> Yeah, we should just include an implementation of SHA-256 in the code.
> There's also the option...
Given that the main selling point of HMAC vs. DTLS is that it has no
dependencies, it wouldn't be particularly wise to make the reference
implementation depend on a Linux-specific library.
Of
>> do loop-free routing.
> Hah. :)
> I note that babel doesn't actually do that, any more.
Pick a pair (p, id), where p is a prefix and id is a router id. Consider
the graph defined by all route table entries indexed by (p, id). Then
Babel guarantees that at any time this graph is acyclic.
> +rc = setsockopt(s, SOL_SOCKET, SO_MAX_PACING_RATE, , sizeof(rate));
It's only effective on TCP sockets, and only when using the FQ scheduler.
-- Juliusz
___
Babel-users mailing list
Babel-users@alioth-lists.debian.net
> In looking over the bird patch, it looks like I merged the wrong
> thing.
Yes, it looks like it. hmac-challenge is the right code.
Weronika, perhaps you could rename the branch hmac to something less
exciting?
Dave, please be aware that the HMAC code is not quite finished yet. Once
we got a
> Or an user error. In either case, I don't get what a 32-bit _x86_ virtual
> machine would be good for. Are you teaching some code archeology?
Not at all.
We're trying to make it compulsory for first year students to have a Unix
installation on their personal machine. In practice, this means
> Filing a bug on src:virtualbox with severity 'wishlist' or 'normal' for this
> issue to discuss it with the maintainer of the virtualbox package(s) seems a
> logical thing to do.
Unfortunately, we're speaking about running Debian under VirtualBox under
Windows, so it would need to be something
> Received prefix with no router id.
> Couldn't parse packet (8, 12) from fe80::230:18ff:fec9:de9c on eno1.
Dave, this is concerning, as it indicates that either BIRD or babeld is
violating the spec. I'll try to reproduce it, but if you manage to
capture the paket that's causing this message,
Hi,
I've just merged a bunch of stuff into master:
- branches xroute-nlogn and rfc6126bis are now obsolete;
- please track master instead.
This means that master now implements the new revision of the protocol,
temporarily known as RFC 6126bis. Please see
Dear all,
Babeld-1.8.4 is available from
https://www.irif.fr/~jch/software/files/babeld-1.8.4.tar.gz
https://www.irif.fr/~jch/software/files/babeld-1.8.4.tar.gz.asc
This is hopefully the last release in the babeld-1.8 branch, and the last
release to implement the old source-specific
> I'm somewhat dismayed by the firm recommendation to use the HMAC
> mechanism,
Yeah, this could probably be loosened somewhat.
> which doesn't seem particularly robust.
It's designed to be fairly robust. Of course, we may have done things
wrong.
> Offhand, it seems like replays are possible
> Markus, I tried to be really clear about what I was communicating on the
> slide about implementations, but probably failed.
Indeed.
A number of your comments about Markus' code were entirely unnecessary.
-- Juliusz
___
homenet mailing list
> Anyway, getting back to topic of Ted's passionate speech about bad HNCP
> implementations, I'd love to see him (or someone else) provide better one :-)
Ted is busy working on his implementation of Simple Naming. Please leave
him in peace, it's important that he convince us that Simple Naming
>> I've been encouraging my students to install Debian on their personal
>> machines, and we've found out that a lot of them get the wrong Debian
>> installer:
>>
>> - some of them attempt to install an AMD64 version of Debian in
>> a 32-bit-only virtual machine;
> Why are they creating 32-bit
>> Except it's completely wrong ;-)
> yes, I just tried it. :(
Fixed. (Hopefully, I really need to take a couple of days off.)
-- Juliusz
___
Babel-users mailing list
Babel-users@alioth-lists.debian.net
> Oh, thank you! I stared at this bit of code for hours, trying
> different things, printfing, stepping through a debugger... trying to
> figure out where infinity was missed.
Except it's completely wrong ;-)
Careful, I'm going to rebase the branch.
-- Juliusz
> When discussing virtual machines it would be helpful to mention which virtual
> machine hypervisor is being used, because the resulting behavior can differ
> depending on hypervisor.
It was VirtualBox under Windows. The underlying issue was that VT-x was
disabled in the BIOS, and hence
>> I've been encouraging my students to install Debian on their personal
>> machines, and we've found out that a lot of them get the wrong Debian
>> installer:
>>
>> - some of them attempt to install an AMD64 version of Debian in
>> a 32-bit-only virtual machine;
> Why are they creating 32-bit
> This is not what I get.
> - 32bit debian on 64bit machine: this should be working fine
> - 64bit debian on 32bit machine: I get the attached message
> If it's not what they get, there is some bug and more investigation is
> needed.
I no longer have access to their machines, so I'm
Thanks for all the patches, Dave.
> the nlogn branch has a bug in that redistribute local deny does not work.
This should be fixed now.
-- Juliusz
___
Babel-users mailing list
Babel-users@alioth-lists.debian.net
>> From a user perspective, there are a few problems:
> When an interface goes down and then up again, it's renumbered. This
> includes reboots.
That shouldn't happen as long as there remains at least one Homenet router
to maintain the prefix (see Section 4.1 point 3 of RFC 7695).
I believe
Dear all,
This is to remind you that the Babel working group will be meeting
tomorrow at
15:40 Bangkok (UTC+7)
9:40 Paris (UTC+1)
3:30 New York, NY
0:30 San Luis Obispo, CA
Remote participation is free and warmly welcome. Please see
https://www.ietf.org/how/meetings/103/remote/
Dear Volodymyr,
> default via 192.168.2.1 dev eth0.2 proto static
If you look at /etc/iproute2/rt_protos, you will see that "proto static"
is a protocol number of 4. Now your redistribution rule says:
option 'proto' '3'
This says that only routes with "proto boot" are redistributed. The
> #0 0x0040c1d4 in start_message (buf=buf@entry=0x171e5b8,
> type=type@entry=10, len=len@entry=22) at message.c:957
> #1 0x0040c568 in send_multihop_request (buf=0x171e5b8,
> prefix=0x1cf66b8 "\374c\311/S\266)j", plen=,
> src_prefix=0x1cf66c9 "", src_plen=, seqno=,
>
> It doesn't show up in my version of wireshark, but does in tcpdump.
> sorry for the noise
It's a useful report, it indicates that Wireshark doesn't correctly
indicate unknown sub-TLVs. Needs fixed.
___
Babel-users mailing list
>> there are no timestamps in the multicast hello according to wireshark.
> I may have broken something. I'll have a look.
Works for me (TM).
22:41:33.171052 IP6 (class 0xc0, flowlabel 0x27d4c, hlim 1, next-header UDP
(17) payload length: 52) fe80::8aa8:f6d:d885:2851.6696 >
> is there an updated tcpdump or wireshark for the newer subtlvs?
Not yet. It's an easy hack, unless somebody beats me to it, I may offer
it as a first- or second-year project next spring.
> there are no timestamps in the multicast hello according to wireshark.
I may have broken something.
> ah, ok, so the nlogn branch I've been running was derived from the
> unicast branch? which in turn was derived from the rfc-bis branch? and
> I've been running that all along?
The other way around (unicast branched into rfc6126bis which branched into
xroute-nlogn), but yes.
> So all that's
> One of my issues with crypto, rather than auth, is I'd wanted a way to
> have a partially untrusted network to bootstrap off of and/or to allow at
> least some unauthed or uncrypted nodes to participate with filters or inflated
> metrics.
The important thing to understand is that both security
> since, what the heck, I have 7 different versions of babel in the lab,
> I figured why not add in the unicast branch on two boxes and see what
> else breaks.
The unicast branch is obsolete -- the rfc6126bis branch is based of it.
So if you're running rfc6126bis (or nlogn), you're already
> * I hit the nlogn branch with the same stuff... it's cpu barely ticks
> over, thousands of routes get distributed... it gets knocked off the
> network... and all end up unreachable, after everybody else runs out of
> some resource or another
Dave, I'm planning to merge nlogn into master, so
e?
Thanks,
-- Juliusz Chroboczek
>> for i:=c.Iterator();i.HasNext(); {
>> v := i.Next()
>> }
> I don't like the eyeball friction.
Could you please explain what you mean?
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving
Dave,
If you look at the branch xroute-nlogn, there's some code to update
xroutes in n logn time. It's almost completely untested.
If you've got time, I'd be grateful if you could have a look.
___
Babel-users mailing list
> Being a meshy protocol, though, if something escapes, usually over
> a "backup" link, suddenly a whole bunch more specific routes end up
> going through that backup link and life goes to hell quickly.
Yeah, that's a common user interface issue.
Now that we have mandatory bits, though, this
> Also it would be really helpful if that remaining PR (prefsrc) could be
> considered.
Christof, are you willing to send me a clean patch against the rfc6126bis
branch, or shall I do the merge myself?
-- Juliusz
___
Babel-users mailing list
301 - 400 of 3648 matches
Mail list logo
