Re: [OPSAWG] John Scudder's No Objection on draft-ietf-opsawg-finding-geofeeds-10: (with COMMENT)

[Randy Bush]

my apologies.  -11 had too many typos.  immediately pushed -12

randy

___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

[OPSAWG] I-D Action: draft-ietf-opsawg-finding-geofeeds-12.txt

[internet-drafts]

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
  Massimo Candela
  Warren Kumari
  Russ Housley
Filename: draft-ietf-opsawg-finding-geofeeds-12.txt
Pages   : 23
Date: 2021-05-19

Abstract:
   This document specifies how to augment the Routing Policy
   Specification Language inetnum: class to refer specifically to
   geofeed data CSV files, and describes an optional scheme to use the
   Routing Public Key Infrastructure to authenticate the geofeed data
   CSV files.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-opsawg-finding-geofeeds/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-opsawg-finding-geofeeds-12
https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-finding-geofeeds-12

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-opsawg-finding-geofeeds-12


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

[OPSAWG] I-D Action: draft-ietf-opsawg-finding-geofeeds-11.txt

[internet-drafts]

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
  Massimo Candela
  Warren Kumari
  Russ Housley
Filename: draft-ietf-opsawg-finding-geofeeds-11.txt
Pages   : 23
Date: 2021-05-19

Abstract:
   This document specifies how to augment the Routing Policy
   Specification Language inetnum: class to refer specifically to
   geofeed data CSV files, and describes an optional scheme to use the
   Routing Public Key Infrastructure to authenticate the geofeed data
   CSV files.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-opsawg-finding-geofeeds/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-opsawg-finding-geofeeds-11
https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-finding-geofeeds-11

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-opsawg-finding-geofeeds-11


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG] John Scudder's No Objection on draft-ietf-opsawg-finding-geofeeds-10: (with COMMENT)

