From nobody Tue Mar 8 15:13:46 2022 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 627E23A1B7B; Tue, 8 Mar 2022 15:13:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.107 X-Spam-Level: X-Spam-Status: No, score=-2.107 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A5FeGwf_qoU4; Tue, 8 Mar 2022 15:13:38 -0800 (PST) Received: from mail-pj1-x1031.google.com (mail-pj1-x1031.google.com [IPv6:2607:f8b0:4864:20::1031]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E72C73A1B78; Tue, 8 Mar 2022 15:13:37 -0800 (PST) Received: by mail-pj1-x1031.google.com with SMTP id m11-20020a17090a7f8b00b001beef6143a8so689947pjl.4; Tue, 08 Mar 2022 15:13:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=W4txV2FzJOmjgq4Dxe7lc/JUxvlrRfSmwGrSz+Uz7Lw=; b=Uw+k+e7ogkc49nyaYgXLj8FRq/u3WBzApeKAiSKJSHeBc1jwc2ytkTDNYD25VVAAyV wT3M0gT/cyIKl4GFBoY3wJ52zVYisfP4qA1phBO8Jq47i4QLjtNb0MadETt+ZVteNNUv xb8NzXmxIDXy91vZtY8ID2HEPcgUujOSadWYlTKH1RIgjIpgUz5RogMYhBT2IzdvW3Li jRVvTNkQ59GxVxNuLMD91OQNamIBUr4LKWiq6sqVHt7u0dUYHkPVxrM06ZLqRzSot7b4 MJpsc27wjkxqc33+9j+Lqedsz9RotAeWGKSTKnwTtmAPUKCk/A5BwnEVcek9nitPBUte S/UQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=W4txV2FzJOmjgq4Dxe7lc/JUxvlrRfSmwGrSz+Uz7Lw=; b=b6SPDv/5ppNtie2HHLV7eMgzyuo6PjCGY0sJCkRnqqbfoHlkytNcpSBuCdb/p6brWn G177jJ/r7terE4bJsRRFNl/l3GWcMC+Yb8jXcw0YMlSmuLWF+FqBnutPpM8WainheIbG 0FEzZStQrj/jWmMkLmYHzrtW/NEla9O5ziIXIq/yHqpDUSTwsLXA5kD2ZUC7i83WuT5o t9RPs7Xg7KQDd5DCovyjXKE+rwThzFYLUHrpNG/NuzzjIOWgYDLcsaevS4LuUBA/LpvZ lXmWTfu7sMYXDMZk44P8HpEFO7yPomqAbVZLzs89ITHcPXeuIww8Ncsn1xZ8nfwYytoB Gaiw== X-Gm-Message-State: AOAM532Iw/rxkKig1PjnquyyyTF3hqOXfktpq9iteHgfeOR9k9AREMc8 dSf8IjnO1LdW2Upmq+kaUpBDZcmwEV9asipt X-Google-Smtp-Source: ABdhPJwbWYdEn8BnBMnfVmB/UnxVKAnedU+fYautp20M9ql1DshcM26mQE3Jmo59XCEVcylZNM4Cbg== X-Received: by 2002:a17:902:dad2:b0:151:f895:9c31 with SMTP id q18-20020a170902dad200b00151f8959c31mr8444832plx.93.1646781216934; Tue, 08 Mar 2022 15:13:36 -0800 (PST) Received: from smtpclient.apple (adsl-70-234-233-187.dsl.rcsntx.sbcglobal.net. [70.234.233.187]) by smtp.gmail.com with ESMTPSA id s20-20020a056a00179400b004f709998d13sm157941pfg.10.2022.03.08.15.13.35 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 08 Mar 2022 15:13:36 -0800 (PST) From: Mahesh Jethanandani Message-Id: <9495FF25-6BF3-4BDC-996C-5F10B9C4E489@gmail.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_CDE10C6D-CB66-4332-B69E-BD4AF3F545F1" Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) Date: Tue, 8 Mar 2022 15:13:34 -0800 In-Reply-To: <20220302140422.GE13378@pfrc.org> Cc: Michael SCHARF , "idr-chairs@ietf.org" , "tcpm@ietf.org Extensions" To: Jeffrey Haas References: <4E897FFF-4C6B-43DB-9623-7F168898ECF0@pfrc.org> <20220225214059.GD452@pfrc.org> <94B53B56-1971-4FD1-A557-CF713CEEA62D@gmail.com> <6CACD42C-28D4-4209-B61A-E3F522C0DAE4@pfrc.org> <22b1e046fe6846b0a04e3b430357fb2b@hs-esslingen.de> <20220302140422.GE13378@pfrc.org> X-Mailer: Apple Mail (2.3654.120.0.1.13) Archived-At: Subject: Re: [tcpm] [Idr] Last Call: (A YANG Model for Transmission Control Protocol (TCP) Configuration) to Proposed Standard X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Mar 2022 23:13:45 -0000 --Apple-Mail=_CDE10C6D-CB66-4332-B69E-BD4AF3F545F1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 [Pruning this thread to open issues] > On Mar 2, 2022, at 6:04 AM, Jeffrey Haas wrote: >=20 >>>> From: Jeffrey Haas >>> On Feb 25, 2022, at 7:41 PM, Mahesh Jethanandani = > wrote: >>=20 >>> I think what is meant here is RNextKeyId. This is part of TCP-AO = (Section 2.2 of RFC 5925). We seem to agree that the client, e.g. BGP, = should maintain a reference to the keychain it is using. Does the client = need to do more than providing that reference to TCP, i.e. provide the = RNextKeyId? >>=20 >>>> Note that I'm not arguing that this state is config state at all. = I think this one is likely operational-only state. >>>> But that rather argues what the glue is for the configuration. And = that's where the conversation below gets interesting. >>=20 >> [ms] We never discussed whether additional operational state is = needed for TCP-AO. It is a good question, though. Whether we go down = that road probably depends also on how we further proceed with TCP-AO = configuration. >=20 > Agreed, in general. The specific bit of state cited here, RNextKeyId, = is > ideally short-lived operational state for when a key rollover in = TCP-AO > happens. It is primarily useful for "stuck" key roll overs. I will add RNextKeyId as a ro node to the AO configuration. >=20 >>>> - The states exposed in the model are incomplete. While they cover = much >>>> that is from the TCP-MIB (as noted by the discussion text), some = things >>>> like FIN_WAIT* are very helpful for troubleshooting stuck TCP = sessions or >>>> socket exhaustion. >=20 >> [ms] There was some discussion in TCPM on whether to focus on the = base statistics from the TCP MIB (RFC 4022), or whether to include more = stats. Note that there is a TCP Extended Statistics MIB (RFC 4898), but = at least I am not aware of any implementation of that MIB. >=20 > Understood. See near top of message my opinion on such things. >=20 > That said, tcp state for things like FIN_WAIT* are well deployed in my > experience. (And sadly, to my operational experience in trying to > troubleshoot network and stack issues.) I will wait for the WG to comment on whether they want to include TCP = connection state in the model. >=20 >> [ms] The stats defined by the TCP MIB are supported not only on = several router operating systems, but e.g. also on Linux (/proc/net/snmp = on a Debian Buster system). Also, there have been a report that Windows = uses global stats along the lines of the MIB definitions (see = https://mailarchive.ietf.org/arch/msg/tcpm/3oMQdIrz9prgE1smt-aFTEFpqGs/ = for details). Of course, operating systems may have useful stats beyond = the TCP MIB. For instance, in Linux the =E2=80=9Cnetstat -s=E2=80=9D = command reports also counters beyond the TCP MIB, including a counter = related to FIN_WAIT, but at least some of these counters reported by = =E2=80=9Cnetstat -s=E2=80=9D are Linux-specific, as they refer to = Linux-internal heuristics. So, sure, we can add further stats to the = YANG model, but then we need a very careful analysis whether these stats = are indeed reasonably similar implemented. I have done such an analysis = for some other TCP configuration parameters and even for pretty trivial = parameters the existing running TCP code differs significantly. There is = a significant risk that whatever we would write in a YANG model deviates = from running code. TCP-AO may be partly an exception because the = implementations are all fairly new. >=20 > In some of my prior kernel browsing for various operational state, = I've seen > that the stats are literally named after the old MIB variables. So, = there's > examples of providing stats because standards work motivated it. >=20 > I don't advocate trying to cover everything. For IETF work, what I > generally advocate for is things that the protocol specifications lead = to. > Session state should be an easy answer. >=20 > For other things that are less supportable by common reference to RFCs = but > may be widely but not pervasively deployed, YANG module authors have a > choice: Don't put it in, and permit implementors to augment the = feature into > the model. Put it in, and require implementors to deviate features = they > don't support. >=20 > YANG, at least, gives us the easy option for such augmentations and > deviations. It'll be up to the wisdom of the contributors to the = Working > Group as to what makes sense in such circumstances. Again, I will wait for the WG to comment on what additional stats if any = need to be included in the model. >=20 >> [ms] The TCP connection table is *not* intended for configuration = state. >=20 > Then you have an example that needs work. :-) Which example are you referring to?=20 If you are referring to the example in B.2 - TCP-AO configuration, you = will notice that the TCP-AO configuration has two parts. One part, which = is state or =E2=80=98config false=E2=80=99 data and includes the local = and remote-address; local and remote port. The other part is the AO = parameters such as =E2=80=98recv-id=E2=80=99 and =E2=80=99send-id=E2=80=99= which is configuration or =E2=80=98config true=E2=80=99 data. There is = an existing draft System-defined Configuration = , that gets into how one can use state data (connection = 4-tuple), to configure the TCP-AO parameters (config true), but the = short of it is that till that draft becomes a RFC, the only way to model = all the parameters as either =E2=80=98config true=E2=80=99 or =E2=80=98con= fig false=E2=80=99. I chose the former. >=20 >> I have been told that this list has to be read-write because of YANG = semantics, albeit a large part of the content is read-only. >=20 > I would be curious to see the YANG doctor analysis that lead to this > decision. Do you have a pointer? See above. >=20 >> The document already explains this as follows: =E2=80=9CTCP = connection table: Access to status information for all TCP connections. = Note, the connection table is modeled as a list that is read-writeable, = even though a connection cannot be created by adding entries to the = table. Similarly, deletion of connections from this list is = implementation-specific.=E2=80=9D I agree that if a TCP connection were = to be established by that table, wildcards would be needed=20 >=20 > Asking a simple "netstat" question: How do you model sockets in the = LISTEN > state? For such sockets, how do you model listening on one address or = a > wildcard address? >=20 >> =E2=80=93 but in reality TCP connections are established by the = application or service, e.g. by the sockets API. One doesn=E2=80=99t use = a YANG model for that, at least as far as I know. If the list only = includes established TCP connections, every single TCP connection has a = well-defined src/dst IP address and a well-defined src/dst port = (5-tuple); on the connection initiator side, src address and src port = may be selected by the stack. The current model in = draft-ietf-tcpm-yang-tcp-06 also does not model a list of listeners. >=20 > My point is made for listeners. I believe this is a model gap. One way that I have seen this modeled is as follows. leaf-list listen-addresses { type union { type inet:ip-address; type enumeration { enum any { description "The agent should listen on any address bound to an interface on the system."; } } type string; } default =E2=80=9Cany"; must "(not(../listen-addresses =3D =E2=80=98any' and = count(../listen-addresses) > 1))" { error-message =E2=80=9C=E2=80=98any', IP addresses, and = interface names are mutually exclusive"; } description "The IP addresses that the agent should listen on. This may be an IPv4 or an IPv6 address, interface = name=20 or the enum =E2=80=98any=E2=80=99."; } >=20 >> [ms] In a nutshell, if connections cannot be created by adding = entries to the list, I don=E2=80=99t understand why wildcards would be = needed. >=20 > For operational state for listeners. That said, I'm less advocating = for > "create a connection in this table" and more about "how does a TCP = client > wanting to use TCP-AO get its job done?" Things get interesting when you try to configure TCP-AO parameters using = this model. Theoretically, one does not know the 4-tuple for a given = connection, till the connection is already established, by which time it = is already too late to provide the AO parameters, as they would be = needed at connection establishment time. So the short answer is, I do = not know. >=20 >>>> + The binding between a send-id and receive-id likely belong in the >>>> keychain. This likely requires augmenting the keychain model. >>=20 >>> Did you mean binding between tcp-ao and the keychain model it is = using? >>=20 >> I mean that send-id/receive-id state likely belongs in an individual = keychain entry. That means the keychain model needs augmenting. The = augmentation can be sourced from the tcpm RFC. >>=20 >> [ms] That solution (used by all known router implementations) is = already explicitly explained in draft-ietf-tcpm-yang-tcp-06 as follows: = =E2=80=9CThe keychain for TCP-AO can be modeled by the YANG Data Model = for Key Chains [RFC8177]. The groupings defined in this document can be = imported and used as part of such a preconfiguration.=E2=80=9D >=20 > I don't find the example clear. As noted above, configuration state = in > existing implementations requires a binding of a send-id and a = receive-id > (TCP-AO configuration state) to the keychain entry. Binding is what the example in Section B.2 is trying to demonstrate. The = send-id (61) and recv-id (84) are bound to the keychain =E2=80=9Cao-config= =E2=80=9D. I will model in the RNextKeyId parameter, but the keychain model is not = clear in how it is going to use the RNextKeyId, or how the key rollover = happens. And draft-ietf-tcpm-ao-test-vectors = = does not have an example for RNextKeyId. I can assume the bindings are = similar, and bind RNextKeyId to the keychain =E2=80=9Cao-config=E2=80=99, = and a keystring of =E2=80=98testvector=E2=80=99 much like =E2=80=98recv-id= =E2=80=99 and =E2=80=99send-id=E2=80=99. How does that sound? Thanks. Mahesh Jethanandani mjethanandani@gmail.com --Apple-Mail=_CDE10C6D-CB66-4332-B69E-BD4AF3F545F1 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 [Pruning this thread to open issues]

On Mar = 2, 2022, at 6:04 AM, Jeffrey Haas <jhaas@pfrc.org> wrote:

From: = Jeffrey Haas <jhaas@pfrc.org>
On Feb 25, = 2022, at 7:41 PM, Mahesh Jethanandani <mjethanandani@gmail.com<mailto:mjethanandani@gmail.com>> wrote:

I think what is meant here is RNextKeyId. This is part of = TCP-AO (Section 2.2 of RFC 5925). We seem to agree that the client, e.g. = BGP, should maintain a reference to the keychain it is using. Does the = client need to do more than providing that reference to TCP, i.e. = provide the RNextKeyId?

Note that I'm not arguing that this state is config state at = all.  I think this one is likely operational-only state.
But that rather argues what the glue is for the = configuration.  And that's where the conversation below gets = interesting.

[ms] = We never discussed whether additional operational state is needed for = TCP-AO. It is a good question, though. Whether we go down that road = probably depends also on how we further proceed with TCP-AO = configuration.

Agreed, in = general.  The specific bit of state cited here, RNextKeyId, is
ideally short-lived operational state for when a key rollover = in TCP-AO
happens.  It is primarily useful for = "stuck" key roll overs.

I will add RNextKeyId as a ro node to the AO = configuration.


- The states exposed in the model are = incomplete.  While they cover much
that is from the = TCP-MIB (as noted by the discussion text), some things
= like FIN_WAIT* are very helpful for troubleshooting stuck TCP sessions = or
socket exhaustion.

[ms] There was some = discussion in TCPM on whether to focus on the base statistics from the = TCP MIB (RFC 4022), or whether to include more stats. Note that there is = a TCP Extended Statistics MIB (RFC 4898), but at least I am not aware of = any implementation of that MIB.

Understood.  See near top of message my opinion on such = things.

That said, tcp state for things = like FIN_WAIT* are well deployed in my
experience. =  (And sadly, to my operational experience in trying to
troubleshoot network and stack issues.)

I will = wait for the WG to comment on whether they want to include TCP = connection state in the model.


[ms] The stats defined = by the TCP MIB are supported not only on several router operating = systems, but e.g. also on Linux (/proc/net/snmp on a Debian Buster = system). Also, there have been a report that Windows uses global stats = along the lines of the MIB definitions (see  https://mailarchive.ietf.org/arch/msg/tcpm/3oMQdIrz9prgE1smt-aF= TEFpqGs/ for details). Of course, operating systems may have useful = stats beyond the TCP MIB. For instance, in Linux the =E2=80=9Cnetstat = -s=E2=80=9D command reports also counters beyond the TCP MIB, including = a counter related to FIN_WAIT, but at least some of these counters = reported by =E2=80=9Cnetstat -s=E2=80=9D are Linux-specific, as they = refer to Linux-internal heuristics. So, sure, we can add further stats = to the YANG model, but then we need a very careful analysis whether = these stats are indeed reasonably similar implemented. I have done such = an analysis for some other TCP configuration parameters and even for = pretty trivial parameters the existing running TCP code differs = significantly. There is a significant risk that whatever we would write = in a YANG model deviates from running code. TCP-AO may be partly an = exception because the implementations are all fairly new.

In some of my prior kernel = browsing for various operational state, I've seen
that the = stats are literally named after the old MIB variables.  So, = there's
examples of providing stats because standards work = motivated it.

I don't advocate trying to = cover everything.  For IETF work, what I
generally = advocate for is things that the protocol specifications lead to.
Session state should be an easy answer.

For other things that are less supportable by common = reference to RFCs but
may be widely but not pervasively = deployed, YANG module authors have a
choice: Don't put it = in, and permit implementors to augment the feature into
the = model.  Put it in, and require implementors to deviate features = they
don't support.

YANG, at = least, gives us the easy option for such augmentations and
deviations.  It'll be up to the wisdom of the = contributors to the Working
Group as to what makes sense = in such circumstances.

Again, I will wait for the WG to comment on what = additional stats if any need to be included in the model.


[ms] The = TCP connection table is *not* intended for configuration state.

Then you have an example that = needs work. :-)

Which example are you referring to? 

If you are referring to the example in B.2 - = TCP-AO configuration, you will notice that the TCP-AO configuration has = two parts. One part, which is state or =E2=80=98config false=E2=80=99 = data and includes the local and remote-address; local and remote port. = The other part is the AO parameters such as =E2=80=98recv-id=E2=80=99 = and =E2=80=99send-id=E2=80=99 which is configuration or =E2=80=98config = true=E2=80=99 data. There is an existing draft System-defined Configuration, that gets = into how one can use state data (connection 4-tuple), to configure the = TCP-AO parameters (config true), but the short of it is that till that = draft becomes a RFC, the only way to model all the parameters as either = =E2=80=98config true=E2=80=99 or =E2=80=98config false=E2=80=99. I chose = the former.


I have been told that this list has to be = read-write because of YANG semantics, albeit a large part of the content = is read-only.

I would be = curious to see the YANG doctor analysis that lead to this
decision.  Do you have a pointer?

See = above.


The document already explains this as follows: =E2=80=9CTCP = connection table: Access to status information for all TCP connections. =  Note, the connection table is modeled as a list that is = read-writeable, even though a connection cannot be created by adding = entries to the table.  Similarly, deletion of connections from this = list is implementation-specific.=E2=80=9D I agree that if a TCP = connection were to be established by that table, wildcards would be = needed

Asking a simple = "netstat" question: How do you model sockets in the LISTEN
state?  For such sockets, how do you model listening on = one address or a
wildcard address?

=E2=80=93 but in reality = TCP connections are established by the application or service, e.g. by = the sockets API. One doesn=E2=80=99t use a YANG model for that, at least = as far as I know. If the list only includes established TCP connections, = every single TCP connection has a well-defined src/dst IP address and a = well-defined  src/dst port (5-tuple); on the connection initiator = side, src address and src port may be selected by the stack. The current = model in draft-ietf-tcpm-yang-tcp-06 also does not model a list of = listeners.

My point is made = for listeners.  I believe this is a model gap.

One way = that I have seen this modeled is as follows.

    leaf-list listen-addresses = {
      type union {
      =   type inet:ip-address;
    =     type enumeration {
  =         enum any {
  =           description
  =            "The agent should listen on any = address
              = bound to an interface on the system.";
    =       }
        }
        type string;
      }
    =   default =E2=80=9Cany";
    =   must "(not(../listen-addresses =3D =E2=80=98any' and = count(../listen-addresses) > 1))" {
    =     error-message =E2=80=9C=E2=80=98any', IP = addresses, and interface names are mutually exclusive";
      }
    =   description
      =   "The IP addresses that the agent should
  =        listen on. This may be an IPv4 or an IPv6 = address, interface name 
        =  or the enum =E2=80=98any=E2=80=99.";
    = }



[ms] In a nutshell, if = connections cannot be created by adding entries to the list, I don=E2=80=99= t understand why wildcards would be needed.
For operational state for listeners.  That said, I'm = less advocating for
"create a connection in this table" = and more about "how does a TCP client
wanting to use = TCP-AO get its job done?"

Things get interesting when you try to configure TCP-AO = parameters using this model. Theoretically, one does not know the = 4-tuple for a given connection, till the connection is already = established, by which time it is already too late to provide the AO = parameters, as they would be needed at connection establishment time. So = the short answer is, I do not know.


+ The binding between a = send-id and receive-id likely belong in the
=   keychain.  This likely requires augmenting the keychain = model.

Did you mean binding between tcp-ao and the = keychain model it is using?

I = mean that send-id/receive-id state likely belongs in an individual = keychain entry.  That means the keychain model needs augmenting. =  The augmentation can be sourced from the tcpm RFC.
[ms] That solution (used by all known router = implementations) is already explicitly explained in = draft-ietf-tcpm-yang-tcp-06 as follows: =E2=80=9CThe keychain for TCP-AO = can be modeled by the YANG Data Model for Key Chains [RFC8177]. =  The groupings defined in this document can be imported and used as = part of such a preconfiguration.=E2=80=9D

I don't find the example clear.  As noted above, = configuration state in
existing implementations requires a = binding of a send-id and a receive-id
(TCP-AO = configuration state) to the keychain entry.

Binding is = what the example in Section B.2 is trying to demonstrate. The send-id = (61) and recv-id (84) are bound to the keychain = =E2=80=9Cao-config=E2=80=9D.

I will = model in the RNextKeyId parameter, but the keychain model is not clear = in how it is going to use the RNextKeyId, or how the key rollover = happens. And draft-ietf-tcpm-ao-test-vectors does not have = an example for RNextKeyId. I can assume the bindings are similar, and = bind RNextKeyId to the keychain =E2=80=9Cao-config=E2=80=99, and a = keystring of =E2=80=98testvector=E2=80=99 much like =E2=80=98recv-id=E2=80= =99 and =E2=80=99send-id=E2=80=99. How does that sound?

Thanks.

Mahesh = Jethanandani
mjethanandani@gmail.com






= --Apple-Mail=_CDE10C6D-CB66-4332-B69E-BD4AF3F545F1--