On Wed, Jun 28, 2023 at 2:52 AM Randy Bush wrote:
>
> we have pushed draft-ymbk-opsawg-9092-update-01, see
> https://datatracker.ietf.org/doc/draft-ymbk-opsawg-9092-update/
> and asked to have a few minutes for it on the agenda next month.
>
> as the document says
>
> Changes from [RFC9092] includ
I support adoption. This is a worthwhile update, its very simple and direct.
Wider use of Geofeed would be net-beneficial for understanding how IP
addresses are deployed, and who better to state that than the delegate
with an ability to prove their locus of control with a signature?
Sure, they can
I have read this version and checked the difference to the prior
version. It addressed specific issues I understood, it looks to
address ambiguities in the encoding and representation of its
structure which make it much more likely people can interoperate
correctly.
I think overall this is a good
To Randy's "remarks: field comment I would agree, it really isn't
desirable to make RIR police Remarks: and write NLP parsers to find
these things.
SHOULD NOT is better, guidance to users, no obligation to manage in
the RIR whois update process
-G
___
I think this is useful.
It shows how tools that operations people are familiar with can be
used to improve the trust in the feed.
Nice work Job!
-G
On Wed, Feb 3, 2021 at 12:25 PM Job Snijders
wrote:
>
> Dear Randy, working group,
>
> It appears to me you really wanted to ask 'how the heck did
n RPSL systems
author and supports the proposal.
Personnel
Who is the Document Shepherd?
The document Shepherd is George Michaelson g...@apnic.net
Who is the Responsible Area Director?
The responsible Area Director is Robert Wilton
(3) Briefly describe the review of this docu
> addresses a real world problem, of merit. The solution is plausible
> and low cost for high gain.
>
> If there was a MIB Doctor, YANG Doctor, Media Type or other
> expert review, what was its course (briefly)? In the case of a
> Media Type review, on what date was
please push the 03. I think it is very likely to close all the low-level Nits.
-G
On Wed, Feb 17, 2021 at 4:55 AM Randy Bush wrote:
>
> thanks ggm for a stunningly thorough shepherd's report. i have an -03
> revsion in an emacs buffer addressing your comments which i will publish
> when you, th
This resolved all but two downref issues:
** Downref: Normative reference to an Informational RFC: RFC 5485
** Downref: Normative reference to an Informational RFC: RFC 8805
As discussed, I think these cannot resolve, and will have to be
discussed out with the AD and IESG during review.
There is
Thats a good question. Whois lookups CAN ask for superior covering
blocks. Its in the protocol to do it (flags) in the port 43 query. I
don't think its normal.
This is the problem with data services which push to the most specific
record (and, in Whois, many exist) and inclusion of signing, which
A 04 version has gone up, with sensible edits to refine references to
the functional code (RSC) signing example, and no shepherd process is
required for this change: its good, useful and doesn't alter any
normative or IDNIT behaviour as I see it.
cheers
-George
On Fri, Feb 19, 2021 at 6:01 AM Jo
I also think Randy's version is better because of two things:
1) it aligns with reality: fields are added to RPSL as a response of
operator driven demand.
2) it aligns with the least cost path out: the likelihood of a reprise
or -bis of RPSL completing in the short or medium term in either IETF
o
> 2. -
>
>then BASE64 encoded and line wrapped to 72 or fewer characters.
>
> FP: Less of a comment and more of a question: what is the reason for setting
> the line length, and specifically to 72 (or fewer) characters?
RPSL uses a 6 character indent from the 80 column days to denote
folde
REGEXT is where RDAP is defined, and would be a good place for the RDAP
projection of this data to be worked on, thats how they handled geofeed. I
think the OPSAWG is a fine place to discuss this proposal right now.
I like this proposal a lot. I think it is the right kind of abstraction for
a poin
14 matches
Mail list logo