[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 define a new RPSL geofeed:
>attribute in the inetnum: class.  Until such time, this document
> 
> I, too, am curious as to why this ideal solution isn’t considered
> achievable. 
> 
> I’m also a little confused by the way you seem to be arguing with
> yourself in this section. First you tell me that change control for
> RPSL is vested in the operator community (by implication, not the
> IETF). A few paragraphs later you say:
> 
>While we leave global agreement of RPSL modification to the
>relevant parties, we specify that a proper geofeed: attribute in
>the inetnum: class MUST be "geofeed: ", and MUST be followed by a
>single URL which
> 
> Is it up to them? Or is it up to you? I don’t get it. I mean, I’m fine
> with what you’ve specced, but when you fence it off with disclaimers
> that say RPSL modification isn’t up to you, it leaves me confused.
> 
> Perhaps your point is that the IETF gets to specify the geofeed:
> attribute, but only the RIRs get to decide when they will start using
> it?

really, if the ripe community adopts it.  and progress is good there.

ever see the cat herding video?  https://archive.psg.com/cat-herders.mov

> By the way, I bet you should expand “RIR“ on first use.

ack.  but aren't the darned RIRs expansive enough?  :)

> 2. Section 3:
> 
>Until all producers of inetnum:s, i.e. the RIRs, state that they have
>migrated to supporting a geofeed: attribute, consumers looking at
>inetnum:s to find geofeed URLs MUST be able to consume both the
>remarks: and geofeed: forms.  This not only implies that the RIRs
>support the geofeed: attribute, but that all registrants have
>migrated any inetnum:s from remarks: use to geofeed:s.
> 
> The referent of “this” in the last sentence isn’t clear. Maybe you mean
> “migrated”? Rewriting as ‘“Migrated” not only implies…’ would clarify,
> if so.

sure

> 3. Section 3:
> 
>Any particular inetnum: object MUST have at most, one geofeed
>reference, whether a remarks: or a proper geofeed: attribute when it
>is implemented.  If there is more than one, all are ignored.
> 
> This makes me think the geofeed: attribute will never, ever be
> adopted, because you’ve just created a flag day requirement.

no.  this is per inetnum: object, not per registry.  see beginning of
para.  perhaps i should add an example of an inetnum: object.

inetnum:147.28.0.0 - 147.28.15.255
netname:RGNET-RSCH-147-0
country:EE
org:ORG-RO47-RIPE
admin-c:RB45695-RIPE
tech-c: RB45695-RIPE
abuse-c:AR52766-RIPE
status: LEGACY
notify: r...@rg.net
mnt-by: MAINT-RGNET
mnt-by: RIPE-NCC-LEGACY-MNT
remarks:Geofeed https://rg.net/geofeed
created:2020-10-20T23:45:00Z
last-modified:  2020-11-12T13:16:12Z
source: RIPE

except i bet it would take hours to use proper example formalities for
everything.

> Why not permit both the remarks: and geofeed: versions to enable
> transition?

because then, as you point out, it is three paragraphs if they disagree.

> 4. Section 5:
> 
>If and only if the geofeed file is not signed per Section 4, then
>multiple inetnum: objects MAY refer to the same geofeed file, and the
>consumer MUST use only geofeed lines where the prefix is covered by
>the address range of the inetnum: object they have followed.
> 
> Presumably this only works with unsigned geofeeds because you’re
> implicitly requiring that the geofeed file be signed only once. Is
> there any particular driver for this sign-only-once requirement? On a
> cursory review of §4, I don’t see anything that would make multiple
> signatures impracticable.

the grofeed lines would then need to be sorted, clumped, ...  seems a
bit complex for not much win.  due to the administrative structure and
process, inetnum: objects tend to the same granularity as RPKI objects.
so having the geofeed files follow seems natural.

i figure that, if signing actually is used, and folk whine, we can beg
russ to do a bis.

> I note that §3 says
> 
>If a geofeed CSV file describes multiple disjoint ranges of IP
>address space, there are likely to be geofeed references from
>multiple inetnum: objects.
> 
> While the text in §5 doesn’t actually give the lie to this quote (since I can
> read it as “if an unsigned geofeed CSV file…”) it does seem like the document
> is pulling in two different directions.
> 
> At the very least, if there is a requirement that only a single signature be
> present in a geofeed file, can you say that explicitly in §4?

sure.

> 5. Section 5:
> 
>An entity 

[OPSAWG] John Scudder's No Objection on draft-ietf-opsawg-finding-geofeeds-10: (with COMMENT)

[John Scudder via Datatracker]

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 refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-opsawg-finding-geofeeds/



--
COMMENT:
--

Thanks for this document, it looks useful. I have some comments and questions
below.

0. I’d like to thank George Michaelson for a thorough and helpful, not to say
exemplary, shepherd’s report.

1. Section 3:

   Ideally, RPSL would be augmented to define a new RPSL geofeed:
   attribute in the inetnum: class.  Until such time, this document

I, too, am curious as to why this ideal solution isn’t considered achievable.

I’m also a little confused by the way you seem to be arguing with yourself in
this section. First you tell me that change control for RPSL is vested in the
operator community (by implication, not the IETF). A few paragraphs later you
say:

   While we leave global agreement of RPSL modification to the relevant
   parties, we specify that a proper geofeed: attribute in the inetnum:
   class MUST be "geofeed: ", and MUST be followed by a single URL which

Is it up to them? Or is it up to you? I don’t get it. I mean, I’m fine with
what you’ve specced, but when you fence it off with disclaimers that say RPSL
modification isn’t up to you, it leaves me confused.

Perhaps your point is that the IETF gets to specify the geofeed: attribute, but
only the RIRs get to decide when they will start using it? This is generally
true of everything the IETF does, of course, but OK. But if that’s what you
mean, it really wasn’t clear to me from reading the text.

By the way, I bet you should expand “RIR“ on first use.

2. Section 3:

   Until all producers of inetnum:s, i.e. the RIRs, state that they have
   migrated to supporting a geofeed: attribute, consumers looking at
   inetnum:s to find geofeed URLs MUST be able to consume both the
   remarks: and geofeed: forms.  This not only implies that the RIRs
   support the geofeed: attribute, but that all registrants have
   migrated any inetnum:s from remarks: use to geofeed:s.

The referent of “this” in the last sentence isn’t clear. Maybe you mean
“migrated”? Rewriting as ‘“Migrated” not only implies…’ would clarify, if so.

3. Section 3:

   Any particular inetnum: object MUST have at most, one geofeed
   reference, whether a remarks: or a proper geofeed: attribute when it
   is implemented.  If there is more than one, all are ignored.

This makes me think the geofeed: attribute will never, ever be adopted, because
you’ve just created a flag day requirement. Why not permit both the remarks:
and geofeed: versions to enable transition? Presumably you'd need some
tie-break rule in case they're pointing different places, but that doesn't seem
like a deal-breaker.

4. Section 5:

   If and only if the geofeed file is not signed per Section 4, then
   multiple inetnum: objects MAY refer to the same geofeed file, and the
   consumer MUST use only geofeed lines where the prefix is covered by
   the address range of the inetnum: object they have followed.

Presumably this only works with unsigned geofeeds because you’re implicitly
requiring that the geofeed file be signed only once. Is there any particular
driver for this sign-only-once requirement? On a cursory review of §4, I don’t
see anything that would make multiple signatures impracticable.

I note that §3 says

   If a geofeed CSV file describes multiple disjoint ranges of IP
   address space, there are likely to be geofeed references from
   multiple inetnum: objects.

While the text in §5 doesn’t actually give the lie to this quote (since I can
read it as “if an unsigned geofeed CSV file…”) it does seem like the document
is pulling in two different directions.

At the very least, if there is a requirement that only a single signature be
present in a geofeed file, can you say that explicitly in §4?

5. Section 5:

   An entity fetching geofeed data using these mechanisms MUST NOT do
   frequent real-time look-ups to prevent load on RPSL and geofeed
   servers.  [RFC8805] Section 3.4 suggests use of the [RFC7234] HTTP

Nit: I think you need a comma between “look-ups” and “to”. Or re-word as “To
prevent undue load on RPSL and geofeed servers, an entity fetching geofeed data
using these mechanisms MUST NOT do frequent real-time look-ups.” (I also added
“undue” because of course every transaction induces SOME load.)

6. General Comment:

While I notice some reviewers have expressed discomfort with the 

Re: [OPSAWG] Éric Vyncke's No Objection on draft-ietf-opsawg-finding-geofeeds-10: (with COMMENT)

[Randy Bush]

> -- 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 when both "remarks: Geofeed" and "geofeed" are present but
> differ be mentioned ?

you want more/other than

   Any particular inetnum: object MUST have at most, one geofeed
   reference, whether a remarks: or a proper geofeed: attribute when it
   is implemented.  If there is more than one, all are ignored.

> -- Section 4 --
> What happens if the public key of the certificate is changed? Should the cert
> serial number be part of the signature? Or at least mention the obvious that
> the signature must be re-executed when the cert if changed (e.g., in
> section 5).

added

   If the geofeed file is signed, and the signer's certificate changes,
   the signature in the geofeed file MUST be updated.

> -- Section 5 --
> Is there any reason why the doc shepherd is not acknowledged ?

in what way was this insufficient?

The authors also thank George Michaelson, the document shepherd, ...

> I find the use of the colon in "inetnum:" quite annoying and
> confusing.

so say we all.  but it seems to be the convention in the RPSL docs.

> The use of quotes in the last § of section 3 is easier to read and
> parse

i think we're in RDAP land at that point.  perhaps massimo and/pr ggm,
who are more clued in that space could comment.

> -- Section 3 --
> Do the examples really need to be in IPv4 ? ;-)

i am old

> -- Section 4 --
> The use of "department" in "getting the department with the Hardware
> Security Module" is difficult to understand by non-English native
> readers (at least for me as I had to re-read it twice and guess the
> meaning).

prefer "part of the company?"

randy

___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG] Roman Danyliw's Discuss on draft-ietf-opsawg-finding-geofeeds-10: (with DISCUSS and COMMENT)

[Russ Housley]

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 ; draft-ietf-opsawg-finding-geofe...@ietf.org;
>> opsawg-cha...@ietf.org; Ops Area WG ; George Michaelson
>> 
>> Subject: Re: Roman Danyliw's Discuss on draft-ietf-opsawg-finding-geofeeds-
>> 10: (with DISCUSS and COMMENT)
>> 
>> Roman:
>> 
>> Addressing some of your comments below.  I'm leaving others to my co-
>> authors.
>> 
>>> --
>>> DISCUSS:
>>> --
>>> 
>>> The validation process for the signature computed in Section 4 seems
>>> underspecified.
>>> 
>>> For example, let’s consider the example in Appendix A.  Through a whois
>> query
>>> for 192.0.2.0 one finds a “remarks:Geofeed ” field which
>>> leads to a geofeed file which had the detached CMS signature blob “#
>>> RPKI
>>> Signature: 192.0.2.0/24” depicted at the end of Appendix A.  What
>>> reference or text guides how to validate that signature in the RPKI
>>> (akin to the level of detail in Section 3.3 of RFC7909 or RFC6125)?
>>> 
>>> I’m inferring that the steps would roughly be:
>>> 
>>> ** Download the end-entity certificate identified by the
>>> subjectKeyIdentifier field via the pointer/URI in the
>>> “subjectInfoAccess”  field extracted from the CMS signature blob
>>> 
>>> ** Download the intermediate certificate identified by the
>>> authorityKeyIdentifier field via the pointer/URI in the “caIssuer”
>>> field extracted from the CMS signature blob
>>> 
>>> ** Based on the RIR identified in the whois query, download the RPKI
>>> trust anchor of the RIR
>>> 
>>> ** Validate the certificate chain from the RPKI trust anchor down to
>>> the end-entity certificate.  Check that all of the basicConstraints,
>>> certificatePolicies, etc. are accurate.  Check the CRL.
>>> 
>>> ** Verify that the end-entity certificate contains the IP address of
>>> interest
>>> (192.0.2.0) in the sbgp-ipAddrBlock field
>>> 
>>> ** Validate the signature using the algorithm identified in the CMS
>>> signature blog using the end-entity certificate
>>> 
>>> Is that the process?  Is that stated somewhere in the document or
>>> available via reference?
>> 
>> I suggest the following changes in Section 4:
>> 
>> OLD:
>> 
>>   Validation of the signing certificate needs to ensure that it is part
>>   of the current manifest and that the resources are covered by the
>>   RPKI certificate.
>> 
>>   As the signer specifies the covered RPKI resources relevant to the
>>   signature, the RPKI certificate covering the inetnum: object's
>>   address range is included in the [RFC5652] CMS SignedData
>>   certificates field.
>> 
>>   Identifying the private key associated with the certificate, and
>>   getting the department with the Hardware Security Module (HSM) to
>>   sign the CMS blob is left as an exercise for the implementor.  On the
>>   other hand, verifying the signature requires no complexity; the
>>   certificate, which can be validated in the public RPKI, has the
>>   needed public key.
>> 
>> NEW:
>> 
>>   As the signer specifies the covered RPKI resources relevant to the
>>   signature, the RPKI certificate covering the inetnum: object's
>>   address range is included in the [RFC5652] CMS SignedData
>>   certificates field.
>> 
>>   Identifying the private key associated with the certificate, and
>>   getting the department with the Hardware Security Module (HSM) to
>>   sign the CMS blob is left as an exercise for the implementor.  On the
>>   other hand, verifying the signature requires no complexity; the
>>   certificate, which can be validated in the public RPKI, has the
>>   needed public key.
>> 
>>   The trust anchors for the RIRs are expected to already be available
>>   to the party performing signature validation.  Validation of the CMS
>>   signature on the geofeed file involves:
>> 
>>   1.  Obtain the signer's certificate from an RPKI Repository.  The 
>> certificate
>>   SubjectKeyIdentifier extension [RFC5280] MUST match the
>>   SubjectKeyIdentifier in the CMS SignerInfo SignerIdentifier [RFC5652].
>>   If the key identifiers do not match, then validation MUST fail.
>> 
>>   2. Construct the certification path for the signer's certificate.  All of
>>   the needed certificates are expected to be readily available in the
>>   RPKI Repository.  The certification path MUST be valid according to
>>   the validation algorithm in [RFC5280] and the additional checks
>>   specified in [RFC3779] associated with the IP Address Delegation
>>   certificate extension and the Autonomous System Identifier Delegation
>>   certificate extension.  If certification path validation is 
>> unsuccessful, then
>>   validation 

Re: [OPSAWG] Roman Danyliw's Discuss on draft-ietf-opsawg-finding-geofeeds-10: (with DISCUSS and COMMENT)

[Roman Danyliw]

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 draft-ietf-opsawg-finding-geofeeds-
> 10: (with DISCUSS and COMMENT)
> 
> Roman:
> 
> Addressing some of your comments below.  I'm leaving others to my co-
> authors.
> 
> > --
> > DISCUSS:
> > --
> >
> > The validation process for the signature computed in Section 4 seems
> > underspecified.
> >
> > For example, let’s consider the example in Appendix A.  Through a whois
> query
> > for 192.0.2.0 one finds a “remarks:Geofeed ” field which
> > leads to a geofeed file which had the detached CMS signature blob “#
> > RPKI
> > Signature: 192.0.2.0/24” depicted at the end of Appendix A.  What
> > reference or text guides how to validate that signature in the RPKI
> > (akin to the level of detail in Section 3.3 of RFC7909 or RFC6125)?
> >
> > I’m inferring that the steps would roughly be:
> >
> > ** Download the end-entity certificate identified by the
> > subjectKeyIdentifier field via the pointer/URI in the
> > “subjectInfoAccess”  field extracted from the CMS signature blob
> >
> > ** Download the intermediate certificate identified by the
> > authorityKeyIdentifier field via the pointer/URI in the “caIssuer”
> > field extracted from the CMS signature blob
> >
> > ** Based on the RIR identified in the whois query, download the RPKI
> > trust anchor of the RIR
> >
> > ** Validate the certificate chain from the RPKI trust anchor down to
> > the end-entity certificate.  Check that all of the basicConstraints,
> > certificatePolicies, etc. are accurate.  Check the CRL.
> >
> > ** Verify that the end-entity certificate contains the IP address of
> > interest
> > (192.0.2.0) in the sbgp-ipAddrBlock field
> >
> > ** Validate the signature using the algorithm identified in the CMS
> > signature blog using the end-entity certificate
> >
> > Is that the process?  Is that stated somewhere in the document or
> > available via reference?
> 
> I suggest the following changes in Section 4:
> 
> OLD:
> 
>Validation of the signing certificate needs to ensure that it is part
>of the current manifest and that the resources are covered by the
>RPKI certificate.
> 
>As the signer specifies the covered RPKI resources relevant to the
>signature, the RPKI certificate covering the inetnum: object's
>address range is included in the [RFC5652] CMS SignedData
>certificates field.
> 
>Identifying the private key associated with the certificate, and
>getting the department with the Hardware Security Module (HSM) to
>sign the CMS blob is left as an exercise for the implementor.  On the
>other hand, verifying the signature requires no complexity; the
>certificate, which can be validated in the public RPKI, has the
>needed public key.
> 
> NEW:
> 
>As the signer specifies the covered RPKI resources relevant to the
>signature, the RPKI certificate covering the inetnum: object's
>address range is included in the [RFC5652] CMS SignedData
>certificates field.
> 
>Identifying the private key associated with the certificate, and
>getting the department with the Hardware Security Module (HSM) to
>sign the CMS blob is left as an exercise for the implementor.  On the
>other hand, verifying the signature requires no complexity; the
>certificate, which can be validated in the public RPKI, has the
>needed public key.
> 
>The trust anchors for the RIRs are expected to already be available
>to the party performing signature validation.  Validation of the CMS
>signature on the geofeed file involves:
> 
>1.  Obtain the signer's certificate from an RPKI Repository.  The 
> certificate
>SubjectKeyIdentifier extension [RFC5280] MUST match the
>SubjectKeyIdentifier in the CMS SignerInfo SignerIdentifier [RFC5652].
>If the key identifiers do not match, then validation MUST fail.
> 
>2. Construct the certification path for the signer's certificate.  All of
>the needed certificates are expected to be readily available in the
>RPKI Repository.  The certification path MUST be valid according to
>the validation algorithm in [RFC5280] and the additional checks
>specified in [RFC3779] associated with the IP Address Delegation
>certificate extension and the Autonomous System Identifier Delegation
>certificate extension.  If certification path validation is 
> unsuccessful, then
>validation MUST fail.
> 
>3. Validate the CMS SignedData as specified in [RFC5652] using the
>public key from the validated signer's certificate.  If the 

Re: [OPSAWG]  WG Adoption Call for draft-claise-opsawg-service-assurance-yang-07

[Henk Birkholz]

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 is ready for adoption and for the working 
group to work on.


Authors, please rename the I-D to 
draft-ietf-opsawg-service-assurance-yang-00, keeping the content as is, 
and resubmit.



For the OPSAWG co-chairs,

Henk

On 27.04.21 20:01, Henk Birkholz wrote:

Dear OPSAWG members,

this starts a call for Working Group Adoption for

https://datatracker.ietf.org/doc/html/draft-claise-opsawg-service-assurance-yang-07 



ending on Tuesday, May 18th.

As a reminder, this I-D describes YANG modules intended to facilitate 
the aggregation of an assurance graph about the health of services and 
sub-services in a system of interconnected network devices. To achieve 
that, the I-D defines modules for graph updates about (sub-)services and 
corresponding health and symptom knowledge acquired via assurance 
telemetry.


Please reply with your support and especially any substantive comments 
you may have.



For the OPSAWG co-chairs,

Henk

___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg


___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG]  WG Adoption Call for draft-claise-opsawg-service-assurance-architecture-05

[Henk Birkholz]

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 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-service-assurance-architecture-00, keeping the content 
as is, and resubmit.


Additionally, please continue to discuss the scope of this document and 
its relationship to IBN as well as other topics in an open discussion on 
the list. As highlighted by the comments, service assurance and closed 
loop automation can be in support of various network-related 
requirements. Scoping decisions to that regard will have an impact on 
the shape of this document.



For the OPSAWG co-chairs,

Henk

On 27.04.21 20:00, Henk Birkholz wrote:

Dear OPSAWG members,

this starts a call for Working Group Adoption for

https://datatracker.ietf.org/doc/html/draft-claise-opsawg-service-assurance-architecture-05 



ending on Tuesday, May 18th.

As a reminder, this I-D describes the health of an interconnected system 
of network devices and (sub-)services located in that system. A degraded 
health status is explained via symptom descriptions and the resulting 
interconnected knowledge is aggregated in an assurance graph.


Please reply with your support and especially any substantive comments 
you may have.



For the OPSAWG co-chairs,

Henk

___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg


___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG] Roman Danyliw's Discuss on draft-ietf-opsawg-finding-geofeeds-10: (with DISCUSS and COMMENT)

[Russ Housley]

Roman:

Addressing some of your comments below.  I'm leaving others to my co-authors.

> --
> DISCUSS:
> --
> 
> The validation process for the signature computed in Section 4 seems
> underspecified.
> 
> For example, let’s consider the example in Appendix A.  Through a whois query
> for 192.0.2.0 one finds a “remarks:Geofeed ” field which
> leads to a geofeed file which had the detached CMS signature blob “# RPKI
> Signature: 192.0.2.0/24” depicted at the end of Appendix A.  What reference or
> text guides how to validate that signature in the RPKI (akin to the level of
> detail in Section 3.3 of RFC7909 or RFC6125)?
> 
> I’m inferring that the steps would roughly be:
> 
> ** Download the end-entity certificate identified by the subjectKeyIdentifier
> field via the pointer/URI in the “subjectInfoAccess”  field extracted from the
> CMS signature blob
> 
> ** Download the intermediate certificate identified by the
> authorityKeyIdentifier field via the pointer/URI in the “caIssuer” field
> extracted from the CMS signature blob
> 
> ** Based on the RIR identified in the whois query, download the RPKI trust
> anchor of the RIR
> 
> ** Validate the certificate chain from the RPKI trust anchor down to the
> end-entity certificate.  Check that all of the basicConstraints,
> certificatePolicies, etc. are accurate.  Check the CRL.
> 
> ** Verify that the end-entity certificate contains the IP address of interest
> (192.0.2.0) in the sbgp-ipAddrBlock field
> 
> ** Validate the signature using the algorithm identified in the CMS signature
> blog using the end-entity certificate
> 
> Is that the process?  Is that stated somewhere in the document or available 
> via
> reference?

I suggest the following changes in Section 4:

OLD:

   Validation of the signing certificate needs to ensure that it is part
   of the current manifest and that the resources are covered by the
   RPKI certificate.

   As the signer specifies the covered RPKI resources relevant to the
   signature, the RPKI certificate covering the inetnum: object's
   address range is included in the [RFC5652] CMS SignedData
   certificates field.

   Identifying the private key associated with the certificate, and
   getting the department with the Hardware Security Module (HSM) to
   sign the CMS blob is left as an exercise for the implementor.  On the
   other hand, verifying the signature requires no complexity; the
   certificate, which can be validated in the public RPKI, has the
   needed public key.

NEW:

   As the signer specifies the covered RPKI resources relevant to the
   signature, the RPKI certificate covering the inetnum: object's
   address range is included in the [RFC5652] CMS SignedData
   certificates field.

   Identifying the private key associated with the certificate, and
   getting the department with the Hardware Security Module (HSM) to
   sign the CMS blob is left as an exercise for the implementor.  On the
   other hand, verifying the signature requires no complexity; the
   certificate, which can be validated in the public RPKI, has the
   needed public key.

   The trust anchors for the RIRs are expected to already be available
   to the party performing signature validation.  Validation of the CMS
   signature on the geofeed file involves:

   1.  Obtain the signer's certificate from an RPKI Repository.  The certificate
   SubjectKeyIdentifier extension [RFC5280] MUST match the
   SubjectKeyIdentifier in the CMS SignerInfo SignerIdentifier [RFC5652].
   If the key identifiers do not match, then validation MUST fail.

   2. Construct the certification path for the signer's certificate.  All of
   the needed certificates are expected to be readily available in the
   RPKI Repository.  The certification path MUST be valid according to
   the validation algorithm in [RFC5280] and the additional checks
   specified in [RFC3779] associated with the IP Address Delegation
   certificate extension and the Autonomous System Identifier Delegation
   certificate extension.  If certification path validation is 
