CC to opsawg working group.
-邮件原件-
发件人: wangzitao
发送时间: 2022年5月5日 15:52
收件人: 'Joe Clarke (jclarke)' ; adr...@olddog.co.uk;
ron.even@gmail.com; liuc...@chinaunicom.cn; xuhl@chinatelecom.cn;
oscar.gonzalezded...@telefonica.com; bin_...@comcast.com
抄送: opsawg-cha...@ietf.org; Wubo
Just chiming in on this thread.
Don't be frightened of downrefs. They are just a small piece of process
easily handled.
Better to set the reference correctly. If it is necessary to read RFC 4026
in order to understand part of this document, then it is a normative
reference. Otherwise, of
From: Jean Quilbeuf
Sent: 29 April 2022 17:19
Dear Tom,
Thank you very much for your comments.
Here is the updated version:
URL:
https://www.ietf.org/archive/id/draft-ietf-opsawg-service-assurance-yang-05.txt
Status:
Hi Greg,
Thanks for the comments. STAMP referenced as RFC 8762 has been added as one of
PM measurement protocol.
Please be aware this model is a network model and does not specifies the
details of STAMP.
Please check whether rev-08 addresses your concerns:
Hi Bo,
thank you for your quick response to my comment and clarification. The
updates fully address my comments.
Regards,
Greg
On Thu, May 5, 2022 at 5:46 AM Wubo (lana) wrote:
> Hi Greg,
>
>
>
> Thanks for the comments. STAMP referenced as RFC 8762 has been added as
> one of PM measurement
>>> * Would it make sense to further refine your contact leafs to check for the
>>> MUST URI schemas?
(They are URI schemes, not URI schemas.)
It is generally a mistake to hardwire specific URI schemes in a specification
that uses URIs to provide flexibility.
(What if in a few years you would
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 : Updates to the TLS Transport Model for SNMP
Author : Kenneth Vaughn
On 5/5/22 11:05, Carsten Bormann wrote:
* Would it make sense to further refine your contact leafs to check for
the MUST URI schemas?
> (They are URI schemes, not URI schemas.)
>
> It is generally a mistake to hardwire specific URI schemes in a specification
> that uses URIs to provide
Thanks for all the work Bo,
We're just waiting on IPR responses from:
ron.even@gmail.com
liuc...@chinaunicom.cn
xu...@chinatelecom.cn
oscar.gonzalezded...@telefonica.com
And I'll need the chairs to set the Intended Status of the document in the
Datatracker.
Cheers,
Adrian
I have uploaded a new version of the "Updates to the TLS Transport Model for
SNMP". This version includes the following changes:
Changed the name of the registry to the SNMP-TLSTM registry
Updated reference to DTLS 1.3 to reflect the publication of RFC 9147
Clarified the first paragraph of
Before I go and check the details...
[...] TLSTMv1.3 MUST only be used with
(D)TLS version 1.2 and later.
What does this MUST tell me? There is no definition of TLSTMv1.3 nor
do we version MIB modules. I understand the intention of the statement
but we need to be more careful about the
> There is no definition of TLSTMv1.3 nor do we version MIB modules
Agreed, This is old text that I missed from when this was intended to be a
replacement to RFC 6353 rather than an update. I think it is best to just
delete the sentence so the paragraph would now read "[RFC6353] stated that
We made the mistake by simply reusing the TLS hash algorithm for a
different purpose. We now factor things out by having a separate
registry for the hashing algorithms used to create certficate
fingerprints. But why would we now tie this back to TLS hashing
algorithms? In modern TLS, I think they
I have no real problem either way; unless I hear someone else argue for making
it automatic in the next couple of days, I will delete the last two sentences
of the first paragraph of the IANA Considerations so that it will read:
This document requires the establishment of a new SNMP-TLSTM
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 : A YANG Model for Network and VPN Service Performance
Monitoring
Authors : Bo
Hi Adrian,
Thanks for the review.
We have submitted rev-08 to address this issue and also comments from YANG
doctor Radek and Greg.
Please see the
diff:https://www.ietf.org/rfcdiff?url2=draft-ietf-opsawg-yang-vpn-service-pm-08.
Thanks,
Bo
-Original Message-
From: Adrian Farrel
Hi Radek,
Thanks for your helpful comments. We agree with your analysis and suggestions.
It is acceptable to configure both PM types, although using both PM types is
redundant.
We have updated the YANG model as you suggested.
Please see the diff:
* The description of the transparency-extension grouping is a tautology. This
is one of my pet peeves. Can you add more flavor here?
Fleshed out a tad.
Thanks. Much better.
* Would it make sense to further refine your contact leafs to check for the
MUST URI schemas?
I know what you
Hi Joe,
No, I'm not aware of any IPR that applies to this draft.
Thanks,
Honglei Xu
>> De : Joe Clarke (jclarke) Envoyé : mardi 1 mars
>> 2022 00:11 À : Wubo (lana) om>; Qin Wu
>> om>; BOUCADAIR Mohamed INNOV/NET
>> om>; Oscar González de Dios
>> om>; Bin Wen
>> Objet : Poll for IPR:
19 matches
Mail list logo
