Hi Francesca, Thanks for clearing your DISCUSS. For the YANG validation failure, it seems like the YANG validator for the submission is not updated yet and shows a false warning.
IESG MEMBERS, Here are updates for I2NSF YANG I-Ds for the IETF Trust Copyright Text and Language Tag. I attach the revision letter to explain how those I-Ds are updated. We authors believe that the three I2NSF I-Ds have resolved all the issues raised during the IESG evaluation. Please make the following three I-Ds move forward. - I2NSF Capability I-D https://datatracker.ietf.org/doc/html/draft-ietf-i2nsf-capability-data-model-30 - NSF-Facing Interface I-D https://datatracker.ietf.org/doc/html/draft-ietf-i2nsf-nsf-facing-interface-dm-25 - Monitoring Interface I-D https://datatracker.ietf.org/doc/html/draft-ietf-i2nsf-nsf-monitoring-data-model-17 Thanks for your support. Best Regards, Paul On Wed, Apr 13, 2022 at 9:03 PM Francesca Palombini via Datatracker < [email protected]> wrote: > Francesca Palombini has entered the following ballot position for > draft-ietf-i2nsf-nsf-monitoring-data-model-16: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to > https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ > for more information about how to handle DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > > https://datatracker.ietf.org/doc/draft-ietf-i2nsf-nsf-monitoring-data-model/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Thank you for the work on this document. > > Many thanks to Valery Smyslov for his review: > https://mailarchive.ietf.org/arch/msg/art/2XuRUuQaI8ZrVSyuWQn1SHi5dEY/, > and to > the authors for addressing his comments. > > Thank you for addressing my DISCUSS points. I have checked about the Web > Attack > Alarm and heard no objections on this use from the HTTPBIS wg: > https://mailarchive.ietf.org/arch/msg/httpbisa/H2bsyIoGo9JKNUlsCrrwA_rnp08/ > . > DISCUSS point kept for record below. > > Also please note that the YANG validation fails on the datatracker. > > Francesca > > ----- > > Section 6.3.4. > > FP: It is not clear to me why these specific header fields (and these > fields > only) are selected to be part of the information about Web Attack Alarm - > req-user-agent, cookies. I agree with Ben's DISCUSS point 1. (reported > below) > and would even add to that that more motivation around which header fields > are > included and why, would help. I'd also like to know if the HTTPBIS working > group has been involved in the discussion, and if not, if they could be to > give > their expert opinion. > > Ben's DISCUSS: > > (1) I'm not sure I understand the motivation for recommending (in ยง6.3.4) > that > the HTTP Cookie header field be included in a notification about a Web > Attack Event. In general, the cookie field can contain very sensitive > information, including credentials, and it is very risky to be sending the > cookies around outside of their primary protocol context. Perhaps, if we > are fully confident that the NSF has correctly identified an attack, it > might be useful to send the cookies around, but I think there are still > some > scenarios (e.g., a compromised end-user browser) where the cookies in an > attack request are still confidential information that should not be > disclosed. Could we say more about why it is recommended to always include > the cookies or weaken the recommendation? > > > > _______________________________________________ > I2nsf mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/i2nsf >
Revision-Letter-for-I2NSF-Documents-2022-04-13.pdf
Description: Adobe PDF document
_______________________________________________ I2nsf mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2nsf
