Hi Randy, Please see inline …
From: Randy Bush <ra...@psg.com> Date: Thursday, 18 January 2024 at 19:45 To: Rob Wilton (rwilton) <rwil...@cisco.com> Cc: draft-ietf-opsawg-9092-update....@ietf.org <draft-ietf-opsawg-9092-update....@ietf.org>, Mahesh Jethanandani <mjethanand...@gmail.com>, Ops Area WG <opsawg@ietf.org> Subject: Re: AD review of draft-ietf-opsawg-9092-update-08 hi rob, thanks for review. appreciated. No problem. > (1) p 4, sec 3. inetnum: Class > > Any particular inetnum: object SHOULD have, at most, one geofeed > reference, whether a remarks: or a proper geofeed: attribute when it > is implemented. If there is more than one, the geofeed: attribute > SHOULD be used. > > I don't find this text as clear as it could be. Given the > recommendation is to have a single geofeed reference, then I think > that it would be helpful to provide guidance as to what format that > geofeed reference should take. I.e., I presume that the geofeed > reference SHOULD also use the geofeed: attribute format if the RIR > supports it or the remarks attribute otherwise? Any particular inetnum: object SHOULD have, at most, one geofeed reference, whether a remarks: or a proper geofeed: attribute when it is implemented. A geofeed: attribute is preferred, of course, if the RIR supports it. If there is more than one type of attribute in the intetnum: object, the geofeed: attribute SHOULD be used. LGTM. > (2) p 9, sec 6. Operational Considerations > > The geofeed files MUST be published via and fetched using HTTPS > [RFC9110]. > > Also note you have a similiar RFC 2119 statement in section 4, and I > wonder whether it would be clearer to only have the formal requirement > listed in one place and referenced from the other place? sure. removed the one in §4 Thanks. > (3) p 9, sec 6. Operational Considerations > > The geofeed files MUST be published via and fetched using HTTPS > [RFC9110]. > > It is interesting that the geofeed files MUST be fetched using HTTPS, > but earlier the RIR's FTP SHOULD be used to gather the geofeed > references. Presumably if the RIR data was available via HTTPS that > could also be used? this refers to RIRs providing *bulk* ftp, i.e. get the whole shebang in one slurp. can not do that for the geofeed files that are referenced. xref GEOFEED-FINDER does provide bulk retrieval of the geofeed files. Ack. Okay. > (4) p 11, sec 9. Security Considerations > > 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. > > This feels like quite a strong statement to make, and I wonder whether > it won't be better to just point out the risks of using a third-party > and then allow the reader to decide whether to accept that risk? that is why it is SHOULD not MUST, tempting though a MUST may be. there is a general problem of lack of understanding of trust boundaries in a lot of these ops data. if you do not mind, i think we would leave it in. Okay. > (5) p 7, sec 5. Authenticating Geofeed Data (Optional) > > Identifying the private key associated with the certificate and > getting the department that controls the private key (which might be > stored in a Hardware Security Module (HSM)) to generate the CMS > signature is left as an exercise for the implementor. On the other > hand, verifying the signature has no similar complexity; the > certificate, which is validated in the public RPKI, contains the > needed public key. The RPKI trust anchors for the RIRs are expected > to already be available to the party performing signature validation. > Validation of the CMS signature over the geofeed file involves: > > involves: => "involves the following steps:", or you need to change > back Obtain ... => Obtaining ..., etc. sharp eye there. i went with obtaining; gerundification :) Okay. You obviously need to change the tense of the action verb in the rest of the list. want me to push this as a -09, or let it mellow? Please push -09, and I’ll push to the IETF LC. Regards, Rob again, thanks. randy
_______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg