Re: [MMUSIC] Review of draft-ietf-mmusic-trickle-ice-02

Peter Saint-Andre - &yet <peter@andyet.net> Mon, 19 October 2015 18:05 UTC

Return-Path: <peter@andyet.net>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 321101B2A90 for <mmusic@ietfa.amsl.com>; Mon, 19 Oct 2015 11:05:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level:
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
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 wN8LRJMfZyaA for <mmusic@ietfa.amsl.com>; Mon, 19 Oct 2015 11:05:00 -0700 (PDT)
Received: from mail-io0-f177.google.com (mail-io0-f177.google.com [209.85.223.177]) (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 88D181B2A73 for <mmusic@ietf.org>; Mon, 19 Oct 2015 11:05:00 -0700 (PDT)
Received: by iofz202 with SMTP id z202so61487191iof.2 for <mmusic@ietf.org>; Mon, 19 Oct 2015 11:05:00 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=QWhMHkL64wxeTMz4gHSVLNV1AM17gjQQETQUPu90nCE=; b=jOT+12Mi8Uzm/VstT39e1HCdfYjeETXbOjBrgS4eJ3AmCg6SXhnL/K/mCEss38ZM6K gmqKrQbipDm5CHaZxyd4uJVNgdgulsOEWpxYIVNiKPlIkAseET+7rsc6P+yvBDnk6awk lBcv3xzgkd266ySiiTjFOaT6xZyo/+h2laq/5GyKblpHsDjIhL91UqKiPOMjL8M47fWH rOO67bpPTOS+HptAHRYFzM6Q2knmNyxTR2IBCghpYiJuVMeQplRJsWJmA+K3/SZYnTOz MUHny8/xdOV2do+N/dbtqKAAsAJGdP/7DaY+WwD+5U76IZ1S+n3Dj7wh7JILfkZe68Iw kDbQ==
X-Gm-Message-State: ALoCoQnG7Dvasfq+Y271mH/KakcDZCO3nNWTXwbf7+C0dxWqumaXXsIhhMJARrQRpJdmt64b/Y+Z
X-Received: by 10.107.160.67 with SMTP id j64mr31486109ioe.128.1445277899830; Mon, 19 Oct 2015 11:04:59 -0700 (PDT)
Received: from aither.local (c-73-34-202-214.hsd1.co.comcast.net. [73.34.202.214]) by smtp.googlemail.com with ESMTPSA id p189sm14369894ioe.21.2015.10.19.11.04.58 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 19 Oct 2015 11:04:58 -0700 (PDT)
To: Brandon Williams <brandon.williams@akamai.com>, mmusic@ietf.org, draft-ietf-mmusic-trickle-ice@tools.ietf.org
References: <55E8A14B.5080305@akamai.com> <561F1C2A.5090008@andyet.net> <561FB305.30001@akamai.com>
From: Peter Saint-Andre - &yet <peter@andyet.net>
Message-ID: <562530C9.3010004@andyet.net>
Date: Mon, 19 Oct 2015 12:04:57 -0600
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.2.0
MIME-Version: 1.0
In-Reply-To: <561FB305.30001@akamai.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/mmusic/SiOHE25k6p9oI0ArojLpjaPcYwk>
Subject: Re: [MMUSIC] Review of draft-ietf-mmusic-trickle-ice-02
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mmusic/>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 19 Oct 2015 18:05:05 -0000

On 10/15/15 8:07 AM, Brandon Williams wrote:
> On 10/14/2015 11:23 PM, Peter Saint-Andre - &yet wrote:
>>> s 6.2
>>> It's unclear to me why it's useful to monitor Active/Frozen state for
>>> check lists with no remote and/or local candidates.
>>
>> Does §6.2 actually say that?
>>
>>> What is actually
>>> being monitored in? Or is this just meant to indicate than an empty
>>> checklist MUST/SHOULD be treated as frozen for the purpose of the frozen
>>> candidates algorithm?
>
> I was referring to this text from section 6.2:
>
>     Obviously in
>     order for candidate pairing to be possible, it would be necessary
>     that both the offer and the answer contained candidates.  If this was
>     not the case agents will still create the check lists (so that their
>     Active/Frozen state could be monitored and updated) but they will
>     only populate them once they actually have the candidate pairs.
>
> This does seem to indicate that empty checklists might be created for
> the purpose Active/Frozen state monitoring.

Yes, it does. The assumption seems to be that candidate pairs will be 
forthcoming and that the user agents won't do any checking until the 
checklist is non-empty. Does that seem to be problematic?

Peter