[Asap] Re: Mohamed Boucadair's Discuss on draft-ietf-asap-sip-auto-peer-32: (with DISCUSS and COMMENT)

[[e-mail]]

Hi Sreekanth, 

Thank you for the follow-up and updates made so far. 

Please see inline for the question you raised.

Cheers,
Med

> -----Message d'origine-----
> De : Sreekanth Narayanan <[e-mail]>
> Envoyé : lundi 20 octobre 2025 19:36
> À : BOUCADAIR Mohamed INNOV/NET <[e-mail]>
> Cc : The IESG <[e-mail]>; draft-ietf-asap-sip-auto-
> [e-mail]; [e-mail]; [e-mail];
> [e-mail]; [e-mail]
> Objet : Re: [Asap] Mohamed Boucadair's Discuss on draft-ietf-asap-
> sip-auto-peer-32: (with DISCUSS and COMMENT)
> 
> 
> Hi Mohamed,
> 
> Hope you are well.
> I've addressed all of the comments except the one regarding the
> SIP option parameters.
> 
> > # 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.
> 
> Yes this sub-registry is what we'd like to represent as a limited
> set of choices for the "extension" field. Since this sub-registry
> is already available at
> https://www.iana.org/assignments/sip-parameters/sip-parameters.xhtml#sip-parameters-4, what would be the best way to do this.

[Med] I think the best approach here is to rely on the registry and avoid creating two sources of values that a service provider can use, especially that the identifiers used in your module are not easily correlated with the names present in the registry.

Instead, I suggest that you define an IANA-maintained module that will mirror the content of sip-parameters-4.

To help you with that approach, I drafted for you how this would look like:

* the IANA-maintained module will like as follows: https://github.com/boucadair/IETF-Drafts-Reviews/blob/master/YANG/iana-sip-option-tags.yang
* the changes to your current module can be also seen here:
  - updated file: https://github.com/boucadair/IETF-Drafts-Reviews/blob/master/YANG/ietf-sip-auto-peering.yang
  - diff vs -35: https://github.com/boucadair/IETF-Drafts-Reviews/commit/c8fe588b7a8472fa0b368157c097108a6d36fc30

If you go that path: 

(1) You will need to complete the iana-sip-option-tags file with all content of the registry. You can do that manually or using a script. An xslt script can be found at https://github.com/llhotka/iana-yang, but I think that it is better at thit stage that you do that manually.

(2) Put iana-sip-option-tags in an appendix with "Initial Version of the SIP Option Tags IANA-Maintained Module" as title + add a note to the RFC Editor to remove it from the final RFC

(3) Update IANA section with the actions to register iana-sip-option-tags + add a new subsection that follows the template at https://datatracker.ietf.org/doc/html/draft-ietf-netmod-rfc8407bis-28#name-template-for-iana-maintained.

(4) indicate in the text that advertised extensions are filtered out by service providers using local policy.

Hope this helps.

 In an
