-D is published.. Changing
it just introduces the scope for mistakes.
Don't do it. Ever.
Tom Petch
p.s. I wonder if anyone has ever appealed to the IESG against a decision to
change th name of an I-D:-)
Thanks,
Yingzhen
On Tue, Mar 12, 2024 at 9:38 PM Christian Hopps
mailto:cho
ation
with segment routing.";
NEW
"This augments ISIS protocol configuration
with segment routing for the MPLS data plane.";
Tom Petch
From: Lsr on behalf of internet-dra...@ietf.org
Sent: 31 December 2023 06:30
To: i-d-annou
or secondary sources, the secondary can only get it wrong; you always
go back to the primary (unless or until the primary is replaced which is not
the case for most of the definitions here).
> On Jan 13, 2024, at 07:42, tom petch wrote:
>
> From: Lsr on behalf of The IESG
>
> Sent: 11
in line
Tom Petch
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr
defeats me.
It is present in a daigram, s.3.6, but with no explanation. Reading RFC5340
it could be A.4.3 but I am not sure
Tom Petch
Abstract
This document defines a YANG data model augmenting the IETF OSPF YANG
model to provide support for OSPFv3 Link State Advertisement (LSA
that although by the time of publication, LSR as well underway, yet
it remained an OSPF RFC. Other RFC with seemingly similar metadata did not
join the RFC Editor Queue until after the LSR WG had come into being and so
have been regarded as LSR RFC and listed as such in the datatracker.
Tom Petch
From: Acee Lindem
Sent: 01 January 2024 13:14
> On Dec 30, 2023, at 06:56, tom petch wrote:
>
> Going through ospf-sr-yang-25 (and no, I do not want a new version for
> Christmas!) it seems to me that RFC8666 updates, RFC8665 even if the metadata
> does not mention it.
&
repetition
Tom Petch
From: Lsr on behalf of internet-dra...@ietf.org
Sent: 19 December 2023 21:41
To: i-d-annou...@ietf.org
Cc: lsr@ietf.org
Subject: [Lsr] I-D Action: draft-ietf-ospf-sr-yang-25.txt
Internet-Draft draft-ietf-ospf-sr-yang-25.txt is now available. It is a work
item of the Link State
nd RFC8666 as Normative References and defines a leaf 'af'
whose definition in RFC8666 contradicts that in RFC8665 unless and until
RFC8666 is seen as updating RFC8665 and which could confuse those who
comprehend the Normative References, IMHO.,
Tom Petch
Thanks,
Yingzhen
On Sat, Dec 30, 2023 at 3
but is it your intention?
Tom Petch
From: Lsr on behalf of internet-dra...@ietf.org
Sent: 19 December 2023 21:41
To: i-d-annou...@ietf.org
Cc: lsr@ietf.org
Subject: [Lsr] I-D Action: draft-ietf-ospf-sr-yang-25.txt
Internet-Draft draft-ietf-ospf-sr-yang
From: Acee Lindem
Sent: 12 December 2023 22:25
Hi Tom,
> On Dec 11, 2023, at 7:45 AM, tom petch wrote:
Acee
top posting since most of my comments are addressed in -25 (which I have
reviewed)
Renaming the YANG module is a pain but probably needs doing on the assumpt
is which I will post
separately.
Tom Petch
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr
From: Acee Lindem
Sent: 18 December 2023 13:14
To: tom petch
Cc: julien.meu...@orange.com; Routing Directorate;
draft-ietf-ospf-sr-yang@ietf.org; Lsr
Subject: Re: [Lsr] RtgDir Last Call Review: draft-ietf-ospf-sr-yang
Tom,
On Dec 18, 2023, at 07:47, tom petch wrote:
I have yet to catch
- but the call never came. I think my
comments are addressed in -21, when ospfv3 was added, but I will check again in
-24
Tom Petch
From: Acee Lindem
Sent: 12 December 2023 22:25
To: tom petch
Cc: julien.meu...@orange.com; Routing Directorate;
draft
d on lsr, the former not. mm
Tom Petch
Les
> -Original Message-
> From: tom petch
> Sent: Wednesday, December 13, 2023 9:34 AM
> To: Les Ginsberg (ginsberg) ; lsr-cha...@ietf.org
> Cc: lsr@ietf.org
> Subject: Re: RFC8665
>
> From: Les Ginsber
pages which just consumes more of my
time to find.
I am thinking that the metadata may be wrong and there will be other problems
but as yet have no evidence thereof.
Tom Petch
Les
> -Original Message-
> From: Lsr On Behalf Of tom petch
> Sent: Monday, December 11, 202
"SRMS preference TLV, value from 0 to 255.";
so what? what difference soes it make to be 0 or 255 or 42?
Tom Petch
From: Lsr on behalf of julien.meu...@orange.com
Sent: 05 December 2023 08:15
Hi Acee,
I've looked at the diff: the new version l
I look in vain in the datatracker for RFC8665.
Document search finds it, the data tracker does not list it.
I realise that it is not a product of the lsr WG but then neither are RFC9129
or RFC8920 AFAICTand they are listed.
Odd; well, irritating to be precise.
Tom Petch
e list
"IS-IS will not advertise nor receive any mapping server..."
'not receive' implies a filter for such traffic. Perhaps not act upon.
/allows to advertise/advertises/
/allows to enable/controls/
" /* Notifications */ "
probably redundant or else something missing
On to OSPF (s
see other minor glitches which I hope to flag next week.
Tom Petch
From: julien.meu...@orange.com
Sent: Thursday, November 30, 2023 08:35
To: tom petch
Cc: lsr@ietf.org
Subject: Re: RtgDir Last Call Review: draft-ietf-ospf-sr-yang
Hi Tom,
That looks to me like
opinion on
the router-id type.
type or value?
I have annotated my copy of the I-D with the word 'Good' alongside the values
of the router-type:-)
Tom Petch
Julien
On 29/11/2023 17:33, tom petch wrote:
> Why is this review on rt...@ietf.org and not on lsr@ietf.org?
>
>
Why is this review on rt...@ietf.org and not on lsr@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; rt...@ietf.org
to me. I will shut up now and let the process take its course.
Tom Petch
Best Regards
Aijun Wang
China Telecom
-邮件原件-
发件人: lsr-boun...@ietf.org [mailto:lsr-boun...@ietf.org] 代表 tom petch
发送时间: 2023年9月15日 18:41
收件人: Aijun Wang ; John Scudder
; cho...@chopps.org
抄送: lsr ; draft-ppsenak
then express in response to a consensus call. The facts may
persuade some, they may not persuade others but it is the summation of views
expressed on the list that determines the consensus, not facts.
Tom Petch
Hi, Chris:
I have asked Acee the following questions
(https://mailarchive.ietf.org
to me to be
next step.
Tom Petch
We request the WG document be based on the
https://datatracker.ietf.org/doc/draft-wang-lsr-prefix-unreachable-annoucement/,
because it is the first document to initiate the use case, provide the
explicit signaling mechanism, and cover more scenarios.
It’s
to at a future date.
Tom Petch
From: Lsr on behalf of internet-dra...@ietf.org
Sent: 11 September 2023 12:25
To: i-d-annou...@ietf.org
Cc: lsr@ietf.org
Subject: [Lsr] I-D Action: draft-ietf-lsr-igp-ureach-prefix-announce-00.txt
Internet-Draft draft-ietf-lsr-igp
From: Acee Lindem
Sent: 21 August 2023 15:52
Hi Tom,
Thanks for the review.
> On Aug 21, 2023, at 06:57, tom petch wrote:
>
> From: Lsr on behalf of Christian Hopps
>
> Sent: 19 August 2023 01:26
>
> This begins a 2 week WG Last Call, ending Sep 1,
ection the data objects relate to
reference
"RFC 8362: OSPFv3 Link State Advertisement (LSA)
Extensibility, Appendix B - AreaExtendedLSASupport";
(twice)
Appendix B is Area Configuration Parameters
Tom Petch
Authors,
Please indicate to the list, your k
From: Acee Lindem
Sent: 09 June 2023 16:05
Hi Tom,
I believe Yingzhen and I have fixed all of these nits in the -14 version.
https://datatracker.ietf.org/doc/draft-ietf-lsr-ospfv3-extended-lsa-yang/
yes, looks good,
Tom Petch
> On Jun 1, 2023, at 6:16 AM, tom petch wrote:
>
> Ac
Acee
My comments all relate to the 'latter I-D', that is to the extended LSAs YANG
model, the one you really want to publish and not to the admin tags (which you
will doubtless want to publish in due course).
Tom Petch.
_
From: Acee Lindem
Sent: 31 May 2023
/opf:ospfv3/ospf:body:
here and elsewhere, what is the final colon doing?
contact URL is out of date
references to OSPF YANG need updating to the RFC
'Figure .. ' now appears in four places, doubtless a 'good idea' from the tool
makers.
Like I say, not justifying a new I-D just yet IMHO.
Tom
ocuments as well. I
don’t know what the DOWNREF registry is.
https://datatracker.ietf.org/doc/downref/
A registry of documents which have been approved by the IESG for use as
DOWNREFs in the past and so do not need further approval or a mention in the
Last Call notice
Tom Petch
> ## Nits
&
the IANA
actions when they review it.
Tom Petch
> -Original Message-
> From: tom petch
> Sent: Friday, April 21, 2023 4:55 AM
>
> From: Les Ginsberg (ginsberg)
> Sent: 20 April 2023 17:21
>
> Tom -
>
> https://www.iana.org/assignments/isis-tlv-codepoint
ed
7.4
Likewise, the IANA page has
bit 3 Flexible Algorithm RFC9350
which the I-D lacks
7.5
you got there before me but IANA starts the name with I S I S
which as above I think significant in this context.
Tom Petch
Les
> -Original Message-
> From: tom petch
> Sent:
From: John Scudder
Sent: 20 April 2023 13:45
To: tom petch
Cc: cho...@chopps.org; draft-ietf-lsr-rfc8919...@ietf.org; lsr-cha...@ietf.org;
lsr@ietf.org
Subject: Re: [Lsr] Last Call: (IS-IS
Application-Specific Link Attributes) to Proposed Standard
Hi Tom,
Thanks for catching this, sorry I
the "IS-IS TLV Codepoints" registry to control the assignment
"
When I go to the IANA website I see lots of I S - I S under which it might be
but not that particular one. What is it by another name?
Tom Petch
Abstract
Existing traffic-engineering-related link attribu
number).
Is this the recommended way of doing it?
Tom Petch
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr
involvement with the IETF
that I get feedback some years down the line along the lines that my
suggestions were better than they seemed at the time so I continue to make them
(I also know that I could word them better at times). Whatever you come up is
ok.
Tom Petch
More inline. Look for LES2
From: Les Ginsberg (ginsberg)
Sent: 08 December 2022 15:38
Tom -
> -Original Message-
> From: tom petch
> Sent: Thursday, December 8, 2022 2:52 AM
>
> From: Lsr on behalf of Christian Hopps
>
> Sent: 07 December 2022 13:20
> This begins a 2 week WG Last C
registry has 28 references to RFC8920; should this be updated?
Tom Petch
Authors,
Please indicate to the list, your knowledge of any IPR related to this work.
Thanks,
Chris.
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr
f the 'when' clauses is at odds with the description there
of. I suspect that the when clauses are incorrect.
Somewhat challenging:-(
Tom Petch
Best Regards,
Oscar
-Mensaje original-
De: internet-dra...@ietf.org
Enviado el: lunes, 24 de octubre de 2022 19:26
Para: Os
o late. The I-D, after 1129 days, has completed AUTH48 and its release as an
RFC is imminent.
Tom Petch
1.
/ietf-routing:routing/control-plane-protocols/control-plane-protocol/ietf-ospf:ospf/areas/area/interfaces/interface/interface-id
This leaf's type should be u32 and not u16.
2.
reference in
the Registration Procedures to common expert review guidance for the
grouping since I do not know what is meant by a grouping.
Tom Petch
Abstract
This document describes a backward-compatible, optional IS-IS
extension that allows the creation of I
like a good plan,
Tom Petch
Thanks,
—John
> On Sep 12, 2022, at 5:33 AM, tom petch wrote:
>
> From: Lsr on behalf of John Scudder
>
> Sent: 06 September 2022 22:04
>
>> On Sep 6, 2022, at 5:00 PM, Acee Lindem (acee) wrote:
>>
>> I guess if we do decide
well as OSPF). No need
for ten columns, just a structured approach.
It took a lot of detailed review to get it right - Loa knows that well - but I
believe that the effort was worth it.
Tom Petch
—John
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr
_
From: John Scudder
Sent: 14 June 2022 21:49
Cc: John E Drake; Les Ginsberg (ginsberg); Tony Li; tom petch; Acee Lindem
(acee); lsr@ietf.org
Subject: Re: [Lsr] Dynamic Flooding on Dense Graphs -
draft-ietf-lsr-dynamic-flooding
I’ll point out that option 2 frees us from having to run an annual
regex for system-id which if I
reverse engineer it aright allows for all zero along with all [0-9a-fA-F]
Tom Petch
HTH
Les
From: Lsr On Behalf Of Jaideep Choudhary
Sent: Tuesday, June 14, 2022 8:00 AM
To: Tony Li
Cc: supp...@ietf.org; lsr@ietf.org
Subject: Re: [Lsr] [rt5.ietf.org #7080]
later be
demonstrated.
Tom Petch
Thanks,
Acee
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr
is accomplished by assigning, within the node,
a distinct "zone index" to each zone of the same scope to which that
node is attached, and by allowing all internal uses of an address to
be qualified by a zone index.
'
All internal uses! that is what an implementer should
; I am
wondering if it requires zones in the YANG.
I was unaware of the existence of zones with IPv4 until I came across them in
the YANG types but that is my ignorance - they were always there1!
Tom Petch
The current definition of ipv6-address type and the ip-address nodes in
ietf-ip.yang
is a bad one. I would introduce types with zone -
that is a no-brainer - but would deprecate the existing types.
Tom Petch
As mentioned previously, it is also worth comparing this to the OpenConfig YANG
modules:
They have redefined ip-address (and v4/v6 variants) to exclude zone information
That is the I-D that has just been approved by the IESG!
I do wonder about BFD. Single hop IPv6 would seem to be a case for link local
even if RFC5881 has a SHOULD NOT for using link local; and IPv6 link local is
where the zone may be needed to identify the interface. RFC5881 does not
mention
From: tom petch
Sent: 08 April 2022 17:32
From: Lsr on behalf of Joel M. Halpern
Sent: 07 April 2022 18:51
Given that you are asking for an incompatible change to an existing
module, the shoe would seem to be on the other foot.
If you could show it was necessary to make such an incompatible
and it may be a case where a zone is required. I would
make sense for that protocol, as it would for other 'local' protocols, such as
printing, problem determination and so on.
Tom Petch
Yours,
Joel
On 4/7/2022 1:22 PM, Acee Lindem (acee) wrote:
> Hi Joel,
>
> On 4/7/22, 1:18 PM, "J
, the zone is silently discarded and the address is used without the
zone. But, like the assertion that keeping the zone will cause who knows what
damage, I have not done the research to substantiate that assumption.
Tom Petch
I appreciate that this is an NBC change, but I believe
and I2NSF WG I-Ds, and there are
others.
Also, some authors want the zone information as part of their leaf.
Tom Petch
Thanks,
Acee
On 4/4/22, 7:11 AM, "Lsr on behalf of tom petch" wrote:
I assume that this is a refresh while waiting for ospf.yang to wind its way
through
to
'Revised'
Tom Petch
From: Lsr on behalf of internet-dra...@ietf.org
Sent: 07 March 2022 03:14
To: i-d-annou...@ietf.org
Cc: lsr@ietf.org
Subject: [Lsr] I-D Action: draft-ietf-lsr-ospfv3-extended-lsa-yang-10.txt
A New Internet-Draft is available from
lace with tabs, at least on every copy I
have downloaded from the RFC Editor web site, and several years of trying have
never yielded the magic formula as to what the tab settings should be for the
document to print in a usable format.
I would engage with a 2328bis
Tom Petc
. There might have been some
progress in the past year but I see no evidence thereof.
Equally, my sense was that there was no consensus in support of taking
draft-knodel as a way forward, political pressure perhaps, but not IETF
consensus.
Tom Petch
Thank you,
Mike
From: Lsr on behalf of tom petch
Sent: 14 October 2021 16:42
From: Christian Hopps
Sent: 14 October 2021 13:13
Does it junk the mail if the one true and proper form is used: "IS-IS" (i.e.,
with the hyphen)? :)
Yes. That is what the thread about Prefix unreachable that Acee kick
as I have received your e-mail.
It even junked an e-mail that I sent to another WG but I cannot see what it saw
in that!
Tom Petch
Thanks,
Chris.
> On Oct 14, 2021, at 7:15 AM, tom petch wrote:
>
> Top posting for a different topic
>
> My ESP, one of the larger ones in the w
nothirng
Tom Petch
ps perhaps this is the considered opinion of the ESP on the I-D:-)
From: Lsr on behalf of Acee Lindem (acee)
Sent: 12 October 2021 20:05
To: lsr@ietf.org
Speaking as WG Chairs:
The authors of “Prefix Unreachable Announcement” have
. that key
names do not reveal sensitive information about the network.
Tom Petch
Thanks,
Yaron
On 8/10/21, 15:01, "Qin Wu" wrote:
Yaron:
Thank for clarification. I agree to keep the last sentence in the second
paragraph of section 7 as is.
But I prefer to add th
was expecting an action by
the AD to be required and have seen no sign thereof which may be relevant.
Tom Petch
Regards,
Reshad.
On 2021-03-22, 3:30 PM, "Rtg-bfd on behalf of Yingzhen Qu"
wrote:
Hi,
I also support the split of ietf-bfd-mpls-te module from the base BFD
Review and deduce that that is how the assignment was made. And even
if there is a more recent RFC to be pointed to, I think it clearer to spell out
that Expert Review was how the value was assigned and so not to look for
further documentation.
Tom Petch.
Les
> -Original Mess
the world has been getting on quite happily without it for 13 years? Is there
anything that now needs a value which previously did not? If so, that might be
more suitable for an I-D.
Tom Petch
I thought it polite to mention this before you spend the time and effort to
produce a new version
From: Joel M. Halpern
Sent: 22 June 2021 09:57
Do Les' suggested edits address your concerns.
We will apply yor changes to the IANA considerations section.
I would go further than Les as I suggested on Tuesday. Perhaps it is time for
a new version to comment on.
Tom Petch
Yours,
Joel
On 6
ts language should use RFC8174.
With the revised IANA Considerations, there is no need for Security
Considerations to make any mention of YANG.
Tom Petch
Les
> -Original Message-
> From: Joel Halpern Direct
> Sent: Monday, June 21, 2021 8:47 AM
> To: Les Ginsberg (ginsberg) ;
Well, what does it do? Gives examples of its use? I see nothing more.
Tom Petch
We are explicit in this draft that one of the obvious uses for this
ifType is to trigger 5309 behavior.
Yours,
Joel
On 6/21/2021 4:41 AM, tom petch wrote:
> From: Lsr on behalf of Harold Liu
>
>
as I said
in a separate note is to ask IANA to update two references, nothing more.
Tom Petch
And I would like to share more background information for this internet
draft:
As Joel mentioned, we requested and received an IF Type assignment from
IANA (with expert review) for point-to-
for
interface type ap2pOverLan by Expert review which caused IANA to add the
entries to the MIB module and the YANG module but IANA do not need to be told
that - they did it!
Tom Petch
Yours,
Joel
On 6/18/2021 12:20 PM, tom petch wrote:
> From: Joel M. Halpern
> Sent: 18 June 2021 16
this I-D ... well I am not clear
what it does except lay claim to things that others have already done with
RFC5309 and expert review :-)
I think too that camel case is problematic. SMI uses it, YANG does not but we
are now likely stuck with identity p2pOverLan .
Tom Petch
Yours,
Joel
On
would go for it.
I think too that this I-D should reference and build on RFC5309. At present it
looks like an Unused Ref.
Tom Petch
Thank you,
Joel
On 6/16/2021 4:41 PM, Acee Lindem (acee) wrote:
> Hi Joel,
>
> At first I wondered where this document should reside and then decided th
From: Lsr on behalf of gregory.mir...@ztetx.com
Sent: 25 May 2021 22:02
Inline under
Tom Petch
Hi Tony,
thank you for clarifying your view on this. Please find my notes in-line below
under the GIM>> tag.
Regards,
Greg Mirsky
Sr. Standardization Expert
预研标准部/有线研究院/有线产品经营部 St
different to that of ospf-yang with IPsec, key-chain
and key-explicit.
I would sum up the I-D as 'routing for everyone but different' and wonder what
others might think.
Tom Petch
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr
Acee's suggestion that the TE part should be split from the BFD YANG
draft so that the other three WG, who have been held up for years, can progress.
Tom Petch
Copying the LSR WG.
Meeting recording is @ https://www.youtube.com/watch?v=vSqfJJ3gOc0
Regards,
Reshad
as it could be. What matters? TLV
144, so that comes first; to me, it is a no-brainer but clearly my brain is
different.
Tom Petch
Tony
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr
I gave
as show-stoppers to adoption. The period for the adoption call has now expired
so I was expecting a follow-up from the Chairs.
I would leave further changes until the adoption is complete.
Tom Petch
Thanks,
Yingzhen
On Jan 5, 2021, at 10:02 AM, Yingzhen Qu
mailto:yingzhen
From: Christian Hopps
Sent: Tuesday, January 05, 2021 16:54
> On Jan 5, 2021, at 11:47 AM, tom petch wrote:
>
> From: Lsr on behalf of Christian Hopps
>
> Sent: 05 January 2021 09:19
>
> This begins a 2 week WG adoption call for the following draft:
>
> https://dat
, the references do not reflect RFC
published last year, YANG import lack references, the key references are listed
as Informative.
And, contrary to the announcement, the intended status of the I-D is
Informational.
I am surprised that anyone should consider this to be in a state fit for
adoption!
Tom
From: Lsr on behalf of internet-dra...@ietf.org
Sent: 18 December 2020 18:43
I still have an issue with the prefix in -02
The examples use rm: which I find a bit short.
The module should be the same but uses isis-rmetric: which I find a bit long.
isis-rm: would suit me
Tom Petch
A New
The text in question is specified by
YANG Guidelines RFC8407 and appears in (almost) all I-D with a YANG Module.
The text is the consensus of the NETMOD WG. The Secure Transport layer is a
defined part of the Netconf architecture and can be implemented by at least
four p
From: Acee Lindem (acee)
Sent: 10 December 2020 00:11
Speaking as WG member:
Hi Chris, Tom,
On 12/9/20, 6:03 AM, "Lsr on behalf of tom petch" wrote:
From: Lsr on behalf of Acee Lindem (acee)
Sent: 30 November 2020 18:14
Two thoughts
isis-rmetric is
? Is there any way to tell if it is present or not?
Tom Petch
As stated as the IETF 109 LSR WG meeting, we feel the IS-IS reverse metric
augmentation is ready for publication. This begins a two week last call for the
subject draft. Please indicate your support or objection on this list prior to
12:00 AM
Who cares?
Well it is a MISSREF for bfd-yang which is a MISSREF for ospf-yang inter alia
so may be those dusty old I-D will come to life and see if they are still valid
or not (some are not:-(.
Tom Petch
___
Lsr mailing list
Lsr@ietf.org
https
there is one such for YANG terminology
- I wonder if ospf-dynamic-flooding would be a better feature name given there
are the two of them side-by-side
Tom Petch
Tony
> On Sep 15, 2020, at 9:04 AM, Acee Lindem (acee)
> wrote:
>
> It looks like some unfortunate tab settings at least for th
From: Acee Lindem (acee)
Sent: 29 September 2020 22:44
Hi Tom,
We can add the references. See ACEE>.
Yes please - it will make it easier for me to review
On 8/13/20, 6:03 AM, "Lsr on behalf of tom petch" wrote:
From: Lsr on behalf of internet-dra...@ietf.org
Sent: 1
The formatting of this I-D seems to have gone wrong making it hard to read and
review. The indentation of successive lines of the YANG module is more than it
usually is. This was a problem with -01 that was not present in -02 but has
now returned in -03
Tom Petch
From: I-D-Announce
point about link type is that you are augmenting ospf-yang which uses an
enum so in places users will be required to use an enum and in others a uint8
which could be confusing
Tom Petch
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item
;
I think you know this by now but this one would work but is not needed,
simple equality test would do.
when "derived-from-or-self(../../ospf:header/ospf:type,
'ospfv3-e-as-external-lsa')"
again equality is all that seems to be needed
when "derived-from-or-self(../../
module but you include the boilerplate.
Tree diagrams no reference
means different I-D in different places
import lack references
security lacks TLS1.3
RFC8242 not in I-D References
RFC8174 not in I-D References
import OSPF must be Normative
Tom Petch
This model severs
efix "isis"; }
lacks a reference clause
IS-IS reverse metric functionality [RFC8500].
YANG module must be plain text and this looks like it is not.
Tom Petch
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr
Tony
I suggest you have a read of RFC8407, not so much s.4, which is rather
detailed, but the other sections.
Tom Petch
- Original Message -
From:
To: "tom petch"
Cc:
Sent: Saturday, September 07, 2019 3:51 AM
Hi Tom,
Thank you very much for your comments. We will ad
which the
I-D becomes; I see no reference to the name at the start of the I-D,
namely
YANG Data Model for Dynamic Flooding
which must appear in the IANA Considerations, which it does not as they
are absent.
Also, many lines are too long for an RFC which makes the I-D (too)
difficult to rea
description
"Opaque type and ID only apply to Opaque LSAs.";
The must and the description match but why are they part of container
header and not part of the leaves?
Tom Petch
- Original Message -
From: "tom petch"
Sent: Friday, July 05, 2019 5:3
d?
This I-D is big - 125pp - and I will not finish reviewing it by July
17th but expect to do so some time later in the month - I will post
again when I have.
Tom Petch
- Original Message -
From: "The IESG"
To: "IETF-Announce"
Cc: ; "Stephane Litkowski"
; ;
;
Sent
cated YANG to suppress the
interface-global value when that at the interface-level is configured,
but they don't, they rely on correct implementation! Also, this
structure is not, IMHO, readily apparent in the tree diagram unless you
know what to look for.
Tom Petch
- Original Message -
Fro
Original Message -
From:
Sent: Friday, June 07, 2019 9:03 AM
Hi Tom,
Thanks for your feedback.
Pls find some comments inline
Stephane
-Original Message-
From: tom petch [mailto:ie...@btconnect.com]
Sent: Thursday, June 06, 2019 18:59
Stephane
The YANG module has RFC5307
ule names or module revision dates)
floating around or do the tools hide such details and present a coherent
picture to an operator?
Likewise, does it matter how many features there are, with a Cartesian
explosion leading to a five or six digit number of combination
e XML/HTML anchors and not plain text.
Time idnits learnt what a YANG module looks like!
Tom Petch
- Original Message -
From: "Acee Lindem (acee)"
To: "Yingzhen Qu" ; ;
Sent: Monday, January 21, 2019 9:07 PM
Subject: Re: [Lsr] Shepherd review comments on
draft-iet
1 - 100 of 112 matches
Mail list logo
