YANG Data Models for the Application-Layer Traffic Optimization (ALTO) Protocol
draft-ietf-alto-oam-yang-17

[Ballot discuss]
Per -15 ballot review:

** Section 8.  Per the guidance on writeable data, aren’t significant parts of alto-server/listen sensitive as one could alter the stored keys for the server or client; or the username/password combinations (in http-server-parameters)?

** Section 8.  Per the guidance about readable data:

-- isn’t tls-server-parameters sensitive since it could contain raw private keys (e.g., ks:inline-or-keystore-symmetric-key-grouping)?

-- Would it be best practice to be able to read all of the authorized users?

Thanks for the response at https://mailarchive.ietf.org/arch/msg/alto/tD88zktK20QDBIbd-jbGt5JJDLc/

> Yes, some groupings in alto-server/listen are also sensitive. But they are
> defined in other RFCs, thus the security considerations in those RFCs also
> apply to them.

This described approach is inconsistent with my observation on how the YANG security template is used.  If there is a path which has security considerations, the issues are typically highlighted regardless of whether there is reuse.  Setting aside that this is a YANG module, my experience with any protocol document is that if there is a mechanism reused by reference and it introduces a relevant security dependency, it would have been cited in the Security Considerations as applicable.  Neither of these approach appear to be taken here.  Is there a reason why not?

[Ballot discuss]
Thanks for working on this specification.

It appears that this specification does not support the https://datatracker.ietf.org/doc/draft-ietf-alto-new-transport/, as it only defines TCP server grouping but the new transport also compatible with HTTP/3 which would be running over QUIC. I would like to discuss why is that so and if there explicit reasoning behind excluding HTTP/3 why is that described? It is no longer the case that QUIC and HTTP/3 is work in progress.

Also supporting Roman's discuss. It is very important that we record under what circumstances ALTO servers are configured to use HTTP instead of HTTPS.

[Ballot comment]
Hi,

Thank you for this well written document and YANG module.

I have a few minor, non-blocking comments, that the authors can address as they wish.

Minor level comments:

(1) p 8, sec 5.1.  Overview of ALTO O&M Data Model

            module: ietf-alto
              +--rw alto!

Making alto a top level presence container isn't a problem, but given the clients are a list anyway, I would have probably just have made alto-server a presence container instead of the top level container.


(2) p 62, sec Appendix A.  Examples of Extending the ALTO O&M Data Model

  The case peeringdb allows the ALTO server to update the server URI to
  the org object of the organization record in PeeringDB.

Perhaps include an informative reference to PeeringDB, or briefly explain what it is.



Nit level comments:

(3) p 3, sec 1.  Introduction

  The basic structure of this YANG data model is guided by Section 16                                                                                                                                                                                                                                                                                                                     
  of [RFC7285] and [RFC7971].  Although the scope of the YANG data                                                                                                                                                                                                                                                                                                                         
  model in this document mainly focuses on the support of the base ALTO                                                                                                                                                                                                                                                                                                                   
  protocol [RFC7285] and the existing ALTO standard extensions:                                                                                                                                                                                                                                                                                                                           
  [RFC8189], [RFC8895], [RFC8896], [RFC9240], [RFC9241], [RFC9275], and                                                                                                                                                                                                                                                                                                                   
  [RFC9439].                                                                                                                                                                                                                                                                                                                                                                               
                                                                                                                                                                                                                                                                                                                                                                                           
I'm not sure the second sentence quite scans, perhaps drop "Although"?   

Regards,
Rob

[Ballot comment]

# Éric Vyncke, INT AD, comments for draft-ietf-alto-oam-yang-15

Thank you for the work put into this document.

Please find below some non-blocking COMMENT points (but replies would be appreciated even if only for my own education).

Special thanks to Mohamed Boucadair for the shepherd's detailed write-up including the WG consensus and the justification of the intended status.

Other thanks to Ted Lemon and Scott Rose, the DNS directorate reviewers, please consider this dns-dir review:
https://datatracker.ietf.org/doc/review-ietf-alto-oam-yang-15-dnsdir-telechat-lemon-2023-10-23/ (authors should probably reply on the email thread)
https://datatracker.ietf.org/doc/review-ietf-alto-oam-yang-14-dnsdir-telechat-rose-2023-10-19/ (and I have seen authors' reply)

I hope that this review helps to improve the document,

Regards,

-éric

# COMMENTS

## NMDA support

I often see YANG RFC stating their support (or lack of) NMDA (RFC 8342), is there any reason why NMDA support is not stated in the text ?

## Section 3 (comments can be ignored)

While it does not hurt, several acronyms are really well-known, hence no need to expand them.

Is "O&M" really used in other documents ? First time that I see this acronym.

## Section 5.1

As the module is prefixed by the ietf-alto namespace, strongly suggest to use another term than "alto" at the root and even more s/alto-client/client/ s/alto-server/server/

## Section 5.3.1.1

As I am trusting the SEC ADs' reviews, I will not ballot a blocking DISCUSS, please remove all HTTP (as opposed to HTTPS) in the text and in the data model itself. Or is "http" used instead of "https" ? But, then why is there a "tls"

Later in the YANG module itself, it seems that the TLS termination would be done in a different node, then how can this TLS termination be configured ? If confirmed, then adding some text in this section would make the reader's task easier.

## Section 5.3.2

I am sorry, but relying on SYSLOG in 2023 seems really legacy...

## Section 7.1

Some identities would benefit if the units where mentioned in the description instead of providing a pointer to another RFC (e.g., for delay-rt), adding a meaningful description (such as "round-trip delay") would also be benefitial for the reader.

## Section A.5

The example should also have a listen to "::/0" for IPv6

# NITS

## Section 4.2 and other places

s/the data models/the data model/ or /the data modules/ as this I-D defines a single data model consisting of several data modules.

[Ballot discuss]
(There were a number of YANG references to chase down.  Please correct my read of the YANG model if I have misunderstood.)

** Implementing mutual TLS/client side certificates (per Section 8.3.5 of RFC7285) appears to need more guidance.  Client EE certificates and client CAs can be specified by the tls:tls-server-group in alto/server-listen-stack/https/tls-server-parameters.  However, it appears to me that there isn’t any way then to later reference them in the alto-server/auth-client section.  When doing username and password authentication via http-server-parameters/client-authentication, there is a common user-id field shared with auth-client/https-auth-client.

** Section 5.4.3.  It appears that there is an http-auth-client for both http and https.  Is this suggesting that it is possible to have authenticated users over unencrypted HTTP.  How does that work securely?  Is this related to Section 8’s “The ietf-alto supports an HTTP listen mode to cover cases where the ALTO server stack does not handle the TLS termination itself, but is handled by a separate component.”  If so, what is the residual risk of this approach?

** Section 8.  Per the guidance on writeable data, aren’t significant parts of alto-server/listen sensitive as one could alter the stored keys for the server or client; or the username/password combinations (in http-server-parameters)?

** Section 8.  Per the guidance about readable data:

-- isn’t tls-server-parameters sensitive since it could contain raw private keys (e.g., ks:inline-or-keystore-symmetric-key-grouping)?

-- Would it be best practice to be able to read all of the authorized users?

[Ballot comment]
Thank you to Rich Salz for the SECDIR review.

