Re: [OPSAWG] CALL FOR ADOPTION: draft-ymbk-opsawg-9092-update

[Job Snijders]

Dear Randy, others,

On Tue, Sep 12, 2023 at 01:36:08PM -0700, Randy Bush wrote:
> 
> ok, i am trying to make some time for this.  thanks for the review!
> 
> > In section 8 'Implementation Status', a reference could be added to
> > https://www.rpki-client.org/. I extended this RPKI validator
> > implementation to have the ability to cryptographically verify a given
> > RPKI-signed Geofeed authenticator. Yay, running code!
> 
> cool.  but may we please have a cite to how to use this for "Finding and
> Using Geofeed Data?"

Perhaps in section 8:

Support to authenticate Geofeed files using the RPKI [HOWTO] was
implemented in [rpki-client].

https://www.rpki-client.org/";>
  
rpki-client





  


https://sobornost.net/~job/using_geofeed_authenticators.txt";>
  
Example on how to use rpki-client to authenticate a signed 
Geofeed


  


> > In section 5 it is unclear why RPKI-RTA and RFC 9323 are compared to
> > each other in a subjective manner about perceived complexity.
> 
> a *comparison* was not intended, and i don't see it there.

Ah, ok. For both RSC and RTA distinct properties are listed such as
"applicable in long run", "usable", "complex code"; if no comparison is
intended I'd just remove the two paragraphs about RTA & RSC.

> how about
> 
> The address range of the signing certificate MUST cover all
> prefixes on the geofeed file it signs.  The certificate MUST NOT
> include the Autonomous System Identifier Delegation certificate
> extension [RFC3779].
> 
> and, for good measure
> 
>The end-entity certificate is issued by the CA.  This certificate
>grants signature authority for one IPv4 address block (192.0.2.0/24).
>Signature authority for AS numbers is not needed for geofeed data
>signatures, so AS numbers MUST NOT be included in the certificate.

Perfect.

> > The example EE certificate in Appendix A erroneously contains a
> > superfluous Subject Information Access AccessDescription pointing
> > towards a RRDP server. RRDP SIA ADs are only expected to appear on CA
> > certificates, not on EE certs. See
> > https://www.rfc-editor.org/errata/eid7239 for more information.
> 
> so remove
> 
>SEQUENCE {
> OBJECT IDENTIFIER subjectInfoAccess
>  (1 3 6 1 5 5 7 1 11)
> OCTET STRING, encapsulates {
>  SEQUENCE {
>   SEQUENCE {
>OBJECT IDENTIFIER '1 3 6 1 5 5 7 48 13'
>[6]
> 'https://rrdp.example.net/notification.xml'
> }
>}
>   }
>  }

Yes, that's what I meant. Thanks.

> > I've prepared newly generated certificates which the authors could
> > consider using: https://git.rg.net/randy/draft-9092update/pulls/1/files
> > I also took the liberty to include a missing CRL, and update the example
> > from IPv4 to IPv6 :-) 
> 
> way too much hacking for my taste without adding clarity.  e.g. how does
> an ipv6 sales pitch add clarity for the implementor or user?  let's see
> what other authors think.
> 
> or, to put it another way, what *minimal* change would add significant
> clarity?  in this wg, we're not paid by the word :)

Yeah, apologies for the massive churn, but without the other private
keys I couldn't regenerate just the bits that needed updating. I wish
the original RFC included the CA's private key rather than the EE's
private key. :-)

In this context I have a few comments applicable to
draft-ietf-opsawg-9092-update-01

1/ the new EE certificate uses an 'inherit' element in its RFC3779
   extension, but section 5 disallows the use of 'inherit' in EEs.

2/ given that the example EE was refreshed in -01, the example
   Base64-encoded CMS signature (page 24) also must be refreshed.

