Hi Qiufang,
On Fri, Feb 17, 2023 at 5:34 PM maqiufang (A) <maqiufa...@huawei.com> wrote:
> 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?
>
Good point. I think we can reuse the client-authentication config. The
auth-client list can just provide a binding from the client-id to one of
http basic-auth user-id, certificate name, and public key name. It allows a
role in the role list to easily reference an authenticated client using
client-id.
>
>
> 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?
>
I think leaf-list should be enough. Will change it.
>
>
> 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".
>
Could it be caused by the local cache? I don't see the warnings reported by
the datatracker.
Cheers,
Jensen
>
>
> 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> 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
> https://www.ietf.org/mailman/listinfo/alto
>
>
_______________________________________________
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto
