Automatic Peering for SIP Trunks
draft-ietf-asap-sip-auto-peer-41

[Ballot comment]
Hi Kaustubh, Sreekanth, and Cullen,

The change made in 36 vs 32 are great. Thank you for addressing the comments in my previous [1].

Please note that -36 has this warning:

"# read iana-sip-option-tags@2025-12-13.yang (CL)
iana-sip-option-tags@2025-12-13.yang:66: warning: the module seems to use RFC 2119 keywords, but the required text from RFC 8174 is not found or is not correct (see pyang --ietf-help for details)."

You can fix this by adding the  RFC 2119 keywords boilerplate inside the description clause of the IANA module in the Appendix A.

Cheers,
Med

[1] https://mailarchive.ietf.org/arch/msg/asap/G9Z7NNUh60SLuv_6WKyB4fsLzas/

[Ballot comment]
Thanks for addressing my previous DISCUSS and COMMENTs. A few notes left from the diff, but nothing blocking, so I'm updating my ballot.

In the third paragraph of 4.6, "in such statuses" => "in such responses". HTTP responses contain a status code, (header and potentially trailer) fields, and a body.

Throughout, change most occurrences of "HTTPS" to "HTTP" except when talking specifically about the "https" URI scheme (which should be lower-cased). Compare to https://www.rfc-editor.org/rfc/rfc9110.html#https.uri for usage. I see that you've made changes in this direction, but now lower-case some instances where you're talking about the protocol rather than the scheme. The RFC Editor can probably help sort this if needed.

TLS is required, but no particular version? Why not 1.2 or later, or 1.3?

Consider using the line-wrapping format described in RFC8792.

[Ballot discuss]
Thank you for the work put into this document.

As noted in https://datatracker.ietf.org/doc/statement-iesg-handling-ballot-positions-20220121/, a DISCUSS ballot is a request to have a discussion on the point below; I really think that the document would be improved with a change here, but can be convinced otherwise.

# Normative Language in Section 4.6

Why is generation of errors using lower-case "must"? Is this not a requirement? Being distinct from the "MUST" in the same section suggests it's not, but it seems like it ought to be.

# Discussion of HTTP Status Codes in Section 4.6

It's true that HTTP servers can respond with redirect status codes, including the three mentioned in this section, so I think the "may" doesn't need to be all-caps. Servers can also respond with any other HTTP status code, but you don't discuss those. That includes other 3XX status codes besides the three you list. They don't need permission from this document. Rather, servers need guidance about what information to include when they do and clients need guidance about how to handle those responses.

I think what you're actually trying to say here is that servers SHOULD include a Location header if they respond with a 3xx (Redirect) status code. A reference to https://www.rfc-editor.org/rfc/rfc9110.html#name-redirection-3xx for client handling of redirects might be appropriate as well.

[Ballot comment]
"aren't required to enforce the guidelines" seems like too many layers of vague indirection. Is this saying "because those guidelines aren't hard requirements that can be enforced by the peer"?

Thanks for a thorough overview/terminology section. "SIP Auto Peer" is used here without definition. I assume, based on the document name, that it's intended to be the thing in this draft? Maybe introduce it by name in the introduction.

In Section 2.2, I'd drop the discussion of alternative approaches that this draft doesn't take. Either move it to an appendix on alternatives the WG didn't adopt or leave it out entirely.

Throughout, change most occurrences of "HTTPS" to "HTTP" except when talking specifically about the "https" URI scheme (which should be lower-cased). Compare to https://www.rfc-editor.org/rfc/rfc9110.html#https.uri for usage.

Similarly, I'd adjust the language around being "based on HTTP/1.1" and "backward compatible with HTTP/1.1." Rather, you're using the semantics of HTTP (RFC9110), which all HTTP versions support.

Why is RFC3262 mentioned in the prose but not as a reference? Given that the specific SIP extension isn't needed to understand/implement this particular protocol, I'd suggest dropping the over-specific example entirely and simply talking about SIP extensions in general.

TLS is required, but no particular version? Why not 1.2 or later, or 1.3?

Rather than saying "line wraps are for display purposes only", consider using the wrapping format described in RFC8792.

In Section 4.6, "response" should be "status code". The usual format for these would be "400 (Bad Request)"; see https://httpwg.org/admin/editors/style-guide#status-codes for more examples and a helpful reference.

Why is Section 5 entitled "State Deltas" when the point of the section is that this protocol doesn't define a way to communicate state deltas? I'd drop the discussion of what you're not doing, title it "Monitoring for updates", and discuss caching and periodically re-verifying here. Also note that HTTP has mechanisms for only fetching a document if it has changed; see https://www.rfc-editor.org/rfc/rfc9110.html#name-conditional-requests.

I will defer to others whose YANG experience is much greater than mine, but there appear to be many things present in the YANG module which are not described in the prose of this document, including references to RFCs which are not in this document's References. That's likely not correct.

=== NITS FOLLOW ===

- Section 1, "using which" => "by which"
- Section 2.2, "facilitates" => "enables"

[Ballot discuss]
Section 7, paragraph 0
>    This section defines a YANG module [RFC7950] for encoding the service
>    provider capability set.  Section 7.1 provides the tree diagram,
>    which is followed by a description of the various nodes within the
>    module defined in this draft.

If I understand what is being proposed in this draft, the idea is for some entity in the enterprise to query the service provider for a capability set and use that to build the configuration that will be supported by the SIP device. At the same time, the YANG module says:

"The data is published by service providers and consumed by enterprises via standard YANG-based interfaces (RESTCONF, NETCONF, etc.)."

For the config data to be consumed by the enterprise over RESTCONF or NETCONF, the data model cannot be a read-only module. In other words, how can the config data be populated if the model is read-only? Please articulate clearly how the entity in the enterprise sets up the configuration for each SIP device and how the SIP device consumes that configuration. Note: each device in the enterprise needs to have its own customized configuration in most cases.

This document seems to have unresolved IANA issues. Holding a DISCUSS for IANA,
so we can determine next steps during the telechat.

[Ballot comment]
Section 7.2, paragraph 0
>    This section defines the YANG module for the peering capability set
>    document.  This module depends on existing YANG modules that provide
>    common YANG data types [RFC6991] and system management [RFC7317].

There are references to several RFCs in the YANG module that have not been called out here, e.g., RFC 3262, RFC 4028, RFC 3891, etc. Can those be added here? Maybe add a statement - "In addition, this YANG module references [RFC3262], [RFC4028], ...".

Section 7.2, paragraph 20
>      identity tls {
>        base sip-transport-protocol;
>        description
>          "TLS used for SIP requests and responses.";
>      }

Med in his review has already talked about moving some of these identity definitions to an IANA module, which I will not repeat here. Needless to say, I support that DISCUSS from him.

Moreover, TLS is not a transport protocol. It is security on top of a transport protocol. In addition, TLS over UDP would be DTLS, which is not mentioned here. It might help to split the transport protocol from whether security is enabled or not.

Section 7.2, paragraph 26
>      identity tls-version {
>        description
>          "Base for Transport Layer Security versions.";
>      }
>
>      identity "tls-v1-2" {
>        base tls-version;
>        description
>          "Version 1.2 of TLS";
>      }
>
>      identity "tls-v1-3" {
>        base tls-version;
>        description
>          "Version 1.3 of TLS";
>      }

I am sure there is a TLS version defined as part of the IANA registry, and a corresponding YANG model with the version defined. Please use that instead of defining your own.

Section 7.2, paragraph 36
>          leaf not-before {
>            type uint32;
>            units "seconds";
>            mandatory true;
>            description
>              "A node that identifies the unix epoch time at which the
>              parameters in this capability set document are activated or
>              considered valid. This node has been set to mandatory as it
>              is the service provider's responsibility to inform when new
>              peering settings take effect. Without being aware of a start
>              time, the enterprise network will experience failures.";
>          }

Is there a reason why the 'timeticks' or 'timestamp' definition in RFC 6991 cannot be used here?

