Re-,

Thank you Randy for the follow-up.

Please see one comment inline.

Cheers,
Med

> -----Message d'origine-----
> De : Randy Bush <[email protected]>
> Envoyé : mercredi 15 novembre 2023 18:07
> À : BOUCADAIR Mohamed INNOV/NET <[email protected]>
> Cc : Oops Area WG <[email protected]>
> Objet : Re: [OPSAWG] WG LC: draft-ietf-opsawg-9092-update
> 
> hi med,
> 
> thanks a million for the time reviewing
> 
> >   *   Abstract: add "This document obsoletes RFC 9092.
> 
> sure; in my emacs buffer for -07.  aside: is this sort of doc tracking
> in abstracts a fashion?
> 
> >   *   Abstract: s/datafiles/data files
> 
> doh.  thanks.
> 
> >   *   The changes vs 9092 lists "Geofeed file only UTF-8 CSV", but
> the
> >       NEW abstract removes the CSV mentions that were called out in
> >       the abstract of RFC9092. I would revert to the OLD wording in
> >       9092.
> 
> my, admittedly poor, memory is that this happened because some other
> reviewer pushed in the other direction.
> 
> but i think this would be a good change and is in my emacs buffer for
> -07.  unless i hear otherwise, good change
> 
> >  * I would delete "Stress that authenticating geofeed data is
> >    optional." as it was clear enough in 9092 that part is optional:
> > "  An optional utterly awesome but slightly complex means for
> >    authenticating geofeed data"
> 
> this was put in very intentionally.  we got a fair bit of ops
> reluctance to implement because folk whined that the authentication
> was too high a hill to climb.
> 
> to quote a proponent "This is probably the main push back I get from
> people procrastinating [about] adoption."
> 
> so, unless you feel strongly, i suggest no harm in the redundancy of
> leaving it in.
> 
> >   *   Inappropriate use of normative language in an example in
> Section
> >       4: s/ this MUST be discarded because 192.0.2.0/24 is within
> the
> >       more/ this must be discarded because 192.0.2.0/24 is within
> the
> >       more
> 
> uh, discarding is not optional, but rather an 'absolute requirement'
> [2119].  are we off here?  if you feel strongly, whack me again.
> 

[Med] The point is that this is an example to illustrate the following MUST:

   Given an address range of interest, the most specific inetnum: object
   with a geofeed reference MUST be used to fetch the geofeed file.

The second MUST is not justified. 

> >   * Not sure I would keep the last para starting with "There is
> >     open-source code to traverse ..." in Section 4. This is can be
> >     moved to an appendix of to Section 8.
> 
> hmmm.  this is not describing an implementation (sec 8) of geofeed
> objects, but a *use* of them.  it's a bit of a selling point, ease of
> use.  i am open to argument either way.  clue bat please.
> 
> again, deep thanks for reviewing.  good reviews are not easy to get
> these days.
> 
> 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.

_______________________________________________
OPSAWG mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/opsawg

Reply via email to