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

[Jari Arkko <[e-mail]>]

Your plans sound good, Suresh. Thanks.

Jari

Suresh Krishnan wrote:
> 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
>
>