Re: [Dots] Genart last call review of draft-ietf-dots-data-channel-27

[<[e-mail]>]

Hi Roni, 

Thank you for the review. 

Please see inline.

Cheers,
Med

> -----Message d'origine-----
> De : Datatracker on behalf of Roni Even [mailto:[e-mail]]
> Envoyé : jeudi 7 mars 2019 11:21
> À : [e-mail]
> Cc : [e-mail]; [e-mail]; [e-mail]
> Objet : Genart last call review of draft-ietf-dots-data-channel-27
> 
> Reviewer: Roni Even
> Review result: Ready with Nits
> 
> I am the assigned Gen-ART reviewer for this draft. The General Area
> Review Team (Gen-ART) reviews all IETF documents being processed
> by the IESG for the IETF Chair.  Please treat these comments just
> like any other last call comments.
> 
> For more information, please see the FAQ at
> 
> <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.
> 
> Document: draft-ietf-dots-data-channel-??
> Reviewer: Roni Even
> Review Date: 2019-03-07
> IETF LC End Date: 2019-03-13
> IESG Telechat date: Not scheduled for a telechat
> 
> Summary:
> The document is ready with nits and one minor issue for publication as a
> standard track RFC
> 
> Major issues:
> 
> Minor issues:
> 
> 1. In section 2 there is a discussion about conflicting filtering requests. 

[Med] I guess you meant section 3.

I
> think that this can be considered as an attack and should be mentioned in the
> security section.

[Med] Conflicts may be caused by various "legitimate" actions. Of course, as discussed in the Security section, an attacker who access to a DOTS client can do a lot of things such as installing some filters including conflicting ones. This is already reported in the security section.


 I also think that such a conflict must be reported to the
> administrator even if rejected.

[Med] This is deployment-specific. For example, if conflict handling requires "notify an administrator for validation", there is no point to report again. 

> 
> Nits/editorial comments:
> 
> 1. In figure 2 missing HTTP layer?

[Med] No, that is on purpose. RESTCONF (which is an HTTP-based protocol) layer is sufficient.    

> 2. In section 6.1 "If the request is missing a mandatory attribute or its
> contains " should be "it" instead of "its" 3.

[Med] Thank you for catching this. Fixed.

 In section 7.3 "A DOTS client
> periodically queries  ...".  I did not see any text about why this is done is
> this a common behavior? how often? 4. 

[Med] This is left to implementations. We don't have any solid argument to recommend a value. 


After figure 29 "bound to a given ACL
> as
> shown in Figure 28 " I think it should be 27?

[Med] This should be Figure 30. Fixed. Thanks.

 5. In figure 31
> ""pending-lifetime": 8000 ," why 8000 and not 9080 as in figure 28?
> 

[Med] This is because pending-lifetime was decremented since the GET in Figure 28 was issued.