On Wednesday, December 8, 2021, 11:24:58 AM EST, t petch <ie...@btconnect.com> wrote: 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. <RR> If that is the case, then does that mean obsoleting 9127 is not the right thing to do? Regards,Reshad. 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 > . >
