my apologies. -11 had too many typos. immediately pushed -12
randy
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg
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 : Finding and Using Geofeed Data
Authors : Randy Bush
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 : Finding and Using Geofeed Data
Authors : Randy Bush
thanks john. appreciated.
> 0. I’d like to thank George Michaelson for a thorough and helpful, not
> to say exemplary, shepherd’s report.
it's odd. the acks have thanked ggm twice, once for shepherding, and
folk seem to miss it.
> 1. Section 3:
>
>Ideally, RPSL would be augmented to
John Scudder has entered the following ballot position for
draft-ietf-opsawg-finding-geofeeds-10: No Objection
When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)
Please
> -- Section 3 --
> Having a standards track document relying on a 'remarks:' attribute looks
> really weird. Should it rather be informational ? NB: I understand that
> changing the RPSL syntax is mostly mission impossible.
note that it also specifies the "Geofeed:" attribute
> Should the case
Thanks Roman. Two follow-up comments in line.
Russ
> On May 19, 2021, at 5:59 PM, Roman Danyliw wrote:
>
> Hi Russ!
>
> Inline ...
>
>> -Original Message-
>> From: Russ Housley
>> Sent: Wednesday, May 19, 2021 11:27 AM
>> To: Roman Danyliw
>> Cc: IESG ;
Hi Russ!
Inline ...
> -Original Message-
> From: Russ Housley
> Sent: Wednesday, May 19, 2021 11:27 AM
> To: Roman Danyliw
> Cc: IESG ; draft-ietf-opsawg-finding-geofe...@ietf.org;
> opsawg-cha...@ietf.org; Ops Area WG ; George Michaelson
>
> Subject: Re: Roman Danyliw's Discuss on
Dear OPSAWG members,
this email concludes the call for Working Group Adoption on
https://datatracker.ietf.org/doc/html/draft-claise-opsawg-service-assurance-yang-07.
We received a large number of positive replies, no objections, and
various significant comments.
The chairs believe this I-D
Dear OPSAWG members,
this email concludes the call for Working Group Adoption on
https://datatracker.ietf.org/doc/html/draft-claise-opsawg-service-assurance-architecture-05.
We received a large number of positive replies, no objections, and
various significant comments.
The chairs believe
Roman:
Addressing some of your comments below. I'm leaving others to my co-authors.
> --
> DISCUSS:
> --
>
> The validation process for the signature computed
Hi Joe,
Thank you for the comments.
Please see inline.
Cheers,
Med
De : Joe Clarke (jclarke) [mailto:jcla...@cisco.com]
Envoyé : mercredi 19 mai 2021 16:09
À : BOUCADAIR Mohamed TGI/OLN ; opsawg@ietf.org
Cc : draft-ietf-opsawg-vpn-common@ietf.org
Objet : Re: New Version Notification for
Thanks, med (and Tom for the review).
A few comments on the diff. For your ipv4 and ipv6 feature additions, What
about saying:
"IPvX traffic can be _carried_ in the VPN..." (or transported, perhaps)
The text "can be assigned to an access" reads odd to me. With respect to the
rest of the
Hi all,
This version addresses the recent comments from Tom (add some reference, update
some descriptions).
Cheers,
Med
> -Message d'origine-
> De : internet-dra...@ietf.org [mailto:internet-dra...@ietf.org]
> Envoyé : mercredi 19 mai 2021 15:50
> À : BOUCADAIR Mohamed TGI/OLN ; Oscar
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 Layer 3 VPN Network YANG Model
Authors : Samier Barguil
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 Layer 2/3 VPN Common YANG Model
Authors : Samier Barguil
In my experience, SBOM’s are specific to a particular vendor, product, version
(assuming 3 part semantic versioning) and timestamp. The URI, if using the
.well-known construct, will need to accommodate many SBOM’s – perhaps “base” is
providing this level of specificity, e.g.
Hi Eliot,
I think SaaS use cases are a problem for SBOM formats. Not so much for
discovery and access.
There seems to be some inconsistency with the well known URI.
In section 2 "{ORIGIN}/.well-known/sbom/base"
In section 4, the MUD YANG model, "https://{hostname}/.well-known/sbom;.
And again
Éric Vyncke has entered the following ballot position for
draft-ietf-opsawg-finding-geofeeds-10: No Objection
When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)
Please
Thank you Wassim for your review, it comforts my own ballot
-éric
-Original Message-
From: Int-dir on behalf of Wassim Haddad via
Datatracker
Reply-To: Wassim Haddad
Date: Tuesday, 18 May 2021 at 22:05
To: "int-...@ietf.org"
Cc: "last-c...@ietf.org" , "opsawg@ietf.org"
,
20 matches
Mail list logo
