Issue 29: Editorial comments from Tero

[email protected] writes:
> The design document also uses the word "path" in senses that
> don't include the route taken by the packets (see e.g. the
> definition for "primary path").

Actually the "primary path" does not say weather the route of the
packet is included or not. The definition of "Path" do say that route
is included. 

> Also, some of the terminology in the design document needs a bit
> revision, since it implicitly assumes the SCTP-like "option 1"
> for issue 20, instead of the "initiator decides" we chose.

Better send updates then and say where it mentiones that we selected
option 1 so we can fix it. Note, that in multiple places it tries not
to say which option we have selected when describing the problem, and
only in the end of section mentions which of those options were
selected. Also decribing the other problems can still use more generic
text, even when we could use less generic one because of the some
options we selected in some other places.

This way if we decide to select some option, we do not need to modify
other parts of the document, as the generic text is still valid there.

> I've actually considered this, and checked that the ordering 
> is consistent with IKEv2 :-)  (According to IKEv2 Section 2.23, 
> NAT_DETECTION_*_IP in reply comes after Nr but before CERTREQ.)

True, I didn't remember it was explicitly mentioned in the text. Some
of the other optional ones are not mentioned.

> Yes, this was the idea: if we have sent the request to more than one
> address (==updated the destination address in the IKE_SA, at least
> currently), we need to send a new INFORMATIONAL request to check
> RR. I'll rephrase that paragraph to make it clearer...

Try to include also description of the attack, not only the solution,
as it do make the text more understandable to know why it is done that
way. 
-- 
[email protected]