On 08/12/2021 12:58, Jeffrey Haas wrote:
Tom,

On Wed, Dec 08, 2021 at 09:30:02AM +0000, t petch wrote:
All the instances of the text string '9127' that appear in the I-D
9127-bis and most of which need to be changed to the text string
'XXXX'.  I stopped counting when I got to forty.

Thanks for clarifying.  I've opened a new issue in the github for this.
(Issue #8)  I had originally thought you'd meant instances in the
RFC series.

Also, I think that having two RFC with identical names and a very
slight difference in technical content is likely to induce errors ie
a revised title is needed such as 'YANG Data Model for Bidirectional
Forwarding Direction - Enhanced' or Revised or Augmented or MkII or
some such.  And yes, that is another forty changes.

I'm personally of mixed opinion on this one.

The YANG modules, the thing of main importance here, all contain version
strings in their filenames.

Similarly, the modules get a revision clause that cover the changes.  The
description for what is currently listed as revision 2021-12-01 currently
says "RFC 9127-bis".  This could perhaps use better text.  Any specific
suggestions?

The IANA Considerations are now a nonsense; I think that IANA need
consulting on what they want to do about whatever happens and
9127-bis revising accordingly.

Issue #9 has been opened to track this.  I believe this is mostly a simle
matter of requesting IANA to update the previous registrations to point to
the RFC-to-be.

Wrong!

RFC9127 set up an IANA-maintained module and provided the initial entries and handed control over to IANA. That is done, dusted, finished with. You cannot provide initial entries again, they are there in IANA. You cannot provide the instructions - they have already been given to IANA. (Something similar has happened previously with other WG and the result is a mess, a chain of RFC which you have to trace back and end up concluding that this is impossible to understand; indeed there is an I-D with the IESG at present where several AD have said they cannot comprehend how the registry got into the state it is in - I can!).

There is nothing to be changed as a result of what is currently proposed in 9127-bis; the IANA registry, the instructions about it change not a whit so this I-D must do nothing. A helpful note explaining why section 2.11 has been removed (as it must be) and an IANA Considerations saying that this I-D, unlike RFC9127, makes no change to the IANA-maintained module (as indeed it cannot as it is IANA-maintained!). It is all very simple and logical.

Tom Petch






And then there are all the things that I have yet to think about -
give me time:-)

The feedback and its impact on document quality is appreciated.

-- Jeff
.


Reply via email to