Hi, Jensen, all I have reviewed the new version today, and following are some of my further comments: Regarding sec.5.4.3, I am not sure if the authentication choice is needed. A grouping named alto-server-listen-stack-grouping is defined in the document and uses http-server-parameters and tls-server-parameters grouping definition, I think the authentication is already specified inside the grouping (with conformance to sec.8.3.5 in RFC7285. If the connection is based on the http, following are some related client authentication configuration (expended by http-server-parameters grouping): | | | +--rw client-authentication! {client-auth-supported}? | | | +--rw users {local-users-supported}? | | | +--rw user* [user-id] | | | +--rw user-id string | | | +--rw (auth-type) | | | +--:(basic) | | | +--rw basic {basic-auth}? | | | +--rw user-id? string | | | +--rw password? ianach:crypt-hash If the connection is based on the https, following are some related authentication configuration (expended by tls-server-parameters grouping): | | +--rw client-authentication! {client-auth-supported}? | | | +--rw ca-certs! {client-auth-x509-cert}? | | | | +--rw (local-or-truststore) | | | | +--:(local) {local-definitions-supported}? | | | | | +--rw local-definition | | | | | +--rw certificate* [name] | | | | | +--rw name string | | | | | +--rw cert-data trust-anchor-cert-cms | | | | | +---n certificate-expiration {certificate-expiration-notification}? | | | | | +-- expiration-date yang:date-and-time | | | | +--:(truststore) {central-truststore-supported,certificates}? | | | | +--rw truststore-reference? ts:certificate-bag-ref | | | +--rw ee-certs! {client-auth-x509-cert}? | | | | +--rw (local-or-truststore) | | | | +--:(local) {local-definitions-supported}? | | | | | +--rw local-definition | | | | | +--rw certificate* [name] | | | | | +--rw name string | | | | | +--rw cert-data trust-anchor-cert-cms | | | | | +---n certificate-expiration {certificate-expiration-notification}? | | | | | +-- expiration-date yang:date-and-time | | | | +--:(truststore) {central-truststore-supported,certificates}? | | | | +--rw truststore-reference? ts:certificate-bag-ref | | | +--rw raw-public-keys! {client-auth-raw-public-key}? | | | | +--rw (local-or-truststore) | | | | +--:(local) {local-definitions-supported}? | | | | | +--rw local-definition | | | | | +--rw public-key* [name] | | | | | +--rw name string | | | | | +--rw public-key-format identityref | | | | | +--rw public-key binary | | | | +--:(truststore) {central-truststore-supported,public-keys}? | | | | +--rw truststore-reference? ts:public-key-bag-ref | | | +--rw tls12-psks? empty {client-auth-tls12-psk}? | | | +--rw tls13-epsks? empty {client-auth-tls13-epsk}? So what are we expecting to define this authentication choice?
If there is only one client-id leaf needed inside client list, then why not directly define the client as leaf-list? Or would we like future extension to the client list definition? BTW. There seems to exist some revision inconsistence warnings: libyang warn: File name "ietf-alto-st...@2022-07-11.yang" does not match module revision "2023-02-10". libyang warn: File name "ietf-a...@2022-10-24.yang" does not match module revision "2023-02-10". Best Regards, Qiufang From: alto [mailto:alto-boun...@ietf.org] On Behalf Of Jensen Zhang Sent: Friday, February 17, 2023 12:30 AM To: alto@ietf.org Subject: Re: [alto] I-D Action: draft-ietf-alto-oam-yang-03.txt Hi ALTOers, The revision -03 of draft-ietf-alto-oam-yang has been uploaded. In this new revision, the authors fixed all the YANG syntax issues and made the following changes based on the discussions in WG: - Added the basic data model for ALTO client operation and management - Added resource-level access control (see discussions [1]) - Revised data model for reactive mode data source configuration (see [2]) - Improved and added more examples in the appendix about extending the data model for real implementation - Added security considerations [1] https://mailarchive.ietf.org/arch/msg/alto/NX_Y_nvJrNDj6FIVreRbzzo3XNg/ [2] https://mailarchive.ietf.org/arch/msg/alto/U2LIc1e8zP4Y6yVLnVo7WSzkJmc/ Any comments and feedback are welcomed. Best regards, Jensen On Sat, Feb 11, 2023 at 10:53 AM <internet-dra...@ietf.org<mailto: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 Application-Layer Traffic Optimization WG of the IETF. Title : A Yang Data Model for OAM and Management of ALTO Protocol Authors : Jingxuan Jensen Zhang Dhruv Dhody Kai Gao Roland Schott Filename : draft-ietf-alto-oam-yang-03.txt Pages : 65 Date : 2023-02-10 Abstract: This document defines a YANG data model for Operations, Administration, and Maintenance (OAM) & Management of Application- Layer Traffic Optimization (ALTO) Protocol. The operator can use the data model to create and update ALTO information resources, manage the access control, configure server-to-server communication and server discovery, and collect statistical data. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-alto-oam-yang/ There is also an HTML version available at: https://www.ietf.org/archive/id/draft-ietf-alto-oam-yang-03.html A diff from the previous version is available at: https://author-tools.ietf.org/iddiff?url2=draft-ietf-alto-oam-yang-03 Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts _______________________________________________ alto mailing list alto@ietf.org<mailto:alto@ietf.org> https://www.ietf.org/mailman/listinfo/alto
_______________________________________________ alto mailing list alto@ietf.org https://www.ietf.org/mailman/listinfo/alto