unsuccessful, then
   validation MUST fail.

   3. Validate the CMS SignedData as specified in [RFC5652] using the
   public key from the validated signer's certificate.  If the signature
   validation is unsuccessful, then validation MUST fail.

   4. Verify that the IP Address Delegation certificate extension [RFC3779]
   covers the address range of the geofeed file.  If the address range is
   not covered, then validation MUST fail.

   If all of these steps MUST be successful to consider the geofeed file
   signature as valid.

> 
> 
> --
> COMMENT:
> --
> 
> Thank you to Kyle Rose for the 

Re: [OPSAWG] New Version Notification for draft-ietf-opsawg-vpn-common-08.txt

[mohamed.boucadair]

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 draft-ietf-opsawg-vpn-common-08.txt

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)
[Med] Sure. Fixed.

The text "can be assigned to an access" reads odd to me.  With respect to the 
rest of the document, maybe network access is more consistent.
[Med] changed to "VPN network access" for better clarity.

For the input-bw and output-bw, the use of the words upload and download read 
odd to me.
[Med] For me as well, but this is inherited from RFC8299 and RFC8466. I prefer 
to maintain those to ease mapping when RFC8299bis and RFC8466bis are considered.
What about "upstream" and "downstream" instead?

Finally, you removed ccm-priority-type.  You had borrowed this, but I wonder if 
removing this from common causes some other ripples in L2NM.
[Med] This was moved back to the L2NM as we use it there.
  Ultimately, I don't have a problem with this typedef being pulled from its 
canonical source as long as the downstream ramifications are addressed.

Joe
[Med] The changes can be tracked: 
https://github.com/IETF-OPSAWG-WG/lxnm/commit/ab10294cdb24cb147ee0789f76b26395457639a8.
On 5/19/21 09:56, 
mohamed.boucad...@orange.com wrote:

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

Gonzalez de Dios 
;
 Oscar de Dios

;
 Qin WU ;

Qin Wu ; Samier Barguil

;
 samier barguil



Objet : New Version Notification for draft-ietf-opsawg-vpn-common-

08.txt





A new version of I-D, draft-ietf-opsawg-vpn-common-08.txt

has been successfully submitted by Mohamed Boucadair and posted to

the IETF repository.



Name: draft-ietf-opsawg-vpn-common

Revision: 08

Title:A Layer 2/3 VPN Common YANG Model

Document date:2021-05-19

Group:opsawg

Pages:68

URL:https://www.ietf.org/archive/id/draft-ietf-opsawg-

vpn-common-08.txt

Status: https://datatracker.ietf.org/doc/draft-ietf-opsawg-

vpn-common/

Htmlized:   https://datatracker.ietf.org/doc/html/draft-ietf-

opsawg-vpn-common

Htmlized:   https://tools.ietf.org/html/draft-ietf-opsawg-vpn-

common-08

Diff:   https://www.ietf.org/rfcdiff?url2=draft-ietf-opsawg-

vpn-common-08



Abstract:

   This document defines a common YANG module that is meant to be

reused

   by various VPN-related modules such as Layer 3 VPN and Layer 2 VPN

   network models.



Editorial Note (To be removed by RFC Editor)



   Please update these statements within the document with the RFC

   number to be assigned to this document:



   o  "This version of this YANG module is part of RFC ;"



   o  "RFC : A Layer 2/3 VPN Common YANG Model";



   o  reference: RFC 



   Also, please update the "revision" date of the YANG module.









Please note that it may take a couple of minutes from the time of

submission until the htmlized version and diff are available at

tools.ietf.org.



The IETF Secretariat







_



Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc

pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce 
message par erreur, veuillez le signaler

a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
electroniques etant susceptibles d'alteration,

Orange decline toute responsabilite si ce message a ete altere, deforme ou 
falsifie. Merci.



This message and its attachments may contain confidential or privileged 
information that may be protected by law;

they should not be distributed, used or copied without authorisation.

If you have received this email in error, please notify the sender and delete 
this message and its attachments.

As emails may be altered, Orange is not liable for messages that have been 
modified, changed or falsified.

Thank you.

Re: [OPSAWG] New Version Notification for draft-ietf-opsawg-vpn-common-08.txt

[Joe Clarke (jclarke)]

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 document, maybe network access is more consistent.

For the input-bw and output-bw, the use of the words upload and download read 
odd to me.  What about "upstream" and "downstream" instead?

Finally, you removed ccm-priority-type.  You had borrowed this, but I wonder if 
removing this from common causes some other ripples in L2NM.  Ultimately, I 
don't have a problem with this typedef being pulled from its canonical source 
as long as the downstream ramifications are addressed.

Joe

On 5/19/21 09:56, 
mohamed.boucad...@orange.com wrote:

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
Gonzalez de Dios 
;
 Oscar de Dios
