Subject: IETF documents consistency problem

From: Vasilenko Eduard <[email-masked]>
Date: Mon, 22 Nov 2021 12:34:11 +0000

Hello Intenet Engineers,
I like to share my observation on standards (in)consistency.
Whatever old enough (5+ years) technology one would choose - one needs to research to find all related documents.
Some would say that additionally, one needs to dig all related emails.

There is a practice in IETF not to change the basic specification, but to release a separate RFC just for small expansion.

In some situations, It may be difficult to trace the parent specification or maybe many parent specifications.
But the problem is that the patch is not merging with parent specification if it is an evident expansion just for one specification.
For example, why RFC 7048<https://datatracker.ietf.org/doc/rfc7048/> or RFC 9131<https://datatracker.ietf.org/doc/rfc9131/> are separate from RFC 4861<https://datatracker.ietf.org/doc/rfc4861/>? If it is optional, then tell it in the primary specification.
It is not so much a problem for WG members - they need to do research anyway (and remember everything),
But for the Internet community, it is not possible to find time for comprehensive research for every topic.
I remember that the Carrier engineer has sent me his list of RFCs and drafts that need to be researched to understand ND. I was impressed by the list size but found later a few old RFCs that should be added to the list.

Other SDOs are more consistent. It is possible to be sure where to look to find a comprehensive discussion of the problem (with all features).
IEEE 802.11 WG (WiFi) is an example of the opposite extreme: they merge everything into the same parent document that may cross 5000 pages very soon. They have a separate WG just to maintain this monster.

Probably, there are many reasons:
- it is difficult to find a "consensus", hence, better not to touch the primary specification (people would abuse an opportunity to change it again in many places)
- basic RFC could not accommodate all names as co-authors. How WG members would report their contribution to the employer?
- merge would need some additional efforts
- and many others.

The net result is terrible. Muddy waters where only WG members could catch a big fish.
It is never open nor transparent for the Internet community.

IMHO: all WGs (especially old) have to have a separate thread for merging all the staff that they have produced over years.
Expansion for the one protocol should be released as the protocol update, not as a separate patch.
Patches should be more often integrated into the primary document.

Best Regards
Eduard Vasilenko
Senior Architect
Europe Standardization & Industry Development Department
Tel: +7(985) 910-1105, +7(916) 800-5506

---

From: Abdussalam Baryun <[email-masked]>
Date: Fri, 26 Nov 2021 21:28:43 +0200

Hi Eduard,

I agree there is a problem which needs time and effort to solve. It may be
the area director job to help to clarify or solve or reduce the cause.
However, in all IETF WGs if they think they want to do the job they can,.

AB

On Mon, Nov 22, 2021 at 2:34 PM Vasilenko Eduard <vasilenko.eduard=
[email-masked]> wrote:

> Whatever old enough (5+ years) technology one would choose – one needs to
> research to find all related documents.
>
> There is a practice in IETF not to change the basic specification, but to
> release a separate RFC just for small expansion.
>
>
>
> But the problem is that the patch is not merging with parent specification
> if it is an evident expansion just for one specification.
>
> For example, why RFC 7048 <https://datatracker.ietf.org/doc/rfc7048/> or RFC
> 9131 <https://datatracker.ietf.org/doc/rfc9131/> are separate from RFC
> 4861 <https://datatracker.ietf.org/doc/rfc4861/>? If it is optional, then
> tell it in the primary specification.
>
> It is not so much a problem for WG members – they need to do research
> anyway (and remember everything),
>
> I remember that the Carrier engineer has sent me his list of RFCs and
> drafts that need to be researched to understand ND. I was impressed by the
> list size but found later a few old RFCs that should be added to the list.
>
>
>
> Other SDOs are more consistent. It is possible to be sure where to look to
> find a comprehensive discussion of the problem (with all features).
>
> IEEE 802.11 WG (WiFi) is an example of the opposite extreme: they merge
> everything into the same parent document that may cross 5000 pages very
> soon. They have a separate WG just to maintain this monster.
>
>
>
> - it is difficult to find a “consensus”, hence, better not to touch the
> primary specification (people would abuse an opportunity to change it again
> in many places)
>
> - basic RFC could not accommodate all names as co-authors. How WG members
> would report their contribution to the employer?
>
> IMHO: all WGs (especially old) have to have a separate thread for merging
> all the staff that they have produced over years.
>