From tom.taylor.stds@gmail.com Sun Apr 15 17:27:00 2012 Return-Path: X-Original-To: ancp@ietfa.amsl.com Delivered-To: ancp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EECB821F88F2 for ; Sun, 15 Apr 2012 17:26:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.271 X-Spam-Level: X-Spam-Status: No, score=-3.271 tagged_above=-999 required=5 tests=[AWL=0.328, 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 tbG5-oswZfma for ; Sun, 15 Apr 2012 17:26:59 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 30FD921F88EB for ; Sun, 15 Apr 2012 17:26:59 -0700 (PDT) Received: by lbbgf14 with SMTP id gf14so1639928lbb.31 for ; Sun, 15 Apr 2012 17:26:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding:x-antivirus :x-antivirus-status; bh=Q+aTPqg+M5FxsKBccpStVLa8o4necBtsz30+aQT7hrk=; b=nPYuIJc53VElvsNM+pXx2FbYeQuKJ5v2v+CE0GNlPgYQcJNB7T6JFP9koH13kAmc4O nxlFMi1JM4K/X8OfeG3gpoUDfbgg+7EXnUzCzN46tyKxGJON3dqy/VvRgkhWm1zUgEWj uApmDBxO0YWwAnmRJIUzloVCHJ6Awgp6oakdxceWtWgLldve8jP3chQfXuY/P/eel9E6 IPau7R7eOIxUuUPR4wSWL8WOMAOMNkmnZkFGDSTBhl18L5Qc+CF8VAyYlhSVo1Trs5Yo KBZS45JR6sFf8CTlVcARR3R7DppfE+X9zdY+X+LqGSIh46O+dHw/bNzw+FL2d4l3K5kC oXqQ== Received: by 10.152.105.226 with SMTP id gp2mr8429172lab.43.1334536018058; Sun, 15 Apr 2012 17:26:58 -0700 (PDT) Received: from [127.0.0.1] (dsl-207-112-91-137.tor.primus.ca. [207.112.91.137]) by mx.google.com with ESMTPS id b3sm22358194lby.7.2012.04.15.17.26.55 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 15 Apr 2012 17:26:56 -0700 (PDT) Message-ID: <4F8B6749.8040406@gmail.com> Date: Sun, 15 Apr 2012 20:26:49 -0400 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: "ancp@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 120415-1, 15/04/2012), Outbound message X-Antivirus-Status: Clean Subject: [ANCP] Specific versus general error codes X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Apr 2012 00:27:00 -0000 I'm doing my promised review of draft-ietf-ancp-mc-extensions-06.txt. So far I've found a few more-or-less editorial errors. I've now reached Section 4.3.2, where two new Result Code values are defined, but are not documented as fully as specified in the IANA Considerations section of RFC 6320. Before I expand the documentation, I'll ask whether the two codes are really useful, or whether they are sufficiently covered by 0x55 "Invalid TLV contents". The two codes are: 0x64 "Command error" (invalid command code received) and 0x65 "Bad flow address" (unsupported address family or ASM with source address or SSM without a source address). Tom Taylor From flefauch@cisco.com Mon Apr 16 02:08:06 2012 Return-Path: X-Original-To: ancp@ietfa.amsl.com Delivered-To: ancp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13A3921F873E for ; Mon, 16 Apr 2012 02:08:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.421 X-Spam-Level: X-Spam-Status: No, score=-10.421 tagged_above=-999 required=5 tests=[AWL=0.178, 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 zZbRy+aWtfNn for ; Mon, 16 Apr 2012 02:08:05 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 14B8921F8733 for ; Mon, 16 Apr 2012 02:08:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=flefauch@cisco.com; l=1781; q=dns/txt; s=iport; t=1334567284; x=1335776884; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=NBFF2fVTd7N4lAMYdBzJVWjj3/xWJ4McghWUranHj50=; b=IbszK4kNNsbEYsIdxxeySdJz+Yo11svuTJ7WWtyhe1HHxWlBAsOfGE8T MK8kzUfy83MY1TcV3f39jI4tMMTnq63+KbJJ7dHevtjQs5HZEGdTr4HPX usBdAQaTULUizJKoefUzJTmmQUo4VsBpAwPSzWp0YpCQznaQKp1TxCPIH I=; X-IronPort-AV: E=Sophos;i="4.75,427,1330905600"; d="scan'208";a="135254845" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-1.cisco.com with ESMTP; 16 Apr 2012 09:08:01 +0000 Received: from ams-flefauch-8713.cisco.com (ams-flefauch-8713.cisco.com [10.55.161.196]) by ams-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id q3G980Td008205; Mon, 16 Apr 2012 09:08:01 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Francois Le Faucheur In-Reply-To: <4F8B6749.8040406@gmail.com> Date: Mon, 16 Apr 2012 11:08:05 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4F8B6749.8040406@gmail.com> To: Tom Taylor X-Mailer: Apple Mail (2.1084) Cc: "ancp@ietf.org" Subject: Re: [ANCP] Specific versus general error codes X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Apr 2012 09:08:06 -0000 Hello Tom, I don't have an extremely strong view, but my input would be: * I think it is useful to be able to convey the actual reason = for "invalidity" (eg command error or bad flow address) * it could be done with a separate error code (as currently = proposed) or probably via the combination of a more generic error code = "Invalid TLV value" and a more explicit "error message" (as used in = 4.2.2). I personally have a weak preference for the former. In addition to the above, you probably have already noted that the error = codes are sometimes listed in decimal and sometimes in hex. eg. =20 - "0x64 | Command error." vs - "100 Command error. This SHOULD be reported for the = case that an invalid command code has been received." You may want to rename "Bad flow address" into "Invalid flow address". Cheers Francois On 16 Apr 2012, at 02:26, Tom Taylor wrote: > I'm doing my promised review of draft-ietf-ancp-mc-extensions-06.txt. = So far I've found a few more-or-less editorial errors. I've now reached = Section 4.3.2, where two new Result Code values are defined, but are not = documented as fully as specified in the IANA Considerations section of = RFC 6320. Before I expand the documentation, I'll ask whether the two = codes are really useful, or whether they are sufficiently covered by = 0x55 "Invalid TLV contents". The two codes are: >=20 > 0x64 "Command error" (invalid command code received) >=20 > and >=20 > 0x65 "Bad flow address" (unsupported address family or ASM with source = address or SSM without a source address). >=20 > Tom Taylor > _______________________________________________ > ANCP mailing list > ANCP@ietf.org > https://www.ietf.org/mailman/listinfo/ancp From tom.taylor.stds@gmail.com Mon Apr 16 05:56:13 2012 Return-Path: X-Original-To: ancp@ietfa.amsl.com Delivered-To: ancp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30A3621F8687 for ; Mon, 16 Apr 2012 05:56:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.312 X-Spam-Level: X-Spam-Status: No, score=-3.312 tagged_above=-999 required=5 tests=[AWL=0.287, 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 pA6eMGIdokWe for ; Mon, 16 Apr 2012 05:56:12 -0700 (PDT) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 3FB6321F867A for ; Mon, 16 Apr 2012 05:56:12 -0700 (PDT) Received: by lagj5 with SMTP id j5so4190552lag.31 for ; Mon, 16 Apr 2012 05:56:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding :x-antivirus:x-antivirus-status; bh=kWGf3Zyx+4ezhTS2SDh60PpLiEFoxw3zmDvBpRwurQk=; b=l29KgMC0iOkSopakGyz3Ez5nEL+CHOG4FroGASqMtxGtUhBURFrTaJk/RL7EPPl41W urAcGKsGekfaq0AnLTCXPbp7uTA81AdnwgGiCFzvL4uTqeSVqN6jEvbwe+mjXRBCNZA5 7s609RWSFsIPOygYupbRH7ChBuV/RTdSRXUl8jRCjH01RiWLszThp/BHXrarPzgy0xJg mF+Gd73PElwZEd3lL8eHwOO4b08sn+lBZCi58wj5chZqk3IaiDj3f2HAa0oMV77D94kZ zOmBBE3Id5RVlFn/w9zPjRAS+szAG2thbxyM4yzQHgaZz2hxcvV2r5FORULEn33tfvFG VwPQ== Received: by 10.152.105.241 with SMTP id gp17mr11094551lab.21.1334580971117; Mon, 16 Apr 2012 05:56:11 -0700 (PDT) Received: from [127.0.0.1] (dsl-207-112-91-137.tor.primus.ca. [207.112.91.137]) by mx.google.com with ESMTPS id te8sm19346845lab.3.2012.04.16.05.56.07 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 16 Apr 2012 05:56:09 -0700 (PDT) Message-ID: <4F8C16E5.1020406@gmail.com> Date: Mon, 16 Apr 2012 08:56:05 -0400 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: Francois Le Faucheur References: <4F8B6749.8040406@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 120416-0, 16/04/2012), Outbound message X-Antivirus-Status: Clean Cc: "ancp@ietf.org" Subject: Re: [ANCP] Specific versus general error codes X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Apr 2012 12:56:13 -0000 Thanks for the comments. Changing code values to hex to conform with the already-established registry is one of my editorial to-do's. On 16/04/2012 5:08 AM, Francois Le Faucheur wrote: > Hello Tom, > > I don't have an extremely strong view, but my input would be: > * I think it is useful to be able to convey the actual reason for "invalidity" (eg command error or bad flow address) > * it could be done with a separate error code (as currently proposed) or probably via the combination of a more generic error code "Invalid TLV value" and a more explicit "error message" (as used in 4.2.2). I personally have a weak preference for the former. > > > > In addition to the above, you probably have already noted that the error codes are sometimes listed in decimal and sometimes in hex. eg. > - "0x64 | Command error." vs > - "100 Command error. This SHOULD be reported for the case that an invalid command code has been received." > > > You may want to rename "Bad flow address" into "Invalid flow address". > > Cheers > > Francois > > > > > On 16 Apr 2012, at 02:26, Tom Taylor wrote: > >> I'm doing my promised review of draft-ietf-ancp-mc-extensions-06.txt. So far I've found a few more-or-less editorial errors. I've now reached Section 4.3.2, where two new Result Code values are defined, but are not documented as fully as specified in the IANA Considerations section of RFC 6320. Before I expand the documentation, I'll ask whether the two codes are really useful, or whether they are sufficiently covered by 0x55 "Invalid TLV contents". The two codes are: >> >> 0x64 "Command error" (invalid command code received) >> >> and >> >> 0x65 "Bad flow address" (unsupported address family or ASM with source address or SSM without a source address). >> >> Tom Taylor >> _______________________________________________ >> ANCP mailing list >> ANCP@ietf.org >> https://www.ietf.org/mailman/listinfo/ancp > > From tom.taylor.stds@gmail.com Mon Apr 23 17:46:57 2012 Return-Path: X-Original-To: ancp@ietfa.amsl.com Delivered-To: ancp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B41B421F8704 for ; Mon, 23 Apr 2012 17:46:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.399 X-Spam-Level: X-Spam-Status: No, score=-3.399 tagged_above=-999 required=5 tests=[AWL=0.200, 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 tffoQgREPTwd for ; Mon, 23 Apr 2012 17:46:56 -0700 (PDT) Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) by ietfa.amsl.com (Postfix) with ESMTP id 1FFB621F86B9 for ; Mon, 23 Apr 2012 17:46:55 -0700 (PDT) Received: by wibhq7 with SMTP id hq7so89366wib.13 for ; Mon, 23 Apr 2012 17:46:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding:x-antivirus :x-antivirus-status; bh=vGJdcVlDZV2eqrM1qPVsSzvaj6loT98mGkNwOQCezfs=; b=NG03zsGAPSzY6Va886sWEjxnN8smen5y0BkHX5/TmnsPMosMlsi/sRAI94KzRE/zQL Zu/zHgKalsll0I2fDR1dulMeQzy/UCV3dhrR0tPTNNkM+BF67yKtnazdoFui7qVKQGUH bd6U+U2H5npa3hatPr+iPgyE7bx1A7k5bhc5Jv2NkxJ4QbMUHi1e+bOxLcOYdVwnNsMY o4WhPmhYSiPZhA0jpYPkPZn4D2/d7U/kal9TAhaXFCHhewtA1+9A3hGLCaFuJwubQXY7 rL34PkbpmWQ3Eo2A2oL6E+vxz9eeBExjPTHz5ejrc43M+oCkNCJ/UTZgsehAEVBspPsP pwSg== Received: by 10.180.94.33 with SMTP id cz1mr26319065wib.13.1335228415126; Mon, 23 Apr 2012 17:46:55 -0700 (PDT) Received: from [127.0.0.1] (dsl-207-112-91-137.tor.primus.ca. [207.112.91.137]) by mx.google.com with ESMTPS id fn2sm40818517wib.0.2012.04.23.17.46.52 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 23 Apr 2012 17:46:53 -0700 (PDT) Message-ID: <4F95F7FC.5060303@gmail.com> Date: Mon, 23 Apr 2012 20:46:52 -0400 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: "ancp@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 120423-1, 23/04/2012), Outbound message X-Antivirus-Status: Clean Subject: [ANCP] Ambiguity in draft-ietf-ancp-mc-extensions-06.txt section 5.3 X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Apr 2012 00:46:57 -0000 Section 5.3 of draft-ietf-ancp-mc-extensions-06.txt defines the List-Action TLV, which is quite complex. Near the end of the section, the text allows prefix lengths of zero to signify wildcards. If a zero prefix length is used, the corresponding prefix is to be omitted. The text also says that a zero value for the source prefix length indicates ASM. This text fails to cover a couple of cases where the operator is using SSM, because it conflates the absence of a specific source address with ASM. The first case is when the operator wants to specify the combination of an SSM multicast group index and wildcarded source prefix. The second case is when the operator wants to wildcard everything (i.e. group and source prefix lengths both zero), but is using SSM. My proposed solution is to delete the following sentence: "In particular, a value of 0x00 for the Source PrefLen indicates an ASM multicast entry, and the Source Prefix will be absent." Obviously this means that in the case of a zero-length source address prefix, the AN does not know from the profile whether ASM or SSM is being used. I don't think the AN needs to know that to do its job -- it just has to admit or block flows based on the criteria given to it. Comments? Tom Taylor From tom.taylor.stds@gmail.com Mon Apr 23 18:30:15 2012 Return-Path: X-Original-To: ancp@ietfa.amsl.com Delivered-To: ancp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50AA221F86FF for ; Mon, 23 Apr 2012 18:30:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.414 X-Spam-Level: X-Spam-Status: No, score=-3.414 tagged_above=-999 required=5 tests=[AWL=0.185, 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 u7pqDnmkkZAc for ; Mon, 23 Apr 2012 18:30:14 -0700 (PDT) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by ietfa.amsl.com (Postfix) with ESMTP id 121F421F86FE for ; Mon, 23 Apr 2012 18:30:13 -0700 (PDT) Received: by wibhj6 with SMTP id hj6so2735387wib.13 for ; Mon, 23 Apr 2012 18:30:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding:x-antivirus :x-antivirus-status; bh=IskzD0fZNz67MFDpMPEFgN5C0KKwUg1NcDP9ZmjCrIA=; b=GKpP8E6S+L5Z+M0mrS/nOO+2tWZHCXjaEmY+6WDraWmEWJgzgMOTYiNqXr67nYA47g COnNSTqyz9Nt6dNy3fwVBZ6lRs4VEYP/s0AIa3L23jx6c+xCghKotxt7ipcJP1dt4Z3D v7uoRu/oJLUXCkCdR5LZl27tPVs8hDGD7hZcrNcysyPp6MgtW7VBWE3MeaoTkHh0S9Rr zkuuDeC50cLVQR2GZ0AXR2tMfuYIAgt2pdqvkrAMAY6Kkv6dM9ZdnG7zaQ7gjrEvcwC4 9FxFlj9DXcNQdwkF6WN/UnncdyI73Yfq5lPgMEFd1oiajljZ4vuqGDYEdZr7rCRf7TRn rA7Q== Received: by 10.180.78.9 with SMTP id x9mr2790835wiw.18.1335231013262; Mon, 23 Apr 2012 18:30:13 -0700 (PDT) Received: from [127.0.0.1] (dsl-207-112-91-137.tor.primus.ca. [207.112.91.137]) by mx.google.com with ESMTPS id n8sm41127976wix.10.2012.04.23.18.30.09 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 23 Apr 2012 18:30:12 -0700 (PDT) Message-ID: <4F960221.3030106@gmail.com> Date: Mon, 23 Apr 2012 21:30:09 -0400 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: "ancp@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 120423-1, 23/04/2012), Outbound message X-Antivirus-Status: Clean Subject: [ANCP] Non-existent result code in Section 6 of draft-ietf-ancp-mc-extensions-06.txt X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Apr 2012 01:30:15 -0000 Section 6 of draft-ietf-ancp-mc-extensions-06.txt refers to the following result code: 84 "TLV or value not supported by negotiated capability set" This was not defined in the base document (RFC 6320). Something of the sort, but perhaps more general, should have been defined there, something like: 0x54 "Not supported by negotiated set of capabilities" Should we write a separate draft updating RFC 6320 and adding this new value (setting a precedent for other general error codes), or just go ahead and define it in draft-ietf-ancp-mc-extensions? The amount of explanation goes beyond one paragraph, because handling of unsupported messages has to be described too. Comments? Tom Taylor From tom.taylor.stds@gmail.com Wed Apr 25 05:48:28 2012 Return-Path: X-Original-To: ancp@ietfa.amsl.com Delivered-To: ancp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84CF621F86C5 for ; Wed, 25 Apr 2012 05:48:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.426 X-Spam-Level: X-Spam-Status: No, score=-3.426 tagged_above=-999 required=5 tests=[AWL=0.173, 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 1dLfmIzqvsbR for ; Wed, 25 Apr 2012 05:48:27 -0700 (PDT) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id B75E021F86BE for ; Wed, 25 Apr 2012 05:48:26 -0700 (PDT) Received: by bkuw5 with SMTP id w5so40297bku.31 for ; Wed, 25 Apr 2012 05:48:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding:x-antivirus :x-antivirus-status; bh=X9VSKT9/+aXmAZP/f0YHbhmt6pI/gGTuxg7U0TBDO0Q=; b=s2t1T13p2jGu+ZsYUbALLUH98VXNzbVqEqXOFbnM/7P75KORHSJ7vaRlF5q9GGaWdc JfwHVmu4H5ZIen0xRkhknYhitFblDeX8V3vD3+oGsw/7drQtceS16nuUmIsDH8zpGX8o G7RL4i01TwZtTQesQ3Vp2p5X+s7nbjy7ZN0mlfGfAr2+mMxV7HnZI7iVv4BGctM4scSZ uspAGwQ7rRG6uOWInU+Z7rYwlXQCCjr+KdcXJ0S+jHwbbB5BbmKhtBod9m3US38bYGP+ aiUvqKMK+mBdIg6cwTDt8gEjDm0r/R6WneDdr/jwBLr0mcOsD3DShG3HmPxJ3ISmPjhP xZBA== Received: by 10.205.124.14 with SMTP id gm14mr802449bkc.139.1335358105809; Wed, 25 Apr 2012 05:48:25 -0700 (PDT) Received: from [127.0.0.1] (dsl-207-112-91-137.tor.primus.ca. [207.112.91.137]) by mx.google.com with ESMTPS id z17sm38344442bkw.12.2012.04.25.05.48.22 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 25 Apr 2012 05:48:23 -0700 (PDT) Message-ID: <4F97F293.20009@gmail.com> Date: Wed, 25 Apr 2012 08:48:19 -0400 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: "ancp@ietf.org" , "ancp-chairs@tools.ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 120425-0, 25/04/2012), Outbound message X-Antivirus-Status: Clean Subject: [ANCP] draft-ietf-ancp-mc-extensions-06 X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Apr 2012 12:48:28 -0000 I have finished my review of draft-ietf-ancp-mc-extensions-06. Fortunately, I have not identified any further substantive issues other than the two I reported to the list the other day, but I do propose quite a few editorial changes. I could enumerate them if so desired. I need direction going forward. Shall I update the document with all my proposed changes and do a separate draft for the new 0x54 error code? I could delete explicit reference to that code in the multicast extensions draft, so we wouldn't have a dependency issue holding up publication. Then the new error code draft could be held open if implementers think they might come up with other base-level error codes. Tom Taylor From matthew.bocci@alcatel-lucent.com Thu Apr 26 01:39:23 2012 Return-Path: X-Original-To: ancp@ietfa.amsl.com Delivered-To: ancp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F47C21F87BC for ; Thu, 26 Apr 2012 01:39:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.602 X-Spam-Level: X-Spam-Status: No, score=-109.602 tagged_above=-999 required=5 tests=[AWL=0.647, BAYES_00=-2.599, HELO_EQ_FR=0.35, 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 4hJt-TVl0Ue7 for ; Thu, 26 Apr 2012 01:39:23 -0700 (PDT) Received: from smail2.alcatel.fr (smail2.alcatel.fr [64.208.49.57]) by ietfa.amsl.com (Postfix) with ESMTP id A104321F87C0 for ; Thu, 26 Apr 2012 01:39:22 -0700 (PDT) Received: from FRMRSSXCHHUB04.dc-m.alcatel-lucent.com (FRMRSSXCHHUB04.dc-m.alcatel-lucent.com [135.120.45.64]) by smail2.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id q3Q8XnHU001754 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 26 Apr 2012 10:39:17 +0200 Received: from FRMRSSXCHMBSA3.dc-m.alcatel-lucent.com ([135.120.45.36]) by FRMRSSXCHHUB04.dc-m.alcatel-lucent.com ([135.120.45.64]) with mapi; Thu, 26 Apr 2012 10:38:24 +0200 From: "Bocci, Matthew (Matthew)" To: Tom Taylor , "ancp@ietf.org" , "ancp-chairs@tools.ietf.org" Date: Thu, 26 Apr 2012 10:38:22 +0200 Thread-Topic: draft-ietf-ancp-mc-extensions-06 Thread-Index: Ac0jh/DLJxmdikaCT1So/g51T2VK3A== Message-ID: In-Reply-To: <4F97F293.20009@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.0.120402 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.80 Subject: Re: [ANCP] draft-ietf-ancp-mc-extensions-06 X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Apr 2012 08:39:23 -0000 Tom, It does seem to make sense to create a separate draft defining the error code and its associated handling if we think that it would be of use elsewhere and off it might be added to. I propose the following way forward: - Create a cleaned up version of the MC extensions draft - create a separate error codes draft - Run a short 1 week WG LC on the changes to the MC extensions draft. - WG LC the error codes draft once MC extensions has gone to the IESG. Regards Matthew On 25/04/2012 13:48, "Tom Taylor" wrote: >I have finished my review of draft-ietf-ancp-mc-extensions-06. >Fortunately, I have not identified any further substantive issues other >than the two I reported to the list the other day, but I do propose >quite a few editorial changes. I could enumerate them if so desired. > >I need direction going forward. Shall I update the document with all my >proposed changes and do a separate draft for the new 0x54 error code? I >could delete explicit reference to that code in the multicast extensions >draft, so we wouldn't have a dependency issue holding up publication. >Then the new error code draft could be held open if implementers think >they might come up with other base-level error codes. > >Tom Taylor From flefauch@cisco.com Thu Apr 26 05:00:48 2012 Return-Path: X-Original-To: ancp@ietfa.amsl.com Delivered-To: ancp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDFB621F87BC for ; Thu, 26 Apr 2012 05:00:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.152 X-Spam-Level: X-Spam-Status: No, score=-10.152 tagged_above=-999 required=5 tests=[AWL=0.446, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 8AcEcu5PBrcj for ; Thu, 26 Apr 2012 05:00:48 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id B999121F87AA for ; Thu, 26 Apr 2012 05:00:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=flefauch@cisco.com; l=4735; q=dns/txt; s=iport; t=1335441647; x=1336651247; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to; bh=rxOJeJWIhthvejniLHAACmwB36b5CQj7orLc0VKoSwM=; b=C0ePnsyaZ5F22j6BIOPZwTzs+V/lEALuUtGHrxYq5W/QFuX8ox+DAocA FwQrC7mWhVcNOmJWm7pK/31S5NfstybVpmDMSZL2eVgTE0p+ittRzsGKr L5ShpEt4a04qT8H+NQBRNnvEb07cnvxW5z8vsy+8VY1ERfGQH75XhDDpB U=; X-IronPort-AV: E=Sophos;i="4.75,486,1330905600"; d="scan'208,217";a="71823374" Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-2.cisco.com with ESMTP; 26 Apr 2012 12:00:46 +0000 Received: from ams-flefauch-8712.cisco.com (ams-flefauch-8712.cisco.com [10.55.161.195]) by ams-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id q3QC0j2Z016541; Thu, 26 Apr 2012 12:00:46 GMT Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: multipart/alternative; boundary="Apple-Mail=_65BA4A5F-65B6-4DD7-B455-4158783CE86F" From: Francois Le Faucheur In-Reply-To: Date: Thu, 26 Apr 2012 14:00:40 +0200 Message-Id: <8848D605-B3EB-471E-8CEA-653CB7AE3A52@cisco.com> References: To: "Bocci, Matthew (Matthew)" X-Mailer: Apple Mail (2.1257) Cc: "ancp@ietf.org" , "ancp-chairs@tools.ietf.org" Subject: Re: [ANCP] draft-ietf-ancp-mc-extensions-06 X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Apr 2012 12:00:48 -0000 --Apple-Mail=_65BA4A5F-65B6-4DD7-B455-4158783CE86F Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii On 26 Apr 2012, at 10:38, Bocci, Matthew (Matthew) wrote: > Tom, > > It does seem to make sense to create a separate draft defining the error > code and its associated handling if we think that it would be of use > elsewhere and off it might be added to. > > I propose the following way forward: > > - Create a cleaned up version of the MC extensions draft > - create a separate error codes draft > - Run a short 1 week WG LC on the changes to the MC extensions draft. > - WG LC the error codes draft once MC extensions has gone to the IESG. Works for me. Francois > > Regards > > Matthew > > On 25/04/2012 13:48, "Tom Taylor" wrote: > >> I have finished my review of draft-ietf-ancp-mc-extensions-06. >> Fortunately, I have not identified any further substantive issues other >> than the two I reported to the list the other day, but I do propose >> quite a few editorial changes. I could enumerate them if so desired. >> >> I need direction going forward. Shall I update the document with all my >> proposed changes and do a separate draft for the new 0x54 error code? I >> could delete explicit reference to that code in the multicast extensions >> draft, so we wouldn't have a dependency issue holding up publication. >> Then the new error code draft could be held open if implementers think >> they might come up with other base-level error codes. >> >> Tom Taylor > > _______________________________________________ > ANCP mailing list > ANCP@ietf.org > https://www.ietf.org/mailman/listinfo/ancp --Apple-Mail=_65BA4A5F-65B6-4DD7-B455-4158783CE86F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
Tom,

It does seem to make sense to create a = separate draft defining the error
code and its associated handling if = we think that it would be of use
elsewhere and off it might be added = to.

I propose the following way forward:

- Create a = cleaned up version of the MC extensions draft
- create a separate = error codes draft
- Run a short 1 week WG LC on the changes to the MC = extensions draft.
- WG LC the error codes draft once MC extensions = has gone to the IESG.

Works = for = me.

Francois



Regards

Matthew

On 25/04/2012 = 13:48, "Tom Taylor" <tom.taylor.stds@gmail.com>= ; wrote:

I have finished my review of = draft-ietf-ancp-mc-extensions-06.
Fortunately, I have not identified any further substantive = issues other
than the two I = reported to the list the other day, but I do = propose
quite a few editorial = changes. I could enumerate them if so = desired.

I need = direction going forward. Shall I update the document with all = my
proposed changes and do a = separate draft for the new 0x54 error code? = I
could delete explicit = reference to that code in the multicast = extensions
draft, so we = wouldn't have a dependency issue holding up = publication.
Then the new = error code draft could be held open if implementers = think
they might come up with = other base-level error codes.

Tom = Taylor

_______________________________________________=
ANCP mailing list
ANCP@ietf.org
https://www.ietf.org/ma= ilman/listinfo/ancp

Date: Mon, 30 Apr 2012 17:26:39 -0700 Cc: ancp@ietf.org Subject: [ANCP] I-D Action: draft-ietf-ancp-mc-extensions-07.txt X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 May 2012 00:26:40 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Access Node Control Protocol Working = Group of the IETF. Title : Multicast Control Extensions for ANCP Author(s) : Francois Le Faucheur Roberta Maglione Tom Taylor Filename : draft-ietf-ancp-mc-extensions-07.txt Pages : 97 Date : 2012-04-30 This document specifies the extensions to the Access Node Control Protocol required for support of the multicast use cases defined in the Access Node Control Protocol framework document and one additional use case described in this document. These use cases are organized into the following ANCP capabilities: o NAS-initiated multicast replication; o conditional access with white and black lists; o conditional access with grey lists; o bandwidth delegation; o committed bandwidth reporting. These capabilities may be combined according to the rules given in this specification. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ancp-mc-extensions-07.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-ancp-mc-extensions-07.txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-ancp-mc-extensions/ From tom.taylor.stds@gmail.com Mon Apr 30 17:35:56 2012 Return-Path: X-Original-To: ancp@ietfa.amsl.com Delivered-To: ancp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A8CF21F8567 for ; Mon, 30 Apr 2012 17:35:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.437 X-Spam-Level: X-Spam-Status: No, score=-3.437 tagged_above=-999 required=5 tests=[AWL=0.162, 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 CFWQI1dNi5Dj for ; Mon, 30 Apr 2012 17:35:56 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id D873221F84C8 for ; Mon, 30 Apr 2012 17:35:55 -0700 (PDT) Received: by obbeh20 with SMTP id eh20so1769480obb.31 for ; Mon, 30 Apr 2012 17:35:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding:x-antivirus :x-antivirus-status; bh=pGpDXJPoODJMMIriaY3Xtda5Z5YKHLpxN2Xh4yMwn3Y=; b=WFj7Ec2IboqfqGMIxv51p47sKabmUJ12OYYcOK+H8pF4lXL2qfm3wLeP4Ndg8FTQGR yVmJoSbI74xuAOSKOiXfE7dzvKjNHg/gZWakL8587CgZeuEPyHNvolLJTJY+L/O0Y8VI Mo6vDNA23kZ3frn5drdgx/P69+yu75RQmF5WFeJ86dPIsV0yIAopshj9GqEktj75xwbV CaSFsBTp16aedIBhDGlsrF11ZVJPuTUFUjgjLH0FYbSpM5T0sEkDYBOTpM9SPI+0/JoS jgCR9/HhLG0k9qiBvh3d+bg5UU1iNEfm9UxcUj6Rca3h6zwV6m/gw/cD3KI7O1MeDT7T cUjw== Received: by 10.182.46.100 with SMTP id u4mr7481272obm.46.1335832555536; Mon, 30 Apr 2012 17:35:55 -0700 (PDT) Received: from [127.0.0.1] (dsl-207-112-91-137.tor.primus.ca. [207.112.91.137]) by mx.google.com with ESMTPS id s8sm14980124oec.1.2012.04.30.17.35.53 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 30 Apr 2012 17:35:54 -0700 (PDT) Message-ID: <4F9F2FE9.8000604@gmail.com> Date: Mon, 30 Apr 2012 20:35:53 -0400 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: "ancp@ietf.org" , "ancp-chairs@tools.ietf.org" Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 120430-1, 30/04/2012), Outbound message X-Antivirus-Status: Clean Subject: [ANCP] ANCP multicast extensions changes X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 May 2012 00:35:56 -0000 I have submitted a new version of the ANCP multicast extensions document. Most of the changes were trivial edits (e.g., "white", "black", and "grey" changed uniformly to lower case). Here are the more significant changes: General - In all message illustrations, got rid of sub-version in the ANCP header. - aligned codepoint presentation (hex or decimal) with the presentation in the IANA Considerations section of RFC 6320. - documented the new Result Codes properly, as required by the RFC 6320. Section 4.2 - added text on setting the Function field in the Port Management message Section 4.2.2 - cleaned up Result Code reference Section 4.3 - added missing column in Figure 5 - gave forward reference for occurence of "Other Embedded TLV" - changed IPv4 addresses in example to IPv6 so there is at least one IPv6 example in the document Section 4.3.2 - fixed incorrect Result Code reference - added proper documentation for new Result Codes 0x64, 0x65, 0x66 Section 4.4.1, 4.4.2 - referred to RFC 6320 for Transaction ID Section 4.5.1, 4.5.2 - added Result Code in bullet a of deadlock avoidance in Section 4.5.2 - provided proper documentation for the three new Result Codes 0x67, 0x68, 0x69 Section 4.7.2 - corrected Result Code reference Section 5.2 - changed units of Multicast-Service-Profile-Name from bits to octets Section 5.3 - SUBSTANTIVE: as indicated on the list, deleted the statement: "In particular, a value of 0x00 for the Source PrefLen indicates an ASM multicast entry, and the Source Prefix will be absent." Remain sub-sections of Section 5 Section 6 - SEMI-SUBSTANTIVE: as discussed on the list, deleted the example reference to the Result Code "TLV or value not supported by negotiated capability set". I'll be submitting a separate I-D for that one any others people think should be added to the base protocol. Section 6.1 - added note that Target TLV has to be supported in every capability Section 6.1.1 - added note that Command TLV has to be supported - corrected name of Sequence number TLV in table - added Bandwidth-Allocation TLV to table Section 6.1.4 - added note that Command TLV has to be supported - corrected name of Sequence number TLV in table Section 6.2.1, 6.2.2 - changed "MAY"s to "may"s given the context Section 6.3.3 - rewrote third paragraph in active voice to make it clearer Section 7 - slight expansion of security considerations, nothing substantive added Section 8 - slight renaming of new Result Code 0x65 - presentation adjustments for TLV codepoints References - deleted RFC 3292 (replaced with RFC6320 somewhere further back) Section A.2 - added references to figures in body of text, causing figures to receive numbers (e.g., newly-numbered Figure 24) -- hence subsequent figures that had numbers before now have new numbers Tom Taylor