[DNA] Comments on draft-daley-dna-det-fastra-00.txt

[Jari Arkko <jari.arkko@kolumbus.fi>]

I have read the draft draft-daley-dna-det-fastra-00.txt and
have the following comments and questions:

Overall:

I think the protocol is valid, and necessary. I wish
it could be simpler, but it was not immediately obvious
to me how it could be simplified :-)

Technical:

> 11.4  Presence of Incompatible Fast Routers
> 
>    When routers wishing to undertake FastRA exist on the link but are
>    not trusted for inclusion in the Fast Routers List, two distinct sets
>    of routers may appear.
> 
>    Each set may not trust another, and may instead have its own router
>    at each Rank.  In this case, the IncompatibleFastRouters flag SHOULD
>    be set on the interface until the untrusted routers become trusted,
>    or cease being Fast Routers.

Can you talk more about the details regarding incompatible
fast routers? When would another router be incompatible?
Perhaps you are thinking of that if it doesn't have a SEND
certificate to a suitable trust anchor, then its not
compatible? But if there are incompatible sets, won't their
FastRAs collide?

> 12.4  Host Reception of DetFRAOs

Is it really necessary have this as a part of the protocol?
It complicates the protocol, and I'm not sure I see the
reason why hosts should know what the rank and other parameters
of the routers are. The host might have a need to know how
fast it should get the first/last RA on this link -- but this could
be told to the host without exposing it to the ranks and other
details of the router-to-router functionality.

> When using SEND,

Can you clarify whether the use of SEND is mandatory or
optional in the context of your protocol? I think it should
be optional, but your text is not clear on this point.

>    routers MUST check that the
>    router from which they receive a DetFRAO is an authorized router from
>    that link, and that the router trusts the delegation service used to
>    sign this authorization [5].

I think we need more detail on how this check is to be
performed. I think it should be enough that the other
router has the same trusted anchor as you do, but perhaps
are want a more specific check that the router is also
a router for this link. How would you check that?

Editorial:

o Section 2: I would suggest a newline between the term and
   its explanation, use <vspace blankLines='1' /> in XML2RFC.

>       Deterministic Fast Router Advertisement
>                      The configuration status for FastRA, as defined in
> 
>    Section 4.2
>     of this document.

Extra newlines.

--Jari