From hadi@mojatatu.com Tue Jul 2 05:59:40 2013 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0777321F9D72 for ; Tue, 2 Jul 2013 05:59:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.676 X-Spam-Level: X-Spam-Status: No, score=-102.676 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, 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 iIiQAQv2o5K8 for ; Tue, 2 Jul 2013 05:59:35 -0700 (PDT) Received: from mail-ve0-f173.google.com (mail-ve0-f173.google.com [209.85.128.173]) by ietfa.amsl.com (Postfix) with ESMTP id E9B7F21F9446 for ; Tue, 2 Jul 2013 05:59:07 -0700 (PDT) Received: by mail-ve0-f173.google.com with SMTP id jw11so4765310veb.18 for ; Tue, 02 Jul 2013 05:59:06 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type :x-gm-message-state; bh=rpV8j56Rx0TqdMxOYBEvxllsXxjD7XuHWMst/L279ho=; b=XDxzi/TbnjTVUoiFBT1W94ZsGkp1gUg0clmOlF9c2zLlSxxfGCIy/z+IpdKa5vADH7 3fw/IklsFXFj6/kVmzA5AVGao7EdvVkgEGaNnszT3w8YNoYTLSuNY1i/yjRPZX7Qry1v WoY+5FVPkn5yn7xJm5yJTX+077Y3NvHeONAiGH8VY3bS6f1UmnMxAuMwecVyAg+FUsTX SDqr+mSSREKmKZFKvDGUrBKaFgu919UU82ze9IAq0kB0e8lQtBUgKn//q9Z0Z16YsGgo BUwamI6OUjaSVut9icqe2/lx2xLF6SXj14sT/7VQGobxp3qUDR2gy3B/ydfY56cEE7wc AbAg== X-Received: by 10.221.31.130 with SMTP id sg2mr10865774vcb.86.1372769946224; Tue, 02 Jul 2013 05:59:06 -0700 (PDT) MIME-Version: 1.0 Received: by 10.58.247.197 with HTTP; Tue, 2 Jul 2013 05:58:45 -0700 (PDT) From: Jamal Hadi Salim Date: Tue, 2 Jul 2013 08:58:45 -0400 Message-ID: To: "forces@ietf.org" Content-Type: multipart/alternative; boundary=001a1133a04c00dd2104e086e945 X-Gm-Message-State: ALoCoQnrjxZPTlDnOavdF5b5bKZjq11+NKEMM27tFSSkSZt5B9gQyhEtLiUCjZLGV3vA65xqkRNd Subject: [forces] bitmap representation X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jul 2013 12:59:40 -0000 --001a1133a04c00dd2104e086e945 Content-Type: text/plain; charset=ISO-8859-1 While updating the protocol-update I have developed doubts on bitmaps. I would like to see if it can be removed from mention in the protocol update document. The original intention was for the protocol side to describe how the bitmap should be packed. i.e a bitmap[N] while looks like a byte[N] cannot simply be packed into a TLV since the L is a byte/octet counter. I am sure there are other reasons we said this needs protocol mention, but i cant recall. It would simplify the protocol-update document if this becomes part of the model domain. If we were to define the bitmap as: {uint32 length, data} then we could pack upto 2^32 -1 bits in a TLV/ILV where the L would still count then number of bytes + any padding but the encoded length will count the number of bits. Thoughts? cheers, jamal --001a1133a04c00dd2104e086e945 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

While updating the protocol-update I have d= eveloped doubts on
bitmaps. I would like to see if it can be removed fr= om mention in the protocol
update document.

The original intention was for the protocol side to describe how the b= itmap
should be packed. i.e a bitmap[N] while looks like a byte[N= ] cannot simply
be packed into a TLV since the L is a byte/octet = counter.
I am sure there are other reasons we said this needs protocol mention,=
but i cant recall.

It would simplify th= e protocol-update document if this becomes part of the
model doma= in. If we were to define the bitmap as:
{uint32 length, data}
then we could pack upto 2^32 -1 bits i= n a TLV/ILV where the L would still
count then number of bytes + = any padding but the encoded length will count
the number of bits.=

Thoughts?

cheers,
ja= mal


--001a1133a04c00dd2104e086e945-- From ehalep@gmail.com Tue Jul 2 07:53:32 2013 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D405621F9F83 for ; Tue, 2 Jul 2013 07:53:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 LAlauNyjq2zZ for ; Tue, 2 Jul 2013 07:53:28 -0700 (PDT) Received: from mail-ea0-x229.google.com (mail-ea0-x229.google.com [IPv6:2a00:1450:4013:c01::229]) by ietfa.amsl.com (Postfix) with ESMTP id 3AC4421F9EB6 for ; Tue, 2 Jul 2013 07:53:26 -0700 (PDT) Received: by mail-ea0-f169.google.com with SMTP id h15so2835815eak.0 for ; Tue, 02 Jul 2013 07:53:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:x-mailer:thread-index:content-language; bh=a2JxtAmpsPzVmHhegxSNzd4IFwRC6fXf3PRF1v2QQlw=; b=i5jNS5eBhN0YSwNii/T9zYJlivrbv6kKVYurMYJYBhJ514w5Ec/d2JuHlaHLkMCClX s7K3YmcPCIZWlkbqZZk81zLIxYX1R75TaRX5lla03w3S5Ms7uVU/KHr4fsWwTbB/jPJM 1j//tJDSrkU6YOZFVIr1YBCFhfoXWFO+boYKz2Mh4CubGAFM+3FEVUjm49dJ0/wz7VTm IedDS/Ey7Fxrz0dUoqpJn7o6iltJmHyJDvbBBaD/NGNGY+WIxLwJi2enl76fLYPhGU4J im/QxLir2wNiF2pj3WWKQ3zW0HMY8V/P8cWwjrOpExm/nyEuSko9YrkhfCxuZ2Kus5uQ yeoA== X-Received: by 10.14.246.197 with SMTP id q45mr26743885eer.15.1372776795555; Tue, 02 Jul 2013 07:53:15 -0700 (PDT) Received: from EhalepXPS (ppp141237075082.access.hol.gr. [141.237.75.82]) by mx.google.com with ESMTPSA id b3sm37043707eev.10.2013.07.02.07.53.14 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Tue, 02 Jul 2013 07:53:15 -0700 (PDT) From: "Haleplidis Evangelos" To: References: In-Reply-To: Date: Tue, 2 Jul 2013 17:53:11 +0300 Message-ID: <004b01ce7733$e09bafe0$a1d30fa0$@com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_004C_01CE774D.05E8E7E0" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac53J2+YhTcUjC7ZQRa3cku63veO6AAAZUZA Content-Language: el Subject: Re: [forces] bitmap representation X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jul 2013 14:53:32 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_004C_01CE774D.05E8E7E0 Content-Type: text/plain; charset="iso-8859-7" Content-Transfer-Encoding: quoted-printable Greetings Jamal, =20 Please see inline. =20 Regards, Evangelos Haleplidis. =20 The original intention was for the protocol side to describe how the = bitmap should be packed. i.e a bitmap[N] while looks like a byte[N] cannot = simply be packed into a TLV since the L is a byte/octet counter. =20 [=C5=C7] Yes, this won't work and imho defining a specific TLV for = bitmaps is not a good approach (as has been described currently in the model = extension document) =20 I am sure there are other reasons we said this needs protocol mention, but i cant recall. =20 [=C5=C7] The main reason we said this needs protocol mention, if I = remember correctly, is that how bitmaps are packed should be defined in a = protocol document instead of a model one. =20 It would simplify the protocol-update document if this becomes part of = the model domain. If we were to define the bitmap as: {uint32 length, data} then we could pack upto 2^32 -1 bits in a TLV/ILV where the L would = still count then number of bytes + any padding but the encoded length will = count the number of bits. =20 [=C5=C7] While I agree that this would alleviate the need for defining a = new TLV, however is encoding protocol semantics into the model a good = practice? =20 Thoughts? =20 [=C5=C7] I think that we can safely assume that the LFB knows what is = coming for it as in the case of arrays where it expects an index for a fulldata in front of each array. Can we use the same concept and word it like "every bitmap datatype is 32-bit aligned (with padding) and is prefixed with a 32-bit length field that will define the number of used bits"?=20 Essentially it's exactly what you described above but encoded in the protocol instead of the model. =20 Additionally where would the following text be suitable best, the model = or the protocol? "The ordering of the bits in a ForCES message MUST be in the order that = are defined in the xml library."=20 =20 cheers, jamal =20 =20 ------=_NextPart_000_004C_01CE774D.05E8E7E0 Content-Type: text/html; charset="iso-8859-7" Content-Transfer-Encoding: quoted-printable

Greetings Jamal,

 

Please see inline.

 

Regards,

Evangelos Haleplidis.

 

The original = intention was for the protocol side to describe how the = bitmap

should be = packed. i.e a bitmap[N] while looks like a byte[N] cannot = simply

be packed into a = TLV since the L is a byte/octet counter.

 

[=C5=C7] Yes, this won’t work and imho defining a specific TLV = for bitmaps is not a good approach (as has been described currently in = the model extension document)

 

I am sure = there are other reasons we said this needs protocol = mention,

but i cant = recall.

 

[=C5=C7] The main reason we said this needs protocol mention, if I = remember correctly, is that how bitmaps are packed should be defined in = a protocol document instead of a model = one.

 

It would simplify the = protocol-update document if this becomes part of = the

model domain. = If we were to define the bitmap as:

{uint32 length, data}

then we could pack upto 2^32 -1 bits in a TLV/ILV = where the L would still

count then number of bytes + any padding but the = encoded length will count

the number of bits.

 

[=C5=C7] While I agree that this would alleviate the need for = defining a new TLV, however is encoding protocol semantics into the = model a good practice?

 

Thoughts?

 

[=C5=C7] I think that we can safely assume that the LFB knows what is = coming for it as in the case of arrays where it expects an index for a = fulldata in front of each array. Can we use the same concept and word it = like “every bitmap datatype is 32-bit aligned (with padding) and = is prefixed with a 32-bit length field that will define the number of = used bits”?

Essentially it’s exactly what you described above but encoded = in the protocol instead of the model.

 

Additionally where would the following text be suitable best, the = model or the protocol?

“The ordering of the bits in a ForCES message MUST be in the = order that are defined in the xml library.” =

 

cheers,

jamal

 

 

------=_NextPart_000_004C_01CE774D.05E8E7E0-- From joel@stevecrocker.com Tue Jul 2 08:00:15 2013 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50D2E21F9CCC for ; Tue, 2 Jul 2013 08:00:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.469 X-Spam-Level: X-Spam-Status: No, score=-1.469 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DSL=1.129, UNPARSEABLE_RELAY=0.001] 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 PZxQMW0PmCow for ; Tue, 2 Jul 2013 08:00:11 -0700 (PDT) Received: from execdsl.com (remote.shinkuro.com [50.56.68.178]) by ietfa.amsl.com (Postfix) with ESMTP id 2260D21F8BD5 for ; Tue, 2 Jul 2013 08:00:11 -0700 (PDT) Received: from dummy.name; Tue, 02 Jul 2013 15:00:10 +0000 Message-ID: <51D2EAF7.6060104@stevecrocker.com> Date: Tue, 02 Jul 2013 11:00:07 -0400 From: Joel User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Haleplidis Evangelos References: <004b01ce7733$e09bafe0$a1d30fa0$@com> In-Reply-To: <004b01ce7733$e09bafe0$a1d30fa0$@com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: forces@ietf.org Subject: Re: [forces] bitmap representation X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jul 2013 15:00:15 -0000 Structurally, it really bothers me for the model to discuss bitmaps in terms of 32 bit blocks of bits. A bitmap is a sequence of bits. Encoding is a separate matter, and not part of the model. Yours, joel On 7/2/2013 10:53 AM, Haleplidis Evangelos wrote: > Greetings Jamal, > > Please see inline. > > Regards, > > Evangelos Haleplidis. > > The original intention was for the protocol side to describe how the bitmap > > should be packed. i.e a bitmap[N] while looks like a byte[N] cannot simply > > be packed into a TLV since the L is a byte/octet counter. > > *//* > > */[ΕΗ] Yes, this won’t work and imho defining a specific TLV for bitmaps > is not a good approach (as has been described currently in the model > extension document)/* > > I am sure there are other reasons we said this needs protocol mention, > > but i cant recall. > > *//* > > */[ΕΗ] The main reason we said this needs protocol mention, if I > remember correctly, is that how bitmaps are packed should be defined in > a protocol document instead of a model one./* > > It would simplify the protocol-update document if this becomes part of the > > model domain. If we were to define the bitmap as: > > {uint32 length, data} > > then we could pack upto 2^32 -1 bits in a TLV/ILV where the L would still > > count then number of bytes + any padding but the encoded length will count > > the number of bits. > > */[ΕΗ] While I agree that this would alleviate the need for defining a > new TLV, however is encoding protocol semantics into the model a good > practice?/* > > Thoughts? > > *//* > > */[ΕΗ] I think that we can safely assume that the LFB knows what is > coming for it as in the case of arrays where it expects an index for a > fulldata in front of each array. Can we use the same concept and word it > like “every bitmap datatype is 32-bit aligned (with padding) and is > prefixed with a 32-bit length field that will define the number of used > bits”? /* > > */Essentially it’s exactly what you described above but encoded in the > protocol instead of the model./* > > *//* > > */Additionally where would the following text be suitable best, the > model or the protocol?/* > > */“The ordering of the bits in a ForCES message MUST be in the order > that are defined in the xml library.” /* > > *//* > > cheers, > > jamal > > > > _______________________________________________ > forces mailing list > forces@ietf.org > https://www.ietf.org/mailman/listinfo/forces > From hadi@mojatatu.com Tue Jul 2 09:17:28 2013 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D200521F9F3A for ; Tue, 2 Jul 2013 09:17:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.776 X-Spam-Level: X-Spam-Status: No, score=-102.776 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, 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 9pxF7bmJTPar for ; Tue, 2 Jul 2013 09:17:23 -0700 (PDT) Received: from mail-ve0-f176.google.com (mail-ve0-f176.google.com [209.85.128.176]) by ietfa.amsl.com (Postfix) with ESMTP id 7D63821F9E5A for ; Tue, 2 Jul 2013 09:17:23 -0700 (PDT) Received: by mail-ve0-f176.google.com with SMTP id c13so5070086vea.35 for ; Tue, 02 Jul 2013 09:17:22 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=LcHkoHYZKo6LoxR6uLSv+RgiTeYqHjDtGhWveLQA03g=; b=XdhqV42U/sZz/z0zn9FW2y49Ti+6KDTLvZr9/GdIN0vg+QyCgzQDCx3IA2uCrODlkw bmfk88v40lFKGnYuCTvfmJRoEF2/TZWdtrDHqPDXJOumlgLzR/mlh1d8l3OXQ2Iplz/3 Mm06RWF+WsX+aLcqwWymQUuUzskxsZj1fA+TSehfxgWRm3wCeomF7uBETNNW7+LyI8tj wwoZeXgrcKqHpXsW5qI3ufDGBrl0EKec6BQ5PTWPCv5YA/gyMSqh/yDxzGtr7gcDOHlR P5bvVvses0qfYqOkxxLv6iTETDbrS2AEg3YHizgSz2dHljKc6F6gyJkaxlEroUp9GMAQ koCw== X-Received: by 10.220.185.4 with SMTP id cm4mr11560573vcb.96.1372781842640; Tue, 02 Jul 2013 09:17:22 -0700 (PDT) MIME-Version: 1.0 Received: by 10.58.247.197 with HTTP; Tue, 2 Jul 2013 09:17:02 -0700 (PDT) In-Reply-To: <004b01ce7733$e09bafe0$a1d30fa0$@com> References: <004b01ce7733$e09bafe0$a1d30fa0$@com> From: Jamal Hadi Salim Date: Tue, 2 Jul 2013 12:17:02 -0400 Message-ID: To: Haleplidis Evangelos Content-Type: multipart/alternative; boundary=001a11c2ddd215c0f304e089aebe X-Gm-Message-State: ALoCoQmoCspnObKm0YXa4OybW40uUsHOTpQZ3HlbNWETqC+1JfRIByv6f5241ZtNdPLbctdwwlxR Cc: "forces@ietf.org" Subject: Re: [forces] bitmap representation X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jul 2013 16:17:29 -0000 --001a11c2ddd215c0f304e089aebe Content-Type: text/plain; charset=ISO-8859-7 Content-Transfer-Encoding: quoted-printable Greetings Evangelos, On Tue, Jul 2, 2013 at 10:53 AM, Haleplidis Evangelos wro= te: > > ** > > * * > > *[=C5=C7] Yes, this won't work and imho defining a specific TLV for bitma= ps > is not a good approach (as has been described currently in the model > extension document)* > > ** > Not a specific TLV or ILV, rather a way to further refine the description of the encode a datatype. We have an example of such "refinenemt" in the protocol in the form of a PATH-DATA TLV which is {flags, idcount, idlist, data} The tuple {flags, idcount, idlist} is always present. It describes the content that is encoded which could be a KEY or in the new case TABLE range If both sides know that we have bitmap on path a/b then both sides should be able to encode/decode such encapsulation. ** > > I am sure there are other reasons we said this needs protocol mention,***= * > > but i cant recall.**** > > * * > > *[=C5=C7] The main reason we said this needs protocol mention, if I remem= ber > correctly, is that how bitmaps are packed should be defined in a protocol > document instead of a model one.* > The question is: why? > *[=C5=C7] While I agree that this would alleviate the need for defining a= new > TLV, however is encoding protocol semantics into the model a good practic= e? > * > > ** > I am still not seeing this being a protocol semantic. > *[=C5=C7] I think that we can safely assume that the LFB knows what is co= ming > for it as in the case of arrays where it expects an index for a fulldata = in > front of each array. Can we use the same concept and word it like "every > bitmap datatype is 32-bit aligned (with padding) and is prefixed with a > 32-bit length field that will define the number of used bits"? * > > *Essentially it's exactly what you described above but encoded in the > protocol instead of the model.* > > ** > So at least we have an agreement on the encoding. If i have a complex type like a struct - I dont need to go to the protocol and describe it. What i am suggesting is define this as if it is a struct and then we dont need to say anything at the protocol level. > * * > > *Additionally where would the following text be suitable best, the model > or the protocol?* > > *"The ordering of the bits in a ForCES message MUST be in the order that > are defined in the xml library." * > > ** > That is another thing we need to address. Network order is big endian - and we've always said things go out in network order - but i am not sure how well this applies to arbitrary sized bits. cheers, jamal --001a11c2ddd215c0f304e089aebe Content-Type: text/html; charset=ISO-8859-7 Content-Transfer-Encoding: quoted-printable
Greetings Evangelos,

On Tue, Jul 2, 2013 at 10:53 AM, Haleplidis Eva= ngelos <ehalep@gmail.com> wrote:


 

 



N= ot a specific TLV or ILV, rather a way to further refine the description of= the
encode a datatype.
We have an example of such "refinene= mt" in the protocol in the form of a 
PATH-DATA TLV whi= ch is {flags, idcount, idlist, data}
The tuple {flags, idcount, i= dlist} is always present. It describes the content
that is encoded which could be a KEY or in the new case TABLE range
If both sides know that we have bitmap on path a/b then both sides<= /div>
should be able to encode/decode such encapsulation.

 = ;

I am= sure there are other reasons we said this needs protocol mention,

but i cant recall.

 

[=C5= =C7] The main reason we said this needs protocol mention, if I remember cor= rectly, is that how bitmaps are packed should be defined in a protocol docu= ment instead of a model one.



The quest= ion is: why?
 

[=C5=C7] While I agree that this would alleviate the need for defin= ing a new TLV, however is encoding protocol semantics into the model a good= practice?



I= am still not seeing this being a protocol semantic.
 

[=C5=C7] I think that we can safely assume that the LFB knows what is comi= ng for it as in the case of arrays where it expects an index for a fulldata= in front of each array. Can we use the same concept and word it like &ldqu= o;every bitmap datatype is 32-bit aligned (with padding) and is prefixed wi= th a 32-bit length field that will define the number of used bits”? <= u>

Esse= ntially it’s exactly what you described above but encoded in the prot= ocol instead of the model.

<= /u>


So at least we have an agreement on the encoding. 
If i have a complex type like a struct - I dont need to go to the protoco= l and describe it. What i am suggesting is define
this as if it i= s a struct and then we dont need to say anything at the protocol level.

 

 

Additionally where would the following text be= suitable best, the model or the protocol?

&ldq= uo;The ordering of the bits in a ForCES message MUST be in the order that a= re defined in the xml library.”

<= /u>


That is another thing we need to address.
Network orde= r is big endian - and we've always said things go out in network order = - but i am not sure how
well this applies to arbitrary sized bits= .

cheers,
jamal


--001a11c2ddd215c0f304e089aebe-- From joel@stevecrocker.com Tue Jul 2 09:22:30 2013 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A60411E80C5 for ; Tue, 2 Jul 2013 09:22:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.469 X-Spam-Level: X-Spam-Status: No, score=-1.469 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DSL=1.129, UNPARSEABLE_RELAY=0.001] 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 j6mzBV6bfDHM for ; Tue, 2 Jul 2013 09:22:25 -0700 (PDT) Received: from execdsl.com (remote.shinkuro.com [50.56.68.178]) by ietfa.amsl.com (Postfix) with ESMTP id EE61B21F9E21 for ; Tue, 2 Jul 2013 09:22:24 -0700 (PDT) Received: from dummy.name; Tue, 02 Jul 2013 16:22:24 +0000 Message-ID: <51D2FE3C.1060905@stevecrocker.com> Date: Tue, 02 Jul 2013 12:22:20 -0400 From: Joel User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Jamal Hadi Salim References: <004b01ce7733$e09bafe0$a1d30fa0$@com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: "forces@ietf.org" Subject: Re: [forces] bitmap representation X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jul 2013 16:22:30 -0000 To answer your "why" question, from my perspective one of the key separations between model and protocol is that the encoding of bits on the wire is a protocol task. Providing enough information that bits can be encoded is the models task. Yours, Joel On 7/2/2013 12:17 PM, Jamal Hadi Salim wrote: > __ > > I am sure there are other reasons we said this needs protocol > mention,____ > > but i cant recall.____ > > */__ __/* > > */[ΕΗ] The main reason we said this needs protocol mention, if I > remember correctly, is that how bitmaps are packed should be defined > in a protocol document instead of a model one./* > > > > The question is: why? From hadi@mojatatu.com Tue Jul 2 09:23:08 2013 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B62F221F9F7E for ; Tue, 2 Jul 2013 09:23:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.826 X-Spam-Level: X-Spam-Status: No, score=-102.826 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, 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 bPgN-5eYWDA6 for ; Tue, 2 Jul 2013 09:22:57 -0700 (PDT) Received: from mail-ve0-f174.google.com (mail-ve0-f174.google.com [209.85.128.174]) by ietfa.amsl.com (Postfix) with ESMTP id 1C3C411E80E0 for ; Tue, 2 Jul 2013 09:22:57 -0700 (PDT) Received: by mail-ve0-f174.google.com with SMTP id oz10so4972319veb.5 for ; Tue, 02 Jul 2013 09:22:56 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=hs+9++epSijtXjukeWXxYTqIhwrZ9RnLZqUuu4dAffo=; b=eO2nXHfOZaSK9gl+VjBHDYm64wFpNxcV5BO4vGo+Y7sG7DrbMYmJvPmnmbWIiq3E0W glPnXrb1oEuvH41ZMFtV5LxpMKFIyi3q6cnAFW7EiaQf1ewOGSefJEDA4jfKi1UArSsz 6GH5H+H2aAUmrWCrOOJFP1t1BsY5jYR1nYjyJXV9H6EsiaSxoBsUuQgDUznpWOYjcZb6 XFf+K1ymi4BasJGiH8kSN20AV4MN4ZX9c4UJWwVQaInwDLc/er1bp5HUGgbxGZ1knqc5 wxI1XWdxpmy9j2rJNrJgSS3KPlVDod2jwcOhaidFuUAn9uUTxBJpaK1NqAZSjqhQ43ES 1f9A== X-Received: by 10.52.65.111 with SMTP id w15mr9349073vds.73.1372782176538; Tue, 02 Jul 2013 09:22:56 -0700 (PDT) MIME-Version: 1.0 Received: by 10.58.247.197 with HTTP; Tue, 2 Jul 2013 09:22:36 -0700 (PDT) In-Reply-To: <51D2EAF7.6060104@stevecrocker.com> References: <004b01ce7733$e09bafe0$a1d30fa0$@com> <51D2EAF7.6060104@stevecrocker.com> From: Jamal Hadi Salim Date: Tue, 2 Jul 2013 12:22:36 -0400 Message-ID: To: Joel Content-Type: multipart/alternative; boundary=20cf307f3b44fcabc804e089c1fc X-Gm-Message-State: ALoCoQmmd0PwELza/DbkescM7ZeCAMX6jCrfia0Ya6uA0CNYVNNzfGF/CJRz36xd1w4qXQhWW961 Cc: "forces@ietf.org" Subject: Re: [forces] bitmap representation X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jul 2013 16:23:08 -0000 --20cf307f3b44fcabc804e089c1fc Content-Type: text/plain; charset=ISO-8859-1 On Tue, Jul 2, 2013 at 11:00 AM, Joel wrote: > Structurally, it really bothers me for the model to discuss bitmaps in > terms of 32 bit blocks of bits. A bitmap is a sequence of bits. Encoding > is a separate matter, and not part of the model. I am suggesting that this is a model new type. It is a complex struct with a length followed by a series of bits. The 32 bit length is just to describe how many bits exist in the bitmap. So we have: I/TLV, L = length in bytes of whats carried including padding V = length i.e count of bits being carried followed by packed bits. cheers, jamal --20cf307f3b44fcabc804e089c1fc Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Tue, Jul 2, 2013 at 11:0= 0 AM, Joel <joel@stevecrocker.com> wrote:
Structurally, it really bothers me for the m= odel to discuss bitmaps in terms of 32 bit blocks of bits. =A0A bitmap is a= sequence of bits. Encoding is a separate matter, and not part of the model= .

I am suggesting that this is a model new type. It is a = complex struct with a length followed
by a series of bits. The 32= bit length is just to describe how many bits exist in the bitmap.
So we have:
=A0 =A0I/TLV,=A0
=A0 =A0 =A0 =A0 =A0L = =3D length in bytes of whats carried including padding
=A0 =A0 = =A0 =A0 =A0V =3D=A0
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0length i.e cou= nt of bits being carried followed by packed bits.

cheers,
jamal
=A0 =A0 =A0 =A0 =A0= =A0
=A0 =A0 =A0
--20cf307f3b44fcabc804e089c1fc-- From hadi@mojatatu.com Tue Jul 2 09:23:56 2013 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9AD1821F9E21 for ; Tue, 2 Jul 2013 09:23:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.856 X-Spam-Level: X-Spam-Status: No, score=-102.856 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, 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 q7Dvrlj5eulU for ; Tue, 2 Jul 2013 09:23:51 -0700 (PDT) Received: from mail-vc0-f178.google.com (mail-vc0-f178.google.com [209.85.220.178]) by ietfa.amsl.com (Postfix) with ESMTP id 0B9D411E80E1 for ; Tue, 2 Jul 2013 09:23:50 -0700 (PDT) Received: by mail-vc0-f178.google.com with SMTP id m17so2910563vca.23 for ; Tue, 02 Jul 2013 09:23:50 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=cx6RCZeJ1YQBi65/9UAdjHFiRDG4MEfqvhu9MMV75BE=; b=AZyMiMbWnH5tDhzba0ovi4p+EJqmn8KRhr1oArnG0YtRjJ6XXTUmLw9I74CykcnVtf NN/FCCo1XyTUhrqf3r7K0hMS5TfchB7k+RYPFjV75waKLVC8Zo0e5BlzYpJBijgI7lOB lhGvmC1YsRgGG8itKvsizQTpavQACeLZofzI96fwu/SpL+yS/nAOyfry23y7Sn+iAlSD 3K7lEDhprqwHtikYehBL0A340CQlURp8RQSkES0uDVzlRgxY9Lim4X1PkzCS8JpbYn3k Gh1cAjwh7AQpE+RhpYmqcRHqeJlEPlTi7KraVqyHII4w96+wWVD5pNZ2WE1Cu+hOsJZu Q7xg== X-Received: by 10.220.42.147 with SMTP id s19mr11555161vce.46.1372782230461; Tue, 02 Jul 2013 09:23:50 -0700 (PDT) MIME-Version: 1.0 Received: by 10.58.247.197 with HTTP; Tue, 2 Jul 2013 09:23:30 -0700 (PDT) In-Reply-To: <51D2FE3C.1060905@stevecrocker.com> References: <004b01ce7733$e09bafe0$a1d30fa0$@com> <51D2FE3C.1060905@stevecrocker.com> From: Jamal Hadi Salim Date: Tue, 2 Jul 2013 12:23:30 -0400 Message-ID: To: Joel Content-Type: multipart/alternative; boundary=047d7b3a8d0c3377fb04e089c514 X-Gm-Message-State: ALoCoQmibsWyt/n7FHx33EGpYfrdoTNruljO0ZpZWLluN5jpzR7upmPCGE7eKVQqAkJpPd29KieJ Cc: "forces@ietf.org" Subject: Re: [forces] bitmap representation X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jul 2013 16:23:56 -0000 --047d7b3a8d0c3377fb04e089c514 Content-Type: text/plain; charset=ISO-8859-7 Content-Transfer-Encoding: quoted-printable Refer to my other email. If i consider the bitmap entity as a complex type, the protocol is agnostic to it. cheers, jamal On Tue, Jul 2, 2013 at 12:22 PM, Joel wrote: > To answer your "why" question, from my perspective one of the key > separations between model and protocol is that the encoding of bits on th= e > wire is a protocol task. Providing enough information that bits can be > encoded is the models task. > > Yours, > Joel > > On 7/2/2013 12:17 PM, Jamal Hadi Salim wrote: > >> __ >> >> >> I am sure there are other reasons we said this needs protocol >> mention,____ >> >> but i cant recall.____ >> >> */__ __/* >> >> */[=C5=C7] The main reason we said this needs protocol mention, if I >> >> remember correctly, is that how bitmaps are packed should be defined >> in a protocol document instead of a model one./* >> >> >> >> The question is: why? >> > --047d7b3a8d0c3377fb04e089c514 Content-Type: text/html; charset=ISO-8859-7 Content-Transfer-Encoding: quoted-printable
Refer to my other email.
If i consider the bitmap enti= ty as a complex type, the protocol is agnostic to it.

<= div>cheers,
jamal


<= div class=3D"gmail_quote"> On Tue, Jul 2, 2013 at 12:22 PM, Joel <joel@stevecrocker.com> wrote:
To answer your "why" question, from my perspective one of the key= separations between model and protocol is that the encoding of bits on the= wire is a protocol task. =A0Providing enough information that bits can be = encoded is the models task.

Yours,
Joel

On 7/2/2013 12:17 PM, Jamal Hadi Salim wrote:
=A0 =A0 __


=A0 =A0 I am sure there are other reasons we said this needs protocol
=A0 =A0 mention,____

=A0 =A0 but i cant recall.____

=A0 =A0 */__ __/*

=A0 =A0 */[=C5=C7] The main reason we said this needs protocol mention, if = I

