[netconf] Re: WGLC for restconf-trace-ctx-headers-01

[[e-mail]]

Hi Jan,

Thanks for the follow-up.

Please see inline.

Cheers,
Med



Orange Restricted

De : Jan Lindblad (jlindbla) <[e-mail]>
Envoyé : mercredi 25 septembre 2024 14:44
À : BOUCADAIR Mohamed INNOV/NET <[e-mail]>; Per Andersson <[e-mail]>; [e-mail]
Objet : Re: [netconf] Re: WGLC for restconf-trace-ctx-headers-01

Thank you Med for your detailed review!

We have prepared an updated -02 version of the document.
https://datatracker.ietf.org/doc/draft-ietf-netconf-restconf-trace-ctx-headers/02/

Your review comments contain several dozens of detailed wording changes, so we will not repeat or respond to each one here. Most have been accepted as is, thank you 😊 , while some have been merged with wording changes from other sources.
[Med] Thanks.

You also raise a few higher level questions, and let us go through them here. My comments as [janl].

A RESTCONF server SHOULD follow the "Processing Model for Working with Trace Context" as specified in {{W3C-Trace-Context}}.

Can we call exception case where this SHOULD can be safely ignored?

[janl] We have attempted to follow the W3C language and intentions as closely as possible, so I’m not sure it’s a good idea for us to second guess or elaborate on W3Cs ideas for why this is a SHOULD and not a MUST.

[Med] I hear you. As indicated in my review, I was more concerned that W3C section says explicitly that “This section is non-normative”, while this part is the key normative part of the restconf-trace spec.

Isn’t this deployment-specific/policy-based?

[janl] Yes, I would think the exception cases would be deployment specific. Do we need to update our text somehow?
[Med] I would avoid the normative language for that part, then. Thanks.

If a server decides to reject an RPC because of the Trace Context header values, the server MUST return a RESTCONF rpc-error with the following values:

      error-tag:      operation-failed
      error-type:     protocol
      error-severity: error

Should we define an error code for cases where the response trace values do not match the ones in the request? Actually, shouldn’t that behavior be called out here?

[janl] I’m not sure I follow this suggestion. Do you mean that the server includes the request headers in its response, and have changed the values somehow? Who should issue this error, and report it to whom?
[Med] The case I was referring to is a check at the client side. You are right, there is no error to issue there, but may be a log or something similar at the client side?

The lowest RESTCONF layer is HTTPS, and the mandatory-to-implement secure transport is TLS [RFC8446].

Not sure I would maintain this.

[janl] What would you propose? This is a quote from RFC8040 (with updated TLS RFC number).
[Med] No need to repeat this as the spec inherits RFC8040 sec considerations. Adding a generic mention to sec cons of 8040 would be sufficient.


      Date: Thu, 26 Jan 2017 20:56:30 GMT

[date] to be updated.

[janl] The text above is from an existing example quoted from RFC8040, which this document adds some headers to, in order to exemplify their use. I would refrain from changing anything non-essential in it for easier comparison.
[Med] ACK.

Thank you for the detailed review!

Best Regards,
/jan


From: [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>
Date: Thursday, 19 September 2024 at 15:13
To: Per Andersson <[e-mail]<mailto:[e-mail]>>, [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>
Subject: [netconf] Re: WGLC for restconf-trace-ctx-headers-01
Hi all,

I support this spec, but I think the document requires some work/refinements.

FWIW, my review can be found here:

* pdf: https://github.com/boucadair/IETF-Drafts-Reviews/blob/master/2024/draft-ietf-netconf-restconf-trace-ctx-headers-01-rev%20Med.pdf
* doc: https://github.com/boucadair/IETF-Drafts-Reviews/raw/master/2024/draft-ietf-netconf-restconf-trace-ctx-headers-01-rev%20Med.doc

Authors, feel free to grab whatever you think useful in the review.

Cheers,
Med

> -----Message d'origine-----
> De : Per Andersson <[e-mail]<mailto:[e-mail]>>
> Envoyé : mercredi 18 septembre 2024 12:48
> À : [e-mail]<mailto:[e-mail]>
> Objet : [netconf] Re: WGLC for restconf-trace-ctx-headers-01
>
>
> Dear WG,
>
> The WGLC is extended for another two weeks.
>
> Please take the time to review this document.
>
>
> --
> Per
>
> _______________________________________________
> netconf mailing list -- [e-mail]<mailto:[e-mail]> To unsubscribe send an
> email to [e-mail]<mailto:[e-mail]>
____________________________________________________________________________________________________________
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.
_______________________________________________
netconf mailing list -- [e-mail]<mailto:[e-mail]>
To unsubscribe send an email to [e-mail]<mailto:[e-mail]>
Orange Restricted

____________________________________________________________________________________________________________
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.