Why do you define a new grouping, tcp-server-info? Why not just augment what is in 9105? This adds complexity with minimal, if any, benefit that I see. [Med] 9105 does not have a list. The initial intent was to cover when there are more addresses to reach the same server identifier by the same domain-name for redundancy and so on. We could configure two sever entries, but then all the credentials will need to be repeated for each member of the group. Also, if there is a procedure to fall back when an instance is not responsive, that will be difficult to control with the separate entries. Would that makes sense?
[JMC] No, 9105 doesn’t have a list of addresses to refer to a single server. That said, in my experience I haven’t needed that. I accomplish redundancy via multiple server instances (where they sync state or have a common config database). I don’t know that having multiple addresses per instance adds a lot of practical value vs. The added complexity and possible confusion. Does the new domain-name leaf need to be mandatory if certs are used? [Med] I don’t think so as DNS-ID and IP-ID are allowed for identification. No? This prompted me that a check is needed when SNI is enabled but we don’t have a knob to control SNI activation. I think we need one. [JMC] Thanks for the confirmation. Yes, SNI would be a good thing to cover. Finally, on operational data, should this module introduce any TLS-specific stats in addition to those in 9105? I feel like certificate issues or PSK problems might be useful. [Med] Good point. Will cover this in future iterations. [JMC] Thanks ! Last night I was thinking having stats on server vs. client auth failures would be helpful. Joe
_______________________________________________ OPSAWG mailing list -- opsawg@ietf.org To unsubscribe send an email to opsawg-le...@ietf.org
