Subject: [NSIS] Re: NATFW: some minor, non-technical issues

From: Martin Stiemerling <[email-masked]>
Date: Wed, 4 Oct 2006 22:04:53 +0200

Hi Matthias,

Thanks for the nits. More inline.

   Martin

Am 29.08.2006 um 10:45 schrieb Matthias Friedrich:

> Hi,
>
> I'd like to post my list of collected nitpicks (mostly spelling)  
> before
> I lose the file once again. The section numbers have been updated to
> draft version -12.
>
>   * Section 3.2.3., first paragraph
>     "consists" seems to be superfluous here

Fixed.

>
>   * Section 3.7.5., item "NSLP responder"
>     "The _NF_ should never receive NOTIFY messages ..." -> should  
> be NR

Fixed.

>
>   * Section 3.7.6., second paragraph
>     "The processing when receiving a TRACE message is _the_ different
>      for ..."

Fixed.

>
>   * Section 3.7.7., last paragraph
>     "... by setting the P flag in the NSLP header _is set_ to P=1 ..."

Fixed.

>
>   * Section 3.7.7.1., first paragraph
>     "In this case, _a_ NR can signal ..." -> an

Fixed.

>
>   * Section 3.7.7.1., second paragraph
>     "The absence of _an_ NONCE object ..." -> a

Fixed.

>
>   * Section 3.7.7.2., last paragraph
>     "Any device beyond this point will never _received_ ..." ->  
> receive

Fixed.

>
>   * Section 5.1.1., first paragraph
>     "_An_ addition to authentication the nodes will ..." -> In  
> addition?

The sentence was totally broken. It reads now:
The nodes will have to authorize each other, additionally to the  
authentication.

>
>   * Section 5.1.2., first paragraph
>     "In such a scenario, _a_ the previously discussed ..."

Fixed.

>
>   * Section 5.1.3., first paragraph
>     "In many cases the signaling message initiator might already aware
>     of ... " -> already _be_ aware

Fixed.

>
>   * Section 5.2.4., first sentence
>     I don't get it. Also, what does the "(*)" mean?

Well, basically a good catch. :-)
It now reads:
When a data receiver DR behind a NAT sends a RESERVE-EXTERNAL-ADDRESS  
(REA)
message to get a public reachable address, this address can be used as a
contact address by an arbitrary data sender, if the DR was unable to
restrict the future data sender.

The (*) means wildcard or not specified. I have added some  
description for
this.

>
>   * Section 5.2.4., third paragraph
>     "The data _sender_ might want to update the NAT binding ..."
>     Shouldn't this be the receiver?

Yes, should be receiver. Fixed.

>
>   * Section 5.2.4., last paragraph
>     "The DR MUST be able to specify which data _sender_ are allowed
>     to traverse the NAT in order to be forwarded to _DRs_ address."
>     -> plural, DR's

Fixed to:

The DR MUST be able to specify which data sender is allowed to traverse
the NAT in order to be forwarded to DR's address.

>
>   * Section 5.2.5., third paragraph
>     "By injecting a bogus _responses_ or NOTIFY message, for instance,
>     _timeout_, a malicious host could try to teardown NATFW NSLP  
> session
>     state as well."
>     -> "responses"? And what is meant by "timeout" here?

Responses refers to responses to CREATE/REA. The timeout is the session
timeout. Fixed.

>
>   * Section 5.3.1.3., last paragraph
>     "A NATFW NSLP node MUST be configurable to block unauthorized
>     signaling _message_." -> plural

Fixed.

>
>   * Section 5.4., last paragraph
>     There is no "firewall FW" in figure 42.

Removed the sentences, i.e., it was a left-over from an old version.

>
>   * Section 5.11.1., first paragraph
>     I'd remove the "provide" after the colon.

Removed and fixed.

>
>   * Section 5.11.1., last paragraph
>     "Hencem"

Fixed.

Thanks for all the fixes!

   Martin

_______________________________________________
nsis mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nsis