Re: [Dots] WGLC for draft-ietf-dots-rfc8782-bis-01

[[e-mail]]

Hi Yasuaki, 

Thank you for clarifying. 

> I can explain the use case but I am not sure it is meaningful.
> Let a client send a PUT mitigation request to the server, and
> another client program send a GET request to obtain that mitigation
> request.
> In this case, the latter client might get more information if the
> GET response includes attack-status.

(Putting aside how the information will be used by the second client: anomaly detect among clients of the same domain(?))

This assumes that the server maintains two mitigation requests with conflicting scopes and which are issued by distinct clients of the same domain. This is not allowed in the current spec. When such mitigations are received, is likely to maintain only one of them active. 

So even if the constraint is relaxed to echo "attack-status" by a server, only the client that communicated the parameter can access it ... but I don't see why we need to do that.  

Cheers,
Med

> -----Message d'origine-----
> De : Yasuaki Morita [mailto:[e-mail]]
> Envoyé : mardi 6 octobre 2020 16:58
> À : BOUCADAIR Mohamed TGI/OLN <[e-mail]>
> Cc : Valery Smyslov <[e-mail]>; [e-mail]; dots-
> [e-mail]; [e-mail]
> Objet : Re: [Dots] WGLC for draft-ietf-dots-rfc8782-bis-01
> 
> Hi Med
> 
> Thank you for your reply.
> 
> > [Med] It is mandatory in a request and an accepted mitigation
> response, but not in a conflict response for instance.
> > The structure applies of the mitigation independently whether this
> a request, response, conflict, efficacy update, etc.
> 
> I see, I understand.
> 
> > [Med] "attack-status" is an attribute that is sent by a client to
> share its view on the attack with the server. The server manipulates
> "status" to report the status as seen at the server side.
> > The server does not include the "attack-status" (received from the
> client) in a GET.
> >
> > > There is no reason to restrict the server sending attack-status
> to
> > > the clients.
> 
> Perhaps this is something I didn't understand correctly about the
> use of "attack-status" in RFC8782 (not bis), which defines "attack-
> status"
> as the following.
> 
>            |     +--rw attack-status?          iana-signal:attack-
> status
> 
> >
> > [Med] What would be the use case if that constraint was relaxed?
> 
> I can explain the use case but I am not sure it is meaningful.
> Let a client send a PUT mitigation request to the server, and
> another client program send a GET request to obtain that mitigation
> request.
> In this case, the latter client might get more information if the
> GET response includes attack-status.
> 


_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.