mir/kea
2
0
Fork 0
mirror of https://gitlab.isc.org/isc-projects/kea synced 2025-09-03 23:45:27 +00:00
Code Issues Releases Wiki Activity

[3873] Fix typos

Browse Source
This commit is contained in:
Shawn Routhier
2015-07-01 23:15:50 -07:00
parent bc9e23fcf6
commit f374d3819c
1 changed files with 19 additions and 19 deletions
Download Patch File Download Diff File Expand all files Collapse all files

38
doc/guide/faq.xml
View File

@@ -23,7 +23,7 @@
<section id="q1-generic"> <section id="q1-generic">
<title>Where did the Kea name came from?</title> <title>Where did the Kea name came from?</title>
<para>Kea is a name of high mountain parrot living in New Zealand. <para>Kea is the name of a high mountain parrot living in New Zealand.
See this <ulink url="https://lists.isc.org/pipermail/kea-users/2014-October/000032.html" /> See this <ulink url="https://lists.isc.org/pipermail/kea-users/2014-October/000032.html" />
for an extended answer.</para> for an extended answer.</para>
@@ -34,7 +34,7 @@
<para>Kea is developed by a small team of engineers. Our resources are <para>Kea is developed by a small team of engineers. Our resources are
limited, so we need to prioritize requests. The complexity of a new limited, so we need to prioritize requests. The complexity of a new
feature (how difficult is it to implement a feature and how likely it feature (how difficult it is to implement a feature and how likely it
would break something that already works), amount of work required and would break something that already works), amount of work required and
expected popularity (i.e. how many users would actually benefit from it) expected popularity (i.e. how many users would actually benefit from it)
are three leading factors. We sometimes also have contractual obligations. are three leading factors. We sometimes also have contractual obligations.
@@ -44,43 +44,43 @@
implement features that are actively requested first, but the reality implement features that are actively requested first, but the reality
is that we have more requests than we can handle, so some of them must is that we have more requests than we can handle, so some of them must
be postponed, at least in the near future. So is your request likely to be postponed, at least in the near future. So is your request likely to
be reject? Not at all. You can do many things to greatly improve chances be rejected? Not at all. You can do many things to greatly improve the
of your request to be fulfilled. First, it helps to explain why you chances of your request being fulfilled. First, it helps to explain why you
need a feature. If your explanation is reasonable and there are likely need a feature. If your explanation is reasonable and there are likely
other users that would benefit from it, the chances for Kea developers other users that would benefit from it, the chances for Kea developers
to put this task on a roadmap is better. Saying that you are willing to put this task on a roadmap is better. Saying that you are willing
to participate in tests (e.g. test engineering drops when they become to participate in tests (e.g. test engineering drops when they become
available) is also helpful.</para> available) is also helpful.</para>
<para>Another thing you can do to greatly improve chances of a feature <para>Another thing you can do to greatly improve the chances of a feature
to appear is to actually develop it on your own and submit a patch. to appear is to actually develop it on your own and submit a patch.
That's a venue that people often forget about. Kea is an open source That's an avenue that people often forget about. Kea is open source
software and we do accept patches. There are certain requirements, like software and we do accept patches. There are certain requirements, like
code quality, comments, unit-tests, documentation, etc., but we have code quality, comments, unit-tests, documentation, etc., but we have
accepted a significant number of patches in the past, so it's doable. accepted a significant number of patches in the past, so it's doable.
Accepted contributions range from minor documentation corrections to Accepted contributions range from minor documentation corrections to
significant new features, like support for new database type. Before significant new features, like support for a new database type. Before
considering writing and submitting a patch, make sure you read considering writing and submitting a patch, make sure you read
Contributor's Guide in <ulink url="http://git.kea.isc.org/~tester/kea/doxygen/">Kea Developer's Guide</ulink>. the Contributor's Guide in <ulink url="http://git.kea.isc.org/~tester/kea/doxygen/">Kea Developer's Guide</ulink>.
</para> </para>
<para>Kea is developed by ISC, which is non-profit organization. <para>Kea is developed by ISC, which is a non-profit organization.
You may consider signing a development contract with us. In the past You may consider signing a development contract with us. In the past
we did implement certain features due to contractual obligations. we did implement certain features due to contractual obligations.
With additional funds we are able to put extra engineering efforts With additional funds we are able to put extra engineering efforts
into Kea development. We can reshuffle our schedule or add extra into Kea development. We can reshuffle our schedule or add extra
hands to the team if needed. Please keep in mind that Kea is an hands to the team if needed. Please keep in mind that Kea is
open source software and its principal goal is to provide good DHCP open source software and its principle goal is to provide a good DHCP
solution that can be used by everyone. In other words, we may solution that can be used by everyone. In other words, we may
refuse a contract that would tie the solution to specific proprietary refuse a contract that would tie the solution to specific proprietary
technology or make it unusable for other users. Also, we strive to technology or make it unusable for other users. Also, we strive to
make Kea a reference implementation, so if your proposal significantly make Kea a reference implementation, so if your proposal significantly
violates RFC, we may have a problem with that. Nevertheless, please violates a RFC, we may have a problem with that. Nevertheless, please
talk to us and we may be able to find a solution.</para> talk to us and we may be able to find a solution.</para>
<para>Finally, Kea has a <ulink url="http://kea.isc.org/roadmap">public <para>Finally, Kea has a <ulink url="http://kea.isc.org/roadmap">public
roadmap</ulink>, with releases happening several times each year. We tend roadmap</ulink>, with releases happening several times each year. We tend
to not modify features for current milestone, unless there are very good to not modify features for the current milestone, unless there are very good
reasons to do so. Therefore "I'd like a featury X in 6 months" is much reasons to do so. Therefore "I'd like a featury X in 6 months" is much
better received than "I'd like a feature X now".</para> better received than "I'd like a feature X now".</para>
</section> </section>
@@ -91,20 +91,20 @@
<title>Frequently Asked Questions about DHCPv4</title> <title>Frequently Asked Questions about DHCPv4</title>
<section iq="q1-dhcp4"> <section iq="q1-dhcp4">
<title>I set up a firewall, but Kea server still receives the traffic. Why?</title> <title>I set up a firewall, but the Kea server still receives the traffic. Why?</title>
<para>Any DHCPv4 server must be able to receive from and send traffic to the <para>Any DHCPv4 server must be able to receive from and send traffic to
hosts that don't have an IPv4 address assigned yet. That is typically not hosts that don't have an IPv4 address assigned yet. That is typically not
possible with regular UDP sockets, therefore Kea DHCPv4 server uses raw possible with regular UDP sockets, therefore the Kea DHCPv4 server uses raw
sockets by default. Raw sockets mean that the incoming packets are received sockets by default. Raw sockets mean that the incoming packets are received
as raw Ethernet frames, thus bypassing the whole kernel IP stack, including as raw Ethernet frames, thus bypassing the whole kernel IP stack, including
any firewalling rules your kernel may provide.</para> any firewalling rules your kernel may provide.</para>
<para>If you do not want the server to use raw sockets, it is possible to <para>If you do not want the server to use raw sockets, it is possible to
config Kea DHCPv4 server to use UDP sockets instead. See <command>dhcp-socket-type</command> configure the Kea DHCPv4 server to use UDP sockets instead. See <command>dhcp-socket-type</command>
described in <xref linkend="dhcp4-interface-configuration" />. However, described in <xref linkend="dhcp4-interface-configuration" />. However,
using UDP sockets have certain limitations. In particular, it may not allow using UDP sockets has certain limitations. In particular, they may not allow
to send responses directly to the clients without IPv4 addresses assigned. for sending responses directly to clients without IPv4 addresses assigned.
That's ok, if all your traffic is coming through relay agents.</para> That's ok, if all your traffic is coming through relay agents.</para>
</section> </section>