Section 7.2, paragraph 56
>            leaf-list value {
>              type string;
>              description
>                "A list that encapsulates the DID number range allocated
>                to the enterprise. If the num-ranges 'type' is set to
>                'range' or 'collection', the 'count' node MUST have a
>                valid, non-zero, positive integer. If the number-range
>                'type' value is set to 'range', then, the number in this
>                field represents the first phone number of a DID range
>                allocated to the enterprise. The value of subsequent
>                numbers of the given DID range are obtained by adding one
>                to the value of this field. The number of times we need to
>                add one is indicated by the 'count' field.";

It is not clear to me why value has to be a string. If the number range is a non-zero, positive number, why can't it be a uint32 or uint64?

Section 7.2, paragraph 59
>            leaf ptime {
>              type uint8;
>              units "milliseconds";
>              description
>                "Packetization time in milliseconds.";
>            }

Can this use 'timeticks' definition from RFC 6991?

Section 7.2, paragraph 59
>            leaf parameter {
>              type string;
>              description
>                "Optional parameter for additional media details regarding
>                the encoding.";
>            }

Would any parameter do? Why is this an unbounded string? Are those optional parameters not known? If known, why are they not part of the model?

Section 11, paragraph 1
>    The capability set document contains sensitive information that must
>    be protected from attackers.  A capability set document leak can
>    inflict considerable damage to both the enterprise as well as the
>    service provider.  An attacker that gains access to the capability
>    set document can cause problems in multiple ways.
>
>    There are multiple attack points in the ASAP workflow.  The sections
>    below deal with the different points at which the workflow is
>    vulnerable to attackers.

Med has placed a DISCUSS on this Section also. Needless to say, I support the DISCUSS points he has raised.

However, even as the authors have updated the section, there are a few additional comments. In Section 11.3, YANG Security Considerations, you are missing a complete (second) paragraph on the use of NACM. Please add that.

Section 11.3, paragraph 1
>    There are no particularly sensitive writable data nodes.

Hmm. I am not sure. How about if anyone were to overwrite, say, the host information or the 'registrar' information? Would that not affect the system?

No reference entries found for these items, which were mentioned in the text:
[RFC3688].

Possible DOWNREF from this Standards Track doc to
[iana-crypt-hash-yang-module]. If so, the IESG needs to approve it.

-------------------------------------------------------------------------------
NIT
-------------------------------------------------------------------------------

All comments below are about very minor potential issues that you may choose to
address in some way - or ignore - as you see fit. Some were flagged by
automated tools (via https://github.com/larseggert/ietf-reviewtool), so there
will likely be some false positives. There is no need to let me know what you
did with these suggestions.

Uncited references: [RFC4855], [RFC2833], [RFC4585], [sip-option-parameters],
[RFC4961], [iana-crypt-hash-yang-module], and [RFC7362].

Reference [RFC2833] to RFC2833, which was obsoleted by RFC4733 and RFC4734
(this may be on purpose).

Section 1, paragraph 1
> e and service provider networks. Currently published standards provide a str
>                                  ^^^^^^^^^
A comma may be missing after the conjunctive/linking adverb "Currently".

Section 1, paragraph 2
> ise network, which is usually an error prone exercise. Additionally, such te
>                                  ^^^^^^^^^^^
This word is normally spelled with a hyphen.

Section 2.1, paragraph 0
> eams of calls setup by the SP-SSE and a HTTPS [RFC9110] server. +-----------
>                                      ^
Use "an" instead of "a" if the following word starts with a vowel sound, e.g.
"an article", "an hour".

Section 2.2, paragraph 2
> he enterprise network creates a well formed HTTP GET request to solicit the
>                                ^^^^^^^^^^^
This word is normally spelled with a hyphen.

Section 2.2, paragraph 5
> dd support for such a SIP extension. A HTTPS-based approach would be relativ
>                                      ^
Use "An" instead of "A" if the following word starts with a vowel sound, e.g.
"an article", "an hour".

Use "an" instead of "a" if the following word starts with a vowel sound, e.g.
"an article", "an hour".

"I", paragraph 15
> media cut through if it is known before-hand that early media is expected for
>                                  ^^^^^^^^^^^
This word is normally spelled as one.

"I", paragraph 17
> ack { description "Provisional acknowledgement."; } enum subscribe { descript
>                                ^^^^^^^^^^^^^^^
Do not mix variants of the same word ("acknowledgement" and "acknowledgment")
within a single text.

"I", paragraph 18
> ider. The list of supported methods help to appropriately configure various
>                                    ^^^^
Possible agreement error.

"I", paragraph 19
> e P-Asserted-ID header field or the From header field, whereas others place
>                                    ^^^^
Did you mean "form"?

"I", paragraph 19
> equires the enterprise network to normalize the calling number into E.164 for
>                                  ^^^^^^^^^
Do not mix variants of the same word ("normalize" and "normalise") within a
single text.

"I", paragraph 19
> numbers to E.164 format, while a false leaves the formatting of the calling
>                                ^^^^^^^^^^^^^^
The plural noun "leaves" cannot be used with the article "a". Did you mean "a
false leaf"?

"I", paragraph 23
> zero, positive number, why can't it be a uint32 or uint64? } } } container me
>                                        ^
Use "an" instead of "a" if the following word starts with a vowel sound, e.g.
"an article", "an hour".

"I", paragraph 26
>  provider network and because of sub-optimal media routing, an enterprise dev
>                                  ^^^^^^^^^^^
This word is normally spelled as one.

"I", paragraph 50
> st target, the edge element generates a HTTP GET request. This request can b
>                                      ^
Use "an" instead of "a" if the following word starts with a vowel sound, e.g.
"an article", "an hour".

"I", paragraph 56
> redentials used in building the Authorisation header field provided in respon
>                                ^^^^^^^^^^^^^
Do not mix variants of the same word ("authorisation" and "authorization")
within a single text.

"I", paragraph 59
> se that the service provider may want conceal from other enterprises or custo
>                                  ^^^^^^^^^^^^
The verb "conceal" needs to be in the to-infinitive form.

[Ballot comment]
The document starts out saying privacy is important and HTTPS / TLS should be used, but then I see later in the doc:


    If an enterprise edge element attempts to discover the URL of the endpoints hosted in the ssp1.example.com domain, it issues the following request
    (line wraps are for display purposes only).

        GET /.well-known/webfinger?
            resource=http%3A%2F%2Fssp1.example.com
            rel=sipTrunkingCapability
            HTTP/1.1
        Host: ssp1.example.com


        HTTP/1.1 200 OK
        Access-Control-Allow-Origin: *
        Content-Type: application/jrd+json

        {
          "subject" : "http://ssp1.example.com",
          "links" :
          [

That is two references using http:// and not https://
Is that intentional? If so, should the doc explain this?

[Ballot discuss]
Hi Kaustubh, Sreekanth, and Cullen,

Thank you for the effort put into this specification.

Thanks to Jen Linkova for the OPSDIR review.

I focused my review on the YANG part. Please find below some points for discussion:

# Missing IANA Considerations

Please follow the template provided in https://datatracker.ietf.org/doc/html/draft-ietf-netmod-rfc8407bis-28#name-iana-template-for-documents for IANA actions.

# Missing YANG security considerations

RFC8407bis says:

  Each specification that defines one or more modules MUST contain a
  section that discusses security considerations relevant to those
  modules.

Please follow the template provided in https://datatracker.ietf.org/doc/html/draft-ietf-netmod-rfc8407bis-28#section-3.7

# IANA is the authoritative reference for IANA-maintained module, not RFCs

The RFC does only define the initial version.

NEW:
  import iana-crypt-hash {
    prefix "ianach";
    reference
      https://www.iana.org/assignments/iana-crypt-hash/iana-crypt-hash.xhtml;
  }

That registry reference should be listed as normative.

FWIW, RFC8407bis says:

  For the sake of consistency and ability to support new values while
  maintaining IANA registries as the unique authoritative source of
  information, this document recommends the use of IANA-maintained
  modules as the single source of information.

# Option Tags

CURRENT:
  identity sip-extension {
    description
      "Base identity for SIP extensions/option tags as defined by IANA
      SIP Parameters registry.";
  }

Not sure which registry are we referring to here. Is it https://www.iana.org/assignments/sip-parameters/sip-parameters.xhtml#sip-parameters-4?

If we are expecting the values to be mirrored from that registry, then an IANA-maintained registry for options tags would be needed here.

Not sure why only a subset of options are “hardcoded” in the module.

# Extensibility

CURRENT:
    leaf variant {
      type enumeration {
        enum v1_0 {
          description
            "Variant 1.0 of the capability set document is defined in
            this draft";
        }
      }
      mandatory true;
      description
        "A node that identifies the version number of the capability
        set document. This draft defines the parameters for variant
        1.0; future specifications might define a richer parameter set,
        in which case the variant must be changed to 2.0, 3.0 and so
        on. Future extensions to the capability set document MUST also
        ensure that the corresponding YANG module is defined.";
    }

This seems to be restrictive in case other values are defined in the feature.

FWIW, RFC8407bis says:

  If the set of values is fixed and the data type contents are
  controlled by a single naming authority (e.g., IANA), then an
  enumeration data type SHOULD be used.
 
  …

  If distributed extensibility or hierarchical organization of
  enumerated values is required, then the "identityref" data type
  SHOULD be used instead of an enumeration or other built-in type.

## Same issue with:

CURRENT:
      leaf-list transport {
        type enumeration {
          enum tcp {
            description
              "Transmission Control Protocol";
          }
          enum tls {
            description
              "Transport Layer Security (over TCP)";
          }
          enum udp {
            description
              "User Datagram Protocol";
          }
        }

For example, how this will accommodate support for SIP over QUIC in the future?

## Same issue with if future codecs are to be supported

CURRENT:
        leaf media-format {
          type enumeration {

## Same issue with future TLS versions

CURRENT:
            enum tls_v1_2 {
              description
                "TLS version 1.2.";
            }
            enum tls_v1_3 {
              description
                "TLS version 1.3.";
            }

# Extending the Capability Set: Unknown import

CURRENT:
        import ietf-peering {
          prefix "peering";
        }

        augment "/peering:peering-info" {


The demonstration to illustrate the extensibility of the module should be based on “ietf-sip-auto-peering”. The prefix used in the imported module should be used as well.

# At least 3261 should be listed as Normative (this is needed for SIP methods and so on)

CURRENT;
13.  Informative References
  ..
  [RFC3261]  Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
              A., Peterson, J., Sparks, R., Handley, M., and E.
              Schooler, "SIP: Session Initiation Protocol", RFC 3261,
              DOI 10.17487/RFC3261, June 2002,
              .

Please double check the classification of the reference as I think other entries are normative.

[Ballot discuss]
Hi Kaustubh, Sreekanth, and Cullen,

Thank you for the effort put into this specification.

I focused my review on the YANG part. Please find below some points for discussion:

# Missing IANA Considerations

Please follow the template provided in https://datatracker.ietf.org/doc/html/draft-ietf-netmod-rfc8407bis-28#name-iana-template-for-documents for IANA actions.

# Missing YANG security considerations

RFC8407bis says:

  Each specification that defines one or more modules MUST contain a
  section that discusses security considerations relevant to those
  modules.

Please follow the template provided in https://datatracker.ietf.org/doc/html/draft-ietf-netmod-rfc8407bis-28#section-3.7

# IANA is the authoritative reference for IANA-maintained module, not RFCs

The RFC does only define the initial version.

NEW:
  import iana-crypt-hash {
    prefix "ianach";
    reference
      https://www.iana.org/assignments/iana-crypt-hash/iana-crypt-hash.xhtml;
  }

That registry reference should be listed as normative.

FWIW, RFC8407bis says:

  For the sake of consistency and ability to support new values while
  maintaining IANA registries as the unique authoritative source of
  information, this document recommends the use of IANA-maintained
  modules as the single source of information.

# Option Tags

CURRENT:
  identity sip-extension {
    description
      "Base identity for SIP extensions/option tags as defined by IANA
      SIP Parameters registry.";
  }

Not sure which registry are we referring to here. Is it https://www.iana.org/assignments/sip-parameters/sip-parameters.xhtml#sip-parameters-4?

If we are expecting the values to be mirrored from that registry, then an IANA-maintained registry for options tags would be needed here.

Not sure why only a subset of options are “hardcoded” in the module.

# Extensibility

CURRENT:
    leaf variant {
      type enumeration {
        enum v1_0 {
          description
            "Variant 1.0 of the capability set document is defined in
            this draft";
        }
      }
      mandatory true;
      description
        "A node that identifies the version number of the capability
        set document. This draft defines the parameters for variant
        1.0; future specifications might define a richer parameter set,
        in which case the variant must be changed to 2.0, 3.0 and so
        on. Future extensions to the capability set document MUST also
        ensure that the corresponding YANG module is defined.";
    }

This seems to be restrictive in case other values are defined in the feature.

FWIW, RFC8407bis says:

  If the set of values is fixed and the data type contents are
  controlled by a single naming authority (e.g., IANA), then an
  enumeration data type SHOULD be used.
 
  …

  If distributed extensibility or hierarchical organization of
  enumerated values is required, then the "identityref" data type
  SHOULD be used instead of an enumeration or other built-in type.

## Same issue with:

CURRENT:
      leaf-list transport {
        type enumeration {
          enum tcp {
            description
              "Transmission Control Protocol";
          }
          enum tls {
            description
              "Transport Layer Security (over TCP)";
          }
          enum udp {
            description
              "User Datagram Protocol";
          }
        }

For example, how this will accommodate support for SIP over QUIC in the future?

## Same issue with if future codecs are to be supported

CURRENT:
        leaf media-format {
          type enumeration {

## Same issue with future TLS versions

CURRENT:
            enum tls_v1_2 {
              description
                "TLS version 1.2.";
            }
            enum tls_v1_3 {
              description
                "TLS version 1.3.";
            }

# Extending the Capability Set: Unknown import

CURRENT:
        import ietf-peering {
          prefix "peering";
        }

        augment "/peering:peering-info" {


The demonstration to illustrate the extensibility of the module should be based on “ietf-sip-auto-peering”. The prefix used in the imported module should be used as well.

# At least 3261 should be listed as Normative (this is needed for SIP methods and so on)

CURRENT;
13.  Informative References
  ..
  [RFC3261]  Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
              A., Peterson, J., Sparks, R., Handley, M., and E.
              Schooler, "SIP: Session Initiation Protocol", RFC 3261,
              DOI 10.17487/RFC3261, June 2002,
              .

Please double check the classification of the reference as I think other entries are normative.

[Ballot comment]
# All YANG versions

OLD:
  Yet another example of an alternative mechanism would be for service
  providers and enterprise equipment manufacturers to agree on YANG
  models [RFC6020] that enable configuration to be pushed over NETCONF
  [RFC6241] to enterprise networks from a centralised source hosted in
  service provider networks. 

NEW:
  Yet another example of an alternative mechanism would be for service
  providers and enterprise equipment manufacturers to agree on YANG
  models [RFC6020][RFC7950] that enable configuration to be pushed over NETCONF
  [RFC6241] to enterprise networks from a centralised source hosted in
  service provider networks. 

# No need to repeat the conventions

OLD:
  This section provides a tree diagram [RFC8340] for the "ietf-sip-
  auto-peering" module.  The interpretation of the symbols appearing in
  the tree diagram is as follows:

  *  Brackets "[" and "]" enclose list keys.

  *  Abbreviations before data node names: "rw" means configuration
      (read-write), and "ro" means state data (read-only).

  *  Symbols after data node names: "?" means an optional node, "!"
      means a presence container, and "*" denotes a list and leaf-list.

  *  Parentheses enclose choice and case nodes, and case nodes are also
      marked with a colon (":").

  *  Ellipsis ("...") stands for contents of subtrees that are not
      shown.

NEW:
  The meanings of the symbols in the YANG tree diagrams are defined in
  "YANG Tree Diagrams" [RFC8340].


# Please remove all RFCs citations from the description clauses of the YANG module. A “reference” statement can be used for this, instead.

CURRENT:
          description
            "A node indicating whether the SIP service
            provider expects the enterprise network to use symmetric
            RTP as defined in [@RFC4961]. Enforcement of this
            requirement by service providers on enterprise networks
            is typically useful in scenarios such as media latching
            [@RFC7362]. This node is a boolean type, a value of true
            indicates that the service provider expects the
            enterprise network to use symmetric RTP, whereas a value
            of false indicates that the enterprise network can use
            asymmetric RTP.";

There several similar occurrences to be fixed.

# Underscore

CURRENT:
        enum v1_0 {
          description

..
            enum tls_v1_2 {
              description
                "TLS version 1.2.";
            }
            enum tls_v1_3 {
              description
                "TLS version 1.3.";
            }

RFC84017bis says:
  Uppercase characters, the period character, and
  the underscore character MAY be used if the identifier represents a
  well-known value that uses these characters.

I don’t this the underscore is consistent with that guidance.

# List identifiers

OLD:
      list realms {
        key "name";
        description

NEW:
      list realm {
        key "name";
        description


OLD:
    leaf-list extensions {

NEW:
    leaf-list extension {

RFC8407bis:
  List identifiers SHOULD be singular with the surrounding container
  name plural.  Similarly, "leaf-list" identifiers SHOULD be singular.

Please fix this for similar uses in the module.

# Meaningful identifiers

OLD:
      leaf-list dns {

NEW:
      leaf-list dns-server {

# NETCONF is not normative, any YANG-based interface can leverage the approach in this spec. Idem, 8340 should be listed as informative

CURRENT:

14.  Normative References
  [RFC6241]  Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
              and A. Bierman, Ed., "Network Configuration Protocol
              (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
              .
..
  [RFC8340]  Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams",
              BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018,
              .

Cheers,
Med

[Ballot comment]
Thanks to Joerg Ott for a TSV-ART review. This review touches on a topic
that seems to require additional text:

"The only bit to note is that the document makes just a brief reference to
QUIC in section 4.2.  Is this sufficient?  I am curious if a dedicated ALPN
should be used for this capability retrieval protocol or if general h3 is
deemed sufficient.  The capability descriptions only refer to UDP, TCP,
and TLS, probably because SIP over QUIC wasn‘t defined yet.  Is there a
clear path on how such future transport would be integrated?  If so, would
it make sense to capture this already now?  (I don‘t know how much QUIC
has made it into SIP signaling specifications, while RTP-over-QUIC is
already being defined in AVT.)"

This is a comment, not a DISCUSS, but none-the-less I would like to understand
what approach is being recomended.

I think if deployment of SIP over QUIC is discussed, then some details would be
needed - if not, then the text ought to called-out this as not within scope
of this specific I-D. The current text mentions QUIC but doesn't explain enough
to make this clear.

IESG/Authors/WG Chairs:

IANA has completed its review of draft-ietf-asap-sip-auto-peer-32, which is currently in Last Call, and has the following comments:

We understand that this document doesn't require any registry actions.

While it's often helpful for a document's IANA Considerations section to remain in place upon publication even if there are no actions, if the authors strongly prefer to remove it, we do not object.

If this assessment is not accurate, please respond as soon as possible.

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 2025-09-25):

From: The IESG
To: IETF-Announce
CC: andy@hxr.us, asap-chairs@ietf.org, asap@ietf.org, draft-ietf-asap-sip-auto-peer@ietf.org, marc@petit-huguenin.org, snandaku@cisco.com
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (Automatic Peering for SIP Trunks) to Proposed Standard


The IESG has received a request from the Automatic SIP trunking And Peering
WG (asap) to consider the following document: - 'Automatic Peering for SIP
Trunks'
  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 2025-09-25. 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 specifies a framework that enables enterprise telephony
  Session Initiation Protocol (SIP) networks to solicit and obtain a
  capability set document from a SIP service provider.  The capability
  set document encodes a set of characteristics that enable easy
  peering between enterprise and service provider SIP networks.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-asap-sip-auto-peer/



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

This document was previously sent to the IESG for publication. Between WGLC and IESG Evaluation, it has changed significantly warranting a second round of last calls.

[Ballot comment]
Thanks for addressing my comments.

## Comments

### MIME type

```
478   outlined in section 4.5.  The MIME type for the capability set
479   document defined in this draft is "application/json".  Accordingly,
480   the Accept header field value MUST be restricted only to this MIME
481   type.
```

The modern term for MIME type is "media type". See RFC6838 Section 1.1.

The restriction for the accept header seems not needed for interop as the server can ignore the accept header, and still always return application/json.

You might consider reframing this as:
This document does not specify any content negotiation.
The server MUST set the response content type header to the application/json media type.

### Conditional request

```
483   The generated HTTP GET request MUST NOT use the "Expect" and "Range"
484   header fields.  The requests MUST also not use any conditional
485   request.
```

Consider the comment on the conditional request as it relates to the accept header, and authorization headers and the guidance in section 4.6.

```
545   Capability servers include the capability set documents in the body
546   of a successful response.  Capability set documents MUST be formatted
547   in JSON.  For requests that are incorrectly formatted, the capability
548   server must generate a "400 Bad Request" response.  If the client
549   (enterprise edge element) includes any other MIME types in Accept
550   header field other than "application/json", the capability set must
551   reject the request with a "406 Not Acceptable" response.
```

For a get request, outside of headers, which parameters might a client supply that would result in the 400?

Consider clarifying that 400 and 406 are http status codes for the response, and not the response body.

Is the expected content type for responses with status 400 and 406 also application/json?

Is there a status that is expected to be returned for invalid access tokens?

### SHOULD follow redirects?

```
563   The server SHOULD include the Location header field in such
564   responses.
```

Under which cases can this SHOULD be ignored?
Is the client expected to follow redirects?

### Caching guidance

```
576   intervals to obtain the full capability set document.  It is
577   recommended that capability servers are polled every 24 hours.
```

Is there any need to comment on cache control?

### OAuth is required?

```
379   In the context of the SIP Auto Peer framework, OAuth2.0 MUST be used
380   to carry out client authentication.  Enterprise edge elements that
```

later

```
1861   In scenarios wherein client authentication is carried out using OAuth
1862   resource owner credentials, it is required to ensure that these
1863   credentials cannot be acquired by any unauthorised third-party.  If
```

Are other authentication mechanisms allowed?

### Why is SIP-Connect-TR normative?

What parts of it are required to be understood to implement `draft-ietf-asap-sip-auto-peer` ?

[Ballot comment]
Thanks for addressing my main blocking DISCUSS of section 9.1 (and many of my COMMENTS), there are kept below only for archiving...

I will rely on the YANG doctors review by Ebben Aries due today about the absence of YANG module registration in the IANA considerations (as Mahesh, the OPS AD, did not block on it, I am assuming that my point is not valid though).

Regards

-éric

--- ignore everything below ---

# Previous ballot of Éric Vyncke, INT AD, comments for draft-ietf-asap-sip-auto-peer-20
CC @evyncke

Thank you for the work put into this document.

Please find below two blocking DISCUSS points (easy to address), some non-blocking COMMENT points (but replies would be appreciated even if only for my own education), and some nits.

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

I hope that this review helps to improve the document,

Regards,

-éric


## DISCUSS (blocking)

As noted in https://www.ietf.org/blog/handling-iesg-ballot-positions/, a DISCUSS ballot is just a request to have a discussion on the following topics:

### Section 9.1

Please do not use the Google & Cisco OpenDNS IPv4 addresses but use some addresses out of the test networks or documentation prefix.

### Section 10

Happy to stand corrected, but AFAIK all YANG modules must be registered by the IANA.
## COMMENTS (non-blocking)

### Section 2.3

Isn't the 2nd sentence contradicting the first one in `The capability set document included in a successful response is formatted in JSON. The formatting depends on the value of the "Accept" header field of the HTTP GET request. ` ?

### Section 4.3

Suggest moving the Figure 2 earlier in the text as it is now far after the explanations.

### Section 4.5

Using https://ssp1.example.com/.well-known/ipTrunkingCapability could have been easier or am I missing something ?

### Section 7.2

I will rely on the OPS ADs to check whether the following point is more a DISCUSS, but is there a valid reason of not re-using existing types for IP address & port defined in basis YANG modules (and there is `import ietf-inet-types`) ?

The regex are a little too complex for my brain to check whether all and only RFC 5952 IPv6 addresses can be accepted by the regexp, e.g., 2001::db8::1 should be rejected.

### Section 7.3

`element must be set to the quadruple octet of 0.0.0.0` smells the old legacy IPv4... Why not using "::/0" ?


## NITS (non-blocking / cosmetic)

### Use of SVG graphics

To make a much nicer HTML rendering, suggest using the aasvg too to generate SVG graphics. It is worth a try ;-)

[Ballot discuss]
# Orie Steele, ART AD, comments for draft-ietf-asap-sip-auto-peer-21
CC @OR13

* line numbers:
  - https://author-tools.ietf.org/api/idnits?url=https://www.ietf.org/archive/id/draft-ietf-asap-sip-auto-peer-21.txt&submitcheck=True

* comment syntax:
  - https://github.com/mnot/ietf-comments/blob/main/format.md

* "Handling Ballot Positions":
  - https://ietf.org/about/groups/iesg/statements/handling-ballot-positions/

## Discuss

### Example exchange

```
1828       GET /capdoc?trunkid=trunkent1456 HTTP/1.1
1829       Host: capserver.ssp1.com
1830       Accept:application/peering-info+json
```

`application/peering-info` is not listed in https://www.iana.org/assignments/media-types/media-types.xhtml

and is not `application/json`.

Is there a missing authorization header in this example?

[Ballot comment]

## Comments

### MIME type

```
478   outlined in section 4.5.  The MIME type for the capability set
479   document defined in this draft is "application/json".  Accordingly,
480   the Accept header field value MUST be restricted only to this MIME
481   type.
```

The modern term for MIME type is "media type". See RFC6838 Section 1.1.

The restriction for the accept header seems not needed for interop as the server can ignore the accept header, and still always return application/json.

You might consider reframing this as:
This document does not specify any content negotiation.
The server MUST set the response content type header to the application/json media type.

### Conditional request

```
483   The generated HTTP GET request MUST NOT use the "Expect" and "Range"
484   header fields.  The requests MUST also not use any conditional
485   request.
```

Consider the comment on the conditional request as it relates to the accept header, and authorization headers and the guidance in section 4.6.

```
545   Capability servers include the capability set documents in the body
546   of a successful response.  Capability set documents MUST be formatted
547   in JSON.  For requests that are incorrectly formatted, the capability
548   server must generate a "400 Bad Request" response.  If the client
549   (enterprise edge element) includes any other MIME types in Accept
550   header field other than "application/json", the capability set must
551   reject the request with a "406 Not Acceptable" response.
```

For a get request, outside of headers, which parameters might a client supply that would result in the 400?

Consider clarifying that 400 and 406 are http status codes for the response, and not the response body.

Is the expected content type for responses with status 400 and 406 also application/json?

Is there a status that is expected to be returned for invalid access tokens?

### SHOULD follow redirects?

```
563   The server SHOULD include the Location header field in such
564   responses.
```

Under which cases can this SHOULD be ignored?
Is the client expected to follow redirects?

### Caching guidance

```
576   intervals to obtain the full capability set document.  It is
577   recommended that capability servers are polled every 24 hours.
```

Is there any need to comment on cache control?

### OAuth is required?

```
379   In the context of the SIP Auto Peer framework, OAuth2.0 MUST be used
380   to carry out client authentication.  Enterprise edge elements that
```

later

```
1861   In scenarios wherein client authentication is carried out using OAuth
1862   resource owner credentials, it is required to ensure that these
1863   credentials cannot be acquired by any unauthorised third-party.  If
```

Are other authentication mechanisms allowed?

### Why is SIP-Connect-TR normative?

What parts of it are required to be understood to implement `draft-ietf-asap-sip-auto-peer` ?

[Ballot comment]
# Internet AD comments for draft-ietf-asap-sip-auto-peer-20
CC @ekline

* comment syntax:
  - https://github.com/mnot/ietf-comments/blob/main/format.md

* "Handling Ballot Positions":
  - https://ietf.org/about/groups/iesg/statements/handling-ballot-positions/

## Comments

* I support Mahesh's and Eric's Discuss points.

[Ballot discuss]
This particular identifier rose to a DISCUSS because of the security vulnerability it causes.

Section 7.2, paragraph 24
>            leaf password {
>              type string;
>              description "Password for digest authentication within
>              the realm specified in the preceding leaf.";
>            }
>          }

I do not think it ok for the password to be stored in the clear in the config database. Anyone able to read the config will be able to see the password that has been configured. This should instead be something like this:

        leaf password {
          type ianach:crypt-hash;
          description
    "Password for digest authentication within
              the realm specified in the preceding leaf
              stored as a cryptograhic hash.";
        }

where the prefix ianaich comes from the import statement:

  import iana-crypt-hash {
    prefix ianach;
  }

[Ballot comment]
This document should have had a YANG doctor review done early in the process. Even a Last Call review would have helped. At this stage, even if a review is done, the changes are fairly extensive that another Last Call might be needed. But I will leave that decision with the AD and the WG chairs.

Section 4, paragraph 1
>    This section describes the use of HTTPS as a transport protocol for
>    the peering workflow.  This workflow is based on HTTP/1.1, and as
>    such is compatible with any future version of HTTP that is backward
>    compatible with HTTP/1.1 including HTTP/3 [RFC9114].


First of all thanks to Dan Harkins for his SECDIR review, and to Joel Halpern who did the Gen-ART review, and brings up a similar point.
In his review, Dan points out the lack of mention of TLS version. An explicit mention of TLS versions that should be used would help implementors.

Section 7.2, paragraph 1
>    This section defines the YANG module for the peering capability set
>    document.  This module does not depend on existing YANG modules.  It
>    defines syntax for domain names, IP addresses and port numbers.

I will note that the YANG doctor has not reviewed this document, otherwise they would have flagged most of these issues.

The YANG modules normatively imports RFC6991 module, but does not include its reference anywhere. Please list all RFCs whose YANG modules are referenced in the module.

Section 7.2, paragraph 2
>      import ietf-inet-types {
>        prefix "inet";
>      }

Please add a reference statement to RFC 6991 in the import statement.

Section 7.2, paragraph 3
>        WG Chair: Jean Mahoney
>       
>
>        WG Chair: Gonzalo Salgueiro
>       

We do not list the chairs in the YANG module anymore. Please remove.

Section 7.2, paragraph 7
>        Copyright (c) 2016 IETF Trust and the persons identified as
>        authors of the code.  All rights reserved.

Please update the Copyright year to 2025.

Section 7.2, paragraph 8
>        This version of this YANG module is part of RFC 7895; see
>        the RFC itself for full legal notices.


I doubt that this version of the YANG module is part of RFC 7895 :-). Please change it to RFC XXXX, and put a note somewhere in the draft for the RFC Editor to replace XXXX with the RFC number that is assigned to this document. Something like this:
    This version of this YANG module is part of RFC XXXX
    (https://www.rfc-editor.org/info/rfcXXXX); see the RFC itself
    for full legal notices.

Section 7.2, paragraph 9
>      revision 2025-01-30 {
>        description "Capability set document v2.";
>        reference
>          "draft-ietf-asap-sip-auto-peer-20:
>          Automatic Peering for SIP Trunks";
>      }

Put a note for the RFC Editor to replace the revision number (which is a date), with the date when this document is published as a RFC. Replace the description statement with "Initial Version". Finally, change the reference statement to "RFC XXXX: Automatic Peering for SIP Trunks"

Section 7.2, paragraph 12
>      typedef ipv4-address-port {
>        type string {
>          pattern "(([0-9]|[1-9][0-9]|1[0-9]{2}|2[0-4][0-9]|25[0-5])"
>          + "\\.){3}([0-9]|[1-9][0-9]|1[0-9]{2}|2[0-4][0-9]|25[0-5]):"
>          + "([1-9][0-9]{0,3}|[1-5][0-9]{4}|6[0-4][0-9]{3}|65[0-4][0-9]"
>          + "{2}|655[0-2][0-9]|6553[0-5])";
>        }
>        description "The ipv4-address-port type represents an IPv4
>        address in dotted-quad notation followed by a port number.";
>      }
>
>      typedef ipv6-address-port {
>        type string {
>          pattern "\\[((:|[0-9a-fA-F]{0,4}):)([0-9a-fA-F]{0,4}:){0,5}"
>          + "((([0-9a-fA-F]{0,4}:)?(:|[0-9a-fA-F]{0,4}))|(((25[0-5]|2"
>          + "[0-4][0-9]|[01]?[0-9]?[0-9])\\.){3}(25[0-5]|2[0-4][0-9]|"
>          + "[01]?[0-9]?[0-9])))\\]:([1-9][0-9]{0,3}|[1-5][0-9]{4}|6"
>          + "[0-4][0-9]{3}|65[0-4][0-9]{2}|655[0-2][0-9]|6553[0-5])";
>          pattern "\\[(([^:]+:){6}(([^:]+:[^:]+)|(.*\\..*)))|((([^:]+:)"
>          + "*[^:]+)?::(([^:]+:)*[^:]+)?)\\]:([1-9][0-9]{0,3}|[1-5]"
>          + "[0-9]{4}|6[0-4][0-9]{3}|65[0-4][0-9]{2}|655[0-2][0-9]|6553"
>          + "[0-5])";
>        }
>        description "The ipv6-address type represents an IPv6 address
>        in full, mixed, shortened, and shortened-mixed notation
>        followed by a port number.";
>      }
>
>      typedef ip-address-port {
>        type union {
>          type ipv4-address-port;
>          type ipv6-address-port;
>        }
>        description "The ip-address-port type represents an IP
>        address:port number and is IP version neutral.";
>      }
>
>      typedef domain-name-port {
>        type string {
>          length "1..258";
>          pattern "(((([a-zA-Z0-9_]([a-zA-Z0-9\\-_]){0,61})?[a-zA-Z0-9]"
>          + "\\.)*([a-zA-Z0-9_]([a-zA-Z0-9\\-_]){0,61})?[a-zA-Z0-9]"
>          + "\\.?)|\\.):([1-9][0-9]{0,3}|[1-5][0-9]{4}|6[0-4][0-9]{3}|"
>          + "65[0-4][0-9]{2}|655[0-2][0-9]|6553[0-5])";
>        }
>        description "The domain-name-port type represents a DNS domain
>        name followed by a port number. The name SHOULD be fully
>        qualified whenever possible.";
>      }
>
>      typedef host-port {
>        type union {
>          type ip-address-port;
>          type domain-name-port;
>        }
>        description "The host type represents either an IP address or a
>        DNS domain name followed by a port number.";
>      }

Any reason not to use the definition of 'ipv4-address', ipv6-address', 'ip-address', 'host', and 'domain-name-port' from RFC 6991?

Section 7.2, paragraph 13
>        leaf index {
>          type int32;
>          description "Index for the peering-info set.";
>        }

Can the index be a negative number?

Section 7.2, paragraph 13
>        leaf variant {
>          type string;
>          mandatory true;
>          description "Variant of peering-response document.";
>        }

Why is 'variant' 'mandatory true'? The node definitions in Section 7.3 should be moved under each node, which would help better understand why this leaf needs to be set.

Section 7.2, paragraph 14
>          leaf notBefore {
>            type string;
>            mandatory true;
>            description "Time and date specifying when the parameters
>            specified in this capability set document are considered
>            active or valid.";
>          }

YANG discourages the use of camelcase for identifiers. See Section 4.3.2 of draft-ietf-netmod-rfc8407bis. Instead use 'not-before'. Why 'type string' and not 'type date-and-time' which can ease the comparison?

Section 7.2, paragraph 14
>          leaf location {
>            type string;
>            mandatory true;
>            description "Location of the new version of capability set
>            document.";
>          }
>        }

Helps to explain why the node is 'mandatory true'. The explanation in Section 7.3, which should be moved here, does not explain why it has to be 'mandatory true'.

Section 7.2, paragraph 24
>          leaf-list callControl {
>            type host-port;
>            max-elements 3;
>            description "List of service provider call control servers.";
>          }

Same comment as above on camel case as it applied to this and all the subsequent use of it below.

Section 7.2, paragraph 24
>          leaf-list dns {
>            type inet:ip-address;
>            max-elements 2;
>            description "IP address of the DNS Server(s) hosted by the
>            service provider.";
>          }

Curious mixed use of 'ip-address-port' everywhere else and 'ip-address' here.

Section 7.2, paragraph 26
>          leaf outboundProxy {
>            type host-port;
>            description "SIP Outbound Proxy.";
>          }
>        }
>
>        container call-specs {
>          description "Information about call specifications,
>          restrictions and additional handling criteria for SIP calls
>          between the enterprise and service provider network.";

Section 7.2, paragraph 25
>          leaf earlyMedia {
>            type boolean;
>            description "Flag indicating whether the service provider is
>            expected to deliver early media.";
>          }

What is the default for this boolean value? Also, it helps to say something like, "When set to true, the flag indicates that the serivce provider is expecting to deliver early media.", or something like that. This comment applies to all identifiers defined as booleans below.

Section 7.2, paragraph 26
>          leaf supportedMethods {
>            type string;
>            description "Leaf/Leaf List indicating the different SIP
>            methods supported by the service provider.";
>          }

Are there a well known set of SIP methods? If so, these should be defined as enums or even identities. This comment applies to all the "methods" defined below.

Section 7.2, paragraph 28
>            leaf preferredMethod {
>              type string;
>              description "Field specifying which SIP header must be
>              used by the enterprise network to communicate caller
>              information.";
>            }
>          }

If the supportedMethods is changed to enum or integer, I imagine this would have to change also.

Section 7.2, paragraph 29
>            leaf index {
>              type int32;
>              description "Index for the ranges.";
>            }

Same comment as the comment above for index.

Section 7.2, paragraph 29
>            leaf type {
>              type string;
>              description "String indicating whether the number range
>              allocated to the enterprise network is passed by value or
>              by reference.";
>            }

If the type takes a value of 'type' or 'collection', why is not an enum instead of a string?

Section 7.2, paragraph 29
>            leaf count {
>              when "../type = 'range' or ../type = 'collection'";
>              type int32;
>              description "The count of the individual numbers present
>              in the number range.";
>            }

Can the count be negative?

Section 7.2, paragraph 29
>            leaf-list value {
>              type string;
>              description "Value of the individual number in the number
>              range or URL being passed as reference.";
>            }

If value can be a number or a URL string, can this not be a union of uint32 and a string type?

Section 7.2, paragraph 31
>            leaf-list mediaFormat {
>              type string;
>              description "Leaf List indicating the audio media formats
>              supported by the service provider.";
>            }

Same comment as above. If there are well known media formats, this should be listed as an enum or identity.

Section 7.2, paragraph 41
>          leaf payloadNumber {
>            type int8 {
>              range "96..127";
>            }
>            description "Leaf indicating the payload number(s) supported
>            by the service provider for DTMF related via RTP NTE.";

If the payload number is a postive number, why is the type an int8 and not a uint8?

Section 7.2, paragraph 44
>            leaf version {
>              type string {
>                pattern "([1-9]\\.[0-9])(;[1-9]\\.[0-9])?|(NULL)";
>              }
>              description "Leaf indicating the TLS version supported by
>              the SIP service provider.";

This should be a choice statement, with v1.2 and v1.3 as the only options.

Section 7.2, paragraph 45
>            leaf keyManagement {
>              type string {
>                pattern "(SDES(;DTLS-SRTP,version=[1-9]\\.[0-9](,[1-9]"
>                + "\\.[0-9])?)?)|(DTLS-SRTP,version=[1-9]\\.[0-9](,"
>                + "[1-9]\\.[0-9])?)|(NULL)";
>              }
>              description "Leaf indicating the key management methods
>              supported by the service provider for SRTP.";
>            }

I am not an expert in the different key management supported by SIP, but if these are a few, and not tens or hundreds of them, it could be better to define them as choice statement. That assumes that there is only method that can be selected at any particular time.

Section 7.2, paragraph 44
>          leaf certLocation {
>            type string;
>            description "Location of the service provider certificate
>            chain for SIP over TLS.";
>          }

It is not clear what kind of location parameter this is. Is it a URL, XPath to where the certificate is stored??

Section 7.2, paragraph 48
>        leaf extensions {
>          type string;
>          description "Lists the various SIP extensions supported by the
>          service provider.";
>        }

If SIP extensions are a certain type, they should be listed as enums or identifiers.

Section 7.3, paragraph 1
>    This sub-sections provides the definition and encoding rules of the
>    various nodes of the YANG module defined in section 7.2

These definitions and encoding rules should be part of the YANG module, and not as a separate section. The reason for that is that once a YANG module is extracted from an RFC, it becomes a standalone entity, and should be self-explanatory, rather than having an implementor having to refer back to this document.

Section 7.4, paragraph 0
>    There are situations in which equipment manufactures or service
>    providers would benefit from extending the YANG module defined in
>    this draft.  For example, service providers could extend the YANG
>    module to include information that further simplifies direct IP
>    peering.  Such information could include: trunk group identifiers,
>    customer/enterprise account numbers, service provider support
>    numbers, among others.  Extension of the module can be achieved by
>    importing the module defined in this draft.  An example is provided
>    below: Consider a new YANG module "vendorA" specified for VendorA's
>    enterprise SBC.  The "vendorA-config" YANG module is configured as
>    follows:

Examples are generally informative, and belong in the Appendix.

Section 11, paragraph 0
>    The capability set document contains sensitive information that must
>    be protected from attackers.  A capability set document leak can
>    inflict considerable damage to both the enterprise as well as the
>    service provider.  An attacker that gains access to the capability
>    set document can cause problems in multiple ways.

This section lacks security considerations for the YANG module. Please refer to draft-ietf-netmod-rfc8407bis, Section 3.7.

The IANA review of this document seems to not have concluded yet.

Possible DOWNREF from this Standards Track doc to [SIP-Connect-TR]. If so, the
IESG needs to approve it.

Found terminology that should be reviewed for inclusivity; see
https://www.rfc-editor.org/part2/#inclusive_language for background and more
guidance:

* Term "master"; alternatives might be "active", "central", "initiator",
  "leader", "main", "orchestrator", "parent", "primary", "server"
* Term "traditional"; alternatives might be "classic", "classical", "common",
  "conventional", "customary", "fixed", "habitual", "historic",
  "long-established", "popular", "prescribed", "regular", "rooted",
  "time-honored", "universal", "widely used", "widespread"

Found IP blocks or addresses not inside RFC5737/RFC3849 example ranges:
"0.0.0.0", "208.67.222.222", "192.168.12.25", and "8.8.8.8".

-------------------------------------------------------------------------------
NIT
-------------------------------------------------------------------------------

All comments below are about very minor potential issues that you may choose to
address in some way - or ignore - as you see fit. Some were flagged by
automated tools (via https://github.com/larseggert/ietf-reviewtool), so there
will likely be some false positives. There is no need to let me know what you
did with these suggestions.

Document still refers to the "Simplified BSD License", which was corrected in
the TLP on September 21, 2021. It should instead refer to the "Revised BSD
License".

Reference [RFC2833] to RFC2833, which was obsoleted by RFC4733 and RFC4734
(this may be on purpose).

Section 1, paragraph 1
> e and service provider networks. Currently published standards provide a str
>                                  ^^^^^^^^^
A comma may be missing after the conjunctive/linking adverb "Currently".

Section 1, paragraph 2
> ise network, which is usually an error prone exercise. Additionally, such te
>                                  ^^^^^^^^^^^
This word is normally spelled with a hyphen.

Section 2.1, paragraph 1
> eams of calls setup by the SP-SSE and a HTTPS [RFC9110] server. +-----------
>                                      ^
Use "an" instead of "a" if the following word starts with a vowel sound, e.g.
"an article", "an hour".

Section 2.2, paragraph 2
> he enterprise network creates a well formed HTTP GET request to solicit the
>                                ^^^^^^^^^^^
This word is normally spelled with a hyphen.

Section 2.2, paragraph 5
> dd support for such a SIP extension. A HTTPS-based approach would be relativ
>                                      ^
Use "An" instead of "A" if the following word starts with a vowel sound, e.g.
"an article", "an hour".

Section 2.3, paragraph 5
> 1.1 including HTTP/3 [RFC9114]. First of all thanks to Dan Harkins for his S
>                                ^^^^^^^^^^^^
Often, this adverbial phrase is redundant. Consider using an alternative.

Section 4.3, paragraph 4
>  | | Authorization | | (SBC) |<--(3)---- Access Token --
>      ^^^^^^^^^^^^^
Do not mix variants of the same word ("authorization" and "authorisation")
within a single text.

Section 4.3, paragraph 6
> quired to authenticate with the authorization server located in the service p
>                                ^^^^^^^^^^^^^
Do not mix variants of the same word ("authorization" and "authorisation")
within a single text.

Section 4.3, paragraph 7
> C contacts the service provider authorization server to obtain an access toke
>                                ^^^^^^^^^^^^^
Do not mix variants of the same word ("authorization" and "authorisation")
within a single text.

Section 4.3, paragraph 7
> tep 1. 3. The service provider authorization server ratifies the credentials
>                                ^^^^^^^^^^^^^
Do not mix variants of the same word ("authorization" and "authorisation")
within a single text.

Section 4.3, paragraph 8
> t in the enterprise network generates a HTTP GET request such that the reques
>                                      ^
Use "an" instead of "a" if the following word starts with a vowel sound, e.g.
"an article", "an hour".

"YANG", paragraph 18
> mber, why is the type an int8 and not a uint8? } leaf iteration { type boole
>                                      ^
Use "an" instead of "a" if the following word starts with a vowel sound, e.g.
"an article", "an hour".

"YANG", paragraph 28
> Node Definitions COMMENT: This sub-sections provides the definition and encod
>                                ^^^^^^^^^^^^
This word is normally spelled as one.

"YANG", paragraph 44
> g the response parameter of the Authorization header field. *password*:A lea
>                                ^^^^^^^^^^^^^
Do not mix variants of the same word ("authorization" and "authorisation")
within a single text.

"YANG", paragraph 45
> g the response parameter of the Authorization header field. *callControl*: A
>                                ^^^^^^^^^^^^^
Do not mix variants of the same word ("authorization" and "authorisation")
within a single text.

"I", paragraph 3
> media cut through if it is known before-hand that early media is expected for
>                                  ^^^^^^^^^^^
This word is normally spelled as one.

Section 7.3, paragraph 4
> equires the enterprise network to normalize the calling number into E.164 fo
>                                  ^^^^^^^^^
Do not mix variants of the same word ("normalize" and "normalise") within a
single text.

Section 7.3, paragraph 19
>  provider network and because of sub-optimal media routing, an enterprise dev
>                                  ^^^^^^^^^^^
This word is normally spelled as one.

Section 7.3, paragraph 29
> etermine middlebox configuration before-hand. [RFC4733] iterates over [RFC28
>                                  ^^^^^^^^^^^
This word is normally spelled as one.

Section 7.3, paragraph 32
> ted, they should be separated by semi-colons. If the service provider does n
>                                  ^^^^^^^^^^^
This word is normally spelled as one.

Section 7.3, paragraph 53
> st target, the edge element generates a HTTP GET request. This request can b
>                                      ^
Use "an" instead of "a" if the following word starts with a vowel sound, e.g.
"an article", "an hour".

[Ballot comment]
Thank you to Joel Halpern for the GENART review.

** idnits returned the following:
  -- Obsolete informational reference (is this intentional?): RFC 2833
    (Obsoleted by RFC 4733, RFC 4734)

[Ballot discuss]

# Éric Vyncke, INT AD, comments for draft-ietf-asap-sip-auto-peer-20
CC @evyncke

Thank you for the work put into this document.

Please find below two blocking DISCUSS points (easy to address), some non-blocking COMMENT points (but replies would be appreciated even if only for my own education), and some nits.

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

I hope that this review helps to improve the document,

Regards,

-éric


## DISCUSS (blocking)

As noted in https://www.ietf.org/blog/handling-iesg-ballot-positions/, a DISCUSS ballot is just a request to have a discussion on the following topics:

### Section 9.1

Please do not use the Google & Cisco OpenDNS IPv4 addresses but use some addresses out of the test networks or documentation prefix.

### Section 10

Happy to stand corrected, but AFAIK all YANG modules must be registered by the IANA.

[Ballot comment]

## COMMENTS (non-blocking)

### Section 2.3

Isn't the 2nd sentence contradicting the first one in `The capability set document included in a successful response is formatted in JSON. The formatting depends on the value of the "Accept" header field of the HTTP GET request. ` ?

### Section 4.3

Suggest moving the Figure 2 earlier in the text as it is now far after the explanations.

### Section 4.5

Using https://ssp1.example.com/.well-known/ipTrunkingCapability could have been easier or am I missing something ?

### Section 7.2

I will rely on the OPS ADs to check whether the following point is more a DISCUSS, but is there a valid reason of not re-using existing types for IP address & port defined in basis YANG modules (and there is `import ietf-inet-types`) ?

The regex are a little too complex for my brain to check whether all and only RFC 5952 IPv6 addresses can be accepted by the regexp, e.g., 2001::db8::1 should be rejected.

### Section 7.3

`element must be set to the quadruple octet of 0.0.0.0` smells the old legacy IPv4... Why not using "::/0" ?

### Section 10

Should the YANG modules be registered by the IANA ?

## NITS (non-blocking / cosmetic)

### Use of SVG graphics

To make a much nicer HTML rendering, suggest using the aasvg too to generate SVG graphics. It is worth a try ;-)

IESG/Authors/WG Chairs:

IANA has completed its review of draft-ietf-asap-sip-auto-peer-18, which is currently in Last Call, and has the following comments:

We understand that this document doesn't require any registry actions.

While it's often helpful for a document's IANA Considerations section to remain in place upon publication even if there are no actions, if the authors strongly prefer to remove it, we do not object.

If this assessment is not accurate, please respond as soon as possible.

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 2025-02-21):

From: The IESG
To: IETF-Announce
CC: asap-chairs@ietf.org, asap@ietf.org, draft-ietf-asap-sip-auto-peer@ietf.org, marc@petit-huguenin.org, snandaku@cisco.com, superuser@gmail.com
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (Automatic Peering for SIP Trunks) to Proposed Standard


The IESG has received a request from the Automatic SIP trunking And Peering
WG (asap) to consider the following document: - 'Automatic Peering for SIP
Trunks'
  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 2025-02-21. 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 specifies a framework that enables enterprise telephony
  Session Initiation Protocol (SIP) networks to solicit and obtain a
  capability set document from a SIP service provider.  The capability
  set document encodes a set of characteristics that enable easy
  peering between enterprise and service provider SIP networks.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-asap-sip-auto-peer/



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

# Document Shepherd Write-Up for Group Documents

*This version is dated 4 July 2022.*

Thank you for your service as a document shepherd. Among the responsibilities is
answering the questions in this write-up to give helpful context to Last Call
and Internet Engineering Steering Group ([IESG][1]) reviewers, and your
diligence in completing it is appreciated. The full role of the shepherd is
further described in [RFC 4858][2]. You will need the cooperation of the authors
and editors to complete these checks.

Note that some numbered items contain multiple related questions; please be sure
to answer all of them.

Write-up based on draft-ietf-asap-sip-auto-peer-16

## 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?

I read again all the emails exchanged and the minutes of the sessions at IETF 110 and IETF 111 and the consensus represents the concurrence of a few individuals, with other being silent.

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

No controversy.

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)?

I could not find any information on implementations of this specification.

## 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.

This specification uses OAUTH2 and YANG so it would benefit from reviews by the artart and yangdoctors directorates.  None of these occurred yet.

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.

I checked that the YANG module meets the guidelines in RFC 8497.

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]?

The yang module has been checked using the online validator at https://www.yangcatalog.org/yangvalidator

Each regex have been checked using the online validator: https://www.yangcatalog.org/yangre.  Note that only a few values have been tested for each, in addition to a visual check of the regex.

The yang model complies with NMDA.

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 JSON example has been verified to be correct against the YANG module using the pyang tool.

## 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?

I did a new review of this document and believe this document is ready for publication.

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?

No issues have been identified after looking at the list of common issues for the ART and OPS areas.

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 is being requested.

This is the proper type of RFC because this document defines an interoperable protocol, and this protocol is expected to be widely used in the Internet.

The Datatracker reflects 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, the authors have been reminded, and all required disclosures have been filed.  No IPR disclosures have been made.

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.

There is less than five authors in this document.

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.)

No nits are reported by idnits.

I have reviewed the document against the content guidelines, and found no issue.

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

No.

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

All references are freely available.

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, RFC 7092 and RFC 7362.

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]).

There is no IANA considerations.

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.

Not applicable.


[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://wiki.ietf.org/group/ops/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://wiki.ietf.org/group/iesg/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

*This version is dated 4 July 2022.*

Thank you for your service as a document shepherd. Among the responsibilities is
answering the questions in this write-up to give helpful context to Last Call
and Internet Engineering Steering Group ([IESG][1]) reviewers, and your
diligence in completing it is appreciated. The full role of the shepherd is
further described in [RFC 4858][2]. You will need the cooperation of the authors
and editors to complete these checks.

Note that some numbered items contain multiple related questions; please be sure
to answer all of them.

Write-up based on draft-ietf-asap-sip-auto-peer-16

## 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?

I read again all the emails exchanged and the minutes of the sessions at IETF 110 and IETF 111 and the consensus represents the concurrence of a few individuals, with other being silent.

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

No controversy.

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)?

I could not find any information on implementations of this specification.

## 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.

This specification uses OAUTH2 and YANG so it would benefit from reviews by the artart and yangdoctors directorates.  None of these occurred yet.

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.

I checked that the YANG module meets the guidelines in RFC 8497.

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]?

The yang module has been checked using the online validator at https://www.yangcatalog.org/yangvalidator

Each regex have been checked using the online validator: https://www.yangcatalog.org/yangre.  Note that only a few values have been tested for each, in addition to a visual check of the regex.

The yang model complies with NMDA.

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 JSON example has been verified to be correct against the YANG module using the pyang tool.

## 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?

I did a new review of this document and believe this document is ready for publication.

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?

No issues have been identified after looking at the list of common issues for the ART and OPS areas.

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 is being requested.

This is the proper type of RFC because this document defines an interoperable protocol, and this protocol is expected to be widely used in the Internet.

The Datatracker reflects 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, the authors have been reminded, and all required disclosures have been filed.  No IPR disclosures have been made.

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.

There is less than five authors in this document.

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.)

No nits are reported by idnits.

I have reviewed the document against the content guidelines, and found no issue.

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

No.

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

All references are freely available.

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]).

There is no IANA considerations.

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.

Not applicable.


[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://wiki.ietf.org/group/ops/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://wiki.ietf.org/group/iesg/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

*This version is dated 4 July 2022.*

Thank you for your service as a document shepherd. Among the responsibilities is
answering the questions in this write-up to give helpful context to Last Call
and Internet Engineering Steering Group ([IESG][1]) reviewers, and your
diligence in completing it is appreciated. The full role of the shepherd is
further described in [RFC 4858][2]. You will need the cooperation of the authors
and editors to complete these checks.

Note that some numbered items contain multiple related questions; please be sure
to answer all of them.

Write-up based on draft-ietf-asap-sip-auto-peer-16

## 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?

I read again all the emails exchanged and the minutes of the sessions at IETF 110 and IETF 111 and the consensus represents the concurrence of a few individuals, with other being silent.

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

No controversy.

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)?

I could not find any information on implementations of this specification.

## 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.

This specification uses OAUTH2 and YANG so it would benefit from reviews by the artart and yangdoctors directorates.  None of these occurred yet.

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.

I checked that the YANG module meets the guidelines in RFC 8497.

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]?

The yang module has been checked using the online validator at https://www.yangcatalog.org/yangvalidator

Each regex have been checked using the online validator: https://www.yangcatalog.org/yangre.  Note that only a few values have been tested for each, in addition to a visual check of the regex.

The yang model complies with NMDA.

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 JSON example has been verified to be correct against the YANG module using the pyang tool.

## 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?

I did a new review of this document and believe this document is ready for publication.

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?

No issues have been identified after looking at the list of common issues for the ART and OPS areas.

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 is being requested.

This is the proper type of RFC because this document defines an interoperable protocol, and this protocol is expected to be widely used in the Internet.

The Datatracker reflects 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, the authors have been reminded, and all required disclosures have been filed.  No IPR disclosures have been made.

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.

There is less than five authors in this document.

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.)

No nits are reported by idnits.

I have reviewed the document against the content guidelines, and found no issue.

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

No.

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

All references are freely available.

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]).

There is no IANA considerations.

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.

Not applicable.


[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://wiki.ietf.org/group/ops/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://wiki.ietf.org/group/iesg/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/