Subject: DT's review of draft-ietf-send-cga-00.txt, part 2

From: "Dave Thaler" <[email-masked]>
Date: Thu, 19 Jun 2003 15:53:29 -0700

Typos and grammatical errors (see separate email for technical issues):

Section 1:
>  computing a cryptographic hash of the public key. This kind of IPv6 
>  addresses are called cryptographically generated addresses (CGA). 
             ^^^
Should be "is" since the subject is singular ("kind").

>  limit of the interface identifier, and the implications CGA 
>  addresses on privacy.                                  ^

Insert "of".

Section 2:
>  The above definition can be stated in terms of the following two 
>  bit masks:                                                   ^^^

Should be "three".

Section 4:
>  RECOMMENDED to that the initial modifier value in step (1) is 
               ^^
Delete "to".

>  fast. Nodes that implement CGA generation MAY set the security 
>  parameter Sec to always 0. In that case, steps (2)-(3) of the 
                          ^
Insert "be".

Section 5:
>  specification may define situations where a it is acceptable for 
                                             ^
Delete "a".

Section 6.1:
>  sNodes that use the Secure Neighbor Discovery (SEND) protocol and 
   ^
Delete "s".

>  Note that the node MAY use trusted-root authorization mechanism 
                             ^
Insert "a".

>  instead or in addition to the CGA authorization mechanism 
          ^
Insert "of".

>         SendKeyInformation ::= SEQUENCE { 
>           cgaParameters  CGAParameters OPTIONAL, 
>           signerInfo     SubjectPublicKeyInfo OPTIONAL } 

Would be better to delete this and just refer to [AKSZ03] for
the definition of SendKeyInformation so you don't have to rev this
spec if it changes.

Section 6.2:
>  verification of the CGA property, the receiver must verify the MUST 
                                                  ^^^^^^^^^^^^^^^
>  verify the source address of the packet as described in Section 5. 

Delete duplicate "must verify the".

Section 7.1:
>  It is important to understand that that attacker can create a new 
                                      ^^^^
Should be "an".

Section 7.2:
>  The effectiveness of the hash extension depends of the assumption 
                                                   ^^
Should be "on".

>  generator will grow and the same (potentially exponential) rate. 
                       ^^^
Should be "at".

>  problem. (If CGA address were used as a part of a strong 
                    ^^^^^^^
Should be "addresses".

Section 7.3:
>  its appearances of the local link. As long as the node keeps using 
       ^^^^^^^^^^^^^^
I don't know how to interpret this.  Please reword. 
"appearances on" is better, but it's still unclear what "appearances"
means.

-Dave

--------------------------------------------------------------------
To unsubscribe from this list, send email with "UNSUBSCRIBE" in the
body to <[email-masked]>.
Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html
--------------------------------------------------------------------