From: Eliot Lear
Sent: Friday, September 02, 2022 17:59
Hi Tom,
Just on this one point:
On 02.09.22 18:05, tom petch wrote:
> does 'http' match the pattern 'https?' ?
It should. However, some of the validators have some difficulty on
(expr1)|(expr2)|(expr3).* because th
https not http
Tom Petch
Eliot
On 02.09.22 18:57, internet-dra...@ietf.org wrote:
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> This draft is a work item of the Operations and Management Area
Separately
From: Eliot Lear
Sent: Wednesday, September 07, 2022 12:32
On 07.09.22 12:02, tom petch wrote:
> From: OPSAWG on behalf of Eliot Lear
> Sent: 02 September 2022 18:03
>
> This addresses Tom Petch's comments.
>
>
>
> W
From: Michael Richardson
Sent: Wednesday, September 07, 2022 14:51
tom petch wrote:
> web should be https not http
There are lots of reasons why a self-hosted SBOM might have to be HTTP.
Indeed, but my original comment, April I think, was that
http://tools,ietf.org
should be
ht
the I-D, I get told the document is available for a lot of
Swiss francs.
Tom Petch
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Operations and Management Area Working Group
WG of the IETF.
Title : Disco
get it back, hence my reference to Henk and November 2021 hoping that that
would be enough clues for others to find what I was referring to.
Tom Petch
Viele Grüße,
Henk
On 13.09.22 12:26, Eliot Lear wrote:
> The only change from this version is the pointer to a free version of
>
ned module which by then will have been obsolete for some time and
almost certainly wrong. Hence an IANA-maintained module should always be
published on its own.
Tom Petch
For the OPSAWG co-chairs,
Henk
___
OPSAWG mailing list
OPSAWG@ietf.org
ht
get what I have learnt from this thread and read the
revised I-D to see if I find it any clearer but will probably end up with the
same conclusion, this is two separate RFC.
Tom Petch.
Regards,
Rob
From: Wubo (lana)
Sent: 15 September 2022 03:17
To: Rob Wilton (rwilton) ;
draft-ietf-opsaw
'see section 6.2'
where there is no mention of them.
The IANA Guidelines RFC recommends a two-tier structure of Group and Registry.
The Group(s) involved here could do with a mention.
Tom Petch
Thanks.
Joe
___
OPSAWG mailing list
OPSAW
t are TBA3 et al. meant to be assigned by IANA? If so , IANA should be told
(good as IANA are as interpreting our sloppy work).
Tom Petch
Joe
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg
et to. Authors can, and do, add a note to the effect that users
should visit the IANA website, and give a URL, Such a note should always be
present IMO.
Tom Petch
Designers of IANA-maintained modules MAY supply the full initial
version of the module in a specification document tha
nk it will depend on who is Security AD at the time.
Tom Petch
ps I have found a send button, for better or worse
-Tiru
Cheers,
Med
> -Message d'origine-
> De : OPSAWG mailto:opsawg-boun...@ietf.org>> De la
> part de tom petch
> Envoyé : vendredi 16 septem
"Time units, where the options are s, ms, ns, etc.";
This is taken from RFC8532 where the options are hours minutes seconds
milliseconds microseconds nanoseconds. I think that the reader deserves
a more accurate description.
I see it as a clever idea to have one YANG module in two di
in as to
whether or not it is just two concepts,, 'underlay networks and overlay VPN
services' to quote the Abstract, or if there is more involved.
From your discussion with the authors I think just two, but I do not find the
body of the I-D clear on that.
Tom Petch
Cheers,
Adrian
-
Thinking some more ...
On 22/09/2022 12:24, tom petch wrote:
On 20/09/2022 17:24, The IESG wrote:
The IESG has received a request from the Operations and Management Area
Working Group WG (opsawg) to consider the following document: - 'A
YANG Model
for Network and VPN Service Perfor
the
relationships? I do not know . It is the sort of uncertainty that some Genart
reviewers are good at spotting so I will wait to see what else Last Call brings
up.
Tom Petch
Thanks,
Rob
> -Original Message-
> From: tom petch
> Sent: 23 September 2022 12:20
> To: Ro
C1123], [RFC5890] etc
'
Consistency with YANG would be good:-)
Tom Petch
Joe
From: Kenneth Vaughn
Date: Tuesday, October 4, 2022 at 10:37
To: Joe Clarke (jclarke)
Cc: opsawg@ietf.org
Subject: Re: SHEPHERD REVIEW: draft-ietf-opsawg-tlstm-update-07
I've updated the document; the only items
s tls-1.2? And is this the same as that which the
Netconf WG refers to as tls12?
Tom Petch
For the OPSAWG co-chairs,
Henk
On 29.09.22 10:27, Henk Birkholz wrote:
> Dear OPSAWG members,
>
> this email concludes the first WGLC call for
> https://www.ietf.org/archive/id/draft-ietf-o
From: Henk Birkholz
Sent: 12 October 2022 14:07
To: tom petch; opsawg; draft-ietf-opsawg-mud-...@ietf.org; Thomas Fossati
Subject: Re: [OPSAWG] 🔔 WG Last Call for draft-ietf-opsawg-mud-tls-07
Hi Tom,
would it be possible for you to augment your first comment with change
proposals, if possible
prefix of acl so I would see the augment as acl-tls and not
ietf-acl-tls; but mud is ietf-mud (unfortunately:-( so the augment is perhaps
better as ietf-mud-tls.
Tom Petch
Cheers,
-Tiru
On Wed, 12 Oct 2022 at 18:37, Henk Birkholz
mailto:henk.birkh...@sit.fraunhofer.de>> wrote:
Hi Tom,
wo
From: tirumal reddy
Sent: 14 October 2022 09:22
On Thu, 13 Oct 2022 at 16:55, tom petch
mailto:ie...@btconnect.com>> wrote:
From: tirumal reddy mailto:kond...@gmail.com>>
Sent: 13 October 2022 07:57
Thanks Tom for the review. Yes, we will fix the references identified by Tom.
inline one minor editorial comment plus a technical one which I do not
know the answer to.
From: tirumal reddy
Sent: 14 October 2022 14:01
On Fri, 14 Oct 2022 at 16:46, tom petch
mailto:ie...@btconnect.com>> wrote:
From: tirumal reddy mailto:kond...@gmail.com>>
Sent: 14 Octobe
draft-ietf-opsawg-mud-tls
augments RFC8519 but while the RFC structures its matches as a series of
choices, the augmentation does not. Should it?
The I-D has passed WGLC but has been delayed by me making editorial comments.
AFAICT the I-D has not had a YANG Doctor review.
Tom Petch
to me so I thought that someone had had a look at it even if
the datatracker records no review.
Tom Petch
Cheers, thanks.
t
[1] https://datatracker.ietf.org/doc/draft-ietf-opsawg-mud-tls/shepherdwriteup/
[2] https://trac.ietf.org/trac/ops/wiki/yang-doctors-review#Purpose
--
IMPORTANT NOTICE: Th
From: Michael Richardson
Sent: Monday, October 17, 2022 14:24
To: tom petch; Mahesh Jethanandani; net...@ietf.org; opsawg@ietf.org
Subject: Re: [OPSAWG] Augmenting ACLs in mud-tls
tom petch wrote:
> draft-ietf-opsawg-mud-tls augments RFC8519 but while the RFC
> structures its matc
x27;TCP/IP' is wrong. For me,
this needs fixing first before e/g/ seeing if the challenges of TLS13 are met.
Terminology needs to be consistent but it also needs to be accurate.
The I-D does not say, but perhaps should, that nothing therein applies to TLS1.2
Tom Petch
ting.
s.3.1.1 would be four pages long if we had pages but we don't. Perhaps worth
splitting into more sub-sections although I cannot see any obvious place to
make a split.
Tom Petch
Abstract
This document describes an architecture that aims at assuring that
service instances
(device id, hostname, management IP) depends
Is that an e.g. or an i.e.?
s.5.3
leaf interface {
type string;
mandatory true;
description
"Name of the interface.";
As above, unconstricted string. This could be a leafref in order to
ref
, uniqueness,
and constraints that that imposes on the choice thereof.
Tom Petch
Abstract
This document describes an architecture that aims at assuring that
service instances are running as expected. As services rely upon
multiple sub-services provided by a variety of elements includin
OPSAWG pages
draft-gharris does not appear
There are two other, perhaps related, I-D which appear
draft-ietf-opsawg-pcap-01 dated 29jul22 author G Harris status Informational
draft-richardson-opsawg-pcapng-extras-01 30jul22
Perhaps three minutes was not enough:-(
Tom Petch
(note that there was
From: Michael Richardson
Sent: Sunday, November 13, 2022 09:11
To: tom petch; opsawg@ietf.org
Subject: Re: [OPSAWG] progressing the PCAP documents
>>>>> OPSAWG on behalf of Michael Richardson
>>>>> writes:
> That is not what I see in the Datatracker
instance with an unrestricted string seems
onerous
Tom Petch
Best,
Jean
-Original Message-
From: tom petch [mailto:daedu...@btconnect.com]
Sent: Wednesday 9 November 2022 12:04
To: last-c...@ietf.org
Cc: draft-ietf-opsawg-service-assurance-y...@ietf.org; opsawg@ietf.org;
opsawg-cha
ely for this in future and will quote this comment in my support.
Tom Petch
From: OPSAWG on behalf of Eric Vyncke (evyncke)
Sent: 15 December 2022 07:12
To: Jean Quilbeuf; The IESG
Cc: draft-ietf-opsawg-service-assurance-y...@ietf.org; opsawg-cha...@ie
explanation of a digital twin and then saw that it is
a research topic of the IRSG about which consensus has not been achieved. As
such, I think it wrong for us to try and introduce it to YANG at this point in
time
Tom Petch
First, As described in RFC8969 or RFC8309, LxSM service delivery model or
tatus which is the 'Operational status of the service...'
i.e. a SAP has only one service status so a SAP has only one service
If there were more than one then oper-status would be a list keyed on service
In passing /povider/provider/
Tom Petch
The new text is available at:
URL:
is only a single service per SAP.
Ah yes,I can see it now on page 10. I did not understand that from Abstract or
Introduction.
Tom Petch
Regards,
Rob
> -Original Message-----
> From: tom petch
> Sent: 19 December 2022 12:19
> To: mohamed.boucad...@orange.com; Rob Wilton (r
opsawg-pcaplinktype-01.html
ending on Monday, December 30th.
Henk
As December 30th is gets closer it is looking less like a Monday to me; I like
the idea of CoB on Monday and have penciled that into my brain as a deadline
Tom Petch
As a recap: we already went through a first WGLC for
draft-
k that this needs an executive decision. If the IETF cannot produce a
specification to its usual standards, how far should it go?
In passing, 65000 appears in two ranges.
Tom Petch
ending on Monday, December 30th.
As a recap: we already went through a first WGLC for
draft-tuexen-opsawg-pcapng-
From: Carsten Bormann
Sent: 29 December 2022 13:20
On 2022-12-29, at 12:55, tom petch wrote:
>
> The linktype I-D is defective with its documentary references so the
> website is going to be as well. The number of references for links is
> considerable in the I-D although no
From: Michael Tuexen
Sent: 29 December 2022 17:13
> On 29. Dec 2022, at 17:45, tom petch wrote:
>
> From: Carsten Bormann
> Sent: 29 December 2022 13:20
>
> On 2022-12-29, at 12:55, tom petch wrote:
>>
>> The linktype I-D is defective with its documentary re
From: Michael Tuexen
Sent: 30 December 2022 14:48
> On 30. Dec 2022, at 12:41, tom petch wrote:
> From: Michael Tuexen
> Sent: 29 December 2022 17:13
>> On 29. Dec 2022, at 17:45, tom petch wrote:
>> From: Carsten Bormann
>> Sent: 29 December 2022 13:20
>> O
From: Carsten Bormann
Sent: 31 December 2022 15:00
On 2022-12-31, at 13:09, tom petch wrote:
>
> The I-D lacks much useful information compared with the tcpdump website which
> you say this replaces
I read Michael’s response as a promise to do the necessary work.
(If he doesn’t
From: Michael Richardson
Sent: Saturday, December 31, 2022 22:17
To: tom petch; Michael Tuexen; opsawg
Subject: Re: [OPSAWG] 🔔 WG Adoption Call for draft-tuexen-opsawg-pcapng-05 and
draft-richardson-opsawg-pcaplinktype-01
> The I-D lacks much useful information compared with the tcpd
From: Michael Tuexen
Sent: 31 December 2022 18:19
> On 31. Dec 2022, at 13:09, tom petch wrote:
>
> From: Michael Tuexen
> Sent: 30 December 2022 14:48
>> On 30. Dec 2022, at 12:41, tom petch wrote:
>> From: Michael Tuexen
>> Sent: 29 December 2022 17:13
>
revision clause is not quite the same as the document title
support for a function is often indicated by a presence container as opposed to
feature; this is widespread in routing modules.
what are the units of period?
not sure if opsawg are interested in this
Tom Petch
Regards,
Giuseppe
(o
.
I do think that the admin matters which is why I tackle an I-D in the way that
I do.
HTH
Tom Petch
Ron
Juniper Business Use Only
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg
Track
Ben suggested making 8805 Standards Track
The Protocol Action was 2021-05-26
HTH
Tom Petch
From: OPSAWG on behalf of Rob Wilton (rwilton)
Sent: 30 November 2023 14:35
To: Joe Clarke (jclarke); Michael Richardson; mohamed.boucad...@orange.com
Cc: opsaw
From: ippm on behalf of Adrian Farrel
Sent: 16 December 2023 10:16
I suppose that I don’t object to the definition of new abbreviations if people
are keen.
Personally, I don’t get the value of “inb-OAM” compared with “in-band OAM”.
It’s not like it can be said faster (one additional syllab
akes dictionary and brute force attacks harder. I don't know of
an RFC that goes into this but then few current RFC talk of character
strings for shared keys.
s.9.5.3
' To allow TACACS+ administraots to ...'
I did wonder if TACACS had ever impinged on IANA and so would this I
I note that
RFC7050
RFC7335
appear in YANG description clauses but are only Informative References,
not Normative as they should be.
Security Considerations references TLS1.2 RFC5246 where TLS1.3 RFC8446
should now be used
A Note to the RFC Editor perhaps
Tom Petch
7;t know of
> an RFC that goes into this but then few current RFC talk of character
> strings for shared keys.
>
> s.9.5.3
> ' To allow TACACS+ administraots to ...'
>
> I did wonder if TACACS had ever impinged on IANA and so would this I-D
> become a refere
eference to TACACS-DS which is not something I am familiar with.
Tom Petch
>
>
>
>
>
> General summary of other comments
>
> s.1
> /Although TACACS+ defines all three, but an/
> Although TACACS+ defines all three, an/
> Correct
he number assigned to
"draft-zhang-i2nsf-info-model-monitoring"
- IANA Considerations must be present
- Security Considerations must include the YANG template
HTH:-)
I am not on the I2NSF list.
Tom Petch
- Original Message -
From: "Linda Dunbar"
To:
Cc:
Sent:
overlap everywhere.
Not sure that that helps but that is the IETF.
Tom Petch
> Authors of the draft-hong-i2nsf-nsf-monitoring-data-model: Can you
please update the draft per Tom's comments.
>
> Linda.
>
> -Original Message-
> From: tom petch [mailto:ie...@btconnect.
w material.
I have read your e-mail (three times) and I cannot see any name for this
I-D anywhere, e.g. something that starts
draft-
And given that we are in the hurricane season, when I-Ds flood out
without any rate-limiting, I am not going to go looking for it without
some clue:-)
Tom Petch
Joe
I am struck by
"CCMIB Sean Turner 5 minutes
Sean wants no one to comment and no one commented"
which seems consistent; no identifier for the whatever-it-is and so
no-one said anything!
Tom Petch
- Original Message -
From: "Joe Clarke (jclarke)"
To:
Sent: Sa
sastrously short of descriptive text, not fit to be an RFC IMHO.
It would be a shame if it were to proceed in its present form just as it
would be a shame if the contents were not used to inform those working
on the NETCONF/NETMOD equivalents.
Tom Petch
- Original Message -
From: "War
what
it currently is when creating the YANG module for interface types. I
wonder if other WG have an interest, CCAMP or TEAS perhaps. I agree
that int-area is the WG best equipped to work on it and that it needs
working on.
Tom Petch
- Original Message -
From: "Suresh Krishnan"
sing on it; I am not sure that
there is here.
And it would focus on the name, as in 'Your name is mud' which, in my
culture, does not have a positive association.
Tom Petch
> Joe
> ___
> OPSAWG mailing list
> OPSAWG@ietf.org
ICT; better done sooner than later
IANA considerations must be present else no YANG module as per RFC8407
Security Considerations must include the boiler plate as per RFC8407 (in
fact, most of the above stems from RFC8407)
I reckon that you will need some 30 or so Normative References by the
time you are d
interfaces {
which is wrong - no CODE BEGINS - and then
module ietf-interfaces {
which is words fail me. What are you trying to do?
Tom Petch
ps draft-shytyi-netmod-vysm looked like a good start before the switch
to opsawg.
We added a section that describes wha
that you are augmenting
be that ietf-interfaces or anything else..
Hence my 'bizarre'.
Tom Petch
- Original Message -
From: "Dmytro Shytyi"
To: "tom petch"
Cc: "opsawg"
Sent: Saturday, October 19, 2019 1:22 PM
Hello Tom,
>import tailf-nc
- Original Message -
From: "Dmytro Shytyi"
To: "tom petch"
Cc: "opsawg"
Sent: Tuesday, October 22, 2019 6:57 PM
Hello Tom,
I can imagine your birraze. And I would like to add the next thing: the
model from RFC 8343 has some code that we are interested i
ust of history. The
only expected change is from draft-authername to draft-ietf at the time
of adoption. Anything else just increases the workload, if only a
fraction, for everyone involved.
Tom Petch
> Cheers,
> Tianran & Joe
>
> > -Original Message-
> > From
this came up at IESG Review when ADs could not
look back at earlier versions of the I-D because the link between
draft-author-wgname-oldname and draft-ietf-wgname-differentname was
missing and only those who had been around the WG in question some years
earlier knew of the connection..
Tom
ative structure'
tom petch
From: OPSAWG on behalf of Warren Kumari
Sent: 22 January 2020 22:38
To: opsawg@ietf.org;
draft-boydseda-ipfix-psamp-bulk-data-yang-model@ietf.org; Paul Aitken;
Gerhard Muenz; Benoit Claise
Subject: [OPSAWG] Request
in the 1990s but nothing
current.
Tom Petch
From: OPSAWG on behalf of Warren Kumari
Sent: 09 February 2020 21:49
To: Joe Clarke (jclarke)
Cc: opsawg; draft-ietf-opsawg-...@ietf.org
Subject: Re: [OPSAWG] WG LC for draft-ietf-opsawg-sdi-02
Dear OpsAWG
key pairs these days driven by the
requirements of PC to connect to networks and suspect that there is a disaster
there waiting to happen because the risks are not understood and believe that
what is being recommended here may fall in the same category.
Tom Petch
rt checks
I think that more references are needed. DHCP yes, but also RADIUS, TFTP,
HTTPS, 802.1AR, SMIME
Tom Petch
Thank you for the shepherd writeup / review,
W
P.S: Apologies all for the terseness of this email (and other emails)
- I am attempting to improve my typing, and so am tryi
these two points nailed down more after which I could
propose some refinement to the language.
Tom Petch
From: OPSAWG on behalf of internet-dra...@ietf.org
Sent: 03 April 2020 21:40
To: i-d-annou...@ietf.org
Cc: opsawg@ietf.org
Subject: [OPSAWG] I-D
From: Warren Kumari
Sent: 06 April 2020 16:07
On Mon, Apr 6, 2020 at 6:36 AM tom petch wrote:
>
> Warren
>
> Where I think I get confused with this is its context. Abstract talks of
> travelling to a datacentre and elsewhere there are references to a POP, both
> of which to
From: Warren Kumari
Sent: 06 April 2020 16:07
On Mon, Apr 6, 2020 at 6:36 AM tom petch wrote:
>
Warren,
understanding better what you have in mind, I suggest a few changes to the
Abstract and Introduction, as below. My language is probably a bit tighter,
omitting some adverbs but that
' (to me the obviously best way to do it) sometimes coloured
lines down the side of the screen, all of which seems outside my control - sigh.
Tom Petch
--
Michael Richardson , Sandelman Software Works
-= IPv6 IoT consulting =-
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg
/*UNUSED*/ is about. And examples in the
body of the I-D rather than as an Informative appendix . I am
unenthusiastic about looking any deeper.
Tom Petch
I’m getting to the virtual interim TODO items, and this was first on my list.
I have requested a Yang Doctor review for revision -03 of
ted to the usual A-Z 0-9 plus some punctuation)?
Overall I was expecting more but that said I cannot think of what to add!
Tom Petch
From: OPSAWG on behalf of Joe Clarke (jclarke)
Sent: 20 April 2020 14:23
To: opsawg
Subject: [OPSAWG] WG LC: draft-i
- IANA Considerations registers an existing prefix
- YANG imports mostly lack reference statements.
-Abstract 'The L2SM complements the Layer 2 Service model ...'
Tom Petch
Best Regards and stay safe during the time that a small piece of ARN is ruling
our lifes,
One point inline
From: Wubo (lana)
Sent: 22 April 2020 04:54
Hi Tom,
Thanks for the comments, please see reply inline below.
Regards,
Bo
-邮件原件-
发件人: OPSAWG [mailto:opsawg-boun...@ietf.org] 代表 tom petch
发送时间: 2020年4月21日 17:09
I think that more
seems a bit too 'tentative'
Tom Petch
This draft was an AD-sponsored work with Ignas and has now moved under Rob. It
has received a number of reviews (some thorough, some more cursory), and it is
destined to obsolete 6728 (Configuration Data Model for the IP Flow Information
Export (
From: Wubo (lana)
Sent: 23 April 2020 12:53
Hi Tom,
Thanks for pointing this out, please see the reply below.
Regards,
Bo
-邮件原件-
发件人: tom petch [mailto:ie...@btconnect.com]
发送时间: 2020年4月22日 23:34
One point inline
From: Wubo (lana)
Sent: 22
on to mean all three.
At present, I cannot think of a less clumsy way in YANG. Thus, I do not see a
bit string as any more attractive.
Tom Petch
Joe
Tom Petch
[Bo] Many thanks for your suggestion. The other two methods are indeed clumsy.
Please see if the following modification are as you
From: Joe Clarke (jclarke)
Sent: 24 April 2020 17:42
On Apr 24, 2020, at 11:37, tom petch wrote:
>
> From: Joe Clarke (jclarke)
> Sent: 24 April 2020 14:24
>
> [Bo] You are correct, and I think this model should not exclude this cases.
> I am considering of two possible appro
s was a common case. Joe suggests that no accounting is the
commoner - I do not have sufficient exposure to know - in which case I would
not bother with 'all'. Whether or not to make auth/auth the default I have no
particular view on - as I say, I lack the exposure to be confident about
rouble is, they
cut across WG, there is no obvious home for them, nowhere to come to agreement
on what they should be
Tom Petch
All in all, importing the SVC module breaks the separation between the two
layers. If we would like to re-use types, identities, features definitions, a
separate modul
ith a different author to
the importing I-D; a no brainer really.
Tom Petch
Joe
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg
common.
Even if L2NM is thought to have nothing in common with the other three, it may
be worth splitting out types, identities and such like into a separate YANG
module at least so that the two can progress separately
Tom Petch
egards,
Roque
On 26.05.20, 19:59, "OPSAWG on behalf of
R of the four documents under
consideration and to create a monster document and assuming that that is a good
basis.
Critical assessment is what is needed IMHO. Sometimes it is better to create
your own version of vpn-id or ODUC than import a hundred pages of someone
else's in order to get them.
, layer0 types has undergone several revolutions
before getting to its current state. These common identity etc are hard to get
right in the IETF.
Tom Petch
Italo
> -Original Message-
> From: Adrian Farrel [mailto:adr...@olddog.co.uk]
> Sent: giovedì 28 maggio 2020 19:15
> To
this a year or two hence - what
is easier to understand, what harder to misunderstand/? Stick to simplicity
and consistency.
HTH
Tom Petch
Best wishes,
Haomian
发件人: OPSAWG [mailto:opsawg-boun...@ietf.org] 代表 Qin Wu
发送时间: 2020年6月4日 12:09
收件人: Joe Clarke (jclarke) ; SAMIER BARGUIL
GIRALDO
抄送
have WG
consensus on the carve-up first.
Tom Petch
Best,
Adrian
-Original Message-
From: OPSAWG On Behalf Of Joe Clarke (jclarke)
Sent: 16 June 2020 15:18
To: opsawg
Subject: [OPSAWG] CALL FOR ADOPTION: draft-barguil-opsawg-l2sm-l2nm
Hello, opsawg. I hope everyone is doing well.
This s
From: OPSAWG on behalf of Joe Clarke (jclarke)
Sent: 28 May 2020 15:52
To: opsawg
Looking at the example in tacacs-yang-06 I see it uses an address of
10.10..10.x. I think that this should be an address reserved for documentation
192.0.2 if I recall.
Tom Petch
I have completed my first
From: Joe Clarke (jclarke)
Sent: 18 June 2020 18:16
To: tom petch
Cc: opsawg; draft-ietf-opsawg-tacacs-y...@ietf.org
Subject: Re: example in tacacs yang was Re: Shepherd review of
draft-ietf-opsawg-tacacs-yang
> On Jun 18, 2020, at 12:01, tom petch wrote:
>
> From: OPSAWG on beha
IETF's
successes, making information available in a standard, but simple, format. So
another alternative is to publish an individual I-D which can be adopted by the
WG, copied into an all-embracing I-D, binned, .....
Tom Petch
If you have some time, we can have a short ca
wanted and created an unnecessarily
complicated combination, but that is really a comment on the inadequacies of
YANG, of the inability to import only the bits you wanted, something that SMI
did not suffer from:-)
Tom Petch
Regards,
Samier Barguil
Transport & IP Networks | GCTIO - Te
is not permitted, then you have to change the module name, which
would seem to defeat the purpose of this particular exercise so it is important
to get it right first time..
Tom Petch
My 2 cents
Italo
> -Original Message-
> From: Joe Clarke (jclarke) [mailto:jcla...@cisco.com]
Looking at -08
Title suggest /yang/YANG/
leaf vrf-instance
might benefit from a reference to RFC8529
(ie I did not know where to look:-)
security
/cause the device vulnerable to attacks/make the device vulnerable to attacks/
IANA
Namespace /yang: ietf/yang:ietf/
Tom Petch
From: Wubo (lana)
Sent: 03 September 2020 12:11
Hi Tom,
Many thanks for the review, will fix in the rev-09.
Or leave it and treat the comments as part of IETF Last Call (which I hope will
happen soon) - I am easy either way.
Tom Petch
Thanks,
Bo
-邮件原件-
发件人: tom petch [mailto:ie
a lot of vendor-related, proprietary data or implementation detail
that I expect will all have to go. Repeated references to github? err no.
My guess is that about half of the current text would make it through. Even
the ISE might baulk at some of it.
Tom Petch
"re-publishing + inher
ll the proprietary stuff, all the references to github. And
plenty needs adding to bring it up to IETF 2020 standards. Give it to the ISE
and even they might choke on it but any output from them can only be a better
starting point for an IETF WG.
Tom Petch
Grüße, C
t consider that the IETF does not have the
expertise to provide Designated Experts - well, I would.
As Adrian says below, options 1 and 2 look the right way to go.
Tom Petch
4. The Independent Submissions stream is not a short-cut to RFC publication. If
there is a proper home within the IETF then
objections, and
a set of comments.
The chairs believe this I-D is ready for adoption and for the working
group to work on.
Authors please rename the I-D to
draft-ietf-opsawg-mud-iot-dns-considerations-00, keeping the content as
is, and resubmit.
Is that really the name you want it to bee?
Tom Petch
1 - 100 of 187 matches
Mail list logo
