Retiring src/sys/netiso and associated code

[Joerg Sonnenberger]

Hi all,
a while ago the OSI options were removed from most default kernel
configurations due to questionable security state of the code and
general lack of testing. I don't think the situation has improved in any
noticable way. It adds complexity for the routing code, which I want to
work on. Not breaking it requires testing, which doesn't seem to happen.
So who is actively using the OSI network stack with NetBSD and is in a
position to test changes? Alternatively, I would like to finally let it
rest in peace.

Joerg

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Mindaugas Rasiukevicius]

Post by Joerg Sonnenberger
Hi all,
a while ago the OSI options were removed from most default kernel
configurations due to questionable security state of the code and
general lack of testing. I don't think the situation has improved in any
noticable way. It adds complexity for the routing code, which I want to
work on. Not breaking it requires testing, which doesn't seem to happen.
So who is actively using the OSI network stack with NetBSD and is in a
position to test changes? Alternatively, I would like to finally let it
rest in peace.

Yes, please! It will help the network stack modernisation efforts.

[Christos Zoulas]

Post by Joerg Sonnenberger
Hi all,
a while ago the OSI options were removed from most default kernel
configurations due to questionable security state of the code and
general lack of testing. I don't think the situation has improved in any
noticable way. It adds complexity for the routing code, which I want to
work on. Not breaking it requires testing, which doesn't seem to happen.
So who is actively using the OSI network stack with NetBSD and is in a
position to test changes? Alternatively, I would like to finally let it
rest in peace.

Get rid of it; if someone wants it back they will need to revive it.

christos


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[John Nemeth]

On Jun 20, 4:53pm, Joerg Sonnenberger wrote:
}
} a while ago the OSI options were removed from most default kernel
} configurations due to questionable security state of the code and
} general lack of testing. I don't think the situation has improved in any
} noticable way. It adds complexity for the routing code, which I want to
} work on. Not breaking it requires testing, which doesn't seem to happen.
} So who is actively using the OSI network stack with NetBSD and is in a
} position to test changes? Alternatively, I would like to finally let it
} rest in peace.

Isn't it needed to support the IS-IS routing protocol? Of course,
I have no idea how many sites still use it, or use it with NetBSD.

}-- End of excerpt from Joerg Sonnenberger

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Joerg Sonnenberger]

Post by John Nemeth
}
} a while ago the OSI options were removed from most default kernel
} configurations due to questionable security state of the code and
} general lack of testing. I don't think the situation has improved in any
} noticable way. It adds complexity for the routing code, which I want to
} work on. Not breaking it requires testing, which doesn't seem to happen.
} So who is actively using the OSI network stack with NetBSD and is in a
} position to test changes? Alternatively, I would like to finally let it
} rest in peace.
Isn't it needed to support the IS-IS routing protocol?

Quagga contains at least parts of a userland-only implementation of the
OSI protocol parts needed. As such, any work related to IS-IS should be
focussing on that, I believe.

Joerg

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Ignatios Souvatzis]

Post by Joerg Sonnenberger

Post by John Nemeth
}
} a while ago the OSI options were removed from most default kernel
} configurations due to questionable security state of the code and
} general lack of testing. I don't think the situation has improved in any
} noticable way. It adds complexity for the routing code, which I want to
} work on. Not breaking it requires testing, which doesn't seem to happen.
} So who is actively using the OSI network stack with NetBSD and is in a
} position to test changes? Alternatively, I would like to finally let it
} rest in peace.
Isn't it needed to support the IS-IS routing protocol?

gated uses the NETISO-provided sockets for IS-IS, as far as I know.
I don't know if it survives in the wild. Chris?

Post by Joerg Sonnenberger
Quagga contains at least parts of a userland-only implementation of the
OSI protocol parts needed. As such, any work related to IS-IS should be
focussing on that, I believe.

Most important real-world use of NETISO parts would certainly be IS-IS.
If we can provide that via Quagga userland-only, thats good.

That written:

I don't see how NETISO adds complexity to the routing code. We will
have at least two protocols for a long time anyway; three for a
while (there are people who use network printers over Appletalk,
and not only me).

Actually, I'd consider IPv4 non-contiguous netmask routing more alien
to IPv6 hierarchical routing than OSI. I know we discussed it years ago,
but did we actually decide to get rid of IPv4 hierarchical netmasks yet?

What OSI certainly adds, is *line count*. And some of it, unnecessarily;
e.g. nowadays we'd implement some of the tunneling options as a
few lines of GIF interface.

I have published testing code which should be enough for the datagram
socket and routing case:

ftp://ftp.netbsd.org/pub/NetBSD/misc/is/isotest/

What I never tried is to set up a lab where NetBSD routes DECnet-phase-V
(-OSI) machines. Should be easy with emulators nowadays.

There's been a report about problems with the packetstream (TP4)
code, which seems to hint at real-world uses.

-is

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de