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 "[email protected]" does not match module
revision "2023-02-10".
libyang warn: File name "[email protected]" does not match module
revision "2023-02-10".
Best Regards,
Qiufang
From: alto [mailto:[email protected]] On Behalf Of Jensen Zhang
Sent: Friday, February 17, 2023 12:30 AM
To: [email protected]
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
<[email protected]<mailto:[email protected]>> 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
[email protected]<mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/alto
_______________________________________________
alto mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/alto
