[netmod] Re: I-D Action: draft-ietf-netmod-rfc8407bis-21.txt

[[e-mail]]

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 <[e-mail]>
> Envoyé : jeudi 12 décembre 2024 18:24
> À : BOUCADAIR Mohamed INNOV/NET <[e-mail]>
> Cc : [e-mail]; Rob Wilton (rwilton) <[e-mail]>
> 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, [e-mail]
> 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' <[e-mail]>; Rob Wilton (rwilton)
> >> <[e-mail]> Cc : Lou Berger <[e-mail]>;
> >> [e-mail] 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 <[e-mail]> Envoyé : mardi 3
> >> décembre 2024
> >>> 00:42 À : BOUCADAIR Mohamed INNOV/NET
> >> <[e-mail]>;
> >>> Rob Wilton (rwilton) <[e-mail]> Cc : Lou Berger
> >>> <[e-mail]>; [e-mail] 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, [e-mail]
> >>> 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 : [e-mail] <[e-mail]>
> >>> Envoyé :
> >>>>> jeudi 14 novembre 2024 08:43 À : [e-mail] Cc :
> >>>>> [e-mail] 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 -- [e-mail] To unsubscribe send an
> email to
> > [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.