Hi Kent, 

The edits made to that para are meant to better align with the following core 
guidance: 

   o  Readable data nodes that contain especially sensitive information
                                       ^^^^^^^^^^^^^^^^^^^^
      or that raise significant privacy concerns MUST be explicitly
      listed by name, and the reasons for the sensitivity/privacy
      concerns MUST be explained.

That is, not cite every ro but those that are particularly sensitive. The edits 
also provide examples of what can be considered as particularly sensitive.

I think that part is an improvement.

Cheers,
Med

> -----Message d'origine-----
> De : Kent Watsen <[email protected]>
> Envoyé : jeudi 12 décembre 2024 19:19
> À : BOUCADAIR Mohamed INNOV/NET <[email protected]>
> Cc : [email protected]; Rob Wilton (rwilton) <[email protected]>
> Objet : Re: [netmod] I-D Action: draft-ietf-netmod-rfc8407bis-
> 21.txt
> 
> 
> Hi Med,
> 
> Sorry, my autocorrect hit my last message:
> 
>       OLD:  type “Euopean”
>       NEW:  typo "Euopean”
> 
> And indeed, that is the case, as the word is correctly spelled in
> 8407 and 6087.
> 
> Can we return the paragraph to its former self?
> 
> Kent
> 
> 
> > On Dec 12, 2024, at 12:35 PM, [email protected]
> wrote:
> >
> > Re-,
> >
> > For
> >> instance, the type "Euopean” didn’t exist before.  Can we
> return the
> >> paragraph to its former self?
> >
> > "Euopean" was in 8407 and 6087 as well. The edits in the bis do
> not touch that part. I'm providing excerpts, fwiw:
> >
> > 8407bis:
> >
> >   -- If the data model contains any particularly sensitive
> readable
> >   -- data nodes, e.g., ones that might be protected by a
> >   -- "nacm:default-deny-read" or a "nacm:default-deny-all"
> extensions
> >   -- statement, or if they may reveal sensitive customer
> information
> >   -- or violate personal privacy laws, such as those of the
> Euopean
> >   -- Union, if exposed to unauthorized parties, then those
> subtrees
> >   -- and data nodes must be listed here, along with an
> explanation of
> >   -- the associated sensitivity, security, or privacy concerns.
> >
> > RFC8407:
> >
> >    -- for all YANG modules you must evaluate whether any
> readable data
> >    -- nodes (those are all the "config false" nodes, but also
> all other
> >    -- nodes, because they can also be read via operations like
> get or
> >    -- get-config) are sensitive or vulnerable (for instance, if
> they
> >    -- might reveal customer information or violate personal
> privacy
> >    -- laws such as those of the European Union if exposed to
> >    -- unauthorized parties)
> >
> > RFC6087:
> >
> >   -- for all YANG modules you must evaluate whether any
> readable data
> >   -- nodes (those are all the "config false" nodes, but also
> all other
> >   -- nodes, because they can also be read via operations like
> get or
> >   -- get-config) are sensitive or vulnerable (for instance, if
> they
> >   -- might reveal customer information or violate personal
> privacy
> >   -- laws such as those of the European Union if exposed to
> >   -- unauthorized parties)
> >
> > Cheers,
> > Med
> >
> >> -----Message d'origine-----
> >> De : Kent Watsen <[email protected]> Envoyé : jeudi 12
> décembre
> >> 2024 18:24 À : BOUCADAIR Mohamed INNOV/NET
> >> <[email protected]> Cc : [email protected]; Rob
> Wilton
> >> (rwilton) <[email protected]> Objet : Re: [netmod] I-D Action:
> >> draft-ietf-netmod-rfc8407bis- 21.txt
> >>
> >>
> >> Hi Med,
> >>
> >> Thanks for tracking this.  That is an amazing amount of
> sleuthing!
> >> To be honest, I didn’t realize that the paragraph existing
> before.
> >> I’ll let Lou speak for himself, but I don’t mind keeping
> legacy text
> >> in place.
> >>
> >> That said, this text is not exactly the same as before.  The
> >> paragraph was changed by a PR that Rob Wilton pushed.  For
> instance,
> >> the type "Euopean” didn’t exist before.  Can we return the
> paragraph
> >> to its former self?
> >>
> >> Kent / chair
> >>
> >>
> >>
> >>> On Dec 12, 2024, at 9:02 AM, [email protected]
> >> wrote:
> >>>
> >>> Hi Kent, all,
> >>>
> >>> I went back and checked the archives. The text about laws and
> >> so on is there even longer that I thought: the text was even
> in
> >> RFC6087!
> >>>
> >>> That text was introduced in
> >>>
> >>
> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2
> >> Fdata
> >>> tracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-netmod-yang-usage-
> >> 10&data=0
> >>>
> >>
> 5%7C02%7Cmohamed.boucadair%40orange.com%7C99f13f492d2a464d2fc208d
> >> d1ad1
> >>>
> >>
> c372%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C638696210420580
> >> 653%7
> >>>
> >>
> CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMC
> >> IsIlA
> >>>
> >>
> iOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=
> >> qrUn4
> >>> 1Z31GbriiNtMbTIgbzbogxQshLYhX6Uon2ssBk%3D&reserved=0
> (08/2010)
> >>>
> >>> This was proposed by Bert Wijnen at
> >>
> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2
> >>
> Fmailarchive.ietf.org%2Farch%2Fmsg%2Fnetmod%2Fk7KYXbqti4vCWYMNzaW
> >>
> TukE80pM%2F&data=05%7C02%7Cmohamed.boucadair%40orange.com%7C99f13
> >>
> f492d2a464d2fc208dd1ad1c372%7C90c7a20af34b40bfbc48b9253b6f5d20%7C
> >>
> 0%7C0%7C638696210420596474%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcG
> >>
> kiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIld
> >>
> UIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=t98hp%2B3ozoyWUm9pAeYl6T%2FlHxCw
> >> TYh2%2BWR3geXD6H0%3D&reserved=0 (03/2010). The discussion
> seems also
> >> to happen in IETF#77
> >>
> (https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%
> >>
> 2Fwww.ietf.org%2Fproceedings%2F77%2Fminutes%2Fnetmod.txt&data=05%
> >>
> 7C02%7Cmohamed.boucadair%40orange.com%7C99f13f492d2a464d2fc208dd1
> >>
> ad1c372%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C638696210420
> >>
> 604276%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLj
> >>
> AuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C
> >>
> %7C%7C&sdata=ic%2BER2KWqYP6yRrvNvEA7WYFyXQ109VqxMImSw4Ip9A%3D&res
> >> erved=0). I failed to find objection in that thread of even
> after.
> >>>
> >>> As a lazy editor, my position is to leave this as it is as no
> >> one complained for 14 years.
> >>>
> >>> Please let me know if you still think we should change this.
> If
> >> so, please share OLD/NEW and I will implement it.
> >>>
> >>> Cheers,
> >>> Med
> >>>
> >>>> -----Message d'origine-----
> >>>> De : BOUCADAIR Mohamed INNOV/NET
> >>>> Envoyé : mardi 3 décembre 2024 06:23 À : 'Kent Watsen'
> >>>> <[email protected]>; Rob Wilton (rwilton)
> <[email protected]> Cc
> >>>> : Lou Berger <[email protected]>; [email protected] Objet : RE:
> >>>> [netmod] I-D Action:
> >>>> draft-ietf-netmod-rfc8407bis- 21.txt
> >>>>
> >>>> Hi Kent, all,
> >>>>
> >>>>> Lou and I are concerned about the text:
> >>>>>
> >>>>>  … or if they may reveal sensitive customer information
> >>>>> -- or violate personal privacy laws, such as those of the
> >>>> Euopean
> >>>>> -- Union, if exposed to unauthorized parties,
> >>>>>
> >>>>> The reason being is that it gets into Legal
> interpretations.
> >>>> We think
> >>>>> that this text can be struck, leaving it to the simpler
> >>>> statement "any
> >>>>> particularly sensitive readable data nodes”.
> >>>>
> >>>> That text is actually from RFC8407! Please see also
> >>>>
> >>
> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2
> >> Fwik
> >>>> i.ietf.org%2Fgroup%2Fops%2Fyang-security-
> >> guidelines&data=05%7C02%7Cmo
> >>>>
> >>
> hamed.boucadair%40orange.com%7C99f13f492d2a464d2fc208dd1ad1c372%7
> >> C90c
> >>>>
> >>
> 7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C638696210420611947%7CUnkn
> >> own%
> >>>>
> >>
> 7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJ
> >> XaW4
> >>>>
> >>
> zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=q3Ki%2FH
> >> tN%2
> >>>> BFGmGTB3mq%2FlNDGx5%2FjtoRYM1M5FoTfcem0%3D&reserved=0
> >>>>
> >>>> I don't know the context how that specific text landed in
> >> 8407.
> >>>>
> >>>> Cheers,
> >>>> Med
> >>>>
> >>>>> -----Message d'origine-----
> >>>>> De : Kent Watsen <[email protected]> Envoyé : mardi 3
> >>>> décembre 2024
> >>>>> 00:42 À : BOUCADAIR Mohamed INNOV/NET
> >>>> <[email protected]>;
> >>>>> Rob Wilton (rwilton) <[email protected]> Cc : Lou Berger
> >>>>> <[email protected]>; [email protected] Objet : Re: [netmod] I-
> D
> >>>> Action:
> >>>>> draft-ietf-netmod-rfc8407bis- 21.txt
> >>>>>
> >>>>>
> >>>>> Hi Med (and Rob Wilton),
> >>>>>
> >>>>> The current document contains new text proposed by Rob
> Wilton
> >>>> (in his
> >>>>> PR):
> >>>>>
> >>>>> -- If the data model contains any particularly sensitive
> >>>> readable
> >>>>> -- data nodes, e.g., ones that might be protected by a
> >>>>> -- "nacm:default-deny-read" or a "nacm:default-deny-all"
> >>>>> extensions
> >>>>> -- statement, or if they may reveal sensitive customer
> >>>> information
> >>>>> -- or violate personal privacy laws, such as those of the
> >>>> Euopean
> >>>>> -- Union, if exposed to unauthorized parties, then those
> >>>> subtrees
> >>>>> -- and data nodes must be listed here, along with an
> >>>> explanation of
> >>>>> -- the associated sensitivity, security, or privacy
> concerns.
> >>>>>
> >>>>> Lou and I are concerned about the text:
> >>>>>
> >>>>>  … or if they may reveal sensitive customer information
> >>>>> -- or violate personal privacy laws, such as those of the
> >>>> Euopean
> >>>>> -- Union, if exposed to unauthorized parties,
> >>>>>
> >>>>> The reason being is that it gets into Legal
> interpretations.
> >>>> We think
> >>>>> that this text can be struck, leaving it to the simpler
> >>>> statement "any
> >>>>> particularly sensitive readable data nodes”.
> >>>>>
> >>>>> Rob, do you have any objections?
> >>>>>
> >>>>> Kent and Lou
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>> On Nov 14, 2024, at 2:56 AM, [email protected]
> >>>>> wrote:
> >>>>>>
> >>>>>> Hi all,
> >>>>>>
> >>>>>> This version implements the changes discussed in Dublin,
> >>>>> especially to address the comments about long trees (Lou)
> and
> >>>> better
> >>>>> organize the commentary text in the sec template (Rob).
> >>>>>>
> >>>>>> Kent, it seems that you had a comment about clarifying
> "long
> >>>>> lines" (?) but I fail to see which part you were referring
> >> to,
> >>>>> especially that there are no occurrences of "lines" or
> "long
> >>>> line" in
> >>>>> -21. May be this was related to some of the text removed to
> >>>> address
> >>>>> the comment from Lou?
> >>>>>>
> >>>>>> Unless Kent still think a new rev is needed (and assuming
> he
> >>>>> provides text :-)), I think this version is ready to be
> sent
> >> to
> >>>> the
> >>>>> IESG.
> >>>>>>
> >>>>>> Thank you.
> >>>>>>
> >>>>>> Cheers,
> >>>>>> Med
> >>>>>>
> >>>>>>> -----Message d'origine-----
> >>>>>>> De : [email protected] <[email protected]>
> >>>>> Envoyé :
> >>>>>>> jeudi 14 novembre 2024 08:43 À : [email protected] Cc
> :
> >>>>>>> [email protected] Objet : I-D Action:
> >>>>>>> draft-ietf-netmod-rfc8407bis-21.txt
> >>>>>>>
> >>>>>>>
> >>>>>>> Internet-Draft draft-ietf-netmod-rfc8407bis-21.txt is now
> >>>>> available.
> >>>>>>> It is a work item of the Network Modeling (NETMOD) WG of
> >> the
> >>>>> IETF.
> >>>>>>>
> >>>>>>> Title:   Guidelines for Authors and Reviewers of
> Documents
> >>>>>>> Containing YANG Data Models
> >>>>>>> Authors: Andy Bierman
> >>>>>>>          Mohamed Boucadair
> >>>>>>>          Qin Wu
> >>>>>>> Name:    draft-ietf-netmod-rfc8407bis-21.txt
> >>>>>>> Pages:   93
> >>>>>>> Dates:   2024-11-13
> >>>>>>>
> >>>>>>> Abstract:
> >>>>>>>
> >>>>>>> This memo provides guidelines for authors and reviewers
> of
> >>>>>>> specifications containing YANG modules, including IANA-
> >>>>> maintained
> >>>>>>> modules.  Recommendations and procedures are defined,
> >>>> which
> >>>>> are
> >>>>>>> intended to increase interoperability and usability of
> >>>>> Network
> >>>>>>> Configuration Protocol (NETCONF) and RESTCONF protocol
> >>>>>>> implementations that utilize YANG modules.  This document
> >>>>> obsoletes
> >>>>>>> RFC 8407.
> >>>>>>>
> >>>>>>> Also, this document updates RFC 8126 by providing
> >>>> additional
> >>>>>>> guidelines for writing the IANA considerations for RFCs
> >>>> that
> >>>>>>> specify
> >>>>>>> IANA-maintained modules.  The document also updates RFC
> >>>> 6020
> >>>>> by
> >>>>>>> clarifying how modules and their revisions are handled by
> >>>>> IANA.
> >>>>>>>
> >>>>>>> The IETF datatracker status page for this Internet-Draft
> >> is:
> >>>>>>>
> >>>>>
> >>>>
> >>
> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2
> >>>>>>> Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-netmod-
> >>>>>>>
> >>>>>
> >>>>
> >>
> rfc8407bis%2F&data=05%7C02%7Cmohamed.boucadair%40orange.com%7C4ae
> >>>>>>>
> >>>>>
> >>>>
> >>
> ea5b9e9654b719a2308dd048011cb%7C90c7a20af34b40bfbc48b9253b6f5d20%
> >>>>>>>
> >>>>>
> >>>>
> >>
> 7C0%7C0%7C638671670286827006%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1h
> >>>>>>>
> >>>>>
> >>>>
> >>
> cGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsI
> >>>>>>>
> >>>>>
> >>>>
> >>
> ldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=TgPG%2BoExl6Z9GN27ifA%2FaXYeny
> >>>>>>> juNEjhs%2BGPyqbC8pc%3D&reserved=0
> >>>>>>>
> >>>>>>> There is also an HTML version available at:
> >>>>>>>
> >>>>>
> >>>>
> >>
> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2
> >>>>>>> Fwww.ietf.org%2Farchive%2Fid%2Fdraft-ietf-netmod-
> >> rfc8407bis-
> >>>>>>>
> >>>>>
> >>>>
> >>
> 21.html&data=05%7C02%7Cmohamed.boucadair%40orange.com%7C4aeea5b9e
> >>>>>>>
> >>>>>
> >>>>
> >>
> 9654b719a2308dd048011cb%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C
> >>>>>>>
> >>>>>
> >>>>
> >>
> 0%7C638671670286853445%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOn
> >>>>>>>
> >>>>>
> >>>>
> >>
> RydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjo
> >>>>>>>
> >>>>>
> >>>>
> >>
> yfQ%3D%3D%7C0%7C%7C%7C&sdata=VkB16NFtocbYQX5eL44D0EQaEGqrx6%2F3KG
> >>>>>>> B7urTEbl4%3D&reserved=0
> >>>>>>>
> >>>>>>> A diff from the previous version is available at:
> >>>>>>>
> >>>
> >>>
> >>
> _________________________________________________________________
> >> _____
> >>> ______________________________________
> >>> 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.
> >>> _______________________________________________
> >>> netmod mailing list -- [email protected] To unsubscribe send an
> >> email to
> >>> [email protected]
> >
> >
> _________________________________________________________________
> _____
> > ______________________________________
> > 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.
> > _______________________________________________
> > netmod mailing list -- [email protected] To unsubscribe send an
> email to
> > [email protected]

____________________________________________________________________________________________________________
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.
_______________________________________________
netmod mailing list -- [email protected]
To unsubscribe send an email to [email protected]

Reply via email to