Hi Amanda, Thank you for your additional review and comment. Your comment should be addressed in my local version.
I have added: 1-63 | Unassigned BTW, I have added the following note. Is this appropriate? Any correction welcome. "Note: In order to minimize encoding space, a new allocation should pick the smallest available value." Thanks you, --Bruno > Orange Restricted > -----Original Message----- > From: Amanda Baber via RT <[email protected]> > Sent: Thursday, June 29, 2023 4:12 AM > To: DECRAENE Bruno INNOV/NET <[email protected]> > Cc: [email protected]; [email protected]; [email protected]; > [email protected]; [email protected]; [email protected]; [email protected]; > [email protected]; [email protected]; > [email protected]; [email protected]; [email protected]; > [email protected]; [email protected]; [email protected]; > [email protected] > Subject: [IANA #1275635] RE: Early review: draft-ietf-lsr-isis-fast-flooding > (IETF 116) > > Hi Bruno, all, > > This looks great, and unfortunately I see that I missed one item. > > The table in Section 7.3 contains a single registration that has value 0. How > many unassigned values are available? Here we'd like to see something that > looks like the "7-255 | Unassigned" entry in Table 1. > > Thank you very much for the updates! > > Amanda > > On Wed Jun 28 15:34:33 2023, [email protected] wrote: > > Dear Amanda, IANA > > > > > Before the IETF meeting, we check documents listed on working group > > > agendas for IANA-related issues > > > > Many thanks for your early review and your comments. > > > > FYI, we have just published -04 which is intended to address your > > comments. > > > > A diff from the previous version is available at: > > https://author-tools.ietf.org/iddiff?url2=draft-ietf-lsr-isis-fast- > > flooding-04 > > > > Best regards, > > --Bruno, on behalf of authors > > > > > > Orange Restricted > > > > -----Original Message----- > > From: Amanda Baber via RT <[email protected]> > > Sent: Thursday, March 23, 2023 5:58 AM > > Cc: [email protected]; [email protected]; DECRAENE > > Bruno INNOV/NET <[email protected]>; [email protected]; > > [email protected]; [email protected]; > > [email protected]; [email protected]; [email protected]; > > [email protected]; [email protected]; [email protected]; > > [email protected]; [email protected]; [email protected]; > > [email protected] > > Subject: [IANA #1269112] Early review: draft-ietf-lsr-isis-fast- > > flooding (IETF 116) > > > > Dear Authors, > > > > Before the IETF meeting, we check documents listed on working group > > agendas for IANA-related issues. We have questions about the current > > version of this document: > > > > https://datatracker.ietf.org/doc/draft-ietf-lsr-isis-fast-flooding/ > > > > 1) Every IS-IS registry now has a "Description" field between the > > "Expert(s)" and "Reference" fields: > > > > https://www.iana.org/assignments/isis-tlv-codepoints > > > > Should that be provided for the new registries? > > > > 2) Every IS-IS registry name is now prefixed by "IS-IS." Also, there > > appears to be a naming scheme in place. Should these names be changed? > > If you have questions, please contact Les Ginsberg. > > > > 2) What's the registration procedure for the registry in Section 7.3? > > > > For more information on general (non-IS-IS-specific) IANA > > requirements, please see > > > > https://www.iana.org/help/protocol-registration > > > > If you have any questions, just let us know. If you'd like to talk in > > person, you can find us next to the RFC Editor's table from Monday > > through Thursday. You can also request another review at any time by > > contacting us at [email protected]. > > > > Best regards, > > > > Amanda Baber > > IANA Operations Manager > > ____________________________________________________________________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations > > confidentielles ou privilegiees et ne doivent donc > > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez > > recu ce message par erreur, veuillez le signaler > > a l'expediteur et le detruire ainsi que les pieces jointes. Les > > messages electroniques etant susceptibles d'alteration, > > Orange decline toute responsabilite si ce message a ete altere, > > deforme ou falsifie. Merci. > > > > This message and its attachments may contain confidential or > > privileged information that may be protected by law; > > they should not be distributed, used or copied without authorisation. > > If you have received this email in error, please notify the sender and > > delete this message and its attachments. > > As emails may be altered, Orange is not liable for messages that have > > been modified, changed or falsified. > > Thank you. > ____________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you. _______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