3/ might be good to suggest the use of one-time-use EE certs, perhaps:

   The CA MUST sign only one Geofeed with each generated private key and
   MUST generate a new key pair for each new version of the Geofeed. An
   associated EE certificate used in this fashion is termed a
   "one-time-use" EE certificate (see Section 3 of [RFC6487]).

There indeed is no specific need to use IPv6 in the examples, but it is
important that the provided examples comply with the specification and
contain enough information for reproduction to sign & authenticate.

Let me know if any help is needed with the above.

Thanks!

Kind regards,

Job

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

Re: [OPSAWG] [Inventory-yang] [inventory-yang] poll for network inventory base model

[LUIS ANGEL MUÑOZ , Vodafone]

Hello

My vote is for option 1. to adopt draft-ietf-ccamp-network-inventory-yang-02 in 
IVY.

I share the rationale to include its existing synergies with topology models.

Thanks
Luis

De : Inventory-yang 
mailto:inventory-yang-boun...@ietf.org>> De la 
part de maqiufang (A) Envoy? : lundi 28 ao?t 2023 08:22 ? : 
inventory-y...@ietf.org
Cc : ivy-cha...@ietf.org; opsawg 
mailto:opsawg@ietf.org>>; cc...@ietf.org
Objet : [Inventory-yang] [inventory-yang] poll for network inventory base model

Hi Working Group,

It?s now time to start considering how to move forward with the inventory base 
model. We have two different documents that could be used as a starting point 
for our work or, in case the working group believes none of them is ?good 
enough?, we can start a brand new ID.
In case the latter option is chosen, Daniele and I will write a -00 version 
including just the table of content and what we?d like to be covered in each 
section. The document will then be handed over to a pool of authors which will 
bring it till the WG adoption.

Hence, we will have a 3 weeks polling starting today. We decided to make it a 
bit longer than usual because this time the working group is requested to 
review two drafts instead of one.

This mail starts a 3 weeks polling, terminating on September 15th,  where we 
would like the working group to express your preference among:


  1.  Adopt  draft-ietf-ccamp-network-inventory-yang-02 in IVY and evolve it to 
become the network inventory base model
  2.  Adopt draft-wzwb-opsawg-network-inventory-management-03 in IVY and evolve 
it to become the network inventory base model
  3.  Start a brand new document from scratch as described above

In the week after the closure of the polling (between September 18 and 25) we 
will have an IVY interim meeting to discuss the issues/concerns raised during 
the polling ( A separate mail will be sent).

Thank you,

Qiufang and Daniele




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.
-- next part --
An HTML attachment was scrubbed...
URL: 


--

Message: 2
Date: Tue, 5 Sep 2023 01:05:23 +
From: Tianran Zhou 
To: Tianran Zhou ,
"opsawg@ietf.org" 
Cc: "opsawg-cha...@ietf.org" 
Subject: [OPSAWG] Conclusion//RE: IPR poll for
draft-ma-opsawg-ucl-acl-03
Message-ID: 
Content-Type: text/plain; charset="us-ascii"

Hi WG,

We collected replies from all the authors.
All the authors are not aware of any IPR that applies to this draft. And there 
is no question in the mailing list.
So we will proceed.

Best,
Tianran


From: OPSAWG [mailto:opsawg-boun...@ietf.org] On Behalf Of Tianran Zhou
Sent: Friday, September 1, 2023 3:51 PM
To: opsawg@ietf.org
Cc: opsawg-cha...@ietf.org
Subject: [OPSAWG] IPR poll for draft-ma-opsawg-ucl-acl-03

Hi WG,

According to the decision from IETF117, we are going to run the working group 
adoption call for draft-ma-opsawg-ucl-acl-03.
https://datatracker.ietf.org/doc/draft-ma-opsawg-ucl-acl/

Ahead the adoption call, we'd like to poll for known IPR.

Authors and contributors please respond to the mailing list whether or not you 
are aware of any IPR that pertains to this work.

Please state either:

