Re: [CCAMP] AD review of draft-ietf-ccamp-assoc-ext

"Adrian Farrel" <adrian@olddog.co.uk> Mon, 13 August 2012 09:19 UTC

Return-Path: <adrian@olddog.co.uk>
X-Original-To: ccamp@ietfa.amsl.com
Delivered-To: ccamp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0187C21F8701 for <ccamp@ietfa.amsl.com>; Mon, 13 Aug 2012 02:19:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.499
X-Spam-Level:
X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=0.100, 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 VwSutmXSWDNx for <ccamp@ietfa.amsl.com>; Mon, 13 Aug 2012 02:19:58 -0700 (PDT)
Received: from asmtp5.iomartmail.com (asmtp5.iomartmail.com [62.128.201.176]) by ietfa.amsl.com (Postfix) with ESMTP id 3993D21F8578 for <ccamp@ietf.org>; Mon, 13 Aug 2012 02:19:58 -0700 (PDT)
Received: from asmtp5.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id q7D9Je7j013703; Mon, 13 Aug 2012 10:19:49 +0100
Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id q7D9JdQW013671 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 13 Aug 2012 10:19:40 +0100
From: Adrian Farrel <adrian@olddog.co.uk>
To: 'Lou Berger' <lberger@labn.net>
References: <021a01cd7536$2104aa10$630dfe30$@olddog.co.uk> <50227712.4010203@labn.net> <056001cd7699$eb953330$c2bf9990$@olddog.co.uk> <50257116.5030201@labn.net>
In-Reply-To: <50257116.5030201@labn.net>
Date: Mon, 13 Aug 2012 10:19:36 +0100
Message-ID: <086a01cd7934$c30753b0$4915fb10$@olddog.co.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQH2xGWI71ErEuAv2SBWNzwa8SIWFAJTXtInAdtGSo8DAyZS85bLTnRQ
Content-Language: en-gb
Cc: draft-ietf-ccamp-assoc-ext.all@tools.ietf.org, 'CCAMP' <ccamp@ietf.org>
Subject: Re: [CCAMP] AD review of draft-ietf-ccamp-assoc-ext
X-BeenThere: ccamp@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: adrian@olddog.co.uk
List-Id: Discussion list for the CCAMP working group <ccamp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ccamp>, <mailto:ccamp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ccamp>
List-Post: <mailto:ccamp@ietf.org>
List-Help: <mailto:ccamp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ccamp>, <mailto:ccamp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 13 Aug 2012 09:19:59 -0000

Hi Lou,

> > The bottom line here appears to be:
> > - leave updates 4872
> 
> > - remove updates 2205, 3209, 3473
> 
> Are you sure about this?  Other RFCs that provide incremental functions
> that are not required by all implementations identify the base protocol
> in the Updates field. For example, take a look at rfc5151 it says both
> 3209 and 3473 are updated.

Are you sure the authors of 5151 did not intend that all new implementations of
3209 and 3473 should include full support for 5151?

But I can see that there may have been confusion in the WG consensus on this
point if there is lack of clarity about what "updates" means in the header. My
view is that "updates" means "this becomes part of the protocol spec originally
stated by the updated RFC". It is quite possible that this has not been
applied/enforced in the past, and I am currently hunting for a definitive
reference (if I can't find one, I will have to run some IETF process to create a
clear definition of "updates" for future use).

> >>> Section 4.1
[snip]
> How about:
> 
>   This field contains a value that is a unique global identifier or the
>   special value zero (0).  When non-zero and not overridden by local
>   policy, the Global_ID as defined in [RFC6370] SHALL be used.
>   The special value of zero indicates that no global identifier is
>   present. Note that a Global Association Source of zero SHOULD be
>   limited to entities contained within a single operator.

Yes. Thanks.

> >>> Section 4.1
[snip]
> >> How about:
> >>    Extended Association ID: variable, 4-byte aligned
> >>
> >>       This field contains data that is additional information to support
> >>       unique identification.  The length and contents of this field is
> >>       determined by the Association Source.  The length of this field
> >>       is derive from the object Length field and as such MUST have a
> >>       zero length or be 4-byte aligned.  A zero length indicates that
> >>       this field is omitted.
> >
> > Still having trouble with "determined by".  Try "dependent on".
> 
> how about "scoped by"

Yes.

Many thanks,
Adrian