> -- Section 3 -- > Having a standards track document relying on a 'remarks:' attribute looks > really weird. Should it rather be informational ? NB: I understand that > changing the RPSL syntax is mostly mission impossible.
note that it also specifies the "Geofeed:" attribute > Should the case when both "remarks: Geofeed" and "geofeed" are present but > differ be mentioned ? you want more/other than Any particular inetnum: object MUST have at most, one geofeed reference, whether a remarks: or a proper geofeed: attribute when it is implemented. If there is more than one, all are ignored. > -- Section 4 -- > What happens if the public key of the certificate is changed? Should the cert > serial number be part of the signature? Or at least mention the obvious that > the signature must be re-executed when the cert if changed (e.g., in > section 5). added If the geofeed file is signed, and the signer's certificate changes, the signature in the geofeed file MUST be updated. > -- Section 5 -- > Is there any reason why the doc shepherd is not acknowledged ? in what way was this insufficient? The authors also thank George Michaelson, the document shepherd, ... > I find the use of the colon in "inetnum:" quite annoying and > confusing. so say we all. but it seems to be the convention in the RPSL docs. > The use of quotes in the last § of section 3 is easier to read and > parse i think we're in RDAP land at that point. perhaps massimo and/pr ggm, who are more clued in that space could comment. > -- Section 3 -- > Do the examples really need to be in IPv4 ? ;-) i am old > -- Section 4 -- > The use of "department" in "getting the department with the Hardware > Security Module" is difficult to understand by non-English native > readers (at least for me as I had to re-read it twice and guess the > meaning). prefer "part of the company?" randy _______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
