Mention the exact day of the SCALE 14x talk.

[wiki] / goals.mdwn

diff --git a/goals.mdwn b/goals.mdwn
index 8a0eebb..57bffec 100644 (file)
--- a/goals.mdwn
+++ b/goals.mdwn
@@ -65,7 +65,7 @@ The 1.1 branch of tinc has been created as a stepping stone towards
 2.0. Only gradual changes to the source code are allowed, ensuring
 that the code is always in a mostly usable state. The protocol will
 stay compatible with that of the 1.0 branch. The following features
 2.0. Only gradual changes to the source code are allowed, ensuring
 that the code is always in a mostly usable state. The protocol will
 stay compatible with that of the 1.0 branch. The following features

-are planned in this branch:
+are planned or are already implemented in this branch:

 
 **Replaceble cryptography backend**
 
 
 **Replaceble cryptography backend**
 


@@ -93,16 +93,6 @@ in the tinc.conf files. It is desirable to have tinc manage the
 creation of control connections as well, so that the administrator
 does not have to do this manually anymore.
 
 creation of control connections as well, so that the administrator
 does not have to do this manually anymore.
 

-**Deal with NAT**
-
-The 1.0 branch by default tries to exchange packets via UDP.
-However, if one or more peers are behind a NAT, and source ports
-might be changed or packets may not arrive at all, the
-administrator had to manually enable the TCPOnly option or use
-another workaround to get tinc to work. Tinc should be able to cope
-with altered source ports, and should detect whether or not packet
-exchange via UDP works at all, and if not fall back to TCP.
-

 **Automate setting up nodes**
 
 The tincctl utility should have a wizard-like interface that asks a few
 **Automate setting up nodes**
 
 The tincctl utility should have a wizard-like interface that asks a few


@@ -146,14 +136,14 @@ PGP, where peers can sign each other, and if there are enough
 signatures, they can allow communication. Trust management should
 be simple, for example using a command like
 
 signatures, they can allow communication. Trust management should
 be simple, for example using a command like
 

-    tinc trust *foo*
+    tinc trust foo

 
 which should let the local tinc
 daemon trust information from the peer named *foo*. To authorise
 the use of addresses on the VPN, a command like the following could
 be used:
 
 
 which should let the local tinc
 daemon trust information from the peer named *foo*. To authorise
 the use of addresses on the VPN, a command like the following could
 be used:
 

-    tinc allow *bar* 192.168.3.0/24
+    tinc allow bar 192.168.3.0/24

 
 This should generate a small certificate that proves that the node that
 issued this command trusts node *bar* with the 192.168.3.0/24 range
 
 This should generate a small certificate that proves that the node that
 issued this command trusts node *bar* with the 192.168.3.0/24 range


@@ -162,11 +152,11 @@ tinc daemon's configuration, but also spread immediately amongst
 the other peers in the VPN. It is also important to allow trust and
 authorisation to be revoked in the same way:
 
 the other peers in the VPN. It is also important to allow trust and
 authorisation to be revoked in the same way:
 

-    tinc distrust *foo*
+    tinc distrust foo

 
 This should make the local tinc daemon stop trusting any information from *foo*.
 
 
 This should make the local tinc daemon stop trusting any information from *foo*.
 

-    tinc deny *bar*
+    tinc deny bar

 
 This should generate a certificate (with a newer timestamp than the previous one) denying
 *bar* any access, and spread this amongst the other peers as well.
 
 This should generate a certificate (with a newer timestamp than the previous one) denying
 *bar* any access, and spread this amongst the other peers as well.