;
 Qin WU ;
Qin Wu ; Samier Barguil
;
 samier barguil

Objet : New Version Notification for draft-ietf-opsawg-vpn-common-
08.txt


A new version of I-D, draft-ietf-opsawg-vpn-common-08.txt
has been successfully submitted by Mohamed Boucadair and posted to
the IETF repository.

Name:   draft-ietf-opsawg-vpn-common
Revision:   08
Title:  A Layer 2/3 VPN Common YANG Model
Document date:  2021-05-19
Group:  opsawg
Pages:  68
URL:https://www.ietf.org/archive/id/draft-ietf-opsawg-
vpn-common-08.txt
Status: https://datatracker.ietf.org/doc/draft-ietf-opsawg-
vpn-common/
Htmlized:   https://datatracker.ietf.org/doc/html/draft-ietf-
opsawg-vpn-common
Htmlized:   https://tools.ietf.org/html/draft-ietf-opsawg-vpn-
common-08
Diff:   https://www.ietf.org/rfcdiff?url2=draft-ietf-opsawg-
vpn-common-08

Abstract:
   This document defines a common YANG module that is meant to be
reused
   by various VPN-related modules such as Layer 3 VPN and Layer 2 VPN
   network models.

Editorial Note (To be removed by RFC Editor)

   Please update these statements within the document with the RFC
   number to be assigned to this document:

   o  "This version of this YANG module is part of RFC ;"

   o  "RFC : A Layer 2/3 VPN Common YANG Model";

   o  reference: RFC 

   Also, please update the "revision" date of the YANG module.




Please note that it may take a couple of minutes from the time of
submission until the htmlized version and diff are available at
tools.ietf.org.

The IETF Secretariat





_

Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce 
message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou 
falsifie. Merci.

This message and its attachments may contain confidential or privileged 
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete 
this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been 
modified, changed or falsified.
Thank you.




___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG] New Version Notification for draft-ietf-opsawg-vpn-common-08.txt

[mohamed.boucadair]

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
> Gonzalez de Dios ; Oscar de Dios
> ; Qin WU ;
> Qin Wu ; Samier Barguil
> ; samier barguil
> 
> Objet : New Version Notification for draft-ietf-opsawg-vpn-common-
> 08.txt
> 
> 
> A new version of I-D, draft-ietf-opsawg-vpn-common-08.txt
> has been successfully submitted by Mohamed Boucadair and posted to
> the IETF repository.
> 
> Name: draft-ietf-opsawg-vpn-common
> Revision: 08
> Title:A Layer 2/3 VPN Common YANG Model
> Document date:2021-05-19
> Group:opsawg
> Pages:68
> URL:https://www.ietf.org/archive/id/draft-ietf-opsawg-
> vpn-common-08.txt
> Status: https://datatracker.ietf.org/doc/draft-ietf-opsawg-
> vpn-common/
> Htmlized:   https://datatracker.ietf.org/doc/html/draft-ietf-
> opsawg-vpn-common
> Htmlized:   https://tools.ietf.org/html/draft-ietf-opsawg-vpn-
> common-08
> Diff:   https://www.ietf.org/rfcdiff?url2=draft-ietf-opsawg-
> vpn-common-08
> 
> Abstract:
>This document defines a common YANG module that is meant to be
> reused
>by various VPN-related modules such as Layer 3 VPN and Layer 2 VPN
>network models.
> 
> Editorial Note (To be removed by RFC Editor)
> 
>Please update these statements within the document with the RFC
>number to be assigned to this document:
> 
>o  "This version of this YANG module is part of RFC ;"
> 
>o  "RFC : A Layer 2/3 VPN Common YANG Model";
> 
>o  reference: RFC 
> 
>Also, please update the "revision" date of the YANG module.
> 
> 
> 
> 
> Please note that it may take a couple of minutes from the time of
> submission until the htmlized version and diff are available at
> tools.ietf.org.
> 
> The IETF Secretariat
> 


_

Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce 
message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou 
falsifie. Merci.

This message and its attachments may contain confidential or privileged 
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete 
this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been 
modified, changed or falsified.
Thank you.

___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

[OPSAWG] I-D Action: draft-ietf-opsawg-l3sm-l3nm-09.txt

[internet-drafts]

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
  Oscar Gonzalez de Dios
  Mohamed Boucadair
  Luis Angel Munoz
  Alejandro Aguado
Filename: draft-ietf-opsawg-l3sm-l3nm-09.txt
Pages   : 138
Date: 2021-05-19

Abstract:
   This document defines an L3VPN Network YANG Model (L3NM) that can be
   used for the provisioning of Layer 3 Virtual Private Network (VPN)
   services within a service provider network.  The model provides a
   network-centric view of L3VPN services.

   L3NM is meant to be used by a network controller to derive the
   configuration information that will be sent to relevant network
   devices.  The model can also facilitate the communication between a
   service orchestrator and a network controller/orchestrator.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-opsawg-l3sm-l3nm/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-opsawg-l3sm-l3nm-09
https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-l3sm-l3nm-09

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-opsawg-l3sm-l3nm-09


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

[OPSAWG] I-D Action: draft-ietf-opsawg-vpn-common-08.txt

[internet-drafts]

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
  Oscar Gonzalez de Dios
  Mohamed Boucadair
  Qin Wu
