Thanks for the ping, Acee.
Looking at the latest version I have one question. The revised Section 6.2.2
says,
Whereas flow control prevents the sender from overwhelming the
receiver, congestion control prevents senders from overwhelming the
network. For an IS-IS adjacency, the netw
Sent: Thursday, April 11, 2024 11:53 AM
To: Zaheduzzaman Sarker
mailto:zahed.sarker.i...@gmail.com>>;
lsr-cha...@ietf.org<mailto:lsr-cha...@ietf.org>; John Scudder - Juniper
(j...@juniper.net<mailto:j...@juniper.net>)
mailto:j...@juniper.net>>
Cc: Zaheduzzaman Sarker
mai
get your
> agreement on the revised text for that section - it was not intended to
> address other editorial issues (such as revising related section names) -
> which we will certainly do when generating an updated version.
> A few more comments inline.
>
>> -Original Me
Hi Zahed,
I’m sure Les will reply as soon as his TZ allows him adequate caffeination :-).
To jump-start things, though, a couple questions/comments below.
> On Apr 9, 2024, at 5:49 AM, Zaheduzzaman Sarker
> wrote:
>
> Thanks for taking the stab, it is a good start but no quite there yet.
>
>
P. S. With this change I guess you’d also want to change “algorithm 1” to just
“algorithm.”
—John
On Apr 5, 2024, at 4:33 PM, John Scudder wrote:
[External Email. Be cautious of content]
Thanks, Les. LGTM. It’s late in Zahed’s TZ so I’m guessing he might not get
back to us until Monday
keeping pace with the rate of LSPs transmitted.
In the absence of an advertisement of partialSNPInterval, a locally
configured value can be used.
From: John Scudder mailto:j...@juniper.net>>
Sent: Friday, April 5, 2024 9:37 AM
To: Zaheduzzaman Sarker
mailto:zahed.sarker.i...@gmail.com>
reflects the
intention clearly and matches with the section title change. I can have a look
if there is any proposed changes.
//Zahed
On Fri, Apr 5, 2024 at 3:00 PM John Scudder
mailto:j...@juniper.net>> wrote:
Hi Les,
On Apr 5, 2024, at 12:17 AM, Les Ginsberg (ginsberg)
mailto:ginsb...@cis
Hi Les,
On Apr 5, 2024, at 12:17 AM, Les Ginsberg (ginsberg) wrote:
John – I am not entirely clear on what would address your comment. Would
replacing “algorithm” with “approach” in Section 6.3.2 be satisfactory?
I think so, with the exception of “there is no requirement or intent to
standard
updated response after rereading those
paragraphs.
John – I am not entirely clear on what would address your comment. Would
replacing “algorithm” with “approach” in Section 6.3.2 be satisfactory?
Les
From: John Scudder
Sent: Thursday, April 4, 2024 6:59 AM
To: Zaheduzzaman Sarker
Cc: The IESG
Hi Zahed,
I guess the authors should respond comprehensively. I do have one response to
your comments on algorithm 2, though. They seem to boil down to your first
comment, "Can we really call congestion control algorithm 2 a congestion
control algorithm?” It seems to me, on looking at the docum
Regarding whether it should be verified or HFDU, I haven’t taken a hard look
yet. The operative question from the guidance [1] though, is if the change
corrects “errors at the time the document was published”.
The guidance is necessarily not completely prescriptive and my impression is
that the
. My comments continue to apply to centralized mode,
though.
Thanks,
--John
> On Feb 6, 2024, at 8:52 PM, John Scudder
> wrote:
>
> ### Section 6.7
>
> I had asked about old vs. new topologies. Your new version has this:
>
> In centralized mode, trans
Hi Tony,
> On Feb 6, 2024, at 7:43 PM, Tony Li wrote:
>
> Thank you for your fantastic comments. Please see inline.
You’re welcome and thank you for your careful reply, and also for the
additional polishing. I’ve just reviewed the diff, it looks good. Just a few
things to note in the revisio
Hi All,
I reviewed the diffs from 05 to 06 and the email; looks good to me, thank you.
I see that there is an active discussion going on about Mirja Kühlewind’s
TSVART review of 06. It seems to me it would probably be better to let that
play out before sending the document for IETF Last Call. S
Hi Acee, Roman, all,
[top posting, hope that’s OK]
After talking with Roman about this today, what I understand his position to be
is (at least in part), since the document identifies one specific case of a
type of attack ("The ability to disable OSPFv3 Extended LSA support can result
in a den
On Jan 24, 2024, at 12:51 PM, bruno.decra...@orange.com wrote:
>
> as a correction we are proposing the following two changes
Looks good to me.
—John
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr
Hi Authors,
This isn't a full review of your document, however, I was looking at it and
noticed that in the IANA section, you create two registries with the "expert
review" policy. RFC 8126 says that you need to provide guidance to the
designated experts for such registries. If you plan on havi
is merited, of course) is a
draft to update or replace the base spec.”
In short, “never mind!”
—John
> On Jan 11, 2024, at 2:24 PM, John Scudder wrote:
>
> Hi Acee, WG,
>
> I'm convinced this doesn't meet the criteria to be verified as a technical
> erratum. I am
Actually, upon reviewing this one, I'm leaning back toward simply rejecting
both this erratum and erratum 7644. As we discussed earlier in the thread on
this one, the best fix (assuming the working group agrees is a fix is merited,
of course) is a draft to update or replace the base spec.
—John
Hi Acee, WG,
I'm convinced this doesn't meet the criteria to be verified as a technical
erratum. I am considering verifying it as "Hold for Document Update”, though.
The definition for HFDU is "The erratum is not a necessary update to the RFC.
However, any future update of the document might co
Hi All,
Thanks for the easy review, basically LGTM. I have just a few nits, below. I'll
hold off on sending the doc for IETF LC for a short time, in case you want to
fix these first. (It would be OK to send the current version, but IMO you might
as well do another revision since GENART or other
Hi Hannes,
Thanks for pointing this out:
> On Dec 7, 2023, at 4:38 AM, Hannes Gredler
> wrote:
>
> We have used similar textblocks for the OSPFv2 and OSPFv3 SR extensions and I
> am not aware
> of any questions from implementators around ambiguity.
I checked RFCs 8665 and 8666, and they don'
Hi Acee,
> On Dec 7, 2023, at 3:44 PM, Acee Lindem wrote:
>
> We’ll probably never BIS these RFCs but I would agree that it would be good
> for one of the RFC authors to provide a clearer definition of the
> relationship between the L flag, V flag, TLV length, and TLV values (label,
> index,
Hi Tony,
Thanks for your prompt reply. I can live with most of that, just a few
follow-ups below.
> On Dec 7, 2023, at 3:45 PM, Tony Li wrote:
>
> Hi John,
>
> Thank you for your comments and suggestions. I’m incorporating most of
> them
Cool. Looking forward to reviewing version 10.
> and
Hi Les,
> On Dec 7, 2023, at 4:03 PM, Les Ginsberg (ginsberg)
> wrote:
>
> Let's be careful here.
Certainly. I don't think we've been proceeding recklessly so far, have we?
> SR-MPLS has been deployed for several years, there are multiple
> implementations which have demonstrated interoperab
Hi Hannes,
> On Dec 7, 2023, at 4:38 AM, Hannes Gredler
> wrote:
>
> We have used similar textblocks for the OSPFv2 and OSPFv3 SR extensions and I
> am not aware
> of any questions from implementators around ambiguity.
Thanks for the pointer, I’ll take a look at those, too.
> IMO there is cl
-Flag are set to 1:
> The SID/Index/Label field is a 3-octet local label where the 20 rightmost
> bits are used for encoding the label value.
>
> Do you still believe some change/clarification is needed?
>
>Les
>
> > -Original Message-
> > From
Hi Authors and Contributors who "should be considered as coauthors”,
Your RFC defines the SID/Index/Label field of the Prefix Segment Identifier
(Prefix-SID) Sub-TLV, in Section 2.1, as:
SID/Index/Label as defined in Section 2.1.1.1.
But when I look at Section 2.1.1.1 I see that it define
Hi Aijun,
I apologize for the length of time it’s taken me to respond to your request.
Having now taken the time to study the question properly, including a review of
both drafts in question, the WG adoption call, and the subsequent email, here’s
my take.
In large part, your position appears
Without commenting on the other aspects,
> On Sep 20, 2023, at 3:34 PM, Tony Przygienda wrote:
>
> 3. the MTU "largest datagram" needs to be errate'd to something more precise
> on top.
Generally, errata are not the right way to fix “this is underspecified” kinds
of problems. The right way is
Tom is right of course, and thank you for pointing it out. (The specific
section in RFC 2026 to look at is 6.5.1.)
In the meantime, I’ll review the mailing list discussion. However, the most
desirable outcome would be to settle things at the WG level without further
escalation.
—John
> On Sep
#PP):
>
> On 27/06/2023 17:48, John Scudder wrote:
> > Hi Authors,
> >
> > I don’t think we’ve completely closed on this. Zahed is asking for Section
> > 3 to be tightened a little bit. The authors haven’t either said “no we
> > won’t” or proposed text. In ho
-Algorithm is:
* Able to compute a path for such Flex-Algorithm
* Part of the topology for such Flex-Algorithm
(Adds the indefinite article in two places, changes definite article to
indefinite in one place.)
Thanks,
—John
> On Jun 9, 2023, at 11:30 AM, John Scudder
> wrote:
>
Ok.
—John
On Jun 9, 2023, at 11:28 AM, Zaheduzzaman Sarker
wrote:
[External Email. Be cautious of content]
On Thu, 8 Jun 2023 at 15:09, John Scudder
mailto:j...@juniper.net>> wrote:
Hi Zahed,
> On Jun 8, 2023, at 6:42 AM, Zaheduzzaman Sarker
> mailto:zahed.sarker.i.
Hi Zahed,
> On Jun 8, 2023, at 6:42 AM, Zaheduzzaman Sarker
> wrote:
>
> I can help with text if I can understand use case better. Right now that is
> not the case.
Do you understand the use case and intent of the section well enough now that
you’d be able to propose text?
Thanks,
—John
__
Hi Peter and all,
> On Jun 8, 2023, at 2:43 AM, Peter Psenak
> wrote:
>
>> A node MUST participate in a Flex-Algorithm to be:
>> - Able to compute path for such Flex-Algorithm
>> - Part of the topology for such Flex-Algorithm
>>
>> This is an odd use of MUST.
>
> what
> On May 25, 2023, at 11:53 AM, tom petch wrote:
>
> We want to keep these down references and update these documents as well. I
> don’t know what the DOWNREF registry is.
>
>
> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/downref/__;!!NEt6yMaO-gk!EFkdlgJWZLwuWb0cM-xrtJ9oKP-eu5
> On May 25, 2023, at 10:39 AM, Acee Lindem wrote:
>
> Please note that RFCs should use US English as opposed British English. See
> section 3.1 of RFC 7322.
Correct citation, slightly inaccurate summary — either US English or British
English is OK, but it MUST be all one or all the other, and
I have an elaboration on one of Jim’s points:
> On May 24, 2023, at 12:23 PM, Jim Guichard via Datatracker
> wrote:
>
> - Section 7.1 SRv6 Locator TLV:
>
>- The text 'Locator continued..' in Figure 5 might be confusing as perhaps
>it is just me but when I initially read it, I thought t
John Scudder has entered the following ballot position for
draft-ietf-lsr-ospfv3-srv6-extensions-11: Yes
When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)
Please refer
Hi Authors (and cc WG),
I see there were some changes that were agreed during IETF LC. It would be
great if you could issue a new version incorporating those before IESG
evaluation; in the meantime, I’ve issued the ballot. I expect this will be on
the June 8 IESG agenda.
Thanks,
—John
> On M
That seems reasonable.
Les, I encourage you not to wait for the end of IESG review to make the change,
if you’re going to — maybe it will help someone else even though Warren did
extra work (sorry Warren, I tried).
—John
On May 18, 2023, at 3:54 PM, Warren Kumari wrote:
On Thu, May 18, 2
Hi Authors, WG,
Looks like the IETF LC went fine, I’ve issued the ballot for this document.
Note that the May 25 telechat agenda is already full so I anticipate this will
be on the June 8 telechat.
It looks like there were some editorial points raised in the genart review,
please consider pos
> On May 3, 2023, at 11:04 AM, Les Ginsberg (ginsberg)
> wrote:
>
>> 2) Please reconsider the link to the mailarchive in the RFC. Put it in the
>> shepherd writeup or in the history in the datatracker as a comment (chairs
>> can
>> do this). Otherwise it adds to the list of URLs that we have to
;
> Hi John,
>
> I apologize for the misses, likely the result of multiple editors
> updating the draft in parallel.
>
> I also fixed the nits and updated the security sections as you proposed.
>
> Version 10 has been published.
>
> thanks,
> Peter
>
>
Hi Ketan,
> On May 2, 2023, at 11:46 AM, Ketan Talaulikar wrote:
[omitting agreed points that don’t need further discussion]
> > @@ -825,6 +988,9 @@
> > one neighbor. Thus multiple instances of the SRv6 End.X SID and SRv6
> > LAN End.X SID Sub-TLVs MAY be advertised within the E-Router
r IS-IS as to whether this duplication is addressed in
> IS-IS specifications.
>
> Thanks,
> Acee
>
>> On Apr 28, 2023, at 9:13 AM, Peter Psenak
>> wrote:
>>
>> Hi John,
>>
>> Shradha and I have worked to address your comments.
>> Th
Hi Ketan,
Thanks for your careful answers.
> On Apr 27, 2023, at 12:35 PM, Ketan Talaulikar wrote:
…
> @@ -245,6 +260,12 @@
>
> The SRv6 Capabilities TLV may contain optional Sub-TLVs. No Sub-TLVs
> are defined in this specification.
> +---
> +jgs: Thank you for setting up registry c
On Apr 20, 2023, at 1:24 PM, Peter Psenak wrote:
>
> Hi John,
>
> I usually push txt version and give XML only to RFC Editors.
I used to do that too. Also for no particular reason, just habit I guess.
> No particular reason, I can upload XML next time.
Thanks! It’s not a huge difference for m
l>
[apple-touch-icon.png]<https://www.iana.org/assignments/isis-tlv-codepoints/isis-tlv-codepoints.xhtml>
—John
On Apr 20, 2023, at 12:04 PM, tom petch wrote:
From: John Scudder
Sent: 20 April 2023 13:45
To: tom petch
Cc: cho...@chopps.org; draft-ietf-lsr-rfc8919...@ietf.org; lsr-cha...
Hi Les,
> On Apr 20, 2023, at 10:43 AM, Les Ginsberg (ginsberg)
> wrote:
>
> Also to John - if you have provided a review of the bis draft (as you suggest
> below) I don’t seem to have seen it.
> Did you send it to the list?? Or are you referring to your comments from last
> year which result
[adding individual cc for authors to work around bounce issues]
One additional request — when you post your next revision, unless you have some
specific reason NOT to upload the XML, please do that? It appears that for
version 08 you only uploaded the txt rendering, which means there’s no native
Hi Tom,
Thanks for catching this, sorry I missed it in my review. The registry is now
named "IS-IS Sub-TLVs for Application-Specific SRLG TLV”, so,
OLD:
7.5. Sub-TLVs for TLV 238 Registry
IANA has created a new registry titled "Sub-TLVs for TLV 238" under
the "IS-IS TLV Codepoints" regis
Verified. Also, note taken that it’s important to do a complete review of the
updates to the document before signing off on AUTH48 — the RFC Editor,
wonderful though they are, are not subject matter experts and they can and do
occasionally make these kinds of mistakes through no fault of their o
n – whatever you want to do here is fine – but I think your statement “the
> lack of expansion confused at least one person” is being overly generous in
> this case.
>
> Les
>
> From: Lsr On Behalf Of John Scudder
> Sent: Monday, March 6, 2023 4:57 AM
> To: Acee
“Hold For Document Update” is exactly for the purpose [1] of making nominal but
inessential improvements. This one seems roughly on the level of “trivial
grammar correction” (item 4 of [1]) which is in-scope for HFDU, and apparently
the lack of expansion confused at least one person, so I’m incl
> On Dec 15, 2022, at 8:45 AM, Acee Lindem wrote:
>
> Section 2 defines the flags field in the OSPFv3 SR capabilities TLV. I don’t
> see an IANA registry defined for these flags.
Yes exactly. So, note to whoever does have the pen, please add that registry.
(And I dropped the srv6-extensions au
> John,
>
> On 14/12/2022 22:59, John Scudder wrote:
>> Hi Authors, WG,
>>
>> As part of my review of draft-ietf-idr-bgpls-srv6-ext-12 I was looking at
>> these documents and came up with a few comments that would otherwise become
>> part of my AD review for o
Hi Authors, WG,
As part of my review of draft-ietf-idr-bgpls-srv6-ext-12 I was looking at these
documents and came up with a few comments that would otherwise become part of
my AD review for ospfv3-srv6-extensions, so I thought I’d share them now.
draft-ietf-lsr-isis-srv6-extensions-19 is curre
Hi Lars,
There has been considerable discussion about the WG’s reason for structuring
the document this way, and helpful updates made to the current document. I
think we can conclude, or at least I conclude, that this was done with
considered intent and for good reasons.
Do you feel your DISCU
ad so they can also check/review
> the same.
>
> Thanks,
> Ketan
>
>
> On Thu, Oct 6, 2022 at 6:37 PM John Scudder wrote:
> Hi Ketan,
>
> Thanks for the analysis. A few comments below.
>
> > On Oct 6, 2022, at 8:30 AM, Ketan Talaulikar wrote:
> >
Thanks for the review, Rich. One tiny nit, mostly for the authors:
> On Oct 3, 2022, at 12:23 PM, Rich Salz via Datatracker
> wrote:
>
> s/could be in most extreme case/could be in THE most extreme case/
Please don’t put “the” in all caps when you do the edit. Even though there’s no
formal re
provide a pointer to the text for each inline
> below. I am not sure that I understand option 3 very well.
>
>
> On Wed, Oct 5, 2022 at 9:42 PM John Scudder wrote:
> Hi All,
>
> (To keep everyone in the loop since you weren’t all on the cc of the IANA
> review email.
Silly me,
> On Oct 5, 2022, at 2:17 PM, John Scudder wrote:
>
> see that warning from idnits pretty often too, I don’t know what triggers it,
… it’s right there in the warning:
(Using the creation date from RFC5088, updated by this document, for
RFC5378 checks: 2006-09-20
Hi Dhruv,
> On Oct 5, 2022, at 1:13 PM, Dhruv Dhody wrote:
>
> Yes, none of the changes require it!
> But this existing idnits warning made sense to me and thus I added the
> disclaimer. Let me know if that is a mistake, I can revert!
Is there actually pre-2008 material in the draft? I didn
Hi All,
(To keep everyone in the loop since you weren’t all on the cc of the IANA
review email.)
Amanda Baber at IANA pointed out that the added paragraph is a problem for IANA
since it’s too imprecise for IANA to carry out. The options come down to:
1. Revisit the WG decision, and add a field
t; Cc: The IESG ,
> "draft-ietf-lsr-pce-discovery-security-supp...@ietf.org"
> ,
> "lsr-cha...@ietf.org" , "lsr@ietf.org" ,
> Acee Lindem , "p...@ietf.org" , "Les Ginsberg
> (ginsberg)" , Adrian Farrel , John
> Scudder , Roman Dan
Hi Acee,
> On Oct 4, 2022, at 12:57 PM, Acee Lindem (acee)
> wrote:
>
>> From: "Rob Wilton (rwilton)"
...
>> Is there somewhere for these new config knobs are being tracked - so that
>> they don’t get forgotten?
>
> We have the Datatracker for that…
I don’t follow — what datatracker featur
ver the
> PCEP security support prior to establishing a PCEP session. The restrictions
> defined in [RFC5089][RFC5089] should still be considered to be in place."
>
> which is an accurate summary.
>
> Hard for me to justify modifying RFC 5088/5089 simply to add a pointe
GHtry0Z17ASBG2PUMF_yYzechg$
> ).
>
> Thanks,
> Acee
>
> On 10/4/22, 1:29 PM, "John Scudder" wrote:
>
>Hi Everyone,
>
>+Adrian since he appears to have been the shepherd for RFC 5088, which is
> the root of Lars’ DISCUSS.
>+Hannes, L
Hi Everyone,
+Adrian since he appears to have been the shepherd for RFC 5088, which is the
root of Lars’ DISCUSS.
+Hannes, Les, JP, Meral as people who may have more context on the question
Since I haven’t seen any replies to this DISCUSS yet I did a little digging.
The text in question:
No
Hi Les and other authors,
I didn’t see a reply to Murray’s comment. It’s not a DISCUSS so not mandatory
for you to reply but it would be appreciated.
Of Murray’s comments, I personally don’t think RFC 7981 needs to be normative,
the test being that if you never looked at 7981 you’d still know h
> On Sep 24, 2022, at 3:55 AM, Dan Romascanu via Datatracker
> wrote:
>
> I would also suggest sending the document for review to the IEEE 802.1 WG via
> the IETF-IEEE coordination team.
N.b. I’ve pinged the coordination team leads and 802.1 liaison manager with
this suggestion.
Thanks,
—Jo
> wrote:
>
>
> Tom -
>
> > -Original Message-
> > From: t petch
> > Sent: Wednesday, September 21, 2022 3:45 AM
> > To: Les Ginsberg (ginsberg) ; John Scudder
> >
> > Cc: Eric Vyncke (evyncke) ; The IESG ;
> > draft-ietf-lsr-
Hi Tom,
Thanks for your comments!
> On Sep 16, 2022, at 11:56 AM, t petch wrote:
>
> On 16/09/2022 14:13, John Scudder wrote:
>> Hi Éric,
>>
>> A few comments below.
>>
>>> On Sep 16, 2022, at 4:27 AM, Éric Vyncke via Datatracker
>>> w
Hi Éric,
A few comments below.
> On Sep 16, 2022, at 4:27 AM, Éric Vyncke via Datatracker
> wrote:
>
> ## COMMENTS
>
> ### Section 3.1
>
> ```
> The Router ID field of the inter-AS reachability TLV is 4 octets in
> length, which contains the IPv4 Router ID of the router who generates
>
Make it so. ;-)
—John
> On Sep 13, 2022, at 8:11 PM, Amanda Baber via RT
> wrote:
>
> [External Email. Be cautious of content]
>
>
> Hi John,
>
> As the AD for this document, can you approve this early allocation request?
>
> Document:
> https://urldefense.com/v3/__https://datatracker.ie
ote:
>
> From: Lsr on behalf of John Scudder
>
> Sent: 06 September 2022 22:04
>
>> On Sep 6, 2022, at 5:00 PM, Acee Lindem (acee) wrote:
>>
>> I guess if we do decide to either abandon the reorganization suggestion
>> altogether, or to pursue it as
Hi Peter,
Thanks. I’ve requested IETF LC.
—John
> On Sep 12, 2022, at 7:36 AM, Peter Psenak wrote:
>
>
> Hi John,
>
> please see inline (##PP2)
>
> On 09/09/2022 17:29, John Scudder wrote:
>> Hi Peter,
>>
>> Thanks for your reply and for the pi
> On Sep 6, 2022, at 5:00 PM, Acee Lindem (acee) wrote:
>
>I guess if we do decide to either abandon the reorganization suggestion
> altogether, or to pursue it as a separate draft, then
> draft-ietf-lsr-ospf-l2bundles should just stick to its existing approach of
> listing restrictions in
Hi Acee,
> On Sep 5, 2022, at 1:23 PM, Acee Lindem (acee) wrote:
>
> First of all, I think this IANA OSPFv3 Extended-LSA Sub-TLV specification, if
> it is to be done at all, should be done in a separate draft.
I guess by “specification” you mean “registry reorganization”, right? I’m OK
with t
iff below:
> https://urldefense.com/v3/__https://www.ietf.org/rfcdiff?url2=draft-ietf-lsr-pce-discovery-security-support-10__;!!NEt6yMaO-gk!HwD1Ifh0JYKZJd08a0_G-rVhAdKeeLZpK7-YXH9YdLqDvEzqivIQ2g6vRxWDh2c_dlPglDDYH3qcYVer_d9zLGutJPam$
>
> -Qin (on behalf of authors)
> -邮件原件-
> 发件人: J
Hi Ketan,
Seems like a good plan. Comments below.
> On Sep 5, 2022, at 3:31 AM, Ketan Talaulikar wrote:
>
> I am personally OK with adopting the "boy scout" approach here - even if it
> might be seen as a scope creep.
>
> Following is a proposal for feedback from you and the WG:
>
> We'll f
Hi Qin and all,
Looks like we’ve agreed on all the points under discussion, I’ll look forward
to reviewing the next revision.
Thanks,
—John
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr
LV to L2 Bundle Member TLV.
>
> I am open to your and WG's suggestions on this.
I, too, would like to hear the WG’s input.
Thanks,
—John
>
> Thanks,
> Ketan
>
>
> On Fri, Sep 2, 2022 at 10:23 PM John Scudder wrote:
> Hi Ketan,
>
> Thanks for the upd
ve also posted an update with the changes discussed below:
> https://datatracker.ietf.org/doc/html/draft-ietf-lsr-ospf-reverse-metric-07
>
>
> On Sat, Sep 3, 2022 at 1:03 AM John Scudder wrote:
> Hi Ketan,
>
> LGTM generally. Regarding your uses of SHOULD, the updates to refe
trict-mode-07
>
>
> On Sat, Sep 3, 2022 at 2:06 AM John Scudder wrote:
> Hi Ketan,
>
> My comments in line below.
>
> > On Sep 2, 2022, at 6:37 AM, Ketan Talaulikar wrote:
> >
> > Hi John,
> >
> > Please check inline below for responses with
Hi Ketan,
My comments in line below.
> On Sep 2, 2022, at 6:37 AM, Ketan Talaulikar wrote:
>
> Hi John,
>
> Please check inline below for responses with KT2
>
>
> On Thu, Sep 1, 2022 at 10:42 PM John Scudder wrote:
> Hi Ketan,
>
> Thanks for the prompt
Hi Ketan,
LGTM generally. Regarding your uses of SHOULD, the updates to refer to Section
7 are helpful. I agree that the other uses are innocuous enough as to be
obvious to “one versed in the art”; we shall see if other reviewers agree. I
personally am not crazy about RFC 2119 keywords directed
Hi Ketan,
Thanks for the update.
> On Sep 2, 2022, at 9:16 AM, Ketan Talaulikar wrote:
>
> Since the OSPFv3 registry is shared for all OSPFv3 Extended LSA TLVs'
> sub-TLVs, we need another flag X for those sub-TLVs that are not associated
> with the Router Link TLV.
Good point. But, doesn’t
This looks right. If there are any objections to verifying it, please let me
know.
—John
> On Sep 1, 2022, at 2:39 PM, RFC Errata System
> wrote:
>
>
> The following errata report has been submitted for RFC2328,
> "OSPF Version 2".
>
> --
> You may review
Hi Ketan,
Thanks for the prompt update. I have one question about your edits. In Section
6, I had suggested
OLD:
Implementations MAY
provide a local configuration option to specifically enable BFD
operation in OSPF BFD strict-mode only.
NEW (my suggestion):
Implementations MAY
p
Dear Authors,
Thanks for this short, clean, document. I have no nits (!!) and only one
substantive comment to discuss.
In Figures 2 and 3, you annotate all the sub-TLVs from the relevant OSPFv2 and
OSPFv3 registries, to indicate whether those sub-TLVs are, or are not,
applicable in the context
Hi Qin,
Thanks for your reply, and Dhruv, Acee, and Les for your subsequent remarks.
I’m rolling all my comments together into this reply to Qin’s message. Anything
that’s settled I’ve snipped out, remaining items discussed in line.
> On Aug 25, 2022, at 5:21 AM, Qin Wu
> wrote:
[snip]
> +j
Les, thanks for the followup, and the sanity-check.
> On Aug 26, 2022, at 3:04 PM, Les Ginsberg (ginsberg)
> wrote:
>
> Rather than do what John suggests below (have two lengths in the encoding),
> please define distinct formats for each protocol.
> This should be done for the KEY-ID sub-TLV a
few additional format diffs were introduced by the new author
> tools (not directly by me).
>
> Les
>
>> -Original Message-
>> From: John Scudder
>> Sent: Thursday, August 18, 2022 8:46 AM
>> To: Les Ginsberg (ginsberg)
>> Cc: draft-ietf-lsr-isi
Hi Acee,
> On Aug 18, 2022, at 1:10 PM, Acee Lindem (acee)
> wrote:
>
> Speaking as Document Shepherd:
>
> Hi John,
>
> Thanks much for your review and suggested text. I think these will improve
> the both the precision of the specification and the readability. I read
> though the commen
Hi Les,
Thanks for your prompt reply. My comments in line below.
> On Aug 18, 2022, at 12:49 AM, Les Ginsberg (ginsberg)
> wrote:
[snipped]
> I have a couple of other points I’ll raise here instead of in line.
>
> 1. I was a little surprised in the Acknowledgements to see that Les is
> than
Hi Authors,
Thanks for your patience as this clean and easy-to-review document sat in my
queue for too long. :-( Here’s my review.
I’ve supplied my comments in the form of an edited copy of the draft. Minor
editorial suggestions (including at least two reversions to the language of the
base do
Thanks. Approved.
—John
On Jul 8, 2022, at 7:25 PM, Acee Lindem (acee) wrote:
Hi John,
From: John Scudder
Date: Friday, July 8, 2022 at 7:13 PM
To: Acee Lindem
Cc: IANA , lsr ,
draft-ietf-lsr-ospfv3-srv6-extensions
Subject: Re: Early allocation request for code points in
draft-ietf
1 - 100 of 129 matches
Mail list logo
