At least ChatGTP agrees this is backward compatible:
In YANG (RFC 7950), loosening a constraint is backward compatible, while
tightening a constraint is not.
Changing the range from:
uint8 { range "1..128"; }
to:
uint8 { range "0..128"; }
expands the set of valid values by adding 0.
That means:
All values that were valid before (1..128) are still valid
Existing clients that send values in the old range will continue to work
Existing servers that produced values in the old range are still compliant
So this is a relaxation, not a restriction.
How RFC 7950 views this
RFC 7950 treats changes as backward compatible if they do not invalidate
previously valid data. Expanding a range (or length, pattern, etc.) fits that
rule.
Practical caveats (worth keeping in mind)
While it’s backward compatible per YANG rules, you should still consider:
Semantic meaning: If 0 has special meaning (e.g., “unset”, “disabled”), clients
may not expect it.
Defaults: If the leaf has a default, adding 0 doesn’t change behavior unless
the default is changed.
Client assumptions: Some clients may implicitly assume >=1 even if the model
didn’t strictly guarantee it — that’s a client bug, but it happens.
Summary
✅ Backward compatible in YANG 1.1
❌ Not backward compatible would be something like 1..128 → 10..128
If you want, I can also walk through how this affects semantic versioning,
deviation handling, or client/server upgrade scenarios.
Is this conversation helpful so far?
> On Jan 27, 2026, at 8:42 AM, Acee Lindem <[email protected]> wrote:
>
> Hi Oscar,
>
> It would seem otherwise be a backward compatible change since the range is
> less restrictive but would require a BIS version of the document.
>
> Thanks,
> Acee
>
>> On Jan 27, 2026, at 8:22 AM, OSCAR GONZALEZ DE DIOS
>> <[email protected]> wrote:
>>
>> Dear RTWG colleagues and RFC 9067 authors,
>>
>> The yang model in 9067 allows to represent a prefix range list with
>> ip-prefix and a mask-lenght-lower and upper in each entry of the list. While
>> using the model to reconcile all the prefix-lists in my company's networks I
>> found that it was not possible to represent one corner case the exact
>> 0.0.0.0/0 (or the equivalent ::/0 in IPv6) . It would be ip-prefix
>> 0.0.0.0/0 mask-lenght-lower 0 and upper-length-lower 0, but unfortunately in
>> the model mask-length-upper needs to be at least 1 (cannot be 0).
>>
>> Would it be feasible to update the yang model to allow the
>> mask-length-upper to start with 0 and cover this use case (found in
>> operational networks)?
>>
>> Please find below the tree and current definition.
>>
>> | | +--rw prefixes
>> | | +--rw prefix-list* [ip-prefix mask-length-lower
>> | | mask-length-upper]
>> | | +--rw ip-prefix inet:ip-prefix
>> | | +--rw mask-length-lower uint8
>> | | +--rw mask-length-upper uint8
>> leaf mask-length-upper {
>> type uint8 {
>> range "1..128";
>> }
>> must '../mask-length-upper >= ../mask-length-lower' {
>> error-message "The upper bound MUST NOT be less "
>> + "than lower bound.";
>> }
>> description
>> "Mask length range upper bound. It MUST NOT be less than
>> lower bound.";
>> }
>> }
>>
>> Best Regards,
>>
>>
>> Oscar Gonzalez de Dios
>> Technical Lead for SDN in Transport Networks
>> Telefonica CTIO Transport Network Unit
>> <Outlook-hdzxtpb2.png>
>>
>>
>>
>> Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario,
>> puede contener información privilegiada o confidencial y es para uso
>> exclusivo de la persona o entidad de destino. Si no es usted. el
>> destinatario indicado, queda notificado de que la lectura, utilización,
>> divulgación y/o copia sin autorización puede estar prohibida en virtud de la
>> legislación vigente. Si ha recibido este mensaje por error, le rogamos que
>> nos lo comunique inmediatamente por esta misma vía y proceda a su
>> destrucción.
>>
>> The information contained in this transmission is confidential and
>> privileged information intended only for the use of the individual or entity
>> named above. If the reader of this message is not the intended recipient,
>> you are hereby notified that any dissemination, distribution or copying of
>> this communication is strictly prohibited. If you have received this
>> transmission in error, do not read it. Please immediately reply to the
>> sender that you have received this communication in error and then delete it.
>>
>> Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinatário,
>> pode conter informação privilegiada ou confidencial e é para uso exclusivo
>> da pessoa ou entidade de destino. Se não é vossa senhoria o destinatário
>> indicado, fica notificado de que a leitura, utilização, divulgação e/ou
>> cópia sem autorização pode estar proibida em virtude da legislação vigente.
>> Se recebeu esta mensagem por erro, rogamos-lhe que nos o comunique
>> imediatamente por esta mesma via e proceda a sua destruição
>> _______________________________________________
>> rtgwg mailing list -- [email protected] <mailto:[email protected]>
>> To unsubscribe send an email to [email protected]
>> <mailto:[email protected]>
_______________________________________________
rtgwg mailing list -- [email protected]
To unsubscribe send an email to [email protected]
