hi med, >>> (4) Note sure we can mandate by spec how the data can be >>> "consumed". I'm afraid the NEW sentence in the Sec Cons>> isn't >>> useful. I would at least avoid the use of normative language >>> there. >> >> you mean >> >> The consumer of geofeed data SHOULD fetch and process the data >> themselves. Importing datasets produced and/or processed by a >> third-party places ill-advised trust in the third-party. >> >> are you saying this is not a security consideration, with which i >> am inclined to disagree? it's an attack vector; i could >> indirectly cause you not to get your MTV. or you just don't like >> the SHOULD? > > [Med] The point here is that the NEW SHOULD is too specific about how > a consumer access the content, while it does not guarantee that the > data is not altered (absent integrity/verification checks). Also, it > is OK to access the data via trusted parties that extract and present > the data with all due checks/verification in place. > > BTW, please note that you already have: > > All the security > considerations of [RFC8805] apply here as well. > > And RFC8805 says the following: > > For consumers, feed retrieval processes may receive input from > potentially hostile sources (e.g., in the event of hijacked traffic). > As such, proper input validation and defense measures MUST be taken > (see the discussion in Section 3.1).
i am still waiting to hear from co-authors. but ... i think this is trying to address an actual current problem. folk are alleging to provide aggregated data with no formal statement of the methods to ensure provenance, integrity, or authenticity of those data. so i am gonna stall on this one. >>> (3) Section 3 >>> >>> CURRENT: >>> "Currently, this has been..." >>> >>> It is good to report what is implemented, but I don't think we need >>> to have them frozen in the spec. Please see RFC7942. >> >> easy for me to hack, but i would like to hear from co-authors >> before doing so. some motivation for this update is the socio- >> politics of the RIRs and getting them to move forward. >> >> or are you perhaps suggesting an Implementation Status Section per >> 7942? > > [Med] Yes. ok. done. it is not always easy to pick what to move. so further discussion solicited. > [Med] https://author-tools.ietf.org/iddiff thanks! i am a poor ietf tools archaeologist. unfortunately, i am old enough to not like massive bits in an email. so i have stashed a proposed diff at https://archive.psg.com/draft-ymbk-9092update.diff.html thanks again for spending time on this. much appreciated. randy _______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
