Summary

  • ARIN still lists suggestion 2024.8, filed in May 2024, as Open. The submitter reported an apparent 1,024-character limit on IRR remarks while moving AS-SET records into ARIN’s authenticated registry.
  • The request describes a Lumen convention in which remarks: Level3 members: carries source-qualified members and takes precedence over the standard RPSL members field.
  • Lumen’s own guide says the same AS-SET can be interpreted differently by its filter generator and by another consumer. That makes parser identity and output part of the control record.
  • Expanding a field can remove an awkward AS-SET-chaining workaround. It cannot make a private grammar portable or prove which filter reached a router.
  • ARIN should publish the field-change and validation boundary it controls; Lumen should make the parser profile and generated-set evidence it controls reproducible.

Analysis

A small ticket with two meanings inside it

The first version of this problem fits neatly into a product backlog. Dale Carder’s 9 May 2024 suggestion says that an attempt to move AS-SET records from a third-party, non-authoritative registry into ARIN encountered what appeared to be a 1,024-character ceiling on remarks. The proposed remedies are familiar: raise the limit, allow the attribute to repeat, or both.

The workaround was less neat. The submitter says the set had to be broken into a chain of smaller AS-SETs. That adds names, recursion and more places where an update can be incomplete. ARIN agreed that the improvement would help migration into its authenticated IRR and said it would consider the request with other IRR work. More than two years later, the current suggestion index still shows 2024.8 as Open.

That is the public status, not a verdict on ARIN’s internal work. The suggestion gives no promised delivery date, and this review did not test an authenticated object to see whether the reported limit remains in production. Yet the ticket remains useful because its motivating example identifies a problem that a character count cannot settle.

The extra text is not merely commentary. It can be executable policy input.

When a remark outranks the membership field

RFC 2622 gives the attributes different jobs. In an AS-SET, members lists AS numbers or other AS-SET names. mbrs-by-ref supplies an indirect, maintainer-based path into the set. remarks is free-form explanation or clarification. A person reading a conventional RPSL object can reasonably expect the membership fields to answer who belongs.

Lumen documents another rule for its own filter generator. If an AS-SET contains a remark beginning Level3 members: or Level3 mbrsby-ref:, the marked lines take precedence over the ordinary membership attributes. The private form can attach a registry source to each referenced object. Lumen says this solves a limitation in the general syntax it supports for cross-registry expansion.

The guide does not hide the consequence. It calls the behavior “filter generator dependent interpretation of set objects.” In its worked scenario, a consumer that understands the standard member entries derives one set, while Lumen ignores those entries because a special remark is present and derives its set from the alternate text.

RADb’s current help material records the same convention: a Level3 members: remark can point to a named database and referenced object. This is more than an obscure user report. It is a documented compatibility language living inside an attribute that the base specification calls free text.

Compatibility languages are not automatically bad. Distributed IRRs never became one perfectly coherent database, and operators have had to choose sources, mirrors and expansion rules. Lumen must protect ASN 3356 and build filters that reflect what customers are actually entitled to announce. Its guide says those filters are generated from IRR information and refreshed daily. Per-member source qualification can prevent a consumer from resolving a name in the wrong registry.

The trouble is not that the workaround exists. The trouble is that its authority is easy to misread.

One stored object, more than one effective set

The object maintainer writes an AS-SET. ARIN authenticates, validates and publishes the object. A consumer chooses its IRR sources and retrieves it. A parser then decides whether the marked remark is inert prose or an instruction that displaces members. Only after that interpretation can route objects be gathered and a filter candidate generated. Review, deployment and router state lie further downstream. BGP propagation and packet delivery lie further still.

Collapsing that chain creates two opposite mistakes. One makes ARIN responsible for a private parser it does not operate. The other treats Lumen’s result as an inevitable reading of an ARIN object. Neither is accurate. ARIN controls the accepted record. Lumen controls its interpretation profile. The customer controls the submitted intent, within each system’s rules. A router’s final policy cannot be inferred from any one of those records.

Field length affects only one seam. More capacity may let a maintainer keep a source-qualified compatibility list in one object instead of chaining several sets. That is a real benefit. But if the standard member field and private remark diverge, a larger field simply permits a larger divergence. If a maintainer edits members without knowing that one consumer ignores it, the visible correction may not change that consumer’s generated set. If the private parser changes, the stored object can remain byte-for-byte identical while its effective meaning changes.

This is why “support more characters” is not a complete acceptance test. The real test asks what each supported interpreter produces.

The receipt should begin at interpretation

A proportionate record need not publish router configurations, customer contracts or internal topology. It can start with the public object key, authoritative source and a canonical hash or serial of the object observed. It should name the parser profile and version, the marker that activated the private rule and the precedence assigned to it.

The next fields are the useful ones: source-qualified tokens accepted; tokens rejected, with reason classes; the normalized member set produced by standard expansion; the member set produced by the compatibility profile; and a digest plus a bounded list of additions, removals and unresolved references. A timestamp, input-source snapshot and generation status would make later reproduction possible. “Generated” must remain separate from “reviewed,” “deployed” and “observed at the router.”

ARIN’s part is narrower. If it changes the limit or makes remarks repeatable, the disposition should identify affected object classes and interfaces, describe how existing values are handled, and state plainly that accepting free text does not validate every external interpretation. If it decides not to implement the request, the same page should record that decision and the migration alternative. An indefinitely open label leaves operators unable to distinguish waiting, design and refusal.

Lumen’s part is to keep the compatibility profile testable. The April 2023 guide is strong evidence of the documented rule, but it is not a current filter receipt for every customer. A versioned parser statement and a way to compare standard with Lumen-specific expansion would turn a convention into something an operator can verify before a maintenance window.

What the sources do not establish

No tested route is alleged here. The record does not show a prefix rejected, leaked or accepted incorrectly. It does not show an outage, a security incident, a harmed customer or even how many current objects use the marker. The apparent 1,024-character ceiling comes from the submitter’s account; it was not reproduced in 2026. Open status does not prove that ARIN has done nothing behind the page.

Nor does a 2023 guide prove that every Lumen customer, parser instance or router follows the documented behavior unchanged today. It proves something narrower and sufficient: Lumen publicly described a precedence rule that makes interpretation consumer-dependent. That is enough to require care when calling a remarks expansion a mere user-interface enhancement.

The safest conclusion is also the most practical. Keep the compatibility path while operators still need it. Give it a name, version, output and migration state. Make the standard and private readings comparable. Then a larger field becomes an implementable improvement rather than a larger place for two control systems to disagree.

Sources