I think that this I-D needs a few tweaks.
'RIB' 'a RIB '' the RIB' all appear and I like consistency; since boxes
can have multiple RIBs, I suspect 'a RIB' is best.
'route' v 'path' - RFC8349 consciously decided that path did not mean
much and so the term does not appear; here 'path' seems to used without
a clear differentation from 'route'
s.3.2 'Ipv4'
s3.3 'operational state'
should this be an NMDA datastore?
s.5
'import' statements need 'reference' clauses, all of them
Datastore Architecture (NDMA) as described in RFC 8242.
perhaps 8342
leaf total-active-routes {
what is an active route? what criterion can be applied to pick them out
of a RIB?
"The tag is a 32-bit opaque value associate ...
/associate/associated/
Not sure but
OLD
"The application-specific tag is an additional tag that
can be used applications that require semantics and/or
policy different from that of the tag. For example,
the tag is usually automatically advertised in OSPF
AS-External Link State Advertisements (LSAs) while this
application-specific tag is not advertised implicitly.";
NEW
"The application tag is an additional tag that
can be used by applications that require semantics and/or
policy different from that of the tag. For example,
the tag is usually advertised in OSPF
AS-External Link State Advertisements (LSAs) while this
application tag is not advertised";
'implicitly' does not make sense to me and the juxtaposition of 'tag'
and 'application tag' may confuse and using 'tag' in so many other
places may confuse more; time for a typedef? (tag also appears already
in RFC8349 but not, sadly, in RFC8294)
MULTI seems to have lost an I
OSPF. ECMP could do with references
s.7
" name: ietf-acl namespace: urn:ietf:params:xml:ns:yang:ietf-rib-
extension prefix: ietf-rib-ext reference: RFC XXXX "
oh dear
Appendix B should use documentation addresses not 10. 192.1.
The IESG have been known to reject examples that do not include some
IPv6
Tom Petch
----- Original Message -----
From: <[email protected]>
To: <[email protected]>
Cc: <[email protected]>
Sent: Thursday, June 25, 2020 11:12 PM
Subject: I-D Action: draft-ietf-rtgwg-yang-rib-extend-04.txt
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
This draft is a work item of the Routing Area Working Group WG of the
IETF.
Title : RIB YANG Data Model
Authors : Acee Lindem
Yingzhen Qu
Filename : draft-ietf-rtgwg-yang-rib-extend-04.txt
Pages : 22
Date : 2020-06-25
Abstract:
The Routing Information Base (RIB) is a list of routes and their
corresponding administrative data and operational state.
RFC 8349 defines the basic building blocks for RIB, and this model
augments it to support multiple next-hops (aka, paths) for each
route
as well as additional attributes.
The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-rtgwg-yang-rib-extend/
There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-rtgwg-yang-rib-extend-04
https://datatracker.ietf.org/doc/html/draft-ietf-rtgwg-yang-rib-extend-0
4
A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-rtgwg-yang-rib-extend-04
Please note that it may take a couple of minutes from the time of
submission
until the htmlized version and diff are available at tools.ietf.org.
Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/
_______________________________________________
I-D-Announce mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
.
_______________________________________________
rtgwg mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/rtgwg