Filename: draft-ietf-opsawg-vpn-common-08.txt
Pages   : 68
Date: 2021-05-19

Abstract:
   This document defines a common YANG module that is meant to be reused
   by various VPN-related modules such as Layer 3 VPN and Layer 2 VPN
   network models.

Editorial Note (To be removed by RFC Editor)

   Please update these statements within the document with the RFC
   number to be assigned to this document:

   o  "This version of this YANG module is part of RFC ;"

   o  "RFC : A Layer 2/3 VPN Common YANG Model";

   o  reference: RFC 

   Also, please update the "revision" date of the YANG module.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-opsawg-vpn-common/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-opsawg-vpn-common-08
https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-vpn-common-08

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-opsawg-vpn-common-08


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG] Draft-ietf-opsawg-sbom-access-01

[Dick Brooks]

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. https://{hostname}/.well-known/sbom 
 
/Vendor/Product/Version/IamtheTimestampedSBOM.spdx

 

I tend to think of GitHub as a litmus test for these type of scenarios. “How 
would this work on GitHub?” 

 

Thanks,

 

Dick Brooks



  Never trust software, always 
verify and report! ™

  
http://www.reliableenergyanalytics.com

Email:   
d...@reliableenergyanalytics.com

Tel: +1 978-696-1788

 

From: OPSAWG  On Behalf Of Patrick Dwyer
Sent: Wednesday, May 19, 2021 8:26 AM
To: Eliot Lear 
Cc: opsawg 
Subject: Re: [OPSAWG] Draft-ietf-opsawg-sbom-access-01

 

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 in 5.2

But I could be missing something.

Pat

 

On Wed, May 19, 2021 at 2:40 AM Eliot Lear mailto:40cisco@dmarc.ietf.org> > wrote:

Hi everyone,

 

This draft corrects some of the YANG and discusses, but does not address a SaaS 
use case.  I don’t think we want to cover that here, but rather that it should 
be covered in some place like the W3C.

 

Please have a gander.  If you don’t like what you see, feel free to propose 
changes.  I’d like to have at least one more version out before our next 
virtual meeting.

 

Eliot

___
OPSAWG mailing list
OPSAWG@ietf.org  
https://www.ietf.org/mailman/listinfo/opsawg

___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG] Draft-ietf-opsawg-sbom-access-01

[Patrick Dwyer]

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 in 5.2

But I could be missing something.

Pat

On Wed, May 19, 2021 at 2:40 AM Eliot Lear 
wrote:

> Hi everyone,
>
> This draft corrects some of the YANG and discusses, but does not address a
> SaaS use case.  I don’t *think* we want to cover that here, but rather
> that it should be covered in some place like the W3C.
>
> Please have a gander.  If you don’t like what you see, feel free to
> propose changes.  I’d like to have at least one more version out before our
> next virtual meeting.
>
> Eliot
> ___
> OPSAWG mailing list
> OPSAWG@ietf.org
> https://www.ietf.org/mailman/listinfo/opsawg
>
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

[OPSAWG] Éric Vyncke's No Objection on draft-ietf-opsawg-finding-geofeeds-10: (with COMMENT)

[Éric Vyncke via Datatracker]

É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 refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-opsawg-finding-geofeeds/



--
COMMENT:
--

Thank you for the work put into this document.

Please find below some non-blocking COMMENT points (but replies would be
appreciated), and some nits.

Thank you to George Michaelson for his shepherd's write-up (including the WG
consensus). Nice to have acknowledged him.

Thank you Jean-Michel Combes for the INT-DIR Last Call review at:
https://datatracker.ietf.org/doc/review-ietf-opsawg-finding-geofeeds-08-intdir-lc-combes-2021-05-14/

The telechat INT-DIR review by Wassim Haddad also seconds a good opinion of
this document.

I hope that this helps to improve the document,

Regards,

-éric

== COMMENTS ==

-- 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.

Should the case when both "remarks: Geofeed" and "geofeed" are present but
differ be mentioned ?

-- Section 4 --
What happens if the public key of the certificate is changed? Should the cert
serial number be part of the signature? Or at least mention the obvious that
the signature must be re-executed when the cert if changed (e.g., in section 5).

-- Section 5 --
Is there any reason why the doc shepherd is not acknowledged ?

== NITS ==

I find the use of the colon in "inetnum:" quite annoying and confusing. The use
of quotes in the last § of section 3 is easier to read and parse

-- Section 3 --
Do the examples really need to be in IPv4 ? ;-)

-- Section 4 --
The use of "department" in "getting the department with the Hardware Security
Module" is difficult to understand by non-English native readers (at least for
me as I had to re-read it twice and guess the meaning).



___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG] [Int-dir] Intdir telechat review of draft-ietf-opsawg-finding-geofeeds-10

[Eric Vyncke (evyncke)]

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" 
, "draft-ietf-opsawg-finding-geofeeds@ietf.org" 

Subject: [Int-dir] Intdir telechat review of 
draft-ietf-opsawg-finding-geofeeds-10

Reviewer: Wassim Haddad
Review result: Ready

Current version is in good shape (note: I first reviewed v08). 

Thanks! 


___
Int-dir mailing list
int-...@ietf.org
https://www.ietf.org/mailman/listinfo/int-dir

___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg