Hi,

At first sorry for the late reply and thanks for your review.

2008/12/18 Michaela Vanderveen <[email protected]>:
> Hi,
>
> I have reviewed this draft and have the following comments:
>
> Other reviewers think that the draft is reaching too far into the solution
> space, for a problem statement. I find the level of solution hints to be
> acceptable. In any case it seems that maybe it's a bit late for a WGLC?

BTW, that was something asked by people from the WG :)

>
> It would be nice if the text below Fig. 5 actually referred to nodes M and N
> and their locations, to illustrate the issues therein in a more  concrete
> fashion. Ditto goes for Fig. 6.

OK.

>
> Section 2.3: The last part of the sentence "but may be matched with Neighbor
> solicitation and advertisement services using the proxy's source
>    address in the same way as Mobile IPv6 [RFC4389] [RFC3775]"
> is not clear; more text about how Mobile IPv6 does matching of what to what.

All is normally described in section 2.1 but I can add a reference to
this section :)

>
> Section 4.3: Not sure why we worry about the case when a node leaves the
> link before it completes DAD, so it does not really have an address. Is this
> any more common than the case of mobiles moving so fast that they can't
> complete a handshake registration?

E.g., MIPv6 bootstrapping where the HA has to perform a DAD for the
HoA before to assign it.

>
> Section 8.3, first paragraph: why is accurate timekeeping required for
> certificates? Certificates should be longer-term, unlike binding messages,
> say, which need timestamps for anti-replay.

Yes and no :)
Depends whether a certificate based authorization of ND proxy is
short-term as a CGA or not ... I must admit this is unclear for me for
the moment :s

>
> Some editorials below:
>
> Abstract: First sentence needs rephrasing (at least replace "no" by "not")

OK. Thanks.

>
> Section 2.2.:  * "This is case" -> "This is the case"
>            * "this latest assigns it" -> "the latter assigns such an
>     address"
>            * "to be able to intercept messages, sent to the node, to tunnel
> them to this latest" -> "to be able to intercept and tunnel messages to the
> node".
>

OK. Thanks.

> Section 3: "These advertisements must therefore have enough authority to
> override Neighbor cache entries even though they are secured." ->
>            " These advertisements must therefore have enough authority to
> override secured Neighbor cache entries." (not clear which are secured, the
> advertisements or the cache entries).
>

OK. Thanks.

> Section 4.1: Reference to CGA is not [3971] but [3972].

OK. Thanks

>
> Section 4.2: "and infers support for CGA verification.
>    Clarification or changing of this issue for non-CGA operations may be
>    necessary." ->
>         "and allows for CGA verification.
>    Updating of the signature function to support non-CGA operations may be
> necessary." (or something along these lines)
>

OK. Thanks.

> Section 5.1.2. " This certificate would need to be passed near to binding
> time" - clarify: passed to whom, and what does "near" mean, shortly before
> or shortly after binding update time instance?
>

OK.

> Section 5.1.3: The sentence starting with "This is the case..." is too long
> and needs to be split into two for clarity (e.g. at the "but to check..")).
>

OK.

> Section 5.1.4: * "the HA no more needs to" -> "the HA no longer needs to"
>        * "this results to use a virtual" -> "this results in a virtual"
>

OK.

> Section 5.2.2:  * "Routers advertising on networks without routers" sounds
> strange. Rephrase?
>

OK (cf. previous reply to another review).

>  * "Any device can set up to be" -> "Any device can set out to be"
>

OK.

> Section 5.2.6: * "supercede" -> "supersede".
>          * "and may wish two network segments to appear to be
>    connected" -> " and may want to make two network segments appear to be
>    connected"
>

OK.

> Section 6: "defending a same"  -> "defending the same"
>            "a same PMIP " -> "the same PMIP"
>

OK. Thanks.

Best regards and happy new year.

JMC.

> Regards,
> Michaela
>
>
>
>
_______________________________________________
CGA-EXT mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/cga-ext

Reply via email to