[Lsr] Question on draft-qgp-lsr-isis-pics-yang
Working Group, During the presentation of draft-qgp-lsr-isis-pics-yang there was a rather strong opposition in the chat against using the ISO-term "PICS" in an IETF document. I think the term "Support" was suggested (excuse me if I missed something), but I'm not that impressed, and would rather like to see something like - "Supported Protocol Aspects". /Loa -- Loa Anderssonemail: l...@pi.nu Senior MPLS Expert loa.pi...@gmail.com Bronze Dragon Consulting phone: +46 739 81 21 64 ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] [EXTERNAL] RtgDir Last Call review: draft-ietf-lsr-isis-fast-flooding
Sasha, Good catch! I missed that. /Loa On 2023-10-08 08:33, Alexander Vainshtein wrote: Loa and all, I’ve read the draft, and found what looks as an obvious typo in the following sentence in Section 8 (highlighted): In the absence of cryptographic authentication, as IS-IS does not run over IP but directly over the link layer, it's considered difficult to inject false SNP/IHH without having access to the link layer. It should be: In the absence of cryptographic authentication, as IS-IS does not run over IP but directly over the link layer, it's considered difficult to inject false SNP/IIH without having access to the link layer. Lots of thanks to the authors for a very readable document and to Loa for an excellent review. Regards, Sasha *From:* Lsr *On Behalf Of *Loa Andersson *Sent:* Saturday, October 7, 2023 7:32 PM *To:* rtg-...@ietf.org *Cc:* rtg-...@ietf.org; draft-ietf-lsr-isis-fast-flooding@ietf.org; lsr-chairs ; lsr@ietf.org; l...@pi.nu *Subject:* [EXTERNAL] [Lsr] RtgDir Last Call review: draft-ietf-lsr-isis-fast-flooding Hello, I have been selected as the Routing Directorate reviewer for this draft. The Routing Directorate seeks to review all routing or routing-related drafts as they pass through IETF last call and IESG review, and sometimes on special request. The purpose of the review is to provide assistance to the Routing ADs. For more information about the Routing Directorate, please see https://wiki.ietf.org/en/group/rtg/RtgDir <https://wiki.ietf.org/en/group/rtg/RtgDir> Although these comments are primarily for the use of the Routing ADs, it would be helpful if you could consider them along with any other IETF Last Call comments that you receive, and strive to resolve them through discussion or by updating the draft. Document: draft-ietf-lsr-isis-fast-flooding (the current version is -05) Reviewer: Loa Andersson Review Date: 2023-10-08 IETF LC End Date: Intended Status: Experimental Summary: This document is basically ready for publication; I only found one issue - the number of authors listed. Document Overview: Current Link State Protocol Data Unit (PDU) flooding rates are much slower than what modern networks can support. The use of IS-IS at larger scale requires faster flooding rates to achieve desired convergence goals. This document discusses the need for faster flooding, the issues around faster flooding, and some example approaches to achieve faster flooding. It also defines protocol extensions relevant to faster flooding. Comments: The draft is well-written and easy to read. I gone over the IANA Considerations and allocations, and not found anything that need to be addressed. Major Issues: Number of authors: There are 7 authors, that is more the the "allowed" 5 authors. I have no background why there 7 authors listed, this has to be addressed in some way: - reduce the number of authors to five - keep the number of authors at seven, and the Shepherd will have to address this in the SWU, I have put this as a "major issue" since I don't know where to put it. My personal opinion is that anyone that has contributed text to the document, and participated in the authors discussions, should be listed as an author. "No minor issues found." Nits: The nits-tool only finds a Miscellaneous warning: -- The document date (5 September 2023) is 32 days in the past. Is this intentional? This warning is a bit annoying since it is impossible to avoid. I have not found any other nits. /Loa -- Loa Andersson email: l...@pi.nu <mailto:l...@pi.nu> Senior MPLS Expert loa.pi...@gmail.com <mailto:loa.pi...@gmail.com> Bronze Dragon Consulting phone: +46 739 81 21 64 ___ Lsr mailing list Lsr@ietf.org <mailto:Lsr@ietf.org> https://www.ietf.org/mailman/listinfo/lsr <https://www.ietf.org/mailman/listinfo/lsr> *Disclaimer* This e-mail together with any attachments may contain information of Ribbon Communications Inc. and its Affiliates that is confidential and/or proprietary for the sole use of the intended recipient. Any review, disclosure, reliance or distribution by others or forwarding without express permission is strictly prohibited. If you are not the intended recipient, please notify the sender immediately and then delete all copies, including any attachments. -- Loa Anderssonemail: l...@pi.nu Senior MPLS Expert loa.pi...@gmail.com Bronze Dragon Consulting phone: +46 739 81 21 64 ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
[Lsr] RtgDir Last Call review: draft-ietf-lsr-isis-fast-flooding
Hello, I have been selected as the Routing Directorate reviewer for this draft. The Routing Directorate seeks to review all routing or routing-related drafts as they pass through IETF last call and IESG review, and sometimes on special request. The purpose of the review is to provide assistance to the Routing ADs. For more information about the Routing Directorate, please see https://wiki.ietf.org/en/group/rtg/RtgDir Although these comments are primarily for the use of the Routing ADs, it would be helpful if you could consider them along with any other IETF Last Call comments that you receive, and strive to resolve them through discussion or by updating the draft. Document: draft-ietf-lsr-isis-fast-flooding (the current version is -05) Reviewer: Loa Andersson Review Date: 2023-10-08 IETF LC End Date: Intended Status: Experimental Summary: This document is basically ready for publication; I only found one issue - the number of authors listed. Document Overview: Current Link State Protocol Data Unit (PDU) flooding rates are much slower than what modern networks can support. The use of IS-IS at larger scale requires faster flooding rates to achieve desired convergence goals. This document discusses the need for faster flooding, the issues around faster flooding, and some example approaches to achieve faster flooding. It also defines protocol extensions relevant to faster flooding. Comments: The draft is well-written and easy to read. I gone over the IANA Considerations and allocations, and not found anything that need to be addressed. Major Issues: Number of authors: There are 7 authors, that is more the the "allowed" 5 authors. I have no background why there 7 authors listed, this has to be addressed in some way: - reduce the number of authors to five - keep the number of authors at seven, and the Shepherd will have to address this in the SWU, I have put this as a "major issue" since I don't know where to put it. My personal opinion is that anyone that has contributed text to the document, and participated in the authors discussions, should be listed as an author. "No minor issues found." Nits: The nits-tool only finds a Miscellaneous warning: -- The document date (5 September 2023) is 32 days in the past. Is this intentional? This warning is a bit annoying since it is impossible to avoid. I have not found any other nits. /Loa -- Loa Anderssonemail: l...@pi.nu Senior MPLS Expert loa.pi...@gmail.com Bronze Dragon Consulting phone: +46 739 81 21 64 ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] When is an IANA Registry Required
v-codepoints.xhtml <https://www.iana.org/assignments/isis-tlv-codepoints/isis-tlv-codepoints.xhtml> you will easily be able to find whatever information you need. The addition of a separate registry for each flags field is then redundant at best. And redundancy in such matters introduces additional work and the possibility of unintentional inconsistency which I find hard to justify. Hence my conclusion that the value of such additional registries does not justify their creation. You (and others) may still disagree. And I assure you that as my primary motivation for this thread was to have a consistent WG policy for such fields, I will abide by whatever policy is chosen by the WG even if it is not my preferred choice. But I do think the arguments being made for the creation of such registries bear closer scrutiny. Just my opinion of course… Thanx (again) for listening. Les *From:*Tony Li mailto:tony1ath...@gmail.com>> *On Behalf Of *Tony Li *Sent:* Thursday, March 18, 2021 8:24 AM *To:* Les Ginsberg (ginsberg) <mailto:ginsb...@cisco.com>> *Cc:* Alvaro Retana <mailto:aretana.i...@gmail.com>>; draft-ietf-lsr-isis-srv6-extensi...@ietf.org <mailto:draft-ietf-lsr-isis-srv6-extensi...@ietf.org>; lsr@ietf.org <mailto:lsr@ietf.org>; John Scudder <mailto:j...@juniper.net>>; Christian Hopps <mailto:cho...@chopps.org>>; lsr-cha...@ietf.org <mailto:lsr-cha...@ietf.org> *Subject:* Re: [Lsr] When is an IANA Registry Required Les, IMO, there is no need for registries for the first category. The WG has been alive for over 20 years, defined many new TLVs with flags fields, and I am not aware of any confusion – so if it ain’t broke don’t fix it. With all due respect Les, you appear to operate with an eidetic memory of all things IS-IS, so I think that you discount the confusion that the rest of us live in. If a field has values defined in two documents, then there’s confusion. Even just finding both is a challenge. Regards, Tony ___________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr -- Loa Anderssonemail: l...@pi.nu Senior MPLS Expert loa.pi...@gmail.com Bronze Dragon Consulting phone: +46 739 81 21 64 ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] WG adoption call for draft-przygienda-lsr-flood-reflection-01
Working Group, I support the adoption of this document. /Loa On 11/06/2020 03:28, Christian Hopps wrote: This begins a 2 week WG adoption call for the following draft: https://datatracker.ietf.org/doc/draft-przygienda-lsr-flood-reflection The draft would be adopted on the Experimental track. Please indicate your support or objection by June 24, 2020. Authors, please respond to the list indicating whether you are aware of any IPR that applies to this draft. Thanks, Chris and Acee. ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr -- Loa Anderssonemail: l...@pi.nu Senior MPLS Expert loa.pi.nu@gmail Bronze Dragon Consulting phone: +46 739 81 21 64 ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] [IANA #1171772] Early Allocations request for "Area Proxy for IS-IS" - draft-li-lsr-isis-area-proxy-04
Amanda, Thanks, for the clarification. I have not had to manage code point allocation for Expert Review registries and had not looked at 7370. Small question, if you do the hybrid early allocation and then 6 months later the document is is approved as an RFC is that the time when you mark the allocations permanent? /Loa On 03/06/2020 03:17, Amanda Baber via RT wrote: Hi Loa, all, A note about this: Yeah - you are requesting code points from registries where the registration procedures are "Expert Review". But those are not early allocation, they are permanent. There is a kind of hybrid early allocation/Expert Review procedure for the IS-IS Exert Review registries, which is what I understood to be in use here. If the experts approve, we mark the registrations as temporary and ask them to re-approve a year later. It's described in Section 4 of RFC 7370: https://tools.ietf.org/html/rfc7370#section-4 thanks, Amanda On Tue Jun 02 18:01:21 2020, l...@pi.nu wrote: Tony, inline plz. On 02/06/2020 22:42, Tony Przygienda wrote: Loa, fair points though I would say adoption is kind of a different kettle of fish than early allocation. yeah - but the point I made, modulo some small updates in the IANA considerations I think the document is ready for wg adoption. And really the updates in the IANA considerations is strictly not necessary for wg adoption, but I prefer to have the IANA registries in scope clearly pointed out. RFC7120 does not seem to apply given ISIS registries are under expert review (largely due to historical reasons AFAIS). Yeah - you are right. I missed that, was to focused on the requirements in 7120. I watch that with lots of interest since due to customer discussions/(deployment) planning we request with experts early allocation for https://datatracker.ietf.org/doc/draft-przygienda-lsr-flood- reflection/ Yeah - you are requesting code points from registries where the registration procedures are "Expert Review". But those are not early allocation, they are permanent. We have however the benefit of not needing any new registries. Yes, that is a blessing, but for a new registry you can actually capture in the draft and populate it with code point values, the only thing is that once you put a value in there it should not be changed. Especially if you know of early implementations. For your draft the registries should be called: Sub-TLVs for TLV 242 (IS-IS Router CAPABILITY TLV); and Sub-TLVs for TLVs 22, 23, 25, 141, 222, and 223 (Extended IS reachability, IS Neighbor Attribute, L2 Bundle Member Attributes, inter-AS reachability information, MT-ISN, and MT IS Neighbor Attribute TLVs) (Don't blame me, I didn't name the registries :) ). and both registries are found in the IS-IS TLV Codepoints namespace. /Loa thanks -- tony On Tue, Jun 2, 2020 at 1:00 AM Loa Andersson mailto:l...@pi.nu>> wrote: Folks, I have two questions on the early allocation. RFC 7120 allows early allocation for two types of The processes described below assume that the document in question is the product of an IETF Working Group (WG). If this is not the case, replace "WG chairs" below with "Shepherding Area Director". draft-li-lsr-isis-area-proxy is an individual document, i.e. not a product of a working group nor shepherded by an AD, and does not seem to meet the criteria for early allocation. Also. draft-li-lsr-isis-area-proxy request that IANA create a new registry, as far as I understand new registries can't be created through early allocation. It is hardly necessary. The code points are requested from "the IS-IS TLV Codepoints registry", howver the "IS-IS TLV Codepoints" is a name space with 14 different registries. I think the the registry you want to allocated code point from the "TLV Codepoints registry" Since the document, at least I read it, well meet the criteria for becoming a working document (minor update to the IANA section), I think that the easy way out is to start the working group adoption poll. /Loa On 02/06/2020 12:52, Tony Li wrote: > > Hi Amanda, > >> However, the IANA Considerations section is missing some information. >> How would we fill in the IIH, LSP, SNP, and Purge fields for >> the TLV >> Codepoint registrations? > > > We’ve addressed this in > https://tools.ietf.org/html/draft-li-lsr-isis-area-proxy-06.. > > Thanks, > Sarah & Tony > > > ___ > Lsr mailing list > Lsr@ietf.org <mailto:Lsr@ietf.org> > https://www.ietf.org/mailman/listinfo/lsr > -- My mail server from time to time has come under DOS attacks, we are working to fix it but it may take some time. If you get de
Re: [Lsr] Question on the early allocation - Re: [IANA #1171772] Early Allocations request for "Area Proxy for IS-IS" - draft-li-lsr-isis-area-proxy-04
Tony, I guess that this shows that we should take care naming our registries. In line please- On 02/06/2020 23:24, tony...@tony.li wrote: Hi Loa, The code points are requested from "the IS-IS TLV Codepoints registry", howver the "IS-IS TLV Codepoints" is a name space with 14 different registries. I think the the registry you want to allocated code point from the "TLV Codepoints registry” I apologize for the confusion, you are certainly correct. The confusion arises because the page is named “IS-IS TLV Codepoints” and the registry is the “TLV Codepoints Registry” so to be precise, we should request an allocation from the “IS-IS TLV Codepoints TLV Codepoints Registry”. That does seem somewhat awkward and redundant redundant. To reduce confusion in the future, perhaps the entire page should be renamed to “IS-IS Codepoints”? In the party of the world there I'm active there is a tendency to call "the page" the "name space", that stops us from repeating "registry" to often, so we have name space, registry and sub-registry. This is as I understand it a terminology IANA understands, even if there is no formal acceptance of it. Renaming the name space would require us to update a number of IS-IS documents. I would advice against that, but if the wg decides to do it try to help to get correct. For the time being I'd say that we want to allocate the code points from the "TLV Codepoints" reistry in the IS-IS TLV Codepoints" namespace. Doing that way it is also easier to find the correct registry. >/Loa Regards, Tony -- My mail server from time to time has come under DOS attacks, we are working to fix it but it may take some time. If you get denial of service sending to me plz try to use loa.pi.nu@gmail Loa Anderssonemail: l...@pi.nu Senior MPLS Expert Bronze Dragon Consulting phone: +46 739 81 21 64 ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] Question on the early allocation - Re: [IANA #1171772] Early Allocations request for "Area Proxy for IS-IS" - draft-li-lsr-isis-area-proxy-04
Tony, inline plz. On 02/06/2020 22:42, Tony Przygienda wrote: Loa, fair points though I would say adoption is kind of a different kettle of fish than early allocation. yeah - but the point I made, modulo some small updates in the IANA considerations I think the document is ready for wg adoption. And really the updates in the IANA considerations is strictly not necessary for wg adoption, but I prefer to have the IANA registries in scope clearly pointed out. RFC7120 does not seem to apply given ISIS registries are under expert review (largely due to historical reasons AFAIS). Yeah - you are right. I missed that, was to focused on the requirements in 7120. I watch that with lots of interest since due to customer discussions/(deployment) planning we request with experts early allocation for https://datatracker.ietf.org/doc/draft-przygienda-lsr-flood-reflection/ Yeah - you are requesting code points from registries where the registration procedures are "Expert Review". But those are not early allocation, they are permanent. We have however the benefit of not needing any new registries. Yes, that is a blessing, but for a new registry you can actually capture in the draft and populate it with code point values, the only thing is that once you put a value in there it should not be changed. Especially if you know of early implementations. For your draft the registries should be called: Sub-TLVs for TLV 242 (IS-IS Router CAPABILITY TLV); and Sub-TLVs for TLVs 22, 23, 25, 141, 222, and 223 (Extended IS reachability, IS Neighbor Attribute, L2 Bundle Member Attributes, inter-AS reachability information, MT-ISN, and MT IS Neighbor Attribute TLVs) (Don't blame me, I didn't name the registries :) ). and both registries are found in the IS-IS TLV Codepoints namespace. /Loa thanks -- tony On Tue, Jun 2, 2020 at 1:00 AM Loa Andersson <mailto:l...@pi.nu>> wrote: Folks, I have two questions on the early allocation. RFC 7120 allows early allocation for two types of The processes described below assume that the document in question is the product of an IETF Working Group (WG). If this is not the case, replace "WG chairs" below with "Shepherding Area Director". draft-li-lsr-isis-area-proxy is an individual document, i.e. not a product of a working group nor shepherded by an AD, and does not seem to meet the criteria for early allocation. Also. draft-li-lsr-isis-area-proxy request that IANA create a new registry, as far as I understand new registries can't be created through early allocation. It is hardly necessary. The code points are requested from "the IS-IS TLV Codepoints registry", howver the "IS-IS TLV Codepoints" is a name space with 14 different registries. I think the the registry you want to allocated code point from the "TLV Codepoints registry" Since the document, at least I read it, well meet the criteria for becoming a working document (minor update to the IANA section), I think that the easy way out is to start the working group adoption poll. /Loa On 02/06/2020 12:52, Tony Li wrote: > > Hi Amanda, > >> However, the IANA Considerations section is missing some information. >> How would we fill in the IIH, LSP, SNP, and Purge fields for the TLV >> Codepoint registrations? > > > We’ve addressed this in > https://tools.ietf.org/html/draft-li-lsr-isis-area-proxy-06.. > > Thanks, > Sarah & Tony > > > ___ > Lsr mailing list > Lsr@ietf.org <mailto:Lsr@ietf.org> > https://www.ietf.org/mailman/listinfo/lsr > -- My mail server from time to time has come under DOS attacks, we are working to fix it but it may take some time. If you get denial of service sending to me plz try to use loa.pi.nu@gmail Loa Andersson email: l...@pi.nu <mailto:l...@pi.nu> Senior MPLS Expert Bronze Dragon Consulting phone: +46 739 81 21 64 ___ Lsr mailing list Lsr@ietf.org <mailto:Lsr@ietf.org> https://www.ietf.org/mailman/listinfo/lsr ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr -- My mail server from time to time has come under DOS attacks, we are working to fix it but it may take some time. If you get denial of service sending to me plz try to use loa.pi.nu@gmail Loa Anderssonemail: l...@pi.nu Senior MPLS Expert Bronze Dragon Consulting phone: +46 739 81 21 64 ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] Question on the early allocation - Re: [IANA #1171772] Early Allocations request for "Area Proxy for IS-IS" - draft-li-lsr-isis-area-proxy-04
Tony, inline plz. On 02/06/2020 22:42, Tony Przygienda wrote: Loa, fair points though I would say adoption is kind of a different kettle of fish than early allocation. yeah - but the point I made, modulo some small updates in the IANA considerations I think the document is ready for wg adoption. And really the updates in the IANA considerations is strictly not necessary for wg adoption, but I prefer to have the IANA registries in scope clearly pointed out. RFC7120 does not seem to apply given ISIS registries are under expert review (largely due to historical reasons AFAIS). Yeah - you are right. I missed that, was to focused on the requirements in 7120. I watch that with lots of interest since due to customer discussions/(deployment) planning we request with experts early allocation for https://datatracker.ietf.org/doc/draft-przygienda-lsr-flood-reflection/ Yeah - you are requesting code points from registries where the registration procedures are "Expert Review"" We have however the benefit of not needing any new registries. Yes, that is a blessing, but for a new registry you can actually capture in the draft and populate it with code point values, the only thing is that once you put a value in there it should not be changed. Especially if you know of early implementations. For your draft the registries should be called: Sub-TLVs for TLV 242 (IS-IS Router CAPABILITY TLV); and Sub-TLVs for TLVs 22, 23, 25, 141, 222, and 223 (Extended IS reachability, IS Neighbor Attribute, L2 Bundle Member Attributes, inter-AS reachability information, MT-ISN, and MT IS Neighbor Attribute TLVs) (Don't blame me, I didn't name the registries :) ). and both registries are found in the IS-IS TLV Codepoints namespace. /Loa thanks -- tony On Tue, Jun 2, 2020 at 1:00 AM Loa Andersson <mailto:l...@pi.nu>> wrote: Folks, I have two questions on the early allocation. RFC 7120 allows early allocation for two types of The processes described below assume that the document in question is the product of an IETF Working Group (WG). If this is not the case, replace "WG chairs" below with "Shepherding Area Director". draft-li-lsr-isis-area-proxy is an individual document, i.e. not a product of a working group nor shepherded by an AD, and does not seem to meet the criteria for early allocation. Also. draft-li-lsr-isis-area-proxy request that IANA create a new registry, as far as I understand new registries can't be created through early allocation. It is hardly necessary. The code points are requested from "the IS-IS TLV Codepoints registry", howver the "IS-IS TLV Codepoints" is a name space with 14 different registries. I think the the registry you want to allocated code point from the "TLV Codepoints registry" Since the document, at least I read it, well meet the criteria for becoming a working document (minor update to the IANA section), I think that the easy way out is to start the working group adoption poll. /Loa On 02/06/2020 12:52, Tony Li wrote: > > Hi Amanda, > >> However, the IANA Considerations section is missing some information. >> How would we fill in the IIH, LSP, SNP, and Purge fields for the TLV >> Codepoint registrations? > > > We’ve addressed this in > https://tools.ietf.org/html/draft-li-lsr-isis-area-proxy-06.. > > Thanks, > Sarah & Tony > > > ___ > Lsr mailing list > Lsr@ietf.org <mailto:Lsr@ietf.org> > https://www.ietf.org/mailman/listinfo/lsr > -- My mail server from time to time has come under DOS attacks, we are working to fix it but it may take some time. If you get denial of service sending to me plz try to use loa.pi.nu@gmail Loa Andersson email: l...@pi.nu <mailto:l...@pi.nu> Senior MPLS Expert Bronze Dragon Consulting phone: +46 739 81 21 64 ___ Lsr mailing list Lsr@ietf.org <mailto:Lsr@ietf.org> https://www.ietf.org/mailman/listinfo/lsr ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr -- My mail server from time to time has come under DOS attacks, we are working to fix it but it may take some time. If you get denial of service sending to me plz try to use loa.pi.nu@gmail Loa Anderssonemail: l...@pi.nu Senior MPLS Expert Bronze Dragon Consulting phone: +46 739 81 21 64 ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
[Lsr] Question on the early allocation - Re: [IANA #1171772] Early Allocations request for "Area Proxy for IS-IS" - draft-li-lsr-isis-area-proxy-04
Folks, I have two questions on the early allocation. RFC 7120 allows early allocation for two types of The processes described below assume that the document in question is the product of an IETF Working Group (WG). If this is not the case, replace "WG chairs" below with "Shepherding Area Director". draft-li-lsr-isis-area-proxy is an individual document, i.e. not a product of a working group nor shepherded by an AD, and does not seem to meet the criteria for early allocation. Also. draft-li-lsr-isis-area-proxy request that IANA create a new registry, as far as I understand new registries can't be created through early allocation. It is hardly necessary. The code points are requested from "the IS-IS TLV Codepoints registry", howver the "IS-IS TLV Codepoints" is a name space with 14 different registries. I think the the registry you want to allocated code point from the "TLV Codepoints registry" Since the document, at least I read it, well meet the criteria for becoming a working document (minor update to the IANA section), I think that the easy way out is to start the working group adoption poll. /Loa On 02/06/2020 12:52, Tony Li wrote: Hi Amanda, However, the IANA Considerations section is missing some information. How would we fill in the IIH, LSP, SNP, and Purge fields for the TLV Codepoint registrations? We’ve addressed this in https://tools.ietf.org/html/draft-li-lsr-isis-area-proxy-06.. Thanks, Sarah & Tony ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr -- My mail server from time to time has come under DOS attacks, we are working to fix it but it may take some time. If you get denial of service sending to me plz try to use loa.pi.nu@gmail Loa Anderssonemail: l...@pi.nu Senior MPLS Expert Bronze Dragon Consulting phone: +46 739 81 21 64 ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] draft-ietf-ospf-lls-interface-id-04 Shepherd review
Folks, I agree - no reason to delay! There is one small difference between what is in the document and what is in the RFC I pointed to The document has "...as described in [BCP 14] [RFC2119] [RFC8174]..." While RFC has "...as described in BCP 14 [RFC2119] [RFC8174]..." The reference list in the RFC do not have BCP 14 listed as a reference. I don't know if this helps. Acee BCP 14 is both [RFC2119] and [RFC8174]. /Loa On 2018-07-09 14:29, Acee Lindem (acee) wrote: Hi Peter, Strange, I'd remove the reference to [BCP14] since RFC 8174 and BCP 14 are the same document. I'm going to request publication as this certainly isn't enough to delay for an update. Thanks, Acee On 7/9/18, 8:26 AM, "Peter Psenak (ppsenak)" wrote: Hi Acee, that is exactly what I have in the draft. thanks, Peter On 09/07/18 13:36 , Acee Lindem (acee) wrote: > Hi Peter, > > The new boiler plate for requirements language, with references to both RFC 2119 and RFC 8174, is: > > > 1.1. Requirements Language > > The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", > "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and > "OPTIONAL" in this document are to be interpreted as described in BCP > 14 [RFC2119] [RFC8174] when, and only when, they appear in all > capitals, as shown here. > > > This should resolve the IDNITS warning. > > Thanks, > Acee > > On 7/9/18, 5:14 AM, "Peter Psenak (ppsenak)" wrote: > > Hi Yingzhen, > > thanks for your review. > > As regards to first IDNITS warning, not sure about the first one, I took > the section "Requirements Language" from RFC8395 as suggested by Loa. > RFC2119 is only referenced there, that should not be a problem though. > > I removed the reference to ISO10589. > > thanks, > Peter > > On 09/07/18 00:41 , Yingzhen Qu wrote: > > Dear authors, > > > > I have done shepherd review of draft-ietf-ospf-lls-id-04 as requested by > > LSR chairs. I’d like to thank all authors for their contributions on > > this document, also people who have reviewed this document and provided > > valuable comments and discussions. > > > > The document is well written and ready for publication. > > > > IDNITS check found a couple of nits: > > > >Miscellaneous warnings: > > > > > > > > > >** The document contains RFC2119-like boilerplate, but doesn't seem to > > > > mention RFC 2119. The boilerplate contains a reference [BCP14], > > but that > > > > reference does not seem to mention RFC 2119 either. > > > >-- The document date (July 1, 2018) is 7 days in the past. Is this > > > > intentional? > > > >Checking references for intended status: Proposed Standard > > > > > > > > > > (See RFCs 3967 and 4897 for information about using normative > > references > > > > to lower-maturity documents in RFCs) > > > >== Unused Reference: 'ISO10589' is defined on line 200, but no explicit > > > > reference was found in the text > > > > '[ISO10589] International Organization for Standardization, > > "Intermed...' > > > >-- Possible downref: Non-RFC (?) normative reference: ref. 'BCP14' > > > >-- Possible downref: Non-RFC (?) normative reference: ref. 'ISO10589' > > > > Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 3 comments (--). > > > > > > > > Thanks, > > > > Yingzhen > > > > > ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr -- Loa Anderssonemail: l...@pi.nu Senior MPLS Expert Bronze Dragon Consulting phone: +46 739 81 21 64 ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
[Lsr] Early review of draft-ietf-ospf-lls-interface-id
To: foo-wg-chairs@…; draft-foo-name.all@…; Cc: rtg-dir@…; foo-wg-mailing-list; Subject: RtgDir Early review: draft-ietf-ospf-lls-interface-id-03.txt Hello I have been selected to do a routing directorate “early” review of this draft. https://datatracker.ietf.org/doc/draft-ietf-ospf-lls-interface-id/ The routing directorate will, on request from the working group chair, perform an “early” review of a draft before it is submitted for publication to the IESG. The early review can be performed at any time during the draft’s lifetime as a working group document. The purpose of the early review depends on the stage that the document has reached. As this document is close to working group last call, my focus for the review was to determine whether the document is ready to be published. Please consider my comments along with the other working group last call comments. For more information about the Routing Directorate, please see http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir Document: draft-ietf-ospf-lls-interface-id-03.txt Reviewer: Loa Andersson Review Date: 2018-06-29 Intended Status: Standards track Summary: No issues found. This document is basically ready for publication, but has nits that should be considered prior to being submitted to the IESG. I have gathered the nits in a word file that has been sent to the authors and chairs. I also recommend that the authors take a look at my proposed change to the IANA section. Nits: The nits found is that the Abstract is too raw, but as sufficient info are available in the Introduction, this should be a simple editorial change. There is one sentence at the end of section that I think is ambigious. But I leave it to the authors to update if they think it is necessary. LSA is actually not a well-know abbreviation, and should be expanded. However, I think it should be well-know, since this is within the purview of the LSR chairs, I leave to them to take necessary actions if they see fit. I have suggested some editorial changes to the IANA considerations. /Loa -- Loa Anderssonemail: l...@pi.nu Senior MPLS Expert Bronze Dragon Consulting phone: +46 739 81 21 64 ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