=A0 =A0 remember correctly, is that how bitmaps are packed should be define= d
=A0 =A0 in a protocol document instead of a model one./*



The question is: why?

--047d7b3a8d0c3377fb04e089c514-- From joel@stevecrocker.com Tue Jul 2 09:30:25 2013 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42C4D21F9C4C for ; Tue, 2 Jul 2013 09:30:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.469 X-Spam-Level: X-Spam-Status: No, score=-1.469 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DSL=1.129, UNPARSEABLE_RELAY=0.001] 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 xB2w5sEHSDXs for ; Tue, 2 Jul 2013 09:30:20 -0700 (PDT) Received: from execdsl.com (remote.shinkuro.com [50.56.68.178]) by ietfa.amsl.com (Postfix) with ESMTP id 3584421F9978 for ; Tue, 2 Jul 2013 09:30:20 -0700 (PDT) Received: from dummy.name; Tue, 02 Jul 2013 16:30:19 +0000 Message-ID: <51D30017.5030909@stevecrocker.com> Date: Tue, 02 Jul 2013 12:30:15 -0400 From: Joel User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Jamal Hadi Salim References: <004b01ce7733$e09bafe0$a1d30fa0$@com> <51D2FE3C.1060905@stevecrocker.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-7; format=flowed Content-Transfer-Encoding: 8bit Cc: "forces@ietf.org" Subject: Re: [forces] bitmap representation X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jul 2013 16:30:25 -0000 It s true that you can, within the current protocol, define a structure consisting o a bit count and an array of 32 bit unsigned values. And you can use that for a bitmap. But from a modeling perspective you are modeling a packing rather than modeling a bitmap. If you want to argue that we do not need to model a bitmap of named bits, that's fine. It is a discussion we should have. Yours, Joel On 7/2/2013 12:23 PM, Jamal Hadi Salim wrote: > Refer to my other email. > If i consider the bitmap entity as a complex type, the protocol is > agnostic to it. > > cheers, > jamal > > > On Tue, Jul 2, 2013 at 12:22 PM, Joel > wrote: > > To answer your "why" question, from my perspective one of the key > separations between model and protocol is that the encoding of bits > on the wire is a protocol task. Providing enough information that > bits can be encoded is the models task. > > Yours, > Joel > > On 7/2/2013 12:17 PM, Jamal Hadi Salim wrote: > > __ > > > I am sure there are other reasons we said this needs protocol > mention,____ > > but i cant recall.____ > > */__ __/* > > */[] The main reason we said this needs protocol mention, > if I > > remember correctly, is that how bitmaps are packed should > be defined > in a protocol document instead of a model one./* > > > > The question is: why? > > From hadi@mojatatu.com Tue Jul 2 10:00:53 2013 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41F0711E80E1 for ; Tue, 2 Jul 2013 10:00:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.876 X-Spam-Level: X-Spam-Status: No, score=-102.876 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, 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 FUd3vY69B8zZ for ; Tue, 2 Jul 2013 10:00:44 -0700 (PDT) Received: from mail-ve0-f182.google.com (mail-ve0-f182.google.com [209.85.128.182]) by ietfa.amsl.com (Postfix) with ESMTP id 46A6A11E80D1 for ; Tue, 2 Jul 2013 10:00:44 -0700 (PDT) Received: by mail-ve0-f182.google.com with SMTP id ox1so5085321veb.27 for ; Tue, 02 Jul 2013 10:00:43 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=T4qc1K59BuYNgUPyBFUjGwLjIH7Ac2HV9tVifCtqpNA=; b=At7eofUy3CLsuJPsoun/Z8b3Hxo2w8HkjpmUpcG9omd0oc6H+09PwIlPjKOPLF3HJH RtAkqzaH+sj72LHMuWtKWgsk+v4IhVv+mC6Tp8Q5h8Z5KGgRxDcJjPfRkecaakrZq/uH WJKCxes76KCGx05ToRF8zDd9gb9ehQnOIxvNG3vWpUtEOovJGShK04bvYJrBs+8Zgmsf 10dC1Ut5AASLvWLU6UgYewXXNhx0odfl2CzFu4pbPxyy2aFKcUJzWNE3pUaJ5eiWVIta KX1ptsLLK9jI5v1S/6mlEXxLyXlRr5jV1Yj2o4uitnY4NzZfKtAaluSgzYfAbGrisX4N O+Tw== X-Received: by 10.52.177.6 with SMTP id cm6mr9833139vdc.0.1372784443705; Tue, 02 Jul 2013 10:00:43 -0700 (PDT) MIME-Version: 1.0 Received: by 10.58.247.197 with HTTP; Tue, 2 Jul 2013 10:00:22 -0700 (PDT) In-Reply-To: <51D30017.5030909@stevecrocker.com> References: <004b01ce7733$e09bafe0$a1d30fa0$@com> <51D2FE3C.1060905@stevecrocker.com> <51D30017.5030909@stevecrocker.com> From: Jamal Hadi Salim Date: Tue, 2 Jul 2013 13:00:22 -0400 Message-ID: To: Joel Content-Type: multipart/alternative; boundary=20cf3071cc1a1edfec04e08a4907 X-Gm-Message-State: ALoCoQkROXOHVx7ccmqijfNkcSdJCFXLAA9t07qkm++ZdYiQldkgPXGoZeR+eFKNwD9RFTiXDQIV Cc: "forces@ietf.org" Subject: Re: [forces] bitmap representation X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jul 2013 17:00:53 -0000 --20cf3071cc1a1edfec04e08a4907 Content-Type: text/plain; charset=ISO-8859-7 Content-Transfer-Encoding: quoted-printable Ok, so let state my case slightly differently. If i wanted to defined a bitmap as a complex structure which constitutes a bit-length followed by the bit-content, I should be able to do that. I dont need to change anything in the protocol to accomodate that. I could choose to transport such a type as an ILV or TLV. The sender and receiver both understand how to de/encode such a complex type. If we are on agreement on the above, then: Given the model defines the base types, i am asking that this complex struct be made part of the defined types in the model extension draft. There may some other ways to express the bitmap in some complex struct - but what i am not seeing is the special treatment that a bit map should get from the protocol that no other complex struct would need. cheers, jamal On Tue, Jul 2, 2013 at 12:30 PM, Joel wrote: > It s true that you can, within the current protocol, define a structure > consisting o a bit count and an array of 32 bit unsigned values. And you > can use that for a bitmap. > > But from a modeling perspective you are modeling a packing rather than > modeling a bitmap. If you want to argue that we do not need to model a > bitmap of named bits, that's fine. It is a discussion we should have. > > Yours, > Joel > > > On 7/2/2013 12:23 PM, Jamal Hadi Salim wrote: > >> Refer to my other email. >> If i consider the bitmap entity as a complex type, the protocol is >> agnostic to it. >> >> cheers, >> jamal >> >> >> On Tue, Jul 2, 2013 at 12:22 PM, Joel > **> wrote: >> >> To answer your "why" question, from my perspective one of the key >> separations between model and protocol is that the encoding of bits >> on the wire is a protocol task. Providing enough information that >> bits can be encoded is the models task. >> >> Yours, >> Joel >> >> On 7/2/2013 12:17 PM, Jamal Hadi Salim wrote: >> >> __ >> >> >> I am sure there are other reasons we said this needs protoc= ol >> mention,____ >> >> but i cant recall.____ >> >> */__ __/* >> >> */[=C5=C7] The main reason we said this needs protocol ment= ion, >> if I >> >> remember correctly, is that how bitmaps are packed should >> be defined >> in a protocol document instead of a model one./* >> >> >> >> The question is: why? >> >> >> --20cf3071cc1a1edfec04e08a4907 Content-Type: text/html; charset=ISO-8859-7 Content-Transfer-Encoding: quoted-printable

Ok, so let state my case slightly different= ly.
If i wanted to defined a bitmap as a complex structure which consti= tutes a bit-length followed by=A0
the bit-content, I should be ab= le to do that. I dont need to change anything in the protocol to
accomodate that. I could choose to transport such a type as an ILV or = TLV.
The sender and receiver both understand how to de/encode suc= h a complex type.

If we are on agreement on the ab= ove, then:
Given the model defines the base types, i am asking that this complex = struct be made
part of the defined types in the model extension d= raft.

There may some other ways to express the bit= map in some complex struct - but what i am
not seeing is the special treatment that a bit map should get from the= protocol that no other
complex struct would need.

=
cheers,
jamal


On Tue, Jul 2, 2013 at 12:30 PM, Joel <joe= l@stevecrocker.com> wrote:
It s true that you can, within the current protocol, define a structure con= sisting o a bit count and an array of 32 bit unsigned values. =A0And you ca= n use that for a bitmap.

But from a modeling perspective you are modeling a packing rather than mode= ling a bitmap. =A0If you want to argue that we do not need to model a bitma= p of named bits, that's fine. =A0It is a discussion we should have.

Yours,
Joel


On 7/2/2013 12:23 PM, Jamal Hadi Salim wrote:
Refer to my other email.
If i consider the bitmap entity as a complex type, the protocol is
agnostic to it.

cheers,
jamal


On Tue, Jul 2, 2013 at 12:22 PM, Joel <joel@stevecrocker.com
<mailto:joel@= stevecrocker.com>> wrote:

=A0 =A0 To answer your "why" question, from my perspective one of= the key
=A0 =A0 separations between model and protocol is that the encoding of bits=
=A0 =A0 on the wire is a protocol task. =A0Providing enough information tha= t
=A0 =A0 bits can be encoded is the models task.

=A0 =A0 Yours,
=A0 =A0 Joel

=A0 =A0 On 7/2/2013 12:17 PM, Jamal Hadi Salim wrote:

=A0 =A0 =A0 =A0 =A0 =A0 =A0__


=A0 =A0 =A0 =A0 =A0 =A0 =A0I am sure there are other reasons we said this n= eeds protocol
=A0 =A0 =A0 =A0 =A0 =A0 =A0mention,____

=A0 =A0 =A0 =A0 =A0 =A0 =A0but i cant recall.____

=A0 =A0 =A0 =A0 =A0 =A0 =A0*/__ __/*

=A0 =A0 =A0 =A0 =A0 =A0 =A0*/[=C5=C7] The main reason we said this needs pr= otocol mention,
=A0 =A0 =A0 =A0 if I

