he English is flaky in places but I am fine with that; that can be
fixed once the text has been discussed and agreed - in fact there is no
point in producing perfect English if we are then going to discuss and
change it - whereas the points above can mostly be fixed before now.
Tom Petch
module - since the module is
all about extensions to the rib, then naming it just 'rib' seems
misleading.
Tom Petch
___
rtgwg mailing list
rtgwg@ietf.org
https://www.ietf.org/mailman/listinfo/rtgwg
- Original Message -
From: "Mach Chen"
Sent: Thursday, August 02, 2018 2:58 AM
> Hi Rob,
>
> Looks good to me!
Well it would if we were allowed to have [References] in the Abstract
which we are not allowed to have:-)
Tom Petch
> Best regards,
> Mac
- Original Message -
From: "Jeff Tantsura"
To: "tom petch" ; "RTGWG"
Cc: "rtgwg-chairs" ;
Sent: Tuesday, July 31, 2018 10:27 PM
Tom,
Many thanks for your comments!
Authors - I'd expect you to address them while the document is in
adoption
- Original Message -
From: "Robert Wilton"
To: "tom petch" ; "Mach Chen"
; ;
Cc: ;
Sent: Thursday, August 02, 2018 12:06 PM
>
> On 02/08/2018 11:46, tom petch wrote:
> > - Original Message -
> > From: "Mach Chen"
&
e a 12 bit address, not quite
the MAC I see these days! I wonder if it is better to leave this out
and let readers refer to RFC6991.
Tom Petch
- Original Message -
From: "Robert Wilton"
To:
Sent: Friday, August 24, 2018 6:17 PM
> The -01 version fixes some of the comments ra
ilies.
This is of course all valid YANG and will coexist happily inside a
device but a user may not be so happy to have half a dozen or more
conflicting definitions of address family alongside an IANA registry
which is but little used. Also, this is of course also a perfectly
valid way of working for
del for Routing Management", which is
intended to be the basis for routing OAM, with YANG, says
" o The data model should be suitable for the common address
families"
as if there was a common understanding of what the term means.
So, triggers for confu
question is why have so many modules; I am a
fan of separate modules for YANG types and YANG identities, since I see
them as having a different evolution, but that is not done here; rather,
the functionality is broken up, leading to more YANG prefixes, modules
that are more complex. Why?
Tom Petch
expectation that they will
evolve differently - but then that suggests that they should be in
separate RFC! I grant that classifying, metering, marking, etc are
distinct pieces of technology but I am less convinced of the case for
separate YANG modules. Look, for example, at
draft-ietf-isis-yang-
by the NETMOD WG for interface definitions
(RFC7224).
Tom Petch
___
rtgwg mailing list
rtgwg@ietf.org
https://www.ietf.org/mailman/listinfo/rtgwg
at needs defining, NETMOD has the greater expertise of
turning that into a YANG module ie a two-stage process.
Tom Petch
> Lou
>
> (TEAS Co-chair)
>
> On 1/2/2019 5:20 AM, tom petch wrote:
> > The TEAS WG is producing a te-types I-D which contains definitions,
in
> > Y
e is version 1.1 so the reference in
the Introduction must be RFC7950; I cannot understand this I-D using
only RFC6020.
Tom Petch
- Original Message -
From: "Jeff Tantsura"
To: "RTGWG" ; "Routing WG" ;
Sent: Friday, February 15, 2019 7:18 PM
Subject: WG
references IMHO for all the
functions that this I-D specifies and there are none. One to resolve
post-adoption.
Tom Petch
>
> Thanks,
> Yingzhen
>
> On 2/19/19, 4:26 AM, "tom petch" wrote:
>
> Two uncertainties strike me.
>
> One is terminology, whi
- Original Message -
From: "Acee Lindem (acee)"
Sent: Tuesday, March 05, 2019 3:10 PM
> Hi Tom,
>
> On 3/5/19, 7:08 AM, "tom petch" wrote:
>
> - Original Message -
> From: "Yingzhen Qu"
> Sent: Monday, March 04, 20
reference: RFC XXXX
puzzles me
Tom Petch
- Original Message -
From: "Yingzhen Qu"
Sent: Monday, March 04, 2019 9:09 PM
> Hi Tom,
>
> Thanks for your review and comments. We have submitted version -10 to
address your comments, please see my detailed response below sta
I see a number of changes in this I-D cf -01 and would be interested to
hear the authors' comments thereon; I don't disagree with them but some
I wonder at (while others seem obvious:-)
Tom Petch
- Original Message -
From:
Cc:
Sent: Monday, March 11, 2019 6:00 AM
> A
metric and route tag (nothing to do with
path)
"Augment a route with a list of repair-paths.";
list repair-route {
Ah, so a repair path is really a repair route - not helpful
augment ..."rt:simple-next-hop"
{ description
"Add more parameters to
to know
but I would like to be told that before I start looking into the YANG.
Tom Petch
- Original Message -
From: "IETF Secretariat"
Sent: Wednesday, June 19, 2019 2:01 AM
> The RTGWG WG has placed draft-asechoud-rtgwg-qos-model in state
> Candidate for WG Adoption
ecurity boilerplate, you will need some more
references for that, ditto IANA Considerations
Tom Petch
>
> -thanks,
> Aseem
>
> From: Jeff Tantsura
> Date: Friday, June 21, 2019 at 1:40 PM
> To: "rtgwg-cha...@ietf.org" ,
"draft-asechoud-rtgwg-qos-mo...@ietf.org&qu
. ripng, then why not a simple equality?
/cooresponding /corresponding/
for IANA considerations RFC7950 is not a good reference since all it
says is go read RFC6020
Tom Petch
- Original Message -
From: "Jeff Tantsura"
Sent: Thursday, August 29, 2019 5:04 AM
> Dear co-author
s/if:interface" {
is unqualified so this will be added to all interfaces in the box; I am
unclear if this is a good idea.
IANA !
Security !
s.A.1
"RFC 6020: YANG - A Data Modeling Language ...
Tom Petch
- Original Message -
From:
To:
Cc:
Sent: Wednesday, Octob
for me. Is there a reason
for the different text in this qos I-D?
I look forward to the next revision.
Tom Petch
> Regarding the rest of your feedback, my co-authors and I will review
and
> make the necessary changes in the next revision. We can revisit each
> comment when we publish the next r
now - if the structure
changes, then those two parts of this I-D become a nonsense.
Tom Petch
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 : A YANG Data Model
From: Acee Lindem (acee)
Sent: 06 July 2020 13:59
Hi Tom,
On 7/6/20, 7:49 AM, "rtgwg on behalf of tom petch" wrote:
From: rtgwg on behalf of internet-dra...@ietf.org
Sent: 06 July 2020 01:19
I think that the reference to bgp-model in this I-D has to be Normative.
ter engineering IMHO.
Tom Petch
grouping prefix {
description
"Configuration data for a prefix definition.";
leaf ip-address {
type inet:ip-address;
mandatory true;
description
"An IPv6 or IPv4 address. A prefix is defined using
b
clear to such as RTG-DIR. 'must'
be present, and max>= min I think fine, but that is as far as I would go.
Where ipv4 goes one way and ipv6 goes another then YANG choice case case comes
to mind but probably not worth it here.
Tom Petch
Thanks,
Yingzhen
From: John Scudder
Date: Tu
efore giving the green light to this as it
stands.
So, do not support just yet on account on bgp.
Tom Petch
Jeff Tantsura is a co-author of the document, so he won't be involved
in judging consensus.
IPR:
If you are listed as a document author or contributor, please respond to
this ema
From: Acee Lindem (acee)
Sent: 19 August 2020 13:03
Hi Tom,
See inline.
On 8/19/20, 7:47 AM, "rtgwg on behalf of tom petch" wrote:
From: rtgwg on behalf of Chris Bowers
Sent: 17 August 2020 22:45
RTGWG,
This email starts the two week WG last call for
draft-
BGP modules have prefixe bgp-... but
that is of course for the IDR WG to decide.
Tom Petch
Thanks,
Chris
On Mon, Aug 17, 2020 at 4:45 PM Chris Bowers
mailto:chrisbowers.i...@gmail.com>> wrote:
RTGWG,
This email starts the two week WG last call for draft-ietf-rtgwg-policy-model.
From: Acee Lindem (acee)
Sent: 05 September 2020 21:55
Hi Tom,
On 9/4/20, 10:06 AM, "rtgwg on behalf of tom petch" wrote:
From: rtgwg on behalf of Chris Bowers
Sent: 03 September 2020 21:50
RTGWG,
An objection has been raised with respect to requesting publ
will be discussed within
RTGWG.
Chris
The other thought that I had was that the treatment of bgp-model, which I would
regard as unusual, might attract some interesting comment from such as Genart
or Opsdir reviews so it might be valuable to get those done earlier rather than
later.
Tom Petch
ntence in 4.4 saying what a chain looks like as YANG would help as
would a mention of chain alongside list in the description of export-policy and
import-policy. If my inference is wrong, then please tell me what a chain is!
Tom Petch
Thanks
Acee
On 9/10/20, 6:10 PM, "rtgwg on behalf
From: Acee Lindem (acee)
Sent: 16 September 2020 16:53
To: tom petch; Acee Lindem (acee); Chris Bowers; RTGWG
Cc: rtgwg-chairs
Subject: Re: WG last call for draft-ietf-rtgwg-policy-model
Hi Tom,
On 9/16/20, 6:01 AM, "tom petch" wrote:
From: Acee Lindem (acee)
Sent: 15 Sept
'is is' but I did not notice
'outcome outcome'
or
'statisfied'
Sigh. I suggest holding these (which my spell-checking MUA is complaining
about:-) until something else comes along.
Tom Petch
Thanks,
Acee
On 9/16/20, 12:33 PM, "tom petch" wrote:
ecide whether this is completely ruled out by the ordered-by user or
not. Maybe the document needs to say that document order is undefined and that
users must not rely on condition/action being evaluated in the order shown
except where ordered by user.
Tom Petch
Thanks,
Acee
On 9/17/20, 6:
rom/
I-D reference
the references to the two I-D are odd but that is likely a quirk of the tools.
Tom Petch
Thanks,
Acee
On 9/17/20, 6:35 AM, "tom petch" wrote:
From: Acee Lindem (acee)
Sent: 16 September 2020 18:47
Hi Tom, et al,
I have clarified the usage of poli
-intf-vlan-model
which has expired; and the title is not quite right.
Tom Petch
http://www.ietf.org/tools/idnits/ applied to draft-ietf-rtgwg-policy-model-26
produces 1 warning and 4 comments.
Yang Validation for draft-ietf-rtgwg-policy-model-26 on 2021-01-07 listed one
warning.
Please address
out:-)
Tom Petch
discussions with you offline inspired us a lot. The support of the user/app
group is explicitly shown in the text although it was implicitly included. We
have made a lot of efforts on clarifying the scope of the work, introducing the
basic solution, and describing the concrete
From: Yingzhen Qu
Sent: 25 March 2021 23:05
To: tom petch
Hi Tom,
Thank you for the review and comments, really appreciate. Sorry for the delay
of response.
We’ve addressed your comments in the latest version, but forgot to reply to
this email. We’d like to get this draft ready for WG LC, so
for
static routes to support multiple next-hop and more next-hop. which is then
contradicted by 3.1 and 3.2 so what is the point of this I-D? I should be
clear before I start to look at the details of the YANG module and I am not.
So, Not Ready IMHO.
Tom Petch
Thanks,
Yingzhen
On Fri, Apr 23, 20
ce is that it Normatively references
netmod-sub-intf-vlan-model, which expired last year.
The issue is not new; ospf-yang has been waiting a few years for its
references to progress but I do see it as problematic.
Tom Petch
The IESG plans to make a decision in the next few weeks, and soli
thing that the rtgwg or lsr might have done years ago and then
everyone could have used them, as NETMOD created RFC6991, but to do it now
would just tread on the toes of those who have done it for themselves and
confuse those yet to come,
Tom Petch
Thanks,
Yingzhen
> On Jul 18, 2021, at 9:07
out active route and I still find it
tautological.
Authors address gmail.com.com?
Tom Petch
On 17/04/2023 22:40, The IESG wrote:
The IESG has received a request from the Routing Area Working Group WG
(rtgwg) to consider the following document: - 'RIB Extension YANG Data Model'
{
alongside such as
identity vrrp-event-lower-priority-control {
which might not look very clear in five years time.
Tom Petch
Thanks
Acee
___
rtgwg mailing list
rtgwg@ietf.org
https://www.ietf.org/mailman/listinfo/rtgwg
7;sid' none of
which is sufficiently well known to not need expanding when used.
You are adding number eight.
It might help readers, perhaps the IETF at large, if another abbreviation could
be found.
Tom Petch
The draft link:
<https://datatracker.ietf.org/doc/draft-huang-rtgwg-sid-f
not to proceed down this route.
As I say, I think it a show-stopping mistake. When that is resolved, with a
revised I-D, I will make further comments, the first of which is that it needs
examples, not of further modules but of XML using the existing modules.
Tom Petch
The issues reporte
Why is this review on rtgwg@ietf.org and not on l...@ietf.org?
Tom Petch
From: rtgwg on behalf of julien.meu...@orange.com
Sent: 29 November 2023 16:03
To: rtg-...@ietf.org
Cc: rtg-...@ietf.org; draft-ietf-ospf-sr-yang@ietf.org; rtgwg@ietf.org
Ignore this - it was delayed 24 hours for moderation by which time Acee had
addressed the situation.
Tom Petch
From: Lsr on behalf of tom petch
Sent: 29 November 2023 16:33
To: julien.meu...@orange.com; rtg-...@ietf.org
Cc: rtg-...@ietf.org; draft-ietf
that there is too
llittle explanation of what has changed and why, for example between the SMI
and the YANG versions. With this more fundamental change then I think that a
concordance is vital.
Tom Petch
Regards,
Reshad.
Sent from my iPhone
On Mar 2, 2024, at 12:39 AM, Yingzhen Qu wrote
lready if
anything too long!
I want an Abstract to tell me if I should read further and I hope that my
suggestion goes far enough. Will anyone ignore this I-D because the Abstract
does not mention FRR - I was thinking not.
HTH
Tom Petch
Regards,
Greg
On Sun, Oct 20, 2024 at 2:14 AM tom
lready if
anything too long!
I want an Abstract to tell me if I should read further and I hope that my
suggestion goes far enough. Will anyone ignore this I-D because the Abstract
does not mention FRR - I was thinking not.
HTH
Tom Petch
Regards,
Greg
On Sun, Oct 20, 2024 at 2:14 AM tom
lready if
anything too long!
I want an Abstract to tell me if I should read further and I hope that my
suggestion goes far enough. Will anyone ignore this I-D because the Abstract
does not mention FRR - I was thinking not.
HTH
Tom Petch
Regards,
Greg
On Sun, Oct 20, 2024 at 2:14 AM tom
.
This document proposes a framework for a path-aware, remote protection
mechanism for non-TE paths.
with the abbreviations expanded as appropriate (but - of course - no
references!).
HTH
Tom Petch
From: linchangwang
Sent: 18 October 2024 15:13
Petch
From: linchangwang
Sent: 22 October 2024 01:08
To: tom petch; Greg Mirsky
Cc: RTGWG; rtgwg-chairs
Subject: Re: Request for MORE reviews of
draft-liu-rtgwg-path-aware-remote-protection-02
Hi Tom, Greg,
Thank you for your valuable feedback.
We will
55 matches
Mail list logo
