Re: [dna] next steps on draft-ietf-dna-simple

[Suresh Krishnan <[e-mail]>]

Hi Jari,
   Thank you for setting a good way forward with this document and sorry 
for the delayed response. Please see my responses inline.

On 09-11-20 03:39 AM, Jari Arkko wrote:
> The IESG reviewed this draft in our meeting yesterday. A number of 
> issues were brought up, most of it already resolved but some still 
> remain. Here are the changes that I've entered as RFC Editor notes:
> 
> 1) Updates 4861 issue per Brian Carpenter's review comments:
> 
>   Please remove the "Updates 4861" claim from the header.

OK. Since a new rev is needed anyway, I will update the draft itself so 
that the RFC Ed note is not required.

> 
> 2) Unclear specification with respect to what the draft requires about 
> fast RAs. I believe the current wording referred to draft-ietf-dna-frd. 
> Some readers thought our specification was requiring a change from the 
> 4861 rules that dictate a delay before the RS can go out.
> 
>   Please remove the following text from Section 2.4:
> 
>   As a result, in addition to implementing simple DNA, it is desirable
>   that routers adopt procedures which allow for fast unicast Router
>   Advertisement (RA) messages.

Will do.

> 
> 3) An additional security consideration issue was brought in secdir review.
> 
>   Please add the following text to the end of the security
>   considerations section:
> 
>   The DNA procedure does not in itself provide positive, secure 
>   authentication of the router(s) on the network, or authentication of
>   the network itself, as e.g. would be provided by mutual authentication
>   at the link layer. Therefore when such assurance is not available, the
>   host MUST NOT make any security-sensitive decisions based on the DNA
>   procedure. In particular, it MUST NOT decide it has rejoined a network
>   known to be physically secure, and proceed to abandon cryptographic
>   protection.

Will add this text.

> 
> 4) Lars Eggert was happy that the draft included retransmission rules, 
> but noted that the draft should also set an upper limit on how many 
> previous routers are probed.
> 
>   Please add the following text to end of Section 4.4:
> 
>   A Simple DNA implementation SHOULD limit probing to at most
>   six previously seen routers.
> 
> Everyone happy with these changes? Also, we have a few remaining issues:

Will do.

> 
> 5) Lars asked whether some of the SHOULDs in the document should really 
> be MUSTs. In my review this is not universally true at least. For 
> instance, you may give some freedom for implementations to avoid sending 
> probes if there are too many link up events in a short time period. 
> However, we'd like you Suresh go through the document and for each 
> SHOULD think about what the right keyword is. Sometimes it might be a 
> MUST, sometimes a SHOULD. In some of the cases where its a SHOULD, it 
> might be good to include a sentence or two about what issues might be 
> considered when implementing it.

I have identified a bunch of SHOULDs that need to be changed to MUSTs. I 
will try to add explanatory text to the other SHOULDs.

> 
> 6) We need to respond to Ralph Droms' detailed review. (Thank you 
> Ralph!) I think we can forget the Updates 4861 part of his discuss, but 
> the rest is relevant. I'm including his Discuss here for completeness sake:

I will go over the document and change/remove any text that insinuates 
that simple dna changes either DHCPv6 or RFC4861 procedures in any way. 
That should resolve most of the concerns Ralph has raised in this review.

Thanks
Suresh