RFC Editor state is MISSREF, as part of cluster C336:
https://www.rfc-editor.org/cluster_info.php?cid=C336. If I’m untangling the
information there correctly, I think it’s blocked on (at least)
draft-ietf-teas-yang-te.
Was the surgery that Tom mentions, expected to clear it out of MISSREF? If s
Thanks, Mahesh.
> On Jul 27, 2021, at 3:52 PM, Mahesh Jethanandani
> wrote:
>
> The surgery that I performed on the draft, and can be seen in the attached
> files both as a diff and the full file was to remove the mpls-te module
> dependency from this draft. We should therefore at least not b
-rfc-editor
-dward’s old address
This erratum proposes changing “is not equal” to “is not match”. As far as I
can tell would make the text less, not more, precise. I’m going to reject it.
Submitter, if you still feel there is a problem, you can either open a new
erratum expressing your point mo
Hi Folks,
I’ like to thank Glebs for the well-written and researched erratum. I’d like
to engage the WG and authors before moving this one along.
AFAICT (and I am not as expert in the subject as some of you are), the erratum
is correcting a legit bug in the spec. My concern is that as the subm
The same questions and comments apply to this one as to erratum 7082, see
https://mailarchive.ietf.org/arch/msg/rtg-bfd/Q1vE1DLSTPJmYDscTEiF6QHUwgU/
—John
> On Aug 12, 2022, at 10:19 AM, RFC Errata System
> wrote:
>
> The following errata report has been submitted for RFC5880,
> "Bidirectiona
> On Oct 19, 2022, at 2:14 PM, Reshad Rahman wrote:
>
> As Mahesh has replied, we can't do this as an erratum. Doing a new document
> with a module which augments ietf-bfd-lag would be the easiest solution, but
> I don't think it's the way to go. A bis of 9314 is more appropriate.
Maybe we sho
below , co-authors please keep me honest.
>
> Regards,
> Reshad.
>
> On Tuesday, August 23, 2022, 12:40:46 PM EDT, John Scudder
> wrote:
>
>
> Dear Authors,
>
> Thanks for your patience. Here’s my review of your document. There are some
> questions I’ve raised that will need some discussion before I can be sure
> I’ve properly understood the doc.
>
[… snip …]
> One change from prior discussions is that we have decided not to address
> multi-hop for security reasons.
>
> Regards,
> Reshad.
>
> On Monday, October 24, 2022, 10:32:47 AM EDT, John Scudder
> wrote:
>
>
> Hi Reshad,
>
> Thanks for your reply.
Hi Folks,
There don’t appear to be any show-stoppers in Magnus’s review so I’ve gone
ahead and requested to place this on the December 15 IESG agenda. However,
please do follow up with Magnus and push a new version if appropriate.
Thanks,
—John
> On Nov 14, 2022, at 8:18 AM, Magnus Westerlund
Hi Everyone,
I plan to verify this in the near future (let’s say, Monday Feb 13) unless
anyone objects.
Thanks,
—John
> On Nov 6, 2022, at 4:27 AM, RFC Errata System
> wrote:
>
> The following errata report has been submitted for RFC5880,
> "Bidirectional Forwarding Detection (BFD)".
>
>
s a case when bfd.SessionState goes from Down to Init:
>
> If bfd.SessionState is Down
> If received State is Down
> Set bfd.SessionState to Init
>
> Best regards,
> Glebs
>
>
> On 08.02.23 19:58, John Scudder wrote:
>>
l packet) and that does not need to change.
>
> Thanks for making me think twice, er three times, or something.
>
> —Dave
>
>> On Feb 13, 2023, at 6:06 AM, John Scudder wrote:
>>
>> I guess it hinges on whether the reinitialization happens when you
>> transition ou
Hi All,
Regarding Jeff’s "Given the maturity of the feature, I'd suggest sticking to
the reality on the ground”, I want to step in and remind folks about what our
guidelines are for processing errata [1]. They are fairly narrow, by design.
One of the high-order bits of the guidelines is, "Errat
Further to what I just sent,
"is it possible to simply log a permanent erratum that explains the ambiguity
and encourages people not to worry about it?”
Yep. That's basically what I had in mind with "note it in a ‘hold for document
update’ erratum”. I don’t really expect anyone to write an Inte
> of machinations to go out of its way to fix something that is entirely
>>> pedantic. In that case I think holding the erratum for update is the right
>>> choice. The erratum can describe the ambiguity and the WG can decide what
>>> to do about it if they find another reaso
Top-posting to avoid the nest of dueling quoting conventions :-( and since
there’s only one residual point to settle.
I believe the draft text in question is:
OLD:
* Deploy the feature only in certain "trustworthy" environment,
e.g., at an IXP, or between a provider and its customers.
BFD Fans,
I wanted to emphasize Jeff’s request for the WG to take a minute to consider
the update. As far as I can tell, once Reshad fixes the final nit Robert
raised, the document is done. Unless there’s any objection raised [*] by the
end of Tuesday, May 2, I’ll plan to send the document to t
Having heard no further comments, we declare victory. I’ll send the document to
the RFC Editor. Congratulations and thanks to the authors, and thanks to Rob,
Jeff, and everyone who worked with them to improve the document.
—John
> On Apr 27, 2023, at 1:40 PM, John Scudder
> wrote:
&g
You’re assuming either an on-LAN attacker (and therefore, that BFD is being
used on a multiaccess medium) or multihop BFD here, I take it? Because RFC 5881
tells me GTSM is required if there’s no other authentication.
—John
> On Feb 6, 2024, at 8:56 AM, Jeffrey Haas wrote:
>
>
> My thought o
for example, "path continuity"?
* several action points are related to MIB work. How useful is MIB BFD
these days? Would directing the work on BFD management to the BFD YANG model be
a better choice?
Regards,
Greg
On Fri, Oct 18, 2024 at 12:35 PM John Scudder via Datatracker
mailto:no
What Jeff said.
Roman, if you’ll take a marker for an update that covers this document, ex post
facto, I'll commit to handling that as part of the charter update Jeff mentions.
—John
> On Oct 16, 2024, at 10:24 AM, Jeffrey Haas wrote:
>
> Roman,
>
> On Wed, Oct 16, 2024 at 06:24:10AM -0700,
On Jan 13, 2025, at 8:05 AM, Zaheduzzaman Sarker
wrote:
If the real intention is that the implementation just reads the BFD payload and
there is good motivation for putting Zeros then I would suggest writing - the
BFD endpoints/implementation MUST discard any non-zero values. @John
Scudder
I suppose it might also be considered an attractive option to use as a covert
channel, if the zero padding requirement wasn’t there. But it is so that should
be ok.
$0.02,
—John
> On Jan 8, 2025, at 9:18 AM, Jeffrey Haas wrote:
>
> [External Email. Be cautious of content]
>
>
> Deb,
>
>
Hi Mahesh,
(And hoping not to tread on Éric’s toes here…)
On Jan 14, 2025, at 11:55 AM, Mahesh Jethanandani
wrote:
…snip…
2. While the YANG security considerations boilerplate update request seems
otherwise reasonable, the desired format creates a MISREF. This is a more
general issue than just
wo object OIDs is the start and end of the range,
> the practice of using other objects where the index is embedded in the table
> as a notification object is common SNMP MIB practice to provide more
> information.
>
> -- Jeff
>
>>
>> Thanks
>> Gou
rrent status of
the BFD Session to the end user.
Thanks
Goutham
On Sat, Mar 15, 2025 at 5:11 PM Jeffrey Haas
mailto:jh...@pfrc.org>> wrote:
On Thu, Mar 13, 2025 at 01:48:57PM +, John Scudder wrote:
> Hi All,
>
> MIBs aren’t in my comfort zone and I’m having a hard time sussing thi
Hi All,
MIBs aren’t in my comfort zone and I’m having a hard time sussing this one out.
I hope one of the authors, or someone with more clue than me, will take a look.
One point is that the DESCRIPTION says "bfdSessDiag MUST both be set equal to
this new state (i.e., up(4)).” But if I track dow
Thanks for the review, Zafar. I’ve verified the erratum with the described text.
—John
On Mar 18, 2025, at 2:04 PM, Zafar Ali (zali) wrote:
Hi John
The proposed text looks good to me.
Thanks
Regards … Zafar
From: John Scudder mailto:j...@juniper.net>>
Date: Monday, March 17, 2025
John Scudder has entered the following ballot position for
charter-ietf-bfd-08-00: 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.)
The document, along with other
John Scudder has entered the following ballot position for
draft-ietf-bfd-unaffiliated-echo-12: No Objection
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
30 matches
Mail list logo
