Re: [OPSAWG] draft-ymbk-opsawg-9092-update-01

[[e-mail]]

Hi Randy, 

Thank you for the follow-up.

Please see inline. 

Cheers,
Med

> -----Message d'origine-----
> De : Randy Bush <[e-mail]>
> Envoyé : lundi 3 juillet 2023 20:25
> À : BOUCADAIR Mohamed INNOV/NET <[e-mail]>
> Cc : Ops Area WG <[e-mail]>; draft-ymbk-opsawg-9092-
> [e-mail]
> Objet : Re: [OPSAWG] draft-ymbk-opsawg-9092-update-01
> 
> hi med,
> 
> yay!  much thanks for the review.
> 
> > (1) As a complement to the discussion in the first para of the
> > Introduction, I would add a note that the source address does
> not
> > necessary point to the user. You may add a pointer to
> >....
> 
>    Providers of Internet content and other services may wish to
>    customize those services based on the geographic location of
> the user
>    of the service.  This is often done using the source IP address
> used
>    to contact the service, which may not point to a user, see
> [RFC6269],
>    Section 14 in particular.
> 

[Med] Looks good. Thanks. 

> [ are you just fishing for a cite :)  ]

[Med] ha ha ha. Not at all. It is the only stable document I'm aware of that touches on this. There is a recent document draft-iab-privacy-partitioning, but it is still a draft.

> 
> > (2) Section 1
> >
> > CURRENT:
> >    An optional utterly awesome but slightly complex means for
> >    authenticating geofeed data is also defined.
> >
> > You may add a pointer to Section 4 for better clarity.
> 
> <doh>  thanks
> 
>    An optional utterly awesome but slightly complex means for
>    authenticating geofeed data is also defined in Section 4.
> 
> > (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.

> this makes some sense to me; though we do seem to be adding more
> special sections to our cultural expectations.
> 
> co-authors please think about this.  i know massimo, for one, has
> been working the ground fight on this.
> 
> > (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).


> again, i would like to hear from co-authors.
> 
> > (5) RFC9092 is not normative, as this is obsoleted by this one.
> 
> oups.  thanks.
> 
> > (6) I would maintain the OLD title and delete "A Minor Update
> to"
> 
> this makes sense to me.  i have hacked it, but would love to hear
> from co-authors.
> 
> i would send a proposed diff to you, except i no longer know how
> to find the differ on the wonderfully improved web site.
> 

[Med] https://author-tools.ietf.org/iddiff

> again, thanks
> randy
____________________________________________________________________________________________________________
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.