Rob, thanks for catching this, the container has been removed fairly recently,
I'll update section 4.1.
Regards,Reshad.
On Thursday, April 27, 2023, 12:06:15 PM EDT, Rob Wilton (rwilton)
<[email protected]> wrote:
Hi Reshad,
I think that looks good to me.
Whilst checking, I noticed this comment at the beginning of section 4.1:
For operational data, a new "unsolicited" container has been added
for BFD IP single-hop sessions.
Please can you check whether that is still accurate, but otherwise the changes
look good to me, and I’ve already cleared my discuss previously.
Regards,
Rob
From: Reshad Rahman <[email protected]>
Sent: 27 April 2023 16:37
To: The IESG <[email protected]>; Rob Wilton (rwilton) <[email protected]>
Cc: [email protected]; [email protected]; [email protected]
Subject: Re: Robert Wilton's Discuss on draft-ietf-bfd-unsolicited-11: (with
DISCUSS and COMMENT)
Hi Rob,
Changes made in rev-15 to simplify the model:
- Removed the feature for global config, also removed the global enabled leaf
- At the per-interface level, the enabled leaf doesn't depend on the
params-per-interface feature anymore
- Removed the must statements (since global parms config is not feature
dependent anymore)
Other changes:
- Changed role from enum to identity (Jeff's suggestion)
- Updated acknowledgement section
Regards,
Reshad.
Name: draft-ietf-bfd-unsolicited
Revision: 15
Title: Unsolicited BFD for Sessionless Applications
Document date: 2023-04-27
Group: bfd
Pages: 18
URL:
https://www.ietf.org/archive/id/draft-ietf-bfd-unsolicited-15.txt
Status: https://datatracker.ietf.org/doc/draft-ietf-bfd-unsolicited/
Htmlized: https://datatracker.ietf.org/doc/html/draft-ietf-bfd-unsolicited
Diff:
https://author-tools.ietf.org/iddiff?url2=draft-ietf-bfd-unsolicited-15
On Wednesday, April 19, 2023, 09:31:32 AM EDT, Rob Wilton (rwilton)
<[email protected]> wrote:
Hi Reshad,
Please see inline …
From: Reshad Rahman <[email protected]>
Sent: 19 April 2023 03:38
To: The IESG <[email protected]>; Rob Wilton (rwilton) <[email protected]>
Cc: [email protected];[email protected]; [email protected];
Jeffrey Haas <[email protected]>
Subject: Re: Robert Wilton's Discuss on draft-ietf-bfd-unsolicited-11: (with
DISCUSS and COMMENT)
Hi Rob,
Thanks for the feedback. And no need to apologize since it took us much longer
to respond to your initial comments...
Please see inline.
On Tuesday, April 18, 2023, 11:55:03 AM EDT, Rob Wilton (rwilton)
<[email protected]> wrote:
Hi Reshad,
Apologies for the delay.
The changes that you have made are sufficient to clear my discuss.
As a non-discuss (and non-blocking) comment, I do still find this hierarchical
configuration to be somewhat complex on two points:
1. The configuration is under optional feature statements both at the global
level and the per-interface level, and I think that the model would allow
neither feature to be specified, in which case the defaults would be ambiguous.
I’m sure that the WG has a good reason for why it is designed the way it is,
but I can’t help wondering whether it would make the model cleaner/simpler to
require support for the global level configuration, and only have per-interface
level configuration under an optional feature. I.e., if this was done, then
logically, there are always well-defined default values without requiring
evaluation of the must-statement.
<RR> Initially when I did the 2 features I was looking for a way to enforce
that at least 1 of the 2 features is supported but afaik there's no way in YANG
1.1 to do that. When I addressed your comments about config
hierarchy/inheritance, I added the must statements to address that. I did
consider removing one of the features but it wasn't clear to me which one
should be removed, in that some implementations might prefer having just global
config and others would prefer per-interface configuration. But I'm ok with
making the global config mandatory (i.e. remove the feature) if there's
consensus on that, need to discuss with the co-authors too.
[Rob Wilton (rwilton)]
Ack. The only reason that I went with making supporting global configuration
mandatory was that it felt like it should be simpler to implement, and that it
makes the inheritance more robust/simpler.
I think that it maybe possible to achieve what you desire in YANG 1.1 (i.e.,
require at least 1 of the 2 features to always be enabled), but I don’t think
that it is a good idea, and hence I wouldn’t recommend that you do it. Unless
I’m mistaken, what you desire may be achieved in YANG by defining a third
feature (let’s call it HACK) that has its own if-feature sub-statement of
“(GLOBAL or PER-INTERFACE)”, and then make everything at the top level of the
module conditional on the “HACK” feature. However, I think that this would
probably just make the model ugly and confusing to users and probably isn’t
worth the additional complexity/confusion that it would likely cause.
Regards,
Rob
1. I don’t think that the descriptions are necessarily clear about if, and
how, single-interval on the interface is allowed to override
desired-min-tx-interval and required-min-rx-interval configured globally, or
vice-versa. Please consider whether it would be helpful to update the
descriptions of these fields under the interface configuration to clarify these
semantics.
<RR> Ack, I will update the description.
Regards,
Reshad.
Regards,
Rob
From: Reshad Rahman <[email protected]>
Sent: 21 March 2023 01:32
To: The IESG <[email protected]>; Rob Wilton (rwilton) <[email protected]>
Cc: [email protected];[email protected];[email protected];
Jeffrey Haas <[email protected]>
Subject: Re: Robert Wilton's Discuss on draft-ietf-bfd-unsolicited-11: (with
DISCUSS and COMMENT)
Hi Rob,
I believe rev-12 addresses the 3 DISCUSS points below.
We still have to do further updates to the document.
Regards,
Reshad.
On Monday, December 12, 2022, 12:03:19 PM EST, Robert Wilton via Datatracker
<[email protected]> wrote:
Robert Wilton has entered the following ballot position for
draft-ietf-bfd-unsolicited-11: Discuss
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
tohttps://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/
for more information about how to handle DISCUSS and COMMENT positions.
The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-bfd-unsolicited/
----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------
Hi,
Thanks for this document.
Please see my comments below for more details, but I'm balloting discuss on 3
points: (1) The document is somewhat unclear as to whether the configuration is
applied hierarchically (I presume that it is, if not then my second discuss
point is not valid and can be ignored). (2) As specified, I don't think that
the hierarchical configuration will work, because the interface level leaf
"defaults" will override an explicit value configured globally. I.e.,
logically, the interface level leaf, if in scope, will always have a value. (3)
The document should provide an instance-data example in the appendix to
illustrate the use of this configuration.
Regards,
Rob
<snip>
