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://datatracker.ietf.org/doc/html/draft-ietf-netmod-yang-usage-10 
> (08/2010)
> 
> This was proposed by Bert Wijnen at 
> https://mailarchive.ietf.org/arch/msg/netmod/k7KYXbqti4vCWYMNzaWTukE80pM/ 
> (03/2010). The discussion seems also to happen in IETF#77 
> (https://www.ietf.org/proceedings/77/minutes/netmod.txt). 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://wiki.ietf.org/group/ops/yang-security-guidelines
>> 
>> 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]

_______________________________________________
netmod mailing list -- [email protected]
To unsubscribe send an email to [email protected]

Reply via email to