> earlier review of the yang module, I was asked to change this
> field from generic string to a limited list.
> 
> Thanks
> Sreekanth
> 
> 
> On Wednesday, October 8th, 2025 at 8:24 PM, Mohamed Boucadair via
> Datatracker <[e-mail]> wrote:
> 
> > Mohamed Boucadair has entered the following ballot position for
> > draft-ietf-asap-sip-auto-peer-32: Discuss
> >
> > When responding, please keep the subject line intact and reply
> to all
> > email addresses included in the To and CC lines. (Feel free to
> cut
> > this introductory paragraph, however.)
> >
> >
> > Please refer to
> >
> https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2F
> www.
> > ietf.org%2Fabout%2Fgroups%2Fiesg%2Fstatements%2Fhandling-ballot-
> positi
> >
> ons%2F&data=05%7C02%7Cmohamed.boucadair%40orange.com%7C2ca260eb9fb
> 1488
> >
> 231d508de0fff4339%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C638
> 9657
> >
> 86198710487%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOi
> IwLj
> >
> AuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%
> 7C%7
> >
> C&sdata=fQsozrhMa37%2BLwJsty0OK9VE56mvblsX9Xvh8wc9z%2FQ%3D&reserve
> d=0
> > for more information about how to handle DISCUSS and COMMENT
> positions.
> >
> >
> > The document, along with other ballot positions, can be found
> here:
> >
> https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2F
> data
> > tracker.ietf.org%2Fdoc%2Fdraft-ietf-asap-sip-auto-
> peer%2F&data=05%7C02
> >
> %7Cmohamed.boucadair%40orange.com%7C2ca260eb9fb1488231d508de0fff43
> 39%7
> >
> C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C638965786198724228%7CU
> nkno
> >
> wn%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiO
> iJXa
> >
> W4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=favMspB
> iFLa
> > NDAhFGkrllKEKh90BsKAwxAWmqhE0%2Fv0%3D&reserved=0
> >
> >
> >
> > ----------------------------------------------------------------
> ------
> > 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://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2F
> data
> > tracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-netmod-rfc8407bis-
> 28%23name
> > -iana-template-for-
> documents&data=05%7C02%7Cmohamed.boucadair%40orange
> >
> .com%7C2ca260eb9fb1488231d508de0fff4339%7C90c7a20af34b40bfbc48b925
> 3b6f
> >
> 5d20%7C0%7C0%7C638965786198738021%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0
> eU1h
> >
> cGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIl
> dUIj
> >
> oyfQ%3D%3D%7C0%7C%7C%7C&sdata=N8kLTZhFgLyfwwm5Jm%2FYj5AV3batOsyPGV
> Ss%2
> > FA0k5ts%3D&reserved=0
> > 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://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2F
> data
> > tracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-netmod-rfc8407bis-
> 28%23sect
> > ion-
> 3.7&data=05%7C02%7Cmohamed.boucadair%40orange.com%7C2ca260eb9fb148
> >
> 8231d508de0fff4339%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C63
> 8965
> >
> 786198753173%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiO
> iIwL
> >
> jAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C
> %7C%
> >
> 7C&sdata=BR8Th%2FIQJOf1cV%2B2vAQbAFfSfh45tcHWpf%2B4FU4OUC8%3D&rese
> rved
> > =0
> >
> > # 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://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2F
> www.
> > iana.org%2Fassignments%2Fiana-crypt-hash%2Fiana-crypt-
> hash.xhtml&data=
> >
> 05%7C02%7Cmohamed.boucadair%40orange.com%7C2ca260eb9fb1488231d508d
> e0ff
> >
> f4339%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C638965786198767
> 098%
> >
> 7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMC
> IsIl
> >
> AiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=
> kRDM
> > UvbPf%2FNP%2FYzohvTN2oUB168mNaLXDcRAwKaEYBY%3D&reserved=0;
> > }
> >
> > 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://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2F
> www.iana.org%2Fassignments%2Fsip-parameters%2Fsip-
> parameters.xhtml%23sip-parameters-
> 4&data=05%7C02%7Cmohamed.boucadair%40orange.com%7C2ca260eb9fb14882
> 31d508de0fff4339%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C6389
> 65786198781141%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlY
> iOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%
> 7C0%7C%7C%7C&sdata=1AIcx9mQPkz9UPJnCgEDNPCNHnnPuc7gRkZq6zvRi74%3D&
> reserved=0?
> >
> > 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,
> >
> https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2F
> www.rfc-
> editor.org%2Finfo%2Frfc3261&data=05%7C02%7Cmohamed.boucadair%40ora
> nge.com%7C2ca260eb9fb1488231d508de0fff4339%7C90c7a20af34b40bfbc48b
> 9253b6f5d20%7C0%7C0%7C638965786198794921%7CUnknown%7CTWFpbGZsb3d8e
> yJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjo
> iTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=4p%2BfLLNOQxV6soI9Mow
> 9Iav2JrzsAfAYCGyYCwQ3sDA%3D&reserved=0.
> >
> >
> > Please double check the classification of the reference as I
> think
> > other entries are normative.
> >
> >
> > ----------------------------------------------------------------
> ------
> > 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,
> >
> https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2F
> www.rfc-
> editor.org%2Finfo%2Frfc6241&data=05%7C02%7Cmohamed.boucadair%40ora
> nge.com%7C2ca260eb9fb1488231d508de0fff4339%7C90c7a20af34b40bfbc48b
> 9253b6f5d20%7C0%7C0%7C638965786198808482%7CUnknown%7CTWFpbGZsb3d8e
> yJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjo
> iTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=WYHal0%2BqbfjG8BaPods
> qTMZjfjJYNpbfiJh6hrwiJDY%3D&reserved=0.
> >
> > ..
> > [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree
> Diagrams", BCP
> > 215, RFC 8340, DOI 10.17487/RFC8340, March 2018,
> >
> https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2F
> www.rfc-
> editor.org%2Finfo%2Frfc8340&data=05%7C02%7Cmohamed.boucadair%40ora
> nge.com%7C2ca260eb9fb1488231d508de0fff4339%7C90c7a20af34b40bfbc48b
> 9253b6f5d20%7C0%7C0%7C638965786198822406%7CUnknown%7CTWFpbGZsb3d8e
> yJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjo
> iTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=Q3g%2B4fItFJ6GZ%2FTAj
> 9G5dEePCYYgchiKF07rsqXFsp8%3D&reserved=0.
> >
> >
> > Cheers,
> > Med
> >
> >
> >
> > --
> > Asap mailing list -- [e-mail]
> > To unsubscribe send an email to [e-mail]
____________________________________________________________________________________________________________
Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.