Taking a step back
On 05/04/2023 10:20, t petch wrote:
On 04/04/2023 06:20, Rajaguru Veluchamy (rvelucha) wrote:
Thanks, Tom for review/comments.
Version been updated for comments. Can u please check.
How widely is bfd offload implemented by manufacturers? I had a look at
the Juniper website and find it refers to Distributed BFD running on the
Packet Forwarding Engine and Centralized BFD running on the Routing
Engine. Is this what you mean by BFD offload? (Searching the Juniper
website for BFD offload generates thousands of hits none of which seem
to be about the offloading of BFD).
Who else supports it (such as I could see in publicly available
documentation, I am not asking for anything proprietary)? What other
terms are used to reference it?
I always look at the affiilations of the authors of I-D and when I see
several different manufacturere names I am reassured (but not here:-)
Tom Petch
https://www.ietf.org/archive/id/draft-rvelucha-bfd-offload-yang-06.txt
Mmmm, no not really.
For a YANG module to exist it must be registered. You register the name
spaces, which looks ok, except that I think that the choice of names
needs thinking about.
You do not register the YANG modules. This requires a reference to the
document in which the YANG module appears with name and prefix. Where
this is yet to be published, the usual convention is to reference
RFC XXXX <title of I-D>
The prefix in IANA Considerations you specify do not match those in the
YANG modules.
I think the choice of names unfortunate. Yes, these are extensions to
the existing modules but what happens when the next extensions to these
modules comes along? .extext, .ext2, .next? Better to use some
abbreviation of what these modules are about IMHO as a suffix in the
name and in the prefix; hardware offload, reduced to three characters
ideally but 'hw' seems ok - I avoid the letter 'o' because of the
numerous times it gets confused with zero but you might have a better idea.
Security considerations must use the template from YANG Guidelines even
it says there appear to be no exposures.
'contact; ' must be HTTPS: and to the datatracker not tools
BSD licence is 'Revised' not 'Simplified;
Fundamentally, while these are largely editorial I would oppose adoption
until there is some reason why this should exist. Who cares if there is
hardware offload? And what is the boolean for? Can it be set and reset
to turn hardware offload on and off or is it read only to reflect what
the hardware is currenly up to? I expect to learn this from the
Introduction and perhaps from the Abstract.
These thoughts were triggered by my recent experience with an up-market
PC which refused to shutdown when I told it to and led to me pulling the
plug from the wall. I eventually found a customisation option which
specified what should happen when I pressed the off button. To me it is
obvious what should happen when I press the off button, but seemingly
not to leading PC manufacturers and suppliers of leading operating
systems; they need to be told that pressing the off button is an
instruction to power off the PC.
Thus you know exactly what is meant here. I do not:-(
Tom Petch
Regards
V.Rajaguru
XR/BFD/PI
-----Original Message-----
From: t petch <[email protected]>
Sent: Thursday, March 30, 2023 10:02 PM
To: Rajaguru Veluchamy (rvelucha)
<[email protected]>; [email protected]
Cc: [email protected]; Rajaguru Veluchamy (rvelucha) <[email protected]>
Subject: Re: FW: New Version Notification for
draft-rvelucha-bfd-offload-yang-05.txt
On 30/03/2023 15:09, Rajaguru Veluchamy (rvelucha) wrote:
HI Team,
Can we have WG adoption for this draft please.
https://datatracker.ietf.org/doc/draft-rvelucha-bfd-offload-yang/
Since it imports RFC8349, that must be a Normative Reference in
the7950 I-D.
There is a template for Security Considerations in the YANG Guidelines
RFC which there needs to be a good reason not to follow. Those
guidelines drag in some more references.
A YANG module does not exist until it is registered via IANA so the
IANA Considerations need supplying, registering the three modules,
registered the three name spaces.
YANG would benefit from a reference, RFC7950, in the Introduction.
The WG Web URL are out of date as are the trust URL.
The BSD License reference is out of date. (In fact, that reference
was never valid in the first place:-(
RFC9127 gives some ideas of what is wanted.
Tom Petch
Regards
V.Rajaguru
XR/BFD/PI
-----Original Message-----
From: [email protected]<mailto:[email protected]>
<[email protected]<mailto:[email protected]>>
Sent: Thursday, March 30, 2023 7:36 PM
To: Rajaguru Veluchamy (rvelucha)
<[email protected]<mailto:[email protected]>>; Rajaguru
Veluchamy (rvelucha) <[email protected]<mailto:[email protected]>>
Subject: New Version Notification for
draft-rvelucha-bfd-offload-yang-05.txt
A new version of I-D, draft-rvelucha-bfd-offload-yang-05.txt
has been successfully submitted by RAJAGURU VELUCHAMY and posted to
the IETF repository.
Name: draft-rvelucha-bfd-offload-yang
Revision: 05
Title: YANG Data Model for Bidirectional Forwarding
Detection (BFD) Hardware Offloaded Session
Document date: 2023-03-30
Group: Individual Submission
Pages: 10
URL:
https://www.ietf.org/archive/id/draft-rvelucha-bfd-offload-yang-05.txt
Status:
https://datatracker.ietf.org/doc/draft-rvelucha-bfd-offload-yang/
Htmlized:
https://datatracker.ietf.org/doc/html/draft-rvelucha-bfd-offload-yang
Diff:
https://author-tools.ietf.org/iddiff?url2=draft-rvelucha-bfd-offload-yang-05
Abstract:
This document defines a extension YANG data model that can be
used to
manage Hardware Offloaded Bidirectional Forwarding Detection (BFD).
This document specially talks about BFD sessions that are offloaded
to hardware.
The YANG modules in this document conform to the Network Management
Datastore Architecture (NMDA).
The IETF Secretariat
