Re: [CCAMP] WG Last Call: WSON documents - draft-ietf-ccamp-rwa-info
Lou Berger <lberger@labn.net> Thu, 30 January 2014 00:50 UTC
Return-Path: <lberger@labn.net>
X-Original-To: ccamp@ietfa.amsl.com
Delivered-To: ccamp@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 076891A0475 for <ccamp@ietfa.amsl.com>; Wed, 29 Jan 2014 16:50:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level:
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 eu3cWamap5PA for <ccamp@ietfa.amsl.com>; Wed, 29 Jan 2014 16:50:34 -0800 (PST)
Received: from alt-proxy39.mail.unifiedlayer.com (alt-proxy39.mail.unifiedlayer.com [74.220.209.1]) by ietfa.amsl.com (Postfix) with SMTP id D60E91A046B for <ccamp@ietf.org>; Wed, 29 Jan 2014 16:50:33 -0800 (PST)
Received: (qmail 1884 invoked by uid 0); 30 Jan 2014 00:49:23 -0000
Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by oproxy13.mail.unifiedlayer.com with SMTP; 30 Jan 2014 00:49:23 -0000
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Subject:References:In-Reply-To:Message-ID:Date:To:From; bh=Gl5fyBTgCNyX7u5puHwR6PpZ+H8tTc3msYVph7QbOtA=; b=stUyuepksAG5I9g24RCSvXYL5s8fFmSUSR/oEp/8TcMQc6ZKpTLKryOjYkiCMJsuUnjj1xFg0fFxBzk/eWcWSNOwmu31/477UnubovhjlC0ORLBNRpqey/7Hxkeu+mtk;
Received: from box313.bluehost.com ([69.89.31.113]:44328 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.80) (envelope-from <lberger@labn.net>) id 1W8fop-0001NO-Iq; Wed, 29 Jan 2014 17:49:23 -0700
From: Lou Berger <lberger@labn.net>
To: Leeyoung <leeyoung@huawei.com>, CCAMP <ccamp@ietf.org>, draft-ietf-ccamp-rwa-info@tools.ietf.org
Date: Wed, 29 Jan 2014 19:49:22 -0500
Message-ID: <143e09f1698.2764.9b4188e636579690ba6c69f2c8a0f1fd@labn.net>
In-Reply-To: <7AEB3D6833318045B4AE71C2C87E8E1729BB4EC9@dfweml706-chm.china.huawei.com>
References: <524AF9A9.3040006@labn.net> <5266E138.8080605@labn.net> <526FFDBB.4020504@labn.net> <7AEB3D6833318045B4AE71C2C87E8E17291E1BD8@dfweml511-mbs.china.huawei.com> <52DD7E93.1000805@labn.net> <7AEB3D6833318045B4AE71C2C87E8E1729BB4511@dfweml706-chm.china.huawei.com> <52E830A5.2050301@labn.net> <7AEB3D6833318045B4AE71C2C87E8E1729BB4EC9@dfweml706-chm.china.huawei.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 AquaMail/1.3.8 (build: 2100414)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Content-Transfer-Encoding: 8bit
X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net}
Subject: Re: [CCAMP] WG Last Call: WSON documents - draft-ietf-ccamp-rwa-info
X-BeenThere: ccamp@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
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: Thu, 30 Jan 2014 00:50:37 -0000
Young, Looks good to me. Much thanks, Lou On January 29, 2014 7:21:10 PM Leeyoung <leeyoung@huawei.com> wrote: > Hi Lou, > > Please see inline for my resolution to your comments. > Attached is working version of draft-ietf-ccamp-rwa-info-20 and idnit > results that indicate no issue found with the draft. > > Let me know if this is ready to publish. > > Thanks. > Young > > -----Original Message----- > From: Lou Berger [mailto:lberger@labn.net] Sent: Tuesday, January 28, 2014 > 4:35 PM > To: Leeyoung; CCAMP; draft-ietf-ccamp-rwa-info@tools.ietf.org > Subject: Re: [CCAMP] WG Last Call: WSON documents - draft-ietf-ccamp-rwa-info > > Young, > > See below. > > On 1/27/2014 6:46 PM, Leeyoung wrote: > > Hi Lou, > > Here's my comments to your comments. Please see inline for detail. > Enclosed is a working draft that reflects all the changes per your comments. > > Let me know if this is ready to be published. > > Thanks, > > Young > > -----Original Message----- > > From: Lou Berger [mailto:lberger@labn.net] > > Sent: Monday, January 20, 2014 1:53 PM > > To: Leeyoung; CCAMP; draft-ietf-ccamp-rwa-info@tools.ietf.org > > Subject: Re: [CCAMP] WG Last Call: WSON documents - draft-ietf-ccamp-rwa-info > > Young, (all), > > Now that the IPR issues are resolved on the document set, it's time to > get these documents published. > > There are few minor items in this document. > > On 11/7/2013 5:32 PM, Leeyoung wrote: > >> Hi Lou, > >> > >> Here's my response to specific comments to draft-ietf-ccamp-rwa-info. >> > >> Thanks. > >> Young > >> -----Original Message----- > >> From: Lou Berger [mailto:lberger@labn.net] > >> Sent: Tuesday, October 29, 2013 1:26 PM > >> To: CCAMP; draft-ietf-ccamp-rwa-info@tools.ietf.org > >> Subject: Re: [CCAMP] WG Last Call: WSON documents - > draft-ietf-ccamp-rwa-info > >> > >> > > ... > > >> > >> YOUNG>> [Switch] moved to normative reference section. > > A normative reference to a a journal paper, are you sure? I would have > just changed the language to make it informative, but it's your call. > > (Unless the RFC editor chimes in on it...) > > >> > > ... > > YOUNG>> It was a mistake I think that took place while I was shifting > some references around. I will put [Switch] back to informative reference > section. > >> > >> - Section 5: I found it hard to parse the following: > >> As resources are the smallest identifiable unit of > >> processing resource, one can group together resources into blocks if > >> they have similar characteristics relevant to the optical system > >> being modeled, e.g., processing properties, accessibility, etc. > >> Do you perhaps mean? > >> A resource is the smallest identifiable unit of > >> allocation. One can group together resources into blocks if > >> they have similar characteristics relevant to the optical system > >> being modeled, e.g., processing properties, accessibility, etc. > >> > >> YOUNG>> Agreed. Changed. > > I think you have a bad cut and paste. > > s/resource./allocation. > > YOUNG>> Agree. Done. "A resource is the smallest... allocation...." > > >> -Section 5.1: States: " Note that except for <ResourcePoolState> > >> all the other components of <ResourcePool> are relatively static." > >> But the related definitions are: > >> > >> <ResourcePool> ::= <ResourceBlockInfo>... > >> [<ResourceAccessibility>...] [<ResourceWaveConstraints>...] > >> [<RBPoolState>] (section 5) > >> > >> <DynamicNodeInfo> ::= <NodeID> [<ResourcePoolState>] (section >> 7.2) > >> > >> What's the intent here? > >> > >> YOUNG>> See the cleaned text in Section 7.2: > >> Currently the only node information that can be considered dynamic > >> is the resource pool state and can be isolated into a dynamic node > >> information element as follows: > >> > >> <DynamicNodeInfo> ::= <NodeID> [<ResourcePool>] > >> > >> Where > >> > >> <ResourcePool> ::= <ResourceBlockInfo>...[<RBPoolState>] > > sorry, I didn't mean for you to incorporate the <ResourcePool> definition > into the document. this was just for our discussion. I don't think adding > a duplicate/incomplete definition here is the right thing. So I'd drop it > (starting with Where.) > > YOUNG>> OK. "Where..." is dropped. Also changes in Section 5.1: Original: > <RBPoolState> ::=(<ResourceBlockID> <NumResourcesInUse> > <InAvailableWavelengths> <OutAvailableWavelengths>)... > > Changed: <RBPoolState> ::=(<ResourceBlockID> <NumResourcesInUse> > [<InAvailableWavelengths>] [<OutAvailableWavelengths>])* > > > As was the case below, an asterisk isn't valid RBNF, so shouldn't be in > this line. > > Also recall that parentheses implies strict ordering. Perhaps you mean: > <RBPoolState> ::= <ResourceBlockID> <NumResourcesInUse> > [<InAvailableWavelengths>] [<OutAvailableWavelengths>] > [<RBPoolState>] > > YOUNG>> This works for me. Thanks. > > As <InAvailableWavelengths> <OutAvailableWavelengths> are only used in > the cases of shared input or output access to the particular block. > > > > >> > >> > >> - Section 5.2: What is the asterisk "*" all about. > >> > >> YOUNG>> That means whatever within () can be repeated. >> > > I don't recall this syntax definition in BNF/RBNF. Take a look at > http://tools.ietf.org/html/rfc5511#section-2.2.5. > > YOUNG>> Yes, I replaced "*" with "..." (per 2.2.5) which means 'repetition.' > > So you now have: > <ResourceBlockInfo> ::= ([<ResourceSet>] <InputConstraints> > [<ProcessingCapabilities>] <OutputConstraints>)... > > That's fine, but keep in mind that use of parenthesis implies ordering. > Do you mean: > > <ResourceBlockInfo> ::= [<ResourceSet>] <InputConstraints> > [<ProcessingCapabilities>] <OutputConstraints> > [<ResourceBlockInfo>] > > Actually since the use of <ResourceBlockInfo> already indicates repetition > in section 5, no repetition is needed here, which yields > > <ResourceBlockInfo> ::= [<ResourceSet>] <InputConstraints> > [<ProcessingCapabilities>] <OutputConstraints> > > YOUNG>> This works well. In light of the next comment (with a consistent > naming with encode draft, the following is agreed: > <ResourceBlockInfo> ::= <ResourceBlockSet> [<InputConstraints>] > [<ProcessingCapabilities>] [<OutputConstraints>] > > > Also you list [<ResourceSet>] as optional, yet it is mandatory in section > 4.1 of > > http://tools.ietf.org/html/draft-ietf-ccamp-rwa-wson-encode-23 > > YOUNG>> <ResourceSet> is optional. I don't think section 4.1 of > wson-encode-23 treats this as mandatory. Wson-encode-23 document simply > provides encoding details irrespective of whether it is mandatory or > optional. Let me know if you disagree with this. > > So 4.1 of wson-encode-24 you just distributed says: > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | RB Set Field | > : : > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |I|O| Reserved | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Optical Interface Class List(s) (opt) | > : : > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Acceptable Client Signal Type (opt) | > : : > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Input Bit Rate List (opt) | > : : > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Processing Capabilities List (opt) | > : : > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > To me, I'd read this as > > <ResourceBlockInfo> ::= <ResourceBlockSet> > [<InputConstraints>] [<OutputConstraints>] > [<ProcessingCapabilities>] > > Which is correct? Also note that you have ResourceSet in this document and > "RB Set Field" in wson-encode-24. to align this document: > s/<ResourceSet>/<ResourceBlockSet> > > YOUNG>> As discussed previously, <ResourceBlockInfo> ::= <ResourceBlockSet> > [<InputConstraints>] [<ProcessingCapabilities>] [<OutputConstraints>]. > > ... > >> > >> - Section 6.6. I think you have a BNF problem here. The BNF says > restriction parameters are always optional, but your text says that there > are requirements based on <RestrictionTypes>. I think the BNF needs to be > aligned with the text and reflect the requirements. > >> > >> YOUNG>> Made all mandatory element. > > The new text says: > > <PortLabelRestriction> ::= <GeneralPortRestrictions>... > > <MatrixSpecificRestrictions>... > > This now says that a PortLabelRestriction MUST (and always) include > > *both* GeneralPortRestrictions and MatrixSpecificRestrictions. Is this > correct in all cases? > > YOUNG>> No. Actually <PortLabelRestriction> is an optional information. > It will be corrected as follows: > > <PortLabelRestriction> ::= [<GeneralPortRestrictions>...] > [<MatrixSpecificRestrictions>...] > > A few points here: > 1) to get repetition of <PortLabelRestriction> I suggest: > OLD > <LinkInfo> ::= <LinkID> [<AdministrativeGroup>] > [<InterfaceCapDesc>] [<Protection>] [<SRLG>]... > [<TrafficEngineeringMetric>] [<PortLabelRestriction>] > > NEW > <LinkInfo> ::= <LinkID> [<AdministrativeGroup>] > [<InterfaceCapDesc>] [<Protection>] [<SRLG> ...] > [<TrafficEngineeringMetric>] [<PortLabelRestriction> ...] > > YOUNG>> Accepted. > 2) What is unclear is that when <PortLabelRestriction> what it must > contain. looking at 2.2 of wson-encode-24 I see > > > YOUNG>> Actually this is 2.2 of gen-encode-14. > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | MatrixID |RestrictionType| Switching Cap | Encoding | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Additional Restriction Parameters per RestrictionType | > : : > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > which translates to me to be: > <PortLabelRestriction> ::= <MatrixID> <RestrictionType> > <Restriction parameters list> > > <Restriction parameters list> ::= > <Simple label restriction parameters> | > <Channel count restriction parameters> | > <Label range restriction parameters> | > <Simple+channel restriction parameters> | > <Exclusive label restriction parameters> > > <Simple label restriction parameters> ::= <LabelSet> ... > > > <Channel count restriction parameters> ::= <MaxNumChannels> > > > <Label range restriction parameters> ::= > <MaxLabelRange> (<LabelSet> ...) > > > <Simple+channel restriction parameters> ::= > <MaxNumChannels> (<LabelSet> ...) > > <Exclusive label restriction parameters> ::= <LabelSet> ... > > YOUNG>> OK. These are consistent with Gen-Encode-14. All accepted. > > ---------------------------------------------------------------------- > > ------------------------------ > > also: > > <RestrictionParameters> ::= <LabelSet>... <MaxNumChannels> > > <MaxWaveBandWidth> > > So all parameters MUST be included for all RestrictionTypes? I suspect > you mean to say there alternatives based on RestrictionType. > > If correct, syntax is covered in > > http://tools.ietf.org/html/rfc5511#section-2.2.4. > > YOUNG>> No. Indeed these parameters appear only if they match with > Restriction Types. So it should be as follows: > > <RestrictionParameters> ::= (<LabelSet>...) | <MaxNumChannels> | > <MaxLabelRange> | (<LabelSet>... <MaxNumChannels>) | <LinkSet> (Note: this > is arranged to be consistent with > draft-ietf-ccamp-general-constraint-encode-13.txt in the naming and order) > > > Addressed above. > > YOUNG>> OK. > > > In Section 6.6, this is a summary of all encoding changes: > > <PortLabelRestriction> ::= [<GeneralPortRestrictions>...] > [<MatrixSpecificRestrictions>...] > > <GeneralPortRestrictions> ::= <RestrictionType> <RestrictionParameters> > (RestictionType and one of the parameters corresponding to the > RestrictionType must be there) > > <MatrixSpecificRestriction> ::= <MatrixID> <RestrictionType> > <RestrictionParameters> (the same rational apples as above) > > <RestrictionParameters> ::= > > (<LabelSet>...) | <MaxNumChannels> | <MaxLabelRange> | (<LabelSet>... > <MaxNumChannels>) | <LinkSet> > > > > Addressed above. > > YOUNG>> OK. > > > Also the RestrictionParameters object/field naming doesn't match > draft-ietf-ccamp-general-constraint-encode-13.txt, this section should be > updated to match. > > YOUNG>> RestrictionParameters are now matching with > draft-ietf-ccamp-general-constraint-encode-13.txt. > > s/PortSet/LinkSet > > s/MaxWaveWidth/MaxLabelRange > > > I think I sense some fatigue. (on my part too!) > > OLD > LABEL_RANGE: Waveband device with a tunable center frequency and > passband. This constraint is characterized by the MaxLabelRange > parameter which indicates the maximum width of the waveband in terms > of channels. Note that an additional wavelength set can be used to > indicate the overall tuning range. Specific center frequency tuning > information can be obtained from dynamic channel in use information. > It is assumed that both center frequency and bandwidth (Q) tuning > can be done without causing faults in existing signals. > NEW > LABEL_RANGE: Used to indicated a restriction on a range of labels > that can be switched. For example a waveband device with a tunable > center frequency and passband. This constraint is characterized by > the MaxLabelRange parameter which indicates the maximum range of the > labels, e.g., which may represent a waveband in terms of channels. > Note that an additional parameter can be used to > indicate the overall tuning range. Specific center frequency tuning > information can be obtained from dynamic channel in use information. > It is assumed that both center frequency and bandwidth (Q) tuning > can be done without causing faults in existing signals. > > YOUNG>> Accepted with a few grammar/style corrections: indicated -> > indicate; For example -> For example, > > and > OLD > MaxLabelRange is the maximum width of a tunable waveband switching > device. > NEW (from general-constraint-encode) > MaxLabelRange indicates the maximum range of the labels. > > YOUNG>> Accepted. > That's it, thanks,. > Lou > > > ... > > I think this covers all open points on this one. > > Lou > >
- [CCAMP] WG Last Call: WSON documents - rwa-info, … Lou Berger
- Re: [CCAMP] WG Last Call: WSON documents - rwa-in… Margaria, Cyril (Coriant - DE/Munich)
- Re: [CCAMP] WG Last Call: WSON documents - rwa-in… Lou Berger
- Re: [CCAMP] WG Last Call: WSON documents - rwa-in… Leeyoung
- Re: [CCAMP] WG Last Call: WSON documents - rwa-in… Giovanni Martinelli (giomarti)
- Re: [CCAMP] WG Last Call: WSON documents - rwa-in… Giovanni Martinelli (giomarti)
- Re: [CCAMP] WG Last Call: WSON documents - rwa-in… Lou Berger
- Re: [CCAMP] WG Last Call: WSON documents - draft-… Lou Berger
- Re: [CCAMP] WG Last Call: WSON documents - draft-… Lou Berger
- Re: [CCAMP] WG Last Call: WSON documents - draft-… Lou Berger
- Re: [CCAMP] WG Last Call: WSON documents - draft-… Lou Berger
- Re: [CCAMP] WG Last Call: WSON documents - draft-… Lou Berger
- Re: [CCAMP] WG Last Call: WSON documents - draft-… Lou Berger
- Re: [CCAMP] WG Last Call: WSON documents - rwa-in… Leeyoung
- Re: [CCAMP] WG Last Call: WSON documents - draft-… Lou Berger
- Re: [CCAMP] WG Last Call: WSON documents - rwa-in… Lou Berger
- Re: [CCAMP] WG Last Call: WSON documents - rwa-in… Leeyoung
- Re: [CCAMP] WG Last Call: WSON documents - rwa-in… Leeyoung
- Re: [CCAMP] WG Last Call: WSON documents - draft-… Leeyoung
- Re: [CCAMP] WG Last Call: WSON documents - draft-… Leeyoung
- Re: [CCAMP] WG Last Call: WSON documents - draft-… Leeyoung
- Re: [CCAMP] WG Last Call: WSON documents - draft-… Leeyoung
- Re: [CCAMP] WG Last Call: WSON documents - draft-… Lou Berger
- Re: [CCAMP] WG Last Call: WSON documents - draft-… Lou Berger
- Re: [CCAMP] WG Last Call: WSON documents - draft-… Lou Berger
- Re: [CCAMP] WG Last Call: WSON documents - draft-… Leeyoung
- Re: [CCAMP] WG Last Call: WSON documents - draft-… Leeyoung
- Re: [CCAMP] WG Last Call: WSON documents - draft-… Leeyoung
- Re: [CCAMP] WG Last Call: WSON documents - draft-… Lou Berger
- Re: [CCAMP] WG Last Call: WSON documents - draft-… Lou Berger
- Re: [CCAMP] WG Last Call: WSON documents - draft-… Lou Berger
- Re: [CCAMP] WG Last Call: WSON documents - draft-… Leeyoung
- Re: [CCAMP] WG Last Call: WSON documents - draft-… Lou Berger
- Re: [CCAMP] WG Last Call: WSON documents - draft-… Leeyoung
- Re: [CCAMP] WG Last Call: WSON documents - draft-… Lou Berger
- Re: [CCAMP] WG Last Call: WSON documents - draft-… Leeyoung
- Re: [CCAMP] WG Last Call: WSON documents - draft-… Lou Berger
- Re: [CCAMP] WG Last Call: WSON documents - draft-… Lou Berger
- Re: [CCAMP] WG Last Call: WSON documents - draft-… Leeyoung
- Re: [CCAMP] WG Last Call: WSON documents - draft-… Lou Berger
- Re: [CCAMP] WG Last Call: WSON documents - draft-… Giovanni Martinelli (giomarti)
- Re: [CCAMP] WG Last Call: WSON documents - draft-… Giovanni Martinelli (giomarti)
- Re: [CCAMP] WG Last Call: WSON documents - draft-… Giovanni Martinelli (giomarti)
- Re: [CCAMP] WG Last Call: WSON documents - draft-… Lou Berger