"No, I'm not aware of any IPR that applies to this draft"
or
"Yes, I'm aware of IPR that applies to this draft"

If you are aware of IPR, indicate whether or not this has been disclosed per 
IETF IPR rules (see RFCs 3669, 5378, and 8179).

Cheers,
Tianran
-- next part --
An HTML attachment was scrubbed...
URL: 


--

Message: 3
Date: Tue, 5 Sep 2023 01:12:48 +
From: Tianran Zhou 
To: "opsawg@ietf.org" 
Cc: "opsawg-cha...@ietf.org" 
Subject: [OPSAWG] Working group adoption call for
draft-ma-opsawg-ucl-acl-

Re: [OPSAWG] [inventory-yang] poll for network inventory base model

[Olga Havel]

Hi,

My preference is to go with Option 3 and create a core inventory model that 
could going forward be used for physical, virtual and resource logical 
inventory. I know the initial scope is to look at hardware and software 
components, but as it is a new effort we could provide the core that could be 
extended in the future.

One of the approaches from TMF that we can consider is to use the core 
inventory model that can be extended for all resources (TMF639), where resource 
inventory is split into physical and logical inventory. This is also aligned 
with ITU-T, MEF, ONAP, ...

The new draft should also not replicate the same info that is in other drafts, 
like geo-location, L2 and L3 topology properties, proposed extension to IETF 
topology for digital map etc.

Some comments about the individual drafts:
[1] draft-ietf-ccamp-network-inventory-yang-02
The draft uses the TMF MTOSI Physical Inventory Model approach, and focuses on 
modelling of physical components of the network element, like rack, chassis, 
slot, board and port. The draft is also based on RFC8348 (which defines the 
YANG for single device physical inventory model) and plans to look at how to 
reuse this single device model at controller API by either reusing definitions 
or using schema-mount. I believe these are the correct approaches when the 
scope is physical inventory only, but my understanding is that the goal is to 
have the model for both physical, virtual and software inventory.

[2] draft-wzwb-opsawg-network-inventory-management-03
The draft is focusing on network inventory, and defines it as a list of 
equipment, where equipment can be either physical or virtual. It has other 
properties that do not belong to the physical layer, like licenses, location, 
has links to asset ids. It has some duplications with IETF topology models for 
L2 and L3, geo-location RFC and some properties that may not belong to core 
inventory.

Best Regards,
Olga



From: OPSAWG [mailto:opsawg-boun...@ietf.org] On Behalf Of maqiufang (A)
Sent: Monday 28 August 2023 07:22
To: inventory-y...@ietf.org
Cc: ivy-cha...@ietf.org; opsawg ; cc...@ietf.org
Subject: [OPSAWG] [inventory-yang] poll for network inventory base model

Hi Working Group,

It's now time to start considering how to move forward with the inventory base 
model. We have two different documents that could be used as a starting point 
for our work or, in case the working group believes none of them is "good 
enough", we can start a brand new ID.
In case the latter option is chosen, Daniele and I will write a -00 version 
including just the table of content and what we'd like to be covered in each 
section. The document will then be handed over to a pool of authors which will 
bring it till the WG adoption.

Hence, we will have a 3 weeks polling starting today. We decided to make it a 
bit longer than usual because this time the working group is requested to 
review two drafts instead of one.

This mail starts a 3 weeks polling, terminating on September 15th,  where we 
would like the working group to express your preference among:


  1.  Adopt  draft-ietf-ccamp-network-inventory-yang-02 in IVY and evolve it to 
become the network inventory base model
  2.  Adopt draft-wzwb-opsawg-network-inventory-management-03 in IVY and evolve 
it to become the network inventory base model
  3.  Start a brand new document from scratch as described above

In the week after the closure of the polling (between September 18 and 25) we 
will have an IVY interim meeting to discuss the issues/concerns raised during 
the polling ( A separate mail will be sent).

Thank you,

Qiufang and Daniele

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