=A0 =A0 =A0 =A0 =A0 =A0 =A0remember correctly, is that how bitmaps are pack= ed should
=A0 =A0 =A0 =A0 be defined
=A0 =A0 =A0 =A0 =A0 =A0 =A0in a protocol document instead of a model one./*=



=A0 =A0 =A0 =A0 The question is: why?



--20cf3071cc1a1edfec04e08a4907-- From joel@stevecrocker.com Tue Jul 2 11:54:18 2013 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AED4021F8C4B for ; Tue, 2 Jul 2013 11:54:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.469 X-Spam-Level: X-Spam-Status: No, score=-1.469 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_DSL=1.129, UNPARSEABLE_RELAY=0.001] 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 oxuPYJefGKpD for ; Tue, 2 Jul 2013 11:54:13 -0700 (PDT) Received: from execdsl.com (remote.shinkuro.com [50.56.68.178]) by ietfa.amsl.com (Postfix) with ESMTP id 80D3821F9BFF for ; Tue, 2 Jul 2013 11:54:13 -0700 (PDT) Received: from dummy.name; Tue, 02 Jul 2013 18:54:12 +0000 Message-ID: <51D321D0.1090809@stevecrocker.com> Date: Tue, 02 Jul 2013 14:54:08 -0400 From: Joel User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Jamal Hadi Salim References: <004b01ce7733$e09bafe0$a1d30fa0$@com> <51D2FE3C.1060905@stevecrocker.com> <51D30017.5030909@stevecrocker.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-7; format=flowed Content-Transfer-Encoding: 8bit Cc: "forces@ietf.org" Subject: Re: [forces] bitmap representation X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jul 2013 18:54:18 -0000 Clearly, the construct you define is valid within the model and protocol and can be used. I am not sure I would call it a bitmap. Given tat we are not representing protocol message fields, I am not sure what problem is addressed by writing the definition of this data type in an RFC for inclusion in other documents that miht want to use it. Yours, Joel On 7/2/2013 1:00 PM, Jamal Hadi Salim wrote: > > Ok, so let state my case slightly differently. > If i wanted to defined a bitmap as a complex structure which constitutes > a bit-length followed by > the bit-content, I should be able to do that. I dont need to change > anything in the protocol to > accomodate that. I could choose to transport such a type as an ILV or TLV. > The sender and receiver both understand how to de/encode such a complex > type. > > If we are on agreement on the above, then: > Given the model defines the base types, i am asking that this complex > struct be made > part of the defined types in the model extension draft. > > There may some other ways to express the bitmap in some complex struct - > but what i am > not seeing is the special treatment that a bit map should get from the > protocol that no other > complex struct would need. > > cheers, > jamal > > > On Tue, Jul 2, 2013 at 12:30 PM, Joel > wrote: > > It s true that you can, within the current protocol, define a > structure consisting o a bit count and an array of 32 bit unsigned > values. And you can use that for a bitmap. > > But from a modeling perspective you are modeling a packing rather > than modeling a bitmap. If you want to argue that we do not need to > model a bitmap of named bits, that's fine. It is a discussion we > should have. > > Yours, > Joel > > > On 7/2/2013 12:23 PM, Jamal Hadi Salim wrote: > > Refer to my other email. > If i consider the bitmap entity as a complex type, the protocol is > agnostic to it. > > cheers, > jamal > > > On Tue, Jul 2, 2013 at 12:22 PM, Joel > >__> > wrote: > > To answer your "why" question, from my perspective one of > the key > separations between model and protocol is that the encoding > of bits > on the wire is a protocol task. Providing enough > information that > bits can be encoded is the models task. > > Yours, > Joel > > On 7/2/2013 12:17 PM, Jamal Hadi Salim wrote: > > __ > > > I am sure there are other reasons we said this > needs protocol > mention,____ > > but i cant recall.____ > > */__ __/* > > */[] The main reason we said this needs protocol > mention, > if I > > remember correctly, is that how bitmaps are packed > should > be defined > in a protocol document instead of a model one./* > > > > The question is: why? > > > From hadi@mojatatu.com Tue Jul 2 13:37:55 2013 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56CB721F9B85 for ; Tue, 2 Jul 2013 13:37:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.89 X-Spam-Level: X-Spam-Status: No, score=-102.89 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, 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 Th1BuGebFiem for ; Tue, 2 Jul 2013 13:37:50 -0700 (PDT) Received: from mail-ve0-f181.google.com (mail-ve0-f181.google.com [209.85.128.181]) by ietfa.amsl.com (Postfix) with ESMTP id 1481C21F9B87 for ; Tue, 2 Jul 2013 13:37:49 -0700 (PDT) Received: by mail-ve0-f181.google.com with SMTP id db10so5182721veb.26 for ; Tue, 02 Jul 2013 13:37:49 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=HQqTiyPCr5D5+t0vQeU5hOY83OjLGQC+OtdZmglWdCI=; b=ayQmVIUPQIYtcAj2/z2VfXGtzfRkCMtIy4zTgc16QNqOwatfMGOCrv0ttvo3+ZhpgK 2VQS8O+MoXaSFkOzVcMdY4E42Nb7el/eo9l/GGmt/4CYwYYXGB4HDcqcGZ5IGa32AWPh 5JkQdlDbg7R65lkTaY4bFd/BeZ5DFkc44Bw/X7x5Z51JEusOoHnix4mtzyFtUmIC4ReY tHlw6gph9HQyZa25eM3I1sYsRHl1CWPEfHTdelRFoQ+obrCn184Kooqh80CvlB0q9/ir IQbLtkarYIAYtCQ0FmFKLpYRbMmwxefmO3Yzgp2GyEIZqN+5eGRrtNBMJZPY3ij1Kc+x DE2g== X-Received: by 10.58.207.135 with SMTP id lw7mr11853393vec.92.1372797469345; Tue, 02 Jul 2013 13:37:49 -0700 (PDT) MIME-Version: 1.0 Received: by 10.58.247.197 with HTTP; Tue, 2 Jul 2013 13:37:29 -0700 (PDT) In-Reply-To: <51D321D0.1090809@stevecrocker.com> References: <004b01ce7733$e09bafe0$a1d30fa0$@com> <51D2FE3C.1060905@stevecrocker.com> <51D30017.5030909@stevecrocker.com> <51D321D0.1090809@stevecrocker.com> From: Jamal Hadi Salim Date: Tue, 2 Jul 2013 16:37:29 -0400 Message-ID: To: Joel Content-Type: multipart/alternative; boundary=047d7b6d7c5c825c9104e08d5139 X-Gm-Message-State: ALoCoQkC2TgJ+VnAqlBNa205Zw/WhntU44YBtpHyR68UmdJikYZwKpq4m9bfMbnRZM4glKMAebXH Cc: "forces@ietf.org" Subject: Re: [forces] bitmap representation X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jul 2013 20:37:55 -0000 --047d7b6d7c5c825c9104e08d5139 Content-Type: text/plain; charset=ISO-8859-7 Content-Transfer-Encoding: quoted-printable On Tue, Jul 2, 2013 at 2:54 PM, Joel wrote: > Clearly, the construct you define is valid within the model and protocol > and can be used. I am not sure I would call it a bitmap. > There are probably more optimal ways of representing a set of bits. > Given tat we are not representing protocol message fields, I am not sure > what problem is addressed by writing the definition of this data type in an RFC for inclusion in other documents > that miht want to use it. > I will be fine with removing it from both docs. The reason it showed up to begin with was we found that a bit representation of some form or other was frequently used in exchanges between the CE and FE - and that with the current atomic and base types definition there was no optimal way to send a set of bits on the wire. cheers, jamal > > Yours, > Joel > > > On 7/2/2013 1:00 PM, Jamal Hadi Salim wrote: > >> >> Ok, so let state my case slightly differently. >> If i wanted to defined a bitmap as a complex structure which constitutes >> a bit-length followed by >> the bit-content, I should be able to do that. I dont need to change >> anything in the protocol to >> accomodate that. I could choose to transport such a type as an ILV or TL= V. >> The sender and receiver both understand how to de/encode such a complex >> type. >> >> If we are on agreement on the above, then: >> Given the model defines the base types, i am asking that this complex >> struct be made >> part of the defined types in the model extension draft. >> >> There may some other ways to express the bitmap in some complex struct - >> but what i am >> not seeing is the special treatment that a bit map should get from the >> protocol that no other >> complex struct would need. >> >> cheers, >> jamal >> >> >> On Tue, Jul 2, 2013 at 12:30 PM, Joel > **> wrote: >> >> It s true that you can, within the current protocol, define a >> structure consisting o a bit count and an array of 32 bit unsigned >> values. And you can use that for a bitmap. >> >> But from a modeling perspective you are modeling a packing rather >> than modeling a bitmap. If you want to argue that we do not need to >> model a bitmap of named bits, that's fine. It is a discussion we >> should have. >> >> Yours, >> Joel >> >> >> On 7/2/2013 12:23 PM, Jamal Hadi Salim wrote: >> >> Refer to my other email. >> If i consider the bitmap entity as a complex type, the protocol = is >> agnostic to it. >> >> cheers, >> jamal >> >> >> On Tue, Jul 2, 2013 at 12:22 PM, Joel > >> ** >> >__> >> >> wrote: >> >> To answer your "why" question, from my perspective one of >> the key >> separations between model and protocol is that the encoding >> of bits >> on the wire is a protocol task. Providing enough >> information that >> bits can be encoded is the models task. >> >> Yours, >> Joel >> >> On 7/2/2013 12:17 PM, Jamal Hadi Salim wrote: >> >> __ >> >> >> I am sure there are other reasons we said this >> needs protocol >> mention,____ >> >> but i cant recall.____ >> >> */__ __/* >> >> */[=C5=C7] The main reason we said this needs prot= ocol >> mention, >> if I >> >> remember correctly, is that how bitmaps are packed >> should >> be defined >> in a protocol document instead of a model one./* >> >> >> >> The question is: why? >> >> >> >> --047d7b6d7c5c825c9104e08d5139 Content-Type: text/html; charset=ISO-8859-7 Content-Transfer-Encoding: quoted-printable

= On Tue, Jul 2, 2013 at 2:54 PM, Joel <joel@stevecrocker.com> wrote:
Clearly, the construct you define is valid w= ithin the model and protocol and can be used. =A0I am not sure I would call= it a bitmap.

There are probably more optimal ways of re= presenting a set of bits.
=A0
Given tat we are not representing protocol message fields, I am not sure wh= at problem is addressed by writing=A0
the definition of this data type in an RFC for inclusion in other documents= that miht want to use it.


I will be fine with removing it from both docs.
The reason it = showed up to begin with was we found that a bit representation of some form= or other was
frequently used in exchanges between the CE and FE - and that with the= current atomic and base types
definition there was no optimal wa= y to send a set of bits on the wire.

cheers,
jamal

=A0

Yours,
Joel


On 7/2/2013 1:00 PM, Jamal Hadi Salim wrote:

Ok, so let state my case slightly differently.
If i wanted to defined a bitmap as a complex structure which constitutes a bit-length followed by
the bit-content, I should be able to do that. I dont need to change
anything in the protocol to
accomodate that. I could choose to transport such a type as an ILV or TLV.<= br> The sender and receiver both understand how to de/encode such a complex
type.

If we are on agreement on the above, then:
Given the model defines the base types, i am asking that this complex
struct be made
part of the defined types in the model extension draft.

There may some other ways to express the bitmap in some complex struct - but what i am
not seeing is the special treatment that a bit map should get from the
protocol that no other
complex struct would need.

cheers,
jamal


On Tue, Jul 2, 2013 at 12:30 PM, Joel <joel@stevecrocker.com
<mailto:joel@= stevecrocker.com>> wrote:

=A0 =A0 It s true that you can, within the current protocol, define a
=A0 =A0 structure consisting o a bit count and an array of 32 bit unsigned<= br> =A0 =A0 values. =A0And you can use that for a bitmap.

=A0 =A0 But from a modeling perspective you are modeling a packing rather =A0 =A0 than modeling a bitmap. =A0If you want to argue that we do not need= to
=A0 =A0 model a bitmap of named bits, that's fine. =A0It is a discussio= n we
=A0 =A0 should have.

=A0 =A0 Yours,
=A0 =A0 Joel


=A0 =A0 On 7/2/2013 12:23 PM, Jamal Hadi Salim wrote:

=A0 =A0 =A0 =A0 Refer to my other email.
=A0 =A0 =A0 =A0 If i consider the bitmap entity as a complex type, the prot= ocol is
=A0 =A0 =A0 =A0 agnostic to it.

=A0 =A0 =A0 =A0 cheers,
=A0 =A0 =A0 =A0 jamal


=A0 =A0 =A0 =A0 On Tue, Jul 2, 2013 at 12:22 PM, Joel <joel@stevecrocker.com
=A0 =A0 =A0 =A0 <mailto:joel@stevecrocker.com>
=A0 =A0 =A0 =A0 <mailto:joel@stevecrocker.com <mailto:joel@stevecrocker.com>>__= >

=A0 =A0 =A0 =A0 wrote:

=A0 =A0 =A0 =A0 =A0 =A0 =A0To answer your "why" question, from my= perspective one of
=A0 =A0 =A0 =A0 the key
=A0 =A0 =A0 =A0 =A0 =A0 =A0separations between model and protocol is that t= he encoding
=A0 =A0 =A0 =A0 of bits
=A0 =A0 =A0 =A0 =A0 =A0 =A0on the wire is a protocol task. =A0Providing eno= ugh
=A0 =A0 =A0 =A0 information that
=A0 =A0 =A0 =A0 =A0 =A0 =A0bits can be encoded is the models task.

=A0 =A0 =A0 =A0 =A0 =A0 =A0Yours,
=A0 =A0 =A0 =A0 =A0 =A0 =A0Joel

=A0 =A0 =A0 =A0 =A0 =A0 =A0On 7/2/2013 12:17 PM, Jamal Hadi Salim wrote:
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 __


=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 I am sure there are other reaso= ns we said this
=A0 =A0 =A0 =A0 needs protocol
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 mention,____

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 but i cant recall.____

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 */__ __/*

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 */[=C5=C7] The main reason we s= aid this needs protocol
=A0 =A0 =A0 =A0 mention,
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0if I

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 remember correctly, is that how= bitmaps are packed
=A0 =A0 =A0 =A0 should
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0be defined
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 in a protocol document instead = of a model one./*



=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0The question is: why?




--047d7b6d7c5c825c9104e08d5139-- From ehalep@gmail.com Tue Jul 2 16:57:38 2013 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FCF421F9A03 for ; Tue, 2 Jul 2013 16:57:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 2sTOj1jz6Zig for ; Tue, 2 Jul 2013 16:57:35 -0700 (PDT) Received: from mail-ea0-x235.google.com (mail-ea0-x235.google.com [IPv6:2a00:1450:4013:c01::235]) by ietfa.amsl.com (Postfix) with ESMTP id E7EBB21F9A00 for ; Tue, 2 Jul 2013 16:57:34 -0700 (PDT) Received: by mail-ea0-f181.google.com with SMTP id a15so3107365eae.26 for ; Tue, 02 Jul 2013 16:57:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:x-mailer:thread-index:content-language; bh=ty5jIor43iI1xa/29YH8Ssj9KfcjFOCKvs6wX0Pesz4=; b=XN+phswtINheUm+E2y1ikAgPdPXT9v8gVAKWZfXHeclFvcBq4vPvsqS9AYEcsUPOMV TJS7p0JgKPtq65R54lCKxQJ6JapdeutVbLokcgRug1HYTINf97f2SzIUcNkV5umOPR8W Vfx6rbBmkJ4QPb5TpraUAy/lHS5IaJdvtDYKwXoouLS1GnOHJ6KWxAMriScnyGZ3ougv aJ7wXPx7xAMy32ZYHtB60k4nEM2JSea65D+/C3E1BNSf5awH/E15ZnmlLoQXY5O1N0nY D0I8ar5AARCeeIp1IUlKbwkWbPziyLbjhtbG0WEzMagi07u0YJpOXE/Z6iDnGWPcEF1H 2W/A== X-Received: by 10.14.2.137 with SMTP id 9mr28091703eef.64.1372809448247; Tue, 02 Jul 2013 16:57:28 -0700 (PDT) Received: from EhalepXPS (ppp141237075082.access.hol.gr. [141.237.75.82]) by mx.google.com with ESMTPSA id n45sm40063888eew.1.2013.07.02.16.57.26 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Tue, 02 Jul 2013 16:57:27 -0700 (PDT) From: "Haleplidis Evangelos" To: "'Jamal Hadi Salim'" , "'Joel'" References: <004b01ce7733$e09bafe0$a1d30fa0$@com> <51D2FE3C.1060905@stevecrocker.com> <51D30017.5030909@stevecrocker.com> <51D321D0.1090809@stevecrocker.com> In-Reply-To: Date: Wed, 3 Jul 2013 02:57:23 +0300 Message-ID: <00d501ce777f$e6ad1da0$b40758e0$@com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00D6_01CE7799.0BFA55A0" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac53ZAS5pmwiL2EqSkmaEmqhbb8iUgAGQSsA Content-Language: el Cc: forces@ietf.org Subject: Re: [forces] bitmap representation X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jul 2013 23:57:38 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_00D6_01CE7799.0BFA55A0 Content-Type: text/plain; charset="iso-8859-7" Content-Transfer-Encoding: quoted-printable Greetings Jamal and Joel, =20 Clearly, the construct you define is valid within the model and protocol = and can be used. I am not sure I would call it a bitmap. =20 [=C5=C7] I agree that this is not a bitmap, as well imho I don't think = that's a datatype. The reason for this is that there are protocol semantics in = the model and I don't think that there should be. The question is why would = the actual data contain information for the protocol on how the message is = to be parsed? And it's not for a special datatype, but for a base datatype. =20 There are probably more optimal ways of representing a set of bits. =20 Given tat we are not representing protocol message fields, I am not sure what problem is addressed by writing=20 the definition of this data type in an RFC for inclusion in other = documents that miht want to use it. =20 =20 I will be fine with removing it from both docs. The reason it showed up to begin with was we found that a bit = representation of some form or other was frequently used in exchanges between the CE and FE - and that with the current atomic and base types definition there was no optimal way to send a set of bits on the wire. =20 [=C5=C7] I have no problem as well if it will cause more damage than = good. There is always a way to represent a bitmap as an array or a struct of = Boolean, but as you say it's not optimal. Or you can use another datatype of = 1byte or 2 or 4 or 8 bytes to use as a bitmap. The problem here is that you can't specify the meaning of each bit. =20 Imho, I don't think that we can express the bitmap in any way using the current ForCES model/protocol that will allow us without any changes in = the protocol to define a bitmap in any way while allowing an optimal way to = send bitmaps.=20 The reason is that the smallest amount of a ForCES datatype is a byte. = We don't deal with bits. Therefore if the wg agrees that there is a need = for being able to model bitmaps we'll have to discuss on the protocol = extension how that is encoded. =20 Imho, there are a few cases where bitmaps may be useful. Mostly for capabilities though, for example when you have many=20 capabilities of a similar nature, e.g. speed links that you may support, = you can describe it as a bitmap instead of having multiple booleans. =20 cheers, jamal =20 =20 Yours, Joel On 7/2/2013 1:00 PM, Jamal Hadi Salim wrote: Ok, so let state my case slightly differently. If i wanted to defined a bitmap as a complex structure which constitutes a bit-length followed by the bit-content, I should be able to do that. I dont need to change anything in the protocol to accomodate that. I could choose to transport such a type as an ILV or = TLV. The sender and receiver both understand how to de/encode such a complex type. If we are on agreement on the above, then: Given the model defines the base types, i am asking that this complex struct be made part of the defined types in the model extension draft. There may some other ways to express the bitmap in some complex struct - but what i am not seeing is the special treatment that a bit map should get from the protocol that no other complex struct would need. cheers, jamal On Tue, Jul 2, 2013 at 12:30 PM, Joel > wrote: It s true that you can, within the current protocol, define a structure consisting o a bit count and an array of 32 bit unsigned values. And you can use that for a bitmap. But from a modeling perspective you are modeling a packing rather than modeling a bitmap. If you want to argue that we do not need to model a bitmap of named bits, that's fine. It is a discussion we should have. Yours, Joel On 7/2/2013 12:23 PM, Jamal Hadi Salim wrote: Refer to my other email. If i consider the bitmap entity as a complex type, the protocol = is agnostic to it. cheers, jamal On Tue, Jul 2, 2013 at 12:22 PM, Joel >__> wrote: To answer your "why" question, from my perspective one of the key separations between model and protocol is that the encoding of bits on the wire is a protocol task. Providing enough information that bits can be encoded is the models task. Yours, Joel On 7/2/2013 12:17 PM, Jamal Hadi Salim wrote: __ I am sure there are other reasons we said this needs protocol mention,____ but i cant recall.____ */__ __/* */[=C5=C7] The main reason we said this needs = protocol mention, if I remember correctly, is that how bitmaps are packed should be defined in a protocol document instead of a model one./* The question is: why? =20 ------=_NextPart_000_00D6_01CE7799.0BFA55A0 Content-Type: text/html; charset="iso-8859-7" Content-Transfer-Encoding: quoted-printable

Greetings Jamal and Joel,

 

Clearly, = the construct you define is valid within the model and protocol and can = be used.  I am not sure I would call it a = bitmap.

 

[=C5=C7] I agree that this is not a bitmap, as well imho I = don’t think that’s a datatype. The reason for this is that = there are protocol semantics in the model and I don’t think that = there should be. The question is why would the actual data contain = information for the protocol on how the message is to be parsed? And = it’s not for a special datatype, but for a base = datatype.

 

There are = probably more optimal ways of representing a set of = bits.

 

Given tat = we are not representing protocol message fields, I am not sure what = problem is addressed by = writing 

the = definition of this data type in an RFC for inclusion in other documents = that miht want to use it.

 

 

I = will be fine with removing it from both = docs.

The reason it showed = up to begin with was we found that a bit representation of some form or = other was

frequently used = in exchanges between the CE and FE - and that with the current atomic = and base types

definition = there was no optimal way to send a set of bits on the = wire.

 

[=C5=C7] I have no problem as well if it will cause more damage than = good. There is always a way to represent a bitmap as an array or a = struct of Boolean, but as you say it’s not optimal. Or you can use = another datatype of 1byte or 2 or 4 or 8 bytes to use as a bitmap. The = problem here is that you can’t specify the meaning of each = bit.

 

Imho, I don’t think that we can express the bitmap in any way = using the current ForCES model/protocol that will allow us without any = changes in the protocol to define a bitmap in any way while allowing an = optimal way to send bitmaps.

The reason is that the smallest amount of a ForCES datatype is a = byte. We don’t deal with bits. Therefore if the wg agrees that = there is a need for being able to model bitmaps we’ll have to = discuss on the protocol extension how that is = encoded.

 

Imho, there are a few cases where bitmaps may be useful. Mostly for = capabilities though, for example when you have many =

capabilities of a similar nature, e.g. speed links that you may = support, you can describe it as a bitmap instead of having multiple = booleans.

 

cheers,

jamal

 

 


Yours,
Joel



On 7/2/2013 1:00 PM, Jamal Hadi Salim = wrote:


Ok, so let state my case slightly = differently.
If i wanted to defined a bitmap as a complex structure = which constitutes
a bit-length followed by
the bit-content, I = should be able to do that. I dont need to change
anything in the = protocol to
accomodate that. I could choose to transport such a type = as an ILV or TLV.
The sender and receiver both understand how to = de/encode such a complex
type.

If we are on agreement on the = above, then:
Given the model defines the base types, i am asking that = this complex
struct be made
part of the defined types in the model = extension draft.

There may some other ways to express the bitmap = in some complex struct -
but what i am
not seeing is the special = treatment that a bit map should get from the
protocol that no = other
complex struct would = need.

cheers,
jamal


On Tue, Jul 2, 2013 at 12:30 = PM, Joel <joel@stevecrocker.com

<mailto:joel@stevecrocker.com>> wrote:

  =   It s true that you can, within the current protocol, define = a
    structure consisting o a bit count and an array of 32 = bit unsigned
    values.  And you can use that for a = bitmap.

    But from a modeling perspective you are = modeling a packing rather
    than modeling a bitmap. =  If you want to argue that we do not need to
    model = a bitmap of named bits, that's fine.  It is a discussion = we
    should have.

    Yours,
  =   Joel


    On 7/2/2013 12:23 PM, Jamal Hadi = Salim wrote:

        Refer to my other = email.
        If i consider the bitmap entity as = a complex type, the protocol is
        agnostic = to it.

        cheers,
    =     jamal


        On Tue, Jul = 2, 2013 at 12:22 PM, Joel <joel@stevecrocker.com
      =   <mailto:joel@stevecrocker.com>

        <mailto:joel@stevecrocker.com <mailto:joel@stevecrocker.com>>__>

<= div>


  =       wrote:

          =    To answer your "why" question, from my = perspective one of
        the key
  =            separations between model and = protocol is that the encoding
        of = bits
             on the wire is a = protocol task.  Providing enough
        = information that
             bits = can be encoded is the models task.

        =      Yours,
            =  Joel

             On = 7/2/2013 12:17 PM, Jamal Hadi Salim wrote:

      =                 = __


                =       I am sure there are other reasons we said = this
        needs protocol
    =                   = mention,____

              =         but i cant recall.____

    =                   */__ = __/*

                =       */[=C5=C7] The main reason we said this needs = protocol
        mention,
      =            if I

    =                   remember = correctly, is that how bitmaps are packed
        = should
                =  be defined
              =         in a protocol document instead of a model = one./*



              =    The question is: = why?


 

------=_NextPart_000_00D6_01CE7799.0BFA55A0-- From hadi@mojatatu.com Wed Jul 3 03:44:40 2013 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DBE321F9A23 for ; Wed, 3 Jul 2013 03:44:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.901 X-Spam-Level: X-Spam-Status: No, score=-102.901 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, 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 QBq6D0Pfii7A for ; Wed, 3 Jul 2013 03:44:35 -0700 (PDT) Received: from mail-ve0-f170.google.com (mail-ve0-f170.google.com [209.85.128.170]) by ietfa.amsl.com (Postfix) with ESMTP id B5BF621F9A10 for ; Wed, 3 Jul 2013 03:44:34 -0700 (PDT) Received: by mail-ve0-f170.google.com with SMTP id 14so5780298vea.15 for ; Wed, 03 Jul 2013 03:44:32 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=6IqxluvEJRacfq9qBFilzYD/LqcF7qsV8oaSOAoP8LM=; b=YJmNd/iT5TW+yrtJI8lHpkVHiHAouKByclnGPyZ2YXR5uk4Y2Muy7WKh/DKr326A5Z Gug1hH7GvkccWYQUzPd26SuWiYGYl1mxHk2Tvkr4/zcl/yFCILe+aZFq0aeWhz3RKZm9 +0dJ4qvah4XQY6GyAkJQq0mOPHcOOaNrcT7tXBKoTtgA0BjKHn3MysmCYADhWtGaV/IB qndcUx305glmXmuCgoDxYsTRda2Dwrc3tUjtJCKnkUurdWhNf4wRKmsuJeqENseSkGro AmB/v3hslAjbhbyxCz3w9F9qgrcnWMX4M8T6RGVdsvSCEfiVkY2e/ftuObYKK0XSkva3 haTg== X-Received: by 10.58.207.135 with SMTP id lw7mr48949vec.92.1372848272830; Wed, 03 Jul 2013 03:44:32 -0700 (PDT) MIME-Version: 1.0 Received: by 10.58.247.197 with HTTP; Wed, 3 Jul 2013 03:44:12 -0700 (PDT) In-Reply-To: <00d501ce777f$e6ad1da0$b40758e0$@com> References: <004b01ce7733$e09bafe0$a1d30fa0$@com> <51D2FE3C.1060905@stevecrocker.com> <51D30017.5030909@stevecrocker.com> <51D321D0.1090809@stevecrocker.com> <00d501ce777f$e6ad1da0$b40758e0$@com> From: Jamal Hadi Salim Date: Wed, 3 Jul 2013 06:44:12 -0400 Message-ID: To: Haleplidis Evangelos Content-Type: multipart/alternative; boundary=047d7b6d7c5ca2057104e09925ef X-Gm-Message-State: ALoCoQlPfjFfiP+bHQg4vFLIFkW9c5xV4rrX/54mavyIRHHC7S7j4ZYuxx1RCSShEcjZs4bxc0JQ Cc: "forces@ietf.org" Subject: Re: [forces] bitmap representation X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jul 2013 10:44:40 -0000 --047d7b6d7c5ca2057104e09925ef Content-Type: text/plain; charset=ISO-8859-7 Content-Transfer-Encoding: quoted-printable Ok, so how i make the update release for now with a place holder for bitmap and we can talk about this at the meeting then? I am going to post a new version of the draft cheers, jamal On Tue, Jul 2, 2013 at 7:57 PM, Haleplidis Evangelos wrot= e: > Greetings Jamal and Joel,**** > > ** ** > > Clearly, the construct you define is valid within the model and protocol > and can be used. I am not sure I would call it a bitmap.**** > > ** ** > > *[=C5=C7] I agree that this is not a bitmap, as well imho I don=A2t think > that=A2s a datatype. The reason for this is that there are protocol seman= tics > in the model and I don=A2t think that there should be. The question is wh= y > would the actual data contain information for the protocol on how the > message is to be parsed? And it=A2s not for a special datatype, but for a > base datatype.* > > ** ** > > There are probably more optimal ways of representing a set of bits.**** > > **** > > Given tat we are not representing protocol message fields, I am not sure > what problem is addressed by writing **** > > the definition of this data type in an RFC for inclusion in other > documents that miht want to use it.**** > > ** ** > > ** ** > > I will be fine with removing it from both docs.**** > > The reason it showed up to begin with was we found that a bit > representation of some form or other was**** > > frequently used in exchanges between the CE and FE - and that with the > current atomic and base types**** > > definition there was no optimal way to send a set of bits on the wire.***= * > > ** ** > > *[=C5=C7] I have no problem as well if it will cause more damage than goo= d. > There is always a way to represent a bitmap as an array or a struct of > Boolean, but as you say it=A2s not optimal. Or you can use another dataty= pe > of 1byte or 2 or 4 or 8 bytes to use as a bitmap. The problem here is tha= t > you can=A2t specify the meaning of each bit.* > > * * > > *Imho, I don=A2t think that we can express the bitmap in any way using th= e > current ForCES model/protocol that will allow us without any changes in t= he > protocol to define a bitmap in any way while allowing an optimal way to > send bitmaps. * > > *The reason is that the smallest amount of a ForCES datatype is a byte. > We don=A2t deal with bits. Therefore if the wg agrees that there is a nee= d > for being able to model bitmaps we=A2ll have to discuss on the protocol > extension how that is encoded.* > > * * > > *Imho, there are a few cases where bitmaps may be useful. Mostly for > capabilities though, for example when you have many * > > *capabilities of a similar nature, e.g. speed links that you may support, > you can describe it as a bitmap instead of having multiple booleans.* > > ** ** > > cheers,**** > > jamal**** > > ** ** > > **** > > > Yours, > Joel**** > > > > On 7/2/2013 1:00 PM, Jamal Hadi Salim wrote:**** > > > Ok, so let state my case slightly differently. > If i wanted to defined a bitmap as a complex structure which constitutes > a bit-length followed by > the bit-content, I should be able to do that. I dont need to change > anything in the protocol to > accomodate that. I could choose to transport such a type as an ILV or TLV= . > The sender and receiver both understand how to de/encode such a complex > type. > > If we are on agreement on the above, then: > Given the model defines the base types, i am asking that this complex > struct be made > part of the defined types in the model extension draft. > > There may some other ways to express the bitmap in some complex struct - > but what i am > not seeing is the special treatment that a bit map should get from the > protocol that no other > complex struct would need. > > cheers, > jamal > > > On Tue, Jul 2, 2013 at 12:30 PM, Joel > > wrote: > > It s true that you can, within the current protocol, define a > structure consisting o a bit count and an array of 32 bit unsigned > values. And you can use that for a bitmap. > > But from a modeling perspective you are modeling a packing rather > than modeling a bitmap. If you want to argue that we do not need to > model a bitmap of named bits, that's fine. It is a discussion we > should have. > > Yours, > Joel > > > On 7/2/2013 12:23 PM, Jamal Hadi Salim wrote: > > Refer to my other email. > If i consider the bitmap entity as a complex type, the protocol i= s > agnostic to it. > > cheers, > jamal > > > On Tue, Jul 2, 2013 at 12:22 PM, Joel **** > > >__>*= * > ** > > > wrote: > > To answer your "why" question, from my perspective one of > the key > separations between model and protocol is that the encoding > of bits > on the wire is a protocol task. Providing enough > information that > bits can be encoded is the models task. > > Yours, > Joel > > On 7/2/2013 12:17 PM, Jamal Hadi Salim wrote: > > __ > > > I am sure there are other reasons we said this > needs protocol > mention,____ > > but i cant recall.____ > > */__ __/* > > */[=C5=C7] The main reason we said this needs proto= col > mention, > if I > > remember correctly, is that how bitmaps are packed > should > be defined > in a protocol document instead of a model one./* > > > > The question is: why? > > > **** > > ** ** > --047d7b6d7c5ca2057104e09925ef Content-Type: text/html; charset=ISO-8859-7 Content-Transfer-Encoding: quoted-printable
Ok, so how i make the update release for now with a place = holder for
bitmap and we can talk about this at the meeting then?
=
I am going to post a new version of the draft

cheers,
jamal


On Tue, Jul 2, 2013 at 7:57 PM, Haleplidis Evangelos = <ehalep@gmail.com> wrote:

G= reetings Jamal and Joel,

=A0=

Clearly, the construct you define is valid within the model and protocol = and can be used. =A0I am not sure I would call it a bitmap.

=A0

[=C5=C7] I agree that this is not a bitmap, as = well imho I don=A2t think that=A2s a datatype. The reason for this is that = there are protocol semantics in the model and I don=A2t think that there sh= ould be. The question is why would the actual data contain information for = the protocol on how the message is to be parsed? And it=A2s not for a speci= al datatype, but for a base datatype.

=A0=

There= are probably more optimal ways of representing a set of bits.

=A0

Given tat we a= re not representing protocol message fields, I am not sure what problem is = addressed by writing=A0

the definition of this data type in an RFC for inclusion in = other documents that miht want to use it.

=A0

=A0

I will be fine with removing it from both docs.

The reason it showed up to begin with was we found that a bit representatio= n of some form or other was

frequently used in exchanges between the CE and FE - and that with the = current atomic and base types

definition there was no optimal way to se= nd a set of bits on the wire.

=A0<= /span>

[=C5= =C7] I have no problem as well if it will cause more damage than good. Ther= e is always a way to represent a bitmap as an array or a struct of Boolean,= but as you say it=A2s not optimal. Or you can use another datatype of 1byt= e or 2 or 4 or 8 bytes to use as a bitmap. The problem here is that you can= =A2t specify the meaning of each bit.

<= /u>=A0

Imho, I don=A2t think that we can express the b= itmap in any way using the current ForCES model/protocol that will allow us= without any changes in the protocol to define a bitmap in any way while al= lowing an optimal way to send bitmaps.

The = reason is that the smallest amount of a ForCES datatype is a byte. We don= =A2t deal with bits. Therefore if the wg agrees that there is a need for be= ing able to model bitmaps we=A2ll have to discuss on the protocol extension= how that is encoded.

<= /u>=A0

Imho, there are a few cases where bitmaps may b= e useful. Mostly for capabilities though, for example when you have many

capa= bilities of a similar nature, e.g. speed links that you may support, you ca= n describe it as a bitmap instead of having multiple booleans.

=A0=

= cheers,

jamal

=A0

=A0<= u>


Yours,
Joel



On 7/2/2013 1:00 PM, Jamal Hadi Salim wrote:<= /u>


Ok, so let state my case slightly different= ly.
If i wanted to defined a bitmap as a complex structure which constit= utes
a bit-length followed by
the bit-content, I should be able to do= that. I dont need to change
anything in the protocol to
accomodate that. I could choose to transport= such a type as an ILV or TLV.
The sender and receiver both understand h= ow to de/encode such a complex
type.

If we are on agreement on th= e above, then:
Given the model defines the base types, i am asking that this complex
st= ruct be made
part of the defined types in the model extension draft.
=
There may some other ways to express the bitmap in some complex struct = -
but what i am
not seeing is the special treatment that a bit map should = get from the
protocol that no other
complex struct would need.
cheers,
jamal


On Tue, Jul 2, 2013 at 12:30 PM, Joel <joel@stevecrocker.co= m

<mailto:joel@stevecrocker.com>> wrote:
=A0 =A0 It s true that you can, within the current protocol, define a
= =A0 =A0 structure consisting o a bit count and an array of 32 bit unsigned<= br> =A0 =A0 values. =A0And you can use that for a bitmap.

=A0 =A0 But fr= om a modeling perspective you are modeling a packing rather
=A0 =A0 than= modeling a bitmap. =A0If you want to argue that we do not need to
=A0 = =A0 model a bitmap of named bits, that's fine. =A0It is a discussion we=
=A0 =A0 should have.

=A0 =A0 Yours,
=A0 =A0 Joel


=A0 = =A0 On 7/2/2013 12:23 PM, Jamal Hadi Salim wrote:

=A0 =A0 =A0 =A0 Re= fer to my other email.
=A0 =A0 =A0 =A0 If i consider the bitmap entity a= s a complex type, the protocol is
=A0 =A0 =A0 =A0 agnostic to it.

=A0 =A0 =A0 =A0 cheers,
=A0 =A0 = =A0 =A0 jamal


=A0 =A0 =A0 =A0 On Tue, Jul 2, 2013 at 12:22 PM, J= oel <joel@ste= vecrocker.com
=A0 =A0 =A0 =A0 <mailto:joel@stevecrocker.com>=

=A0 =A0 =A0 =A0 <mailto:joel@stevecrocker.com <mailt= o:joel@stevecroc= ker.com>>__>


=A0 =A0= =A0 =A0 wrote:

=A0 =A0 =A0 =A0 =A0 =A0 =A0To answer your "why&= quot; question, from my perspective one of
=A0 =A0 =A0 =A0 the key
= =A0 =A0 =A0 =A0 =A0 =A0 =A0separations between model and protocol is that t= he encoding
=A0 =A0 =A0 =A0 of bits
=A0 =A0 =A0 =A0 =A0 =A0 =A0on the wire is a prot= ocol task. =A0Providing enough
=A0 =A0 =A0 =A0 information that
=A0 = =A0 =A0 =A0 =A0 =A0 =A0bits can be encoded is the models task.

=A0 = =A0 =A0 =A0 =A0 =A0 =A0Yours,
=A0 =A0 =A0 =A0 =A0 =A0 =A0Joel

=A0 =A0 =A0 =A0 =A0 =A0 =A0On 7/2/2013 12:17 PM, Jamal Hadi Salim wrote:
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 __


=A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 I am sure there are other reasons we said t= his
=A0 =A0 =A0 =A0 needs protocol
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 mention,____

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 but i cant recall.____
<= br>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 */__ __/*

=A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 */[=C5=C7] The main reason we said this ne= eds protocol
=A0 =A0 =A0 =A0 mention,
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0if I

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 remember correctly, is that how= bitmaps are packed
=A0 =A0 =A0 =A0 should
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0be defined
= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 in a protocol document instead = of a model one./*



=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0The que= stion is: why?


=A0

=

--047d7b6d7c5ca2057104e09925ef-- From hadi@mojatatu.com Wed Jul 3 03:56:45 2013 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97AC921F9C98 for ; Wed, 3 Jul 2013 03:56:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.909 X-Spam-Level: X-Spam-Status: No, score=-102.909 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, 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 QCUqqj-srPzz for ; Wed, 3 Jul 2013 03:56:40 -0700 (PDT) Received: from mail-vc0-f181.google.com (mail-vc0-f181.google.com [209.85.220.181]) by ietfa.amsl.com (Postfix) with ESMTP id EC19221F9CA4 for ; Wed, 3 Jul 2013 03:56:36 -0700 (PDT) Received: by mail-vc0-f181.google.com with SMTP id lf11so3469804vcb.40 for ; Wed, 03 Jul 2013 03:56:36 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type :x-gm-message-state; bh=bwa5WS5w/cjW7YTbqbZ54RCLqJoOEXRAWI3piT5FJFo=; b=GTmlYbUNTdVk4xPuDC2m1yWh22vqsXN0CI47DtLKSkY1vvgiRg+pFDoGEh/khMm1WL K2pE8j+4aceyFEolKaI65zFnE2bnn1/yx8mGoGLIr76MSW5bg3D22i77yH6jm9en9vB2 cJIZzOHbkcJCkWEjp759/Rj+hXA15MrKFr058GrdIqWGbh1OrjjoNaBX+EYghEIvBiu4 fhLrwODSq1MJwu82DDbFZS545RfnrXyI7vx5viuVWfN8JQR5g0knbGLR+/3mQZzKT1OE Aq9InV65Sq4ySM349MiUeQEe2Ud9dTdO9/taSpbuOyj5Sa48sbCblf0RB+rV0DXD/ndy 02DQ== X-Received: by 10.52.177.6 with SMTP id cm6mr108949vdc.0.1372848996419; Wed, 03 Jul 2013 03:56:36 -0700 (PDT) MIME-Version: 1.0 Received: by 10.58.247.197 with HTTP; Wed, 3 Jul 2013 03:56:16 -0700 (PDT) From: Jamal Hadi Salim Date: Wed, 3 Jul 2013 06:56:16 -0400 Message-ID: To: "forces@ietf.org" Content-Type: multipart/alternative; boundary=20cf3071cc1ac322f604e09950b4 X-Gm-Message-State: ALoCoQmxh0itqZ0Ibt53qCwlx+3ahFPzRWv32J41j9V0nylN6uagiw9U/H1iM0FriulN76HnCKES Subject: [forces] LFB properties X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jul 2013 10:56:45 -0000 --20cf3071cc1ac322f604e09950b4 Content-Type: text/plain; charset=ISO-8859-1 This is a request in relation to the model extension draft. Often when debugging issues between CE and FE we are interested in finding sent/received messages/errors per LFB instance at each layer in the NE cluster. i.e i want to find out for each FE what each LFB instance has in terms of stats in its communication to the CE. This has nothing to do with what such an LFB would have in its data part stats (which should be part of the model for the specific LFB). Our implementation experience indicates we need this for every LFB without exception. While currently we are doing this through some management interface - I would like to propose an "LFB property" (just like we have Table properties) which would have simple stats per LFB instance. The stats are: send {pkts, bytes, errors} and receive {pkts, bytes, errors} Thoughts? cheers, jamal --20cf3071cc1ac322f604e09950b4 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

This is a request in relation to the model = extension draft.

Often when debugging issues between CE = and FE we are interested in
finding sent/received messages/errors= per LFB instance at each
layer in the NE cluster.=A0
i.e i want to find out for each = FE what each LFB instance has
in terms of stats in its communicat= ion to the CE. This has nothing
to do with what such an LFB would= have in its data part stats (which
should be part of the model for the specific LFB).

Our implementation experience indicates we need this for every LFB
without exception. While currently we are doing this through some= =A0
management interface - I would like to propose an "LFB property&q= uot;
(just like we have Table properties) which would have simple= stats
per LFB instance. The stats are:
send {pkts, byt= es, errors} and receive=A0{pkts, bytes, errors}

Thoughts?

cheers,
ja= mal
--20cf3071cc1ac322f604e09950b4-- From ehalep@gmail.com Wed Jul 3 06:40:16 2013 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52D1211E81BA for ; Wed, 3 Jul 2013 06:40:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 94-OkjBMayt9 for ; Wed, 3 Jul 2013 06:40:14 -0700 (PDT) Received: from mail-ea0-x231.google.com (mail-ea0-x231.google.com [IPv6:2a00:1450:4013:c01::231]) by ietfa.amsl.com (Postfix) with ESMTP id 5A4B511E81B6 for ; Wed, 3 Jul 2013 06:40:14 -0700 (PDT) Received: by mail-ea0-f177.google.com with SMTP id j14so89675eak.22 for ; Wed, 03 Jul 2013 06:40:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-type:x-mailer:thread-index:content-language; bh=xQqd6EGt84bNDH2RiC0U6XnYvcVkAOSmRTqelzzgh/Y=; b=DbP9CyQOQFB7Eng+aQlRKG1x9uTGbVPYkB4RvTB+5Z1R728w2LuvWpe5r1eeqnK56v HmJp2L4VZLCop/C1vPWcyIa2WsEC2MinA3ojDiMQRq+4vJVLP7w4LayPa87he8nA4nkt PZ5lgWIOPS+MnAGmx6ZZB9nEKedt4oFnupFUckOB+ySRMeDF13c8IQVA7t6ycKDUz1Gx r64GSbabP8SkyfGNGUSFvYhrxMr5QiBsMJP9S8Wg2qK4Kx0dUX64hcs2KID7qkzHS67q AkH0IGmPGdro4ezHhwo6u5Itfgead2JwaXfA6QbUsW4sff413b/KxqG3d/Gm2XinmslJ mO3g== X-Received: by 10.14.29.69 with SMTP id h45mr1066246eea.127.1372858417065; Wed, 03 Jul 2013 06:33:37 -0700 (PDT) Received: from EhalepXPS (ppp141237019128.access.hol.gr. [141.237.19.128]) by mx.google.com with ESMTPSA id ci50sm44264083eeb.12.2013.07.03.06.33.35 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Wed, 03 Jul 2013 06:33:36 -0700 (PDT) From: "Haleplidis Evangelos" To: "'Jamal Hadi Salim'" , References: In-Reply-To: Date: Wed, 3 Jul 2013 16:33:31 +0300 Message-ID: <00ab01ce77f1$e9d6df80$bd849e80$@com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00AC_01CE780B.0F241780" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac533ARcqK95pf1SRjSlwBb0JGN+EAAFIpOg Content-Language: el Subject: Re: [forces] LFB properties X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jul 2013 13:40:16 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_00AC_01CE780B.0F241780 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Greetings Jamal, I think this is a useful info to have, but I think we may have some issues. Firstly, I'm unsure of whether statistics may be properties from a model point of view. Secondly, I think we'll have an addressing problem. If you define LFB properties how will you get that property? Main Header -> LFB Selector (Class/Instance) -> Operation TLV (Get Prop) Unless we have only one property this will work. But what if we have more than one, you'll need to add a Path Data TLV. This will create an ambiguity of whether that Path Data refers to either a component or the LFB itself. Regards, Evangelos Haleplidis. From: forces-bounces@ietf.org [mailto:forces-bounces@ietf.org] On Behalf Of Jamal Hadi Salim Sent: Wednesday, July 03, 2013 1:56 PM To: forces@ietf.org Subject: [forces] LFB properties This is a request in relation to the model extension draft. Often when debugging issues between CE and FE we are interested in finding sent/received messages/errors per LFB instance at each layer in the NE cluster. i.e i want to find out for each FE what each LFB instance has in terms of stats in its communication to the CE. This has nothing to do with what such an LFB would have in its data part stats (which should be part of the model for the specific LFB). Our implementation experience indicates we need this for every LFB without exception. While currently we are doing this through some management interface - I would like to propose an "LFB property" (just like we have Table properties) which would have simple stats per LFB instance. The stats are: send {pkts, bytes, errors} and receive {pkts, bytes, errors} Thoughts? cheers, jamal ------=_NextPart_000_00AC_01CE780B.0F241780 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Greetings Jamal,

 

I think this is a useful info to have, but I think we may have some = issues.

 

Firstly, I’m unsure of whether statistics may be properties = from a model point of view.

 

Secondly, I think we’ll have an addressing = problem.

If you define LFB properties how will you get that = property?

 

Main Header -> LFB Selector (Class/Instance) -> Operation TLV = (Get Prop)

Unless we have only one property this will = work.

But what if we have more than one, you’ll need to add a Path = Data TLV.

This will create an ambiguity of whether that Path Data refers to = either a component or the LFB itself.

 

Regards,

Evangelos Haleplidis.

 

From:= = forces-bounces@ietf.org [mailto:forces-bounces@ietf.org] On Behalf Of = Jamal Hadi Salim
Sent: Wednesday, July 03, 2013 1:56 = PM
To: forces@ietf.org
Subject: [forces] LFB = properties

 

 

This = is a request in relation to the model extension = draft.

 

Often when debugging issues between CE and FE we are = interested in

finding = sent/received messages/errors per LFB instance at = each

layer in the NE = cluster. 

i.e i want = to find out for each FE what each LFB instance = has

in terms of stats in = its communication to the CE. This has = nothing

to do with what = such an LFB would have in its data part stats = (which

should be part of = the model for the specific LFB).

 

Our implementation experience indicates we need this = for every LFB

without = exception. While currently we are doing this through = some 

management = interface - I would like to propose an "LFB = property"

(just like = we have Table properties) which would have simple = stats

per LFB instance. = The stats are:

send {pkts, = bytes, errors} and receive {pkts, bytes, = errors}

 

Thoughts?

 

cheers,

jamal

------=_NextPart_000_00AC_01CE780B.0F241780-- From hadi@mojatatu.com Wed Jul 3 07:24:00 2013 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 477F021F9C1E for ; Wed, 3 Jul 2013 07:24:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.916 X-Spam-Level: X-Spam-Status: No, score=-102.916 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, 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 f+bm8xFfOeDN for ; Wed, 3 Jul 2013 07:23:55 -0700 (PDT) Received: from mail-vb0-f43.google.com (mail-vb0-f43.google.com [209.85.212.43]) by ietfa.amsl.com (Postfix) with ESMTP id CD6C321F9C2A for ; Wed, 3 Jul 2013 07:23:54 -0700 (PDT) Received: by mail-vb0-f43.google.com with SMTP id e12so160495vbg.2 for ; Wed, 03 Jul 2013 07:23:53 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=4CHlu8mhoVSv6PVEpWwGQWFtfdMjjrxp1X7LZsqGoT8=; b=LGgva3LuWpNZ29xnc7lGm1vofMn+HXbNcnwFJ67JVpx4a0zQ+rOlZlhBd84XMywVV5 zGnGB7zt0/LbzSDOxkArz8j1VU/hJ1wu6z7dOmByFxt549MEeq9jDVFNkZMxrtRlTYbz hnuCopsLqkPcoHhv8qtpBHpxjVEWyqBe2KeMBLdV3cxp9xLCLfOulcF9Egq1A6OE+jFS +OH3qdiKwbUHWkC6YF+WR95E5Daa1wObXdRcKAg2EbwKx0N9ZzTMZ8UykswjO23lGole Y5SlBOcb3fMB2k1pGEwvcEMnF1MVgHBngsvktjXbc1o2iNzrqWdP21ay1R1y0cr2Z140 Yevg== X-Received: by 10.52.94.45 with SMTP id cz13mr325221vdb.9.1372861433109; Wed, 03 Jul 2013 07:23:53 -0700 (PDT) MIME-Version: 1.0 Received: by 10.58.247.197 with HTTP; Wed, 3 Jul 2013 07:23:32 -0700 (PDT) In-Reply-To: <00ab01ce77f1$e9d6df80$bd849e80$@com> References: <00ab01ce77f1$e9d6df80$bd849e80$@com> From: Jamal Hadi Salim Date: Wed, 3 Jul 2013 10:23:32 -0400 Message-ID: To: Haleplidis Evangelos Content-Type: multipart/alternative; boundary=bcaec50162d10bfa5204e09c361e X-Gm-Message-State: ALoCoQl8VF8DehUTj1t14h8C30muDoWOISUmJccx/E4fapvuuHg9MRcCT6yDitrfUc4rtrvnafN6 Cc: "forces@ietf.org" Subject: Re: [forces] LFB properties X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jul 2013 14:24:00 -0000 --bcaec50162d10bfa5204e09c361e Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Greetings Evangelos, On Wed, Jul 3, 2013 at 9:33 AM, Haleplidis Evangelos wrot= e: > Greetings Jamal,**** > > ** ** > > I think this is a useful info to have, but I think we may have some issue= s. > **** > > ** ** > > Firstly, I=92m unsure of whether statistics may be properties from a mode= l > point of view.**** > > ** > >From a purist view, I agree that properties belong to components and LFB instances are not exactly components. However: Given that ForCES LFB instance stats are always going to be needed this could be looked at as an attribute of the LFB instance. We represent attributes as properties. So I would argue it would be reasonable to have LFB properties. > ** > > Secondly, I think we=92ll have an addressing problem.**** > > If you define LFB properties how will you get that property?**** > > ** ** > > Main Header -> LFB Selector (Class/Instance) -> Operation TLV (Get Prop) = * > *** > > Unless we have only one property this will work.**** > > But what if we have more than one, you=92ll need to add a Path Data TLV.*= *** > > This will create an ambiguity of whether that Path Data refers to either = a > component or the LFB itself.**** > > ** > Good point. We should mandate that LFB instance properties cannot be in the form of a struct. i.e it should be a flat space. So a GETPROP to /FE/2/LFB class X/instance 10/1 will return property 1 (which in this case would be stats). It would be ambigous if we had a path of: GETPROP to /FE/2/LFB class X/instance 10/1/1 because that could be intepreted to mean the property id 1 of component ID 1. cheers, jamal --bcaec50162d10bfa5204e09c361e Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
Greetings Evangelos,


On Wed, Jul 3, 2013 at 9:33 AM, Haleplidis Evangelo= s <ehalep@gmail.com> wrote:

Greetings Jamal,

=A0

I think this is a useful info to have,= but I think we may have some issues.

=A0

Firstly, I=92m unsure of whether stati= stics may be properties from a model point of view.

=A0

<= br>

From a purist view, I agree that properties be= long to components and
LFB instances are not exactly components. However:
Given tha= t ForCES LFB instance stats are always going to be needed this could be
looked at as an attribute of the LFB instance. We represent attribut= es as properties.
So I would argue it would be reasonable to have LFB properties.
<= div>
=A0=A0

Sec= ondly, I think we=92ll have an addressing problem.

If you define LFB properties how will = you get that property?

=A0

Main Header -> LFB Selector (Class/= Instance) -> Operation TLV (Get Prop)

Unless we have only one property this will work.<= /u>

But what if we ha= ve more than one, you=92ll need to add a Path Data TLV.

This will create an ambiguity of wheth= er that Path Data refers to either a component or the LFB itself.=

=A0



Good point.
We should = mandate that LFB instance properties cannot be in the form of a struct.
i.e it should be a flat space.
So a GETPROP to /FE/2/LFB cla= ss X/instance 10/1
will return property 1 (which in this case wou= ld be stats).
It would be ambigous if we had a path of:

GETPROP to /FE/2/LFB class X/instance 10/1/1=A0
because that could be intepreted to mean the property id 1 of compon= ent ID 1.


cheers,
jamal
--bcaec50162d10bfa5204e09c361e-- From ehalep@gmail.com Wed Jul 3 15:02:23 2013 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3208221F9CFB for ; Wed, 3 Jul 2013 15:02:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 QHhuovxH7aGw for ; Wed, 3 Jul 2013 15:02:21 -0700 (PDT) Received: from mail-ee0-x230.google.com (mail-ee0-x230.google.com [IPv6:2a00:1450:4013:c00::230]) by ietfa.amsl.com (Postfix) with ESMTP id 4DA7A11E823E for ; Wed, 3 Jul 2013 15:02:14 -0700 (PDT) Received: by mail-ee0-f48.google.com with SMTP id b47so371445eek.35 for ; Wed, 03 Jul 2013 15:01:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:x-mailer:thread-index:content-language; bh=pewrq7yiAquyr5dWKbtv4p2YHKydT76fgMqqZMUZJbo=; b=ibjVCaLnRjnjAIIz3WwCbFuhBkmasw4X1rFxBU1oXNaJT/P7b0hC8Cfj2uzG9xkUve 7ThamF9AHdXxnhhMHgKS0+9Opg4RuQ/S0/obPb22qApueWpG3UbDlSTN0DbfOlEJWziz M2mJ1lVPrO2GAuxAIarsiywMGxIiGFgPmbwg2Vc5Xw8dEG7rDfTroZ8xwKZdNhRgPNew GmuurBiGObYWw+d9Jf2Ah7DcspRSRXCnGb8WVADCx5kF0MBax41m7oWzPL3wSZ/Hq8zd tNOrMNexS38PN665AqY/rRmUBovIQFJagh01CUBYMG9acJTbihOyUvWSXj5oirUQM/dk 2LHw== X-Received: by 10.15.65.8 with SMTP id p8mr3132725eex.110.1372888913363; Wed, 03 Jul 2013 15:01:53 -0700 (PDT) Received: from EhalepXPS (ppp141237019128.access.hol.gr. [141.237.19.128]) by mx.google.com with ESMTPSA id n5sm81810eed.9.2013.07.03.15.01.51 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Wed, 03 Jul 2013 15:01:52 -0700 (PDT) From: "Haleplidis Evangelos" To: "'Jamal Hadi Salim'" References: <00ab01ce77f1$e9d6df80$bd849e80$@com> In-Reply-To: Date: Thu, 4 Jul 2013 01:01:47 +0300 Message-ID: <00f101ce7838$ead7dc80$c0879580$@com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00F2_01CE7852.10251480" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac53+PI8YNTUeD5tSHyJ0gFlGpOd4gABiz7w Content-Language: el Cc: forces@ietf.org Subject: Re: [forces] LFB properties X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jul 2013 22:02:23 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_00F2_01CE7852.10251480 Content-Type: text/plain; charset="iso-8859-7" Content-Transfer-Encoding: quoted-printable Greetings Jamal, Firstly, I'm unsure of whether statistics may be properties from a model point of view. >From a purist view, I agree that properties belong to components and LFB instances are not exactly components. However: Given that ForCES LFB instance stats are always going to be needed this could be looked at as an attribute of the LFB instance. We represent attributes = as properties. So I would argue it would be reasonable to have LFB properties. =20 [=C5=C7] It is reasonable for LFB to have properties.=20 It'd be good, if possible, to get some views for other people as well in regards to having LFB stats as properties. We can discuss this as well at the meeting. =20 This will create an ambiguity of whether that Path Data refers to either = a component or the LFB itself. Good point. We should mandate that LFB instance properties cannot be in the form of = a struct. i.e it should be a flat space. So a GETPROP to /FE/2/LFB class X/instance 10/1 will return property 1 (which in this case would be stats). It would be ambigous if we had a path of: =20 GETPROP to /FE/2/LFB class X/instance 10/1/1=20 because that could be intepreted to mean the property id 1 of component = ID 1. =20 [=C5=C7] It would mean that we don't allow structs and arrays as well.=20 That would indeed solve the problem of ambiguity, but it's a bit = limiting in a model perspective.=20 And I guess these LFB properties should be optional as well. =20 cheers, jamal =20 Regards, Evangelos Haleplidis. ------=_NextPart_000_00F2_01CE7852.10251480 Content-Type: text/html; charset="iso-8859-7" Content-Transfer-Encoding: quoted-printable

Greetings Jamal,

Firstly, I’m unsure of whether statistics may be properties = from a model point of view.

From a purist view, I agree that = properties belong to components and

LFB instances are not exactly components. = However:

Given that ForCES = LFB instance stats are always going to be needed this could = be

looked at as an = attribute of the LFB instance. We represent attributes as = properties.

So I would = argue it would be reasonable to have LFB = properties.

 

[=C5=C7] It is reasonable for LFB to have properties. =

It’d be good, if possible, to get some views for other people = as well in regards to having LFB stats as = properties.

We can discuss this as well at the meeting.

  

This will create an ambiguity of whether that Path Data refers to = either a component or the LFB itself.

Good point.

We should mandate that LFB instance properties cannot = be in the form of a struct.

i.e it should be a flat = space.

So a GETPROP to = /FE/2/LFB class X/instance 10/1

will return property 1 (which in this case would be = stats).

It would be = ambigous if we had a path of:

 

GETPROP to /FE/2/LFB class X/instance = 10/1/1 

because that = could be intepreted to mean the property id 1 of component ID = 1.

 

[=C5=C7] It would mean that we don’t allow structs and arrays = as well.

That would indeed solve the problem of ambiguity, but it’s a = bit limiting in a model perspective.

And I guess these LFB properties should be optional as = well.

 

cheers,

jamal

 

Regards,

Evangelos Haleplidis.

------=_NextPart_000_00F2_01CE7852.10251480-- From hadi@mojatatu.com Fri Jul 5 03:30:15 2013 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34D3911E827A for ; Fri, 5 Jul 2013 03:30:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.921 X-Spam-Level: X-Spam-Status: No, score=-102.921 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, 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 1qk-0JYoFbZH for ; Fri, 5 Jul 2013 03:30:10 -0700 (PDT) Received: from mail-vc0-f182.google.com (mail-vc0-f182.google.com [209.85.220.182]) by ietfa.amsl.com (Postfix) with ESMTP id EA75221F8459 for ; Fri, 5 Jul 2013 03:30:09 -0700 (PDT) Received: by mail-vc0-f182.google.com with SMTP id id13so1526637vcb.27 for ; Fri, 05 Jul 2013 03:30:09 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=lpl6eomRzNyNx/XFWsMUIPasixrTyeDiWzPNtCL22DU=; b=pg4fucZ3MPAlIPXqh7FafpmHn4pCvWlZH4EIe9Y4q7kpCXRqtDGtTf7BNUlvi96q/x BGy7x3Uyw82LlN91k5sXPHG6Xaj+PAPoNtlWFCyLI5XwzxM++/Bh0fIVFUGTHY/rldv2 Uj77nZWyXQSPbaIYPgIJbtyvU5dF26YoqGnCIRaVwxgLjD8VvqdeN7Ga0XHAZfY7LtHW COjrfS6T8mT4kS0lmMbDGdJdo8IgTBmpAhBJJlplSom+xIairDngMtb52LSAKBlG/qck Nqgy2ATPact9gIO+FKih1WSGav9AIEZl3z/rjA/5xNc0D0anox6iSoCqHs6aFzCbtQhM 0A3Q== X-Received: by 10.52.92.16 with SMTP id ci16mr5044506vdb.88.1373020209262; Fri, 05 Jul 2013 03:30:09 -0700 (PDT) MIME-Version: 1.0 Received: by 10.58.245.71 with HTTP; Fri, 5 Jul 2013 03:29:49 -0700 (PDT) In-Reply-To: <00f101ce7838$ead7dc80$c0879580$@com> References: <00ab01ce77f1$e9d6df80$bd849e80$@com> <00f101ce7838$ead7dc80$c0879580$@com> From: Jamal Hadi Salim Date: Fri, 5 Jul 2013 06:29:49 -0400 Message-ID: To: Haleplidis Evangelos Content-Type: multipart/alternative; boundary=20cf307d0648d7c52b04e0c12dec X-Gm-Message-State: ALoCoQmUV2ApxWulIpGP+WwIYvOuTKfzVtSyXVfg+rVSekwKOXBzUNhU9Id19Tqn/Fmpd6vI6ZDN Cc: "forces@ietf.org" Subject: Re: [forces] LFB properties X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jul 2013 10:30:15 -0000 --20cf307d0648d7c52b04e0c12dec Content-Type: text/plain; charset=ISO-8859-7 Content-Transfer-Encoding: quoted-printable Greetings Evangelos, On Wed, Jul 3, 2013 at 6:01 PM, Haleplidis Evangelos wrot= e: > > *[=C5=C7] It is reasonable for LFB to have properties. * > > *It=A2d be good, if possible, to get some views for other people as well = in > regards to having LFB stats as properties.* > > *We can discuss this as well at the meeting.***** > > Indeed - are you able to add this to the model extension draft? > *[=C5=C7] It would mean that we don=A2t allow structs and arrays as well= . * > > *That would indeed solve the problem of ambiguity, but it=A2s a bit > limiting in a model perspective. * > > *And I guess these LFB properties should be optional as well.***** > > ** > All our properties are currently non-complex. I guess we've never had to think about justifying that until now. cheers, jamal --20cf307d0648d7c52b04e0c12dec Content-Type: text/html; charset=ISO-8859-7 Content-Transfer-Encoding: quoted-printable
Greetings Evangelos,

On Wed, Jul 3, 2013 at 6:01 PM, Haleplidis Evangelos <e= halep@gmail.com> wrote:


[=C5=C7] It is reasonable f= or LFB to have properties.

It=A2d be good, if possible= , to get some views for other people as well in regards to having LFB stats= as properties.

We c= an discuss this as well at the meeting.



=
Indeed - are you able to add this to the model extension draft?<= /div>
=A0

[=C5= =C7] It would mean that we don=A2t allow structs and arrays as well.

That= would indeed solve the problem of ambiguity, but it=A2s a bit limiting in = a model perspective.

And = I guess these LFB properties should be optional as well.


All our properties are cur= rently non-complex. I guess we've never had to think about justifying= =A0
that until now.

cheers,
jamal
=
--20cf307d0648d7c52b04e0c12dec-- From hadi@mojatatu.com Fri Jul 5 03:36:39 2013 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18EF611E827C for ; Fri, 5 Jul 2013 03:36:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.926 X-Spam-Level: X-Spam-Status: No, score=-102.926 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, 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 G9gdfu9NF5cx for ; Fri, 5 Jul 2013 03:36:35 -0700 (PDT) Received: from mail-vb0-f49.google.com (mail-vb0-f49.google.com [209.85.212.49]) by ietfa.amsl.com (Postfix) with ESMTP id CBE1011E827A for ; Fri, 5 Jul 2013 03:36:34 -0700 (PDT) Received: by mail-vb0-f49.google.com with SMTP id 12so1565859vbf.8 for ; Fri, 05 Jul 2013 03:36:34 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type:x-gm-message-state; bh=q0iF34ECdNfDZGuD71rxxDT6BWdCqzimqQlTGItzA88=; b=Cg9VKZbc4x2KP8aRZ8jd0WdJ8ONFpJAp6RRApkZyvxPB/K0T6jYrbN3fDkAvUVfEH2 8WGA2zUeiR2lNCJM+dNdCR3owqqXLHuTa+C57EUVmWwHuXLW0VT90CdoDmjTCNsnnIsc K4j45mJaiUhWeATk5e38zwwwJKimwUP41a2I+L+NgPFpsjgQMER1DXsZ3ft701p2lyEb fDCkjIZdtU5O01eBpE0CV98OVqvIrYeEZefg0kF8xafx9+3YS/jDtoSJm3MayAiqyJxo Gm928vRR+ev9lKC8BFfd7tKcBr/qW5OfZyE3qRtiGORsknuS6Wn39fJU48yB4Bc0kF5J IluQ== X-Received: by 10.58.128.71 with SMTP id nm7mr6255750veb.51.1373020594072; Fri, 05 Jul 2013 03:36:34 -0700 (PDT) MIME-Version: 1.0 Received: by 10.58.245.71 with HTTP; Fri, 5 Jul 2013 03:36:14 -0700 (PDT) In-Reply-To: <20130705102551.9194.35626.idtracker@ietfa.amsl.com> References: <20130705102551.9194.35626.idtracker@ietfa.amsl.com> From: Jamal Hadi Salim Date: Fri, 5 Jul 2013 06:36:14 -0400 Message-ID: To: "forces@ietf.org" Content-Type: multipart/alternative; boundary=047d7b60518cc7802e04e0c144c6 X-Gm-Message-State: ALoCoQn76L0GtfL+81VGhZQVGx29/9Ofvs2BkhKEWJp6aevMU7BmnrNwDWS20TNZ/kClqxTEo3d2 Subject: [forces] Fwd: New Version Notification for draft-jhs-forces-protoextenstion-01.txt X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jul 2013 10:36:39 -0000 --047d7b60518cc7802e04e0c144c6 Content-Type: text/plain; charset=ISO-8859-1 updated version of the protocol extension draft. cheers, jamal ---------- Forwarded message ---------- From: Date: Fri, Jul 5, 2013 at 6:25 AM Subject: New Version Notification for draft-jhs-forces-protoextenstion-01.txt To: Jamal Hadi Salim A new version of I-D, draft-jhs-forces-protoextenstion-01.txt has been successfully submitted by Jamal Hadi Salim and posted to the IETF repository. Filename: draft-jhs-forces-protoextenstion Revision: 01 Title: ForCES Protocol Extensions Creation date: 2013-07-05 Group: Individual Submission Number of pages: 10 URL: http://www.ietf.org/internet-drafts/draft-jhs-forces-protoextenstion-01.txt Status: http://datatracker.ietf.org/doc/draft-jhs-forces-protoextenstion Htmlized: http://tools.ietf.org/html/draft-jhs-forces-protoextenstion-01 Diff: http://www.ietf.org/rfcdiff?url2=draft-jhs-forces-protoextenstion-01 Abstract: Experience in implementing and deploying ForCES architecture has demonstrated need for a few small extensions both to ease programmability and to improve wire efficiency of some transactions. This document describes a few extensions to the ForCES Protocol Specification [RFC5810] semantics to achieve that end goal. The IETF Secretariat --047d7b60518cc7802e04e0c144c6 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
updated version of the protocol extension draft.

<= /div>
cheers,
jamal

--= -------- Forwarded message ----------
From: <in= ternet-drafts@ietf.org>
Date: Fri, Jul 5, 2013 at 6:25 AM
Subject: New Version Notification for = draft-jhs-forces-protoextenstion-01.txt
To: Jamal Hadi Salim <hadi@mojatatu.com>



A new version of I-D, draft-jhs-forces-protoextenstion-01.txt
has been successfully submitted by Jamal Hadi Salim and posted to the
IETF repository.

Filename: =A0 =A0 =A0 =A0draft-jhs-forces-protoextenstion
Revision: =A0 =A0 =A0 =A001
Title: =A0 =A0 =A0 =A0 =A0 ForCES Protocol Extensions
Creation date: =A0 2013-07-05
Group: =A0 =A0 =A0 =A0 =A0 Individual Submission
Number of pages: 10
URL: =A0 =A0 =A0 =A0 =A0 =A0 http://www.ietf= .org/internet-drafts/draft-jhs-forces-protoextenstion-01.txt
Status: =A0 =A0 =A0 =A0 =A0http://datatracker.ietf.org/= doc/draft-jhs-forces-protoextenstion
Htmlized: =A0 =A0 =A0 =A0http://tools.ietf.org/html/draft= -jhs-forces-protoextenstion-01
Diff: =A0 =A0 =A0 =A0 =A0 =A0http://www.ietf.org/= rfcdiff?url2=3Ddraft-jhs-forces-protoextenstion-01

Abstract:
=A0 =A0Experience in implementing and deploying ForCES architecture has
=A0 =A0demonstrated need for a few small extensions both to ease
=A0 =A0programmability and to improve wire efficiency of some transactions.=
=A0 =A0This document describes a few extensions to the ForCES Protocol
=A0 =A0Specification [RFC5810] semantics to achieve that end goal.




The IETF Secretariat


--047d7b60518cc7802e04e0c144c6-- From ehalep@gmail.com Mon Jul 8 09:57:16 2013 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC54F21F9C41 for ; Mon, 8 Jul 2013 09:57:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 FVQtENPTrqi4 for ; Mon, 8 Jul 2013 09:57:16 -0700 (PDT) Received: from mail-ea0-x22b.google.com (mail-ea0-x22b.google.com [IPv6:2a00:1450:4013:c01::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 92F6521F9C70 for ; Mon, 8 Jul 2013 09:56:53 -0700 (PDT) Received: by mail-ea0-f171.google.com with SMTP id m14so3051839eaj.16 for ; Mon, 08 Jul 2013 09:56:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:date:message-id:mime-version:content-type :content-transfer-encoding:x-mailer:thread-index:content-language; bh=1tf0osuoqlRp806PP42bbKmjD0eG9NL9OcPr4EvXR5k=; b=frfETszde6SjcK5hJDJvlM16JQ/irho6aJmxD3UC0VyyRDup2Lmg7yoxPNzrfkyRNr TmF00qOak2oSb4vdE4Scen5gfNpK97/74fHJHQU057+V/litmV1uGZ/8K1UmO1Ov0UAS ly2zLxyEQ7XBqBDVgyx0ChNK8yMDyhVcXSMObrtM4AcWCn/Kdc2gnxxMR2AO5VzHTc3x EOJy9Bwp1nXVnulmURDczU1RLtT0qXVesnWRQL4ONi8+SocDjmUPlp/Pqo3YDBOJneAr c04QYWW6TTeXchNP1O8v327OXeEItEp1qrg0CFjFQMJw/R9WhsaGjDpmC3GMi16XNopW ph4A== X-Received: by 10.15.94.142 with SMTP id bb14mr25924574eeb.112.1373302612598; Mon, 08 Jul 2013 09:56:52 -0700 (PDT) Received: from EhalepXPS (ppp079166033096.access.hol.gr. [79.166.33.96]) by mx.google.com with ESMTPSA id o5sm43598131eef.5.2013.07.08.09.56.51 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Mon, 08 Jul 2013 09:56:52 -0700 (PDT) From: "Haleplidis Evangelos" To: Date: Mon, 8 Jul 2013 19:56:49 +0300 Message-ID: <002c01ce7bfc$248cdef0$6da69cd0$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac57/wKNkBVU9ezDSYOggyiqbGFGdQAA5FXQ Content-Language: el Subject: [forces] FW: New Version Notification for draft-haleplidis-forces-model-extension-04.txt X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jul 2013 16:57:17 -0000 Greetings to the list, Just updated the forces model extensions draft. Included is Jamal's request for LFB properties. The document is also slightly restructured for readability. Regards, Evangelos Haleplidis. > -----Original Message----- > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > Sent: Monday, July 08, 2013 7:52 PM > To: Evangelos Haleplidis > Subject: New Version Notification for draft-haleplidis-forces-model- > extension-04.txt >=20 >=20 > A new version of I-D, draft-haleplidis-forces-model-extension-04.txt > has been successfully submitted by Evangelos Haleplidis and posted to > the IETF repository. >=20 > Filename: draft-haleplidis-forces-model-extension > Revision: 04 > Title: ForCES Model Extension > Creation date: 2013-07-08 > Group: Individual Submission > Number of pages: 26 > URL: = http://www.ietf.org/internet-drafts/draft-haleplidis-forces-model-extensi= on-04.txt > Status: = http://datatracker.ietf.org/doc/draft-haleplidis-forces-model-extension > Htmlized: = http://tools.ietf.org/html/draft-haleplidis-forces-model-extension-04 > Diff: = http://www.ietf.org/rfcdiff?url2=3Ddraft-haleplidis-forces-model-extensio= n-04 >=20 > Abstract: > Forwarding and Control Element Separation (ForCES) defines an > architectural framework and associated protocols to standardize > information exchange between the control plane and the forwarding > plane in a ForCES Network Element (ForCES NE). RFC5812 has defined > the ForCES Model provides a formal way to represent the > capabilities, > state, and configuration of forwarding elements within the context > of > the ForCES protocol, so that control elements (CEs) can control the > FEs accordingly. More specifically, the model describes the = logical > functions that are present in an FE, what capabilities these > functions support, and how these functions are or can be > interconnected. >=20 > RFC5812 has been around for two years and experience in its use has > shown room for small extensions without a need to alter the = protocol > while retaining backward compatibility with older xml libraries. > This document extends the model to allow complex datatypes for > metadata, optional default values for datatypes and optional access > types for structures. The document also introduces three new > features, bitmap as a new datatype, a new event condition > BecomesEqualTo and LFB properties. >=20 >=20 >=20 >=20 > The IETF Secretariat From damascene.joachimpillai@verizon.com Fri Jul 12 09:03:38 2013 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F44A11E80FE for ; Fri, 12 Jul 2013 09:03:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.109 X-Spam-Level: X-Spam-Status: No, score=-2.109 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, HTML_MESSAGE=0.001, 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 4Bno2IyUg0Rc for ; Fri, 12 Jul 2013 09:03:34 -0700 (PDT) Received: from fldsmtpe01.verizon.com (fldsmtpe01.verizon.com [140.108.26.140]) by ietfa.amsl.com (Postfix) with ESMTP id BED2621F9A18 for ; Fri, 12 Jul 2013 09:03:33 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: false Received: from unknown (HELO fldsmtpi01.verizon.com) ([166.68.71.143]) by fldsmtpe01.verizon.com with ESMTP; 12 Jul 2013 16:03:25 +0000 From: "Joachimpillai, Damascene M" X-IronPort-AV: E=Sophos;i="4.89,654,1367971200"; d="scan'208,217";a="515970881" Received: from fhdp1lumxc7hb05.verizon.com (HELO FHDP1LUMXC7HB05.us.one.verizon.com) ([166.68.59.192]) by fldsmtpi01.verizon.com with ESMTP; 12 Jul 2013 16:03:25 +0000 Received: from FHDP1LUMXC7V31.us.one.verizon.com ([166.68.125.32]) by FHDP1LUMXC7HB05.us.one.verizon.com ([166.68.59.192]) with mapi; Fri, 12 Jul 2013 12:03:25 -0400 To: "forces@ietf.org" Date: Fri, 12 Jul 2013 12:03:24 -0400 Thread-Topic: [ForCES] Draft planned for WG Adoption Thread-Index: Ac5/FyvChrbDrODvSk+eI1wlD+9OFw== Message-ID: <689CE984BDBA8B4CAF3EA6E2CDC5CACB01213ECF63@FHDP1LUMXC7V31.us.one.verizon.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_689CE984BDBA8B4CAF3EA6E2CDC5CACB01213ECF63FHDP1LUMXC7V3_" MIME-Version: 1.0 Subject: [forces] [ForCES] Draft planned for WG Adoption X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jul 2013 16:03:38 -0000 --_000_689CE984BDBA8B4CAF3EA6E2CDC5CACB01213ECF63FHDP1LUMXC7V3_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi All, We have the following drafts planned for ForCES WG Adoption: draft-haleplidis-forces-model-extension-04 draft-jhs-forces-protoextenstion-01 We would like to invite any comments as to the adoption of these documents = as WG documents within the ForCES charter. Since the WG is under a tight time constraints we would like to close all = comments by the week of August 5th. Thank you for your time and cooperation. Regards, DJ Damascene M Joachimpillai (DJ) Systems Engineering, Internet Software and Technology Group | Verizon Corpo= rate Technology Tel: +1 781 466 1619 | Mob: +1 781 999 4620 60 Sylvan Drive, Waltham, MA, 02451, USA Visit us at verizon.com/ Click here to Manage Your Account Online Twitter | Facebook | YouTube | LinkedIn --_000_689CE984BDBA8B4CAF3EA6E2CDC5CACB01213ECF63FHDP1LUMXC7V3_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi All,

 

We hav= e the following drafts planned for ForCES WG Adoption:

 

draft-ha= leplidis-forces-model-extension-04

<= a href=3D"http://datatracker.ietf.org/doc/draft-jhs-forces-protoextenstion/= ">draft-jhs-forces-protoextenstion-01

 

We would like to invite any com= ments as to the adoption of these documents as WG documents within the ForC= ES charter.  

 

=

Since the WG  is under a tight time constraints w= e would like to close all comments  by the week of August 5th.

 

Thank= you for your time and cooperation.

 

Regards,

DJ

Damascene M Joachimpillai (DJ)

Systems Engineering, Internet Software= and Technology Group | Verizon Co= rporate Technology

Tel: +1 781 466 = 1619 | Mob: +1 781 999 4620

60 Sylvan Drive, Waltham, MA, 02451, USA

 = ;

=  

= Visit us at verizon.com/=

Click here to Manage Your Account Online

 

 

= Twitter  |  Facebook   |  YouTube   |  LinkedIn

 

= --_000_689CE984BDBA8B4CAF3EA6E2CDC5CACB01213ECF63FHDP1LUMXC7V3_-- From hadi@mojatatu.com Fri Jul 12 09:08:49 2013 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A669521F9D8A for ; Fri, 12 Jul 2013 09:08:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.936 X-Spam-Level: X-Spam-Status: No, score=-102.936 tagged_above=-999 required=5 tests=[AWL=0.040, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, 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 mFg698zZXfof for ; Fri, 12 Jul 2013 09:08:44 -0700 (PDT) Received: from mail-vb0-f52.google.com (mail-vb0-f52.google.com [209.85.212.52]) by ietfa.amsl.com (Postfix) with ESMTP id 7C4B221F9C2E for ; Fri, 12 Jul 2013 09:08:44 -0700 (PDT) Received: by mail-vb0-f52.google.com with SMTP id f12so1687524vbg.11 for ; Fri, 12 Jul 2013 09:08:43 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type :x-gm-message-state; bh=UqS+hQFRt4m16ogkgk1sT4zTm110mkTyDeL/RHD7hhw=; b=KbUaZc8fF9QQ9J07j5RcKzDT1RYYj71WkSyJ2J2eX0vGQJR9nOuSeUPka2j1DJ0wQL mvZlfu9qCc8C9dbt8X+9DjJmiN7qAh+fzH/T6YWOwwp4StAGVEnACchoSUSdpNi3pehs Oy8bGWXF3vEaPDQ+TamDrbr2freDLQQMFMq74vCIFKE3iS1f+DoXdDumgzcl+n2YyNBX BbBh275ZbGzwaT2Ni2XJf4Bfy3dDDZ269jrB92WCvdocgtfhcnSfKqR+My8W5PKZI6tq 7uk3PnqLO3obI1XtZQvJHzDFzL9jDukE97qR6lvdJ/WyOoyJx+TQoaUSmv1LVR/8zh5P KGXA== X-Received: by 10.52.186.129 with SMTP id fk1mr20544931vdc.66.1373645323841; Fri, 12 Jul 2013 09:08:43 -0700 (PDT) MIME-Version: 1.0 Received: by 10.58.247.197 with HTTP; Fri, 12 Jul 2013 09:08:23 -0700 (PDT) From: Jamal Hadi Salim Date: Fri, 12 Jul 2013 12:08:23 -0400 Message-ID: To: "forces@ietf.org" Content-Type: multipart/alternative; boundary=bcaec547c84f93428a04e152b944 X-Gm-Message-State: ALoCoQngZjXynUzhO2+FvRqG6XL3VOc23Yt6OZG1//uDqHxlKLCKYtcS1fhGavy+IcZw9pfIvT14 Subject: [forces] Subsidiary Management X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jul 2013 16:08:49 -0000 --bcaec547c84f93428a04e152b944 Content-Type: text/plain; charset=ISO-8859-1 The chairs would like to invite presentation or drafts on Subsidiary management LFB. In particular people who expressed interest, please followup. cheers, jamal --bcaec547c84f93428a04e152b944 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
The chairs would like to invite presentation or drafts on<= div>Subsidiary management LFB. In particular people who=A0
ex= pressed interest, please followup.

cheers,
jamal
--bcaec547c84f93428a04e152b944-- From vumip1@gmail.com Fri Jul 12 15:44:40 2013 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2AFE621F9F8F for ; Fri, 12 Jul 2013 15:44:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] 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 9QFYUcT7zhT5 for ; Fri, 12 Jul 2013 15:44:34 -0700 (PDT) Received: from mail-we0-x22e.google.com (mail-we0-x22e.google.com [IPv6:2a00:1450:400c:c03::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 77F9521F9EE8 for ; Fri, 12 Jul 2013 15:44:23 -0700 (PDT) Received: by mail-we0-f174.google.com with SMTP id q58so8626674wes.33 for ; Fri, 12 Jul 2013 15:44:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=RKxqkIZWGfKu8uZMAIBW/qjICipgLaZd3Emd803hhdo=; b=ziP4vMCReUgdo0zNdg0zfKIoLWFVX8KgbGTHHBsRyCAsGNGKAXU5u4xcqYl4gm3E2b Md/9JzIQqxlcN1600dTSIvRe7vaoROhGdSPgARbQyWf9J1uI6gi2sQfjbZwH09SluVlp AnnGSz0iIV5v9HizXpA5A8l6Lbp75p4UKwQcJw2CuQe4Nq/fBKAfAFPeWC7tsu0m102X jmZUzXvWmK1YM+qDnNgOMoHr276jTOtJN6OxHnK+0cMhjyCOWnerSdPUXEbVqVgYmZT3 c83Umt1fgpP2WVHSe96hKCrGCFYo+u6ryIp76zv2GTBwkFRHFrbi/IkOJ372Se8DG3cj ZJtw== MIME-Version: 1.0 X-Received: by 10.180.188.36 with SMTP id fx4mr2783103wic.55.1373669062607; Fri, 12 Jul 2013 15:44:22 -0700 (PDT) Received: by 10.216.61.78 with HTTP; Fri, 12 Jul 2013 15:44:22 -0700 (PDT) In-Reply-To: References: Date: Fri, 12 Jul 2013 18:44:22 -0400 Message-ID: From: "B.Khasnabish@ieee.org" To: Jamal Hadi Salim Content-Type: multipart/alternative; boundary=001a11c25cd884089904e1584041 Cc: "forces@ietf.org" Subject: Re: [forces] Subsidiary Management X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jul 2013 22:44:40 -0000 --001a11c25cd884089904e1584041 Content-Type: text/plain; charset=ISO-8859-1 Hello Jamal, PLEASE note that I'll have a short preso on Subsidiary Management. May I have a slot for presenting the slides during IETF87 ForCES mtg. on 30 July 2013. Thanks. Best. Bhumip On Fri, Jul 12, 2013 at 12:08 PM, Jamal Hadi Salim wrote: > The chairs would like to invite presentation or drafts on > Subsidiary management LFB. In particular people who > expressed interest, please followup. > > cheers, > jamal > > _______________________________________________ > forces mailing list > forces@ietf.org > https://www.ietf.org/mailman/listinfo/forces > > --001a11c25cd884089904e1584041 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hello Jamal,
=A0
PLEASE note that I'll have a = short preso
on Subsidiary Management.
=A0
May= I have a slot for presenting the slides
during IETF87 ForCES mtg= . on 30 July 2013.
=A0
Thanks.
=A0
Best.
=A0
Bhumip


=A0
On Fri, = Jul 12, 2013 at 12:08 PM, Jamal Hadi Salim <hadi@mojatatu.com> wrote:
The chairs would like to invite presentat= ion or drafts on
Subsidiary management LFB. In particular people who=A0
expres= sed interest, please followup.

cheers,
jamal

_______________________________________________
forces mailing list
forces@ietf.org
= https://www.ietf.org/mailman/listinfo/forces



=A0
--001a11c25cd884089904e1584041-- From hadi@mojatatu.com Mon Jul 15 03:16:56 2013 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D893B21F9814 for ; Mon, 15 Jul 2013 03:16:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.941 X-Spam-Level: X-Spam-Status: No, score=-102.941 tagged_above=-999 required=5 tests=[AWL=0.035, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, 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 r1vuZ8CLNLNP for ; Mon, 15 Jul 2013 03:16:52 -0700 (PDT) Received: from mail-ve0-f181.google.com (mail-ve0-f181.google.com [209.85.128.181]) by ietfa.amsl.com (Postfix) with ESMTP id D8DF121E8097 for ; Mon, 15 Jul 2013 03:16:47 -0700 (PDT) Received: by mail-ve0-f181.google.com with SMTP id db10so9785199veb.12 for ; Mon, 15 Jul 2013 03:16:47 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type:x-gm-message-state; bh=OMPTZWkrWVFERKIGdAhDD5WH5wrm96xtONL6n6zAPi4=; b=lmM0daGJYWQ/7N2Tw4BxGVVPzHOBNj4uX/I1r30nsjPM7X5Vs6ASi/NuY1G8L5o/nm QcjCCV7mztNMBnatCxT8ZOS8yxmLYPNZ10Af+6lzr9WtsevTieeo3TGoZg1qOg6Ectpv 26vOPPVwh/o9zXdRnRKZIpNaMezB9PN43fGGaqmSopu7DV/NJBA/llBo+hU9+s6mEK/p /Vs1uJ7HIAvevvCVDqRIWNv0qKegy3MmT5QyEYjz4+JSxn/afBwmML3n4Ea0PY1WMASm WVb1qijclghAQwb3mMz4nqzk6lxcpwW3pGH0feFLf2BSk08lRptcaxju8sD2FcQDdlso H6nw== X-Received: by 10.52.18.239 with SMTP id z15mr23512936vdd.109.1373883407092; Mon, 15 Jul 2013 03:16:47 -0700 (PDT) MIME-Version: 1.0 Received: by 10.58.247.197 with HTTP; Mon, 15 Jul 2013 03:16:27 -0700 (PDT) In-Reply-To: <20130715013235.6958.93956.idtracker@ietfa.amsl.com> References: <20130715013235.6958.93956.idtracker@ietfa.amsl.com> From: Jamal Hadi Salim Date: Mon, 15 Jul 2013 06:16:27 -0400 Message-ID: To: "forces@ietf.org" Content-Type: multipart/alternative; boundary=bcaec5040dd671639504e18a2804 X-Gm-Message-State: ALoCoQkZi2FjdfHfQjxfTZ3Dxy1T0kX1VDvZt6ZVvbXev9oUvUcWJblyfAaPunejFsgLmkYNxX+q Subject: [forces] Fwd: New Version Notification for draft-joachimpillai-forces-interfelfb-02.txt X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jul 2013 10:16:57 -0000 --bcaec5040dd671639504e18a2804 Content-Type: text/plain; charset=ISO-8859-1 Update based on discussions from Dave Hood and Joel on the list. ---------- Forwarded message ---------- From: Date: Sun, Jul 14, 2013 at 9:32 PM Subject: New Version Notification for draft-joachimpillai-forces-interfelfb-02.txt To: "Damascane M. Joachimpillai" , Jamal Hadi Salim A new version of I-D, draft-joachimpillai-forces-interfelfb-02.txt has been successfully submitted by Damascane M. Joachimpillai and posted to the IETF repository. Filename: draft-joachimpillai-forces-interfelfb Revision: 02 Title: ForCES Inter-FE LFB Creation date: 2013-07-14 Group: Individual Submission Number of pages: 20 URL: http://www.ietf.org/internet-drafts/draft-joachimpillai-forces-interfelfb-02.txt Status: http://datatracker.ietf.org/doc/draft-joachimpillai-forces-interfelfb Htmlized: http://tools.ietf.org/html/draft-joachimpillai-forces-interfelfb-02 Diff: http://www.ietf.org/rfcdiff?url2=draft-joachimpillai-forces-interfelfb-02 Abstract: Forwarding and Control Element Separation (ForCES) defines an architectural framework and associated protocols to standardize information exchange between the control plane and the forwarding plane in a ForCES Network Element (ForCES NE). RFC5812 has defined the ForCES Model which provides a formal way to represent the capabilities, state, and configuration of forwarding elements(FEs) within the context of the ForCES protocol. More specifically, the model describes the logical functions that are present in an FE, what capabilities these functions support, and how these functions are or can be interconnected. The control elements (CEs) can control the FEs using the ForCES model definition. The ForCES WG charter has been extended to allow the LFB topology to be across FEs. This documents describes a non-intrusive way to extend the LFB topology across FEs. The IETF Secretariat --bcaec5040dd671639504e18a2804 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Update based on discussions from Dave Hood = and Joel on the list.

---------- Forwarde= d message ----------
From: <internet-drafts@ie= tf.org>
Date: Sun, Jul 14, 2013 at 9:32 PM
Subject: New Version Notification for= draft-joachimpillai-forces-interfelfb-02.txt
To: "Damascane M. Joa= chimpillai" <damascene.joachimpillai@verizon.com>, Jamal Hadi Salim <hadi@mojatatu.com>



A new version of I-D, draft-joachimpillai-forces-interfelfb-02.txt
has been successfully submitted by Damascane M. Joachimpillai and posted to= the
IETF repository.

Filename: =A0 =A0 =A0 =A0draft-joachimpillai-forces-interfelfb
Revision: =A0 =A0 =A0 =A002
Title: =A0 =A0 =A0 =A0 =A0 ForCES Inter-FE LFB
Creation date: =A0 2013-07-14
Group: =A0 =A0 =A0 =A0 =A0 Individual Submission
Number of pages: 20
URL: =A0 =A0 =A0 =A0 =A0 =A0 http://www= .ietf.org/internet-drafts/draft-joachimpillai-forces-interfelfb-02.txt<= br> Status: =A0 =A0 =A0 =A0 =A0http://datatracker.ietf= .org/doc/draft-joachimpillai-forces-interfelfb
Htmlized: =A0 =A0 =A0 =A0http://tools.ietf.org/html/= draft-joachimpillai-forces-interfelfb-02
Diff: =A0 =A0 =A0 =A0 =A0 =A0http://www.ietf= .org/rfcdiff?url2=3Ddraft-joachimpillai-forces-interfelfb-02

Abstract:
=A0 =A0Forwarding and Control Element Separation (ForCES) defines an
=A0 =A0architectural framework and associated protocols to standardize
=A0 =A0information exchange between the control plane and the forwarding =A0 =A0plane in a ForCES Network Element (ForCES NE). =A0RFC5812 has define= d
=A0 =A0the ForCES Model which provides a formal way to represent the
=A0 =A0capabilities, state, and configuration of forwarding elements(FEs) =A0 =A0within the context of the ForCES protocol. =A0More specifically, the=
=A0 =A0model describes the logical functions that are present in an FE, wha= t
=A0 =A0capabilities these functions support, and how these functions are or=
=A0 =A0can be interconnected. =A0The control elements (CEs) can control the=
=A0 =A0FEs using the ForCES model definition.

=A0 =A0The ForCES WG charter has been extended to allow the LFB topology to=
=A0 =A0be across FEs. =A0This documents describes a non-intrusive way to =A0 =A0extend the LFB topology across FEs.




The IETF Secretariat


--bcaec5040dd671639504e18a2804-- From adrian@olddog.co.uk Wed Jul 24 01:49:04 2013 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4712511E83DA for ; Wed, 24 Jul 2013 01:49:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_44=0.6] 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 kJyPZkYTqWAe for ; Wed, 24 Jul 2013 01:48:58 -0700 (PDT) Received: from asmtp5.iomartmail.com (asmtp5.iomartmail.com [62.128.201.176]) by ietfa.amsl.com (Postfix) with ESMTP id 4313311E83AE for ; Wed, 24 Jul 2013 01:48:57 -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 r6O8muiw015622; Wed, 24 Jul 2013 09:48:56 +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 r6O8mtNs015594 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 24 Jul 2013 09:48:56 +0100 From: "Adrian Farrel" To: Date: Wed, 24 Jul 2013 09:48:54 +0100 Message-ID: <02b001ce884a$a1585040$e408f0c0$@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: Ac6ISp3ROD3H0VgGQwGFXHrzZAO3EA== Content-Language: en-gb Cc: forces@ietf.org Subject: [forces] AD Review of draft-ietf-forces-ceha X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jul 2013 08:49:04 -0000 Hi, I have done my AD review of your document and see nothing major to hold it back, but there are a large number of nits and a few petty questions. We have a responsibility to send the I-D to IETF last call in the best possible shape so that it gets a good review. Therefore, I have put the I-D into "Revised I-D Needed" state and will issue IETF last call when I see a new revision. Thanks for the work, Adrian === Section 1 Need to fix the 2119 boilerplate to include a reference to [RFC2119] --- Section 1 OLD The following definitions are taken from [RFC3654]and [RFC3746]: NEW The following definitions are taken from [RFC3654] and [RFC3746]. They are repeated here for convenience, but the normative definitions are found in the referenced RFCs. END --- Section 1 o ForCES Protocol -- The protocol used at the Fp reference point in the ForCES Framework in [RFC3746]. You need to explain what "Fp" is. --- Section 1 o ForCES Protocol Layer (ForCES PL) -- A layer in the ForCES architecture that embodies the ForCES protocol and the state transfer mechanisms as defined in [RFC5810]. How can this definition come from 3654 or 3746 when it has a reference to 5810? --- Figure 1 Maybe more normal to use "CEn" rather than "CEN" --- Section 2 The master CE controls the FEs via the ForCES protocol operating in the Fp interface. s/in/on/ --- Section 3 To achieve CE High Availability (HA), FEs and CEs MUST inter-operate per [RFC5810] definition which is repeated for contextual reasons in Section 3.1. While you are repeating some of the material from 5810, you are also restating some of it in new words, and adding text. This gives a real problem with determining where the normative definition sits. We have to fix this! Can you determine which sections are informational for this document and which contain new text? Possibly the whole of Section 3 is just informational. If this is the case you can replace the text quoted above with the following: To achieve CE High Availability (HA), FEs and CEs MUST inter-operate per [RFC5810]. The normative description of cold standby for CE HA is provided in [RFC5810]. This section provides a more wordy description of the procedures and is purely informational. In the event of any discrepancies between this text and that in RFC 5810, the text in RFC 5810 takes precedence. --- Figure 2 Will it be obvious to the reader of this document what is meant by "Asso Estb,Caps exchg" --- Section 3.1.1 "CEID" is used without expansion. Although sometimes I find "CE ID" for example in 3.1.2. --- Section 3.1.1 has The FE connects to the CE specified on FEPO CEID component. If it fails to connect to the defined CE, it moves it to the bottom of table BackupCEs and sets its CEID component to be the first CE retrieved from table BackupCEs. This is not a problem, but is unusual. In many redundancy cases, the primary object remains the favorite even when it has failed so that when there is a restoration opportunity (such as a failure of the new primary) it will resume its position as primary. The question here is perhaps whether there is any distinction between CEs except their role as primary or backup. --- Figure 3 has "CEFTI" without explanation. --- Section 3.1.1 has If the FE's FEPO CE Failover Policy is configured to mode 1, it indicates that the FE will run in HA restart recovery. In such a case, the FE transitions to the Not Associated state and the CEFTI timer [RFC5810] is started. The FE MAY continue to forward packets during this state. This use of "MAY" implies to me that it is at least as common that the FE does not forward packets in this state. Is that the intention? --- Section 3.1.1 "HB" is used without expansion. --- Section 4.2 "CEHB" and "FEHB" are used without expansion --- Need to fix the line-length problems in Figure 4 --- Figure 5 implies that the association with the primary CE is the first association formed. Is this a requirement? --- Section 5 needs to give clear and unambiguous instructions to the IANA. It seems that the text in Section 5 is currently a placeholder for the correct text. The shepherd write-up notes the need for this section to be reviewed by "ForCES IANA experts". If these people are not to be found in the ForCES working group, then they exist nowhere. So the WG needs to look at this section and work out what it should really say. --- Section 6 is too sparse. The Security Section in RFC 5810 is sound, so that is not the issue. However, in considering HA you are considering a more complex scenario where each CE must have its communications secured with the FE, and each CE must be authenticated to the FE. That needs discussion. Additionally, can the system be disrupted by simulating CE failure or by disrupting CE-FE communications? --- Section 7.2 I think 5812 is used in a normative way. From hadi@mojatatu.com Wed Jul 24 05:58:01 2013 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A002411E812C for ; Wed, 24 Jul 2013 05:58:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.376 X-Spam-Level: X-Spam-Status: No, score=-102.376 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_44=0.6, RCVD_IN_DNSWL_LOW=-1, 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 jzhffUfHF2oM for ; Wed, 24 Jul 2013 05:57:55 -0700 (PDT) Received: from mail-ve0-f177.google.com (mail-ve0-f177.google.com [209.85.128.177]) by ietfa.amsl.com (Postfix) with ESMTP id 85C4A11E80E6 for ; Wed, 24 Jul 2013 05:57:55 -0700 (PDT) Received: by mail-ve0-f177.google.com with SMTP id cz10so6917834veb.36 for ; Wed, 24 Jul 2013 05:57:54 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=1U3QcgeQ73bTTQlXrVhQ9SeMjKZdPo7WT2KHQQj9Y58=; b=OwQSifkWL2thqunVVqBdJIFtz1t8Nsp6jseUE4AEyZ0R5KKe6QGQbgRYws6lFEOp/L UTMp0FPrWn1EwuwIa6WpxDWtBdrprwtBfFx4oQ95ugwR8gYnjDpqrUP2etoLJ5nIZEa+ CEBoY0RE2lDTgAfwDvLOFPmrKN0hzet2VK62j5c8RdFHRO6+km0qIrzvZ3bdbwUC9jc7 7vGAgll9zKSO1kTpSCnNa1QV+Bvk+PXjkcWjEoQT5HeEfK/oPxSKatQ3+N6zJcFQ+l9z CNwT3oVt1AevgCG9gfY2fP7HdRcYd3vwYvQ5+BxdtfGe+7VQb/aCLqbwb2QqbBO7e7Mf W8wA== X-Received: by 10.52.69.199 with SMTP id g7mr5920783vdu.73.1374670674211; Wed, 24 Jul 2013 05:57:54 -0700 (PDT) MIME-Version: 1.0 Received: by 10.58.247.197 with HTTP; Wed, 24 Jul 2013 05:57:34 -0700 (PDT) In-Reply-To: <02b001ce884a$a1585040$e408f0c0$@olddog.co.uk> References: <02b001ce884a$a1585040$e408f0c0$@olddog.co.uk> From: Jamal Hadi Salim Date: Wed, 24 Jul 2013 08:57:34 -0400 Message-ID: To: Adrian Farrel Content-Type: multipart/alternative; boundary=20cf307d045e385bf004e24175bc X-Gm-Message-State: ALoCoQnTqu01Tg6CfTnXXF7eZgE7BVfqoJrT+ChLvEE39cPvsgZohAzEbXpgDBpfw2JpIXTwYyKN Cc: "forces@ietf.org" , draft-ietf-forces-ceha.all@tools.ietf.org Subject: Re: [forces] AD Review of draft-ietf-forces-ceha X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jul 2013 12:58:01 -0000 --20cf307d045e385bf004e24175bc Content-Type: text/plain; charset=ISO-8859-1 Hi Adrian, Thanks for the review. Comments below. On Wed, Jul 24, 2013 at 4:48 AM, Adrian Farrel wrote: > > > Section 1 > > Need to fix the 2119 boilerplate to include a reference to [RFC2119] > > ok. > --- > > Section 1 > > OLD > The following definitions are taken from [RFC3654]and [RFC3746]: > NEW > The following definitions are taken from [RFC3654] and [RFC3746]. > They are repeated here for convenience, but the normative definitions > are found in the referenced RFCs. > END > > Ok. > --- > > Section 1 > > o ForCES Protocol -- The protocol used at the Fp reference point in > the ForCES Framework in [RFC3746]. > > You need to explain what "Fp" is. > > Figure 1 points to what Fp is, but if it didnt jump at you right away then we should explain it. --- > > Section 1 > > o ForCES Protocol Layer (ForCES PL) -- A layer in the ForCES > architecture that embodies the ForCES protocol and the state > transfer mechanisms as defined in [RFC5810]. > > How can this definition come from 3654 or 3746 when it has a reference to > 5810? > > 3654 and 3746 talked about the protocol in generalities. 5810 talks about the protocol. It came later and is only added there for sake of clarity of what we mean when we say PL. > --- > > Figure 1 > > Maybe more normal to use "CEn" rather than "CEN" > > Ok. > --- > > Section 2 > > The master CE controls the FEs via > the ForCES protocol operating in the Fp interface. > > s/in/on/ > > Ok. > --- > > Section 3 > > To achieve CE High Availability (HA), FEs and CEs MUST inter-operate > per [RFC5810] definition which is repeated for contextual reasons in > Section 3.1. > > While you are repeating some of the material from 5810, you are also > restating some of it in new words, and adding text. > > This gives a real problem with determining where the normative > definition sits. We have to fix this! > > Can you determine which sections are informational for this document and > which contain new text? > > Ok, we'll review, however, note that there is intent in this document to provide clarity in what is prescribed in 5810. This is stated in Section 2.1, to quote: " The problem scope addressed by this document falls into 2 areas: 1. To describe with more clarity (than [RFC5810]) how current cold- standby approach operates within the NE cluster. 2. To describe how to evolve the [RFC5810] cold-standby setup to a hot-standby redundancy setup to improve the failover time and NE availability. " > Possibly the whole of Section 3 is just informational. If this is the > case you can replace the text quoted above with the following: > > To achieve CE High Availability (HA), FEs and CEs MUST inter-operate > per [RFC5810]. The normative description of cold standby for CE HA > is provided in [RFC5810]. This section provides a more wordy > description of the procedures and is purely informational. In the > event of any discrepancies between this text and that in RFC 5810, > the text in RFC 5810 takes precedence. > > --- > > The goal is for someone reading 5810 and not getting clarity on the cold-standby HA\ to read this document instead. I think the part where you say "purely informational" may be overriding that intent. > Figure 2 > > Will it be obvious to the reader of this document what is meant by > "Asso Estb,Caps exchg" > > Will fix. > --- > > Section 3.1.1 > > "CEID" is used without expansion. Although sometimes I find "CE ID" for > example in 3.1.2. > > --- > > Will fix for consistency. > Section 3.1.1 has > > The FE connects to the CE specified on FEPO CEID component. If it > fails to connect to the defined CE, it moves it to the bottom of > table BackupCEs and sets its CEID component to be the first CE > retrieved from table BackupCEs. > > This is not a problem, but is unusual. In many redundancy cases, the > primary object remains the favorite even when it has failed so that > when there is a restoration opportunity (such as a failure of the new > primary) it will resume its position as primary. > > Depends. I actually have seen the sticky prioritization scheme you have described being requested for, but that desire subsidises after we describe that we provide for the master CE to change the mastership if the older CE shows up again i.e whatever the FE does it could be overriden by the CE. > > The question here is perhaps whether there is any distinction between > CEs except their role as primary or backup. > > There is that implicit prioritization which says the ordering of the CEs in the table implies their priorities. > --- > > Figure 3 has "CEFTI" without explanation. > > --- > > It comes from 5810 - will fix. > Section 3.1.1 has > > If the FE's FEPO CE Failover Policy is configured to mode 1, it > indicates that the FE will run in HA restart recovery. In such a > case, the FE transitions to the Not Associated state and the CEFTI > timer [RFC5810] is started. The FE MAY continue to forward packets > during this state. > > This use of "MAY" implies to me that it is at least as common that the > FE does not forward packets in this state. Is that the intention? > > --- > > Abuse of MAY on our part. We'll fix. [There is another knob which says whether to forward packets or not. If that knob is on we continue to forward packets otherwise we dont] > Section 3.1.1 > > "HB" is used without expansion. > > Will fix. > --- > > Section 4.2 > > "CEHB" and "FEHB" are used without expansion > > Will fix. > --- > > Need to fix the line-length problems in Figure 4 > > --- > > We'll fix > Figure 5 implies that the association with the primary CE is the first > association formed. Is this a requirement? > > It is suggested in 5810 i.e that is part of the implicit prioritization from above. The administrator's listing of the controllers in a specific order essentially states which one needs to be connected-to first. But if it is unavailable, then the next one in the list is connected to etc. > --- > > Section 5 needs to give clear and unambiguous instructions to the IANA. > It seems that the text in Section 5 is currently a placeholder for the > correct text. > > Will fix. > The shepherd write-up notes the need for this section to be reviewed by > "ForCES IANA experts". If these people are not to be found in the ForCES > working group, then they exist nowhere. So the WG needs to look at this > section and work out what it should really say. > > There are allocated ForCES IANA experts ;-> I will let the shepherd speak for himself - my gut-feel is he meant those people (some speaking in the third person) review those changes requested. > --- > > Section 6 is too sparse. > > The Security Section in RFC 5810 is sound, so that is not the issue. > However, in considering HA you are considering a more complex scenario > where each CE must have its communications secured with the FE, and each > CE must be authenticated to the FE. That needs discussion. > > Additionally, can the system be disrupted by simulating CE failure or by > disrupting CE-FE communications? > > I cant think off the top of my head what new security issue could be introduced merely because we are running HA (but i have not been sleeping well either, so likely missing something). We'll get back to you. > --- > > Section 7.2 > > I think 5812 is used in a normative way. > > Will fix. Thanks for the review Adrian. cheers, jamal --20cf307d045e385bf004e24175bc Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Hi Adrian,
Thanks for th= e review.=A0Comments below.

On Wed, Jul 24, 2013 at 4:48 AM, Adrian Farrel <adria= n@olddog.co.uk> wrote:


Section 1

Need to fix the 2119 boilerplate to include a reference to [RFC2119]



ok.
=A0
=
---

Section 1

OLD
=A0 =A0The following definitions are taken from [RFC3654]and [RFC3746]:
NEW
=A0 =A0The following definitions are taken from [RFC3654] and [RFC3746]. =A0 =A0They are repeated here for convenience, but the normative definition= s
=A0 =A0are found in the referenced RFCs.
END


Ok.
=A0
---

Section 1

=A0 =A0o =A0ForCES Protocol -- The protocol used at the Fp reference point = in
=A0 =A0 =A0 the ForCES Framework in [RFC3746].

You need to explain what "Fp" is.


Figure 1 points to what Fp is, but if = it didnt jump at you right away then we should
explain it.
<= div>
---

Section 1

=A0 =A0o =A0ForCES Protocol Layer (ForCES PL) -- A layer in the ForCES
=A0 =A0 =A0 architecture that embodies the ForCES protocol and the state =A0 =A0 =A0 transfer mechanisms as defined in [RFC5810].

How can this definition come from 3654 or 3746 when it has a reference to 5810?


3654 and 3746 talked about the protoco= l in generalities.
5810 talks about the protocol. It came later a= nd is only added
there for sake of clarity of what we mean when w= e say PL.

=A0
---

Figure 1

Maybe more normal to use "CEn" rather than "CEN"



Ok.
=A0
=
---

Section 2

=A0 =A0The master CE controls the FEs via
=A0 =A0the ForCES protocol operating in the Fp interface.

s/in/on/


Ok.
=A0
---

Section 3

=A0 =A0To achieve CE High Availability (HA), FEs and CEs MUST inter-operate=
=A0 =A0per [RFC5810] definition which is repeated for contextual reasons in=
=A0 =A0Section 3.1.

While you are repeating some of the material from 5810, you are also
restating some of it in new words, and adding text.

This gives a real problem with determining where the normative
definition sits. We have to fix this!

Can you determine which sections are informational for this document and which contain new text?


Ok, we'll review, however, note th= at there is intent in this document=A0
to provide clarity in what= is prescribed in 5810.=A0
This is stated in Section 2.1, to quot= e:

"
The problem scope addressed by th= is document falls into 2 areas:
=A0 =A01. =A0To describe with mor= e clarity (than [RFC5810]) how current cold-
=A0 =A0 =A0 =A0stand= by approach operates within the NE cluster.
=A0 =A02. =A0To describe how to evolve the [RFC5810] cold-standby setu= p to a
=A0 =A0 =A0 =A0hot-standby redundancy setup to improve the= failover time and NE
=A0 =A0 =A0 =A0availability.
"

=A0
Possibly the whole of Section 3 is just informational. If this is the
case you can replace the text quoted above with the following:

=A0 =A0To achieve CE High Availability (HA), FEs and CEs MUST inter-operate=
=A0 =A0per [RFC5810]. =A0The normative description of cold standby for CE H= A
=A0 =A0is provided in [RFC5810]. =A0This section provides a more wordy
=A0 =A0description of the procedures and is purely informational. =A0In the=
=A0 =A0event of any discrepancies between this text and that in RFC 5810, =A0 =A0the text in RFC 5810 takes precedence.

---



The goal is for someone= reading 5810 and not getting clarity on the cold-standby HA\
to = read this document instead. I think the part where you say "purely inf= ormational"
may be overriding that intent.
=A0=A0
Figure 2

Will it be obvious to the reader of this document what is meant by
"Asso Estb,Caps exchg"


Will fix.
=A0
---

Section 3.1.1

"CEID" is used without expansion. Although sometimes I find "= ;CE ID" for
example in 3.1.2.

---



Will fix for consistenc= y.
=A0
Section 3.1.1 has

=A0 =A0The FE connects to the CE specified on FEPO CEID component. =A0If it=
=A0 =A0fails to connect to the defined CE, it moves it to the bottom of
=A0 =A0table BackupCEs and sets its CEID component to be the first CE
=A0 =A0retrieved from table BackupCEs.

This is not a problem, but is unusual. In many redundancy cases, the
primary object remains the favorite even when it has failed so that
when there is a restoration opportunity (such as a failure of the new
primary) it will resume its position as primary.


Depends. I actually have seen the stic= ky prioritization scheme you have described being
requested for, = but that desire subsidises after we describe that we =A0provide for the mas= ter
CE to change the mastership if the older CE shows =A0up again i.e what= ever the FE does
it could be overriden by the CE.=A0
=A0

The question here is perhaps whether there is any distinction between
CEs except their role as primary or backup.



There is that implicit = prioritization which says the ordering of the CEs in the table
im= plies their priorities.

=A0
---

Figure 3 has "CEFTI" without explanation.

---



It comes from 5810 - wi= ll fix.
=A0
Section 3.1.1 has

=A0 =A0If the FE's FEPO CE Failover Policy is configured to mode 1, it<= br> =A0 =A0indicates that the FE will run in HA restart recovery. =A0In such a<= br> =A0 =A0case, the FE transitions to the Not Associated state and the CEFTI =A0 =A0timer [RFC5810] is started. =A0The FE MAY continue to forward packet= s
=A0 =A0during this state.

This use of "MAY" implies to me that it is at least as common tha= t the
FE does not forward packets in this state. Is that the intention?

---



Abuse of MAY on our par= t. We'll fix.
[There is another knob which says whether to fo= rward packets or not.
If that knob is on we continue to forward p= ackets otherwise we dont]

=A0
Section 3.1.1

"HB" is used without expansion.



Will fix.
=A0=
---

Section 4.2

"CEHB" and "FEHB" are used without expansion


Will fix.
=A0
---

Need to fix the line-length problems in Figure 4

---


We'll fix
=A0
Figure 5 implies that the association with the primary CE is the first
association formed. Is this a requirement?



It is suggested in 5810= i.e that is part of the implicit prioritization
from above.
The administrator's listing of the controllers in a specific orde= r essentially
states which one needs to be connected-to first.
But if it i= s unavailable, then the next one in the list is connected to etc.

=A0
---

Section 5 needs to give clear and unambiguous instructions to the IANA.
It seems that the text in Section 5 is currently a placeholder for the
correct text.



Will fix.
=A0=
The shepherd write-up notes the need for this section to be reviewed by
"ForCES IANA experts". If these people are not to be found in the= ForCES
working group, then they exist nowhere. So the WG needs to look at this
section and work out what it should really say.


There are allocated ForCES IANA expert= s ;-> I will let the shepherd speak for
himself - my gut-feel = is he meant those people (some speaking in the third person)
review those changes requested.
=A0
---

Section 6 is too sparse.

The Security Section in RFC 5810 is sound, so that is not the issue.
However, in considering HA you are considering a more complex scenario
where each CE must have its communications secured with the FE, and each CE must be authenticated to the FE. That needs discussion.

Additionally, can the system be disrupted by simulating CE failure or by disrupting CE-FE communications?


I cant think off the top of my head wh= at new security issue
could be introduced merely because we are r= unning HA (but i have not been sleeping
well either, so likely mi= ssing something). We'll get back to you.

=A0
---

Section 7.2

I think 5812 is used in a normative way.


Will fix.

Tha= nks for the review Adrian.

cheers,
jamal=
--20cf307d045e385bf004e24175bc-- From adrian@olddog.co.uk Wed Jul 24 10:16:53 2013 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7877211E8105 for ; Wed, 24 Jul 2013 10:16:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.566 X-Spam-Level: X-Spam-Status: No, score=-2.566 tagged_above=-999 required=5 tests=[AWL=0.033, 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 xRf-Dd-cWnYY for ; Wed, 24 Jul 2013 10:16:49 -0700 (PDT) Received: from asmtp1.iomartmail.com (asmtp1.iomartmail.com [62.128.201.248]) by ietfa.amsl.com (Postfix) with ESMTP id 1B01611E8101 for ; Wed, 24 Jul 2013 10:16:47 -0700 (PDT) Received: from asmtp1.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id r6OHGkNT031425 for ; Wed, 24 Jul 2013 18:16:46 +0100 Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id r6OHGj0o031419 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Wed, 24 Jul 2013 18:16:46 +0100 From: "Adrian Farrel" To: References: <20130710164235.2C0A36211F@rfc-editor.org> <9DD23086-0DEA-433D-A784-752AEC33592A@amsl.com> <87F1256D-4F16-4F11-9261-13B074CD9FDA@amsl.com> In-Reply-To: <87F1256D-4F16-4F11-9261-13B074CD9FDA@amsl.com> Date: Wed, 24 Jul 2013 18:16:44 +0100 Message-ID: <03c901ce8891$92aa68c0$b7ff3a40$@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: AQKFH5RYRHYoqhw3iwaB62K99mNA+AITSiCCATIaHtSX7LhgQA== Content-Language: en-gb Subject: [forces] FW: email address for M. Gao - Re: AUTH48 [KC]: RFC 6984 NOW AVAILABLE X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jul 2013 17:16:53 -0000 Forwarding to ForCES working group. Please respond to the RFC Editor. Thanks, Adrian > -----Original Message----- > From: Alice Russo [mailto:arusso@amsl.com] > Sent: 24 July 2013 17:52 > To: wmwang@zjsu.edu.cn; hadi@mojatatu.com; ogawa.kentaro@lab.ntt.co.jp; > ehalep@ece.upatras.gr > Cc: forces-ads@tools.ietf.org; forces-chairs@tools.ietf.org; > jmh@joelhalpern.com Halpern; RFC Editor > Subject: email address for M. Gao - Re: AUTH48 [KC]: RFC 6984 interop-09.txt> NOW AVAILABLE > > Authors, > > Does anyone have an updated email address for Ming Gao? Mail to this address > bounced: > > gmyyqno1@zjsu.edu.cn (that contains a one, not a lowercase 'L') > > Thank you. > RFC Editor/ar > > On Jul 24, 2013, at 12:43 PM, Alice Russo wrote: > > > Authors, > > > > We don't believe we have heard from you regarding this document's > > readiness for publication as an RFC. Please reply to the 5 questions > > below and review the document as it appears here: > > > > http://www.rfc-editor.org/authors/rfc6984.txt > > http://www.rfc-editor.org/authors/rfc6984-diff.html > > > > We will wait to hear from you before continuing the publication > > process. FYI, this page shows the AUTH48 status: > > http://www.rfc-editor.org/auth48/rfc6984 > > > > Thank you. > > > > RFC Editor/ar > > > > On Jul 10, 2013, at 12:42 PM, rfc-editor@rfc-editor.org wrote: > > > >> Authors, > >> > >> While reviewing this document during AUTH48, please resolve (as necessary) > the following questions, which are also in the XML file. > >> > >> 1) > >> > >> > >> 2) > >> > >> > >> 3) > >> > >> > >> 4) > >> > >> > >> 5) > >> > >> > >> Thank you. > >> > >> RFC Editor/kc/ar > >> > >> On Jul 10, 2013, rfc-editor@rfc-editor.org wrote: > >> > >> *****IMPORTANT***** > >> > >> Updated 2013/07/10 > >> > >> RFC Author(s): > >> -------------- > >> > >> Instructions for Completing AUTH48 in XML > >> > >> This is your last chance to make changes to your RFC-to-be: > >> draft-ietf-forces-interop-09.txt. > >> Once the document is published as an RFC, we will not make changes. > >> Please follow the instructions below to complete the AUTH48 process. > >> > >> 1) Review the edited document completely. The files are available here: > >> > >> http://www.rfc-editor.org/authors/rfc6984.txt > >> http://www.rfc-editor.org/authors/rfc6984-diff.html > >> > >> This alternate diff file makes it easier to review the sections > >> that were moved: > >> http://www.rfc-editor.org/authors/rfc6984-alt-diff.html > >> > >> We recommend reviewing the entire document, not just the diff file. > >> FYI, http://tools.ietf.org/rfcdiff provides tools to make various > >> kinds of diff files. > >> > >> The placement of page breaks will be handled during the final stages of > >> publication (typically post-xml2rfc processing). > >> > >> 2) Review and resolve (as necessary) any questions raised by the RFC > >> Editor. The questions (if any) have been included in the XML file as > >> comments marked and will be sent in a subsequent email. > >> > >> Retrieve the edited XML file here: > >> > >> http://www.rfc-editor.org/authors/rfc6984.xml > >> > >> (Note that you may need to view the page source to save the file.) > >> > >> 3) Send us your changes or respond with your approval for publication. > >> Please use 'REPLY ALL' so that rfc-editor@rfc-editor.org and the parties > >> CC'ed on this message receive your response. Note that your document will > >> not move forward until we have received approvals from each of the > >> authors listed on the front page. > >> > >> If sending changes, please do one of the following: > >> > >> a. Update the provided XML file, then email us the revised XML file. > >> You may use any filename for the revised file; we will rename it > >> before posting it. > >> > >> --OR-- > >> > >> b. Provide us with an explicit list of changes in this format. > >> > >> Section # (or indicate Global) > >> > >> OLD: > >> old text > >> > >> NEW: > >> new text > >> > >> Be sure to pay particular attention to these areas of the document: > >> - IANA Considerations updates (if applicable) > >> - Contact information > >> - Copyright notice and legends (see item 5 for more details) > >> > >> 4) Review changes submitted by your coauthors (if any). We assume that > >> you will speak up if you do not agree with the proposed changes. > >> That is, your silence is your assent to changes submitted by your > >> coauthors. Note that any changes that are beyond editorial will be > >> sent to the relevant body for approval. > >> > >> 5) Review the copyright notice and legends as defined in RFC 5378 and > >> the Trust Legal Provisions (TLP -- http://trustee.ietf.org/license-info/). > >> > >> If your document was approved for publication with a pre-RFC-5378 > >> copyright notice, we have applied the text from section 6.c.iii of the > >> TLP. Please consider whether this text is required (note that the > >> 6.c.iii text is not applicable to Alternate Stream RFCs). See item > >> 4.5 of the "Copyright FAQ" at http://trustee.ietf.org/faqs.html for > >> guidance on whether this text applies to your document. > >> > >> 6) Please reply, as the document will not be published until we receive > >> approvals from each author. The details of the AUTH48 status of your > >> document are here: > >> > >> http://www.rfc-editor.org/auth48/rfc6984 > >> > >> Thank you for your cooperation, > >> > >> RFC Editor > >> > >> -------------------------------------- > >> RFC6984 (draft-ietf-forces-interop-09) > >> -------------------------------------- > >> Title : Interoperability Report for Forwarding and Control Element > Separation (ForCES) > >> Author(s) : W. Wang, K. Ogawa, E. Haleplidis, M. Gao, J. Hadi Salim > >> WG Chair(s) : Damascane M. Joachimpillai, Jamal Hadi Salim > >> Area Director(s) : Stewart Bryant, Adrian Farrel > >> > > From wmwang2001@hotmail.com Thu Jul 25 04:58:20 2013 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7AF5C21F9A5F for ; Thu, 25 Jul 2013 04:58:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.846 X-Spam-Level: X-Spam-Status: No, score=-0.846 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_BASE64_TEXT=1.753] 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 cpMrra-Su5q7 for ; Thu, 25 Jul 2013 04:58:16 -0700 (PDT) Received: from blu0-omc2-s29.blu0.hotmail.com (blu0-omc2-s29.blu0.hotmail.com [65.55.111.104]) by ietfa.amsl.com (Postfix) with ESMTP id AB63721F99E9 for ; Thu, 25 Jul 2013 04:58:15 -0700 (PDT) Received: from BLU0-SMTP350 ([65.55.111.72]) by blu0-omc2-s29.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 25 Jul 2013 04:58:14 -0700 X-EIP: [8pSq6G2XwrGjcj8ARnQU/malOtmS2qSO] X-Originating-Email: [wmwang2001@hotmail.com] Message-ID: Received: from WmwangHome ([220.184.30.62]) by BLU0-SMTP350.phx.gbl over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Thu, 25 Jul 2013 04:58:13 -0700 From: "Wang,Weiming" To: "Alice Russo" , , , , , References: <20130710164235.2C0A36211F@rfc-editor.org> <9DD23086-0DEA-433D-A784-752AEC33592A@amsl.com> Date: Thu, 25 Jul 2013 19:58:19 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: base64 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-OriginalArrivalTime: 25 Jul 2013 11:58:13.0826 (UTC) FILETIME=[3DC6C220:01CE892E] X-Mailman-Approved-At: Thu, 25 Jul 2013 05:33:30 -0700 Cc: RFC Editor , jmh@joelhalpern.com, forces-chairs@tools.ietf.org, forces-ads@tools.ietf.org Subject: Re: [forces] AUTH48 [KC]: RFC 6984 NOW AVAILABLE X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jul 2013 11:58:20 -0000 SGkgQWxpY2UsIA0KDQpCZWNhdXNlIG9mIHNvbWUgdW5leHBlY3RlZCBvd24gYnVzaW5lc3MsIEkg ZGVsYXllZCB0aGUgcmVzcG9uc2UgdG8geW91LiBWZXJ5IHNvcnJ5IGZvciB0aGF0IGFuZCBJIHdp bGwgdHJ5IHRvIHJlc3BvbmQgdGhpcyB3aXRoaW4gYSBmZXcgZGF5cy4gDQoNCg0KdGhhbmtzLA0K V2VpbWluZw0KDQpQLlMuLCBHYW9taW5nIHdpbGwgcmVzcG9uZCB0byB5b3Ugb24gYSBiaXQgdXBk YXRlIG9mIHRoZSBlbWFpbCBhZGRyZXNzLiBUaGUgZG9tYWluICJAempzdS5lZHUuY24iIHRoYXQg SSBhbmQgR2FvbWluZyB1c2UgZG8gZmFjZSBzb21lIGRpZmZpY3VsdHkuIEZvciBpbnN0YW5jZSwg SSBoYXZlIHRvIHVzZSBteSBob3RtYWlsIGVtYWlsIHRvIHNlbmQgeW91IHRoaXMgbWVzc2FnZSBy YXRoZXIgdGhhbiBieSB0aGF0IG9uZSwgb3IgaXQgbWlnaHQgYmUgYm91bmNlZCBieSBzb21lIG9m IHlvdSBhbmQgeW91IG1heSBub3QgYmUgYWJsZSB0byByZWNlaXZlIGl0LiBBbHNvLCB0aGF0IGRv bWFpbiBhbHNvIGRvZXMgbm90IHdvcmsgZm9yIGlldGYgbWFpbGluZyBsaXN0IGxpa2UgZm9yY2Vz QGlldGYub3JnLg0KDQoNCi0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0gDQpGcm9tOiAiQWxp Y2UgUnVzc28iIDxhcnVzc29AYW1zbC5jb20+DQoNCkF1dGhvcnMsDQoNCldlIGRvbid0IGJlbGll dmUgd2UgaGF2ZSBoZWFyZCBmcm9tIHlvdSByZWdhcmRpbmcgdGhpcyBkb2N1bWVudCdzDQpyZWFk aW5lc3MgZm9yIHB1YmxpY2F0aW9uIGFzIGFuIFJGQy4gUGxlYXNlIHJlcGx5IHRvIHRoZSA1IHF1 ZXN0aW9ucyANCmJlbG93IGFuZCByZXZpZXcgdGhlIGRvY3VtZW50IGFzIGl0IGFwcGVhcnMgaGVy ZToNCg0KICBodHRwOi8vd3d3LnJmYy1lZGl0b3Iub3JnL2F1dGhvcnMvcmZjNjk4NC50eHQNCiAg aHR0cDovL3d3dy5yZmMtZWRpdG9yLm9yZy9hdXRob3JzL3JmYzY5ODQtZGlmZi5odG1sDQoNCldl IHdpbGwgd2FpdCB0byBoZWFyIGZyb20geW91IGJlZm9yZSBjb250aW51aW5nIHRoZSBwdWJsaWNh dGlvbiANCnByb2Nlc3MuIEZZSSwgdGhpcyBwYWdlIHNob3dzIHRoZSBBVVRINDggc3RhdHVzOg0K ICBodHRwOi8vd3d3LnJmYy1lZGl0b3Iub3JnL2F1dGg0OC9yZmM2OTg0DQoNClRoYW5rIHlvdS4N Cg0KUkZDIEVkaXRvci9hcg0KDQpPbiBKdWwgMTAsIDIwMTMsIGF0IDEyOjQyIFBNLCByZmMtZWRp dG9yQHJmYy1lZGl0b3Iub3JnIHdyb3RlOg0KDQo+IEF1dGhvcnMsDQo+IA0KPiBXaGlsZSByZXZp ZXdpbmcgdGhpcyBkb2N1bWVudCBkdXJpbmcgQVVUSDQ4LCBwbGVhc2UgcmVzb2x2ZSAoYXMgbmVj ZXNzYXJ5KSB0aGUgZm9sbG93aW5nIHF1ZXN0aW9ucywgd2hpY2ggYXJlIGFsc28gaW4gdGhlIFhN TCBmaWxlLg0KPiANCj4gMSkgPCEtLSBbcmZjZWRdIFRoZSBYTUwgZmlsZSB0aGF0IHlvdSBzdWJt aXR0ZWQgY29udGFpbnMgc2V2ZXJhbCANCj4gcXVlc3Rpb25zIGFuZCBjb21tZW50cyAoc2VlbWlu Z2x5IGFtb25nIHRoZSBhdXRob3JzKSB0aHJvdWdob3V0IA0KPiB0aGUgZG9jdW1lbnQuIFBsZWFz ZSByZXZpZXcgdGhlbSBhbmQgbGV0IHVzIGtub3cgaWYgYW55IGZ1cnRoZXINCj4gY2hhbmdlcyBh cmUgbmVlZGVkLCBvciBpZiB0aGV5J3ZlIGFscmVhZHkgYmVlbiBhZGRyZXNzZWQgdG8geW91cg0K PiBzYXRpc2ZhY3Rpb24uDQo+IA0KPiBGb3IgZXhhbXBsZSwgb25lIGNvbW1lbnQgaW4gU2VjdGlv biAzLjIgcmVhZHM6DQo+ICIgQ2FuIHlvdSBqdXN0IHJlZmVyIHRvIHRoZSBJUHNlYyByZXF1aXJl bWVudHMgaW4gUkZDIDU4MTE/DQo+IFdoZW4gaSByZWFkIHRoaXMgaSBhbSBub3Qgc3VyZSB3aGF0 IHBhcmFtZXRlcnMgd2VyZSB1c2VkIGZvciBJUHNlYyINCj4gDQo+IEZvciBhbm90aGVyIGV4YW1w bGUsIG9uZSBjb21tZW50IHJlYWRzOg0KPiAiUmVmZXJlbmNlIGZvciBTbWFydGJpdHMgbmVlZGVk Ig0KPiANCj4gKFRoZXJlIGFyZSBtYW55IG1vcmUuKQ0KPiAtLT4NCj4gDQo+IA0KPiAyKSA8IS0t IFtyZmNlZF0gRG8geW91IG1lYW4gKEEpIHRoZSBlcnJvcnMgdGhhdCBhcHBlYXIgaW4gcmVsYXRl ZCBSRkNzIA0KPiBoYXZlIGJlZW4gcmVwb3J0ZWQgb3IgZG8geW91IG1lYW4gKEIpIHRoZSBlcnJv cnMgZm91bmQgaW4gdGhlIEZvckNFUyANCj4gZG9jdW1lbnQgaGF2ZSBiZWVuIHJlcG9ydGVkIGlu IHJlbGF0ZWQgUkZDcz8NCj4gDQo+IE9yaWdpbmFsOg0KPiAgIFNvbWUgZXJyYXRhIHJlbGF0ZWQg dG8gRm9yQ0VTIGRvY3VtZW50IHdlcmUgZm91bmQgYnkgdGhlDQo+ICAgaW50ZXJvcGVyYWJpbGl0 eSB0ZXN0LiAgVGhlIGVycmF0YSBoYXMgYmVlbiByZXBvcnRlZCB0byByZWxhdGVkIElFVEYNCj4g ICBSRkNzLg0KPiANCj4gSWYgKEEpLCBwZXJoYXBzOg0KPiAgIFNvbWUgZXJyYXRhIHJlbGF0ZWQg dG8gdGhlIEZvckNFUyBkb2N1bWVudCB3ZXJlIGZvdW5kIGJ5IHRoZQ0KPiAgIGludGVyb3BlcmFi aWxpdHkgdGVzdC4gIEVycmF0YSBmb3VuZCBpbiByZWxhdGVkIFJGQ3MgaGF2ZSBhbHNvDQo+ICAg YmVlbiByZXBvcnRlZC4NCj4gDQo+IElmIChCKSwgcGVyaGFwczoNCj4gICBTb21lIGVycmF0YSBy ZWxhdGVkIHRvIHRoZSBGb3JDRVMgZG9jdW1lbnQgd2VyZSBmb3VuZCBieSB0aGUNCj4gICBpbnRl cm9wZXJhYmlsaXR5IHRlc3QuICBUaG9zZSBlcnJhdGEgaGF2ZSBiZWVuIHJlcG9ydGVkIGluIA0K PiAgIHJlbGF0ZWQgUkZDcy4NCj4gLS0+DQo+IA0KPiANCj4gMykgPCEtLSBbcmZjZWRdIFBBVEgt REFUQSB2cy4gUEFUSC1EQVRBLVRMVg0KPiBUaGlzIGRvY3VtZW50IHVzZXMgdGhlIHRlcm0gJ1BB VEgtREFUQScgc2V2ZXJhbCB0aW1lcy4NCj4gU2hvdWxkIGl0IGJlIHVwZGF0ZWQgdG8gJ1BBVEgt REFUQS1UTFYnIHRocm91Z2hvdXQgaW4gb3JkZXIgdG8gbWF0Y2gNCj4gdGhlIElBTkEtcmVnaXN0 ZXJlZCBuYW1lIChhbmQgaG93IGl0IGFwcGVhcnMgaW4gUkZDIDYwNTMpPyBGb3IgZXhhbXBsZToN Cj4gDQo+IE9yaWdpbmFsOg0KPiAgIFNwZWNpYWxseSwgd2UgdHJpZWQgdG8gdmVyaWZ5IHRoZSBk YXRhIGZvcm1hdCBvZiBhIFBBVEgtREFUQSANCj4gICB3aXRoIG5lc3RlZCBQQVRILURBVEFzLCBh bmQgLi4uDQo+IA0KPiBQZXJoYXBzOg0KPiAgIFNwZWNpZmljYWxseSwgd2UgdHJpZWQgdG8gdmVy aWZ5IHRoZSBkYXRhIGZvcm1hdCBvZiBhIFBBVEgtREFUQS1UTFYNCj4gICB3aXRoIG5lc3RlZCBQ QVRILURBVEEtVExWcywgYW5kIC4uLg0KPiANCj4gTm90ZTogSW5zdGFuY2VzIG9mIFNQQVJTRS1E QVRBIC8gU1BBUlNFREFUQSBhbmQgRlVMTC1EQVRBIC8gRlVMTERBVEENCj4gaGF2ZSBiZWVuIHVw ZGF0ZWQgdG8gU1BBUlNFREFUQS1UTFYgYW5kIEZVTExEQVRBLVRMViwgcmVzcGVjdGl2ZWx5Lg0K PiBSYXRpb25hbGU6IG1hdGNoIHRoZSBJQU5BLXJlZ2lzdGVyZWQgbmFtZSBvZiB0aGUgVExWLg0K PiAtLT4NCj4gDQo+IA0KPiA0KSA8IS0tIFtyZmNlZF0gUGxlYXNlIGNsYXJpZnkgdGhlIG1lYW5p bmcgb2YgdGhpcyBzZW50ZW5jZS4NCj4gDQo+IE9yaWdpbmFsOg0KPiAgIEluIGNhc2UgKGMpLCB0 d28gRm9yQ0VTIHJvdXRlcnMgd2VyZSBjb25zdHJ1Y3RlZC4gT25lIHdhcyB3aXRoIA0KPiAgIENF IGJ5IE5UVCBhbmQgRkUgYnkgWkpTVSBhbmQgdGhlIG90aGVyIHdhcyBvcHBvc2l0ZS4gDQo+IA0K PiBQZXJoYXBzOg0KPiAgIEluIGNhc2UgKGMpLCB0d28gRm9yQ0VTIHJvdXRlcnMgd2VyZSBjb25z dHJ1Y3RlZDsgb25lIHdhcyB3aXRoIA0KPiAgIE5UVCdzIENFIGFuZCBaSlNVJ3MgRkUsIGFuZCB0 aGUgb3RoZXIgd2FzIHdpdGggTlRUJ3MgRkUgYW5kIA0KPiAgIFpKU1UncyBDRS4gDQo+IC0tPg0K PiANCj4gDQo+IDUpIDwhLS0gW3JmY2VkXSBJbiB0aGUgb3JpZ2luYWwgSS1ELCB0aGUgcmVmZXJl bmNlcyBjb250YWluZWQgDQo+IGFkZGl0aW9uYWwgaW5mb3JtYXRpb24gKGFzaWRlIGZyb20gdGhl IGF1dGhvciwgb3JnYW5pemF0aW9uLCANCj4gdGl0bGUsIGRhdGUsIGFuZCBVUkwpIGFzIGZvbGxv d3MuDQo+IFBsZWFzZSBub3RlIHRoYXQgdGhlIHJlZmVyZW5jZXMgaGF2ZSBiZWVuIHVwZGF0ZWQg c28gdGhpcyANCj4gaW5mb3JtYXRpb24gZG9lcyBub3QgYXBwZWFyIGluIHRoZSBkb2N1bWVudCBp dHNlbGY7IGlmIHlvdSANCj4gd291bGQgc3RpbGwgbGlrZSB0byBoYXZlIGl0IGluY2x1ZGVkLCBw bGVhc2UgbW92ZSBpdCB0byB0aGUgDQo+IGJvZHkgb2YgdGhlIGRvY3VtZW50Lg0KPiANCj4gT3Jp Z2luYWw6DQo+IFtSYWNvb25dICAgLCAiUmFjb29uIGluIE5ldEJTRCBpcyBhIHdlbGwta25vd24g SUtFIGRhZW1vbiBwZXJmb3JtaW5nDQo+ICAgICAgICAgICAgICB0aGUgSVBzZWMgS2V5IEV4Y2hh bmdlIChJS0UpIHdpdGggdGhlIHBlZXJzIiwNCj4gICAgICAgICAgICAgIGh0dHA6Ly93d3cubmV0 YnNkLm9yZy9kb2NzL25ldHdvcmsvaXBzZWMvcmFzdnBuLmh0bWwgLCAuDQo+IA0KPiBbVGNwZHVt cF0gICwgIlRjcGR1bXAgaXMgYSBMaW51eCBwcm90b2NvbCBhbmFseXplci4gVGhlIHNwZWNpZmlj DQo+ICAgICAgICAgICAgICB0Y3BkdW1wIHRoYXQgd2FzIHVzZWQgaXMgYSBtb2RpZmllZCB0Y3Bk dW1wLCBieSBKYW1hbCBIYWRpDQo+ICAgICAgICAgICAgICBTYWxpbSwgdGhhdCBjYW4gYW5hbHl6 ZSBhbmQgZGVjb2RlIHRoZSBGb3JDRVMgcHJvdG9jb2wNCj4gICAgICAgICAgICAgIG1lc3NhZ2Vz IiwgaHR0cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL2ZvcmNlcy8NCj4gICAgICAg ICAgICAgIGN1cnJlbnQvbXNnMDM4MTEuaHRtbCAsIC4NCj4gDQo+IFtUZWFtdmlld2VyXSAgLCAi VGVhbVZpZXdlciBjb25uZWN0cyB0byBhbnkgUEMgb3Igc2VydmVyIGFyb3VuZCB0aGUNCj4gICAg ICAgICAgICAgIHdvcmxkIHdpdGhpbiBhIGZldyBzZWNvbmRzLiAiLCBodHRwOi8vd3d3LnRlYW12 aWV3ZXIuY29tLw0KPiAgICAgICAgICAgICAgLCAuDQo+IA0KPiBDdXJyZW50Og0KPiAgIFtSYWNv b25dICAgICAgVGhlIE5ldEJTRCBGb3VuZGF0aW9uLCAiSG93IHRvIGJ1aWxkIGEgcmVtb3RlIHVz ZXINCj4gICAgICAgICAgICAgICAgIGFjY2VzcyBWUE4gd2l0aCBSYWNvb24iLA0KPiAgICAgICAg ICAgICAgICAgPGh0dHA6Ly93d3cubmV0YnNkLm9yZy9kb2NzL25ldHdvcmsvaXBzZWMvcmFzdnBu Lmh0bWw+Lg0KPiANCj4gICBbVGNwZHVtcF0gICAgIEhhZGkgU2FsaW0sIEouLCAiU3ViamVjdDog dGNwZHVtcCA0LjEuMSIsIG1lc3NhZ2UgdG8NCj4gICAgICAgICAgICAgICAgIHRoZSBJRVRGIGZv cmNlcyBtYWlsaW5nIGxpc3QsIDIwIE1heSAyMDEwLCA8aHR0cDovLw0KPiAgICAgICAgICAgICAg ICAgd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvZm9yY2VzL2N1cnJlbnQvDQo+ICAgICAg ICAgICAgICAgICBtc2cwMzgxMS5odG1sPi4NCj4gDQo+ICAgW1RlYW1WaWV3ZXJdICBUZWFtVmll d2VyIEluYy4sICJUZWFtVmlld2VyIC0gdGhlIEFsbC1Jbi1PbmUgU29mdHdhcmUNCj4gICAgICAg ICAgICAgICAgIGZvciBSZW1vdGUgU3VwcG9ydCBhbmQgT25saW5lIE1lZXRpbmdzIiwNCj4gICAg ICAgICAgICAgICAgIDxodHRwOi8vd3d3LnRlYW12aWV3ZXIuY29tLz4uDQo+IC0tPg0KPiANCj4g DQo+IFRoYW5rIHlvdS4NCj4gDQo+IFJGQyBFZGl0b3Iva2MvYXINCj4gDQo+IE9uIEp1bCAxMCwg MjAxMywgcmZjLWVkaXRvckByZmMtZWRpdG9yLm9yZyB3cm90ZToNCj4gDQo+ICoqKioqSU1QT1JU QU5UKioqKioNCj4gDQo+IFVwZGF0ZWQgMjAxMy8wNy8xMA0KPiANCj4gUkZDIEF1dGhvcihzKToN Cj4gLS0tLS0tLS0tLS0tLS0NCj4gDQo+IEluc3RydWN0aW9ucyBmb3IgQ29tcGxldGluZyBBVVRI NDggaW4gWE1MDQo+IA0KPiBUaGlzIGlzIHlvdXIgbGFzdCBjaGFuY2UgdG8gbWFrZSBjaGFuZ2Vz IHRvIHlvdXIgUkZDLXRvLWJlOiANCj4gZHJhZnQtaWV0Zi1mb3JjZXMtaW50ZXJvcC0wOS50eHQu DQo+IE9uY2UgdGhlIGRvY3VtZW50IGlzIHB1Ymxpc2hlZCBhcyBhbiBSRkMsIHdlIHdpbGwgbm90 IG1ha2UgY2hhbmdlcy4gIA0KPiBQbGVhc2UgZm9sbG93IHRoZSBpbnN0cnVjdGlvbnMgYmVsb3cg dG8gY29tcGxldGUgdGhlIEFVVEg0OCBwcm9jZXNzLg0KPiANCj4gMSkgUmV2aWV3IHRoZSBlZGl0 ZWQgZG9jdW1lbnQgY29tcGxldGVseS4gIFRoZSBmaWxlcyBhcmUgYXZhaWxhYmxlIGhlcmU6DQo+ IA0KPiAgaHR0cDovL3d3dy5yZmMtZWRpdG9yLm9yZy9hdXRob3JzL3JmYzY5ODQudHh0DQo+ICBo dHRwOi8vd3d3LnJmYy1lZGl0b3Iub3JnL2F1dGhvcnMvcmZjNjk4NC1kaWZmLmh0bWwNCj4gDQo+ ICBUaGlzIGFsdGVybmF0ZSBkaWZmIGZpbGUgbWFrZXMgaXQgZWFzaWVyIHRvIHJldmlldyB0aGUg c2VjdGlvbnMgDQo+ICB0aGF0IHdlcmUgbW92ZWQ6DQo+ICBodHRwOi8vd3d3LnJmYy1lZGl0b3Iu b3JnL2F1dGhvcnMvcmZjNjk4NC1hbHQtZGlmZi5odG1sDQo+IA0KPiAgV2UgcmVjb21tZW5kIHJl dmlld2luZyB0aGUgZW50aXJlIGRvY3VtZW50LCBub3QganVzdCB0aGUgZGlmZiBmaWxlLg0KPiAg RllJLCBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvcmZjZGlmZiBwcm92aWRlcyB0b29scyB0byBtYWtl IHZhcmlvdXMNCj4gIGtpbmRzIG9mIGRpZmYgZmlsZXMuDQo+IA0KPiAgVGhlIHBsYWNlbWVudCBv ZiBwYWdlIGJyZWFrcyB3aWxsIGJlIGhhbmRsZWQgZHVyaW5nIHRoZSBmaW5hbCBzdGFnZXMgb2YN Cj4gIHB1YmxpY2F0aW9uICh0eXBpY2FsbHkgcG9zdC14bWwycmZjIHByb2Nlc3NpbmcpLg0KPiAN Cj4gMikgUmV2aWV3IGFuZCByZXNvbHZlIChhcyBuZWNlc3NhcnkpIGFueSBxdWVzdGlvbnMgcmFp c2VkIGJ5IHRoZSBSRkMNCj4gIEVkaXRvci4gIFRoZSBxdWVzdGlvbnMgKGlmIGFueSkgaGF2ZSBi ZWVuIGluY2x1ZGVkIGluIHRoZSBYTUwgZmlsZSBhcw0KPiAgY29tbWVudHMgbWFya2VkIDwhLS0g W3JmY2VkXSAuLi4gLS0+IGFuZCB3aWxsIGJlIHNlbnQgaW4gYSBzdWJzZXF1ZW50IGVtYWlsLg0K PiANCj4gIFJldHJpZXZlIHRoZSBlZGl0ZWQgWE1MIGZpbGUgaGVyZToNCj4gDQo+ICAgICBodHRw Oi8vd3d3LnJmYy1lZGl0b3Iub3JnL2F1dGhvcnMvcmZjNjk4NC54bWwNCj4gDQo+ICAoTm90ZSB0 aGF0IHlvdSBtYXkgbmVlZCB0byB2aWV3IHRoZSBwYWdlIHNvdXJjZSB0byBzYXZlIHRoZSBmaWxl LikNCj4gDQo+IDMpIFNlbmQgdXMgeW91ciBjaGFuZ2VzIG9yIHJlc3BvbmQgd2l0aCB5b3VyIGFw cHJvdmFsIGZvciBwdWJsaWNhdGlvbi4gIA0KPiAgUGxlYXNlIHVzZSAnUkVQTFkgQUxMJyBzbyB0 aGF0IHJmYy1lZGl0b3JAcmZjLWVkaXRvci5vcmcgYW5kIHRoZSBwYXJ0aWVzDQo+ICBDQydlZCBv biB0aGlzIG1lc3NhZ2UgcmVjZWl2ZSB5b3VyIHJlc3BvbnNlLiBOb3RlIHRoYXQgeW91ciBkb2N1 bWVudCB3aWxsDQo+ICBub3QgbW92ZSBmb3J3YXJkIHVudGlsIHdlIGhhdmUgcmVjZWl2ZWQgYXBw cm92YWxzIGZyb20gZWFjaCBvZiB0aGUNCj4gIGF1dGhvcnMgbGlzdGVkIG9uIHRoZSBmcm9udCBw YWdlLg0KPiANCj4gIElmIHNlbmRpbmcgY2hhbmdlcywgcGxlYXNlIGRvIG9uZSBvZiB0aGUgZm9s bG93aW5nOg0KPiANCj4gIGEuIFVwZGF0ZSB0aGUgcHJvdmlkZWQgWE1MIGZpbGUsIHRoZW4gZW1h aWwgdXMgdGhlIHJldmlzZWQgWE1MIGZpbGUuICANCj4gICAgIFlvdSBtYXkgdXNlIGFueSBmaWxl bmFtZSBmb3IgdGhlIHJldmlzZWQgZmlsZTsgd2Ugd2lsbCByZW5hbWUgaXQgDQo+ICAgICBiZWZv cmUgcG9zdGluZyBpdC4NCj4gDQo+ICAtLU9SLS0NCj4gDQo+ICBiLiBQcm92aWRlIHVzIHdpdGgg YW4gZXhwbGljaXQgbGlzdCBvZiBjaGFuZ2VzIGluIHRoaXMgZm9ybWF0Lg0KPiANCj4gICAgIFNl Y3Rpb24gIyAob3IgaW5kaWNhdGUgR2xvYmFsKQ0KPiANCj4gICAgIE9MRDoNCj4gICAgIG9sZCB0 ZXh0DQo+IA0KPiAgICAgTkVXOg0KPiAgICAgbmV3IHRleHQNCj4gDQo+ICBCZSBzdXJlIHRvIHBh eSBwYXJ0aWN1bGFyIGF0dGVudGlvbiB0byB0aGVzZSBhcmVhcyBvZiB0aGUgZG9jdW1lbnQ6DQo+ ICAtIElBTkEgQ29uc2lkZXJhdGlvbnMgdXBkYXRlcyAoaWYgYXBwbGljYWJsZSkNCj4gIC0gQ29u dGFjdCBpbmZvcm1hdGlvbg0KPiAgLSBDb3B5cmlnaHQgbm90aWNlIGFuZCBsZWdlbmRzIChzZWUg aXRlbSA1IGZvciBtb3JlIGRldGFpbHMpDQo+IA0KPiA0KSBSZXZpZXcgY2hhbmdlcyBzdWJtaXR0 ZWQgYnkgeW91ciBjb2F1dGhvcnMgKGlmIGFueSkuICBXZSBhc3N1bWUgdGhhdA0KPiAgeW91IHdp bGwgc3BlYWsgdXAgaWYgeW91IGRvIG5vdCBhZ3JlZSB3aXRoIHRoZSBwcm9wb3NlZCBjaGFuZ2Vz Lg0KPiAgVGhhdCBpcywgeW91ciBzaWxlbmNlIGlzIHlvdXIgYXNzZW50IHRvIGNoYW5nZXMgc3Vi bWl0dGVkIGJ5IHlvdXINCj4gIGNvYXV0aG9ycy4gTm90ZSB0aGF0IGFueSBjaGFuZ2VzIHRoYXQg YXJlIGJleW9uZCBlZGl0b3JpYWwgd2lsbCBiZQ0KPiAgc2VudCB0byB0aGUgcmVsZXZhbnQgYm9k eSBmb3IgYXBwcm92YWwuDQo+IA0KPiA1KSBSZXZpZXcgdGhlIGNvcHlyaWdodCBub3RpY2UgYW5k IGxlZ2VuZHMgYXMgZGVmaW5lZCBpbiBSRkMgNTM3OCBhbmQgDQo+ICB0aGUgVHJ1c3QgTGVnYWwg UHJvdmlzaW9ucyAoVExQIC0tIGh0dHA6Ly90cnVzdGVlLmlldGYub3JnL2xpY2Vuc2UtaW5mby8p Lg0KPiANCj4gIElmIHlvdXIgZG9jdW1lbnQgd2FzIGFwcHJvdmVkIGZvciBwdWJsaWNhdGlvbiB3 aXRoIGEgcHJlLVJGQy01Mzc4DQo+ICBjb3B5cmlnaHQgbm90aWNlLCB3ZSBoYXZlIGFwcGxpZWQg dGhlIHRleHQgZnJvbSBzZWN0aW9uIDYuYy5paWkgb2YgdGhlDQo+ICBUTFAuICBQbGVhc2UgY29u c2lkZXIgd2hldGhlciB0aGlzIHRleHQgaXMgcmVxdWlyZWQgKG5vdGUgdGhhdCB0aGUNCj4gIDYu Yy5paWkgdGV4dCBpcyBub3QgYXBwbGljYWJsZSB0byBBbHRlcm5hdGUgU3RyZWFtIFJGQ3MpLiAg U2VlIGl0ZW0NCj4gIDQuNSBvZiB0aGUgIkNvcHlyaWdodCBGQVEiIGF0IGh0dHA6Ly90cnVzdGVl LmlldGYub3JnL2ZhcXMuaHRtbCBmb3INCj4gIGd1aWRhbmNlIG9uIHdoZXRoZXIgdGhpcyB0ZXh0 IGFwcGxpZXMgdG8geW91ciBkb2N1bWVudC4NCj4gDQo+IDYpIFBsZWFzZSByZXBseSwgYXMgdGhl IGRvY3VtZW50IHdpbGwgbm90IGJlIHB1Ymxpc2hlZCB1bnRpbCB3ZSByZWNlaXZlDQo+ICBhcHBy b3ZhbHMgZnJvbSBlYWNoIGF1dGhvci4gIFRoZSBkZXRhaWxzIG9mIHRoZSBBVVRINDggc3RhdHVz IG9mIHlvdXINCj4gIGRvY3VtZW50IGFyZSBoZXJlOg0KPiANCj4gIGh0dHA6Ly93d3cucmZjLWVk aXRvci5vcmcvYXV0aDQ4L3JmYzY5ODQNCj4gDQo+IFRoYW5rIHlvdSBmb3IgeW91ciBjb29wZXJh dGlvbiwNCj4gDQo+IFJGQyBFZGl0b3INCj4gDQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tDQo+IFJGQzY5ODQgKGRyYWZ0LWlldGYtZm9yY2VzLWludGVyb3AtMDkpDQo+ IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+IFRpdGxlICAgICAgICAg ICAgOiBJbnRlcm9wZXJhYmlsaXR5IFJlcG9ydCBmb3IgRm9yd2FyZGluZyBhbmQgQ29udHJvbCBF bGVtZW50IFNlcGFyYXRpb24gKEZvckNFUykNCj4gQXV0aG9yKHMpICAgICAgICA6IFcuIFdhbmcs IEsuIE9nYXdhLCBFLiBIYWxlcGxpZGlzLCBNLiBHYW8sIEouIEhhZGkgU2FsaW0NCj4gV0cgQ2hh aXIocykgICAgICA6IERhbWFzY2FuZSBNLiBKb2FjaGltcGlsbGFpLCBKYW1hbCBIYWRpIFNhbGlt DQo+IEFyZWEgRGlyZWN0b3IocykgOiBTdGV3YXJ0IEJyeWFudCwgQWRyaWFuIEZhcnJlbA0KPiAN Cg== From gaoming@mail.zjgsu.edu.cn Thu Jul 25 06:02:51 2013 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78AFD21F8FCE for ; Thu, 25 Jul 2013 06:02:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.501 X-Spam-Level: *** X-Spam-Status: No, score=3.501 tagged_above=-999 required=5 tests=[BAYES_50=0.001, CHARSET_FARAWAY_HEADER=3.2, MIME_8BIT_HEADER=0.3] 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 pkmdNxpuYRdG for ; Thu, 25 Jul 2013 06:02:45 -0700 (PDT) Received: from mail.zjgsu.edu.cn (ucmail.zjgsu.edu.cn [124.160.64.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CCFD21F91B4 for ; Thu, 25 Jul 2013 06:02:23 -0700 (PDT) Received: from gaoming ( [124.90.144.36] ) by ajax-webmail-mailportal (Coremail) ; Thu, 25 Jul 2013 21:02:14 +0800 (CST) Date: Thu, 25 Jul 2013 21:02:14 +0800 (CST) From: =?GBK?B?uN/D9w==?= To: joel@stevecrocker.com, forces@ietf.org, "hadi@mojatatu.com" , "ehalep@gmail.com" , "wmwang@mail.zjgsu.edu.cn" , "Adrian Farrel" Message-ID: <2595951.27281374757334819.JavaMail.coremail@mailportal.zjgsu.edu.cn> MIME-Version: 1.0 Content-Type: text/plain; charset=GBK Content-Transfer-Encoding: 7bit X-Originating-IP: [124.90.144.36] X-Priority: 3 X-Mailer: Coremail Webmail Server Version 3.5.2_snapshot build 100908(11656.3368.3360) Copyright (c) 2002-2013 www.mailtech.cn zjgsu X-CM-TRANSID: rBCI85CrNAXWIfFRgI1bAA--.21583W X-CM-SenderInfo: 5jdrzx1qj6ztdloo6yxjvxhvlgxou0/1tbiAQALEVA-I7iZ7gABsZ X-Coremail-Antispam: 1U50xBIdaVrnn0S07vEb7Iv0xC_Jr1lV2xY67kC6x804xJvcS sGvfC2KfnxnUU== X-Mailman-Approved-At: Thu, 25 Jul 2013 07:06:07 -0700 Subject: Re: [forces] email address for M. Gao X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jul 2013 13:02:51 -0000 Hi, all, I am M. Gao. Sorry to inform you that my old email address: gmyyqno1@zjgsu.edu.cn go wrong, I can't recieve any messages with it. Now I declare that please contact me with gaoming@mail.zjgsu.edu.cn and replace the old one with it in the later version of draft-ietf-forces-interop-09.txt. Thank you. Ming Gao From adrian@olddog.co.uk Thu Jul 25 12:38:00 2013 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 692BC21F88DB for ; Thu, 25 Jul 2013 12:38:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.266 X-Spam-Level: X-Spam-Status: No, score=-2.266 tagged_above=-999 required=5 tests=[AWL=0.333, 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 gU6nLZeh+FK3 for ; Thu, 25 Jul 2013 12:37:53 -0700 (PDT) Received: from asmtp4.iomartmail.com (asmtp4.iomartmail.com [62.128.201.175]) by ietfa.amsl.com (Postfix) with ESMTP id 318C921F86BE for ; Thu, 25 Jul 2013 12:37:52 -0700 (PDT) Received: from asmtp4.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id r6PJbpl0004361; Thu, 25 Jul 2013 20:37:51 +0100 Received: from 950129200 ([31.112.60.101]) (authenticated bits=0) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id r6PJbmll004338 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 25 Jul 2013 20:37:50 +0100 From: "Adrian Farrel" To: "'Jamal Hadi Salim'" References: <02b001ce884a$a1585040$e408f0c0$@olddog.co.uk> In-Reply-To: Date: Thu, 25 Jul 2013 20:37:46 +0100 Message-ID: <000001ce896e$719cc370$54d64a50$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQI6Q07702xNavMLAOpMwrNoOkw4/QDZ/dJYmJd9szA= Content-Language: en-gb Cc: forces@ietf.org, draft-ietf-forces-ceha.all@tools.ietf.org Subject: Re: [forces] AD Review of draft-ietf-forces-ceha X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jul 2013 19:38:00 -0000 Hi Jamal, Cut down to issues for debate... >> Section 1 >> >>=A0 =A0o =A0ForCES Protocol Layer (ForCES PL) -- A layer in the ForCES >>=A0 =A0 =A0 architecture that embodies the ForCES protocol and the = state >>=A0 =A0 =A0 transfer mechanisms as defined in [RFC5810]. >> >> How can this definition come from 3654 or 3746 when it has a = reference >> to 5810? > > 3654 and 3746 talked about the protocol in generalities. > 5810 talks about the protocol. It came later and is only added > there for sake of clarity of what we mean when we say PL. I have no issue with this text, per se. However, the top of the section = is pretty clear that it is supposed to be a restatement of 3654 and 3746. = You can't have this cake and eat it. >> Section 3 >> >>=A0 =A0To achieve CE High Availability (HA), FEs and CEs MUST = inter-operate >>=A0 =A0per [RFC5810] definition which is repeated for contextual = reasons in >>=A0 =A0Section 3.1. >> >> While you are repeating some of the material from 5810, you are also >> restating some of it in new words, and adding text. >> >> This gives a real problem with determining where the normative >> definition sits. We have to fix this! >>=20 >> Can you determine which sections are informational for this document >> and which contain new text? > > Ok, we'll review, however, note that there is intent in this = document=A0 > to provide clarity in what is prescribed in 5810.=A0 > This is stated in Section 2.1, to quote: > > " > The problem scope addressed by this document falls into 2 areas: >=A0 =A01. =A0To describe with more clarity (than [RFC5810]) how current = cold- >=A0 =A0 =A0 =A0standby approach operates within the NE cluster. >=A0 =A02. =A0To describe how to evolve the [RFC5810] cold-standby setup = to a >=A0 =A0 =A0 =A0hot-standby redundancy setup to improve the failover = time and NE >=A0 =A0 =A0 =A0availability. > " [snip] > The goal is for someone reading 5810 and not getting clarity on the cold-standby HA\ > to read this document instead. I think the part where you say "purely informational" > may be overriding that intent. OK. So it sounds (by point 1) like you *really* intend to update 5810 by providing new normative text for cold-standby. If that is the case, = let's go for it full-steam ahead! - metadata for updates 5810 - note in Abstract "This document updates RFC 5810 by doing foo" - paragraph in Introduction to explain the update - note in this section to say that this is a new normative description = that updates 5810 >> Section 3.1.1 has >> >>=A0 =A0The FE connects to the CE specified on FEPO CEID component. = =A0If it >>=A0 =A0fails to connect to the defined CE, it moves it to the bottom = of >>=A0 =A0table BackupCEs and sets its CEID component to be the first CE >>=A0 =A0retrieved from table BackupCEs. >> >> This is not a problem, but is unusual. In many redundancy cases, the >> primary object remains the favorite even when it has failed so that >> when there is a restoration opportunity (such as a failure of the new >> primary) it will resume its position as primary. > > Depends. I actually have seen the sticky prioritization scheme you = have described being > requested for, but that desire subsidises after we describe that we = =A0provide for the master > CE to change the mastership if the older CE shows =A0up again i.e = whatever the FE does > it could be overriden by the CE.=A0 OK, if it is a deliberate decision. Thanks for the work, Adrian From hadi@mojatatu.com Sat Jul 27 00:10:55 2013 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B69511E80D5 for ; Sat, 27 Jul 2013 00:10:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.677 X-Spam-Level: X-Spam-Status: No, score=-102.677 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, 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 xJGLLJvoHA-R for ; Sat, 27 Jul 2013 00:10:50 -0700 (PDT) Received: from mail-ve0-f170.google.com (mail-ve0-f170.google.com [209.85.128.170]) by ietfa.amsl.com (Postfix) with ESMTP id 3D04E21F889C for ; Sat, 27 Jul 2013 00:10:49 -0700 (PDT) Received: by mail-ve0-f170.google.com with SMTP id 14so1852762vea.29 for ; Sat, 27 Jul 2013 00:10:49 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=jn9HMAy8fhYhH/tcnmPlTfDz4GOxbVJwu68ABVGm1zA=; b=eXQohg4y/e0yIggLSTgWPidVmZjXPh0FtRlubdERWbt+DWpZ4llUtOnIxBoaLsbQZZ qDuCWDcmdr5CLJ/2LvLHB/0LBfUF+2gioISLqPANmnDfDJfJcsD43IviP48ZrYmYXGZF FRAvd5jB7+z+V/qQgAEgKw7MK1NyqJYyMeLdL8n45MGWxCXmJn+0SX/KLBUofj/rm2ku mLijzSlFuCRq85fERTVFf4x//22QCKvL/p1S0APoLPJ0SheyD7or4XknqZnPKXmrsgA4 44CnxqO2OYFXIzBQ8YW9lsC4XCPV7U7KmIa82PJ5zGUsaJW73xYbDdGb16KyffoFfazZ ApXg== X-Received: by 10.52.73.135 with SMTP id l7mr14301082vdv.9.1374909049207; Sat, 27 Jul 2013 00:10:49 -0700 (PDT) MIME-Version: 1.0 Received: by 10.58.247.197 with HTTP; Sat, 27 Jul 2013 00:10:29 -0700 (PDT) In-Reply-To: <000001ce896e$719cc370$54d64a50$@olddog.co.uk> References: <02b001ce884a$a1585040$e408f0c0$@olddog.co.uk> <000001ce896e$719cc370$54d64a50$@olddog.co.uk> From: Jamal Hadi Salim Date: Sat, 27 Jul 2013 03:10:29 -0400 Message-ID: To: Adrian Farrel Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQn87tV9S5NZBgKL8nC9X/0iKQi9UL0t5q6toItqvN7ueDpd4Slmdgq8SlOmMsnwYP/2hKu9 Cc: "forces@ietf.org" , draft-ietf-forces-ceha.all@tools.ietf.org Subject: Re: [forces] AD Review of draft-ietf-forces-ceha X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Jul 2013 07:10:55 -0000 On Thu, Jul 25, 2013 at 3:37 PM, Adrian Farrel wrote: > Hi Jamal, > > Cut down to issues for debate... > >> 3654 and 3746 talked about the protocol in generalities. >> 5810 talks about the protocol. It came later and is only added >> there for sake of clarity of what we mean when we say PL. > > I have no issue with this text, per se. However, the top of the section is > pretty clear that it is supposed to be a restatement of 3654 and 3746. You can't > have this cake and eat it. > We'll fix the text to clarify. >> " >> The problem scope addressed by this document falls into 2 areas: >> 1. To describe with more clarity (than [RFC5810]) how current cold- >> standby approach operates within the NE cluster. >> 2. To describe how to evolve the [RFC5810] cold-standby setup to a >> hot-standby redundancy setup to improve the failover time and NE >> availability. >> " > [snip] >> The goal is for someone reading 5810 and not getting clarity on the > cold-standby HA\ >> to read this document instead. I think the part where you say "purely > informational" >> may be overriding that intent. > > OK. So it sounds (by point 1) like you *really* intend to update 5810 by > providing new normative text for cold-standby. If that is the case, let's go for > it full-steam ahead! ok. > - metadata for updates 5810 > - note in Abstract "This document updates RFC 5810 by doing foo" > - paragraph in Introduction to explain the update > - note in this section to say that this is a new normative description that > updates 5810 > Thanks for catching this! Pretty sloppy of us. >> Depends. I actually have seen the sticky prioritization scheme you have > described being >> requested for, but that desire subsidises after we describe that we provide > for the master >> CE to change the mastership if the older CE shows up again i.e whatever the > FE does >> it could be overriden by the CE. > > OK, if it is a deliberate decision. > It is - when a CE dissappears in my experience at least it aint coming back soon (either taken down for repair, or hardware failure). So optimizing for that use case seemed reasonable (while providing a way for the CE to override the policy). cheers, jamal