From fluffy@fluffy.im  Tue Feb  7 09:43:32 2012
Return-Path: <fluffy@fluffy.im>
X-Original-To: tsv-area@ietfa.amsl.com
Delivered-To: tsv-area@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 621BB21F88C1; Tue,  7 Feb 2012 09:43:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.489
X-Spam-Level: 
X-Spam-Status: No, score=-3.489 tagged_above=-999 required=5 tests=[AWL=0.110,  BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
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 ZbIKSxrf4AIB; Tue,  7 Feb 2012 09:43:31 -0800 (PST)
Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 73F8321F870E; Tue,  7 Feb 2012 09:43:31 -0800 (PST)
Received: by iagf6 with SMTP id f6so12466905iag.31 for <multiple recipients>; Tue, 07 Feb 2012 09:43:31 -0800 (PST)
Received: by 10.42.136.69 with SMTP id s5mr22422583ict.20.1328636611034; Tue, 07 Feb 2012 09:43:31 -0800 (PST)
Received: from [192.168.4.100] (128-107-239-233.cisco.com. [128.107.239.233]) by mx.google.com with ESMTPS id ch2sm26025283igb.4.2012.02.07.09.43.28 (version=SSLv3 cipher=OTHER); Tue, 07 Feb 2012 09:43:29 -0800 (PST)
Sender: Cullen Jennings <fluffy@fluffy.im>
From: Cullen Jennings <fluffy@iii.ca>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Subject: tsv-dir review of draft-ietf-simple-chat-13
Date: Tue, 7 Feb 2012 10:43:27 -0700
Message-Id: <510CB696-780B-44D0-A72C-EA5BD9E479BD@iii.ca>
To: The IESG <iesg@ietf.org>, draft-ietf-simple-chat.all@tools.ietf.org
Mime-Version: 1.0 (Apple Message framework v1084)
X-Mailer: Apple Mail (2.1084)
Cc: tsv-area@ietf.org, Simple WG <simple@ietf.org>, Transport Directorate <tsv-dir@ietf.org>
X-BeenThere: tsv-area@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF Transport and Services Area Mailing List <tsv-area.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tsv-area>, <mailto:tsv-area-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tsv-area>
List-Post: <mailto:tsv-area@ietf.org>
List-Help: <mailto:tsv-area-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsv-area>, <mailto:tsv-area-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 07 Feb 2012 17:43:32 -0000

I've reviewed this document as part of the transport area directorate's =
ongoing effort to review key IETF documents. These comments were written =
primarily for the transport area directors, but are copied to the =
document's authors for their information and to allow them to address =
any issues raised. When done at the time of IETF Last Call, the authors =
should consider this review together with any other last-call comments =
they receive. Please always CC  tsv-dir@ietf.org if you reply to or =
forward this review.

Summary:

=46rom a transport point of view, this draft is ready for publication as =
a PS RFC.=20

=46rom a transport and congestion point of view, this draft does not =
change any of the underling MSRP behavior and thus this draft is the =
same as MSRP (RFC  4975 & RFC 4976).=20


Details:

There is one issue in the draft related to transport that, if addressed, =
I think would improve the draft.=20

Consider the case of  a chat room that is receiving messages at a rate =
of 10 per second (perhaps bad-attitude during the IESG plenary) and also =
has some clients in the chat room that can only receiving messages at a =
maximum rate of 5 per second ( perhaps an iphone via VPN over 2G). =
Section 6.1 does not say what should happen in this case.=20



From miguel.a.garcia@ericsson.com  Wed Feb  8 02:38:39 2012
Return-Path: <miguel.a.garcia@ericsson.com>
X-Original-To: tsv-area@ietfa.amsl.com
Delivered-To: tsv-area@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E3CE21F85D2; Wed,  8 Feb 2012 02:38:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.162
X-Spam-Level: 
X-Spam-Status: No, score=-10.162 tagged_above=-999 required=5 tests=[AWL=0.437, 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 ttyl2WW1ML2O; Wed,  8 Feb 2012 02:38:39 -0800 (PST)
Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 6247121F85D8; Wed,  8 Feb 2012 02:38:38 -0800 (PST)
X-AuditID: c1b4fb39-b7bf2ae0000069a1-03-4f3250acc309
Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id B3.B6.27041.CA0523F4; Wed,  8 Feb 2012 11:38:37 +0100 (CET)
Received: from [159.107.24.212] (153.88.115.8) by esessmw0184.eemea.ericsson.se (153.88.115.82) with Microsoft SMTP Server id 8.3.137.0; Wed, 8 Feb 2012 11:38:36 +0100
Message-ID: <4F3250AB.4060307@ericsson.com>
Date: Wed, 8 Feb 2012 11:38:35 +0100
From: "Miguel A. Garcia" <Miguel.A.Garcia@ericsson.com>
User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:10.0) Gecko/20120129 Thunderbird/10.0
MIME-Version: 1.0
To: Cullen Jennings <fluffy@iii.ca>
Subject: Re: tsv-dir review of draft-ietf-simple-chat-13
References: <510CB696-780B-44D0-A72C-EA5BD9E479BD@iii.ca>
In-Reply-To: <510CB696-780B-44D0-A72C-EA5BD9E479BD@iii.ca>
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 7bit
X-Brightmail-Tracker: AAAAAA==
X-Mailman-Approved-At: Thu, 09 Feb 2012 08:13:30 -0800
Cc: "draft-ietf-simple-chat.all@tools.ietf.org" <draft-ietf-simple-chat.all@tools.ietf.org>, Simple WG <simple@ietf.org>, "tsv-area@ietf.org" <tsv-area@ietf.org>, The IESG <iesg@ietf.org>, Transport Directorate <tsv-dir@ietf.org>
X-BeenThere: tsv-area@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF Transport and Services Area Mailing List <tsv-area.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tsv-area>, <mailto:tsv-area-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tsv-area>
List-Post: <mailto:tsv-area@ietf.org>
List-Help: <mailto:tsv-area-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsv-area>, <mailto:tsv-area-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 08 Feb 2012 10:38:39 -0000

Hi Cullen,

Thanks for your review. See inline comments.

On 07/02/2012 18:43, Cullen Jennings wrote:

> Consider the case of  a chat room that is receiving messages at a rate
> of 10 per second (perhaps bad-attitude during the IESG plenary) and
> also has some clients in the chat room that can only receiving
> messages at a maximum rate of 5 per second ( perhaps an iphone via VPN
> over 2G). Section 6.1 does not say what should happen in this case.

I understand the problem description. The question is whether we want to 
make the application layer aware of potential congestion and take actions 
on it.

I don't know how the chat room application could in the first place 
detect congestion. Any ideas of what to write in the draft are highly 
appreciated.

/Miguel


-- 
Miguel A. Garcia
+34-91-339-3608
Ericsson Spain

From fluffy@iii.ca  Mon Feb 13 12:30:47 2012
Return-Path: <fluffy@iii.ca>
X-Original-To: tsv-area@ietfa.amsl.com
Delivered-To: tsv-area@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B25C921E801B; Mon, 13 Feb 2012 12:30:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.915
X-Spam-Level: 
X-Spam-Status: No, score=-2.915 tagged_above=-999 required=5 tests=[AWL=-0.316, BAYES_00=-2.599]
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 bKflDNSMjcE0; Mon, 13 Feb 2012 12:30:47 -0800 (PST)
Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id 1BDB121E8018; Mon, 13 Feb 2012 12:30:47 -0800 (PST)
Received: from [192.168.4.100] (unknown [128.107.239.233]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id BAFB622E253; Mon, 13 Feb 2012 15:30:37 -0500 (EST)
Subject: Re: tsv-dir review of draft-ietf-simple-chat-13
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=us-ascii
From: Cullen Jennings <fluffy@iii.ca>
In-Reply-To: <4F3250AB.4060307@ericsson.com>
Date: Mon, 13 Feb 2012 13:30:37 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <E0B59A76-1E2D-404C-9099-E7C7B544432E@iii.ca>
References: <510CB696-780B-44D0-A72C-EA5BD9E479BD@iii.ca> <4F3250AB.4060307@ericsson.com>
To: "Miguel A. Garcia" <Miguel.A.Garcia@ericsson.com>
X-Mailer: Apple Mail (2.1084)
Cc: "draft-ietf-simple-chat.all@tools.ietf.org" <draft-ietf-simple-chat.all@tools.ietf.org>, Transport Directorate <tsv-dir@ietf.org>, "tsv-area@ietf.org" <tsv-area@ietf.org>, Simple WG <simple@ietf.org>, The IESG <iesg@ietf.org>
X-BeenThere: tsv-area@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF Transport and Services Area Mailing List <tsv-area.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tsv-area>, <mailto:tsv-area-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tsv-area>
List-Post: <mailto:tsv-area@ietf.org>
List-Help: <mailto:tsv-area-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsv-area>, <mailto:tsv-area-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 13 Feb 2012 20:30:47 -0000

On Feb 8, 2012, at 3:38 AM, Miguel A. Garcia wrote:

> Hi Cullen,
>=20
> Thanks for your review. See inline comments.
>=20
> On 07/02/2012 18:43, Cullen Jennings wrote:
>=20
>> Consider the case of  a chat room that is receiving messages at a =
rate
>> of 10 per second (perhaps bad-attitude during the IESG plenary) and
>> also has some clients in the chat room that can only receiving
>> messages at a maximum rate of 5 per second ( perhaps an iphone via =
VPN
>> over 2G). Section 6.1 does not say what should happen in this case.
>=20
> I understand the problem description. The question is whether we want =
to make the application layer aware of potential congestion and take =
actions on it.
>=20
> I don't know how the chat room application could in the first place =
detect congestion. Any ideas of what to write in the draft are highly =
appreciated.

Note - I'd be OK with publishing the document with no change but I think =
some text would improve the draft.

I think the most important part is just point out that this is a problem =
and applications need to have a strategy to deal with it. I would not =
prescribe a strategy that apps had to implement but instead have some =
non normative strategies that an application might use. One strategy is =
that is any client falls more than 10 seconds behind, that client get =
disconnected.=20




From miguel.a.garcia@ericsson.com  Mon Feb 13 22:51:23 2012
Return-Path: <miguel.a.garcia@ericsson.com>
X-Original-To: tsv-area@ietfa.amsl.com
Delivered-To: tsv-area@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1984621F86FC; Mon, 13 Feb 2012 22:51:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.28
X-Spam-Level: 
X-Spam-Status: No, score=-10.28 tagged_above=-999 required=5 tests=[AWL=0.319,  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 LnmrkqSroug7; Mon, 13 Feb 2012 22:51:22 -0800 (PST)
Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 918D721F86EE; Mon, 13 Feb 2012 22:51:21 -0800 (PST)
X-AuditID: c1b4fb39-b7bf2ae0000069a1-2d-4f3a0468aab2
Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id DB.8E.27041.8640A3F4; Tue, 14 Feb 2012 07:51:20 +0100 (CET)
Received: from [159.107.24.207] (153.88.115.8) by esessmw0184.eemea.ericsson.se (153.88.115.82) with Microsoft SMTP Server id 8.3.213.0; Tue, 14 Feb 2012 07:51:19 +0100
Message-ID: <4F3A0467.5020705@ericsson.com>
Date: Tue, 14 Feb 2012 07:51:19 +0100
From: "Miguel A. Garcia" <Miguel.A.Garcia@ericsson.com>
User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:10.0.1) Gecko/20120208 Thunderbird/10.0.1
MIME-Version: 1.0
To: Cullen Jennings <fluffy@iii.ca>
Subject: Re: tsv-dir review of draft-ietf-simple-chat-13
References: <510CB696-780B-44D0-A72C-EA5BD9E479BD@iii.ca> <4F3250AB.4060307@ericsson.com> <E0B59A76-1E2D-404C-9099-E7C7B544432E@iii.ca>
In-Reply-To: <E0B59A76-1E2D-404C-9099-E7C7B544432E@iii.ca>
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 7bit
X-Brightmail-Tracker: AAAAAA==
X-Mailman-Approved-At: Tue, 14 Feb 2012 00:13:42 -0800
Cc: "draft-ietf-simple-chat.all@tools.ietf.org" <draft-ietf-simple-chat.all@tools.ietf.org>, Transport Directorate <tsv-dir@ietf.org>, "tsv-area@ietf.org" <tsv-area@ietf.org>, Simple WG <simple@ietf.org>, The IESG <iesg@ietf.org>
X-BeenThere: tsv-area@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF Transport and Services Area Mailing List <tsv-area.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tsv-area>, <mailto:tsv-area-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tsv-area>
List-Post: <mailto:tsv-area@ietf.org>
List-Help: <mailto:tsv-area-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsv-area>, <mailto:tsv-area-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 14 Feb 2012 06:51:23 -0000

Your proposal sounds reasonable. Thanks.

/Miguel

On 13/02/2012 21:30, Cullen Jennings wrote:
>
> On Feb 8, 2012, at 3:38 AM, Miguel A. Garcia wrote:
>
>> Hi Cullen,
>>
>> Thanks for your review. See inline comments.
>>
>> On 07/02/2012 18:43, Cullen Jennings wrote:
>>
>>> Consider the case of  a chat room that is receiving messages at a rate
>>> of 10 per second (perhaps bad-attitude during the IESG plenary) and
>>> also has some clients in the chat room that can only receiving
>>> messages at a maximum rate of 5 per second ( perhaps an iphone via VPN
>>> over 2G). Section 6.1 does not say what should happen in this case.
>>
>> I understand the problem description. The question is whether we want to make the application layer aware of potential congestion and take actions on it.
>>
>> I don't know how the chat room application could in the first place detect congestion. Any ideas of what to write in the draft are highly appreciated.
>
> Note - I'd be OK with publishing the document with no change but I think some text would improve the draft.
>
> I think the most important part is just point out that this is a problem and applications need to have a strategy to deal with it. I would not prescribe a strategy that apps had to implement but instead have some non normative strategies that an application might use. One strategy is that is any client falls more than 10 seconds behind, that client get disconnected.
>
>
>

-- 
Miguel A. Garcia
+34-91-339-3608
Ericsson Spain

From dwing@cisco.com  Wed Feb 29 18:56:33 2012
Return-Path: <dwing@cisco.com>
X-Original-To: tsv-area@ietfa.amsl.com
Delivered-To: tsv-area@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31ED821E8080; Wed, 29 Feb 2012 18:56:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -108.885
X-Spam-Level: 
X-Spam-Status: No, score=-108.885 tagged_above=-999 required=5 tests=[AWL=1.714, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
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 nrAUUHj4RaqQ; Wed, 29 Feb 2012 18:56:32 -0800 (PST)
Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id E441921E801E; Wed, 29 Feb 2012 18:56:26 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=3434; q=dns/txt; s=iport; t=1330570586; x=1331780186; h=from:to:cc:subject:date:message-id:mime-version: content-transfer-encoding; bh=1LauwGOPKzwS6/4rBFU5vyM6YZxu5x1yVcOAi3w9J7Q=; b=VP+lgIMfcUJG0dhn74wLXDL4uj2Tx/WH+CbBhYdgRd1yMfuuE6b2R4ni BJMxfihB681XwavfCHeiTN/N08S/fnzcTNHluegJ5QJILAhExAgFvmBak sGCCeLs8laRefLCmL4xJeI6CCDkswvOBrJq9cL3aFDXDuvpY5dU2KU4RY Q=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Ag4FACrkTk+rRDoH/2dsb2JhbABDpC2PW4EHggEICgEXED8NBRhQIxwBBBMLF4dmoF8BlyiMfwMBDwsBAQoFAgJBAQEDDAsBAYUChCQEiE+FB5p7
X-IronPort-AV: E=Sophos;i="4.73,507,1325462400"; d="scan'208";a="31213932"
Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-1.cisco.com with ESMTP; 01 Mar 2012 02:56:26 +0000
Received: from dwingWS ([10.32.240.195]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id q212uQ1s008363; Thu, 1 Mar 2012 02:56:26 GMT
From: "Dan Wing" <dwing@cisco.com>
To: "'IETF discussion list'" <ietf@ietf.org>
Subject: tsv-dir review of draft-garcia-shim6-applicability-03
Date: Wed, 29 Feb 2012 18:56:26 -0800
Message-ID: <023f01ccf756$e4d4a110$ae7de330$@com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: Acz3VuR9N7pidru3QMmf+hQbv6UdHw==
Content-Language: en-us
Cc: 'marcelo bagnulo braun' <marcelo@it.uc3m.es>, joe.abley@icann.org, tsv-area@ietf.org, alberto@it.uc3m.es, 'Transport Directorate' <tsv-dir@ietf.org>
X-BeenThere: tsv-area@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF Transport and Services Area Mailing List <tsv-area.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tsv-area>, <mailto:tsv-area-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tsv-area>
List-Post: <mailto:tsv-area@ietf.org>
List-Help: <mailto:tsv-area-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsv-area>, <mailto:tsv-area-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 01 Mar 2012 02:56:33 -0000

I have reviewed this document as part of the transport area directorate's
ongoing effort to review key IETF documents. These comments were written
primarily for the transport area directors, but are copied to the document's
authors for their information and to allow them to address any issues
raised. When done at the time of IETF Last Call, the authors should consider
this review together with any other last-call comments they receive. Please
always CC tsv-dir@ietf.org if you reply to or forward this review.

This draft is basically ready for publication, but has nits that should be
fixed before publication.



Nits:

Section 1:

   Such problems are not specific of Shim6, but
   are suffered by the hosts of any site which is connected to multiple
   transit providers, and which receives an IPv6 prefix from each of the
   providers.

It might be useful to add a non-normative reference to RFC5220 at the end of
that sentence.


Section 3.4:

   The use of HBA is more efficient in the sense that addresses require
   less computation than CGA, involving only hash operations for both
   the generation and the verification of locator sets.  However, the
   locators of an HBA set are determined during the generation process,
   and cannot be subsequently changed; the addition of new locators to
   that initial set is not supported, except by re-generation of the
   entire set which will in turn cause all addresses to change.

I think that paragraph is too harsh, as it implies the old addresses
have to be invalidated immediately.  I expect existing connections 
could continue with the old addresses, and, if the host wanted to, 
could even have new connections use the old addresses.  If that
is not possible, the draft should explain why.  If that is possible,
the draft should probably explain it is possible.


Section 4:

   In order to configure source and destination address selection, tools
   such as DHCPv6 can be used to disseminate a [RFC3484] policy table to
   a host.

It might be useful to add a non-normative reference to
draft-ietf-6man-addr-select-opt.


Section 4:

The sentence ending with "properties exhibited by REAP." needs a reference
to RFC5544, which seems to be the RFC defining REAP.



Section 7.7, "Shim6 and IPv6 NAT", the problem could be overcome by the
Shim6 node knowing its IPv6 address after NPTv6 translation.  Probably not
worth adjusting the document, though, as NPTv6 is experimental.


Section 7.7:

   Note that an Application Level Gateway designed to modify the Shim6
   control packets would not be able to generate a valid signature, in
   case a CGA is being used, or a Parameter Data Structure binding the
   translated locator to the other locators of a node, in case a HBA is
   being used.  Therefore, the same failure cases described before would
   remain.

Applications are layer 7, Shim6 is layer 3, so an "Application Layer
Gateway" that modifies Shim6 control packets seems an abuse of terminology.
Suggest: 

OLD:
   Note that an Application Level Gateway designed to modify the Shim6
   control packets would not be able to generate a valid signature, in   
NEW:
   Note that modification of the Shim6 control packets by the IPv6 NAT 
.............^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   would not be able to generate a valid signature, in

-d