** Section A.5.  Per the example:
            "client-authentication": {
              "users": {
                "user": [
                  {
                    "user-id": "alice",
                    "basic": {
                      "user-id": "alice",
                      "password": "$0$p8ssw0rd"
                    }

Isn’t the password supposed to be hashed?  draft-ietf-netconf-http-client-server says password is of type ianach:crypt-hash.

# Document Shepherd Write-Up for draft-ietf-alto-oam-yang

## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?

There is clear consensus to progress this specification.

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?

No controversy was raised during the development of this specification. The authors
were very responsive in taking care of all the comments and making the required changes.

However, there were some aspects that required some cycles before proceeding with the
current design in the spec, e.g.,:

* How to handle data types defined in ALTO IANA registries and whether to consider an
  IANA-maintained YANG module based upon these registries. The decision was to make 
  use of plain identities directly into the base ALO module. The reasoning for this
  decision was that many WG  participants think that the registries won't be updated
  frequently and that having an IANA-maintained module is "overdesign". The Shepherd
  disagrees with that argument as this questions the value of having the registry in 
  the first place, but this is not a blocking point. Let's hope that netmod WG can
  revise the YANG Authors Guidelines to include guidelines for IANA-maintained YANG
  modules.

* Whether and how to supply server-to-server communication for multi-domain
  settings: the decision was to restrict the scope of the discovery, but leave
  the communication out of scope.

* Whether and how to model how ALTO data is aggregated and stored: The decision is
  to consider these as implementation-specific and out of the scope of the base model. 

* Notifications for resource limits: the base module includes specific data nodes
  (notify-res-mem-limit, notify-upd-stream-limit) to trigger notifications. There was
  an alternate proposal to build on RFC 8632 but that was considered as more complex
  to integrate.

During the AD review, text about data sources was softened and only a minimum set
of data nodes to ease grafting future modules is maintained. This approach has the
merit to allow for extensions without making much assumptions on how ALTO can be
grafted to data sources. Generic or specific modules may be thus envisaged to
cover those aspects (out of scope of ALTO).

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
  so, please summarize the areas of conflict in separate email messages to the
  responsible Area Director. (It should be in a separate email because this
  questionnaire is publicly available.)

No.

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?

The only implementation that was disclosed is: https://github.com/openalto/alto.

## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.

YANG. An early review was requested from the yang-doctors.

6. Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

The document follows YANG guidelines, especially those in RFC 8407.

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?

Yes. YANG validation is part of the automated actions set in https://github.com/ietf-wg-alto/draft-ietf-alto-oam-yang.
No errors are to be reported for the YANG modules in the draft.

8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.

The following automated checks are performed:
* pyang for validating YANG modules.
* yangson for validating JSON examples (https://github.com/ietf-wg-alto/draft-ietf-alto-oam-yang/issues/8)

## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?

Yes to all these questions. The document benefited from a fair set of reviews. The
reviews were adequately addressed by the authors.

FWIW, the various reviews from the Shepherd can be tracked at:
* 19 Issues: https://github.com/ietf-wg-alto/draft-ietf-alto-oam-yang/issues?q=is%3Aissue+author%3Aboucadair+
* 33 PRs: https://github.com/ietf-wg-alto/draft-ietf-alto-oam-yang/pulls?q=is%3Apr+author%3Aboucadair+

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?

The following early reviews were solicited for this specification: OPSDIR, YANGDOCTORS,
and TSVART. All the reviews were adequately addressed.

I think these reviews are fair and no subsequent review is needed.

11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?

Proposed Standard.

This status is appropriate given the nature of the specification (YANG modules).
Datatracker state attributes correctly reflect this intent.

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.

Yes. IPR polls were arranged by the Chairs during the call for adoption and also
in the WGLC. All authors replied to the IPR poll:

  * Roland: https://mailarchive.ietf.org/arch/msg/alto/U3qAR9AiT5KwnNJtlo2xAbInP54/
  * Dhruv: https://mailarchive.ietf.org/arch/msg/alto/I1dheuuCa-AeEQgbmn4XWiMwfUc/
  * Jensen: https://mailarchive.ietf.org/arch/msg/alto/48SJEuS46XeWTCHMSadcvcZE9Zs/
  * Qiufang: https://mailarchive.ietf.org/arch/msg/alto/TRPaYSnEiKDIARgNEEFWv2aYeE8/
  * Kai: https://mailarchive.ietf.org/arch/msg/alto/IFFsXP_9lVvQtn-Am6D20tMvlQw/

13. Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front page
    is greater than five, please provide a justification.

Yes.

14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)

Some few nits are displayed by idnits, but those are false positives.

15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].

RFC8189, RFC8895, RFC8896, RFC9240, RFC9241, and RFC9275 are used in the same
way in the document but some of them are listed as normative and others as
informative. This is now fixed: https://github.com/ietf-wg-alto/draft-ietf-alto-oam-yang/issues/75.

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?

N/A

17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.

Yes,

[RFC9275]  Gao, K., Lee, Y., Randriamasy, S., Yang, Y., and J. Zhang,
          "An Extension for Application-Layer Traffic Optimization
          (ALTO): Path Vector", RFC 9275, DOI 10.17487/RFC9275,
          September 2022, .

RFC9275 is cited as normative to be consistent with the other extensions
in the document: RFC8189, RFC8895, RFC8896, RFC9240, and RFC9241:

The basic structure of this YANG data model is guided by Section 16
of [RFC7285] and [RFC7971].  Although the scope of the YANG data
model in this document mainly focuses on the support of the base ALTO
protocol [RFC7285] and the existing ALTO standard extensions
(including [RFC8189], [RFC8895], [RFC8896], [RFC9240], [RFC9241], and
[RFC9275])...

18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?

The document has a normative dependency on the following I-Ds:
* I-D.ietf-netconf-http-client-server
* I-D.ietf-netconf-netconf-client-server
* I-D.ietf-netconf-restconf-client-server
* I-D.ietf-netconf-tcp-client-server
* I-D.ietf-netconf-tls-client-server

However, all these I-Ds were submitted to the IESG for publication.

Note that these I-Ds are imports and must be handled as per the following
    from RFC8407:

    > For every import or include statement that appears in a module
    > contained in the specification that identifies a module in a separate
    > document, a corresponding normative reference to that document MUST
    > appear in the Normative References section.

19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.

No.

20. Describe the document shepherd's review of the IANA considerations section,
    especially with regard to its consistency with the body of the document.
    Confirm that all aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).

This document registers 2 URIs in the "IETF XML Registry" and 2 YANG modules in the "YANG
Module Names" registry. Adequate details to proceed with these actions are
provided in the document.

21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.

N/A.

[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://trac.ietf.org/trac/ops/wiki/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://trac.ietf.org/trac/iesg/wiki/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp79
[8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html
[10]: https://www.rfc-editor.org/info/bcp97
[11]: https://www.rfc-editor.org/rfc/rfc8126.html
[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[15]: https://authors.ietf.org/en/content-guidelines-overview
[16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[17]: https://datatracker.ietf.org/doc/downref/

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

IANA has completed its review of draft-ietf-alto-oam-yang-12. If any part of this review is inaccurate, please let us know.

IANA understands that, upon approval of this document, there are two actions which we must complete.

First, in the ns registry in the IETF XML Registry group located at:

https://www.iana.org/assignments/xml-registry/

two new namespaces will be registered as follows:

ID: yang:ietf-alto
URI: urn:ietf:params:xml:ns:yang:ietf-alto
Filename: [ TBD-at-Registration ]
Reference: [ RFC-to-be ]

ID: yang:ietf-alto-stats
URI: urn:ietf:params:xml:ns:yang:ietf-alto-stats
Filename: [ TBD-at-Registration ]
Reference: [ RFC-to-be ]

As this document requests registrations in an Expert Review or Specification Required (see RFC 8126) registry, we will initiate the required Expert Review via a separate request. Expert review will need to be completed before your document can be approved for publication as an RFC.

Second, in the YANG Module Names registry in the YANG Parameters registry group located at:

https://www.iana.org/assignments/yang-parameters/

two new YANG modules will be registered as follows:

Name: ietf-alto
File: [ TBD-at-Registration ]
Maintained by IANA? N
Namespace: urn:ietf:params:xml:ns:yang:ietf-alto
Prefix: alto
Module:
Reference: [ RFC-to-be ]

Name: ietf-alto-stats
File: [ TBD-at-Registration ]
Maintained by IANA? N
Namespace: urn:ietf:params:xml:ns:yang:ietf-alto-stats
Prefix: alto-stats
Module:
Reference: [ RFC-to-be ]

IANA Note --> While the YANG module names will be registered after the IESG approves the document, the YANG module file will be posted after the RFC Editor notifies us that the document has been published.

We understand that these are the only actions required to be completed upon approval of this document.

NOTE: The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

For definitions of IANA review states, please see:

https://datatracker.ietf.org/help/state/draft/iana-review

Thank you,

David Dong
IANA Services Sr. Specialist

The following Last Call announcement was sent out (ends 2023-10-06):

From: The IESG
To: IETF-Announce
CC: alto-chairs@ietf.org, alto@ietf.org, draft-ietf-alto-oam-yang@ietf.org, martin.h.duke@gmail.com, mohamed.boucadair@orange.com
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (YANG Data Models for the Application-Layer Traffic Optimization (ALTO) Protocol) to Proposed Standard


The IESG has received a request from the Application-Layer Traffic
Optimization WG (alto) to consider the following document: - 'YANG Data
Models for the Application-Layer Traffic Optimization (ALTO)
  Protocol'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2023-10-06. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


  This document defines a YANG data model for Operations,
  Administration, and Maintenance (OAM) & Management of the
  Application-Layer Traffic Optimization (ALTO) Protocol.  The operator
  of an ALTO server can use this data model to (1) set up the ALTO
  server, (2) configure server discovery, (3) create, update and remove
  ALTO information resources, (4) manage the access control of each
  ALTO information resource, and (5) collect statistical data from the
  ALTO server.  The application provider can also use this data model
  to configure ALTO clients to communicate with known ALTO servers.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-alto-oam-yang/



No IPR declarations have been submitted directly on this I-D.


The document contains these normative downward references.
See RFC 3967 for additional information:
    rfc9275: An Extension for Application-Layer Traffic Optimization (ALTO): Path Vector (Experimental - Internet Engineering Task Force (IETF))

# Document Shepherd Write-Up for draft-ietf-alto-oam-yang (16/06/2023)

## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?

There is clear consensus to progress this specification.

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?

No controversy was raised during the development of this specification. The authors
were very responsive in taking care of all the comments and making the required changes.

However, there were some aspects that required some cycles before proceeding with the
current design in the draft, e.g.,:

* How to handle data types defined in ALTO IANA registries and whether to consider an
  IANA-maintained YANG module based upon these registries. The decision was to make 
  use of plain identities directly into the base ALO module. The reasoning for this
  decision was that many WG  participants think that the registries won't be updated
  frequently and that having an IANA-maintained module is "overdesign". The Shepherd
  disagrees with that argument as this questions the value of having the registry in 
  the first place, but this is not a blocking point. Let's hope that netmod WG can
  revise the YANG Authors Guidelines to include guidelines for IANA-maintained YANG
  modules.

* Whether and how to supply server-to-server communication for multi-domain
  settings: the decision was to restrict the scope of the discovery, but leave
  the communication out of scope.

* Whether and how to model how ALTO data is aggregated and stored: The decision is
  to consider these as implementation-specific and out of the scope of the base model. 

* Notifications for resource limits: the base module includes specific data nodes
  (notify-res-mem-limit, notify-upd-stream-limit) to trigger notifications. There was
  an alternate proposal to build on RFC 8632 but that was considered as more complex
  to integrate.

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
  so, please summarize the areas of conflict in separate email messages to the
  responsible Area Director. (It should be in a separate email because this
  questionnaire is publicly available.)

No.

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?

The only implementation that was disclosed is: https://github.com/openalto/alto.

## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.

YANG. An early review was requested from the yang-doctors.

6. Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

The document follows YANG guidelines, especially those in RFC 8407.

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?

Yes. YANG validation is part of the automated actions set in https://github.com/ietf-wg-alto/draft-ietf-alto-oam-yang.
No errors are to be reported for the YANG modules in the draft.

8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.

The following automated checks are performed:
* pyang for validating YANG modules.
* yangson for validating JSON examples (https://github.com/ietf-wg-alto/draft-ietf-alto-oam-yang/issues/8)

## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?

Yes to all these questions. The document benefited from a fair set of reviews. The
reviews were adequately addressed by the authors.

FWIW, the various reviews from the Shepherd can be tracked at:
* 19 Issues: https://github.com/ietf-wg-alto/draft-ietf-alto-oam-yang/issues?q=is%3Aissue+author%3Aboucadair+
* 33 PRs: https://github.com/ietf-wg-alto/draft-ietf-alto-oam-yang/pulls?q=is%3Apr+author%3Aboucadair+

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?

The following early reviews were solicited for this specification: OPSDIR, YANGDOCTORS,
and TSVART. All the reviews were adequately addressed.

I think these reviews are fair and no subsequent review is needed.

11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?

Proposed Standard.

This status is appropriate given the nature of the specification (YANG modules).
Datatracker state attributes correctly reflect this intent.

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.

Yes. IPR polls were arranged by the Chairs during the call for adoption and also
in the WGLC. All authors replied to the IPR poll:

  * Roland: https://mailarchive.ietf.org/arch/msg/alto/U3qAR9AiT5KwnNJtlo2xAbInP54/
  * Dhruv: https://mailarchive.ietf.org/arch/msg/alto/I1dheuuCa-AeEQgbmn4XWiMwfUc/
  * Jensen: https://mailarchive.ietf.org/arch/msg/alto/48SJEuS46XeWTCHMSadcvcZE9Zs/
  * Qiufang: https://mailarchive.ietf.org/arch/msg/alto/TRPaYSnEiKDIARgNEEFWv2aYeE8/
  * Kai: https://mailarchive.ietf.org/arch/msg/alto/IFFsXP_9lVvQtn-Am6D20tMvlQw/

13. Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front page
    is greater than five, please provide a justification.

Yes.

14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)

Some few nits are displayed by idnits, but those are false positives.

15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].

RFC8189, RFC8895, RFC8896, RFC9240, RFC9241, and RFC9275 are used in the same
way in the document but some of them are listed as normative and others as
informative. This is now fixed: https://github.com/ietf-wg-alto/draft-ietf-alto-oam-yang/issues/75.

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?

N/A

17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.

Yes,

[RFC9275]  Gao, K., Lee, Y., Randriamasy, S., Yang, Y., and J. Zhang,
          "An Extension for Application-Layer Traffic Optimization
          (ALTO): Path Vector", RFC 9275, DOI 10.17487/RFC9275,
          September 2022, .

RFC9275 is cited as normative to be consistent with the other extensions
in the document: RFC8189, RFC8895, RFC8896, RFC9240, and RFC9241:

The basic structure of this YANG data model is guided by Section 16
of [RFC7285] and [RFC7971].  Although the scope of the YANG data
model in this document mainly focuses on the support of the base ALTO
protocol [RFC7285] and the existing ALTO standard extensions
(including [RFC8189], [RFC8895], [RFC8896], [RFC9240], [RFC9241], and
[RFC9275])...

18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?

The document has a normative dependency on the following I-Ds:
* I-D.ietf-netconf-http-client-server
* I-D.ietf-netconf-netconf-client-server
* I-D.ietf-netconf-restconf-client-server
* I-D.ietf-netconf-tcp-client-server
* I-D.ietf-netconf-tls-client-server
* I-D.ietf-alto-performance-metrics

However, all these I-Ds were submitted to the IESG for publication.

Note that

(1) The first 5 I-Ds are imports and must be handled as per the following
    from RFC8407:

    > For every import or include statement that appears in a module
    > contained in the specification that identifies a module in a separate
    > document, a corresponding normative reference to that document MUST
    > appear in the Normative References section.

(2)  RFC8407 includes a provision to list I-D.ietf-alto-performance-metrics
    as Informative:

    > If a YANG module
    > contains reference or "description" statements that refer to an
    > I-D, then the I-D is included as an informative reference.

    However, the document follows a consistent approach for listing all
    the extensions (see #17). This is reasonable, especially that
    I-D.ietf-alto-performance-metrics is to be published as RFC SOON.

19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.

No.

20. Describe the document shepherd's review of the IANA considerations section,
    especially with regard to its consistency with the body of the document.
    Confirm that all aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).

This document registers 2 URIs in the "IETF XML Registry" and 2 YANG modules in the "YANG
Module Names" registry. Adequate details to proceed with these actions are
provided in the document.

21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.

N/A.

[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://trac.ietf.org/trac/ops/wiki/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://trac.ietf.org/trac/iesg/wiki/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp79
[8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html
[10]: https://www.rfc-editor.org/info/bcp97
[11]: https://www.rfc-editor.org/rfc/rfc8126.html
[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[15]: https://authors.ietf.org/en/content-guidelines-overview
[16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[17]: https://datatracker.ietf.org/doc/downref/

# Document Shepherd Write-Up for draft-ietf-alto-oam-yang (16/06/2023)

## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?

There is clear consensus to progress this specification.

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?

No controversy was raised during the development of this specification. The authors
were very responsive in taking care of all the comments and making the required changes.

However, there were some aspects that required some cycles before proceeding with the
current design in the draft, e.g.,:

* How to handle data types defined in ALTO IANA registries and whether to consider an
  IANA-maintained YANG module based upon these registries. The decision was to make 
  use of plain identities directly into the base ALO module. The reasoning for this
  decision was that many WG  participants think that the registries won't be updated
  frequently and that having an IANA-maintained module is "overdesign". The Shepherd
  disagrees with that argument as this questions the value of having the registry in 
  the first place, but this is not a blocking point. Let's hope that netmod WG can
  revise the YANG Authors Guidelines to include guidelines for IANA-maintained YANG
  modules.

* Whether and how to supply server-to-server communication for multi-domain
  settings: the decision was to restrict the scope of the discovery, but leave
  the communication out of scope.

* Whether and how to model how ALTO data is aggregated and stored: The decision is
  to consider these as implementation-specific and out of the scope of the base model. 

* Notifications for resource limits: the base module includes specific data nodes
  (notify-res-mem-limit, notify-upd-stream-limit) to trigger notifications. There was
  an alternate proposal to build on RFC 8632 but that was considered as more complex
  to integrate.

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
  so, please summarize the areas of conflict in separate email messages to the
  responsible Area Director. (It should be in a separate email because this
  questionnaire is publicly available.)

No.

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?

The only implementation that was disclosed is: https://github.com/openalto/alto.

## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.

YANG. An early review was requested from the yang-doctors.

6. Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

The document follows YANG guidelines, especially those in RFC 8407.

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?

Yes. YANG validation is part of the automated actions set in https://github.com/ietf-wg-alto/draft-ietf-alto-oam-yang.
No errors are to be reported for the YANG modules in the draft.

8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.

The following automated checks are performed:
* pyang for validating YANG modules.
* yangson for validating JSON examples (https://github.com/ietf-wg-alto/draft-ietf-alto-oam-yang/issues/8)

## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?

Yes to all these questions. The document benefited from a fair set of reviews. The
reviews were adequately addressed by the authors.

FWIW, the various reviews from the Shepherd can be tracked at:
* 19 Issues: https://github.com/ietf-wg-alto/draft-ietf-alto-oam-yang/issues?q=is%3Aissue+author%3Aboucadair+
* 33 PRs: https://github.com/ietf-wg-alto/draft-ietf-alto-oam-yang/pulls?q=is%3Apr+author%3Aboucadair+

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?

The following early reviews were solicited for this specification: OPSDIR, YANGDOCTORS,
and TSVART. All the reviews were adequately addressed.

I think these reviews are fair and no subsequent review is needed.

11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?

Proposed Standard.

This status is appropriate given the nature of the specification (YANG modules).
Datatracker state attributes correctly reflect this intent.

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.

Yes. IPR polls were arranged by the Chairs during the call for adoption and also
in the WGLC. All authors replied to the IPR poll:

  * Roland: https://mailarchive.ietf.org/arch/msg/alto/U3qAR9AiT5KwnNJtlo2xAbInP54/
  * Dhruv: https://mailarchive.ietf.org/arch/msg/alto/I1dheuuCa-AeEQgbmn4XWiMwfUc/
  * Jensen: https://mailarchive.ietf.org/arch/msg/alto/48SJEuS46XeWTCHMSadcvcZE9Zs/
  * Qiufang: https://mailarchive.ietf.org/arch/msg/alto/TRPaYSnEiKDIARgNEEFWv2aYeE8/
  * Kai: https://mailarchive.ietf.org/arch/msg/alto/IFFsXP_9lVvQtn-Am6D20tMvlQw/

13. Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front page
    is greater than five, please provide a justification.

Yes.

14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)

Some few nits are displayed by idnits, but those are false positives.

15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].

RFC8189, RFC8895, RFC8896, RFC9240, RFC9241, and RFC9275 are used in the same
way in the document but some of them are listed as normative and others as
informative. This is now fixed: https://github.com/ietf-wg-alto/draft-ietf-alto-oam-yang/issues/75.

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?

N/A

17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.

Yes,

[RFC9275]  Gao, K., Lee, Y., Randriamasy, S., Yang, Y., and J. Zhang,
          "An Extension for Application-Layer Traffic Optimization
          (ALTO): Path Vector", RFC 9275, DOI 10.17487/RFC9275,
          September 2022, .

RFC9275 is cited as normative to be consistent with the other extensions
in the document: RFC8189, RFC8895, RFC8896, RFC9240, and RFC9241:

The basic structure of this YANG data model is guided by Section 16
of [RFC7285] and [RFC7971].  Although the scope of the YANG data
model in this document mainly focuses on the support of the base ALTO
protocol [RFC7285] and the existing ALTO standard extensions
(including [RFC8189], [RFC8895], [RFC8896], [RFC9240], [RFC9241], and
[RFC9275])...

18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?

The document has a normative dependency on the following I-Ds:
* I-D.ietf-netconf-http-client-server
* I-D.ietf-netconf-netconf-client-server
* I-D.ietf-netconf-restconf-client-server
* I-D.ietf-netconf-tcp-client-server
* I-D.ietf-netconf-tls-client-server
* I-D.ietf-alto-performance-metrics

However, all these I-Ds were submitted to the IESG for publication.

Note that

(1) The first 5 I-Ds are imports and must be handled as per the following
    from RFC8407:

    > For every import or include statement that appears in a module
    > contained in the specification that identifies a module in a separate
    > document, a corresponding normative reference to that document MUST
    > appear in the Normative References section.

(2)  RFC8407 includes a provision to list I-D.ietf-alto-performance-metrics
    as Informative:

    > If a YANG module
    > contains reference or "description" statements that refer to an
    > I-D, then the I-D is included as an informative reference.

    However, the document follows a consistent approach for listing all
    the extensions (see #17). This is reasonable, especially that
    I-D.ietf-alto-performance-metrics is to be published as RFC SOON.

19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.

No.

20. Describe the document shepherd's review of the IANA considerations section,
    especially with regard to its consistency with the body of the document.
    Confirm that all aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).

This document registers 2 URIs in the "IETF XML Registry" and 2 YANG modules in the "YANG
Module Names" registry. Adequate details to proceed with these actions are
provided in the document.

21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.

N/A.

[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://trac.ietf.org/trac/ops/wiki/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://trac.ietf.org/trac/iesg/wiki/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp79
[8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html
[10]: https://www.rfc-editor.org/info/bcp97
[11]: https://www.rfc-editor.org/rfc/rfc8126.html
[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[15]: https://authors.ietf.org/en/content-guidelines-overview
[16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[17]: https://datatracker.ietf.org/doc/downref/

# Document Shepherd Write-Up for draft-ietf-alto-oam-yang (16/06/2023)

## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?

There is clear consensus to progress this specification.

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?

No controversy was raised during the development of this specification. The authors
were very responsive in taking care of all the comments and making the required changes.

However, there were some aspects that required some cycles before proceeding with the
current design in the draft, e.g.,:

* How to handle data types defined in ALTO IANA registries and whether to consider an
  IANA-maintained YANG module based upon these registries. The decision was to make 
  use of plain identities directly into the base ALO module. The reasoning for this
  decision was that many WG  participants think that the registries won't be updated
  frequently and that having an IANA-maintained module is "overdesign". The Shepherd
  disagrees with that argument as this questions the value of having the registry in 
  the first place, but this is not a blocking point. Let's hope that netmod WG can
  revise the YANG Authors Guidelines to include guidelines for IANA-maintained YANG
  modules.

* Whether and how to supply server-to-server communication for multi-domain
  settings: the decision was to restrict the scope of the discovery, but leave
  the communication out of scope.

* Whether and how to model how ALTO data is aggregated and stored: The decision is
  to consider these as implementation-specific and out of the scope of the base model. 

* Notifications for resource limits: the base module includes specific data nodes
  (notify-res-mem-limit, notify-upd-stream-limit) to trigger notifications. There was
  an alternate proposal to build on RFC 8632 but that was considered as more complex
  to integrate.

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
  so, please summarize the areas of conflict in separate email messages to the
  responsible Area Director. (It should be in a separate email because this
  questionnaire is publicly available.)

No.

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?

The only implementation that was disclosed is: https://github.com/openalto/alto.

## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.

YANG. An early review was requested from the yang-doctors.

6. Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

The document follows YANG guidelines, especially those in RFC 8407.

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?

Yes. YANG validation is part of the automated actions set in https://github.com/ietf-wg-alto/draft-ietf-alto-oam-yang.
No errors are to be reported for the YANG modules in the draft.

8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.

The following automated checks are performed:
* pyang for validating YANG modules.
* yangson for validating JSON examples (https://github.com/ietf-wg-alto/draft-ietf-alto-oam-yang/issues/8)

## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?

Yes to all these questions. The document benefited from a fair set of reviews. The
reviews were adequately addressed by the authors.

FWIW, the various reviews from the Shepherd can be tracked at:
* 19 Issues: https://github.com/ietf-wg-alto/draft-ietf-alto-oam-yang/issues?q=is%3Aissue+author%3Aboucadair+
* 33 PRs: https://github.com/ietf-wg-alto/draft-ietf-alto-oam-yang/pulls?q=is%3Apr+author%3Aboucadair+

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?

The following early reviews were solicited for this specification: OPSDIR, YANGDOCTORS,
and TSVART. All the reviews were adequately addressed.

I think these reviews are fair and no subsequent review is needed.

11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?

Proposed Standard.

This status is appropriate given the nature of the specification (YANG modules).
Datatracker state attributes correctly reflect this intent.

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.

Yes. IPR polls were arranged by the Chairs during the call for adoption and also
in the WGLC. All authors replied to the IPR poll:

  * Roland: https://mailarchive.ietf.org/arch/msg/alto/U3qAR9AiT5KwnNJtlo2xAbInP54/
  * Dhruv: https://mailarchive.ietf.org/arch/msg/alto/I1dheuuCa-AeEQgbmn4XWiMwfUc/
  * Jensen: https://mailarchive.ietf.org/arch/msg/alto/48SJEuS46XeWTCHMSadcvcZE9Zs/
  * Qiufang: https://mailarchive.ietf.org/arch/msg/alto/TRPaYSnEiKDIARgNEEFWv2aYeE8/
  * Kai: https://mailarchive.ietf.org/arch/msg/alto/IFFsXP_9lVvQtn-Am6D20tMvlQw/

13. Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front page
    is greater than five, please provide a justification.

Yes.

14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)

Some few nits are displayed by idnits, but those are false positives.

15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].

RFC8189, RFC8895, RFC8896, RFC9240, RFC9241, and RFC9275 are used in the same
way in the document but some of them are listed as normative and others as
informative. This is now fixed: https://github.com/ietf-wg-alto/draft-ietf-alto-oam-yang/issues/75.

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?

N/A

17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.

Yes,

[RFC9275]  Gao, K., Lee, Y., Randriamasy, S., Yang, Y., and J. Zhang,
          "An Extension for Application-Layer Traffic Optimization
          (ALTO): Path Vector", RFC 9275, DOI 10.17487/RFC9275,
          September 2022, .

RFC9275 is cited as normative to be consistent with the other extensions
in the document: RFC8189, RFC8895, RFC8896, RFC9240, and RFC9241:

The basic structure of this YANG data model is guided by Section 16
of [RFC7285] and [RFC7971].  Although the scope of the YANG data
model in this document mainly focuses on the support of the base ALTO
protocol [RFC7285] and the existing ALTO standard extensions
(including [RFC8189], [RFC8895], [RFC8896], [RFC9240], [RFC9241], and
[RFC9275])...

18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?

The document has a normative dependency on the following I-Ds:
* I-D.ietf-netconf-http-client-server
* I-D.ietf-netconf-netconf-client-server
* I-D.ietf-netconf-restconf-client-server
* I-D.ietf-netconf-tcp-client-server
* I-D.ietf-netconf-tls-client-server
* I-D.ietf-alto-performance-metrics

However, all these I-Ds were submitted to the IESG for publication.

Note that

(1) The first 5 I-Ds are imports and must be handled as per the following
    from RFC8407:

    > For every import or include statement that appears in a module
    > contained in the specification that identifies a module in a separate
    > document, a corresponding normative reference to that document MUST
    > appear in the Normative References section.

(2)  RFC8407 includes a provision to list I-D.ietf-alto-performance-metrics
    as Informative:

    > If a YANG module
    > contains reference or "description" statements that refer to an
    > I-D, then the I-D is included as an informative reference.

    However, the document follows a consistent approach for listing all
    the extensions (see #17). This is reasonable, especially that
    I-D.ietf-alto-performance-metrics is to be published as RFC SOON.

19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.

No.

20. Describe the document shepherd's review of the IANA considerations section,
    especially with regard to its consistency with the body of the document.
    Confirm that all aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).

This document registers 2 URIs in the "IETF XML Registry" and 2 YANG modules in the "YANG
Module Names" registry. Adequate details to proceed with these actions are
provided in the document.

21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.

N/A.

[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://trac.ietf.org/trac/ops/wiki/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://trac.ietf.org/trac/iesg/wiki/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp79
[8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html
[10]: https://www.rfc-editor.org/info/bcp97
[11]: https://www.rfc-editor.org/rfc/rfc8126.html
[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[15]: https://authors.ietf.org/en/content-guidelines-overview
[16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[17]: https://datatracker.ietf.org/doc/downref/

# Document Shepherd Write-Up for draft-ietf-alto-oam-yang (16/06/2023)

## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?

There is clear consensus to progress this specification.

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?

No controversy was raised during the development of this specification. The authors
were very responsive in taking care of all the comments and making the required changes.

However, there were some aspects that required some cycles before proceeding with the
current design in the draft, e.g.,:

* How to handle data types defined in ALTO IANA registries and whether to consider an
IANA-maintained YANG module based upon these registries. The decision was to make use of plain
identities directly into the base ALO module. The reasoning for this decision was that many WG
participants think that the registries won't be updated frequently and that having an
IANA-maintained module is "overdesign". The Shepherd disagrees with that argument as
this questions the value of having the registry in the first place, but this is not a
blocking point.

* Whether and how to supply server-to-server communication for multi-domain
settings: the decision was to restrict the scope of the discovery, but leave the communication
out of scope.

* Whether and how to model how alto data is aggregated and stored: The decision is to
consider these as implementation-specific and out of the scope of the base model. 

* Notifications for resource limits: the base module includes specific data nodes
(notify-res-mem-limit, notify-upd-stream-limit) to trigger notifications. There was an
alternate proposal to build on RFC 8632 but that was considered as more complex to integrate.

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
  so, please summarize the areas of conflict in separate email messages to the
  responsible Area Director. (It should be in a separate email because this
  questionnaire is publicly available.)

No.

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?

The only implementation that was disclosed is: https://github.com/openalto/alto.

## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.

YANG. An early review was requested from the yang-doctors.

6. Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

The document follows YANG guidelines, especially those in RFC 8407.

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?

Yes. YANG validation is part of the automated actions set in https://github.com/ietf-wg-alto/draft-ietf-alto-oam-yang.
No errors are to be reported for the YANG modules in the draft.

8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.

The following automated checks are performed:
* pyang for validating YANG modules.
* yangson for validating JSON examples (https://github.com/ietf-wg-alto/draft-ietf-alto-oam-yang/issues/8)

## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?

Yes to all these questions. The document benefited from a fair set of reviews. The
reviews were adequately addressed by the authors.

FWIW, the various reviews from the Shepherd can be tracked at:
* 19 Issues: https://github.com/ietf-wg-alto/draft-ietf-alto-oam-yang/issues?q=is%3Aissue+author%3Aboucadair+
* 33 PRs: https://github.com/ietf-wg-alto/draft-ietf-alto-oam-yang/pulls?q=is%3Apr+author%3Aboucadair+

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?

The following early reviews were solicited for this specification: OPSDIR, YANGDOCTORS,
and TSVART. All the reviews were adequately addressed.

I think these reviews are fair and no subsequent review is needed.

11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?

Proposed Standard.

This status is appropriate given the nature of the specification (YANG modules).
Datatracker state attributes correctly reflect this intent.

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.

Yes. IPR polls were arranged by the Chairs during the call for adoption and also
in the WGLC. All authors replied to the IPR poll:

  * Roland: https://mailarchive.ietf.org/arch/msg/alto/U3qAR9AiT5KwnNJtlo2xAbInP54/
  * Dhruv: https://mailarchive.ietf.org/arch/msg/alto/I1dheuuCa-AeEQgbmn4XWiMwfUc/
  * Jensen: https://mailarchive.ietf.org/arch/msg/alto/48SJEuS46XeWTCHMSadcvcZE9Zs/
  * Qiufang: https://mailarchive.ietf.org/arch/msg/alto/TRPaYSnEiKDIARgNEEFWv2aYeE8/
  * Kai: https://mailarchive.ietf.org/arch/msg/alto/IFFsXP_9lVvQtn-Am6D20tMvlQw/


13. Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front page
    is greater than five, please provide a justification.

Yes.

14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)

Some few nits are displayed by idnits, but those are false positives.

15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].

RFC8189, RFC8895, RFC8896, RFC9240, RFC9241, and RFC9275 are used in the same
way in the document but some of them are listed as normative and others as
informative. This is now fixed:
https://github.com/ietf-wg-alto/draft-ietf-alto-oam-yang/issues/75.


16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?

N/A

17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.

No.

18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?

The document has a normative dependency on the following I-Ds:
* I-D.ietf-netconf-http-client-server
* I-D.ietf-netconf-netconf-client-server
* I-D.ietf-netconf-restconf-client-server
* I-D.ietf-netconf-tcp-client-server
* I-D.ietf-netconf-tls-client-server
* I-D.ietf-alto-performance-metrics

However, all these I-Ds were submitted to IESG for publication.

19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.

No.

20. Describe the document shepherd's review of the IANA considerations section,
    especially with regard to its consistency with the body of the document.
    Confirm that all aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).

This document registers 2 URIs in the "IETF XML Registry" and 2 YANG modules in the "YANG
Module Names" registry. Adequate details to proceed with these actions are
provided in the document.

21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.

N/A.

[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://trac.ietf.org/trac/ops/wiki/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://trac.ietf.org/trac/iesg/wiki/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp79
[8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html
[10]: https://www.rfc-editor.org/info/bcp97
[11]: https://www.rfc-editor.org/rfc/rfc8126.html
[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[15]: https://authors.ietf.org/en/content-guidelines-overview
[16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[17]: https://datatracker.ietf.org/doc/downref/

# Document Shepherd Write-Up for draft-ietf-alto-oam-yang (16/06/2023)

## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?

There is clear consensus to progress this specification.

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?

No controversy was raised during the development of this specification. The authors
were very responsive in taking care of all the comments and making the required changes.

However, there were some aspects that required some cycles before proceeding with the
current design in the draft, e.g.,:

* How to handle data types defined in ALTO IANA registries and whether to consider an
IANA-maintained YANG module based upon these registries. The decision was to make use of plain
identities directly into the base ALO module. The reasoning for this decision was that many WG
participants think that the registries won't be updated frequently and that having an
IANA-maintained module is "overdesign". The Shepherd disagrees with that argument as
this questions the value of having the registry in the first place, but this is not a
blocking point.

* Whether and how to supply server-to-server communication for multi-domain
settings: the decision was to restrict the scope of the discovery, but leave the communication
out of scope.

* Whether and how to model how alto data is aggregated and stored: The decision is to
consider these as implementation-specific and out of the scope of the base model. 

* Notifications for resource limits: the base module includes specific data nodes
(notify-res-mem-limit, notify-upd-stream-limit) to trigger notifications. There was an
alternate proposal to build on RFC 8632 but that was considered as more complex to integrate.

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
  so, please summarize the areas of conflict in separate email messages to the
  responsible Area Director. (It should be in a separate email because this
  questionnaire is publicly available.)

No.

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?

The only implementation that was disclosed is: https://github.com/openalto/alto.

## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.

YANG. An early review was requested from the yang-doctors.

6. Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

The document follows YANG guidelines, especially those in RFC 8407.

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?

Yes. YANG validation is part of the automated actions set in https://github.com/ietf-wg-alto/draft-ietf-alto-oam-yang.
No errors are to be reported for the YANG modules in the draft.

8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.

The following automated checks are performed:
* pyang for validating YANG modules.
* yangson for validating JSON examples (https://github.com/ietf-wg-alto/draft-ietf-alto-oam-yang/issues/8)

## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?

Yes to all these questions. The document benefited from a fair set of reviews. The
reviews were adequately addressed by the authors.

FWIW, the various reviews from the Shepherd can be tracked at:
* 19 Issues: https://github.com/ietf-wg-alto/draft-ietf-alto-oam-yang/issues?q=is%3Aissue+author%3Aboucadair+
* 33 PRs: https://github.com/ietf-wg-alto/draft-ietf-alto-oam-yang/pulls?q=is%3Apr+author%3Aboucadair+

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?

The following early reviews were solicited for this specification: OPSDIR, YANGDOCTORS,
and TSVART. All the reviews were adequately addressed.

I think these reviews are fair and no subsequent review is needed.

11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?

Proposed Standard.

This status is appropriate given the nature of the specification (YANG modules).
Datatracker state attributes correctly reflect this intent.

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.

Yes. IPR polls were arranged by the Chairs during the call for adoption and also
in the WGLC. All authors replied to the IPR poll:

  * Roland: https://mailarchive.ietf.org/arch/msg/alto/U3qAR9AiT5KwnNJtlo2xAbInP54/
  * Dhruv: https://mailarchive.ietf.org/arch/msg/alto/I1dheuuCa-AeEQgbmn4XWiMwfUc/
  * Jensen: https://mailarchive.ietf.org/arch/msg/alto/48SJEuS46XeWTCHMSadcvcZE9Zs/
  * Qiufang: https://mailarchive.ietf.org/arch/msg/alto/TRPaYSnEiKDIARgNEEFWv2aYeE8/
  * Kai: https://mailarchive.ietf.org/arch/msg/alto/IFFsXP_9lVvQtn-Am6D20tMvlQw/


13. Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front page
    is greater than five, please provide a justification.

Yes.

14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)

Some few nits are displayed by idnits, but those are false positives.

15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].

RFC8189, RFC8895, RFC8896, RFC9240, RFC9241, and RFC9275 are used in the same
way in the document but some of them are listed as normative and others as
informative. This is now fixed:
https://github.com/ietf-wg-alto/draft-ietf-alto-oam-yang/issues/75.


16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?

N/A

17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.

No.

18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?

The document has a normative dependency on the following I-Ds:
* I-D.ietf-netconf-http-client-server
* I-D.ietf-netconf-netconf-client-server
* I-D.ietf-netconf-restconf-client-server
* I-D.ietf-netconf-tcp-client-server
* I-D.ietf-netconf-tls-client-server

However, all these I-Ds were submitted to IESG for publication.

19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.

No.

20. Describe the document shepherd's review of the IANA considerations section,
    especially with regard to its consistency with the body of the document.
    Confirm that all aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).

This document registers 2 URIs in the "IETF XML Registry" and 2 YANG modules in the "YANG
Module Names" registry. Adequate details to proceed with these actions are
provided in the document.

21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.

N/A.

[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://trac.ietf.org/trac/ops/wiki/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://trac.ietf.org/trac/iesg/wiki/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp79
[8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html
[10]: https://www.rfc-editor.org/info/bcp97
[11]: https://www.rfc-editor.org/rfc/rfc8126.html
[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[15]: https://authors.ietf.org/en/content-guidelines-overview
[16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[17]: https://datatracker.ietf.org/doc/downref/

# Document Shepherd Write-Up for draft-ietf-alto-oam-yang

## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?

There is clear consensus to progress this specification.

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?

No controversy was raised during the development of this specification from the
WG participants. The authors were very responsive in taking care of the comments
and making the required changes.


3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
  so, please summarize the areas of conflict in separate email messages to the
  responsible Area Director. (It should be in a separate email because this
  questionnaire is publicly available.)

No.

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?

The only implementation that was disclosed is: https://github.com/openalto/alto.

## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.

YANG. An early review was requested from the yang-doctors.

6. Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

The document follows YANG guidelines, especially those in RFC 8407.

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?

Yes. YANG validation is part of the automated actions set in https://github.com/ietf-wg-alto/draft-ietf-alto-oam-yang.
No errors are to be reported for the YANG modules in the draft.

8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.

The following automated checks are performed:
* pyang for validating YANG modules.
* yangson for validating JSON examples (https://github.com/ietf-wg-alto/draft-ietf-alto-oam-yang/issues/8)

## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?

Yes to all these questions. The document benefited from a fair set of reviews. The
reviews were adequately addressed by the authors.

FWIW, the various reviews from the Shepherd can be tracked at:
* 19 Issues: https://github.com/ietf-wg-alto/draft-ietf-alto-oam-yang/issues?q=is%3Aissue+author%3Aboucadair+
* 33 PRs: https://github.com/ietf-wg-alto/draft-ietf-alto-oam-yang/pulls?q=is%3Apr+author%3Aboucadair+

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?

The following early reviews were solicited for this specification: OPSDIR, YANGDOCTORS,
and TSVART. All the reviews were adequately addressed.

I think these reviews are fair and no subsequent review is needed.

11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?

Proposed Standard.

This status is appropriate given the nature of the specification (YANG modules).
Datatracker state attributes correctly reflect this intent.

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.

Yes. IPR polls were arranged by the Chairs during the call for adoption and also
in the WGLC. All authors replied to the IPR poll:

  * Roland: https://mailarchive.ietf.org/arch/msg/alto/U3qAR9AiT5KwnNJtlo2xAbInP54/
  * Dhruv: https://mailarchive.ietf.org/arch/msg/alto/I1dheuuCa-AeEQgbmn4XWiMwfUc/
  * Jensen: https://mailarchive.ietf.org/arch/msg/alto/48SJEuS46XeWTCHMSadcvcZE9Zs/
  * Qiufang: https://mailarchive.ietf.org/arch/msg/alto/TRPaYSnEiKDIARgNEEFWv2aYeE8/
  * Kai: https://mailarchive.ietf.org/arch/msg/alto/IFFsXP_9lVvQtn-Am6D20tMvlQw/


13. Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front page
    is greater than five, please provide a justification.

Yes.

14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)

Some few nits are displayed by idnits, but those are false positives.

15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].

Yes, https://github.com/ietf-wg-alto/draft-ietf-alto-oam-yang/issues/75

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?

N/A

17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.

No.

18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?

The document has a normative dependency on the follwoing I-Ds:
* I-D.ietf-netconf-http-client-server
* I-D.ietf-netconf-netconf-client-server
* I-D.ietf-netconf-restconf-client-server
* I-D.ietf-netconf-tcp-client-server
* I-D.ietf-netconf-tls-client-server

However, all these I-Ds were submitted to IESG for publication.

19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.

No.

20. Describe the document shepherd's review of the IANA considerations section,
    especially with regard to its consistency with the body of the document.
    Confirm that all aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).

This document registers 2 URIs in the "IETF XML Registry" and 2 YANG modules in the "YANG
Module Names" registry. Adequate details to proceed with these actions are
provided in the document.

21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.

N/A.

[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://trac.ietf.org/trac/ops/wiki/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://trac.ietf.org/trac/iesg/wiki/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp79
[8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html
[10]: https://www.rfc-editor.org/info/bcp97
[11]: https://www.rfc-editor.org/rfc/rfc8126.html
[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[15]: https://authors.ietf.org/en/content-guidelines-overview
[16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[17]: https://datatracker.ietf.org/doc/downref/

# Document Shepherd Write-Up for draft-ietf-alto-oam-yang

## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?

There is clear consensus to progress this specification.

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?

No controversy was raised during the development of this specification from the
WG participants. The authors were very responsive in taking care of the comments
and making the required changes.


3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
  so, please summarize the areas of conflict in separate email messages to the
  responsible Area Director. (It should be in a separate email because this
  questionnaire is publicly available.)

No.

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?

The only implementation that was disclosed is: https://github.com/openalto/alto.

## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.

YANG. An early review was requested from the yang-doctors.

6. Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

The document follows YANG guidelines, especially those in RFC 8407.

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?

Yes. YANG validation is part of the automated actions set in https://github.com/ietf-wg-alto/draft-ietf-alto-oam-yang.
No errors are to be reported for the YANG modules in the draft.

8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.

The following automated checks are performed:
* pyang for validating YANG modules.
* yangson for validating JSON examples (https://github.com/ietf-wg-alto/draft-ietf-alto-oam-yang/issues/8)

## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?

Yes to all these questions. The document benefited from a fair set of reviews. The
reviews were adequately addressed by the authors.

FWIW, the various reviews from the Shepherd can be tracked at:
* 19 Issues: https://github.com/ietf-wg-alto/draft-ietf-alto-oam-yang/issues?q=is%3Aissue+author%3Aboucadair+
* 33 PRs: https://github.com/ietf-wg-alto/draft-ietf-alto-oam-yang/pulls?q=is%3Apr+author%3Aboucadair+

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?

The following early reviews were solicited for this specification: OPSDIR, YANGDOCTORS,
and TSVART. All the reviews were adequately addressed.

I think these reviews are fair and no subsequent review is needed.

11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?

Proposed Standard.

This status is appropriate given the nature of the specification (YANG modules).
Datatracker state attributes correctly reflect this intent.

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.

Yes. IPR polls were arranged by the Chairs during the call for adoption and also
in the WGLC. All authors replied to the IPR poll:

  * Roland: https://mailarchive.ietf.org/arch/msg/alto/U3qAR9AiT5KwnNJtlo2xAbInP54/
  * Dhruv: https://mailarchive.ietf.org/arch/msg/alto/I1dheuuCa-AeEQgbmn4XWiMwfUc/
  * Jensen: https://mailarchive.ietf.org/arch/msg/alto/48SJEuS46XeWTCHMSadcvcZE9Zs/
  * Qiufang: https://mailarchive.ietf.org/arch/msg/alto/TRPaYSnEiKDIARgNEEFWv2aYeE8/
  * Kai: https://mailarchive.ietf.org/arch/msg/alto/IFFsXP_9lVvQtn-Am6D20tMvlQw/


13. Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front page
    is greater than five, please provide a justification.

Yes.

14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)

Some few nits are displayed by idnits, but those are false positives.

15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].

Yes, https://github.com/ietf-wg-alto/draft-ietf-alto-oam-yang/issues/75

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?

N/A

17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.

No.

18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?

No.

19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.

No.

20. Describe the document shepherd's review of the IANA considerations section,
    especially with regard to its consistency with the body of the document.
    Confirm that all aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).

This document registers 2 URIs in the "IETF XML Registry" and 2 YANG modules in the "YANG
Module Names" registry. Adequate details to proceed with these actions are
provided in the document.

21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.

N/A.

[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://trac.ietf.org/trac/ops/wiki/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://trac.ietf.org/trac/iesg/wiki/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp79
[8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html
[10]: https://www.rfc-editor.org/info/bcp97
[11]: https://www.rfc-editor.org/rfc/rfc8126.html
[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[15]: https://authors.ietf.org/en/content-guidelines-overview
[16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[17]: https://datatracker.ietf.org/doc/downref/

# Document Shepherd Write-Up for Group Documents

==
# IPR Checks: OK
  * Roland: https://mailarchive.ietf.org/arch/msg/alto/U3qAR9AiT5KwnNJtlo2xAbInP54/
  * Dhruv: https://mailarchive.ietf.org/arch/msg/alto/I1dheuuCa-AeEQgbmn4XWiMwfUc/
  * Jensen: https://mailarchive.ietf.org/arch/msg/alto/48SJEuS46XeWTCHMSadcvcZE9Zs/
  * Qiufang: https://mailarchive.ietf.org/arch/msg/alto/TRPaYSnEiKDIARgNEEFWv2aYeE8/
  * Kai: https://mailarchive.ietf.org/arch/msg/alto/IFFsXP_9lVvQtn-Am6D20tMvlQw/

==

## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
  so, please summarize the areas of conflict in separate email messages to the
  responsible Area Director. (It should be in a separate email because this
  questionnaire is publicly available.)

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?

## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.

6. Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?

8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.

## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?

11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.

13. Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front page
    is greater than five, please provide a justification.

14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)

15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?

17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.

18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?

19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.

20. Describe the document shepherd's review of the IANA considerations section,
    especially with regard to its consistency with the body of the document.
    Confirm that all aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).

21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.

[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://trac.ietf.org/trac/ops/wiki/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://trac.ietf.org/trac/iesg/wiki/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp79
[8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html
[10]: https://www.rfc-editor.org/info/bcp97
[11]: https://www.rfc-editor.org/rfc/rfc8126.html
[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[15]: https://authors.ietf.org/en/content-guidelines-overview
[16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[17]: https://datatracker.ietf.org/doc/downref/