Re: [Aggsrv] understanding the scope of "discovery"

"Andrew Biggs (adb)" <adb@cisco.com> Tue, 19 March 2013 15:22 UTC

Return-Path: <adb@cisco.com>
X-Original-To: aggsrv@ietfa.amsl.com
Delivered-To: aggsrv@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 907AF21F8D5F for <aggsrv@ietfa.amsl.com>; Tue, 19 Mar 2013 08:22:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Level:
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DU7haN8tTxWG for <aggsrv@ietfa.amsl.com>; Tue, 19 Mar 2013 08:22:35 -0700 (PDT)
Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id EE91B21F8D5D for <aggsrv@ietf.org>; Tue, 19 Mar 2013 08:22:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1596; q=dns/txt; s=iport; t=1363706555; x=1364916155; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=SKtlM9CltAItBbi1WqKbklEXDBzXFHx4zsrMZcCeIuU=; b=b7PJa8MFYC4ALzqdevNSXjsbWRRx+TqSiVvxONm9d6lxl6nhHoGdiql6 MmkyquXTvubrf/dLZSxJ3ZPA05h2PNbc0Sm2DIzvcdTnhtqx8BeI0Jqkd TSAts+Eo6bo6KIuxoZavM8Gi1z3LanEuVkQRBf/Pgf92ZOhGw4lmMIlDg o=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av8EAACCSFGtJV2c/2dsb2JhbABDxQ+BVxZ0giQBAQEEOj8SAQgYChRCJQIEDgUIiAyyLZAejU0LgQUxB4JfYQOnYYMKgWo+
X-IronPort-AV: E=Sophos;i="4.84,872,1355097600"; d="scan'208";a="189082089"
Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-2.cisco.com with ESMTP; 19 Mar 2013 15:22:34 +0000
Received: from xhc-rcd-x11.cisco.com (xhc-rcd-x11.cisco.com [173.37.183.85]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id r2JFMYPP012507 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 19 Mar 2013 15:22:34 GMT
Received: from xmb-aln-x06.cisco.com ([169.254.1.248]) by xhc-rcd-x11.cisco.com ([173.37.183.85]) with mapi id 14.02.0318.004; Tue, 19 Mar 2013 10:22:34 -0500
From: "Andrew Biggs (adb)" <adb@cisco.com>
To: Alexey Melnikov <alexey.melnikov@isode.com>
Thread-Topic: [Aggsrv] understanding the scope of "discovery"
Thread-Index: AQHOI0zhdxnePYTEk0CJfRyfOYIPh5itXyoA//+0nwA=
Date: Tue, 19 Mar 2013 15:22:33 +0000
Message-ID: <4289BE64A83C6C4384EE9245D4644539237DE086@xmb-aln-x06.cisco.com>
In-Reply-To: <0D99038D-1D63-4B6E-944A-7F1EFF255F8C@isode.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.3.1.130117
x-originating-ip: [10.129.24.51]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <772613667A0EC349988247E64EABC990@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "aggsrv@ietf.org" <aggsrv@ietf.org>
Subject: Re: [Aggsrv] understanding the scope of "discovery"
X-BeenThere: aggsrv@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Aggregated Service Discovery \(aggsrv\)" <aggsrv.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/aggsrv>, <mailto:aggsrv-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/aggsrv>
List-Post: <mailto:aggsrv@ietf.org>
List-Help: <mailto:aggsrv-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/aggsrv>, <mailto:aggsrv-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 19 Mar 2013 15:22:35 -0000

I definitely agree, it might even be worth making an explicit statement to
that effect in the draft.

Even in the case where the protocol being negotiated doesn't provide a
means for establishing a given operational parameter, I'm wondering if we
should provide any guidance on the kind of information that should be
included as part of discovery.  For example, should it be limited strictly
to information needed to establish a connection to a service, or should
implementors be free to include anything they find useful, up to and
including general client configuration?


On 3/19/13 7:52 AM, "Alexey Melnikov" <alexey.melnikov@isode.com> wrote:

>Hi Andrew,
>
>IMHO, if these things are available in the protocol being negotiated,
>then I think they shouldn't be returned by the aggregated service
>discovery.
>
>On 17 Mar 2013, at 16:20, "Andrew Biggs (adb)" <adb@cisco.com> wrote:
>
>> I thought an interesting point raised in the BoF was the possible
>>overlap of aggregated discovery with the idea of automated client
>>configuration.  This got me to wonder where the line ought to be drawn,
>>if at all, as to the sort of information intended for inclusion in an
>>aggregated service discovery document.  For example, would any of the
>>following be appropriate data to include in a discovery document when
>>configuring a particular service?
>> 
>> * Synchronization window (such as for calendaring).
>> * Session timeout.
>> * Minimum polling interval.
>> * Settings defaults for client behaviors, auto sign-in, etc.
>> 
>> Cheers,
>> Andrew
>