From nobody Wed Aug 6 03:32:36 2014 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 398FB1B2D2C for ; Wed, 6 Aug 2014 03:32:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.191 X-Spam-Level: X-Spam-Status: No, score=-4.191 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DRUGS_MUSCLE=0.01, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wNH6Is9ySsvD for ; Wed, 6 Aug 2014 03:32:31 -0700 (PDT) Received: from inkolg01.tcs.com (inkolg01.tcs.com [121.241.215.10]) by ietfa.amsl.com (Postfix) with ESMTP id 425C21B2D26 for ; Wed, 6 Aug 2014 03:32:29 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.01,811,1400005800"; d="scan'208";a="565136828" Received: from INKOLSALDLPMTA1.india.tcs.com (unknown [127.0.0.1]) by INKOLSALDLPMTA1.india.tcs.com (Service) with ESMTP id B7189DAC12 for ; Wed, 6 Aug 2014 16:02:26 +0530 (IST) Received: from InKolM02.tcs.com (unknown [172.18.18.104]) by INKOLSALDLPMTA1.india.tcs.com (Service) with ESMTP id 88909DAC02 for ; Wed, 6 Aug 2014 16:02:26 +0530 (IST) MIME-Version: 1.0 Importance: Normal X-Priority: 3 (Normal) In-Reply-To: <20140806101420.2243.22999.idtracker@ietfa.amsl.com> References: <20140806101420.2243.22999.idtracker@ietfa.amsl.com> From: Abhijan Bhattacharyya To: core@ietf.org Message-ID: Date: Wed, 6 Aug 2014 16:02:25 +0530 X-Mailer: Lotus Domino Web Server Release 9.0.1HF198 January 23, 2014 X-MIMETrack: Serialize by Notes Server on InKolM02/TCS(Release 9.0.1HF198 | January 23, 2014) at 08/06/2014 16:02:25, Serialize complete at 08/06/2014 16:02:25, Itemize by Notes Server on InKolM02/TCS(Release 9.0.1HF198 | January 23, 2014) at 08/06/2014 16:02:25, Serialize by Notes Server on InKolM02/TCS(Release 9.0.1HF198 | January 23, 2014) at 08/06/2014 16:02:26, Serialize complete at 08/06/2014 16:02:26, Serialize by Router on InKolM02/TCS(Release 9.0.1HF198 | January 23, 2014) at 08/06/2014 16:02:26 Content-Type: multipart/alternative; boundary="=_alternative 0039E64C65257D2C_=" Archived-At: http://mailarchive.ietf.org/arch/msg/core/Ku0fadVJ6MJO4h9X0EQT_fFS8oE Cc: Arpan Pal Subject: [core] draft-tcs-coap-no-response-option-07 : Call for WG adoption X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Aug 2014 10:32:34 -0000 --=_alternative 0039E64C65257D2C_= MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, We have submitted a new version of the No-Response draft. Several editorial= corrections have been made. The references have been updated and enhanced.= A number for the option has been suggested for IANA consideration . As there has been continuity of interest in the mailing list discussions an= d also during the last three WG meetings, may we now ask for the opinion of= the Working Group on adoption of the draft please.=A0 Regards Abhijan Bhattacharyya Associate Consultant Scientist, Innovation Lab, Kolkata, India Tata Consultancy Services Limited Mailto: abhijan.bhattacharyya@tcs.com Website: http://www.tcs.com ____________________________________________ Experience certainty. IT Services Business Solutions Consulting ____________________________________________ -----internet-drafts@ietf.org wrote: ----- To: Soma Bandyopadhyay , "Abhijan Bhattacharyya= " , "Arpan Pal" , Arpan P= al , "Soma Bandyopadhyay" , = Abhijan Bhattacharyya From: internet-drafts@ietf.org Date: 08/06/2014 03:44PM Subject: New Version Notification for draft-tcs-coap-no-response-option-07.= txt A new version of I-D, draft-tcs-coap-no-response-option-07.txt has been successfully submitted by Abhijan Bhattacharyya and posted to the IETF repository. Name: draft-tcs-coap-no-response-option Revision: 07 Title: CoAP option for no server-response Document date: 2014-08-05 Group: Individual Submission Pages: 18 URL: =A0 =A0 =A0 =A0 =A0 =A0http://www.ietf.org/internet-drafts/draft-tcs-c= oap-no-response-option-07.txt Status: =A0 =A0 =A0 =A0 https://datatracker.ietf.org/doc/draft-tcs-coap-no-= response-option/ Htmlized: =A0 =A0 =A0 http://tools.ietf.org/html/draft-tcs-coap-no-response= -option-07 Diff: =A0 =A0 =A0 =A0 =A0 http://www.ietf.org/rfcdiff?url2=3Ddraft-tcs-coap= -no-response-option-07 Abstract: =A0=A0 There can be typical M2M scenarios where responses from the data =A0=A0 sink to the data source against request from the source might be =A0=A0 considered redundant. This kind of open-loop exchange (with no =A0=A0 reverse path from the sink to the source) may be desired while =A0=A0 updating resources in constrained systems looking for maximized =A0=A0 throughput with minimized resource consumption. CoAP already =A0=A0 provides a non-confirmable (NON) mode of exchange where the =A0=A0 receiving end-point does not respond with ACK. However, the =A0=A0 receiving end-point responds the sender with a status code =A0=A0 indicating "the result of the attempt to understand and satisfy the =A0=A0 request". =A0=A0 This draft introduces a header option: 'No-Response' to suppress =A0=A0 responses from the receiver and discusses exemplary use cases which =A0=A0 motivated this proposition based on real experience. This option =A0=A0 also provides granularity by allowing suppression of a typical class =A0=A0 or a combination of classes of responses. This option may be =A0=A0 effective for both unicast and multicast scenarios. =A0=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat =3D=3D=3D=3D=3D-----=3D=3D=3D=3D=3D-----=3D=3D=3D=3D=3D Notice: The information contained in this e-mail message and/or attachments to it may contain = confidential or privileged information. If you are = not the intended recipient, any dissemination, use, = review, distribution, printing or copying of the = information contained in this e-mail message = and/or attachments to it are strictly prohibited. If = you have received this communication in error, = please notify us by reply e-mail or telephone and = immediately and permanently delete the message = and any attachments. Thank you --=_alternative 0039E64C65257D2C_= Content-ID: <> MIME-Version: 1.0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi,
We have submitted a new version of the No-Respons= e draft. Several editorial corrections have been made. The references have = been updated and enhanced. A number for the option has been suggested for I= ANA consideration .
As there has been continuity of interest in t= he mailing list discussions and also during the last three WG meetings, may= we now ask for the opinion of the Working Group on adoption of the draft p= lease. 


Regards
Abhijan Bhattacharyya
Associate Consu= ltant
Scientist, Innovation Lab, Kolkata, India
Tata Consultancy Serv= ices Limited
Mailto: ab= hijan.bhattacharyya@tcs.com
Website: = http://www.tcs.com
____________________________________________
E= xperience certainty. IT Services
Business Solutions
Consulting<= br>____________________________________________


-----internet-drafts@ietf.org wrote: -----
To: Soma Bandyopadhyay <som= a.bandyopadhyay@tcs.com>, "Abhijan Bhattacharyya" <abhijan.bhattachar= yya@tcs.com>, "Arpan Pal" <arpan.pal@tcs.com>, Arpan Pal <arpan= .pal@tcs.com>, "Soma Bandyopadhyay" <soma.bandyopadhyay@tcs.com>, = Abhijan Bhattacharyya <abhijan.bhattacharyya@tcs.com>
From: intern= et-drafts@ietf.org
Date: 08/06/2014 03:44PM
Subject: New Version Noti= fication for draft-tcs-coap-no-response-option-07.txt

A new version of I-D, draft-= tcs-coap-no-response-option-07.txt
has been successfully submitted by Ab= hijan Bhattacharyya and posted to the
IETF repository.

Name: dra= ft-tcs-coap-no-response-option
Revision: 07
Title: CoAP option for n= o server-response
Document date: 2014-08-05
Group: Individual Submis= sion
Pages: 18
URL:            http://www.ietf.org/internet-drafts/draft-tcs-coap-no-response-optio= n-07.txt
Status:         https://datatracke= r.ietf.org/doc/draft-tcs-coap-no-response-option/
Htmlized:   &= nbsp;   http://tools.ietf.org/html/draft-tcs-coap-no-response-option-= 07
Diff:           http://www.ietf= .org/rfcdiff?url2=3Ddraft-tcs-coap-no-response-option-07

Abstrac= t:
   There can be typical M2M scenarios where responses from = the data
   sink to the data source against request from the s= ource might be
   considered redundant. This kind of open-loop= exchange (with no
   reverse path from the sink to the source= ) may be desired while
   updating resources in constrained sy= stems looking for maximized
   throughput with minimized resou= rce consumption. CoAP already
   provides a non-confirmable (N= ON) mode of exchange where the
   receiving end-point does not= respond with ACK. However, the
   receiving end-point respond= s the sender with a status code
   indicating "the result of t= he attempt to understand and satisfy the
   request".

&= nbsp;  This draft introduces a header option: 'No-Response' to suppres= s
   responses from the receiver and discusses exemplary use c= ases which
   motivated this proposition based on real experie= nce. This option
   also provides granularity by allowing supp= ression of a typical class
   or a combination of classes of r= esponses. This option may be
   effective for both unicast and= multicast scenarios.

            = ;                     &nb= sp;                     &= nbsp;                    =      


Please note that it may take a couple of m= inutes from the time of submission
until the htmlized version and diff a= re available at tools.ietf.org.

The IETF Secretariat

<= /div>

=3D=3D=3D=3D=3D-----=3D=3D=3D=3D=3D-----=3D=3D= =3D=3D=3D
Notice: The information contained in this e-mail
message and/or attachments to it may contain
confidential or privileged information. If you are
not the intended recipient, any dissemination, use,
review, distribution, printing or copying of the
information contained in this e-mail message
and/or attachments to it are strictly prohibited. If
you have received this communication in error,
please notify us by reply e-mail or telephone and
immediately and permanently delete the message
and any attachments. Thank you

--=_alternative 0039E64C65257D2C_=-- From nobody Wed Aug 6 07:38:53 2014 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8502E1B2D4E for ; Wed, 6 Aug 2014 07:38:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.89 X-Spam-Level: X-Spam-Status: No, score=-1.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DRUGS_MUSCLE=0.01, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4hDlagUF2EwW for ; Wed, 6 Aug 2014 07:38:47 -0700 (PDT) Received: from smtp-in1.interdigital.com (smtp-in1.interdigital.com [64.208.228.133]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BAB1E1B2D4C for ; Wed, 6 Aug 2014 07:38:47 -0700 (PDT) X-ASG-Debug-ID: 1407335925-06daaa1c7f22de0001-aa7cYp Received: from smtp-out1.interdigital.com (sahara.interdigital.com [10.0.128.27]) by smtp-in1.interdigital.com with ESMTP id 612DLyUcj1Yk0uSx for ; Wed, 06 Aug 2014 10:38:45 -0400 (EDT) X-Barracuda-Envelope-From: Akbar.Rahman@InterDigital.com Received: from SAM.InterDigital.com ([10.30.2.11]) by smtp-out1.interdigital.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 6 Aug 2014 10:38:44 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CFB184.1FED70B0" Date: Wed, 6 Aug 2014 10:38:43 -0400 X-ASG-Orig-Subj: RE: [core] draft-tcs-coap-no-response-option-07 : Call for WG adoption Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [core] draft-tcs-coap-no-response-option-07 : Call for WG adoption Thread-Index: Ac+xYb0VX+BB1rfERx6J3uzzSFDW3gAIjiyg References: <20140806101420.2243.22999.idtracker@ietfa.amsl.com> From: "Rahman, Akbar" To: "Abhijan Bhattacharyya" , X-OriginalArrivalTime: 06 Aug 2014 14:38:44.0827 (UTC) FILETIME=[2008A2B0:01CFB184] X-Barracuda-Connect: sahara.interdigital.com[10.0.128.27] X-Barracuda-Start-Time: 1407335925 X-Barracuda-URL: http://10.1.245.3:8000/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at interdigital.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=9.0 tests=DRUGS_MUSCLE, HTML_MESSAGE X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.8178 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 HTML_MESSAGE BODY: HTML included in message 0.00 DRUGS_MUSCLE Refers to a muscle relaxant Archived-At: http://mailarchive.ietf.org/arch/msg/core/HrVyMJjJw9tnPmgLzLN0ZKH119I Cc: Arpan Pal Subject: Re: [core] draft-tcs-coap-no-response-option-07 : Call for WG adoption X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Aug 2014 14:38:50 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CFB184.1FED70B0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Abhijan, =20 =20 +1 =20 As I said in IETF-Toronto, I think that this is a nice value added feature to have in CoAP. =20 =20 Best Regards, =20 =20 Akbar =20 From: core [mailto:core-bounces@ietf.org] On Behalf Of Abhijan Bhattacharyya Sent: Wednesday, August 06, 2014 6:32 AM To: core@ietf.org Cc: Arpan Pal Subject: [core] draft-tcs-coap-no-response-option-07 : Call for WG adoption =20 Hi, We have submitted a new version of the No-Response draft. Several editorial corrections have been made. The references have been updated and enhanced. A number for the option has been suggested for IANA consideration . As there has been continuity of interest in the mailing list discussions and also during the last three WG meetings, may we now ask for the opinion of the Working Group on adoption of the draft please.=20 Regards Abhijan Bhattacharyya Associate Consultant Scientist, Innovation Lab, Kolkata, India Tata Consultancy Services Limited Mailto: abhijan.bhattacharyya@tcs.com Website: http://www.tcs.com ____________________________________________ Experience certainty. IT Services Business Solutions Consulting ____________________________________________ -----internet-drafts@ietf.org wrote: ----- To: Soma Bandyopadhyay , "Abhijan Bhattacharyya" , "Arpan Pal" , Arpan Pal , "Soma Bandyopadhyay" , Abhijan Bhattacharyya From: internet-drafts@ietf.org Date: 08/06/2014 03:44PM Subject: New Version Notification for draft-tcs-coap-no-response-option-07.txt A new version of I-D, draft-tcs-coap-no-response-option-07.txt has been successfully submitted by Abhijan Bhattacharyya and posted to the IETF repository. Name: draft-tcs-coap-no-response-option Revision: 07 Title: CoAP option for no server-response Document date: 2014-08-05 Group: Individual Submission Pages: 18 URL: http://www.ietf.org/internet-drafts/draft-tcs-coap-no-response-option-07 .txt Status: https://datatracker.ietf.org/doc/draft-tcs-coap-no-response-option/ Htmlized: http://tools.ietf.org/html/draft-tcs-coap-no-response-option-07 Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-tcs-coap-no-response-option-07 Abstract: There can be typical M2M scenarios where responses from the data sink to the data source against request from the source might be considered redundant. This kind of open-loop exchange (with no reverse path from the sink to the source) may be desired while updating resources in constrained systems looking for maximized throughput with minimized resource consumption. CoAP already provides a non-confirmable (NON) mode of exchange where the receiving end-point does not respond with ACK. However, the receiving end-point responds the sender with a status code indicating "the result of the attempt to understand and satisfy the request". This draft introduces a header option: 'No-Response' to suppress responses from the receiver and discusses exemplary use cases which motivated this proposition based on real experience. This option also provides granularity by allowing suppression of a typical class or a combination of classes of responses. This option may be effective for both unicast and multicast scenarios. =20 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat =3D=3D=3D=3D=3D-----=3D=3D=3D=3D=3D-----=3D=3D=3D=3D=3D Notice: The information contained in this e-mail message and/or attachments to it may contain=20 confidential or privileged information. If you are=20 not the intended recipient, any dissemination, use,=20 review, distribution, printing or copying of the=20 information contained in this e-mail message=20 and/or attachments to it are strictly prohibited. If=20 you have received this communication in error,=20 please notify us by reply e-mail or telephone and=20 immediately and permanently delete the message=20 and any attachments. Thank you ------_=_NextPart_001_01CFB184.1FED70B0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Abhijan,

 

 

+1

 

As I said in IETF-Toronto, I think that this is a nice value added = feature to have in CoAP.

 

 

Best Regards,

 

 

Akbar

 

From:= = core [mailto:core-bounces@ietf.org] On Behalf Of Abhijan = Bhattacharyya
Sent: Wednesday, August 06, 2014 6:32 = AM
To: core@ietf.org
Cc: Arpan = Pal
Subject: [core] draft-tcs-coap-no-response-option-07 : = Call for WG adoption

 

Hi,

We have = submitted a new version of the No-Response draft. Several editorial = corrections have been made. The references have been updated and = enhanced. A number for the option has been suggested for IANA = consideration .

As there = has been continuity of interest in the mailing list discussions and also = during the last three WG meetings, may we now ask for the opinion of the = Working Group on adoption of the draft = please. 


Regards
Abhijan Bhattacharyya
Associate = Consultant
Scientist, Innovation Lab, Kolkata, India
Tata = Consultancy Services Limited
Mailto: abhijan.bhattacharyya@tcs.c= om
Website: http://www.tcs.com
___________________= _________________________
Experience certainty. IT = Services
Business = Solutions
Consulting
____________________________________________



-----internet-drafts@ietf.o= rg wrote: -----

To: Soma = Bandyopadhyay <soma.bandyopadhyay@tcs.com= >, "Abhijan Bhattacharyya" <abhijan.bhattacharyya@tcs.c= om>, "Arpan Pal" <arpan.pal@tcs.com>, Arpan Pal = <arpan.pal@tcs.com>, = "Soma Bandyopadhyay" <soma.bandyopadhyay@tcs.com= >, Abhijan Bhattacharyya <abhijan.bhattacharyya@tcs.c= om>
From: internet-drafts@ietf.org
= Date: 08/06/2014 03:44PM
Subject: New Version Notification for = draft-tcs-coap-no-response-option-07.txt

A new version of I-D, = draft-tcs-coap-no-response-option-07.txt
has been successfully = submitted by Abhijan Bhattacharyya and posted to the
IETF = repository.

Name: draft-tcs-coap-no-response-option
Revision: = 07
Title: CoAP option for no server-response
Document date: = 2014-08-05
Group: Individual Submission
Pages: 18
URL:   =          http://www.ietf.org/internet-drafts/draft-tcs-coap-no-respon= se-option-07.txt
Status:         https://datatracker.ietf.org/doc/draft-tcs-coap-no-response-option/
Htmlized:       = http://tools.ietf.org/html/draft-tcs-coap-no-response-option-07
Di= ff:           http://www.ietf.org/rfcdiff?url2=3Ddraft-tcs-coap-no-response-opt= ion-07

Abstract:
   There can be typical M2M = scenarios where responses from the data
   sink to the data = source against request from the source might be
   = considered redundant. This kind of open-loop exchange (with = no
   reverse path from the sink to the source) may be = desired while
   updating resources in constrained systems = looking for maximized
   throughput with minimized resource = consumption. CoAP already
   provides a non-confirmable = (NON) mode of exchange where the
   receiving end-point = does not respond with ACK. However, the
   receiving = end-point responds the sender with a status code
   = indicating "the result of the attempt to understand and satisfy = the
   request".

   This draft = introduces a header option: 'No-Response' to suppress
   = responses from the receiver and discusses exemplary use cases = which
   motivated this proposition based on real = experience. This option
   also provides granularity by = allowing suppression of a typical class
   or a combination = of classes of responses. This option may be
   effective = for both unicast and multicast scenarios.

     =                     =                     =                     =                 =  


Please note that it may take a couple of minutes from = the time of submission
until the htmlized version and diff are = available at tools.ietf.org.

The IETF Secretariat=

=3D=3D=3D=3D=3D-----=3D=3D=3D=3D=3D-----=3D= =3D=3D=3D=3D
Notice: The information contained in this = e-mail
message and/or attachments to it may contain
confidential = or privileged information. If you are
not the intended recipient, = any dissemination, use,
review, distribution, printing or copying of = the
information contained in this e-mail message
and/or = attachments to it are strictly prohibited. If
you have received this = communication in error,
please notify us by reply e-mail or = telephone and
immediately and permanently delete the message
and = any attachments. Thank you

------_=_NextPart_001_01CFB184.1FED70B0-- From nobody Wed Aug 6 11:43:29 2014 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D7761B27B3 for ; Wed, 6 Aug 2014 11:43:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.691 X-Spam-Level: X-Spam-Status: No, score=-3.691 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DRUGS_MUSCLE=0.01, HTML_MESSAGE=0.001, MIME_BAD_LINEBREAK=0.5, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uP2rz-rcDd1N for ; Wed, 6 Aug 2014 11:43:11 -0700 (PDT) Received: from inkolg01.tcs.com (inkolg01.tcs.com [121.241.215.10]) by ietfa.amsl.com (Postfix) with ESMTP id 2E32E1B27AD for ; Wed, 6 Aug 2014 11:43:08 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.01,813,1400005800"; d="scan'208,217";a="565370294" X-DISCLAIMER: FALSE Received: from INKOLSALDLPMTA1.india.tcs.com (unknown [127.0.0.1]) by INKOLSALDLPMTA1.india.tcs.com (Service) with ESMTP id E282EDAC12; Thu, 7 Aug 2014 00:13:06 +0530 (IST) Received: from InKolM02.tcs.com (unknown [172.18.18.104]) by INKOLSALDLPMTA1.india.tcs.com (Service) with ESMTP id ADD08DAC02; Thu, 7 Aug 2014 00:13:06 +0530 (IST) MIME-Version: 1.0 Importance: Normal X-Priority: 3 (Normal) In-Reply-To: References: , <20140806101420.2243.22999.idtracker@ietfa.amsl.com> From: Abhijan Bhattacharyya To: "Rahman, Akbar" Message-ID: Date: Thu, 7 Aug 2014 00:13:04 +0530 X-Mailer: Lotus Domino Web Server Release 9.0.1HF198 January 23, 2014 X-MIMETrack: Serialize by Notes Server on InKolM02/TCS(Release 9.0.1HF198 | January 23, 2014) at 08/07/2014 00:13:04, Serialize complete at 08/07/2014 00:13:04, Itemize by Notes Server on InKolM02/TCS(Release 9.0.1HF198 | January 23, 2014) at 08/07/2014 00:13:04, Serialize by Notes Server on InKolM02/TCS(Release 9.0.1HF198 | January 23, 2014) at 08/07/2014 00:13:05, Serialize complete at 08/07/2014 00:13:05, Serialize by Router on InKolM02/TCS(Release 9.0.1HF198 | January 23, 2014) at 08/07/2014 00:13:05 Content-Type: multipart/alternative; boundary="=_alternative 0066D1EA65257D2C_=" Archived-At: http://mailarchive.ietf.org/arch/msg/core/DNL4qaPuN29xfgUKIqtz-zrFFJA Cc: Arpan Pal , core@ietf.org Subject: Re: [core] draft-tcs-coap-no-response-option-07 : Call for WG adoption X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Aug 2014 18:43:20 -0000 --=_alternative 0066D1EA65257D2C_= Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=ISO-8859-1 Hi Akbar, Thanks for your response. Regards Abhijan Bhattacharyya Associate Consultant Scientist, Innovation Lab, Kolkata, India Tata Consultancy Services Limited Mailto: abhijan.bhattacharyya@tcs.com Website: http://www.tcs.com =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F Experience certainty. IT Services Business Solutions Consulting =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F -----"Rahman, Akbar" wrote: ----- To: "Abhijan Bhattacharyya" , From: "Rahman, Akbar" Date: 08/06/2014 08:08PM Cc: "Arpan Pal" Subject: RE: [core] draft-tcs-coap-no-response-option-07 : Call for WG adop= tion Hi Abhijan, =A0 =A0 +1 =A0 As I said in IETF-Toronto, I think that this is a nice value added feature = to have in CoAP. =A0 =A0 Best Regards, =A0 =A0 Akbar =A0 From: core [mailto:core-bounces@ietf.org] On Behalf Of Abhijan Bhattacharyya Sent: Wednesday, August 06, 2014 6:32 AM To: core@ietf.org Cc: Arpan Pal Subject: [core] draft-tcs-coap-no-response-option-07 : Call for WG adoption =A0 Hi, We have submitted a new version of the No-Response draft. Several editorial= corrections have been made. The references have been updated and enhanced.= A number for the option has been suggested for IANA consideration . As there has been continuity of interest in the mailing list discussions an= d also during the last three WG meetings, may we now ask for the opinion of= the Working Group on adoption of the draft please.=A0 Regards Abhijan Bhattacharyya Associate Consultant Scientist, Innovation Lab, Kolkata, India Tata Consultancy Services Limited Mailto: abhijan.bhattacharyya@tcs.com Website: http://www.tcs.com =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F Experience certainty. IT Services Business Solutions Consulting =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F -----internet-drafts@ietf.org wrote: ----- To: Soma Bandyopadhyay , "Abhijan Bhattacharyya= " , "Arpan Pal" , Arpan P= al , "Soma Bandyopadhyay" , = Abhijan Bhattacharyya From: internet-drafts@ietf.org Date: 08/06/2014 03:44PM Subject: New Version Notification for draft-tcs-coap-no-response-option-07.= txt A new version of I-D, draft-tcs-coap-no-response-option-07.txt has been successfully submitted by Abhijan Bhattacharyya and posted to the IETF repository. Name: draft-tcs-coap-no-response-option Revision: 07 Title: CoAP option for no server-response Document date: 2014-08-05 Group: Individual Submission Pages: 18 URL: =A0 =A0 =A0 =A0 =A0 =A0http://www.ietf.org/internet-drafts/draft-tcs-c= oap-no-response-option-07.txt Status: =A0 =A0 =A0 =A0 https://datatracker.ietf.org/doc/draft-tcs-coap-no-= response-option/ Htmlized: =A0 =A0 =A0 http://tools.ietf.org/html/draft-tcs-coap-no-response= -option-07 Diff: =A0 =A0 =A0 =A0 =A0 http://www.ietf.org/rfcdiff?url2=3Ddraft-tcs-coap= -no-response-option-07 Abstract: =A0=A0 There can be typical M2M scenarios where responses from the data =A0=A0 sink to the data source against request from the source might be =A0=A0 considered redundant. This kind of open-loop exchange (with no =A0=A0 reverse path from the sink to the source) may be desired while =A0=A0 updating resources in constrained systems looking for maximized =A0=A0 throughput with minimized resource consumption. CoAP already =A0=A0 provides a non-confirmable (NON) mode of exchange where the =A0=A0 receiving end-point does not respond with ACK. However, the =A0=A0 receiving end-point responds the sender with a status code =A0=A0 indicating "the result of the attempt to understand and satisfy the =A0=A0 request". =A0=A0 This draft introduces a header option: 'No-Response' to suppress =A0=A0 responses from the receiver and discusses exemplary use cases which =A0=A0 motivated this proposition based on real experience. This option =A0=A0 also provides granularity by allowing suppression of a typical class =A0=A0 or a combination of classes of responses. This option may be =A0=A0 effective for both unicast and multicast scenarios. =A0=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat =3D=3D=3D=3D=3D-----=3D=3D=3D=3D=3D-----=3D=3D=3D=3D=3D Notice: The information contained in this e-mail message and/or attachments to it may contain=20 confidential or privileged information. If you are=20 not the intended recipient, any dissemination, use,=20 review, distribution, printing or copying of the=20 information contained in this e-mail message=20 and/or attachments to it are strictly prohibited. If=20 you have received this communication in error,=20 please notify us by reply e-mail or telephone and=20 immediately and permanently delete the message=20 and any attachments. Thank you --=_alternative 0066D1EA65257D2C_= Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1 Content-ID: <>
Hi Akbar,
Thanks for your response.


Regard= s
Abhijan Bhattacharyya
Associate Consultant
Scientist, Innovation= Lab, Kolkata, India
Tata Consultancy Services Limited
Mailto: abhijan.bhattacharyya@tcs.com
Website: http://www.tcs.com
=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
Experience certai= nty. IT Services
Business Solutions
Consulting
=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F


-----"Rahman, Akbar" <Akbar.Rahman@InterDigital.com> wrote: -= ----
To:= "Abhijan Bhattacharyya" <abhijan.bhattacharyya@tcs.com>, <core@ie= tf.org>
From: "Rahman, Akbar" <Akbar.Rahman@InterDigital.com>Date: 08/06/2014 08:08PM
Cc: "Arpan Pal" <arpan.pal@tcs.com>
= Subject: RE: [core] draft-tcs-coap-no-response-option-07 : Call for WG adop= tion

Hi Abhijan,

 

 

+1

 

As I said in IETF-Toronto, I think that this= is a nice value added feature to have in CoAP.

 

=

 

<= p class=3D"MsoNormal">Best Regards,

 =

 <= /p>

Akbar

 

=

From: core [ma= ilto:core-bounces@ietf.org] On Behalf Of Abhijan Bhattacharyya
Sent: Wednesday, August 06, 2014 6:32 AM
To: core@ietf.orgCc: Arpan Pal
Subject: [core] draft-tcs-coap-no-response= -option-07 : Call for WG adoption

 

Hi,

We have submi= tted a new version of the No-Response draft. Several editorial corrections = have been made. The references have been updated and enhanced. A number for= the option has been suggested for IANA consideration .

As there has been continui= ty of interest in the mailing list discussions and also during the last thr= ee WG meetings, may we now ask for the opinion of the Working Group on adop= tion of the draft please. 


Regards
Abhijan Bhattacharyya=
Associate Consultant
Scientist, Innovation Lab, Kolkata, India
Ta= ta Consultancy Services Limited
Mailto: abhijan.bhattacharyya@tcs.com
Website: http://www.tcs.com
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F
Experience certainty. IT Services
Busines= s Solutions
Consulting
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F



-----internet-drafts@ietf.org wrote: -----

= To: Soma Bandyopadhyay <soma.bandyopadhyay@tcs.com>, "Abhijan Bhattacharyya" <= abhijan.bhattacharyya@tcs.= com>, "Arpan Pal" <arpan.pal= @tcs.com>, Arpan Pal <arpan.= pal@tcs.com>, "Soma Bandyopadhyay" <soma.bandyopadhyay@tcs.com>, Abhijan Bhattacharyya = <abhijan.bhattacharyya@= tcs.com>
From: intern= et-drafts@ietf.org
Date: 08/06/2014 03:44PM
Subject: New Version = Notification for draft-tcs-coap-no-response-option-07.txt=

A new version of I-D, draft-tcs-co= ap-no-response-option-07.txt
has been successfully submitted by Abhijan = Bhattacharyya and posted to the
IETF repository.

Name: draft-tcs-= coap-no-response-option
Revision: 07
Title: CoAP option for no server= -response
Document date: 2014-08-05
Group: Individual Submission
P= ages: 18
URL:            htt= p://www.ietf.org/internet-drafts/draft-tcs-coap-no-response-option-07.txt
Status:         https://datatracker.ietf.org= /doc/draft-tcs-coap-no-response-option/
Htmlized:     &nbs= p; http://tools.ietf.org/html/draft-tcs-coap-no-response-option-07
= Diff:           http://www.ietf.org/rfcdi= ff?url2=3Ddraft-tcs-coap-no-response-option-07

Abstract:
&nbs= p;  There can be typical M2M scenarios where responses from the data   sink to the data source against request from the source migh= t be
   considered redundant. This kind of open-loop exchange = (with no
   reverse path from the sink to the source) may be d= esired while
   updating resources in constrained systems look= ing for maximized
   throughput with minimized resource consum= ption. CoAP already
   provides a non-confirmable (NON) mode o= f exchange where the
   receiving end-point does not respond w= ith ACK. However, the
   receiving end-point responds the send= er with a status code
   indicating "the result of the attempt= to understand and satisfy the
   request".

  = ; This draft introduces a header option: 'No-Response' to suppress
 = ;  responses from the receiver and discusses exemplary use cases which=
   motivated this proposition based on real experience. This = option
   also provides granularity by allowing suppression of= a typical class
   or a combination of classes of responses. = This option may be
   effective for both unicast and multicast= scenarios.

               &= nbsp;                    =                     &nbs= p;                     &n= bsp;  


Please note that it may take a couple of minutes fro= m the time of submission
until the htmlized version and diff are availab= le at tools.ietf.org.

The IETF Secretariat<= /o:p>

=3D=3D=3D=3D=3D-----=3D=3D=3D=3D=3D---= --=3D=3D=3D=3D=3D
Notice: The information contained in this e-mail
me= ssage and/or attachments to it may contain
confidential or privileged i= nformation. If you are
not the intended recipient, any dissemination, u= se,
review, distribution, printing or copying of the
information co= ntained in this e-mail message
and/or attachments to it are strictly pr= ohibited. If
you have received this communication in error,
please = notify us by reply e-mail or telephone and
immediately and permanently = delete the message
and any attachments. Thank you

<= /div>
 --=_alternative 0066D1EA65257D2C_=-- From nobody Wed Aug 6 17:18:05 2014 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 975621A0313 for ; Wed, 6 Aug 2014 17:18:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.741 X-Spam-Level: X-Spam-Status: No, score=-1.741 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DRUGS_MUSCLE=0.01, HTML_MESSAGE=0.001, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7hrIoxkRXDoD for ; Wed, 6 Aug 2014 17:17:58 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C7CD01A02E6 for ; Wed, 6 Aug 2014 17:17:57 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml405-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BHZ37358; Thu, 07 Aug 2014 00:17:56 +0000 (GMT) Received: from SZXEMA406-HUB.china.huawei.com (10.82.72.38) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 7 Aug 2014 01:17:52 +0100 Received: from SZXEMA501-MBS.china.huawei.com ([169.254.2.128]) by SZXEMA406-HUB.china.huawei.com ([10.82.72.38]) with mapi id 14.03.0158.001; Thu, 7 Aug 2014 08:17:48 +0800 From: Likepeng To: Abhijan Bhattacharyya , "core@ietf.org" Thread-Topic: [core] draft-tcs-coap-no-response-option-07 : Call for WG adoption Thread-Index: AQHPsWHHKnwHsr39xUCBDIvs6zKFoJvERxLA Date: Thu, 7 Aug 2014 00:17:47 +0000 Message-ID: <34966E97BE8AD64EAE9D3D6E4DEE36F25818052E@SZXEMA501-MBS.china.huawei.com> References: <20140806101420.2243.22999.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.167.122] Content-Type: multipart/alternative; boundary="_000_34966E97BE8AD64EAE9D3D6E4DEE36F25818052ESZXEMA501MBSchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/core/gFA29S3l7k30kmh61zhBMTVvEpM Cc: Arpan Pal Subject: Re: [core] draft-tcs-coap-no-response-option-07 : Call for WG adoption X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Aug 2014 00:18:01 -0000 --_000_34966E97BE8AD64EAE9D3D6E4DEE36F25818052ESZXEMA501MBSchi_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 KzEuDQoNCkl0IGlzIHNpbXBsZSBhbmQgdXNlZnVsLg0KDQpLaW5kIFJlZ2FyZHMNCktlcGVuZw0K DQq3orz+yMs6IGNvcmUgW21haWx0bzpjb3JlLWJvdW5jZXNAaWV0Zi5vcmddILT6se0gQWJoaWph biBCaGF0dGFjaGFyeXlhDQq3osvNyrG85DogMjAxNMTqONTCNsjVIDE4OjMyDQrK1bz+yMs6IGNv cmVAaWV0Zi5vcmcNCrOty806IEFycGFuIFBhbA0K1vfM4jogW2NvcmVdIGRyYWZ0LXRjcy1jb2Fw LW5vLXJlc3BvbnNlLW9wdGlvbi0wNyA6IENhbGwgZm9yIFdHIGFkb3B0aW9uDQoNCkhpLA0KV2Ug aGF2ZSBzdWJtaXR0ZWQgYSBuZXcgdmVyc2lvbiBvZiB0aGUgTm8tUmVzcG9uc2UgZHJhZnQuIFNl dmVyYWwgZWRpdG9yaWFsIGNvcnJlY3Rpb25zIGhhdmUgYmVlbiBtYWRlLiBUaGUgcmVmZXJlbmNl cyBoYXZlIGJlZW4gdXBkYXRlZCBhbmQgZW5oYW5jZWQuIEEgbnVtYmVyIGZvciB0aGUgb3B0aW9u IGhhcyBiZWVuIHN1Z2dlc3RlZCBmb3IgSUFOQSBjb25zaWRlcmF0aW9uIC4NCkFzIHRoZXJlIGhh cyBiZWVuIGNvbnRpbnVpdHkgb2YgaW50ZXJlc3QgaW4gdGhlIG1haWxpbmcgbGlzdCBkaXNjdXNz aW9ucyBhbmQgYWxzbyBkdXJpbmcgdGhlIGxhc3QgdGhyZWUgV0cgbWVldGluZ3MsIG1heSB3ZSBu b3cgYXNrIGZvciB0aGUgb3BpbmlvbiBvZiB0aGUgV29ya2luZyBHcm91cCBvbiBhZG9wdGlvbiBv ZiB0aGUgZHJhZnQgcGxlYXNlLg0KDQoNClJlZ2FyZHMNCkFiaGlqYW4gQmhhdHRhY2hhcnl5YQ0K QXNzb2NpYXRlIENvbnN1bHRhbnQNClNjaWVudGlzdCwgSW5ub3ZhdGlvbiBMYWIsIEtvbGthdGEs IEluZGlhDQpUYXRhIENvbnN1bHRhbmN5IFNlcnZpY2VzIExpbWl0ZWQNCk1haWx0bzogYWJoaWph bi5iaGF0dGFjaGFyeXlhQHRjcy5jb208bWFpbHRvOmFiaGlqYW4uYmhhdHRhY2hhcnl5YUB0Y3Mu Y29tPg0KV2Vic2l0ZTogaHR0cDovL3d3dy50Y3MuY29tDQpfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXw0KRXhwZXJpZW5jZSBjZXJ0YWludHkuIElUIFNlcnZpY2Vz DQpCdXNpbmVzcyBTb2x1dGlvbnMNCkNvbnN1bHRpbmcNCl9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQoNCg0KLS0tLS1pbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc8 bWFpbHRvOi0tLS0taW50ZXJuZXQtZHJhZnRzQGlldGYub3JnPiB3cm90ZTogLS0tLS0NClRvOiBT b21hIEJhbmR5b3BhZGh5YXkgPHNvbWEuYmFuZHlvcGFkaHlheUB0Y3MuY29tPG1haWx0bzpzb21h LmJhbmR5b3BhZGh5YXlAdGNzLmNvbT4+LCAiQWJoaWphbiBCaGF0dGFjaGFyeXlhIiA8YWJoaWph bi5iaGF0dGFjaGFyeXlhQHRjcy5jb208bWFpbHRvOmFiaGlqYW4uYmhhdHRhY2hhcnl5YUB0Y3Mu Y29tPj4sICJBcnBhbiBQYWwiIDxhcnBhbi5wYWxAdGNzLmNvbTxtYWlsdG86YXJwYW4ucGFsQHRj cy5jb20+PiwgQXJwYW4gUGFsIDxhcnBhbi5wYWxAdGNzLmNvbTxtYWlsdG86YXJwYW4ucGFsQHRj cy5jb20+PiwgIlNvbWEgQmFuZHlvcGFkaHlheSIgPHNvbWEuYmFuZHlvcGFkaHlheUB0Y3MuY29t PG1haWx0bzpzb21hLmJhbmR5b3BhZGh5YXlAdGNzLmNvbT4+LCBBYmhpamFuIEJoYXR0YWNoYXJ5 eWEgPGFiaGlqYW4uYmhhdHRhY2hhcnl5YUB0Y3MuY29tPG1haWx0bzphYmhpamFuLmJoYXR0YWNo YXJ5eWFAdGNzLmNvbT4+DQpGcm9tOiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc8bWFpbHRvOmlu dGVybmV0LWRyYWZ0c0BpZXRmLm9yZz4NCkRhdGU6IDA4LzA2LzIwMTQgMDM6NDRQTQ0KU3ViamVj dDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC10Y3MtY29hcC1uby1yZXNwb25z ZS1vcHRpb24tMDcudHh0DQpBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtdGNzLWNvYXAtbm8t cmVzcG9uc2Utb3B0aW9uLTA3LnR4dA0KaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBi eSBBYmhpamFuIEJoYXR0YWNoYXJ5eWEgYW5kIHBvc3RlZCB0byB0aGUNCklFVEYgcmVwb3NpdG9y eS4NCg0KTmFtZTogZHJhZnQtdGNzLWNvYXAtbm8tcmVzcG9uc2Utb3B0aW9uDQpSZXZpc2lvbjog MDcNClRpdGxlOiBDb0FQIG9wdGlvbiBmb3Igbm8gc2VydmVyLXJlc3BvbnNlDQpEb2N1bWVudCBk YXRlOiAyMDE0LTA4LTA1DQpHcm91cDogSW5kaXZpZHVhbCBTdWJtaXNzaW9uDQpQYWdlczogMTgN ClVSTDogICAgICAgICAgICBodHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFm dC10Y3MtY29hcC1uby1yZXNwb25zZS1vcHRpb24tMDcudHh0DQpTdGF0dXM6ICAgICAgICAgaHR0 cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtdGNzLWNvYXAtbm8tcmVzcG9uc2Ut b3B0aW9uLw0KSHRtbGl6ZWQ6ICAgICAgIGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0 LXRjcy1jb2FwLW5vLXJlc3BvbnNlLW9wdGlvbi0wNw0KRGlmZjogICAgICAgICAgIGh0dHA6Ly93 d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LXRjcy1jb2FwLW5vLXJlc3BvbnNlLW9wdGlv bi0wNw0KDQpBYnN0cmFjdDoNCiAgIFRoZXJlIGNhbiBiZSB0eXBpY2FsIE0yTSBzY2VuYXJpb3Mg d2hlcmUgcmVzcG9uc2VzIGZyb20gdGhlIGRhdGENCiAgIHNpbmsgdG8gdGhlIGRhdGEgc291cmNl IGFnYWluc3QgcmVxdWVzdCBmcm9tIHRoZSBzb3VyY2UgbWlnaHQgYmUNCiAgIGNvbnNpZGVyZWQg cmVkdW5kYW50LiBUaGlzIGtpbmQgb2Ygb3Blbi1sb29wIGV4Y2hhbmdlICh3aXRoIG5vDQogICBy ZXZlcnNlIHBhdGggZnJvbSB0aGUgc2luayB0byB0aGUgc291cmNlKSBtYXkgYmUgZGVzaXJlZCB3 aGlsZQ0KICAgdXBkYXRpbmcgcmVzb3VyY2VzIGluIGNvbnN0cmFpbmVkIHN5c3RlbXMgbG9va2lu ZyBmb3IgbWF4aW1pemVkDQogICB0aHJvdWdocHV0IHdpdGggbWluaW1pemVkIHJlc291cmNlIGNv bnN1bXB0aW9uLiBDb0FQIGFscmVhZHkNCiAgIHByb3ZpZGVzIGEgbm9uLWNvbmZpcm1hYmxlIChO T04pIG1vZGUgb2YgZXhjaGFuZ2Ugd2hlcmUgdGhlDQogICByZWNlaXZpbmcgZW5kLXBvaW50IGRv ZXMgbm90IHJlc3BvbmQgd2l0aCBBQ0suIEhvd2V2ZXIsIHRoZQ0KICAgcmVjZWl2aW5nIGVuZC1w b2ludCByZXNwb25kcyB0aGUgc2VuZGVyIHdpdGggYSBzdGF0dXMgY29kZQ0KICAgaW5kaWNhdGlu ZyAidGhlIHJlc3VsdCBvZiB0aGUgYXR0ZW1wdCB0byB1bmRlcnN0YW5kIGFuZCBzYXRpc2Z5IHRo ZQ0KICAgcmVxdWVzdCIuDQoNCiAgIFRoaXMgZHJhZnQgaW50cm9kdWNlcyBhIGhlYWRlciBvcHRp b246ICdOby1SZXNwb25zZScgdG8gc3VwcHJlc3MNCiAgIHJlc3BvbnNlcyBmcm9tIHRoZSByZWNl aXZlciBhbmQgZGlzY3Vzc2VzIGV4ZW1wbGFyeSB1c2UgY2FzZXMgd2hpY2gNCiAgIG1vdGl2YXRl ZCB0aGlzIHByb3Bvc2l0aW9uIGJhc2VkIG9uIHJlYWwgZXhwZXJpZW5jZS4gVGhpcyBvcHRpb24N CiAgIGFsc28gcHJvdmlkZXMgZ3JhbnVsYXJpdHkgYnkgYWxsb3dpbmcgc3VwcHJlc3Npb24gb2Yg YSB0eXBpY2FsIGNsYXNzDQogICBvciBhIGNvbWJpbmF0aW9uIG9mIGNsYXNzZXMgb2YgcmVzcG9u c2VzLiBUaGlzIG9wdGlvbiBtYXkgYmUNCiAgIGVmZmVjdGl2ZSBmb3IgYm90aCB1bmljYXN0IGFu ZCBtdWx0aWNhc3Qgc2NlbmFyaW9zLg0KDQoNCg0KDQpQbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0 YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZiBzdWJtaXNzaW9uDQp1bnRp bCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IHRvb2xzLmll dGYub3JnLg0KDQpUaGUgSUVURiBTZWNyZXRhcmlhdA0K --_000_34966E97BE8AD64EAE9D3D6E4DEE36F25818052ESZXEMA501MBSchi_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

+1.

 = ;

It is simp= le and useful.

 = ;

Kind Regar= ds

Kepeng

 = ;

=B7=A2=BC=FE=C8=CB: core [mailto:core-bou= nces@ietf.org] =B4=FA=B1=ED = Abhijan Bhattacharyya
=B7=A2=CB=CD= =CA=B1=BC=E4: 2014=C4=EA8=D4=C2<= span lang=3D"EN-US">6=C8=D5 18:32
=CA=D5=BC=FE=C8=CB: core@ietf.org
=B3=AD=CB=CD: Arpan Pal
=D6=F7=CC=E2: [core] draft-tcs-coap-no-response-option-07 : Call for WG adoption

 

Hi,

We have submitted a new = version of the No-Response draft. Several editorial corrections have been m= ade. The references have been updated and enhanced. A number for the option has been suggested for IANA consideration .

As there has been contin= uity of interest in the mailing list discussions and also during the last t= hree WG meetings, may we now ask for the opinion of the Working Group on adoption of the draft please. 


Regards
Abhijan Bhattacharyya
Associate Consultant
Scientist, Innovation Lab, Kolkata, India
Tata Consultancy Services Limited
Mailto: abhijan.bhattachar= yya@tcs.com
Website: http://www.tcs.com
____________________________________________
Experience certainty. IT Services
Business Solutions
Consulting
____________________________________________



-----internet-drafts@ietf.org wrote: -----=

To: Soma Bandyopadhyay <soma.bandyopadhyay@tcs.com>, "Abhijan Bhattacharyya" = <abhijan.bhattacharyya@= tcs.com>, "Arpan Pal" <arpan.pal@t= cs.com>, Arpan Pal <arpan.pa= l@tcs.com>, "Soma Bandyopadhyay" <soma.bandyopadhyay@tcs.com>, Abhijan Bhatta= charyya <abhijan.bhattacharyya= @tcs.com>
From: internet-drafts@ietf.org<= /a>
Date: 08/06/2014 03:44PM
Subject: New Version Notification for draft-tcs-coap-no-response-option-07.= txt

A new version of I-D, draft-t= cs-coap-no-response-option-07.txt
has been successfully submitted by Abhijan Bhattacharyya and posted to the<= br> IETF repository.

Name: draft-tcs-coap-no-response-option
Revision: 07
Title: CoAP option for no server-response
Document date: 2014-08-05
Group: Individual Submission
Pages: 18
URL:            http://www.ietf= .org/internet-drafts/draft-tcs-coap-no-response-option-07.txt
Status:         https://datatracker.ietf.org/doc/draft-tcs-coap-no-response-option/
Htmlized:       http://tools.ietf.org/html/draft-tcs-coap-no-response-option-07
Diff:           http://www.ietf.org/rfcdiff?url2=3Ddraft-tcs-coap-no-response-option-07=

Abstract:
   There can be typical M2M scenarios where responses from the da= ta
   sink to the data source against request from the source might = be
   considered redundant. This kind of open-loop exchange (with no=
   reverse path from the sink to the source) may be desired while=
   updating resources in constrained systems looking for maximize= d
   throughput with minimized resource consumption. CoAP already    provides a non-confirmable (NON) mode of exchange where the    receiving end-point does not respond with ACK. However, the    receiving end-point responds the sender with a status code
   indicating "the result of the attempt to understand and s= atisfy the
   request".

   This draft introduces a header option: 'No-Response' to suppre= ss
   responses from the receiver and discusses exemplary use cases = which
   motivated this proposition based on real experience. This opti= on
   also provides granularity by allowing suppression of a typical= class
   or a combination of classes of responses. This option may be    effective for both unicast and multicast scenarios.

                    =                     &nbs= p;                     &n= bsp;                  


Please note that it may take a couple of minutes from the time of submissio= n
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

--_000_34966E97BE8AD64EAE9D3D6E4DEE36F25818052ESZXEMA501MBSchi_-- From nobody Thu Aug 7 12:31:53 2014 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFDEA1A0049 for ; Thu, 7 Aug 2014 12:31:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.191 X-Spam-Level: X-Spam-Status: No, score=-4.191 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DRUGS_MUSCLE=0.01, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iEWN8bXwDgVW for ; Thu, 7 Aug 2014 12:31:48 -0700 (PDT) Received: from inkolg01.tcs.com (inkolg01.tcs.com [121.241.215.10]) by ietfa.amsl.com (Postfix) with ESMTP id 4DD391A053B for ; Thu, 7 Aug 2014 12:31:47 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.01,819,1400005800"; d="scan'208,217";a="565873088" Received: from INKOLSALDLPMTA1.india.tcs.com (unknown [127.0.0.1]) by INKOLSALDLPMTA1.india.tcs.com (Service) with ESMTP id 25EDFDAC12; Fri, 8 Aug 2014 01:01:41 +0530 (IST) Received: from InKolM02.tcs.com (unknown [172.18.18.104]) by INKOLSALDLPMTA1.india.tcs.com (Service) with ESMTP id E1C36DAC02; Fri, 8 Aug 2014 01:01:40 +0530 (IST) MIME-Version: 1.0 Importance: Normal X-Priority: 3 (Normal) In-Reply-To: <34966E97BE8AD64EAE9D3D6E4DEE36F25818052E@SZXEMA501-MBS.china.huawei.com> References: <34966E97BE8AD64EAE9D3D6E4DEE36F25818052E@SZXEMA501-MBS.china.huawei.com>, <20140806101420.2243.22999.idtracker@ietfa.amsl.com> From: Abhijan Bhattacharyya To: Likepeng Message-ID: Date: Fri, 8 Aug 2014 01:01:38 +0530 X-Mailer: Lotus Domino Web Server Release 9.0.1HF198 January 23, 2014 X-MIMETrack: Serialize by Notes Server on InKolM02/TCS(Release 9.0.1HF198 | January 23, 2014) at 08/08/2014 01:01:38, Serialize complete at 08/08/2014 01:01:38, Itemize by Notes Server on InKolM02/TCS(Release 9.0.1HF198 | January 23, 2014) at 08/08/2014 01:01:38, Serialize by Notes Server on InKolM02/TCS(Release 9.0.1HF198 | January 23, 2014) at 08/08/2014 01:01:39, Serialize complete at 08/08/2014 01:01:39, Serialize by Router on InKolM02/TCS(Release 9.0.1HF198 | January 23, 2014) at 08/08/2014 01:01:39 Content-Type: multipart/alternative; boundary="=_alternative 006B445965257D2D_=" Archived-At: http://mailarchive.ietf.org/arch/msg/core/EOFjChfsjGOfmcItc6_1r32UAB4 Cc: Arpan Pal , "core@ietf.org" Subject: Re: [core] draft-tcs-coap-no-response-option-07 : Call for WG adoption X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Aug 2014 19:31:53 -0000 --=_alternative 006B445965257D2D_= MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Kepeng, Thanks for your response. Regards Abhijan Bhattacharyya Associate Consultant Scientist, Innovation Lab, Kolkata, India Tata Consultancy Services Limited Mailto: abhijan.bhattacharyya@tcs.com Website: http://www.tcs.com ____________________________________________ Experience certainty. IT Services Business Solutions Consulting ____________________________________________ -----Likepeng wrote: ----- To: Abhijan Bhattacharyya , "core@ietf.org" = From: Likepeng Date: 08/07/2014 05:48AM Cc: Arpan Pal Subject: Re: [core] draft-tcs-coap-no-response-option-07 : Call for WG adop= tion +1. =A0 It is simple and useful. =A0 Kind Regards Kepeng =A0 发件人: core [mailto:core-bounces@ietf.org] 代ŝ= 20; Abhijan Bhattacharyya 发送时间: 2014年8月6日 18:32 收件人: core@ietf.org 抄送: Arpan Pal 主题: [core] draft-tcs-coap-no-response-option-07 : Call for WG= adoption =A0 Hi, We have submitted a new version of the No-Response draft. Several editorial= corrections have been made. The references have been updated and enhanced.= A number for the option has been suggested for IANA consideration . As there has been continuity of interest in the mailing list discussions an= d also during the last three WG meetings, may we now ask for the opinion of= the Working Group on adoption of the draft please.=A0 Regards Abhijan Bhattacharyya Associate Consultant Scientist, Innovation Lab, Kolkata, India Tata Consultancy Services Limited Mailto: abhijan.bhattacharyya@tcs.com Website: http://www.tcs.com ____________________________________________ Experience certainty. IT Services Business Solutions Consulting ____________________________________________ -----internet-drafts@ietf.org wrote: ----- To: Soma Bandyopadhyay , "Abhijan Bhattacharyya= " , "Arpan Pal" , Arpan P= al , "Soma Bandyopadhyay" , = Abhijan Bhattacharyya From: internet-drafts@ietf.org Date: 08/06/2014 03:44PM Subject: New Version Notification for draft-tcs-coap-no-response-option-07.= txt A new version of I-D, draft-tcs-coap-no-response-option-07.txt has been successfully submitted by Abhijan Bhattacharyya and posted to the IETF repository. Name: draft-tcs-coap-no-response-option Revision: 07 Title: CoAP option for no server-response Document date: 2014-08-05 Group: Individual Submission Pages: 18 URL: =A0 =A0 =A0 =A0 =A0 =A0http://www.ietf.org/internet-drafts/draft-tcs-c= oap-no-response-option-07.txt Status: =A0 =A0 =A0 =A0 https://datatracker.ietf.org/doc/draft-tcs-coap-no-= response-option/ Htmlized: =A0 =A0 =A0 http://tools.ietf.org/html/draft-tcs-coap-no-response= -option-07 Diff: =A0 =A0 =A0 =A0 =A0 http://www.ietf.org/rfcdiff?url2=3Ddraft-tcs-coap= -no-response-option-07 Abstract: =A0=A0 There can be typical M2M scenarios where responses from the data =A0=A0 sink to the data source against request from the source might be =A0=A0 considered redundant. This kind of open-loop exchange (with no =A0=A0 reverse path from the sink to the source) may be desired while =A0=A0 updating resources in constrained systems looking for maximized =A0=A0 throughput with minimized resource consumption. CoAP already =A0=A0 provides a non-confirmable (NON) mode of exchange where the =A0=A0 receiving end-point does not respond with ACK. However, the =A0=A0 receiving end-point responds the sender with a status code =A0=A0 indicating "the result of the attempt to understand and satisfy the =A0=A0 request". =A0=A0 This draft introduces a header option: 'No-Response' to suppress =A0=A0 responses from the receiver and discusses exemplary use cases which =A0=A0 motivated this proposition based on real experience. This option =A0=A0 also provides granularity by allowing suppression of a typical class =A0=A0 or a combination of classes of responses. This option may be =A0=A0 effective for both unicast and multicast scenarios. =A0=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat =3D=3D=3D=3D=3D-----=3D=3D=3D=3D=3D-----=3D=3D=3D=3D=3D Notice: The information contained in this e-mail message and/or attachments to it may contain = confidential or privileged information. If you are = not the intended recipient, any dissemination, use, = review, distribution, printing or copying of the = information contained in this e-mail message = and/or attachments to it are strictly prohibited. If = you have received this communication in error, = please notify us by reply e-mail or telephone and = immediately and permanently delete the message = and any attachments. Thank you --=_alternative 006B445965257D2D_= Content-ID: <> MIME-Version: 1.0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi Kepeng,
Thanks for your response.


Regar= ds
Abhijan Bhattacharyya
Associate Consultant
Scientist, Innovatio= n Lab, Kolkata, India
Tata Consultancy Services Limited
Mailto: abhijan.bhattacharyya@tcs.com
Website: http://www.tcs.com
___= _________________________________________
Experience certainty. IT Servi= ces
Business Solutions
Consulting
__________________________= __________________


-----Likepeng <l= ikepeng@huawei.com> wrote: -----
To: Abhijan Bhattacharyya <abhijan.bhattacha= ryya@tcs.com>, "core@ietf.org" <core@ietf.org>
From: Likepeng &= lt;likepeng@huawei.com>
Date: 08/07/2014 05:48AM
Cc: Arpan Pal <= ;arpan.pal@tcs.com>
Subject: Re: [core] draft-tcs-coap-no-response-op= tion-07 : Call for WG adoption

+1.

 

It is simple and us= eful.

 

Kind Regards

Kepeng

 

发件人: core [mailto:co= re-bounces@ietf.org] 代ŝ= 20; Abhijan Bhattacharyya
发Ű= 65;时间: 2014年8月6日 18:32
收件人: core@ietf.org
抄送: Arpan Pal
主题: [core] draft-tcs-coap-no-response-option-07 : Call for WG adoption

 

Hi,

We have submitted a new = version of the No-Response draft. Several editorial corrections have been m= ade. The references have been updated and enhanced. A number for the option has been suggested for IANA consideration .

As there has been contin= uity of interest in the mailing list discussions and also during the last t= hree WG meetings, may we now ask for the opinion of the Working Group on adoption of the draft please. 


Regards
Abhijan Bhattacharyya
Associate Consultant
Scientist, Innovation Lab, Kolkata, India
Tata Consultancy Services Limited
Mailto: abhijan.bhattachar= yya@tcs.com
Website: http://www.tcs.com
____________________________________________
Experience certainty. IT Services
Business Solutions
Consulting
____________________________________________



--= ---internet-drafts@ietf.org wrote: -----

To: Soma Bandyopadhyay <soma.bandyopadhyay@tcs.com>, "Abhijan Bhattacharyya" <abhijan.bhattacharyya@tcs.com>, "Arpan Pal" <arpan.pal@tcs.com= >, Arpan Pal <arpan.pal@tcs.com<= /a>>, "Soma Bandyopadhyay" <soma.bandyopadhyay@tcs.com>, Abhijan Bhattacharyya <abhijan.bhattacharyya= @tcs.com>
From: internet-drafts@ietf.org<= /a>
Date: 08/06/2014 03:44PM
Subject: New Version Notification for draft-tcs-coap-no-response-option-07.= txt

A new version of I-D, draft-t= cs-coap-no-response-option-07.txt
has been successfully submitted by Abhijan Bhattacharyya and posted to the<= br> IETF repository.

Name: draft-tcs-coap-no-response-option
Revision: 07
Title: CoAP option for no server-response
Document date: 2014-08-05
Group: Individual Submission
Pages: 18
URL:            http://www.ietf= .org/internet-drafts/draft-tcs-coap-no-response-option-07.txt
Status:         https://datatracker.ietf.org/doc/draft-tcs-coap-no-response-option/
Htmlized:       http://tools.ietf.org/html/draft-tcs-coap-no-response-option-07
Diff:           http://www.ietf.org/rfcdiff?url2=3Ddraft-tcs-coap-no-response-option-07=

Abstract:
   There can be typical M2M scenarios where responses from the da= ta
   sink to the data source against request from the source might = be
   considered redundant. This kind of open-loop exchange (with no=
   reverse path from the sink to the source) may be desired while=
   updating resources in constrained systems looking for maximize= d
   throughput with minimized resource consumption. CoAP already    provides a non-confirmable (NON) mode of exchange where the
   receiving end-point does not respond with ACK. However, the
   receiving end-point responds the sender with a status code
   indicating "the result of the attempt to understand and satisf= y the
   request".

   This draft introduces a header option: 'No-Response' to suppre= ss
   responses from the receiver and discusses exemplary use cases = which
   motivated this proposition based on real experience. This opti= on
   also provides granularity by allowing suppression of a typical= class
   or a combination of classes of responses. This option may be    effective for both unicast and multicast scenarios.

                    =                     &nbs= p;                     &n= bsp;                  


Please note that it may take a couple of minutes from the time of submissio= n
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

=3D=3D=3D=3D=3D-----=3D=3D=3D=3D=3D-----=3D=3D=3D=3D= =3D
Notice: The information contained in this e-mail
message and/or attachments to it may contain
confidential or privileged information. If you are
not the intended recipient, any dissemination, use,
review, distribution, printing or copying of the
information contained in this e-mail message
and/or attachments to it are strictly prohibited. If
you have received this communication in error,
please notify us by reply e-mail or telephone and
immediately and permanently delete the message
and any attachments. Thank you

--=_alternative 006B445965257D2D_=-- From nobody Thu Aug 7 22:53:46 2014 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2ADD91A02DD for ; Thu, 7 Aug 2014 22:53:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NdoRRTVBcbqS for ; Thu, 7 Aug 2014 22:53:42 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F0D541A02E4 for ; Thu, 7 Aug 2014 22:53:41 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml401-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BLA09392; Fri, 08 Aug 2014 05:53:40 +0000 (GMT) Received: from SZXEMA410-HUB.china.huawei.com (10.82.72.42) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 8 Aug 2014 06:53:37 +0100 Received: from SZXEMA501-MBS.china.huawei.com ([169.254.2.128]) by SZXEMA410-HUB.china.huawei.com ([10.82.72.42]) with mapi id 14.03.0158.001; Fri, 8 Aug 2014 13:53:30 +0800 From: Likepeng To: "core@ietf.org" Thread-Topic: New Version Notification for draft-li-core-links-cbor-00.txt Thread-Index: AQHPssyOKvhdXgbvdESvKWcnwvdsgJvGM6AQ Date: Fri, 8 Aug 2014 05:53:30 +0000 Message-ID: <34966E97BE8AD64EAE9D3D6E4DEE36F258180E40@SZXEMA501-MBS.china.huawei.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.167.122] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/core/Sl75LDoYCIYOD4D7_vhocxygJcM Subject: [core] Fw: New Version Notification for draft-li-core-links-cbor-00.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Aug 2014 05:53:45 -0000 SGVsbG8gYWxsLA0KDQpXZSBzdWJtaXR0ZWQgYSBuZXcgZHJhZnQgd2hpY2ggZGVmaW5lcyBhIGNv bW1vbiBmb3JtYXQgZm9yIHJlcHJlc2VudGluZyBXZWIgbGlua3MgaW4gQ0JPUiBmb3JtYXQgKFJG QzcwNDkpLg0KDQpXZSBhcHByZWNpYXRlIHlvdXIgcmV2aWV3IGFuZCBmZWVkYmFjay4NCg0KVGhh bmtzLA0KDQpLaW5kIFJlZ2FyZHMNCktlcGVuZyAmIEJlcnQNCg0KLS0tLS3pgq7ku7bljp/ku7Yt LS0tLQ0K5Y+R5Lu25Lq6OiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcgW21haWx0bzppbnRlcm5l dC1kcmFmdHNAaWV0Zi5vcmddIA0K5Y+R6YCB5pe26Ze0OiAyMDE05bm0OOaciDjml6UgMTM6NTAN CuaUtuS7tuS6ujogQmVydCBHcmVldmVuYm9zY2g7IEJlcnQgR3JlZXZlbmJvc2NoOyBMaWtlcGVu ZzsgTGlrZXBlbmcNCuS4u+mimDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1s aS1jb3JlLWxpbmtzLWNib3ItMDAudHh0DQoNCkEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC1s aS1jb3JlLWxpbmtzLWNib3ItMDAudHh0IGhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQg YnkgS2VwZW5nIExpIGFuZCBwb3N0ZWQgdG8gdGhlIElFVEYgcmVwb3NpdG9yeS4NCg0KTmFtZToJ CWRyYWZ0LWxpLWNvcmUtbGlua3MtY2Jvcg0KUmV2aXNpb246CTAwDQpUaXRsZToJCVJlcHJlc2Vu dGluZyBDb1JFIExpbmsgQ29sbGVjdGlvbnMgaW4gQ0JPUg0KRG9jdW1lbnQgZGF0ZToJMjAxNC0w OC0wNw0KR3JvdXA6CQlJbmRpdmlkdWFsIFN1Ym1pc3Npb24NClBhZ2VzOgkJOA0KVVJMOiAgICAg ICAgICAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWxpLWNvcmUt bGlua3MtY2Jvci0wMC50eHQNClN0YXR1czogICAgICAgICBodHRwczovL2RhdGF0cmFja2VyLmll dGYub3JnL2RvYy9kcmFmdC1saS1jb3JlLWxpbmtzLWNib3IvDQpIdG1saXplZDogICAgICAgaHR0 cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtbGktY29yZS1saW5rcy1jYm9yLTAwDQoNCkFi c3RyYWN0Og0KICAgV2ViIExpbmtpbmcgKFJGQzU5ODgpIHByb3ZpZGVzIGEgd2F5IHRvIHJlcHJl c2VudCBsaW5rcyBiZXR3ZWVuIFdlYg0KICAgcmVzb3VyY2VzIGFzIHdlbGwgYXMgdGhlIHJlbGF0 aW9ucyBleHByZXNzZWQgYnkgdGhlbSBhbmQgYXR0cmlidXRlcw0KICAgb2Ygc3VjaCBhIGxpbmsu ICBJbiBjb25zdHJhaW5lZCBuZXR3b3JrcywgYSBjb2xsZWN0aW9uIG9mIFdlYiBsaW5rcw0KICAg Y2FuIGJlIGV4Y2hhbmdlZCBpbiB0aGUgQ29SRSBsaW5rIGZvcm1hdCAoUkZDNjY5MCkuDQoNCiAg IFRoaXMgc3BlY2lmaWNhdGlvbiBkZWZpbmVzIGEgY29tbW9uIGZvcm1hdCBmb3IgcmVwcmVzZW50 aW5nIFdlYiBsaW5rcw0KICAgaW4gQ0JPUiBmb3JtYXQgKFJGQzcwNDkpLg0KDQpOb3RlDQoNCiAg IERpc2N1c3Npb24gYW5kIHN1Z2dlc3Rpb25zIGZvciBpbXByb3ZlbWVudCBhcmUgcmVxdWVzdGVk LCBhbmQgc2hvdWxkDQogICBiZSBzZW50IHRvIGNvcmVAaWV0Zi5vcmcuDQogICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIA0KUGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51 dGVzIGZyb20gdGhlIHRpbWUgb2Ygc3VibWlzc2lvbiB1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lv biBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IHRvb2xzLmlldGYub3JnLg0KDQpUaGUgSUVURiBT ZWNyZXRhcmlhdA0KDQo= From nobody Fri Aug 8 00:09:09 2014 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 734681A03D8; Fri, 8 Aug 2014 00:09:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kdvAnlPeBz6g; Fri, 8 Aug 2014 00:09:02 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DA2B1A03E4; Fri, 8 Aug 2014 00:08:58 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: DraftTracker Mail System To: iesg@ietf.org, core-chairs@tools.ietf.org, draft-ietf-core-observe@tools.ietf.org, core@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.2.p5 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140808070858.30176.40445.idtracker@ietfa.amsl.com> Date: Fri, 08 Aug 2014 00:08:58 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/core/wY1YgYGNT-yo1Q2q4u1NvZ0ZYv8 Cc: iesg-secretary@ietf.org Subject: [core] Last Call Expired: X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Aug 2014 07:09:04 -0000 Please DO NOT reply to this email. I-D: ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-core-observe/ IETF Last Call has ended, and the state has been changed to Waiting for AD Go-Ahead. From nobody Fri Aug 8 00:20:58 2014 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C58821A03EC for ; Fri, 8 Aug 2014 00:20:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.602 X-Spam-Level: X-Spam-Status: No, score=-3.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_42=0.6, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ylRCU1mYmTcH for ; Fri, 8 Aug 2014 00:20:36 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9E71B1A03E5 for ; Fri, 8 Aug 2014 00:20:35 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml402-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BLA16053; Fri, 08 Aug 2014 07:20:34 +0000 (GMT) Received: from SZXEMA407-HUB.china.huawei.com (10.82.72.39) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 8 Aug 2014 08:20:33 +0100 Received: from SZXEMA501-MBS.china.huawei.com ([169.254.2.128]) by SZXEMA407-HUB.china.huawei.com ([10.82.72.39]) with mapi id 14.03.0158.001; Fri, 8 Aug 2014 15:20:31 +0800 From: Likepeng To: Carsten Bormann , "core (core@ietf.org)" Thread-Topic: [core] I-D Action: draft-ietf-core-links-json-01.txt Thread-Index: AQHO75Vbz5f6l7xsz0e9FAPXe8e8e5pAxjcAgYcJFuA= Date: Fri, 8 Aug 2014 07:20:30 +0000 Message-ID: <34966E97BE8AD64EAE9D3D6E4DEE36F258180EB6@SZXEMA501-MBS.china.huawei.com> References: <20131202193233.18226.97273.idtracker@ietfa.amsl.com> <0B07D56C-D9E5-436F-BE94-FCEC0824B3DC@tzi.org> In-Reply-To: <0B07D56C-D9E5-436F-BE94-FCEC0824B3DC@tzi.org> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.167.122] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/core/93yP2UWneqEQAEHThYL09E_CzvI Subject: Re: [core] I-D Action: draft-ietf-core-links-json-01.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Aug 2014 07:20:41 -0000 SGkgQ2Fyc3RlbiwNCg0KSW4gc2VjdGlvbiAyLjEgImV4YW1wbGVzIiwgdGhlIG9yaWdpbmFsIGxp bmsgaXMgY3Q9NDAsIDQwIGlzIGFuIGludGVnZXIuDQo8L3NlbnNvcnM+O2N0PTQwO3RpdGxlPSJT ZW5zb3IgSW5kZXgiLA0KDQpCdXQgYWZ0ZXIgY29udmVyc2lvbiB0byBKU09OLCBpdCBiZWNvbWVz ICI0MCIsIHdoaWNoIGlzIGEgc3RyaW5nLiANCnsiaHJlZiI6Ii9zZW5zb3JzIiwgImN0IjoiNDAi LCJ0aXRsZSI6IlNlbnNvciBJbmRleCJ9DQoNCkkgdXNlIGNib3IubWUgdG8gY29udmVydCB0aGUg SlNPTiBleGFtcGxlIHRvIENCT1IsIGl0IGFsc28gYmVjb21lcyAidGV4dCBzdHJpbmciDQogICAg ICA2MiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIyB0ZXh0KDIpDQogICAgICAgICAz NDMwICAgICAgICAgICAgICAgICAgICAgICAgICAgIyAiNDAiDQoNCkkgdGhpbmsgaXQgc2hvdWxk IGJlIGtlcHQgYXMgaW50ZWdlciBmb3IgSlNPTiBhbmQgQ0JPUi4NCg0KV2hhdCBkbyB5b3UgdGhp bms/DQoNClRoYW5rcywNCktpbmQgUmVnYXJkcw0KS2VwZW5nDQoNCj4gLS0tLS3pgq7ku7bljp/k u7YtLS0tLQ0KPiDlj5Hku7bkuro6IGNvcmUgW21haWx0bzpjb3JlLWJvdW5jZXNAaWV0Zi5vcmdd IOS7o+ihqCBDYXJzdGVuIEJvcm1hbm4NCj4g5Y+R6YCB5pe26Ze0OiAyMDEz5bm0MTLmnIgz5pel IDM6MzYNCj4g5pS25Lu25Lq6OiBjb3JlIChjb3JlQGlldGYub3JnKQ0KPiDkuLvpopg6IFJlOiBb Y29yZV0gSS1EIEFjdGlvbjogZHJhZnQtaWV0Zi1jb3JlLWxpbmtzLWpzb24tMDEudHh0DQo+IA0K PiBUaGlzIGlzIGEgcmVzdWJtaXQgdG8gYXZvaWQgZXhwaXJhdGlvbiBvZiB0aGUgZHJhZnQsIHdp dGggYSByZWZlcmVuY2UgdXBkYXRlIGFuZA0KPiBhIHNtYWxsIGVkaXRvcmlhbCBmaXguDQo+IChX ZSBzYWlkIHdlIHdlcmUgd2FpdGluZyBmb3Igc29tZSBtb3JlIGltcGxlbWVudGF0aW9uIGV4cGVy aWVuY2UgYmVmb3JlDQo+IGFkdmFuY2luZyB0aGlzLikNCj4gDQo+IEdyw7zDn2UsIENhcnN0ZW4N Cj4gDQo+ID4gCVRpdGxlICAgICAgICAgICA6IFJlcHJlc2VudGluZyBDb1JFIExpbmsgQ29sbGVj dGlvbnMgaW4gSlNPTg0KPiA+IAlBdXRob3IocykgICAgICAgOiBDYXJzdGVuIEJvcm1hbm4NCj4g PiAJRmlsZW5hbWUgICAgICAgIDogZHJhZnQtaWV0Zi1jb3JlLWxpbmtzLWpzb24tMDEudHh0DQo+ ID4gCVBhZ2VzICAgICAgICAgICA6IDYNCj4gPiAJRGF0ZSAgICAgICAgICAgIDogMjAxMy0xMi0w Mg0KPiA+DQo+ID4gQWJzdHJhY3Q6DQo+ID4gICBXZWIgTGlua2luZyAoUkZDNTk4OCkgcHJvdmlk ZXMgYSB3YXkgdG8gcmVwcmVzZW50IGxpbmtzIGJldHdlZW4gV2ViDQo+ID4gICByZXNvdXJjZXMg YXMgd2VsbCBhcyB0aGUgcmVsYXRpb25zIGV4cHJlc3NlZCBieSB0aGVtIGFuZCBhdHRyaWJ1dGVz DQo+ID4gICBvZiBzdWNoIGEgbGluay4gIEluIGNvbnN0cmFpbmVkIG5ldHdvcmtzLCBhIGNvbGxl Y3Rpb24gb2YgV2ViIGxpbmtzDQo+ID4gICBjYW4gYmUgZXhjaGFuZ2VkIGluIHRoZSBDb1JFIGxp bmsgZm9ybWF0IChSRkM2NjkwKS4gIE91dHNpZGUgb2YNCj4gPiAgIGNvbnN0cmFpbmVkIGVudmly b25tZW50cywgaXQgbWF5IGJlIHVzZWZ1bCB0byByZXByZXNlbnQgdGhlc2UNCj4gPiAgIGNvbGxl Y3Rpb25zIG9mIFdlYiBsaW5rcyBpbiBKU09OIGZvcm1hdCAoUkZDNDYyNykuDQo+ID4NCj4gPiAg IFRoaXMgc3BlY2lmaWNhdGlvbiBkZWZpbmVzIGEgY29tbW9uIGZvcm1hdCBmb3IgcmVwcmVzZW50 aW5nIFdlYiBsaW5rcw0KPiA+ICAgaW4gSlNPTiBmb3JtYXQuDQo+ID4NCj4gPg0KPiA+IFRoZSBJ RVRGIGRhdGF0cmFja2VyIHN0YXR1cyBwYWdlIGZvciB0aGlzIGRyYWZ0IGlzOg0KPiA+IGh0dHBz Oi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtY29yZS1saW5rcy1qc29uDQo+ ID4NCj4gPiBUaGVyZSdzIGFsc28gYSBodG1saXplZCB2ZXJzaW9uIGF2YWlsYWJsZSBhdDoNCj4g PiBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWNvcmUtbGlua3MtanNvbi0w MQ0KPiA+DQo+ID4gQSBkaWZmIGZyb20gdGhlIHByZXZpb3VzIHZlcnNpb24gaXMgYXZhaWxhYmxl IGF0Og0KPiA+IGh0dHA6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWlldGYtY29y ZS1saW5rcy1qc29uLTAxDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fDQo+IGNvcmUgbWFpbGluZyBsaXN0DQo+IGNvcmVAaWV0Zi5vcmcNCj4gaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9jb3JlDQo= From nobody Fri Aug 8 00:57:18 2014 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A5D61A0A40 for ; Fri, 8 Aug 2014 00:57:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UVuiQsjSWxrQ for ; Fri, 8 Aug 2014 00:57:15 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 710771A04C5 for ; Fri, 8 Aug 2014 00:57:15 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml402-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BLA19609; Fri, 08 Aug 2014 07:57:13 +0000 (GMT) Received: from SZXEMA408-HUB.china.huawei.com (10.82.72.40) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 8 Aug 2014 08:57:12 +0100 Received: from SZXEMA501-MBS.china.huawei.com ([169.254.2.128]) by SZXEMA408-HUB.china.huawei.com ([10.82.72.40]) with mapi id 14.03.0158.001; Fri, 8 Aug 2014 15:57:06 +0800 From: Likepeng To: "core (core@ietf.org)" Thread-Topic: New Version Notification for draft-becker-core-coap-sms-gprs-05.txt Thread-Index: AQHPst2SNHHzVSe9Bku6/muipAQ1KZvGVXJA Date: Fri, 8 Aug 2014 07:57:06 +0000 Message-ID: <34966E97BE8AD64EAE9D3D6E4DEE36F258180F45@SZXEMA501-MBS.china.huawei.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.167.122] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/core/p1zZJ2sH3RjqCMtudAp2aXjEu-o Subject: [core] Fw: New Version Notification for draft-becker-core-coap-sms-gprs-05.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Aug 2014 07:57:17 -0000 SGVsbG8gYWxsLA0KDQpJbiBUb3JvbnRvIEYyRiBtZWV0aW5nLCB3ZSBoYWQgc29tZSBkaXNjdXNz aW9ucyBhYm91dCBhbHRlcm5hdGl2ZSB0cmFuc3BvcnRzIHRvcGljIGFuZCBzZXZlcmFsIHBlb3Bs ZSBzaG93ZWQgaW50ZXJlc3RzIGFuZCBzdXBwb3J0cyBmb3IgdGhlIFNNUyB0cmFuc3BvcnQgZHJh ZnQuDQoNCldlIHVwZGF0ZWQgdGhlIGRyYWZ0IHJlY2VudGx5IGFuZCBoZXJlIGFyZSB0aGUgY2hh bmdlczoNCiAgIG8gIFJlbW92ZWQgcmVmZXJlbmNlIHRvIFVTU0QuDQogICBvICBVcGRhdGVkIHJl ZmVyZW5jZSB0byBSRkM3MjUyIGFuZCAzR1BQIHNwZWNzLg0KICAgbyAgVXBkYXRlZCBPcHRpb25z Lg0KICAgbyAgQWRhcHRlZCBVUkkgc2NoZW1lLg0KDQpXZSB3b3VsZCBhcHByZWNpYXRlIHlvdXIg cmV2aWV3IGFuZCBmZWVkYmFjay4NCg0KVGhhbmtzLA0KDQpLaW5kIFJlZ2FyZHMNCktlcGVuZyAo T24gYmVoYWxmIG9mIGNvLWF1dGhvcnMgb2YgdGhpcyBkcmFmdCkNCg0KLS0tLS3pgq7ku7bljp/k u7YtLS0tLQ0K5Y+R5Lu25Lq6OiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcgW21haWx0bzppbnRl cm5ldC1kcmFmdHNAaWV0Zi5vcmddIA0K5Y+R6YCB5pe26Ze0OiAyMDE05bm0OOaciDjml6UgMTU6 NTENCuaUtuS7tuS6ujogTGlrZXBlbmc7IE1hcmt1cyBCZWNrZXI7IEtvb2phbmEgS3VsYWRpbml0 aGk7IFRob21hcyBQb2V0c2NoOyBUaG9tYXMgUG9ldHNjaDsgTWFya3VzIEJlY2tlcjsgS29vamFu YSBLdWxhZGluaXRoaTsgTGlrZXBlbmcNCuS4u+mimDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9u IGZvciBkcmFmdC1iZWNrZXItY29yZS1jb2FwLXNtcy1ncHJzLTA1LnR4dA0KDQpBIG5ldyB2ZXJz aW9uIG9mIEktRCwgZHJhZnQtYmVja2VyLWNvcmUtY29hcC1zbXMtZ3Bycy0wNS50eHQNCmhhcyBi ZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgS2VwZW5nIExpIGFuZCBwb3N0ZWQgdG8gdGhl IElFVEYgcmVwb3NpdG9yeS4NCg0KTmFtZToJCWRyYWZ0LWJlY2tlci1jb3JlLWNvYXAtc21zLWdw cnMNClJldmlzaW9uOgkwNQ0KVGl0bGU6CQlUcmFuc3BvcnQgb2YgQ29BUCBvdmVyIFNNUw0KRG9j dW1lbnQgZGF0ZToJMjAxNC0wOC0wOA0KR3JvdXA6CQlJbmRpdmlkdWFsIFN1Ym1pc3Npb24NClBh Z2VzOgkJMTQNClVSTDogICAgICAgICAgICBodHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRy YWZ0cy9kcmFmdC1iZWNrZXItY29yZS1jb2FwLXNtcy1ncHJzLTA1LnR4dA0KU3RhdHVzOiAgICAg ICAgIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWJlY2tlci1jb3JlLWNv YXAtc21zLWdwcnMvDQpIdG1saXplZDogICAgICAgaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwv ZHJhZnQtYmVja2VyLWNvcmUtY29hcC1zbXMtZ3Bycy0wNQ0KRGlmZjogICAgICAgICAgIGh0dHA6 Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWJlY2tlci1jb3JlLWNvYXAtc21zLWdw cnMtMDUNCg0KQWJzdHJhY3Q6DQogICBTaG9ydCBNZXNzYWdlIFNlcnZpY2UgKFNNUykgb2YgbW9i aWxlIGNlbGx1bGFyIG5ldHdvcmtzIGlzIGZyZXF1ZW50bHkNCiAgIHVzZWQgaW4gTWFjaGluZS1U by1NYWNoaW5lIChNMk0pIGNvbW11bmljYXRpb25zLCBzdWNoIGFzIGZvcg0KICAgdGVsZW1hdGlj IGRldmljZXMuICBUaGUgc2VydmljZSBvZmZlcnMgc21hbGwgcGFja2V0IHNpemVzIGFuZCBoaWdo DQogICBkZWxheXMganVzdCBhcyBvdGhlciB0eXBpY2FsIGxvdy1wb3dlciBhbmQgbG9zc3kgbmV0 d29ya3MgKExMTnMpLA0KICAgaS5lLiA2TG9XUEFOcy4gIFRoZSBkZXNpZ24gb2YgdGhlIENvbnN0 cmFpbmVkIEFwcGxpY2F0aW9uIFByb3RvY29sDQogICAoQ29BUCkgW1JGQzcyNTJdLCB0aGF0IHRv b2sgdGhlIGxpbWl0YXRpb25zIG9mIExMTnMgaW50byBhY2NvdW50LCBpcw0KICAgdGh1cyBhbHNv IGFwcGxpY2FibGUgdG8gb3RoZXIgdHJhbnNwb3J0cy4gIFRoZSBhZGFwdGF0aW9uIG9mIENvQVAg dG8NCiAgIFNNUyB0cmFuc3BvcnQgbWVjaGFuaXNtcyBpcyBkZXNjcmliZWQgaW4gdGhpcyBkb2N1 bWVudC4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIA0KUGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkg dGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2Ygc3VibWlzc2lvbiB1bnRp bCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IHRvb2xzLmll dGYub3JnLg0KDQpUaGUgSUVURiBTZWNyZXRhcmlhdA0KDQo= From nobody Fri Aug 8 11:19:56 2014 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4160B1A0067 for ; Fri, 8 Aug 2014 11:19:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cdvOYdv8bmwI; Fri, 8 Aug 2014 11:19:39 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id DFACB1A007D; Fri, 8 Aug 2014 11:19:29 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: core-chairs@tools.ietf.org, draft-ietf-core-observe@tools.ietf.org, core@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.2.p5 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140808181929.4526.21512.idtracker@ietfa.amsl.com> Date: Fri, 08 Aug 2014 11:19:29 -0700 From: IETF Secretariat Archived-At: http://mailarchive.ietf.org/arch/msg/core/8vhvZ3NBAzCfWihZXACUpY0C9_A Subject: [core] ID Tracker State Update Notice: X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Aug 2014 18:19:41 -0000 IESG state changed to IESG Evaluation from Waiting for AD Go-Ahead ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-core-observe/ From nobody Mon Aug 11 13:05:55 2014 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42F1C1A024E for ; Mon, 11 Aug 2014 13:05:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R5xlmRHOyMrp; Mon, 11 Aug 2014 13:05:52 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 768621A01F7; Mon, 11 Aug 2014 13:05:51 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: core-chairs@tools.ietf.org, draft-ietf-core-groupcomm@tools.ietf.org, core@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.2.p5 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140811200551.11974.61096.idtracker@ietfa.amsl.com> Date: Mon, 11 Aug 2014 13:05:51 -0700 From: IETF Secretariat Archived-At: http://mailarchive.ietf.org/arch/msg/core/ZLZDFfiac2Nv75AIn7Rdz6e9g4o Subject: [core] ID Tracker State Update Notice: X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Aug 2014 20:05:53 -0000 IANA review state changed to IANA OK - Actions Needed ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-core-groupcomm/ From nobody Thu Aug 14 00:08:57 2014 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ADF3D1A08EA; Thu, 14 Aug 2014 00:08:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DeYOaYGIGVKB; Thu, 14 Aug 2014 00:08:53 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C1721A08F4; Thu, 14 Aug 2014 00:08:38 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: DraftTracker Mail System To: iesg@ietf.org, core-chairs@tools.ietf.org, draft-ietf-core-groupcomm@tools.ietf.org, core@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.2.p5 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140814070838.18032.26720.idtracker@ietfa.amsl.com> Date: Thu, 14 Aug 2014 00:08:38 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/core/d802farZfc2-yHc9UiOmYI8cSGk Cc: iesg-secretary@ietf.org Subject: [core] Last Call Expired: X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Aug 2014 07:08:54 -0000 Please DO NOT reply to this email. I-D: ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-core-groupcomm/ IETF Last Call has ended, and the state has been changed to Waiting for AD Go-Ahead. From nobody Thu Aug 14 08:51:39 2014 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14E321A07CE for ; Thu, 14 Aug 2014 08:51:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k0diJ0m6z504; Thu, 14 Aug 2014 08:51:30 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 667E71A0834; Thu, 14 Aug 2014 08:51:28 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: core-chairs@tools.ietf.org, draft-ietf-core-groupcomm@tools.ietf.org, core@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.2.p5 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140814155128.2081.38102.idtracker@ietfa.amsl.com> Date: Thu, 14 Aug 2014 08:51:28 -0700 From: IETF Secretariat Archived-At: http://mailarchive.ietf.org/arch/msg/core/QbMYAGVGt3K0HHtFXeDHQ-Xz3Qk Subject: [core] ID Tracker State Update Notice: X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Aug 2014 15:51:36 -0000 IESG state changed to IESG Evaluation from Waiting for AD Go-Ahead ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-core-groupcomm/ From nobody Thu Aug 14 14:07:30 2014 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 678C51A87B0; Thu, 14 Aug 2014 14:06:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.153 X-Spam-Level: X-Spam-Status: No, score=-0.153 tagged_above=-999 required=5 tests=[BAD_CREDIT=2.415, BAYES_00=-1.9, RP_MATCHES_RCVD=-0.668] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Io2jSTrT1eua; Thu, 14 Aug 2014 14:06:28 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 944CE1A87AA; Thu, 14 Aug 2014 14:06:28 -0700 (PDT) Received: from [10.0.1.23] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id s7EL6QWA087315 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 14 Aug 2014 16:06:27 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-173-172-146-58.tx.res.rr.com [173.172.146.58] claimed to be [10.0.1.23] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ben Campbell Date: Thu, 14 Aug 2014 16:06:25 -0500 X-Mao-Original-Outgoing-Id: 429743185.56511-1842d2fea7d969c284feff6e174d3bdd Content-Transfer-Encoding: quoted-printable Message-Id: To: draft-ietf-core-groupcomm.all@tools.ietf.org X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/core/pwvJhIgL9baXO96Pb7w1gPY3w10 X-Mailman-Approved-At: Thu, 14 Aug 2014 14:07:27 -0700 Cc: "gen-art@ietf.org Team \(gen-art@ietf.org\)" , core@ietf.org Subject: [core] Gen-ART LC Review of draft-ietf-core-groupcomm-21 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Aug 2014 21:06:30 -0000 (Oops, I screwed up the CC list the first try. Please send any replies = to this distribution. Apologies for the repeat.) I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at . Please resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-core-groupcomm-21 Reviewer: Ben Campbell Review Date: 2014-08-14 IETF LC End Date: 2014-08-14 IESG Telechat date:=20 Summary: This draft is not ready for publication as an informational = RFC. It has some significant issues, detailed below. **** Major issues: -- The draft contains significant material that I do not believe is = appropriate for an informational RFC, at least without some clear = explanations about why it appears. It purports to clarify the normative = stuff in RFC 7252 concerning multicast, but it does quite a bit more = than that. Section 2.7 defines protocol, in the form of a RESTful methods and = attributes to manage multicast group membership.I agree in some cases it = makes sense for an informational RFC to define protocol. A common = example is when we want to document a proprietary protocol for some = reason. As written, this does not seem to fall unto such a case. If the = authors and working group believe it does, it would be helpful to add = text explaining that, and how the reader should interpret the section. = (I recognize that this interface is optional--but I don't think making = it optional changes whether it should be standards track.) In addition to that, the draft contains quite a bit of guidance that = might be more appropriate BCP. For example, there is guidance here where = not following it might do harm to the network. Additionally, I don't see = how anyone could expect to achieve interoperability the multicast = features of RFC 7252 without understanding this draft. (I have to = wonder why RFC 7252 did not have a normative dependency on this draft.) -- The security aspects of group CoAP are pretty bad. To its credit, the = draft does a pretty good job of calling that out, and that work is in = progress to improve it. But I have to wonder if we would be better off = not encouraging multicast CoAP at all until such improvements are = available. Section 5.3 calls out some reasonable examples of mitigation = approaches, but I am a little concerned at the guidance that one should = worry about these for "sensitive" or "safety-critical" data. People are = not good at knowing what data is "sensitive" until it gets used against = them. I think this is especially true for IoT applications where we have = less deployment experience. Along those lines, the Pervasive Monitoring Considerations section = (kudos for having one, btw), tries to balance application needs vs = protecting information. But the smart-grid example seems to be a case = where the two are really at odds. I am afraid people will interpret this = along the lines of "well, the smart-grid application requirements force = me to send unprotected data all over the place", when I think the right = answer is "Group CoAP should not be used for this sort of application = until we can protect the data". **** Minor issues: -- 2.2, 5th paragraph: "For sending nodes, it is recommended to use the = IP multicast address literal in a group URI." Can you elaborate on why? I can guess, but anytime we suggest using = literal IP addresses rather than DNS names, it's worth elaborating. -- 2.4: " ... if the resource being POSTed to has been designed to cope = with the unreliable and lossy nature of IP multicast." Can you elaborate on what it means to be "designed to cope..."? (Or = reference something that does?) -- 2.6: I think the Resource Directory reference needs to be normative. (I see = the discussion of this from Barry's AD review, where the authors argued = that the reference is optional for implementations. But our definition = of normative references also includes things necessary to fully = understand this draft. Fully understanding even optional features is = part of that.) -- 2.7.1, 2nd paragraph: Does this imply a need to coordinate pre-configured group addresses to = avoid collisions? -- 2.7.2.1: 2nd 2 last paragraph: Are there any scenarios where a missing port might be determined from = DNS, rather than just assuming the default? -- 2.7.2.6, 1st paragraph: "This operation MUST only be used to delete = or update group membership objects for which the CoAP client, invoking = this operation, is responsible" Do I understand correctly that this replaces the entire set? Is it = possible for two different clients to be responsible for two different = subsets? If so, how? -- 2.8 and (especially) 2.9: Lack of 2119 language in the "additional guidlines" seems inconsistent = with other parts of this draft that do use 2119 language. (I agree the = places where you talk about what 7252 already says should not use 2119 = language.) I can maybe see the difference for 2.8, but the = congestion-avoidance stuff in 2.9 seems as appropriate for 2119 language = as most anything else in the draft. (To be clear, I'm not suggesting more or less normative language--only = consistency in its use.) **** Nits/editorial comments: -- Abstract: Please expand CoAP on first use in abstract. (But don't remove the = expansion in the body.) -- 2.2, 4th paragraph: " ... it is recommended ..."=20 Was that intended as normative?=20 Along those lines, I see a number of sections where 2119 words are used = in lower case where it looks like they were not intended as normative = (e.g., where you talk about normative requirements from RFC 7252), but = in other areas it's not as clear (like this one.) It would be best to = either avoid lower case versions of 2119 words, or make it very clear = whether they should be interpreted normatively or not. -- 2.7.2, 2nd paragraph: Wording is confusing. Do you mean MUST use the DTLS method, or MUST use = some method, with DTLS an option? Sentence seems to mean the former, in = which it would be more clear to say "MUST use DTLS as described in ..." -- 2.7.2.1, 3rd paragraph: Please expand JDON on first use. -- 2.7.2.1, paragraph after examples: You mention an optional port for "a" attributes, but not for "n" = attributes. The BNF for group-name seems to allow an optional port. (and = you mention an optional port for "n" later. From nobody Thu Aug 14 15:13:14 2014 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03F9E1A88E3 for ; Thu, 14 Aug 2014 15:13:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.153 X-Spam-Level: X-Spam-Status: No, score=-0.153 tagged_above=-999 required=5 tests=[BAD_CREDIT=2.415, BAYES_00=-1.9, RP_MATCHES_RCVD=-0.668] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j5QG9IvxWgWg for ; Thu, 14 Aug 2014 15:13:08 -0700 (PDT) Received: from smtp-in1.interdigital.com (smtp-in1.interdigital.com [64.208.228.133]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BE5041A88E5 for ; Thu, 14 Aug 2014 15:13:08 -0700 (PDT) X-ASG-Debug-ID: 1408054386-06daaa1c80a4580001-aa7cYp Received: from smtp-out1.interdigital.com (sahara.interdigital.com [10.0.128.27]) by smtp-in1.interdigital.com with ESMTP id N1DSqIJKpXKeECch; Thu, 14 Aug 2014 18:13:06 -0400 (EDT) X-Barracuda-Envelope-From: Akbar.Rahman@InterDigital.com Received: from SAM.InterDigital.com ([10.30.2.11]) by smtp-out1.interdigital.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 14 Aug 2014 18:13:04 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 14 Aug 2014 18:12:44 -0400 X-ASG-Orig-Subj: RE: [core] Gen-ART LC Review of draft-ietf-core-groupcomm-21 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [core] Gen-ART LC Review of draft-ietf-core-groupcomm-21 Thread-Index: Ac+4A8OIanQGZ9nvTFyxtbC9T+FQbgABBzRA References: From: "Rahman, Akbar" To: "Ben Campbell" X-OriginalArrivalTime: 14 Aug 2014 22:13:04.0699 (UTC) FILETIME=[EB7D00B0:01CFB80C] X-Barracuda-Connect: sahara.interdigital.com[10.0.128.27] X-Barracuda-Start-Time: 1408054386 X-Barracuda-URL: http://10.1.245.3:8000/cgi-mod/mark.cgi X-Barracuda-BRTS-Status: 1 X-Virus-Scanned: by bsmtpd at interdigital.com X-Barracuda-Spam-Score: 0.33 X-Barracuda-Spam-Status: No, SCORE=0.33 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=9.0 tests=BAD_CREDIT, BSF_SC0_MISMATCH_TO X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.8449 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.33 BAD_CREDIT BODY: Eliminate Bad Credit 0.00 BSF_SC0_MISMATCH_TO Envelope rcpt doesn't match header Archived-At: http://mailarchive.ietf.org/arch/msg/core/U6hApEvdRqyj2zduvqz_yMe4jBs Cc: gen-art@ietf.org, draft-ietf-core-groupcomm.all@tools.ietf.org, core@ietf.org Subject: Re: [core] Gen-ART LC Review of draft-ietf-core-groupcomm-21 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Aug 2014 22:13:11 -0000 Hi Ben, Thank you for your thorough review. Here is my initial feedback on the two major issues that you raised: >The draft contains significant material that I do not believe is appropriate for an informational RFC, at least without some clear explanations about why it appears. It purports to clarify the normative stuff in RFC 7252 concerning multicast, but it does quite a bit more than that. Section 2.7 defines protocol ... Response: ------------- The majority of the document is geared towards explaining how RESTful group communications protocol should work based on the protocol primitives defined in CoAP (RFC 7252). This was certainly the original intent of the document (i.e. expand and explain CoAP group communications protocol processing defined in RFC 7252 but do not introduce any new functionality). Then at a late(r) stage of development of the document, the WG decided that we should also include some "management" aspects of CoAP group communications. This resulted in addition of Sections 2.6, 2.7, 3.6, 6.1, & 6.2. The offending (new) functionality is pretty clearly limited to these sections. Therefore, I think we have two possible options to address your comment: 1) Remove Sections 2.6, 2.7 & 3.6 that focus on the management aspects from the current document and spawn a new document (or potentially migrate them to I-D.ietf-core-resource-directory if that makes sense). 2) Change the status of the document from Informational to Standards Track or BCP (and clearly indicate that the new functionality beyond RFC 7252 is introduced in Sections 2.6, 2.7, 3.6, 6.1, & 6.2). Ben/Barry - Can you give us some guidance here? >The security aspects of group CoAP are pretty bad. To its credit, the draft does a pretty good job of calling that out, and that work is in progress to improve it. But I have to wonder if we would be better off not encouraging multicast CoAP at all until such improvements are available. Response: ------------- Well, I think that we could definitely add stronger language recommending not to use CoAP group communication until stronger security solutions are developed in IETF. However, as you noted, the fact is that RFC 7252 already allows the current unsecured CoAP group communications. So I don't really appreciate how this could be a blocking issue on progression of this document. Looking forward to your response, Akbar -----Original Message----- From: core [mailto:core-bounces@ietf.org] On Behalf Of Ben Campbell Sent: Thursday, August 14, 2014 5:06 PM To: draft-ietf-core-groupcomm.all@tools.ietf.org Cc: gen-art@ietf.org Team (gen-art@ietf.org); core@ietf.org Subject: [core] Gen-ART LC Review of draft-ietf-core-groupcomm-21 (Oops, I screwed up the CC list the first try. Please send any replies to this distribution. Apologies for the repeat.) I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at . Please resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-core-groupcomm-21 Reviewer: Ben Campbell Review Date: 2014-08-14 IETF LC End Date: 2014-08-14 IESG Telechat date:=20 Summary: This draft is not ready for publication as an informational RFC. It has some significant issues, detailed below. **** Major issues: -- The draft contains significant material that I do not believe is appropriate for an informational RFC, at least without some clear explanations about why it appears. It purports to clarify the normative stuff in RFC 7252 concerning multicast, but it does quite a bit more than that. Section 2.7 defines protocol, in the form of a RESTful methods and attributes to manage multicast group membership.I agree in some cases it makes sense for an informational RFC to define protocol. A common example is when we want to document a proprietary protocol for some reason. As written, this does not seem to fall unto such a case. If the authors and working group believe it does, it would be helpful to add text explaining that, and how the reader should interpret the section. (I recognize that this interface is optional--but I don't think making it optional changes whether it should be standards track.) In addition to that, the draft contains quite a bit of guidance that might be more appropriate BCP. For example, there is guidance here where not following it might do harm to the network. Additionally, I don't see how anyone could expect to achieve interoperability the multicast features of RFC 7252 without understanding this draft. (I have to wonder why RFC 7252 did not have a normative dependency on this draft.) -- The security aspects of group CoAP are pretty bad. To its credit, the draft does a pretty good job of calling that out, and that work is in progress to improve it. But I have to wonder if we would be better off not encouraging multicast CoAP at all until such improvements are available. Section 5.3 calls out some reasonable examples of mitigation approaches, but I am a little concerned at the guidance that one should worry about these for "sensitive" or "safety-critical" data. People are not good at knowing what data is "sensitive" until it gets used against them. I think this is especially true for IoT applications where we have less deployment experience. Along those lines, the Pervasive Monitoring Considerations section (kudos for having one, btw), tries to balance application needs vs protecting information. But the smart-grid example seems to be a case where the two are really at odds. I am afraid people will interpret this along the lines of "well, the smart-grid application requirements force me to send unprotected data all over the place", when I think the right answer is "Group CoAP should not be used for this sort of application until we can protect the data". **** Minor issues: -- 2.2, 5th paragraph: "For sending nodes, it is recommended to use the IP multicast address literal in a group URI." Can you elaborate on why? I can guess, but anytime we suggest using literal IP addresses rather than DNS names, it's worth elaborating. -- 2.4: " ... if the resource being POSTed to has been designed to cope with the unreliable and lossy nature of IP multicast." Can you elaborate on what it means to be "designed to cope..."? (Or reference something that does?) -- 2.6: I think the Resource Directory reference needs to be normative. (I see the discussion of this from Barry's AD review, where the authors argued that the reference is optional for implementations. But our definition of normative references also includes things necessary to fully understand this draft. Fully understanding even optional features is part of that.) -- 2.7.1, 2nd paragraph: Does this imply a need to coordinate pre-configured group addresses to avoid collisions? -- 2.7.2.1: 2nd 2 last paragraph: Are there any scenarios where a missing port might be determined from DNS, rather than just assuming the default? -- 2.7.2.6, 1st paragraph: "This operation MUST only be used to delete or update group membership objects for which the CoAP client, invoking this operation, is responsible" Do I understand correctly that this replaces the entire set? Is it possible for two different clients to be responsible for two different subsets? If so, how? -- 2.8 and (especially) 2.9: Lack of 2119 language in the "additional guidlines" seems inconsistent with other parts of this draft that do use 2119 language. (I agree the places where you talk about what 7252 already says should not use 2119 language.) I can maybe see the difference for 2.8, but the congestion-avoidance stuff in 2.9 seems as appropriate for 2119 language as most anything else in the draft. (To be clear, I'm not suggesting more or less normative language--only consistency in its use.) **** Nits/editorial comments: -- Abstract: Please expand CoAP on first use in abstract. (But don't remove the expansion in the body.) -- 2.2, 4th paragraph: " ... it is recommended ..."=20 Was that intended as normative?=20 Along those lines, I see a number of sections where 2119 words are used in lower case where it looks like they were not intended as normative (e.g., where you talk about normative requirements from RFC 7252), but in other areas it's not as clear (like this one.) It would be best to either avoid lower case versions of 2119 words, or make it very clear whether they should be interpreted normatively or not. -- 2.7.2, 2nd paragraph: Wording is confusing. Do you mean MUST use the DTLS method, or MUST use some method, with DTLS an option? Sentence seems to mean the former, in which it would be more clear to say "MUST use DTLS as described in ..." -- 2.7.2.1, 3rd paragraph: Please expand JDON on first use. -- 2.7.2.1, paragraph after examples: You mention an optional port for "a" attributes, but not for "n" attributes. The BNF for group-name seems to allow an optional port. (and you mention an optional port for "n" later. _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core From nobody Fri Aug 15 03:39:18 2014 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B796D1A8A39; Fri, 15 Aug 2014 03:39:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p0xSJL8y7zr2; Fri, 15 Aug 2014 03:39:13 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7205A1A8A35; Fri, 15 Aug 2014 03:39:13 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Martin Stiemerling" To: The IESG X-Test-IDTracker: no X-IETF-IDTracker: 5.6.2.p5 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140815103913.13631.95848.idtracker@ietfa.amsl.com> Date: Fri, 15 Aug 2014 03:39:13 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/core/BiULn-2_2F-JUeiJoFvm9kgxlgw Cc: draft-ietf-core-observe@tools.ietf.org, core-chairs@tools.ietf.org, core@ietf.org Subject: [core] Martin Stiemerling's No Objection on draft-ietf-core-observe-14: (with COMMENT) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Aug 2014 10:39:15 -0000 Martin Stiemerling has entered the following ballot position for draft-ietf-core-observe-14: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-ietf-core-observe/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Two points/questions: - I wondered what happens in the case when a server is sending too frequently notifications to the client and had to read to Section 4.5.1. Do you mind adding a reference at the end of Section 1.4 to Section 4.5.1? Just to get an early heads-up to the interested reader. - I have a headache with the model used in Section 3.6, i.e., that the client just forgets its wish to receive notifications and solely relies on the transport, i.e., sending the Reset message. The second part, i.e., describing how to explicitly removing notifications looks the much more straight forward way of removing the notifications form the server. Your first approach looks much more like a last resort handling. Especially, since the Reset messages can get lost and it will take a very long time in this case until the server stops sending notifications. And by the way: thanks for the considerations about congestion control! From nobody Fri Aug 15 07:15:00 2014 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AFDD21A0AE1; Fri, 15 Aug 2014 07:14:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EH6WlZMB3F0Y; Fri, 15 Aug 2014 07:14:57 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C7231A0AEE; Fri, 15 Aug 2014 07:14:51 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Martin Stiemerling" To: The IESG X-Test-IDTracker: no X-IETF-IDTracker: 5.6.2.p5 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140815141451.4412.95883.idtracker@ietfa.amsl.com> Date: Fri, 15 Aug 2014 07:14:51 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/core/5UTVQLbOd6F3lUdPQChzZHmX93g Cc: core-chairs@tools.ietf.org, draft-ietf-core-groupcomm@tools.ietf.org, core@ietf.org Subject: [core] Martin Stiemerling's Discuss on draft-ietf-core-groupcomm-21: (with DISCUSS) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Aug 2014 14:14:58 -0000 Martin Stiemerling has entered the following ballot position for draft-ietf-core-groupcomm-21: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-ietf-core-groupcomm/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- I have no general objection to this draft being published, but I have a doubt about the normative language used in this informational draft. What does it mean that an informational draft is using RFC 2119 language to describe how CORE is being operated for multicast? My confusion started in Section 2.5. Is this solely repeating what's anyway specified by CORE or is it giving different advice? Or is it trying to override the CORE spec? What is happening if there are inconsistent guidances? I am not yet through with the whole document, but I would like to get a clarification about the above point before doing any further review of the draft. From nobody Fri Aug 15 08:21:50 2014 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAE371A0BE8 for ; Fri, 15 Aug 2014 08:21:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.568 X-Spam-Level: X-Spam-Status: No, score=-2.568 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.668] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jYjHJrVRmWEd for ; Fri, 15 Aug 2014 08:21:47 -0700 (PDT) Received: from smtp-in1.interdigital.com (smtp-in1.interdigital.com [64.208.228.133]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F22991A0B80 for ; Fri, 15 Aug 2014 08:21:46 -0700 (PDT) X-ASG-Debug-ID: 1408116105-06daaa1c7daf010001-aa7cYp Received: from smtp-out1.interdigital.com (sahara.interdigital.com [10.0.128.27]) by smtp-in1.interdigital.com with ESMTP id vHa4j7zHFKFl5g4s; Fri, 15 Aug 2014 11:21:45 -0400 (EDT) X-Barracuda-Envelope-From: Akbar.Rahman@InterDigital.com Received: from SAM.InterDigital.com ([10.30.2.11]) by smtp-out1.interdigital.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 15 Aug 2014 11:21:41 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 15 Aug 2014 11:21:19 -0400 X-ASG-Orig-Subj: RE: [core] Martin Stiemerling's Discuss on draft-ietf-core-groupcomm-21: (with DISCUSS) Message-ID: In-Reply-To: <20140815141451.4412.95883.idtracker@ietfa.amsl.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [core] Martin Stiemerling's Discuss on draft-ietf-core-groupcomm-21: (with DISCUSS) Thread-Index: Ac+4k090VAyOM+OHSvSCZZVrg77uuQABGELw References: <20140815141451.4412.95883.idtracker@ietfa.amsl.com> From: "Rahman, Akbar" To: "Martin Stiemerling" , "The IESG" X-OriginalArrivalTime: 15 Aug 2014 15:21:41.0555 (UTC) FILETIME=[9D99E030:01CFB89C] X-Barracuda-Connect: sahara.interdigital.com[10.0.128.27] X-Barracuda-Start-Time: 1408116105 X-Barracuda-URL: http://10.1.245.3:8000/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at interdigital.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=9.0 tests=BSF_SC0_MISMATCH_TO X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.8473 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 BSF_SC0_MISMATCH_TO Envelope rcpt doesn't match header Archived-At: http://mailarchive.ietf.org/arch/msg/core/f1D8aQeRtHoJMNorUPX_9_Hxkyc Cc: core-chairs@tools.ietf.org, draft-ietf-core-groupcomm@tools.ietf.org, core@ietf.org Subject: Re: [core] Martin Stiemerling's Discuss on draft-ietf-core-groupcomm-21: (with DISCUSS) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Aug 2014 15:21:48 -0000 Hi Martin, Thanks for the review. With regards to your question: > My confusion started in Section 2.5 Is this solely repeating what's anyway specified by CORE or is it giving different advice? Or is it trying to override the CORE spec? What is happening if there are inconsistent guidances? Response ------------ First some background. If you look at RFC 7252, then you will see that the main CoAP over IP multicast processing protocol operation is concentrated in section 8. There is also some other scattered references to multicast processing in some other sections (e.g. section 4.8 & Appendix A). However, the WG felt early on that there was not enough explanatory and guidance information in RFC 7252 for someone to correctly implement a complete CoAP over IP multicast system (i.e. CoAP group communication). So, we wrote the groupcomm document with the principle of strictly following RFC 7252 rules, and then providing extra guidance in the areas where RFC 7252 was silent or vague. So to answer the first part of your question. As far as we are aware there is never contradictory advice between the two documents. We spent a lot of time in the WG verifying this. So I'm pretty confident about it. For your specific question about groupcomm Section 2.5. We put that section because RFC 7252 did not have any clear guidance for the re-use of Token values in the multicast case. RFC 7252 only clearly specified the unicast case of re-use of Token values. So again there should not be any contradiction, but only extra guidance. Does that clarify things a bit? (Please note that we had a separate but related question from the Gen-Art reviewer (Ben Campbell) regarding the "management" interface we specified in Section 2.7. This was not specified in RFC 7252. So the question was whether an informational document like groupcomm should specify a new management interface. You can see my response in http://www.ietf.org/mail-archive/web/core/current/msg05536.html ). /Akbar -----Original Message----- From: core [mailto:core-bounces@ietf.org] On Behalf Of Martin Stiemerling Sent: Friday, August 15, 2014 10:15 AM To: The IESG Cc: core-chairs@tools.ietf.org; draft-ietf-core-groupcomm@tools.ietf.org; core@ietf.org Subject: [core] Martin Stiemerling's Discuss on draft-ietf-core-groupcomm-21: (with DISCUSS) Martin Stiemerling has entered the following ballot position for draft-ietf-core-groupcomm-21: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-ietf-core-groupcomm/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- I have no general objection to this draft being published, but I have a doubt about the normative language used in this informational draft. What does it mean that an informational draft is using RFC 2119 language to describe how CORE is being operated for multicast? My confusion started in Section 2.5. Is this solely repeating what's anyway specified by CORE or is it giving different advice? Or is it trying to override the CORE spec? What is happening if there are inconsistent guidances? I am not yet through with the whole document, but I would like to get a clarification about the above point before doing any further review of the draft. _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core From nobody Fri Aug 15 11:08:47 2014 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93AC51A01C3 for ; Fri, 15 Aug 2014 11:08:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, SPF_HELO_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QHrX8XJw92cM for ; Fri, 15 Aug 2014 11:08:44 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4E44E1A01B0 for ; Fri, 15 Aug 2014 11:08:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id s7FI8f5S008151 for ; Fri, 15 Aug 2014 20:08:41 +0200 (CEST) Received: from [192.168.217.106] (p54890029.dip0.t-ipconnect.de [84.137.0.41]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id EBE801EA; Fri, 15 Aug 2014 20:08:40 +0200 (CEST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Carsten Bormann Date: Fri, 15 Aug 2014 20:08:39 +0200 X-Mao-Original-Outgoing-Id: 429818919.178284-2d381c3e78f90c651f41fe1e13df6ca7 Content-Transfer-Encoding: quoted-printable Message-Id: To: "core@ietf.org WG" X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/core/CsL2arZ_3yTGVCI1KTzl5oy7d9I Subject: [core] IETF 90 Minutes draft 0.1 uploaded X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Aug 2014 18:08:45 -0000 I have uploaded version 0.1 of the minutes for the Toronto meeting, at http://www.ietf.org/proceedings/90/minutes/minutes-90-core Please check that your contributions are reflected correctly, and please = do check that the items that you agreed to take on do get done... This = was a good meeting from a point of view of making progress in the WG, = and we want to keep up the pace. The secretariat plans to accept correction submissions up to Wednesday = [sic], September 5th, 2014 [I think the Friday at this date is actually = meant here]. I=92ll be on vacation until Sep 3, so maybe send fixes as = comments to this message to the list so other people see them. As usual, I=92ll end on the remark that the secretariat server *still* = presents text files as ISO-8859-1, RFC 2277 [January 1998] = notwithstanding. Maybe download the minutes and then look at them using = a system from this century. Gr=FC=DFe, Carsten From nobody Mon Aug 18 08:49:43 2014 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5AF931A0665; Mon, 18 Aug 2014 08:49:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q-kmXpQpQ3tt; Mon, 18 Aug 2014 08:49:36 -0700 (PDT) Received: from mail-la0-x231.google.com (mail-la0-x231.google.com [IPv6:2a00:1450:4010:c03::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1BEFB1A064B; Mon, 18 Aug 2014 08:49:35 -0700 (PDT) Received: by mail-la0-f49.google.com with SMTP id hz20so4577142lab.8 for ; Mon, 18 Aug 2014 08:49:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=sRfcoYwSXV945xfGhAzcpSscav6wIUWmYHWthboXLIk=; b=EDS762OG6TCJQIad4wj7hhVuam+LC31Y4TGdgF2P+qCOcj/mJa5jfLfrtDr2UAduQr gw9fJvyA+aUjfIWvHVRS0hdf9slj5SBwPapB565CuQdqrIL21loH8hPrK68ZD8nML7J0 JMYqvrNYzLAm6t0uEFLqmod6LuHKf+Mb9U8Z/OqL9SMkKMwqCbRhFyOAbt4rurRb8ck+ xjKvfOryexwXBkusKDUPLX0O4d0IOxsVcdmkZj/QDUXDYKgAv+tqX5DrN9C/nvw9X9jq DRaj+dZMNEU+yMYhNQ0X7F2eVZYwQ3PzcYyHQ0uOgevI2MYNn4E79/7JCpwMM5U+uOxh aOGw== X-Received: by 10.152.88.39 with SMTP id bd7mr4081033lab.89.1408376974363; Mon, 18 Aug 2014 08:49:34 -0700 (PDT) Received: from martins-mbp-4.fritz.box (port-92-202-105-213.dynamic.qsc.de. [92.202.105.213]) by mx.google.com with ESMTPSA id e7sm3106548laf.40.2014.08.18.08.49.32 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 18 Aug 2014 08:49:33 -0700 (PDT) Message-ID: <53F2208A.6030705@gmail.com> Date: Mon, 18 Aug 2014 17:49:30 +0200 From: Martin Stiemerling User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: "Rahman, Akbar" , The IESG References: <20140815141451.4412.95883.idtracker@ietfa.amsl.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/core/R9D5RlML3KngiMl7t06oTy7Uw0w Cc: core-chairs@tools.ietf.org, draft-ietf-core-groupcomm@tools.ietf.org, core@ietf.org Subject: Re: [core] Martin Stiemerling's Discuss on draft-ietf-core-groupcomm-21: (with DISCUSS) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Aug 2014 15:49:38 -0000 Hi Akbar, Am 15.08.14 um 17:21 schrieb Rahman, Akbar: > Hi Martin, > > > Thanks for the review. With regards to your question: > >> My confusion started in Section 2.5 Is this solely repeating what's > anyway specified by CORE or is it giving different advice? Or is it > trying to override the CORE spec? What is happening if there are > inconsistent guidances? > > > Response > ------------ > First some background. If you look at RFC 7252, then you will see that > the main CoAP over IP multicast processing protocol operation is > concentrated in section 8. There is also some other scattered > references to multicast processing in some other sections (e.g. section > 4.8 & Appendix A). However, the WG felt early on that there was not > enough explanatory and guidance information in RFC 7252 for someone to > correctly implement a complete CoAP over IP multicast system (i.e. CoAP > group communication). I do see the point and also appreciate drafts that pull together the differnet pieces so that information becomes earier accessible for implementers. > > So, we wrote the groupcomm document with the principle of strictly > following RFC 7252 rules, and then providing extra guidance in the areas > where RFC 7252 was silent or vague. So to answer the first part of your > question. As far as we are aware there is never contradictory advice > between the two documents. We spent a lot of time in the WG verifying > this. So I'm pretty confident about it. I can live with this and do believe that the group double checked this. > > For your specific question about groupcomm Section 2.5. We put that > section because RFC 7252 did not have any clear guidance for the re-use > of Token values in the multicast case. RFC 7252 only clearly specified > the unicast case of re-use of Token values. So again there should not > be any contradiction, but only extra guidance. Extra guidance casted in normative language in an informational draft makes we feeling really weird. This does not provide benefit, strictly speaking, as this RFC is not updating RFC 7252 with respect to the token handling in the multicast use, as it should, isn't it? > > Does that clarify things a bit? Thanks for your prompt reply, but I do see the need for further discussions with your AD, as this draft is, at least, modifying the protocol behaviour of RFC 7252 in two places (Sections 2.5 and also 2.7). But the draft is never saying this explicity. Thanks, Martin > > > (Please note that we had a separate but related question from the > Gen-Art reviewer (Ben Campbell) regarding the "management" interface we > specified in Section 2.7. This was not specified in RFC 7252. So the > question was whether an informational document like groupcomm should > specify a new management interface. You can see my response in > http://www.ietf.org/mail-archive/web/core/current/msg05536.html ). > > > /Akbar > > > > -----Original Message----- > From: core [mailto:core-bounces@ietf.org] On Behalf Of Martin > Stiemerling > Sent: Friday, August 15, 2014 10:15 AM > To: The IESG > Cc: core-chairs@tools.ietf.org; > draft-ietf-core-groupcomm@tools.ietf.org; core@ietf.org > Subject: [core] Martin Stiemerling's Discuss on > draft-ietf-core-groupcomm-21: (with DISCUSS) > > Martin Stiemerling has entered the following ballot position for > draft-ietf-core-groupcomm-21: Discuss > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > http://datatracker.ietf.org/doc/draft-ietf-core-groupcomm/ > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > I have no general objection to this draft being published, but I have a > doubt about the normative language used in this informational draft. > What does it mean that an informational draft is using RFC 2119 language > to describe how CORE is being operated for multicast? > > My confusion started in Section 2.5. Is this solely repeating what's > anyway specified by CORE or is it giving different advice? Or is it > trying to override the CORE spec? What is happening if there are > inconsistent guidances? > > I am not yet through with the whole document, but I would like to get a > clarification about the above point before doing any further review of > the draft. > > > > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > From nobody Mon Aug 18 09:04:59 2014 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 435DA1A067B; Mon, 18 Aug 2014 09:04:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GJMfIgP5GncF; Mon, 18 Aug 2014 09:04:50 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A37D91A0671; Mon, 18 Aug 2014 09:04:50 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Martin Stiemerling" To: The IESG X-Test-IDTracker: no X-IETF-IDTracker: 5.6.2.p5 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140818160450.15926.23596.idtracker@ietfa.amsl.com> Date: Mon, 18 Aug 2014 09:04:50 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/core/FSjGEI6PR9bErCy8uTeeZSTqnBs Cc: core-chairs@tools.ietf.org, draft-ietf-core-groupcomm@tools.ietf.org, core@ietf.org Subject: [core] Martin Stiemerling's Discuss on draft-ietf-core-groupcomm-21: (with DISCUSS) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Aug 2014 16:04:56 -0000 Martin Stiemerling has entered the following ballot position for draft-ietf-core-groupcomm-21: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-ietf-core-groupcomm/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Updated: I have objections about this draft being published in its current form and with its current status. The draft updates protocol behavior of RFC 7252 in at least two Sections: 2.5 and also 2.7. But is never saying so and legally speaking also not requesting any update of RFC 7252. Section 2.5 updates the handling of tokens for the mutlicast usage. Section 2.7 adds a completely new functionality to the protocol. This has also been nicely pointed out by the GENART reviewer: http://www.ietf.org/mail-archive/web/core/current/msg05535.html Probably the document is heading for standards track instead of informational? Further, I do see multiple playes where the RFC 2119 language is inappropriate: 2.2. Group Definition and Naming [...] All CoAP server nodes SHOULD join the "All CoAP Nodes" multicast group [RFC7252], Section 12.8) by default to enable CoAP discovery. For IPv4, the address is 224.0.1.187 and for IPv6 a server node joins at least both the link-local scoped address FF02::FD and the site- local scoped address FF05::FD. IPv6 addresses of other scopes MAY be enabled. Since this is (hopefully) just repeating what RFC 7252 say, it is just good to say: "All CoAP server nodes should/are supposed to join the "All CoAP Nodes" multicast" Also the "MAY be" is a "can be" in reality. 2.7.2. Membership Configuration RESTful Interface The " an OPTIONAL CoAP membership configuration RESTful" is misplaced, as this in informational draft, but this goes back to my general DISCUSS point above. Further: To access this interface a client MUST use unicast CoAP methods (GET/PUT/POST/DELETE). This interface is a This MUST is not correct here. A sentence saying that only the unicast methods are useful in this respect is sufficient. And here the contradiction is happening, as I do not see a MUST for DTLS in RFC 7252 and this text below is also not adding anything useful to the discussions what is needed to achieve interoperability, i.e., inappropriate for MUST in this place: Also, a form of authorization (making use of DTLS-secured CoAP [RFC7252]) MUST be used such that only authorized controllers are allowed by an endpoint to configure its group membership. From nobody Mon Aug 18 09:27:35 2014 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23E321A06B1 for ; Mon, 18 Aug 2014 09:27:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.568 X-Spam-Level: X-Spam-Status: No, score=-2.568 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.668] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5EslWWoQ_C7B for ; Mon, 18 Aug 2014 09:27:29 -0700 (PDT) Received: from smtp-in1.interdigital.com (smtp-in1.interdigital.com [64.208.228.133]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BE9A21A06B5 for ; Mon, 18 Aug 2014 09:27:27 -0700 (PDT) X-ASG-Debug-ID: 1408379245-06daaa1c7ed36f0001-aa7cYp Received: from smtp-out1.interdigital.com (sahara.interdigital.com [10.0.128.27]) by smtp-in1.interdigital.com with ESMTP id 0mei1iAqUg9oSg3n; Mon, 18 Aug 2014 12:27:25 -0400 (EDT) X-Barracuda-Envelope-From: Akbar.Rahman@InterDigital.com Received: from SAM.InterDigital.com ([10.30.2.11]) by smtp-out1.interdigital.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 18 Aug 2014 12:27:25 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 18 Aug 2014 12:27:19 -0400 X-ASG-Orig-Subj: RE: [core] Martin Stiemerling's Discuss on draft-ietf-core-groupcomm-21: (with DISCUSS) Message-ID: In-Reply-To: <20140818160450.15926.23596.idtracker@ietfa.amsl.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [core] Martin Stiemerling's Discuss on draft-ietf-core-groupcomm-21: (with DISCUSS) Thread-Index: Ac+6/ioPsk0QNmW1QZi7bjeUCcxwHQAAo+kw References: <20140818160450.15926.23596.idtracker@ietfa.amsl.com> From: "Rahman, Akbar" To: "Martin Stiemerling" , "The IESG" X-OriginalArrivalTime: 18 Aug 2014 16:27:25.0988 (UTC) FILETIME=[4BE7D640:01CFBB01] X-Barracuda-Connect: sahara.interdigital.com[10.0.128.27] X-Barracuda-Start-Time: 1408379245 X-Barracuda-URL: http://10.1.245.3:8000/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at interdigital.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=9.0 tests=BSF_SC0_MISMATCH_TO X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.8582 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 BSF_SC0_MISMATCH_TO Envelope rcpt doesn't match header Archived-At: http://mailarchive.ietf.org/arch/msg/core/URjiXq-apUkgQWptKYF7TELy_hs Cc: core-chairs@tools.ietf.org, draft-ietf-core-groupcomm@tools.ietf.org, core@ietf.org Subject: Re: [core] Martin Stiemerling's Discuss on draft-ietf-core-groupcomm-21: (with DISCUSS) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Aug 2014 16:27:31 -0000 Hi Martin, Thanks for the update feedback. Here are my responses: >The draft updates protocol behavior of RFC 7252 in at least two Sections: 2.5 and also 2.7. But is never saying so Ok. We will clarify this in the scope and intro. >Probably the document is heading for standards track instead of informational? Can we instead consider it for BCP status? We have some other drafts in the CORE WG that are BCP and I am thinking that this may be in the same class. Barry - Can you provide a recommendation here? > Further, I do see multiple playes where the RFC 2119 language is inappropriate: Okay. Maybe the best thing will be for me to remove this language. I think Barry hinted at that in earlier AD reviews as well. Best Regards, Akbar -----Original Message----- From: core [mailto:core-bounces@ietf.org] On Behalf Of Martin Stiemerling Sent: Monday, August 18, 2014 12:05 PM To: The IESG Cc: core-chairs@tools.ietf.org; draft-ietf-core-groupcomm@tools.ietf.org; core@ietf.org Subject: [core] Martin Stiemerling's Discuss on draft-ietf-core-groupcomm-21: (with DISCUSS) Martin Stiemerling has entered the following ballot position for draft-ietf-core-groupcomm-21: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-ietf-core-groupcomm/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Updated: I have objections about this draft being published in its current form and with its current status. The draft updates protocol behavior of RFC 7252 in at least two Sections: 2.5 and also 2.7. But is never saying so and legally speaking also not requesting any update of RFC 7252.=20 Section 2.5 updates the handling of tokens for the mutlicast usage.=20 Section 2.7 adds a completely new functionality to the protocol. This has also been nicely pointed out by the GENART reviewer: http://www.ietf.org/mail-archive/web/core/current/msg05535.html Probably the document is heading for standards track instead of informational? Further, I do see multiple playes where the RFC 2119 language is inappropriate: 2.2. Group Definition and Naming [...] All CoAP server nodes SHOULD join the "All CoAP Nodes" multicast group [RFC7252], Section 12.8) by default to enable CoAP discovery. For IPv4, the address is 224.0.1.187 and for IPv6 a server node joins at least both the link-local scoped address FF02::FD and the site- local scoped address FF05::FD. IPv6 addresses of other scopes MAY be enabled. Since this is (hopefully) just repeating what RFC 7252 say, it is just good to say:=20 "All CoAP server nodes should/are supposed to join the "All CoAP Nodes" multicast" Also the "MAY be" is a "can be" in reality.=20 2.7.2. Membership Configuration RESTful Interface The " an OPTIONAL CoAP membership configuration RESTful" is misplaced, as this in informational draft, but this goes back to my general DISCUSS point above.=20 Further: To access this interface a client MUST use unicast CoAP methods (GET/PUT/POST/DELETE). This interface is a This MUST is not correct here. A sentence saying that only the unicast methods are useful in this respect is sufficient. And here the contradiction is happening, as I do not see a MUST for DTLS in RFC 7252 and this text below is also not adding anything useful to the discussions what is needed to achieve interoperability, i.e., inappropriate for MUST in this place: Also, a form of authorization (making use of DTLS-secured CoAP [RFC7252]) MUST be used such that only authorized controllers are allowed by an endpoint to configure its group membership. _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core From nobody Mon Aug 18 18:39:03 2014 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FA1D1A8781; Mon, 18 Aug 2014 18:39:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lN7QhNt_nWTO; Mon, 18 Aug 2014 18:38:59 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 71AC81A8778; Mon, 18 Aug 2014 18:38:58 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "Spencer Dawkins" To: The IESG X-Test-IDTracker: no X-IETF-IDTracker: 5.6.2.p5 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140819013858.3459.81149.idtracker@ietfa.amsl.com> Date: Mon, 18 Aug 2014 18:38:58 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/core/_HcPOXaXioSurXFlIQm8w-0dY6U Cc: draft-ietf-core-observe@tools.ietf.org, core-chairs@tools.ietf.org, core@ietf.org Subject: [core] Spencer Dawkins' No Objection on draft-ietf-core-observe-14: (with COMMENT) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Aug 2014 01:39:00 -0000 Spencer Dawkins has entered the following ballot position for draft-ietf-core-observe-14: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-ietf-core-observe/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I liked this document more than the number of questions I have might make you guess ... These aren't blocking, and "Spencer doesn't grok CoAP" could be a reasonable response to most of them, but I'd ask that you consider them along with any other comments you might collect during IESG evaluation. In this text: 3.2. Notifications Notifications typically have a 2.05 (Content) response code. They include an Observe Option with a sequence number for reordering detection (see Section 3.4), and a payload in the same Content-Format as the initial response. If the client included one or more ETag Options in the request (see Section 3.3), notifications can also have ^^^^ a 2.03 (Valid) response code. I would read “also” as implying “simultaneously”, and I bet that’s not true. If it’s not, would “notifications would have a 2.03 (Valid) response code rather than 2.05” be clearer? I mention this mostly because CoAP is the same as HTTP except when it isn’t, so I don’t know that you don’t mean “simultaneously” without going to look :-) In this text: 3.3.1. Freshness To make sure it has a current representation and/or to re-register its interest in a resource, a client MAY issue a new GET request with the same token as the original at any time. All options MUST be identical to those in the original request, except for the set of ETag Options. It is RECOMMENDED that the client does not issue the request while it still has a fresh notification/response for the resource in its cache. Additionally, the client SHOULD at least wait for a random amount of time between 5 and 15 seconds after Max-Age expired to avoid synchronicity with other clients. Am I reading this correctly as “wait between 5 and 15 seconds after Max-Age expires to send a GET and re-register”? If so, you folk are the experts, but is this making it more likely that the client will miss state changes if the GET to re-register is dropped? Thanks for the shout-out to randomness, of course. In this text: 4.3.1. Freshness After returning the initial response, the server MUST try to keep the ^^^^^^^^^^^^^^^ returned representation current, i.e., it MUST keep the resource state observed by the client as closely in sync with the actual resource state as possible. and in at least one other place in Section 4 that talk about trying to keep the client in sync, it looks like you’re using RFC 2119 language to describe what the protocol designers are thinking (“we MUST make sure that happens”), in ways that can’t be tested and don't impact interoperability. The second MUST seems more reasonable (squishy, but I wouldn't complain about it). In this text: 4.5.1. Congestion Control The server SHOULD NOT send more than one non-confirmable notification ^^^^^^^^^^ per round-trip time (RTT) to a client on average. If the server cannot maintain an RTT estimate for a client, it SHOULD NOT send more than one non-confirmable notification every 3 seconds, and SHOULD use an even less aggressive rate when possible (see also Section 3.1.2 of RFC 5405 [RFC5405]). could you give some guidance on violating the SHOULD, and when/why that would be a great idea? The rest of the congestion control section seemed very reasonable. Thank you. In this text: 5. Intermediaries To perform this task, the intermediary SHOULD make use of the ^^^^^^ protocol specified in this document, taking the role of the client and registering its own interest in the target resource with the next hop towards the server. I find myself wondering why this isn’t a MUST. From nobody Tue Aug 19 07:43:43 2014 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62D301A8907; Tue, 19 Aug 2014 07:43:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ra895lhLVLr4; Tue, 19 Aug 2014 07:43:36 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E96691A8906; Tue, 19 Aug 2014 07:43:34 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Brian Haberman" To: The IESG X-Test-IDTracker: no X-IETF-IDTracker: 5.6.2.p5 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140819144334.30860.77254.idtracker@ietfa.amsl.com> Date: Tue, 19 Aug 2014 07:43:34 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/core/5_qmPfu_er2yCr-SNwvCzhBq1RQ Cc: core-chairs@tools.ietf.org, draft-ietf-core-groupcomm@tools.ietf.org, core@ietf.org Subject: [core] Brian Haberman's Discuss on draft-ietf-core-groupcomm-21: (with DISCUSS and COMMENT) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Aug 2014 14:43:41 -0000 Brian Haberman has entered the following ballot position for draft-ietf-core-groupcomm-21: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-ietf-core-groupcomm/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- I have no issues with the goal of this document, but I do have some items I would like to talk about: 1. The text in section 1.2 implies that the primary multicast mode of operation is source-specific, but doesn't explicitly state that. Is it intended that multicast is only done in an SSM mode? If so, it would be good to provide explicit discussion of that (including references to relevant SSM RFCs such as 3569, 4604, and 4607). If the goal is to also support ASM, that should be stated explicitly. 2. Does the multicast proxy forwarding described in RFC 4605 apply in section 2.1? 3. I am a little concerned with the SHOULD used in section 2.2 when discussing nodes joining the All-CoAP-Nodes multicast address. What happens if a device does not join that group? Will the protocol break? 4. Section 2.3 should allow a device to obtain the port number for the group from the URI schema referenced in section 2.2. 5. I see that the socket() API (RFC 3542) is referenced, but it is not discussed in terms of CoAP interacting with the group management protocols. Is it assumed that implementers know that they are to use that API to indicate changes in group membership state to IGMP/MLD? ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- The various discussions of reliable multicast in the document may benefit from an informative reference to a technique such as RFC 3940. From nobody Tue Aug 19 09:30:14 2014 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4996F1A0645 for ; Tue, 19 Aug 2014 09:30:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.568 X-Spam-Level: X-Spam-Status: No, score=-2.568 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.668] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0W3FWdmI3hnv for ; Tue, 19 Aug 2014 09:30:10 -0700 (PDT) Received: from smtp-in1.interdigital.com (smtp-in1.interdigital.com [64.208.228.133]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4FF121A0029 for ; Tue, 19 Aug 2014 09:30:10 -0700 (PDT) X-ASG-Debug-ID: 1408465808-06daaa39ba02e10001-aa7cYp Received: from smtp-out1.interdigital.com (sahara.interdigital.com [10.0.128.27]) by smtp-in1.interdigital.com with ESMTP id jP6FmRXuSa9OniY4; Tue, 19 Aug 2014 12:30:08 -0400 (EDT) X-Barracuda-Envelope-From: Akbar.Rahman@InterDigital.com Received: from SAM.InterDigital.com ([10.30.2.11]) by smtp-out1.interdigital.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 19 Aug 2014 12:30:07 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 19 Aug 2014 12:29:36 -0400 X-ASG-Orig-Subj: RE: [core] Brian Haberman's Discuss on draft-ietf-core-groupcomm-21: (with DISCUSS and COMMENT) Message-ID: In-Reply-To: <20140819144334.30860.77254.idtracker@ietfa.amsl.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [core] Brian Haberman's Discuss on draft-ietf-core-groupcomm-21: (with DISCUSS and COMMENT) Thread-Index: Ac+7u/tM256WHIcaQDSdSbeubdAc5gAB8Gng References: <20140819144334.30860.77254.idtracker@ietfa.amsl.com> From: "Rahman, Akbar" To: "Brian Haberman" , "The IESG" X-OriginalArrivalTime: 19 Aug 2014 16:30:07.0996 (UTC) FILETIME=[D6E20BC0:01CFBBCA] X-Barracuda-Connect: sahara.interdigital.com[10.0.128.27] X-Barracuda-Start-Time: 1408465808 X-Barracuda-URL: http://10.1.245.3:8000/cgi-mod/mark.cgi X-Barracuda-BRTS-Status: 1 X-Virus-Scanned: by bsmtpd at interdigital.com X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=9.0 tests=BSF_SC0_MISMATCH_TO X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.8618 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 BSF_SC0_MISMATCH_TO Envelope rcpt doesn't match header Archived-At: http://mailarchive.ietf.org/arch/msg/core/_LY-73_t_pZNygB4mhRhw0E82e0 Cc: core-chairs@tools.ietf.org, draft-ietf-core-groupcomm@tools.ietf.org, core@ietf.org Subject: Re: [core] Brian Haberman's Discuss on draft-ietf-core-groupcomm-21: (with DISCUSS and COMMENT) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Aug 2014 16:30:12 -0000 Hi Brain, Thanks for the good review. Following are my responses: >1. The text in section 1.2 implies that the primary multicast mode of operation is source-specific, but doesn't explicitly state that. Is it intended that multicast is only done in an SSM mode? If so, it would be good to provide explicit discussion of that (including references to relevant SSM RFCs such as 3569, 4604, and 4607). If the goal is to also support ASM, that should be stated explicitly. Response: ------------- The intent was not to imply that primary mode should be Source Specific Multicast (SSM. The goal is instead to support Any Source Multicast (ASM). We can update to specifically state that. Are there any specific RFCs we should point to for ASM support? (Note: In some of the future multicast security solutions for group communications being discussed in DICE WG there is interest in source authentication. But even in DICE at this point they are not specifying SSM). >2. Does the multicast proxy forwarding described in RFC 4605 apply in section 2.1? Response: ------------- We did not have a specific requirement to support RFC 4605 multicast proxy forwarding for CoAP group communication. Though of course RFC 4605 type proxy may be deployed as part of the underlying IP multicast infrastructure that CoAP group communication runs on. So, if you wanted us to just point to RFC 4605 as a background reference from section 2.1 then I am fine with that. Is that what you wanted? Please also note that the main proxy functionality that we need for group communication is described in section 2.10. But this is very specific to a CoAP proxy functionality and not RFC 4605 functionality. I just wanted to draw your attention to that fact as we are discussing proxies. >3. I am a little concerned with the SHOULD used in section 2.2 when discussing nodes joining the All-CoAP-Nodes multicast address. What happens if a device does not join that group? Will the protocol break? Response: ------------- The SHOULD was reflecting what was already there in the base CoAP spec (RFC 7252) and CORE link format (RFC 6690). That is, CoAP devices are strongly encouraged to join a multicast group so that they can be easily discoverable by other CoAP nodes. (Please note that it is not a MUST but a SHOULD). If the device decides not join then it simply will not be discovered. Nothing will really break. (Please note that there is a separate thread with Martin that is requesting clarification (from the AD) of whether we should have any normative language in an Informational document or whether this document should be Standards track or BCP instead ...) >4. Section 2.3 should allow a device to obtain the port number for the group from the URI schema referenced in section 2.2. Response: ------------- Section 2.3 reference to ports is guidance for the listener as to which port it should be monitoring on to receive the IP multicast. So I am unfortunately missing your point. Can you please expand on your thinking for me? >5. I see that the socket() API (RFC 3542) is referenced, but it is not discussed in terms of CoAP interacting with the group management protocols. Is it assumed that implementers know that they are to use that API to indicate changes in group membership state to IGMP/MLD? Response: ------------- Our main reference to interaction between CoAP and the group management protocols is in the last paragraph of http://tools.ietf.org/html/draft-ietf-core-groupcomm-21#section-2.7.2.1 (and then repeated in some of the following sections). Should we add the reference to RFC 3542 in that last paragraph (and corresponding following paragraphs)? I think this is a good idea but just want to double check with you. Best Regards, Akbar -----Original Message----- From: core [mailto:core-bounces@ietf.org] On Behalf Of Brian Haberman Sent: Tuesday, August 19, 2014 10:44 AM To: The IESG Cc: core-chairs@tools.ietf.org; draft-ietf-core-groupcomm@tools.ietf.org; core@ietf.org Subject: [core] Brian Haberman's Discuss on draft-ietf-core-groupcomm-21: (with DISCUSS and COMMENT) Brian Haberman has entered the following ballot position for draft-ietf-core-groupcomm-21: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-ietf-core-groupcomm/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- I have no issues with the goal of this document, but I do have some items I would like to talk about: 1. The text in section 1.2 implies that the primary multicast mode of operation is source-specific, but doesn't explicitly state that. Is it intended that multicast is only done in an SSM mode? If so, it would be good to provide explicit discussion of that (including references to relevant SSM RFCs such as 3569, 4604, and 4607). If the goal is to also support ASM, that should be stated explicitly. 2. Does the multicast proxy forwarding described in RFC 4605 apply in section 2.1? 3. I am a little concerned with the SHOULD used in section 2.2 when discussing nodes joining the All-CoAP-Nodes multicast address. What happens if a device does not join that group? Will the protocol break? 4. Section 2.3 should allow a device to obtain the port number for the group from the URI schema referenced in section 2.2. 5. I see that the socket() API (RFC 3542) is referenced, but it is not discussed in terms of CoAP interacting with the group management protocols. Is it assumed that implementers know that they are to use that API to indicate changes in group membership state to IGMP/MLD? ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- The various discussions of reliable multicast in the document may benefit from an informative reference to a technique such as RFC 3940. _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core From nobody Tue Aug 19 09:56:37 2014 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 092C01A0475; Tue, 19 Aug 2014 09:56:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U108NQ2_Xz8E; Tue, 19 Aug 2014 09:56:27 -0700 (PDT) Received: from uillean.fuaim.com (uillean.fuaim.com [206.197.161.140]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7D3151A0640; Tue, 19 Aug 2014 09:56:27 -0700 (PDT) Received: from clairseach.fuaim.com (clairseach-high.fuaim.com [206.197.161.158]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by uillean.fuaim.com (Postfix) with ESMTP id 61D018811D; Tue, 19 Aug 2014 09:56:27 -0700 (PDT) Received: from 1025298212.rude2.ra.johnshopkins.edu (addr16212925014.ippl.jhmi.edu [162.129.250.14]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by clairseach.fuaim.com (Postfix) with ESMTP id C6E5671B0001; Tue, 19 Aug 2014 09:56:26 -0700 (PDT) Message-ID: <53F381B0.1040307@innovationslab.net> Date: Tue, 19 Aug 2014 12:56:16 -0400 From: Brian Haberman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "Rahman, Akbar" , The IESG References: <20140819144334.30860.77254.idtracker@ietfa.amsl.com> In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="aNcBK7NJj1KmJ5L55viisgo7aSsot3dDJ" Archived-At: http://mailarchive.ietf.org/arch/msg/core/t5liCNSK5tnwMoN4pEvW2Z3HL5E Cc: core-chairs@tools.ietf.org, draft-ietf-core-groupcomm@tools.ietf.org, core@ietf.org Subject: Re: [core] Brian Haberman's Discuss on draft-ietf-core-groupcomm-21: (with DISCUSS and COMMENT) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Aug 2014 16:56:30 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --aNcBK7NJj1KmJ5L55viisgo7aSsot3dDJ Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Akbar, On 8/19/14 12:29 PM, Rahman, Akbar wrote: > Hi Brain, >=20 >=20 > Thanks for the good review. Following are my responses: >=20 >> 1. The text in section 1.2 implies that the primary multicast mode of > operation is source-specific, but doesn't explicitly state that. Is it= > intended that multicast is only done in an SSM mode? If so, it would b= e > good to provide explicit discussion of that (including references to > relevant SSM RFCs such as 3569, 4604, and 4607). If the goal is to als= o > support ASM, that should be stated explicitly. >=20 > Response: > ------------- > The intent was not to imply that primary mode should be Source Specific= > Multicast (SSM. The goal is instead to support Any Source Multicast > (ASM). We can update to specifically state that. Are there any > specific RFCs we should point to for ASM support? >=20 > (Note: In some of the future multicast security solutions for group > communications being discussed in DICE WG there is interest in source > authentication. But even in DICE at this point they are not specifying= > SSM). >=20 The term ASM is defined in several different RFCs. The original multicast specification (RFC 1112) is often referenced as the definition of ASM. RFC 5110 should have had a crisp definition, but it doesn't. >=20 >=20 >=20 >> 2. Does the multicast proxy forwarding described in RFC 4605 apply in > section 2.1? >=20 > Response: > ------------- > We did not have a specific requirement to support RFC 4605 multicast > proxy forwarding for CoAP group communication. Though of course RFC > 4605 type proxy may be deployed as part of the underlying IP multicast > infrastructure that CoAP group communication runs on. So, if you wante= d > us to just point to RFC 4605 as a background reference from section 2.1= > then I am fine with that. Is that what you wanted? >=20 I just wanted to ensure that this approach did not preclude RFC 4605 in constrained networks/devices. An informative reference would be fine. > Please also note that the main proxy functionality that we need for > group communication is described in section 2.10. But this is very > specific to a CoAP proxy functionality and not RFC 4605 functionality. > I just wanted to draw your attention to that fact as we are discussing > proxies. >=20 >=20 Yes. >=20 >=20 >> 3. I am a little concerned with the SHOULD used in section 2.2 when > discussing nodes joining the All-CoAP-Nodes multicast address. What > happens if a device does not join that group? Will the protocol break?= >=20 > Response: > ------------- > The SHOULD was reflecting what was already there in the base CoAP spec > (RFC 7252) and CORE link format (RFC 6690). That is, CoAP devices are > strongly encouraged to join a multicast group so that they can be easil= y > discoverable by other CoAP nodes. (Please note that it is not a MUST > but a SHOULD). If the device decides not join then it simply will not > be discovered. Nothing will really break. >=20 Ok. I just wanted to make sure the lack of ability to discover a node would not break multicast distribution. > (Please note that there is a separate thread with Martin that is > requesting clarification (from the AD) of whether we should have any > normative language in an Informational document or whether this documen= t > should be Standards track or BCP instead ...) >=20 >=20 Yes, I am aware of that ongoing discussion. >=20 >=20 >> 4. Section 2.3 should allow a device to obtain the port number for the= > group from the URI schema referenced in section 2.2. >=20 > Response: > ------------- > Section 2.3 reference to ports is guidance for the listener as to which= > port it should be monitoring on to receive the IP multicast. So I am > unfortunately missing your point. Can you please expand on your > thinking for me? >=20 Sure (since I worded my point very poorly). If I am a listener (called a server in 2.3), I need to select a port number. That port number needs to be available to the client devices. So, my concern is one of ensuring the clients select the correct destination port based on the port selected by the server for listening. In relation to 2.3, the server should be able to use the port number published in the URI described in section 2.2, right? >=20 >=20 >> 5. I see that the socket() API (RFC 3542) is referenced, but it is not= > discussed in terms of CoAP interacting with the group management > protocols. Is it assumed that implementers know that they are to use > that API to indicate changes in group membership state to IGMP/MLD? >=20 > Response: > ------------- > Our main reference to interaction between CoAP and the group management= > protocols is in the last paragraph of > http://tools.ietf.org/html/draft-ietf-core-groupcomm-21#section-2.7.2.1= > (and then repeated in some of the following sections). Should we add > the reference to RFC 3542 in that last paragraph (and corresponding > following paragraphs)? I think this is a good idea but just want to > double check with you. >=20 That would make things clearer. Thanks for the quick response! Regards, Brian --aNcBK7NJj1KmJ5L55viisgo7aSsot3dDJ Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.20 (Darwin) Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJT84G3AAoJEBOZRqCi7goqvIwH/REqd7qCqWQWXmzPcNTBE1ml /ql0mrd+sCdNS+CoQV6QI07jZNzRj+W+KlvCIMVcaxLIUCK+2kppvT5Zb/R7G5/I NkCVBF6knlG64u3lBcreduHvbf+sFUllCotmPurQ/+a0N0I3ko++PKgDcOfITkvX O4m3tmyKOClee3nVGWUBEnNE7QJMfe/ObwqcZ+Cioujf88mtO0NfMbFqZcvuTdL/ rM8eRy9o7N408/FqEjIufLUCvUZR/nY7cutnPV00J21lQJgOwmCSERGaa6A/nXh/ Fc/mYy6Bw93cEvSIKekW7qelzSsGQ3oGsclrtk43d/rkr9JNWmr0zRo6nZdjTbk= =9gzc -----END PGP SIGNATURE----- --aNcBK7NJj1KmJ5L55viisgo7aSsot3dDJ-- From nobody Tue Aug 19 12:37:03 2014 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 620441A0B09 for ; Tue, 19 Aug 2014 12:36:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.568 X-Spam-Level: X-Spam-Status: No, score=-2.568 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.668] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ATorUHgLuHr1 for ; Tue, 19 Aug 2014 12:36:55 -0700 (PDT) Received: from smtp-in1.interdigital.com (smtp-in1.interdigital.com [64.208.228.133]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 724061A0B08 for ; Tue, 19 Aug 2014 12:36:55 -0700 (PDT) X-ASG-Debug-ID: 1408477013-06daaa39b906b00001-aa7cYp Received: from smtp-out1.interdigital.com (sahara.interdigital.com [10.0.128.27]) by smtp-in1.interdigital.com with ESMTP id DsPHUqmY5fEve99O; Tue, 19 Aug 2014 15:36:53 -0400 (EDT) X-Barracuda-Envelope-From: Akbar.Rahman@InterDigital.com Received: from SAM.InterDigital.com ([10.30.2.11]) by smtp-out1.interdigital.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 19 Aug 2014 15:36:53 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 19 Aug 2014 15:36:09 -0400 X-ASG-Orig-Subj: RE: [core] Brian Haberman's Discuss on draft-ietf-core-groupcomm-21: (with DISCUSS and COMMENT) Message-ID: In-Reply-To: <53F381B0.1040307@innovationslab.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [core] Brian Haberman's Discuss on draft-ietf-core-groupcomm-21: (with DISCUSS and COMMENT) Thread-Index: Ac+7zoXLJDJj0trLTVOzFcatvoRqtAAFDb2A References: <20140819144334.30860.77254.idtracker@ietfa.amsl.com> <53F381B0.1040307@innovationslab.net> From: "Rahman, Akbar" To: "Brian Haberman" , "The IESG" X-OriginalArrivalTime: 19 Aug 2014 19:36:53.0308 (UTC) FILETIME=[EDC4F7C0:01CFBBE4] X-Barracuda-Connect: sahara.interdigital.com[10.0.128.27] X-Barracuda-Start-Time: 1408477013 X-Barracuda-URL: http://10.1.245.3:8000/cgi-mod/mark.cgi X-Barracuda-BRTS-Status: 1 X-Virus-Scanned: by bsmtpd at interdigital.com X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=9.0 tests=BSF_SC0_MISMATCH_TO X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.8624 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 BSF_SC0_MISMATCH_TO Envelope rcpt doesn't match header Archived-At: http://mailarchive.ietf.org/arch/msg/core/0M_z1YQUOTfsjOZ7SqwWpik2_c4 Cc: core-chairs@tools.ietf.org, draft-ietf-core-groupcomm@tools.ietf.org, core@ietf.org Subject: Re: [core] Brian Haberman's Discuss on draft-ietf-core-groupcomm-21: (with DISCUSS and COMMENT) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Aug 2014 19:36:57 -0000 Hi Brian, Thanks for the responses. I will update the draft with all the points below that we have closed on. For the one open question, below is my response: > If I am a listener (called a server in 2.3), I need to select a port number. That port number needs to be available to the client devices. So, my concern is one of ensuring the clients select the correct destination port based on the port selected by the server for listening. In relation to 2.3, the server should be able to use the port number published in the URI described in section 2.2, right? Response: ------------- Yes, the server should be listening on the port number of the URI as described in section 2.2. Please note that section 2.2 is describing the general structure of the CoAP group URI, and also discussing the case of when the URI is an FQDN and how to resolve it to an IP address through DNS. If that is what you are referring to as "publishing" then we are in sync. Best Regards, Akbar -----Original Message----- From: Brian Haberman [mailto:brian@innovationslab.net]=20 Sent: Tuesday, August 19, 2014 12:56 PM To: Rahman, Akbar; The IESG Cc: core-chairs@tools.ietf.org; draft-ietf-core-groupcomm@tools.ietf.org; core@ietf.org Subject: Re: [core] Brian Haberman's Discuss on draft-ietf-core-groupcomm-21: (with DISCUSS and COMMENT) Hi Akbar, On 8/19/14 12:29 PM, Rahman, Akbar wrote: > Hi Brain, >=20 >=20 > Thanks for the good review. Following are my responses: >=20 >> 1. The text in section 1.2 implies that the primary multicast mode of > operation is source-specific, but doesn't explicitly state that. Is=20 > it intended that multicast is only done in an SSM mode? If so, it=20 > would be good to provide explicit discussion of that (including=20 > references to relevant SSM RFCs such as 3569, 4604, and 4607). If the > goal is to also support ASM, that should be stated explicitly. >=20 > Response: > ------------- > The intent was not to imply that primary mode should be Source=20 > Specific Multicast (SSM. The goal is instead to support Any Source=20 > Multicast (ASM). We can update to specifically state that. Are there > any specific RFCs we should point to for ASM support? >=20 > (Note: In some of the future multicast security solutions for group=20 > communications being discussed in DICE WG there is interest in source=20 > authentication. But even in DICE at this point they are not=20 > specifying SSM). >=20 The term ASM is defined in several different RFCs. The original multicast specification (RFC 1112) is often referenced as the definition of ASM. RFC 5110 should have had a crisp definition, but it doesn't. >=20 >=20 >=20 >> 2. Does the multicast proxy forwarding described in RFC 4605 apply in > section 2.1? >=20 > Response: > ------------- > We did not have a specific requirement to support RFC 4605 multicast=20 > proxy forwarding for CoAP group communication. Though of course RFC > 4605 type proxy may be deployed as part of the underlying IP multicast > infrastructure that CoAP group communication runs on. So, if you=20 > wanted us to just point to RFC 4605 as a background reference from=20 > section 2.1 then I am fine with that. Is that what you wanted? >=20 I just wanted to ensure that this approach did not preclude RFC 4605 in constrained networks/devices. An informative reference would be fine. > Please also note that the main proxy functionality that we need for=20 > group communication is described in section 2.10. But this is very=20 > specific to a CoAP proxy functionality and not RFC 4605 functionality. > I just wanted to draw your attention to that fact as we are discussing > proxies. >=20 >=20 Yes. >=20 >=20 >> 3. I am a little concerned with the SHOULD used in section 2.2 when > discussing nodes joining the All-CoAP-Nodes multicast address. What=20 > happens if a device does not join that group? Will the protocol break? >=20 > Response: > ------------- > The SHOULD was reflecting what was already there in the base CoAP spec > (RFC 7252) and CORE link format (RFC 6690). That is, CoAP devices are > strongly encouraged to join a multicast group so that they can be easily > discoverable by other CoAP nodes. (Please note that it is not a MUST > but a SHOULD). If the device decides not join then it simply will not > be discovered. Nothing will really break. >=20 Ok. I just wanted to make sure the lack of ability to discover a node would not break multicast distribution. > (Please note that there is a separate thread with Martin that is=20 > requesting clarification (from the AD) of whether we should have any=20 > normative language in an Informational document or whether this=20 > document should be Standards track or BCP instead ...) >=20 >=20 Yes, I am aware of that ongoing discussion. >=20 >=20 >> 4. Section 2.3 should allow a device to obtain the port number for=20 >> the > group from the URI schema referenced in section 2.2. >=20 > Response: > ------------- > Section 2.3 reference to ports is guidance for the listener as to=20 > which port it should be monitoring on to receive the IP multicast. So > I am unfortunately missing your point. Can you please expand on your=20 > thinking for me? >=20 Sure (since I worded my point very poorly). If I am a listener (called a server in 2.3), I need to select a port number. That port number needs to be available to the client devices. So, my concern is one of ensuring the clients select the correct destination port based on the port selected by the server for listening. In relation to 2.3, the server should be able to use the port number published in the URI described in section 2.2, right? >=20 >=20 >> 5. I see that the socket() API (RFC 3542) is referenced, but it is=20 >> not > discussed in terms of CoAP interacting with the group management=20 > protocols. Is it assumed that implementers know that they are to use=20 > that API to indicate changes in group membership state to IGMP/MLD? >=20 > Response: > ------------- > Our main reference to interaction between CoAP and the group=20 > management protocols is in the last paragraph of > http://tools.ietf.org/html/draft-ietf-core-groupcomm-21#section-2.7.2. > 1 (and then repeated in some of the following sections). Should we=20 > add the reference to RFC 3542 in that last paragraph (and=20 > corresponding following paragraphs)? I think this is a good idea but=20 > just want to double check with you. >=20 That would make things clearer. Thanks for the quick response! Regards, Brian From nobody Tue Aug 19 12:44:10 2014 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14DAF1A0AF6; Tue, 19 Aug 2014 12:44:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TnAC9Lp4vs5e; Tue, 19 Aug 2014 12:44:04 -0700 (PDT) Received: from uillean.fuaim.com (uillean.fuaim.com [206.197.161.140]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2F45D1A00C2; Tue, 19 Aug 2014 12:44:04 -0700 (PDT) Received: from clairseach.fuaim.com (clairseach-high.fuaim.com [206.197.161.158]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by uillean.fuaim.com (Postfix) with ESMTP id 097908811D; Tue, 19 Aug 2014 12:44:04 -0700 (PDT) Received: from 1025298212.rude2.ra.johnshopkins.edu (addr16212925014.ippl.jhmi.edu [162.129.250.14]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by clairseach.fuaim.com (Postfix) with ESMTP id 75A9271B0001; Tue, 19 Aug 2014 12:44:03 -0700 (PDT) Message-ID: <53F3A8FA.2040703@innovationslab.net> Date: Tue, 19 Aug 2014 15:43:54 -0400 From: Brian Haberman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "Rahman, Akbar" , The IESG References: <20140819144334.30860.77254.idtracker@ietfa.amsl.com> <53F381B0.1040307@innovationslab.net> In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="CdDclE6m7jFbEPm89nMErq3N76QshnIvW" Archived-At: http://mailarchive.ietf.org/arch/msg/core/GCwmdCY81zgFsyABhP_6N8I6H9E Cc: core-chairs@tools.ietf.org, draft-ietf-core-groupcomm@tools.ietf.org, core@ietf.org Subject: Re: [core] Brian Haberman's Discuss on draft-ietf-core-groupcomm-21: (with DISCUSS and COMMENT) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Aug 2014 19:44:06 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --CdDclE6m7jFbEPm89nMErq3N76QshnIvW Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Akbar, On 8/19/14 3:36 PM, Rahman, Akbar wrote: > Hi Brian, >=20 >=20 > Thanks for the responses. I will update the draft with all the points > below that we have closed on. For the one open question, below is my > response: >=20 >=20 >> If I am a listener (called a server in 2.3), I need to select a port > number. That port number needs to be available to the client devices. > So, my concern is one of ensuring the clients select the correct > destination port based on the port selected by the server for listening= =2E > In relation to 2.3, the server should be able to use the port number > published in the URI described in section 2.2, right? >=20 >=20 > Response: > ------------- > Yes, the server should be listening on the port number of the URI as > described in section 2.2. Please note that section 2.2 is describing > the general structure of the CoAP group URI, and also discussing the > case of when the URI is an FQDN and how to resolve it to an IP address > through DNS. If that is what you are referring to as "publishing" then= > we are in sync. >=20 I understand that 2.2 is just discussing the general structure of the CoAP group URI. I am wondering if the following change needs to be made in section 2.3 to utilize that URI from the server's perspective. Does this change make sense? OLD: 1. A pre-configured port number. 2. If the client is configured to use service discovery including port discovery, it uses a port number obtained via a service discovery lookup operation for the targeted CoAP group. 3. Use the default CoAP UDP port (5683). NEW: 1. A pre-configured port number. 2. If the client is configured to use service discovery including port discovery, it uses a port number obtained via a service discovery lookup operation for the targeted CoAP group. 3. The port number published in the corresponding CoAP group URI. 4. Use the default CoAP UDP port (5683). Regards, Brian --CdDclE6m7jFbEPm89nMErq3N76QshnIvW Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.20 (Darwin) Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJT86kAAAoJEBOZRqCi7goqlcoIAIeiFCc8rWFbUmHTYNWyxppC BvWItfTHeM/R00MWpmH+YRBYftezIRkwIDtrRr/DV7iy/iPX9I1WrxhMsPEHbQe+ r+vJAleavAepil5XppJJ7n9lBCVQyLMzkL7m6L6XbrDufIK6df/BAJ80DqdXODq3 P7ePHtZ8T5DFTZA+GQcz2Ra+UhWhBATvmoc1bIfDlWeZEnTrIbeUyMFVlSSu6IDe dQFpxaTHWKHXXVT8ycW71Ih9hkfZNdJlJ/JjQDu7h9Xhp2m3b+M1JmLFI15ysf7M GFQ1yUr9n8h4dJ/xOQGjKLE4eswqWpIXDdn/D+hRHECYa39GntZ1E6qdxfzsGXI= =90TV -----END PGP SIGNATURE----- --CdDclE6m7jFbEPm89nMErq3N76QshnIvW-- From nobody Tue Aug 19 14:04:13 2014 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3263C1A04C5 for ; Tue, 19 Aug 2014 14:04:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.568 X-Spam-Level: X-Spam-Status: No, score=-2.568 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.668] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hNvvOvKQpcad for ; Tue, 19 Aug 2014 14:04:09 -0700 (PDT) Received: from smtp-in1.interdigital.com (smtp-in1.interdigital.com [64.208.228.133]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 352A31A891A for ; Tue, 19 Aug 2014 14:04:08 -0700 (PDT) X-ASG-Debug-ID: 1408482246-06daaa39bb07ff0001-aa7cYp Received: from smtp-out1.interdigital.com (sahara.interdigital.com [10.0.128.27]) by smtp-in1.interdigital.com with ESMTP id PdRkASnjEqanDh1R; Tue, 19 Aug 2014 17:04:06 -0400 (EDT) X-Barracuda-Envelope-From: Akbar.Rahman@InterDigital.com Received: from SAM.InterDigital.com ([10.30.2.11]) by smtp-out1.interdigital.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 19 Aug 2014 17:04:04 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 19 Aug 2014 17:03:29 -0400 X-ASG-Orig-Subj: RE: [core] Brian Haberman's Discuss on draft-ietf-core-groupcomm-21: (with DISCUSS and COMMENT) Message-ID: In-Reply-To: <53F3A8FA.2040703@innovationslab.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [core] Brian Haberman's Discuss on draft-ietf-core-groupcomm-21: (with DISCUSS and COMMENT) Thread-Index: Ac+75e85WUJ8c9peTtymHTTZ0s1UcwACi8GA References: <20140819144334.30860.77254.idtracker@ietfa.amsl.com> <53F381B0.1040307@innovationslab.net> <53F3A8FA.2040703@innovationslab.net> From: "Rahman, Akbar" To: "Brian Haberman" , "The IESG" X-OriginalArrivalTime: 19 Aug 2014 21:04:04.0131 (UTC) FILETIME=[1B953730:01CFBBF1] X-Barracuda-Connect: sahara.interdigital.com[10.0.128.27] X-Barracuda-Start-Time: 1408482246 X-Barracuda-URL: http://10.1.245.3:8000/cgi-mod/mark.cgi X-Barracuda-BRTS-Status: 1 X-Virus-Scanned: by bsmtpd at interdigital.com X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=9.0 tests=BSF_SC0_MISMATCH_TO X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.8626 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 BSF_SC0_MISMATCH_TO Envelope rcpt doesn't match header Archived-At: http://mailarchive.ietf.org/arch/msg/core/Choa62hfqB8UQA5a4CTjkarpFTc Cc: core-chairs@tools.ietf.org, draft-ietf-core-groupcomm@tools.ietf.org, core@ietf.org Subject: Re: [core] Brian Haberman's Discuss on draft-ietf-core-groupcomm-21: (with DISCUSS and COMMENT) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Aug 2014 21:04:11 -0000 Hi Brian, =20 Okay. Now I understand your point. The thing is that the only real "publication" method would have been in the service discovery of item 2. So we could re-phrase item 2 to explicitly call this out as follows: OLD: 2. If the client is configured to use service discovery including port discovery, it uses a port number obtained via a service discovery lookup operation for the targeted CoAP group. NEW: 2. If the client is configured to use service discovery including URI and/or port discovery, it uses the port number obtained via the service discovery lookup operation for the targeted CoAP group. Does that address your question? /Akbar -----Original Message----- From: Brian Haberman [mailto:brian@innovationslab.net]=20 Sent: Tuesday, August 19, 2014 3:44 PM To: Rahman, Akbar; The IESG Cc: core-chairs@tools.ietf.org; draft-ietf-core-groupcomm@tools.ietf.org; core@ietf.org Subject: Re: [core] Brian Haberman's Discuss on draft-ietf-core-groupcomm-21: (with DISCUSS and COMMENT) Hi Akbar, On 8/19/14 3:36 PM, Rahman, Akbar wrote: > Hi Brian, >=20 >=20 > Thanks for the responses. I will update the draft with all the points > below that we have closed on. For the one open question, below is my > response: >=20 >=20 >> If I am a listener (called a server in 2.3), I need to select a port > number. That port number needs to be available to the client devices. > So, my concern is one of ensuring the clients select the correct=20 > destination port based on the port selected by the server for listening. > In relation to 2.3, the server should be able to use the port number=20 > published in the URI described in section 2.2, right? >=20 >=20 > Response: > ------------- > Yes, the server should be listening on the port number of the URI as=20 > described in section 2.2. Please note that section 2.2 is describing=20 > the general structure of the CoAP group URI, and also discussing the=20 > case of when the URI is an FQDN and how to resolve it to an IP address > through DNS. If that is what you are referring to as "publishing"=20 > then we are in sync. >=20 I understand that 2.2 is just discussing the general structure of the CoAP group URI. I am wondering if the following change needs to be made in section 2.3 to utilize that URI from the server's perspective. Does this change make sense? OLD: 1. A pre-configured port number. 2. If the client is configured to use service discovery including port discovery, it uses a port number obtained via a service discovery lookup operation for the targeted CoAP group. 3. Use the default CoAP UDP port (5683). NEW: 1. A pre-configured port number. 2. If the client is configured to use service discovery including port discovery, it uses a port number obtained via a service discovery lookup operation for the targeted CoAP group. 3. The port number published in the corresponding CoAP group URI. 4. Use the default CoAP UDP port (5683). Regards, Brian From nobody Tue Aug 19 14:44:41 2014 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 852F91A6F58; Tue, 19 Aug 2014 14:44:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.153 X-Spam-Level: X-Spam-Status: No, score=-0.153 tagged_above=-999 required=5 tests=[BAD_CREDIT=2.415, BAYES_00=-1.9, RP_MATCHES_RCVD=-0.668] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QrPZmnM6F-Gg; Tue, 19 Aug 2014 14:44:30 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C45C41A0012; Tue, 19 Aug 2014 14:44:30 -0700 (PDT) Received: from [10.0.1.23] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id s7JLiRSn046829 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 19 Aug 2014 16:44:28 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-173-172-146-58.tx.res.rr.com [173.172.146.58] claimed to be [10.0.1.23] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ben Campbell In-Reply-To: Date: Tue, 19 Aug 2014 16:44:26 -0500 X-Mao-Original-Outgoing-Id: 430177466.183369-42dce09289cab1530bd56a69a05fbee9 Content-Transfer-Encoding: quoted-printable Message-Id: <1AB489F7-A7AF-453F-93AF-98BBE1679891@nostrum.com> References: To: "Rahman, Akbar" X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/core/-0AraobaDQ14_tftkF0XyjL68u8 Cc: gen-art@ietf.org, draft-ietf-core-groupcomm.all@tools.ietf.org, core@ietf.org Subject: Re: [core] Gen-ART LC Review of draft-ietf-core-groupcomm-21 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Aug 2014 21:44:32 -0000 On Aug 14, 2014, at 5:12 PM, Rahman, Akbar = wrote: > Hi Ben, >=20 >=20 > Thank you for your thorough review. Here is my initial feedback on = the > two major issues that you raised: >=20 >=20 >> The draft contains significant material that I do not believe is > appropriate for an informational RFC, at least without some clear > explanations about why it appears. It purports to clarify the = normative > stuff in RFC 7252 concerning multicast, but it does quite a bit more > than that. Section 2.7 defines protocol ... >=20 > Response: > ------------- > The majority of the document is geared towards explaining how RESTful > group communications protocol should work based on the protocol > primitives defined in CoAP (RFC 7252). This was certainly the = original > intent of the document (i.e. expand and explain CoAP group > communications protocol processing defined in RFC 7252 but do not > introduce any new functionality). Then at a late(r) stage of > development of the document, the WG decided that we should also = include > some "management" aspects of CoAP group communications. This = resulted > in addition of Sections 2.6, 2.7, 3.6, 6.1, & 6.2. The offending = (new) > functionality is pretty clearly limited to these sections. >=20 > Therefore, I think we have two possible options to address your = comment: > 1) Remove Sections 2.6, 2.7 & 3.6 that focus on the management aspects > from the current document and spawn a new document (or potentially > migrate them to I-D.ietf-core-resource-directory if that makes sense). > 2) Change the status of the document from Informational to Standards > Track or BCP (and clearly indicate that the new functionality beyond = RFC > 7252 is introduced in Sections 2.6, 2.7, 3.6, 6.1, & 6.2). >=20 > Ben/Barry - Can you give us some guidance here? I think this is really up to you and Barry, but I think either approach = would be okay. Option 1 would allow you to treat different sections = differently, which might have some advantage. If you chose option 2, = Standards Track seems the better option as long as the new functionality = is included. >=20 >=20 >=20 >=20 >> The security aspects of group CoAP are pretty bad. To its credit, the > draft does a pretty good job of calling that out, and that work is in > progress to improve it. But I have to wonder if we would be better off > not encouraging multicast CoAP at all until such improvements are > available. >=20 > Response: > ------------- > Well, I think that we could definitely add stronger language > recommending not to use CoAP group communication until stronger = security > solutions are developed in IETF. However, as you noted, the fact is > that RFC 7252 already allows the current unsecured CoAP group > communications. So I don't really appreciate how this could be a > blocking issue on progression of this document. I agree that 7252 already has this issue. It also has some normative = language around not using it without some type of authentication, but = IIRC it doesn't say much about protection from eavesdroppers or privacy = issues.=20 I understood one of the purposes of this draft is to clarify the usage = of group CoAP. I think it's reasonable to expect such clarification to = include(normative or otherwise) guidance on how to use it safely. I = recognize that there is some guidance there already, but I think you = could take a stronger position on some aspects.=20 For example, you mention how the smart grid example may be high risk. It = would be helpful to also point out how it by nature cannot be secured by = the mitigation approaches mentioned in section 5, nor the minimal scope = recommendation in section 5.4. Therefore, perhaps group CoAP should not = be used for that application? >=20 >=20 >=20 > Looking forward to your response, >=20 >=20 > Akbar >=20 >=20 > -----Original Message----- > From: core [mailto:core-bounces@ietf.org] On Behalf Of Ben Campbell > Sent: Thursday, August 14, 2014 5:06 PM > To: draft-ietf-core-groupcomm.all@tools.ietf.org > Cc: gen-art@ietf.org Team (gen-art@ietf.org); core@ietf.org > Subject: [core] Gen-ART LC Review of draft-ietf-core-groupcomm-21 >=20 > (Oops, I screwed up the CC list the first try. Please send any replies > to this distribution. Apologies for the repeat.) >=20 > I am the assigned Gen-ART reviewer for this draft. For background on > Gen-ART, please see the FAQ at >=20 > . >=20 > Please resolve these comments along with any other Last Call comments > you may receive. >=20 > Document: draft-ietf-core-groupcomm-21 > Reviewer: Ben Campbell > Review Date: 2014-08-14 > IETF LC End Date: 2014-08-14 > IESG Telechat date:=20 >=20 > Summary: This draft is not ready for publication as an informational > RFC. It has some significant issues, detailed below. >=20 > **** Major issues: >=20 > -- The draft contains significant material that I do not believe is > appropriate for an informational RFC, at least without some clear > explanations about why it appears. It purports to clarify the = normative > stuff in RFC 7252 concerning multicast, but it does quite a bit more > than that. >=20 > Section 2.7 defines protocol, in the form of a RESTful methods and > attributes to manage multicast group membership.I agree in some cases = it > makes sense for an informational RFC to define protocol. A common > example is when we want to document a proprietary protocol for some > reason. As written, this does not seem to fall unto such a case. If = the > authors and working group believe it does, it would be helpful to add > text explaining that, and how the reader should interpret the section. > (I recognize that this interface is optional--but I don't think making > it optional changes whether it should be standards track.) >=20 > In addition to that, the draft contains quite a bit of guidance that > might be more appropriate BCP. For example, there is guidance here = where > not following it might do harm to the network. Additionally, I don't = see > how anyone could expect to achieve interoperability the multicast > features of RFC 7252 without understanding this draft. (I have to > wonder why RFC 7252 did not have a normative dependency on this = draft.) >=20 > -- The security aspects of group CoAP are pretty bad. To its credit, = the > draft does a pretty good job of calling that out, and that work is in > progress to improve it. But I have to wonder if we would be better off > not encouraging multicast CoAP at all until such improvements are > available. Section 5.3 calls out some reasonable examples of = mitigation > approaches, but I am a little concerned at the guidance that one = should > worry about these for "sensitive" or "safety-critical" data. People = are > not good at knowing what data is "sensitive" until it gets used = against > them. I think this is especially true for IoT applications where we = have > less deployment experience. >=20 > Along those lines, the Pervasive Monitoring Considerations section > (kudos for having one, btw), tries to balance application needs vs > protecting information. But the smart-grid example seems to be a case > where the two are really at odds. I am afraid people will interpret = this > along the lines of "well, the smart-grid application requirements = force > me to send unprotected data all over the place", when I think the = right > answer is "Group CoAP should not be used for this sort of application > until we can protect the data". >=20 >=20 >=20 >=20 > **** Minor issues: >=20 > -- 2.2, 5th paragraph: "For sending nodes, it is recommended to use = the > IP multicast address literal in a group URI." >=20 > Can you elaborate on why? I can guess, but anytime we suggest using > literal IP addresses rather than DNS names, it's worth elaborating. >=20 > -- 2.4: " ... if the resource being POSTed to has been designed to = cope > with the unreliable and lossy nature of IP multicast." >=20 > Can you elaborate on what it means to be "designed to cope..."? (Or > reference something that does?) >=20 > -- 2.6: >=20 > I think the Resource Directory reference needs to be normative. (I = see > the discussion of this from Barry's AD review, where the authors = argued > that the reference is optional for implementations. But our definition > of normative references also includes things necessary to fully > understand this draft. Fully understanding even optional features is > part of that.) >=20 > -- 2.7.1, 2nd paragraph: >=20 > Does this imply a need to coordinate pre-configured group addresses to > avoid collisions? >=20 > -- 2.7.2.1: 2nd 2 last paragraph: >=20 > Are there any scenarios where a missing port might be determined from > DNS, rather than just assuming the default? >=20 > -- 2.7.2.6, 1st paragraph: "This operation MUST only be used to delete > or update group membership objects for which the CoAP client, invoking > this operation, is responsible" >=20 > Do I understand correctly that this replaces the entire set? Is it > possible for two different clients to be responsible for two different > subsets? If so, how? >=20 > -- 2.8 and (especially) 2.9: >=20 > Lack of 2119 language in the "additional guidlines" seems inconsistent > with other parts of this draft that do use 2119 language. (I agree the > places where you talk about what 7252 already says should not use 2119 > language.) I can maybe see the difference for 2.8, but the > congestion-avoidance stuff in 2.9 seems as appropriate for 2119 = language > as most anything else in the draft. >=20 > (To be clear, I'm not suggesting more or less normative language--only > consistency in its use.) >=20 >=20 >=20 >=20 > **** Nits/editorial comments: >=20 > -- Abstract: >=20 > Please expand CoAP on first use in abstract. (But don't remove the > expansion in the body.) >=20 > -- 2.2, 4th paragraph: " ... it is recommended ..."=20 >=20 > Was that intended as normative?=20 >=20 > Along those lines, I see a number of sections where 2119 words are = used > in lower case where it looks like they were not intended as normative > (e.g., where you talk about normative requirements from RFC 7252), but > in other areas it's not as clear (like this one.) It would be best to > either avoid lower case versions of 2119 words, or make it very clear > whether they should be interpreted normatively or not. >=20 > -- 2.7.2, 2nd paragraph: >=20 > Wording is confusing. Do you mean MUST use the DTLS method, or MUST = use > some method, with DTLS an option? Sentence seems to mean the former, = in > which it would be more clear to say "MUST use DTLS as described in = ..." >=20 > -- 2.7.2.1, 3rd paragraph: >=20 > Please expand JDON on first use. >=20 > -- 2.7.2.1, paragraph after examples: >=20 > You mention an optional port for "a" attributes, but not for "n" > attributes. The BNF for group-name seems to allow an optional port. = (and > you mention an optional port for "n" later. >=20 >=20 >=20 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core From nobody Tue Aug 19 14:46:00 2014 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF71D1A6F59; Tue, 19 Aug 2014 14:45:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PBMhMqNBvxgP; Tue, 19 Aug 2014 14:45:54 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C2A301A0012; Tue, 19 Aug 2014 14:45:54 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Spencer Dawkins" To: The IESG X-Test-IDTracker: no X-IETF-IDTracker: 5.6.2.p5 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140819214554.19309.61511.idtracker@ietfa.amsl.com> Date: Tue, 19 Aug 2014 14:45:54 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/core/v5hJsJcvgElHcjIsM400RjECL8w Cc: core-chairs@tools.ietf.org, draft-ietf-core-groupcomm@tools.ietf.org, core@ietf.org Subject: [core] Spencer Dawkins' No Objection on draft-ietf-core-groupcomm-21: (with COMMENT) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Aug 2014 21:45:57 -0000 Spencer Dawkins has entered the following ballot position for draft-ietf-core-groupcomm-21: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-ietf-core-groupcomm/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I share the concerns Martin listed in his Discuss, but that conversation is already underway. I saw that Martin is questioning whether this document should be Informational, but 1.2. Scope While [RFC7252] supports various modes of DTLS based security for CoAP over unicast IP, it does not specify any security modes for CoAP over IP multicast. That is, [RFC7252] assumes that CoAP over IP multicast is not encrypted, nor authenticated, nor access controlled. This document assumes the same security model (see Section 5.1). However, there are several promising security solutions being developed that should be considered in the future for protecting CoAP group communications (see Section 5.3.3). would make me uneasy about publishing it as standards-track in 2014. If this specification was Experimental, I'd feel better, but as the specification itself correctly points out: 5.4. Pervasive Monitoring Considerations A key additional threat consideration for group communication is pointed to by [RFC7258] which warns of the dangers of pervasive monitoring. CoAP group communication which is built on top of IP multicast should pay particular heed to these dangers. This is because IP multicast is easier to intercept (e.g., and to secretly record) compared to unicast traffic. Also, CoAP traffic is meant for the Internet of Things. This means that CoAP traffic is often used for the control and monitoring of critical infrastructure (e.g., lights, alarms, etc.) which may be prime targets for attack. Approving it as a Proposed Standard seems to be begging for someone to deploy it without reading the warning labels ... would anyone who's planning to use CoAP group communications without security (beyond suggestions such as enabling WiFi security), be unwilling to use it at Experimental? In this text: 2.3. Port and URI Configuration A CoAP server that is a member of a group listens for CoAP messages on the group's IP multicast address, usually on the CoAP default UDP port, 5683. If the group uses a specified non-default UDP port, be careful to ensure that all group members are configured to use that same port. Therefore different ports for the same IP multicast address cannot be used to specify different CoAP groups. I'm probably missing something, but I'm not understanding this. If I have two groups of IoT devices configured to use the same IP multicast address, and each group uses its own UDP port, what doesn't work? From nobody Tue Aug 19 15:21:54 2014 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 109E11A6F6B for ; Tue, 19 Aug 2014 15:21:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.568 X-Spam-Level: X-Spam-Status: No, score=-2.568 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.668] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H_hsudUqzoMO for ; Tue, 19 Aug 2014 15:21:48 -0700 (PDT) Received: from smtp-in1.interdigital.com (smtp-in1.interdigital.com [64.208.228.133]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DF8CA1A06F4 for ; Tue, 19 Aug 2014 15:21:47 -0700 (PDT) X-ASG-Debug-ID: 1408486906-06daaa39ba08dd0001-aa7cYp Received: from smtp-out1.interdigital.com (sahara.interdigital.com [10.0.128.27]) by smtp-in1.interdigital.com with ESMTP id 9a0MhG6BKbjGlZoz; Tue, 19 Aug 2014 18:21:46 -0400 (EDT) X-Barracuda-Envelope-From: Akbar.Rahman@InterDigital.com Received: from SAM.InterDigital.com ([10.30.2.11]) by smtp-out1.interdigital.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 19 Aug 2014 18:21:44 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 19 Aug 2014 18:21:16 -0400 X-ASG-Orig-Subj: RE: [core] Spencer Dawkins' No Objection on draft-ietf-core-groupcomm-21: (with COMMENT) Message-ID: In-Reply-To: <20140819214554.19309.61511.idtracker@ietfa.amsl.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [core] Spencer Dawkins' No Objection on draft-ietf-core-groupcomm-21: (with COMMENT) Thread-Index: Ac+79vdsRisgxE3mSTS3EezdhDgvOwAA9DtA References: <20140819214554.19309.61511.idtracker@ietfa.amsl.com> From: "Rahman, Akbar" To: "Spencer Dawkins" , "The IESG" X-OriginalArrivalTime: 19 Aug 2014 22:21:44.0274 (UTC) FILETIME=[F53E9B20:01CFBBFB] X-Barracuda-Connect: sahara.interdigital.com[10.0.128.27] X-Barracuda-Start-Time: 1408486906 X-Barracuda-URL: http://10.1.245.3:8000/cgi-mod/mark.cgi X-Barracuda-BRTS-Status: 1 X-Virus-Scanned: by bsmtpd at interdigital.com X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=9.0 tests=BSF_SC0_MISMATCH_TO X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.8629 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 BSF_SC0_MISMATCH_TO Envelope rcpt doesn't match header Archived-At: http://mailarchive.ietf.org/arch/msg/core/ZmQcLVbvogz95_iUnv1sah_Xv4E Cc: core-chairs@tools.ietf.org, draft-ietf-core-groupcomm@tools.ietf.org, core@ietf.org Subject: Re: [core] Spencer Dawkins' No Objection on draft-ietf-core-groupcomm-21: (with COMMENT) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Aug 2014 22:21:50 -0000 Hi Spencer, Thanks for the good advice on the potential status for the document. I'll wait for our AD (Barry) to make the final decision on that issue. With regards to your final technical question: > I'm probably missing something, but I'm not understanding this. If I have two groups of IoT devices configured to use the same IP multicast address, and each group uses its own UDP port, what doesn't work? Response: ------------- Yes, you could technically do this. But it would be a very inefficient system as you would propagate multicast packets throughout the network and have them received and decoded in a device's IP stack only to throw it away at the last moment because it is on the wrong port. It would be much saner/efficient to have different IP multicast addresses to segregate the packets from the beginning instead of counting on different UDP ports. Best Regards, Akbar -----Original Message----- From: core [mailto:core-bounces@ietf.org] On Behalf Of Spencer Dawkins Sent: Tuesday, August 19, 2014 5:46 PM To: The IESG Cc: core-chairs@tools.ietf.org; draft-ietf-core-groupcomm@tools.ietf.org; core@ietf.org Subject: [core] Spencer Dawkins' No Objection on draft-ietf-core-groupcomm-21: (with COMMENT) Spencer Dawkins has entered the following ballot position for draft-ietf-core-groupcomm-21: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-ietf-core-groupcomm/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I share the concerns Martin listed in his Discuss, but that conversation is already underway.=20 I saw that Martin is questioning whether this document should be Informational, but=20 1.2. Scope While [RFC7252] supports various modes of DTLS based security for CoAP over unicast IP, it does not specify any security modes for CoAP over IP multicast. That is, [RFC7252] assumes that CoAP over IP multicast is not encrypted, nor authenticated, nor access controlled. This document assumes the same security model (see Section 5.1). However, there are several promising security solutions being developed that should be considered in the future for protecting CoAP group communications (see Section 5.3.3). would make me uneasy about publishing it as standards-track in 2014. If this specification was Experimental, I'd feel better, but as the specification itself correctly points out: 5.4. Pervasive Monitoring Considerations A key additional threat consideration for group communication is pointed to by [RFC7258] which warns of the dangers of pervasive monitoring. CoAP group communication which is built on top of IP multicast should pay particular heed to these dangers. This is because IP multicast is easier to intercept (e.g., and to secretly record) compared to unicast traffic. Also, CoAP traffic is meant for the Internet of Things. This means that CoAP traffic is often used for the control and monitoring of critical infrastructure (e.g., lights, alarms, etc.) which may be prime targets for attack. Approving it as a Proposed Standard seems to be begging for someone to deploy it without reading the warning labels ... would anyone who's planning to use CoAP group communications without security (beyond suggestions such as enabling WiFi security), be unwilling to use it at Experimental? In this text: 2.3. Port and URI Configuration A CoAP server that is a member of a group listens for CoAP messages on the group's IP multicast address, usually on the CoAP default UDP port, 5683. If the group uses a specified non-default UDP port, be careful to ensure that all group members are configured to use that same port. Therefore different ports for the same IP multicast address cannot be used to specify different CoAP groups. I'm probably missing something, but I'm not understanding this. If I have two groups of IoT devices configured to use the same IP multicast address, and each group uses its own UDP port, what doesn't work? _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core From nobody Tue Aug 19 15:57:25 2014 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33A2D1A6F7E; Tue, 19 Aug 2014 15:57:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hMlQ6ehPN4bv; Tue, 19 Aug 2014 15:57:15 -0700 (PDT) Received: from mail-la0-x233.google.com (mail-la0-x233.google.com [IPv6:2a00:1450:4010:c03::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B1AF91A6F2A; Tue, 19 Aug 2014 15:56:53 -0700 (PDT) Received: by mail-la0-f51.google.com with SMTP id pn19so6380761lab.24 for ; Tue, 19 Aug 2014 15:56:51 -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=+OCZnOrViBvFYQz3KiXc2v2Hg3A9zPT56BisVVZLcOw=; b=vEJGYGpqTnx2aQktTc0Qp8pD/t7MPhF5AVE/HDoKXLBIx26imiXyhYZorzV8d15w5Q oGl1g0lrYhMLwOgFdAUk+uGn1cprNnNvhArildlC099eYOP9BDQQdDcHzxpEq7CyYmrR XGxTxNXC04CW0NetS0vmAaSaBB8Rbpk4NPpf/sham/1IdLp8XROZJpaoTs+uLqKbMdP1 Pu7tEyxApTN46kvktinlfOqAaUZstPKWEXz2yb7JvNLdu87YDSNxTcii7Y/bCSqL5sJ1 6l7uLZbiAOQhI3nijbgoORPhUPifnbxY9LQb79RJamXTcCLB1wFPVdSCdAW5+v5sA+rz Au5A== MIME-Version: 1.0 X-Received: by 10.112.35.138 with SMTP id h10mr23255509lbj.65.1408489011776; Tue, 19 Aug 2014 15:56:51 -0700 (PDT) Received: by 10.152.206.36 with HTTP; Tue, 19 Aug 2014 15:56:51 -0700 (PDT) In-Reply-To: References: <20140819214554.19309.61511.idtracker@ietfa.amsl.com> Date: Tue, 19 Aug 2014 17:56:51 -0500 Message-ID: From: Spencer Dawkins at IETF To: "Rahman, Akbar" Content-Type: multipart/alternative; boundary=001a11c372bc37934605010367e4 Archived-At: http://mailarchive.ietf.org/arch/msg/core/qBeWmn5O1-xk41m4J4QQVuOi4sc Cc: "core-chairs@tools.ietf.org" , The IESG , "core@ietf.org" , "draft-ietf-core-groupcomm@tools.ietf.org" Subject: Re: [core] Spencer Dawkins' No Objection on draft-ietf-core-groupcomm-21: (with COMMENT) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Aug 2014 22:57:18 -0000 --001a11c372bc37934605010367e4 Content-Type: text/plain; charset=UTF-8 Thank you for the quick response! On Tuesday, August 19, 2014, Rahman, Akbar wrote: > Hi Spencer, > > > Thanks for the good advice on the potential status for the document. > I'll wait for our AD (Barry) to make the final decision on that issue. > With regards to your final technical question: > > > > I'm probably missing something, but I'm not understanding this. If I > have two groups of IoT devices configured to use the same IP multicast > address, and each group uses its own UDP port, what doesn't work? > > Response: > ------------- > Yes, you could technically do this. But it would be a very inefficient > system as you would propagate multicast packets throughout the network > and have them received and decoded in a device's IP stack only to throw > it away at the last moment because it is on the wrong port. It would be > much saner/efficient to have different IP multicast addresses to > segregate the packets from the beginning instead of counting on > different UDP ports. > This is up to you, but "cannot" doesn't mean "bad idea" to me :-) If I might make a suggestion, perhaps deleting the last sentence, and saying something like this in its own paragraph? "Because CoAP is often used with limited-power devices, it is RECOMMENDED that disjoint groups do not attempt to share IP multicast addresses, because all the devices using the same IP multicast address will see traffic for all groups, only to discard traffic intended for other groups based on UDP port." Or maybe multicast people all know that? But do the right thing! Spencer > Best Regards, > > > Akbar > > > > -----Original Message----- > From: core [mailto:core-bounces@ietf.org ] On Behalf Of > Spencer Dawkins > Sent: Tuesday, August 19, 2014 5:46 PM > To: The IESG > Cc: core-chairs@tools.ietf.org ; > draft-ietf-core-groupcomm@tools.ietf.org ; core@ietf.org > > Subject: [core] Spencer Dawkins' No Objection on > draft-ietf-core-groupcomm-21: (with COMMENT) > > Spencer Dawkins has entered the following ballot position for > draft-ietf-core-groupcomm-21: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > http://datatracker.ietf.org/doc/draft-ietf-core-groupcomm/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > I share the concerns Martin listed in his Discuss, but that conversation > is already underway. > > I saw that Martin is questioning whether this document should be > Informational, but > > 1.2. Scope > > While [RFC7252] supports various modes of DTLS based security for > CoAP over unicast IP, it does not specify any security modes for CoAP > over IP multicast. That is, [RFC7252] assumes that CoAP over IP > multicast is not encrypted, nor authenticated, nor access controlled. > This document assumes the same security model (see Section 5.1). > However, there are several promising security solutions being > developed that should be considered in the future for protecting CoAP > group communications (see Section 5.3.3). > > would make me uneasy about publishing it as standards-track in 2014. If > this specification was Experimental, I'd feel better, but as the > specification itself correctly points out: > > 5.4. Pervasive Monitoring Considerations > > A key additional threat consideration for group communication is > pointed to by [RFC7258] which warns of the dangers of pervasive > monitoring. CoAP group communication which is built on top of IP > multicast should pay particular heed to these dangers. This is > because IP multicast is easier to intercept (e.g., and to secretly > record) compared to unicast traffic. Also, CoAP traffic is meant for > the Internet of Things. This means that CoAP traffic is often used > for the control and monitoring of critical infrastructure (e.g., > lights, alarms, etc.) which may be prime targets for attack. > > Approving it as a Proposed Standard seems to be begging for someone to > deploy it without reading the warning labels ... would anyone who's > planning to use CoAP group communications without security (beyond > suggestions such as enabling WiFi security), be unwilling to use it at > Experimental? > > In this text: > > 2.3. Port and URI Configuration > > A CoAP server that is a member of a group listens for CoAP messages > on the group's IP multicast address, usually on the CoAP default UDP > port, 5683. If the group uses a specified non-default UDP port, be > careful to ensure that all group members are configured to use that > same port. Therefore different ports for the same IP multicast > address cannot be used to specify different CoAP groups. > > I'm probably missing something, but I'm not understanding this. If I > have two groups of IoT devices configured to use the same IP multicast > address, and each group uses its own UDP port, what doesn't work? > > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > --001a11c372bc37934605010367e4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Thank you for the quick response!

On Tuesday, August 19, 2014, Rahma= n, Akbar <Akbar.Rahman@= interdigital.com> wrote:
Hi Spencer,


Thanks for the good advice on the potential status for the document.
I'll wait for our AD (Barry) to make the final decision on that issue.<= br> With regards to your final technical question:


> I'm probably missing something, but I'm not understanding this= . If I
have two groups of IoT devices configured to use the same IP multicast
address, and each group uses its own UDP port, what doesn't work?

Response:
-------------
Yes, you could technically do this.=C2=A0 But it would be a very inefficien= t
system as you would propagate multicast packets throughout the network
and have them received and decoded in a device's IP stack only to throw=
it away at the last moment because it is on the wrong port.=C2=A0 It would = be
much saner/efficient to have different IP multicast addresses to
segregate the packets from the beginning instead of counting on
different UDP ports.

This is up to you,= but "cannot" doesn't mean "bad idea" to me :-)

If I might make a suggestion, perhaps deleting the la= st sentence, and saying something like=C2=A0this in its own paragraph?

"Because CoAP is=C2=A0often used with limited-powe= r devices, it is RECOMMENDED that=C2=A0disjoint groups do not attempt to sh= are IP multicast addresses, because=C2=A0all the devices using =C2=A0the sa= me IP multicast address will see traffic for all groups, only to discard tr= affic intended for other groups=C2=A0based on UDP port."

Or maybe multicast people all know that?

=
But do the right thing!

Spencer=C2=A0

=C2=A0
Best Regards,


Akbar



-----Original Message-----
From: core [mailto:core-bounces@ietf.org] On Behal= f Of Spencer Dawkins
Sent: Tuesday, August 19, 2014 5:46 PM
To: The IESG
Cc: core-chairs@tools.ietf.org;
draft-ietf-core-groupcomm@tools.iet= f.org; core@ietf.org
Subject: [core] Spencer Dawkins' No Objection on
draft-ietf-core-groupcomm-21: (with COMMENT)

Spencer Dawkins has entered the following ballot position for
draft-ietf-core-groupcomm-21: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to http://www.ietf.org/iesg/statement/discuss-crit= eria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
http://datatracker.ietf.org/doc/draft-ietf-core-groupcomm/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

I share the concerns Martin listed in his Discuss, but that conversation is already underway.

I saw that Martin is questioning whether this document should be
Informational, but

1.2.=C2=A0 Scope

=C2=A0 =C2=A0While [RFC7252] supports various modes of DTLS based security = for
=C2=A0 =C2=A0CoAP over unicast IP, it does not specify any security modes f= or CoAP
=C2=A0 =C2=A0over IP multicast.=C2=A0 That is, [RFC7252] assumes that CoAP = over IP
=C2=A0 =C2=A0multicast is not encrypted, nor authenticated, nor access cont= rolled.
=C2=A0 =C2=A0This document assumes the same security model (see Section 5.1= ).
=C2=A0 =C2=A0However, there are several promising security solutions being<= br> =C2=A0 =C2=A0developed that should be considered in the future for protecti= ng CoAP
=C2=A0 =C2=A0group communications (see Section 5.3.3).

would make me uneasy about publishing it as standards-track in 2014. If
this specification was Experimental, I'd feel better, but as the
specification itself correctly points out:

5.4.=C2=A0 Pervasive Monitoring Considerations

=C2=A0 =C2=A0A key additional threat consideration for group communication = is
=C2=A0 =C2=A0pointed to by [RFC7258] which warns of the dangers of pervasiv= e
=C2=A0 =C2=A0monitoring.=C2=A0 CoAP group communication which is built on t= op of IP
=C2=A0 =C2=A0multicast should pay particular heed to these dangers.=C2=A0 T= his is
=C2=A0 =C2=A0because IP multicast is easier to intercept (e.g., and to secr= etly
=C2=A0 =C2=A0record) compared to unicast traffic.=C2=A0 Also, CoAP traffic = is meant for
=C2=A0 =C2=A0the Internet of Things.=C2=A0 This means that CoAP traffic is = often used
=C2=A0 =C2=A0for the control and monitoring of critical infrastructure (e.g= .,
=C2=A0 =C2=A0lights, alarms, etc.) which may be prime targets for attack.
Approving it as a Proposed Standard seems to be begging for someone to
deploy it without reading the warning labels ... would anyone who's
planning to use CoAP group communications without security (beyond
suggestions such as enabling WiFi security), be unwilling to use it at
Experimental?

In this text:

2.3.=C2=A0 Port and URI Configuration

=C2=A0 =C2=A0A CoAP server that is a member of a group listens for CoAP mes= sages
=C2=A0 =C2=A0on the group's IP multicast address, usually on the CoAP d= efault UDP
=C2=A0 =C2=A0port, 5683.=C2=A0 If the group uses a specified non-default UD= P port, be
=C2=A0 =C2=A0careful to ensure that all group members are configured to use= that
=C2=A0 =C2=A0same port.=C2=A0 Therefore different ports for the same IP mul= ticast
=C2=A0 =C2=A0address cannot be used to specify different CoAP groups.

I'm probably missing something, but I'm not understanding this. If = I
have two groups of IoT devices configured to use the same IP multicast
address, and each group uses its own UDP port, what doesn't work?


_______________________________________________
core mailing list
core@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/core
--001a11c372bc37934605010367e4-- From nobody Tue Aug 19 16:12:11 2014 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96A831A6F9E; Tue, 19 Aug 2014 16:12:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 99Qrnp3F1pBQ; Tue, 19 Aug 2014 16:12:06 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id EEC861A6FA1; Tue, 19 Aug 2014 16:12:05 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Stephen Farrell" To: The IESG X-Test-IDTracker: no X-IETF-IDTracker: 5.6.2.p5 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140819231205.18772.65775.idtracker@ietfa.amsl.com> Date: Tue, 19 Aug 2014 16:12:05 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/core/dsnDxxkCBkK1BeLKFf5p9Aeujjg Cc: draft-ietf-core-observe@tools.ietf.org, core-chairs@tools.ietf.org, core@ietf.org Subject: [core] Stephen Farrell's No Objection on draft-ietf-core-observe-14: (with COMMENT) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Aug 2014 23:12:08 -0000 Stephen Farrell has entered the following ballot position for draft-ietf-core-observe-14: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-ietf-core-observe/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- - You probably won't want to but I'll ask anyway, just in case:-) The timing and sizes of notifications could expose sensitive information to a network attacker even if encrypted. TLS 1.3 is considering providing padding but TLS 1.2 and earlier don't really. HTTP/2.0 is also considering allowing padding. So should CoAP allow for padding in general, and if so, should this extension also? Or, is there a way to get the same result by sending out-of-date or other notifications that won't be accepted by the observer? If so, might it be worth documenting that? (However, it'd probably be better if both sides knew what was going on.) - I expected to see something about DTLS in section 7. Is there really nothing to be said about session lifetimes or expiry or keep-alives? Has anyone tried this protocol over DTLS in the interops? From nobody Tue Aug 19 17:51:29 2014 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B5F61A00EC for ; Tue, 19 Aug 2014 17:51:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.567 X-Spam-Level: X-Spam-Status: No, score=-2.567 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.668] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 36-LHF5wAMc6 for ; Tue, 19 Aug 2014 17:51:21 -0700 (PDT) Received: from smtp-in1.interdigital.com (smtp-in1.interdigital.com [64.208.228.133]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E31A71A00E1 for ; Tue, 19 Aug 2014 17:51:19 -0700 (PDT) X-ASG-Debug-ID: 1408495877-06daaa39b90a210001-aa7cYp Received: from smtp-out1.interdigital.com (sahara.interdigital.com [10.0.128.27]) by smtp-in1.interdigital.com with ESMTP id PprIN0AoSEB5pnXT; Tue, 19 Aug 2014 20:51:17 -0400 (EDT) X-Barracuda-Envelope-From: Akbar.Rahman@InterDigital.com Received: from SAM.InterDigital.com ([10.30.2.11]) by smtp-out1.interdigital.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 19 Aug 2014 20:51:15 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CFBC10.D8B3A651" Date: Tue, 19 Aug 2014 20:50:47 -0400 X-ASG-Orig-Subj: RE: Spencer Dawkins' No Objection on draft-ietf-core-groupcomm-21: (with COMMENT) Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Spencer Dawkins' No Objection on draft-ietf-core-groupcomm-21: (with COMMENT) Thread-Index: Ac+8AN8oRmGdVy7BTgWTbhRvL1/TPgADtaxw References: <20140819214554.19309.61511.idtracker@ietfa.amsl.com> From: "Rahman, Akbar" To: "Spencer Dawkins at IETF" X-OriginalArrivalTime: 20 Aug 2014 00:51:15.0816 (UTC) FILETIME=[D8B34680:01CFBC10] X-Barracuda-Connect: sahara.interdigital.com[10.0.128.27] X-Barracuda-Start-Time: 1408495877 X-Barracuda-URL: http://10.1.245.3:8000/cgi-mod/mark.cgi X-Barracuda-BRTS-Status: 1 X-Virus-Scanned: by bsmtpd at interdigital.com X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=9.0 tests=BSF_SC0_MISMATCH_TO, HTML_MESSAGE X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.8634 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 BSF_SC0_MISMATCH_TO Envelope rcpt doesn't match header 0.00 HTML_MESSAGE BODY: HTML included in message Archived-At: http://mailarchive.ietf.org/arch/msg/core/zHvocyOprZqsN1u5GFrxpbUgz5g Cc: core-chairs@tools.ietf.org, The IESG , core@ietf.org, draft-ietf-core-groupcomm@tools.ietf.org Subject: Re: [core] Spencer Dawkins' No Objection on draft-ietf-core-groupcomm-21: (with COMMENT) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Aug 2014 00:51:23 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CFBC10.D8B3A651 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 SGkgU3BlbmNlciwNCg0KIA0KDQogDQoNCj5JZiBJIG1pZ2h0IG1ha2UgYSBzdWdnZXN0aW9uLCBw ZXJoYXBzIGRlbGV0aW5nIHRoZSBsYXN0IHNlbnRlbmNlLCBhbmQgc2F5aW5nIHNvbWV0aGluZyBs aWtlIHRoaXMgaW4gaXRzIG93biBwYXJhZ3JhcGg/DQoNCiANCg0KPiJCZWNhdXNlIENvQVAgaXMg b2Z0ZW4gdXNlZCB3aXRoIGxpbWl0ZWQtcG93ZXIgZGV2aWNlcywgaXQgaXMgUkVDT01NRU5ERUQg dGhhdCBkaXNqb2ludCBncm91cHMgZG8gbm90IGF0dGVtcHQgdG8gc2hhcmUgSVAgbXVsdGljYXN0 IGFkZHJlc3NlcywgYmVjYXVzZSBhbGwgdGhlIGRldmljZXMgdXNpbmcgIHRoZSBzYW1lIElQIG11 bHRpY2FzdCBhZGRyZXNzIHdpbGwgc2VlIHRyYWZmaWMgZm9yIGFsbCBncm91cHMsIG9ubHkgdG8g ZGlzY2FyZCB0cmFmZmljIGludGVuZGVkIGZvciBvdGhlciBncm91cHMgYmFzZWQgb24gVURQIHBv cnQuIg0KDQogDQoNCiANCg0KUmVzcG9uc2U6DQoNCi0tLS0tLS0tLS0tLS0NCg0KT2theS4gIEdv b2Qgc3VnZ2VzdGlvbi4gIFdlIHdpbGwgYWRkIGl0IGluIHRoYXQgc2VjdGlvbi4gIChQbGVhc2Ug bGVhdmUgdXMgZWRpdG9yaWFsIGxpY2Vuc2UgdG8gbW9kaWZ5IHRoZSB3b3JkaW5nIHNsaWdodGx5 IGRlcGVuZGluZyBvbiB3aGF0IGhhcHBlbnMgb24gdGhlIG90aGVyIGRpc2N1c3Npb24gcmVnYXJk aW5nIHVzZSBvZiBOb3JtYXRpdmUgbGFuZ3VhZ2UgaW4gdGhlIGRyYWZ0KS4NCg0KIA0KDQogDQoN CkJlc3QgUmVnYXJkcywNCg0KIA0KDQogDQoNCkFrYmFyDQoNCiANCg0KIA0KDQpGcm9tOiBTcGVu Y2VyIERhd2tpbnMgYXQgSUVURiBbbWFpbHRvOnNwZW5jZXJkYXdraW5zLmlldGZAZ21haWwuY29t XSANClNlbnQ6IFR1ZXNkYXksIEF1Z3VzdCAxOSwgMjAxNCA2OjU3IFBNDQpUbzogUmFobWFuLCBB a2Jhcg0KQ2M6IFRoZSBJRVNHOyBjb3JlLWNoYWlyc0B0b29scy5pZXRmLm9yZzsgZHJhZnQtaWV0 Zi1jb3JlLWdyb3VwY29tbUB0b29scy5pZXRmLm9yZzsgY29yZUBpZXRmLm9yZw0KU3ViamVjdDog UmU6IFNwZW5jZXIgRGF3a2lucycgTm8gT2JqZWN0aW9uIG9uIGRyYWZ0LWlldGYtY29yZS1ncm91 cGNvbW0tMjE6ICh3aXRoIENPTU1FTlQpDQoNCiANCg0KVGhhbmsgeW91IGZvciB0aGUgcXVpY2sg cmVzcG9uc2UhDQoNCk9uIFR1ZXNkYXksIEF1Z3VzdCAxOSwgMjAxNCwgUmFobWFuLCBBa2JhciA8 QWtiYXIuUmFobWFuQGludGVyZGlnaXRhbC5jb20+IHdyb3RlOg0KDQpIaSBTcGVuY2VyLA0KDQoN ClRoYW5rcyBmb3IgdGhlIGdvb2QgYWR2aWNlIG9uIHRoZSBwb3RlbnRpYWwgc3RhdHVzIGZvciB0 aGUgZG9jdW1lbnQuDQpJJ2xsIHdhaXQgZm9yIG91ciBBRCAoQmFycnkpIHRvIG1ha2UgdGhlIGZp bmFsIGRlY2lzaW9uIG9uIHRoYXQgaXNzdWUuDQpXaXRoIHJlZ2FyZHMgdG8geW91ciBmaW5hbCB0 ZWNobmljYWwgcXVlc3Rpb246DQoNCg0KPiBJJ20gcHJvYmFibHkgbWlzc2luZyBzb21ldGhpbmcs IGJ1dCBJJ20gbm90IHVuZGVyc3RhbmRpbmcgdGhpcy4gSWYgSQ0KaGF2ZSB0d28gZ3JvdXBzIG9m IElvVCBkZXZpY2VzIGNvbmZpZ3VyZWQgdG8gdXNlIHRoZSBzYW1lIElQIG11bHRpY2FzdA0KYWRk cmVzcywgYW5kIGVhY2ggZ3JvdXAgdXNlcyBpdHMgb3duIFVEUCBwb3J0LCB3aGF0IGRvZXNuJ3Qg d29yaz8NCg0KUmVzcG9uc2U6DQotLS0tLS0tLS0tLS0tDQpZZXMsIHlvdSBjb3VsZCB0ZWNobmlj YWxseSBkbyB0aGlzLiAgQnV0IGl0IHdvdWxkIGJlIGEgdmVyeSBpbmVmZmljaWVudA0Kc3lzdGVt IGFzIHlvdSB3b3VsZCBwcm9wYWdhdGUgbXVsdGljYXN0IHBhY2tldHMgdGhyb3VnaG91dCB0aGUg bmV0d29yaw0KYW5kIGhhdmUgdGhlbSByZWNlaXZlZCBhbmQgZGVjb2RlZCBpbiBhIGRldmljZSdz IElQIHN0YWNrIG9ubHkgdG8gdGhyb3cNCml0IGF3YXkgYXQgdGhlIGxhc3QgbW9tZW50IGJlY2F1 c2UgaXQgaXMgb24gdGhlIHdyb25nIHBvcnQuICBJdCB3b3VsZCBiZQ0KbXVjaCBzYW5lci9lZmZp Y2llbnQgdG8gaGF2ZSBkaWZmZXJlbnQgSVAgbXVsdGljYXN0IGFkZHJlc3NlcyB0bw0Kc2VncmVn YXRlIHRoZSBwYWNrZXRzIGZyb20gdGhlIGJlZ2lubmluZyBpbnN0ZWFkIG9mIGNvdW50aW5nIG9u DQpkaWZmZXJlbnQgVURQIHBvcnRzLg0KDQogDQoNClRoaXMgaXMgdXAgdG8geW91LCBidXQgImNh bm5vdCIgZG9lc24ndCBtZWFuICJiYWQgaWRlYSIgdG8gbWUgOi0pDQoNCiANCg0KSWYgSSBtaWdo dCBtYWtlIGEgc3VnZ2VzdGlvbiwgcGVyaGFwcyBkZWxldGluZyB0aGUgbGFzdCBzZW50ZW5jZSwg YW5kIHNheWluZyBzb21ldGhpbmcgbGlrZSB0aGlzIGluIGl0cyBvd24gcGFyYWdyYXBoPw0KDQog DQoNCiJCZWNhdXNlIENvQVAgaXMgb2Z0ZW4gdXNlZCB3aXRoIGxpbWl0ZWQtcG93ZXIgZGV2aWNl cywgaXQgaXMgUkVDT01NRU5ERUQgdGhhdCBkaXNqb2ludCBncm91cHMgZG8gbm90IGF0dGVtcHQg dG8gc2hhcmUgSVAgbXVsdGljYXN0IGFkZHJlc3NlcywgYmVjYXVzZSBhbGwgdGhlIGRldmljZXMg dXNpbmcgIHRoZSBzYW1lIElQIG11bHRpY2FzdCBhZGRyZXNzIHdpbGwgc2VlIHRyYWZmaWMgZm9y IGFsbCBncm91cHMsIG9ubHkgdG8gZGlzY2FyZCB0cmFmZmljIGludGVuZGVkIGZvciBvdGhlciBn cm91cHMgYmFzZWQgb24gVURQIHBvcnQuIg0KDQogDQoNCk9yIG1heWJlIG11bHRpY2FzdCBwZW9w bGUgYWxsIGtub3cgdGhhdD8NCg0KIA0KDQpCdXQgZG8gdGhlIHJpZ2h0IHRoaW5nIQ0KDQogDQoN ClNwZW5jZXIgDQoNCiANCg0KIA0KDQoJQmVzdCBSZWdhcmRzLA0KCQ0KCQ0KCUFrYmFyDQoJDQoJ DQoJDQoJLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCglGcm9tOiBjb3JlIFttYWlsdG86Y29y ZS1ib3VuY2VzQGlldGYub3JnIDxqYXZhc2NyaXB0Ojs+IF0gT24gQmVoYWxmIE9mIFNwZW5jZXIg RGF3a2lucw0KCVNlbnQ6IFR1ZXNkYXksIEF1Z3VzdCAxOSwgMjAxNCA1OjQ2IFBNDQoJVG86IFRo ZSBJRVNHDQoJQ2M6IGNvcmUtY2hhaXJzQHRvb2xzLmlldGYub3JnIDxqYXZhc2NyaXB0Ojs+IDsN CglkcmFmdC1pZXRmLWNvcmUtZ3JvdXBjb21tQHRvb2xzLmlldGYub3JnIDxqYXZhc2NyaXB0Ojs+ IDsgY29yZUBpZXRmLm9yZyA8amF2YXNjcmlwdDo7PiANCglTdWJqZWN0OiBbY29yZV0gU3BlbmNl ciBEYXdraW5zJyBObyBPYmplY3Rpb24gb24NCglkcmFmdC1pZXRmLWNvcmUtZ3JvdXBjb21tLTIx OiAod2l0aCBDT01NRU5UKQ0KCQ0KCVNwZW5jZXIgRGF3a2lucyBoYXMgZW50ZXJlZCB0aGUgZm9s bG93aW5nIGJhbGxvdCBwb3NpdGlvbiBmb3INCglkcmFmdC1pZXRmLWNvcmUtZ3JvdXBjb21tLTIx OiBObyBPYmplY3Rpb24NCgkNCglXaGVuIHJlc3BvbmRpbmcsIHBsZWFzZSBrZWVwIHRoZSBzdWJq ZWN0IGxpbmUgaW50YWN0IGFuZCByZXBseSB0byBhbGwNCgllbWFpbCBhZGRyZXNzZXMgaW5jbHVk ZWQgaW4gdGhlIFRvIGFuZCBDQyBsaW5lcy4gKEZlZWwgZnJlZSB0byBjdXQgdGhpcw0KCWludHJv ZHVjdG9yeSBwYXJhZ3JhcGgsIGhvd2V2ZXIuKQ0KCQ0KCQ0KCVBsZWFzZSByZWZlciB0byBodHRw Oi8vd3d3LmlldGYub3JnL2llc2cvc3RhdGVtZW50L2Rpc2N1c3MtY3JpdGVyaWEuaHRtbA0KCWZv ciBtb3JlIGluZm9ybWF0aW9uIGFib3V0IElFU0cgRElTQ1VTUyBhbmQgQ09NTUVOVCBwb3NpdGlv bnMuDQoJDQoJDQoJVGhlIGRvY3VtZW50LCBhbG9uZyB3aXRoIG90aGVyIGJhbGxvdCBwb3NpdGlv bnMsIGNhbiBiZSBmb3VuZCBoZXJlOg0KCWh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2Mv ZHJhZnQtaWV0Zi1jb3JlLWdyb3VwY29tbS8NCgkNCgkNCgkNCgktLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoJQ09N TUVOVDoNCgktLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoJDQoJSSBzaGFyZSB0aGUgY29uY2VybnMgTWFydGluIGxp c3RlZCBpbiBoaXMgRGlzY3VzcywgYnV0IHRoYXQgY29udmVyc2F0aW9uDQoJaXMgYWxyZWFkeSB1 bmRlcndheS4NCgkNCglJIHNhdyB0aGF0IE1hcnRpbiBpcyBxdWVzdGlvbmluZyB3aGV0aGVyIHRo aXMgZG9jdW1lbnQgc2hvdWxkIGJlDQoJSW5mb3JtYXRpb25hbCwgYnV0DQoJDQoJMS4yLiAgU2Nv cGUNCgkNCgkgICBXaGlsZSBbUkZDNzI1Ml0gc3VwcG9ydHMgdmFyaW91cyBtb2RlcyBvZiBEVExT IGJhc2VkIHNlY3VyaXR5IGZvcg0KCSAgIENvQVAgb3ZlciB1bmljYXN0IElQLCBpdCBkb2VzIG5v dCBzcGVjaWZ5IGFueSBzZWN1cml0eSBtb2RlcyBmb3IgQ29BUA0KCSAgIG92ZXIgSVAgbXVsdGlj YXN0LiAgVGhhdCBpcywgW1JGQzcyNTJdIGFzc3VtZXMgdGhhdCBDb0FQIG92ZXIgSVANCgkgICBt dWx0aWNhc3QgaXMgbm90IGVuY3J5cHRlZCwgbm9yIGF1dGhlbnRpY2F0ZWQsIG5vciBhY2Nlc3Mg Y29udHJvbGxlZC4NCgkgICBUaGlzIGRvY3VtZW50IGFzc3VtZXMgdGhlIHNhbWUgc2VjdXJpdHkg bW9kZWwgKHNlZSBTZWN0aW9uIDUuMSkuDQoJICAgSG93ZXZlciwgdGhlcmUgYXJlIHNldmVyYWwg cHJvbWlzaW5nIHNlY3VyaXR5IHNvbHV0aW9ucyBiZWluZw0KCSAgIGRldmVsb3BlZCB0aGF0IHNo b3VsZCBiZSBjb25zaWRlcmVkIGluIHRoZSBmdXR1cmUgZm9yIHByb3RlY3RpbmcgQ29BUA0KCSAg IGdyb3VwIGNvbW11bmljYXRpb25zIChzZWUgU2VjdGlvbiA1LjMuMykuDQoJDQoJd291bGQgbWFr ZSBtZSB1bmVhc3kgYWJvdXQgcHVibGlzaGluZyBpdCBhcyBzdGFuZGFyZHMtdHJhY2sgaW4gMjAx NC4gSWYNCgl0aGlzIHNwZWNpZmljYXRpb24gd2FzIEV4cGVyaW1lbnRhbCwgSSdkIGZlZWwgYmV0 dGVyLCBidXQgYXMgdGhlDQoJc3BlY2lmaWNhdGlvbiBpdHNlbGYgY29ycmVjdGx5IHBvaW50cyBv dXQ6DQoJDQoJNS40LiAgUGVydmFzaXZlIE1vbml0b3JpbmcgQ29uc2lkZXJhdGlvbnMNCgkNCgkg ICBBIGtleSBhZGRpdGlvbmFsIHRocmVhdCBjb25zaWRlcmF0aW9uIGZvciBncm91cCBjb21tdW5p Y2F0aW9uIGlzDQoJICAgcG9pbnRlZCB0byBieSBbUkZDNzI1OF0gd2hpY2ggd2FybnMgb2YgdGhl IGRhbmdlcnMgb2YgcGVydmFzaXZlDQoJICAgbW9uaXRvcmluZy4gIENvQVAgZ3JvdXAgY29tbXVu aWNhdGlvbiB3aGljaCBpcyBidWlsdCBvbiB0b3Agb2YgSVANCgkgICBtdWx0aWNhc3Qgc2hvdWxk IHBheSBwYXJ0aWN1bGFyIGhlZWQgdG8gdGhlc2UgZGFuZ2Vycy4gIFRoaXMgaXMNCgkgICBiZWNh dXNlIElQIG11bHRpY2FzdCBpcyBlYXNpZXIgdG8gaW50ZXJjZXB0IChlLmcuLCBhbmQgdG8gc2Vj cmV0bHkNCgkgICByZWNvcmQpIGNvbXBhcmVkIHRvIHVuaWNhc3QgdHJhZmZpYy4gIEFsc28sIENv QVAgdHJhZmZpYyBpcyBtZWFudCBmb3INCgkgICB0aGUgSW50ZXJuZXQgb2YgVGhpbmdzLiAgVGhp cyBtZWFucyB0aGF0IENvQVAgdHJhZmZpYyBpcyBvZnRlbiB1c2VkDQoJICAgZm9yIHRoZSBjb250 cm9sIGFuZCBtb25pdG9yaW5nIG9mIGNyaXRpY2FsIGluZnJhc3RydWN0dXJlIChlLmcuLA0KCSAg IGxpZ2h0cywgYWxhcm1zLCBldGMuKSB3aGljaCBtYXkgYmUgcHJpbWUgdGFyZ2V0cyBmb3IgYXR0 YWNrLg0KCQ0KCUFwcHJvdmluZyBpdCBhcyBhIFByb3Bvc2VkIFN0YW5kYXJkIHNlZW1zIHRvIGJl IGJlZ2dpbmcgZm9yIHNvbWVvbmUgdG8NCglkZXBsb3kgaXQgd2l0aG91dCByZWFkaW5nIHRoZSB3 YXJuaW5nIGxhYmVscyAuLi4gd291bGQgYW55b25lIHdobydzDQoJcGxhbm5pbmcgdG8gdXNlIENv QVAgZ3JvdXAgY29tbXVuaWNhdGlvbnMgd2l0aG91dCBzZWN1cml0eSAoYmV5b25kDQoJc3VnZ2Vz dGlvbnMgc3VjaCBhcyBlbmFibGluZyBXaUZpIHNlY3VyaXR5KSwgYmUgdW53aWxsaW5nIHRvIHVz ZSBpdCBhdA0KCUV4cGVyaW1lbnRhbD8NCgkNCglJbiB0aGlzIHRleHQ6DQoJDQoJMi4zLiAgUG9y dCBhbmQgVVJJIENvbmZpZ3VyYXRpb24NCgkNCgkgICBBIENvQVAgc2VydmVyIHRoYXQgaXMgYSBt ZW1iZXIgb2YgYSBncm91cCBsaXN0ZW5zIGZvciBDb0FQIG1lc3NhZ2VzDQoJICAgb24gdGhlIGdy b3VwJ3MgSVAgbXVsdGljYXN0IGFkZHJlc3MsIHVzdWFsbHkgb24gdGhlIENvQVAgZGVmYXVsdCBV RFANCgkgICBwb3J0LCA1NjgzLiAgSWYgdGhlIGdyb3VwIHVzZXMgYSBzcGVjaWZpZWQgbm9uLWRl ZmF1bHQgVURQIHBvcnQsIGJlDQoJICAgY2FyZWZ1bCB0byBlbnN1cmUgdGhhdCBhbGwgZ3JvdXAg bWVtYmVycyBhcmUgY29uZmlndXJlZCB0byB1c2UgdGhhdA0KCSAgIHNhbWUgcG9ydC4gIFRoZXJl Zm9yZSBkaWZmZXJlbnQgcG9ydHMgZm9yIHRoZSBzYW1lIElQIG11bHRpY2FzdA0KCSAgIGFkZHJl c3MgY2Fubm90IGJlIHVzZWQgdG8gc3BlY2lmeSBkaWZmZXJlbnQgQ29BUCBncm91cHMuDQoJDQoJ SSdtIHByb2JhYmx5IG1pc3Npbmcgc29tZXRoaW5nLCBidXQgSSdtIG5vdCB1bmRlcnN0YW5kaW5n IHRoaXMuIElmIEkNCgloYXZlIHR3byBncm91cHMgb2YgSW9UIGRldmljZXMgY29uZmlndXJlZCB0 byB1c2UgdGhlIHNhbWUgSVAgbXVsdGljYXN0DQoJYWRkcmVzcywgYW5kIGVhY2ggZ3JvdXAgdXNl cyBpdHMgb3duIFVEUCBwb3J0LCB3aGF0IGRvZXNuJ3Qgd29yaz8NCgkNCgkNCglfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KCWNvcmUgbWFpbGluZyBsaXN0 DQoJY29yZUBpZXRmLm9yZyA8amF2YXNjcmlwdDo7PiANCglodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL2NvcmUNCg0K ------_=_NextPart_001_01CFBC10.D8B3A651 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij48bWV0YSBuYW1lPUdlbmVyYXRvciBjb250ZW50 PSJNaWNyb3NvZnQgV29yZCAxNCAoZmlsdGVyZWQgbWVkaXVtKSI+PHN0eWxlPjwhLS0NCi8qIEZv bnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglw YW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5 OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQovKiBTdHlsZSBEZWZp bml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXtt YXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1z b0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0 LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xs b3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVj b3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29BY2V0YXRlLCBsaS5Nc29BY2V0YXRlLCBkaXYuTXNv QWNldGF0ZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkJhbGxv b24gVGV4dCBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglm b250LXNpemU6OC4wcHQ7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiO30NCnNw YW4uQmFsbG9vblRleHRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJCYWxsb29uIFRleHQgQ2hhciI7 DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQi Ow0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQpzcGFuLkVtYWlsU3R5bGUx OQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJy aSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNv LXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNl cmlmIjt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2lu OjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3Jk U2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBl ZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0t LT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4N CjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1s PjwhW2VuZGlmXS0tPjwvaGVhZD48Ym9keSBsYW5nPUVOLVVTIGxpbms9Ymx1ZSB2bGluaz1wdXJw bGU+PGRpdiBjbGFzcz1Xb3JkU2VjdGlvbjE+PHAgY2xhc3M9TXNvTm9ybWFsPkhpIFNwZW5jZXIs PG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPjxw IGNsYXNzPU1zb05vcm1hbD48bzpwPiZuYnNwOzwvbzpwPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+ Jmd0O0lmIEkgbWlnaHQgbWFrZSBhIHN1Z2dlc3Rpb24sIHBlcmhhcHMgZGVsZXRpbmcgdGhlIGxh c3Qgc2VudGVuY2UsIGFuZCBzYXlpbmcgc29tZXRoaW5nIGxpa2UmbmJzcDt0aGlzIGluIGl0cyBv d24gcGFyYWdyYXBoPzxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48bzpwPiZuYnNw OzwvbzpwPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+Jmd0OyZxdW90O0JlY2F1c2UgQ29BUCBpcyZu YnNwO29mdGVuIHVzZWQgd2l0aCBsaW1pdGVkLXBvd2VyIGRldmljZXMsIGl0IGlzIFJFQ09NTUVO REVEIHRoYXQmbmJzcDtkaXNqb2ludCBncm91cHMgZG8gbm90IGF0dGVtcHQgdG8gc2hhcmUgSVAg bXVsdGljYXN0IGFkZHJlc3NlcywgYmVjYXVzZSZuYnNwO2FsbCB0aGUgZGV2aWNlcyB1c2luZyAm bmJzcDt0aGUgc2FtZSBJUCBtdWx0aWNhc3QgYWRkcmVzcyB3aWxsIHNlZSB0cmFmZmljIGZvciBh bGwgZ3JvdXBzLCBvbmx5IHRvIGRpc2NhcmQgdHJhZmZpYyBpbnRlbmRlZCBmb3Igb3RoZXIgZ3Jv dXBzJm5ic3A7YmFzZWQgb24gVURQIHBvcnQuJnF1b3Q7PG86cD48L286cD48L3A+PHAgY2xhc3M9 TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxp YnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdE Jz5SZXNwb25zZTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFu IHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJp ZiI7Y29sb3I6IzFGNDk3RCc+LS0tLS0tLS0tLS0tLTxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBj bGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz5Pa2F5LsKgIEdvb2Qgc3VnZ2Vz dGlvbi7CoCBXZSB3aWxsIGFkZCBpdCBpbiB0aGF0IHNlY3Rpb24uwqAgKFBsZWFzZSBsZWF2ZSB1 cyBlZGl0b3JpYWwgbGljZW5zZSB0byBtb2RpZnkgdGhlIHdvcmRpbmcgc2xpZ2h0bHkgZGVwZW5k aW5nIG9uIHdoYXQgaGFwcGVucyBvbiB0aGUgb3RoZXIgZGlzY3Vzc2lvbiByZWdhcmRpbmcgdXNl IG9mIE5vcm1hdGl2ZSBsYW5ndWFnZSBpbiB0aGUgZHJhZnQpLjxvOnA+PC9vOnA+PC9zcGFuPjwv cD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHls ZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2Nv bG9yOiMxRjQ5N0QnPkJlc3QgUmVnYXJkcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9 TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxp YnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdE Jz5Ba2JhcjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5 bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtj b2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9y bWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwi c2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxw IGNsYXNzPU1zb05vcm1hbD48Yj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseToiVGFob21hIiwic2Fucy1zZXJpZiInPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0n Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiInPiBTcGVu Y2VyIERhd2tpbnMgYXQgSUVURiBbbWFpbHRvOnNwZW5jZXJkYXdraW5zLmlldGZAZ21haWwuY29t XSA8YnI+PGI+U2VudDo8L2I+IFR1ZXNkYXksIEF1Z3VzdCAxOSwgMjAxNCA2OjU3IFBNPGJyPjxi PlRvOjwvYj4gUmFobWFuLCBBa2Jhcjxicj48Yj5DYzo8L2I+IFRoZSBJRVNHOyBjb3JlLWNoYWly c0B0b29scy5pZXRmLm9yZzsgZHJhZnQtaWV0Zi1jb3JlLWdyb3VwY29tbUB0b29scy5pZXRmLm9y ZzsgY29yZUBpZXRmLm9yZzxicj48Yj5TdWJqZWN0OjwvYj4gUmU6IFNwZW5jZXIgRGF3a2lucycg Tm8gT2JqZWN0aW9uIG9uIGRyYWZ0LWlldGYtY29yZS1ncm91cGNvbW0tMjE6ICh3aXRoIENPTU1F TlQpPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48bzpwPiZuYnNwOzwv bzpwPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+VGhhbmsgeW91IGZvciB0aGUgcXVpY2sgcmVzcG9u c2UhPGJyPjxicj5PbiBUdWVzZGF5LCBBdWd1c3QgMTksIDIwMTQsIFJhaG1hbiwgQWtiYXIgJmx0 OzxhIGhyZWY9Im1haWx0bzpBa2Jhci5SYWhtYW5AaW50ZXJkaWdpdGFsLmNvbSI+QWtiYXIuUmFo bWFuQGludGVyZGlnaXRhbC5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD48cCBjbGFz cz1Nc29Ob3JtYWw+SGkgU3BlbmNlciw8YnI+PGJyPjxicj5UaGFua3MgZm9yIHRoZSBnb29kIGFk dmljZSBvbiB0aGUgcG90ZW50aWFsIHN0YXR1cyBmb3IgdGhlIGRvY3VtZW50Ljxicj5JJ2xsIHdh aXQgZm9yIG91ciBBRCAoQmFycnkpIHRvIG1ha2UgdGhlIGZpbmFsIGRlY2lzaW9uIG9uIHRoYXQg aXNzdWUuPGJyPldpdGggcmVnYXJkcyB0byB5b3VyIGZpbmFsIHRlY2huaWNhbCBxdWVzdGlvbjo8 YnI+PGJyPjxicj4mZ3Q7IEknbSBwcm9iYWJseSBtaXNzaW5nIHNvbWV0aGluZywgYnV0IEknbSBu b3QgdW5kZXJzdGFuZGluZyB0aGlzLiBJZiBJPGJyPmhhdmUgdHdvIGdyb3VwcyBvZiBJb1QgZGV2 aWNlcyBjb25maWd1cmVkIHRvIHVzZSB0aGUgc2FtZSBJUCBtdWx0aWNhc3Q8YnI+YWRkcmVzcywg YW5kIGVhY2ggZ3JvdXAgdXNlcyBpdHMgb3duIFVEUCBwb3J0LCB3aGF0IGRvZXNuJ3Qgd29yaz88 YnI+PGJyPlJlc3BvbnNlOjxicj4tLS0tLS0tLS0tLS0tPGJyPlllcywgeW91IGNvdWxkIHRlY2hu aWNhbGx5IGRvIHRoaXMuJm5ic3A7IEJ1dCBpdCB3b3VsZCBiZSBhIHZlcnkgaW5lZmZpY2llbnQ8 YnI+c3lzdGVtIGFzIHlvdSB3b3VsZCBwcm9wYWdhdGUgbXVsdGljYXN0IHBhY2tldHMgdGhyb3Vn aG91dCB0aGUgbmV0d29yazxicj5hbmQgaGF2ZSB0aGVtIHJlY2VpdmVkIGFuZCBkZWNvZGVkIGlu IGEgZGV2aWNlJ3MgSVAgc3RhY2sgb25seSB0byB0aHJvdzxicj5pdCBhd2F5IGF0IHRoZSBsYXN0 IG1vbWVudCBiZWNhdXNlIGl0IGlzIG9uIHRoZSB3cm9uZyBwb3J0LiZuYnNwOyBJdCB3b3VsZCBi ZTxicj5tdWNoIHNhbmVyL2VmZmljaWVudCB0byBoYXZlIGRpZmZlcmVudCBJUCBtdWx0aWNhc3Qg YWRkcmVzc2VzIHRvPGJyPnNlZ3JlZ2F0ZSB0aGUgcGFja2V0cyBmcm9tIHRoZSBiZWdpbm5pbmcg aW5zdGVhZCBvZiBjb3VudGluZyBvbjxicj5kaWZmZXJlbnQgVURQIHBvcnRzLjxvOnA+PC9vOnA+ PC9wPjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPjwvZGl2Pjxk aXY+PHAgY2xhc3M9TXNvTm9ybWFsPlRoaXMgaXMgdXAgdG8geW91LCBidXQgJnF1b3Q7Y2Fubm90 JnF1b3Q7IGRvZXNuJ3QgbWVhbiAmcXVvdDtiYWQgaWRlYSZxdW90OyB0byBtZSA6LSk8bzpwPjwv bzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48bzpwPiZuYnNwOzwvbzpwPjwv cD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD5JZiBJIG1pZ2h0IG1ha2UgYSBzdWdnZXN0 aW9uLCBwZXJoYXBzIGRlbGV0aW5nIHRoZSBsYXN0IHNlbnRlbmNlLCBhbmQgc2F5aW5nIHNvbWV0 aGluZyBsaWtlJm5ic3A7dGhpcyBpbiBpdHMgb3duIHBhcmFncmFwaD88bzpwPjwvbzpwPjwvcD48 L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48bzpwPiZuYnNwOzwvbzpwPjwvcD48L2Rpdj48 ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD4mcXVvdDtCZWNhdXNlIENvQVAgaXMmbmJzcDtvZnRlbiB1 c2VkIHdpdGggbGltaXRlZC1wb3dlciBkZXZpY2VzLCBpdCBpcyBSRUNPTU1FTkRFRCB0aGF0Jm5i c3A7ZGlzam9pbnQgZ3JvdXBzIGRvIG5vdCBhdHRlbXB0IHRvIHNoYXJlIElQIG11bHRpY2FzdCBh ZGRyZXNzZXMsIGJlY2F1c2UmbmJzcDthbGwgdGhlIGRldmljZXMgdXNpbmcgJm5ic3A7dGhlIHNh bWUgSVAgbXVsdGljYXN0IGFkZHJlc3Mgd2lsbCBzZWUgdHJhZmZpYyBmb3IgYWxsIGdyb3Vwcywg b25seSB0byBkaXNjYXJkIHRyYWZmaWMgaW50ZW5kZWQgZm9yIG90aGVyIGdyb3VwcyZuYnNwO2Jh c2VkIG9uIFVEUCBwb3J0LiZxdW90OzxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9 TXNvTm9ybWFsPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9y bWFsPk9yIG1heWJlIG11bHRpY2FzdCBwZW9wbGUgYWxsIGtub3cgdGhhdD88bzpwPjwvbzpwPjwv cD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48bzpwPiZuYnNwOzwvbzpwPjwvcD48L2Rp dj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD5CdXQgZG8gdGhlIHJpZ2h0IHRoaW5nITxvOnA+PC9v OnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxvOnA+Jm5ic3A7PC9vOnA+PC9w PjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPlNwZW5jZXImbmJzcDs8bzpwPjwvbzpwPjwv cD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48bzpwPiZuYnNwOzwvbzpwPjwvcD48L2Rp dj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD4mbmJzcDs8bzpwPjwvbzpwPjwvcD48L2Rpdj48Ymxv Y2txdW90ZSBzdHlsZT0nYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBw dDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdo dDowaW4nPjxwIGNsYXNzPU1zb05vcm1hbD5CZXN0IFJlZ2FyZHMsPGJyPjxicj48YnI+QWtiYXI8 YnI+PGJyPjxicj48YnI+LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08YnI+RnJvbTogY29yZSBb bWFpbHRvOjxhIGhyZWY9ImphdmFzY3JpcHQ6OyI+Y29yZS1ib3VuY2VzQGlldGYub3JnPC9hPl0g T24gQmVoYWxmIE9mIFNwZW5jZXIgRGF3a2luczxicj5TZW50OiBUdWVzZGF5LCBBdWd1c3QgMTks IDIwMTQgNTo0NiBQTTxicj5UbzogVGhlIElFU0c8YnI+Q2M6IDxhIGhyZWY9ImphdmFzY3JpcHQ6 OyI+Y29yZS1jaGFpcnNAdG9vbHMuaWV0Zi5vcmc8L2E+Ozxicj48YSBocmVmPSJqYXZhc2NyaXB0 OjsiPmRyYWZ0LWlldGYtY29yZS1ncm91cGNvbW1AdG9vbHMuaWV0Zi5vcmc8L2E+OyA8YSBocmVm PSJqYXZhc2NyaXB0OjsiPmNvcmVAaWV0Zi5vcmc8L2E+PGJyPlN1YmplY3Q6IFtjb3JlXSBTcGVu Y2VyIERhd2tpbnMnIE5vIE9iamVjdGlvbiBvbjxicj5kcmFmdC1pZXRmLWNvcmUtZ3JvdXBjb21t LTIxOiAod2l0aCBDT01NRU5UKTxicj48YnI+U3BlbmNlciBEYXdraW5zIGhhcyBlbnRlcmVkIHRo ZSBmb2xsb3dpbmcgYmFsbG90IHBvc2l0aW9uIGZvcjxicj5kcmFmdC1pZXRmLWNvcmUtZ3JvdXBj b21tLTIxOiBObyBPYmplY3Rpb248YnI+PGJyPldoZW4gcmVzcG9uZGluZywgcGxlYXNlIGtlZXAg dGhlIHN1YmplY3QgbGluZSBpbnRhY3QgYW5kIHJlcGx5IHRvIGFsbDxicj5lbWFpbCBhZGRyZXNz ZXMgaW5jbHVkZWQgaW4gdGhlIFRvIGFuZCBDQyBsaW5lcy4gKEZlZWwgZnJlZSB0byBjdXQgdGhp czxicj5pbnRyb2R1Y3RvcnkgcGFyYWdyYXBoLCBob3dldmVyLik8YnI+PGJyPjxicj5QbGVhc2Ug cmVmZXIgdG8gPGEgaHJlZj0iaHR0cDovL3d3dy5pZXRmLm9yZy9pZXNnL3N0YXRlbWVudC9kaXNj dXNzLWNyaXRlcmlhLmh0bWwiIHRhcmdldD0iX2JsYW5rIj5odHRwOi8vd3d3LmlldGYub3JnL2ll c2cvc3RhdGVtZW50L2Rpc2N1c3MtY3JpdGVyaWEuaHRtbDwvYT48YnI+Zm9yIG1vcmUgaW5mb3Jt YXRpb24gYWJvdXQgSUVTRyBESVNDVVNTIGFuZCBDT01NRU5UIHBvc2l0aW9ucy48YnI+PGJyPjxi cj5UaGUgZG9jdW1lbnQsIGFsb25nIHdpdGggb3RoZXIgYmFsbG90IHBvc2l0aW9ucywgY2FuIGJl IGZvdW5kIGhlcmU6PGJyPjxhIGhyZWY9Imh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2Mv ZHJhZnQtaWV0Zi1jb3JlLWdyb3VwY29tbS8iIHRhcmdldD0iX2JsYW5rIj5odHRwOi8vZGF0YXRy YWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtY29yZS1ncm91cGNvbW0vPC9hPjxicj48YnI+ PGJyPjxicj4tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tPGJyPkNPTU1FTlQ6PGJyPi0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08YnI+PGJy Pkkgc2hhcmUgdGhlIGNvbmNlcm5zIE1hcnRpbiBsaXN0ZWQgaW4gaGlzIERpc2N1c3MsIGJ1dCB0 aGF0IGNvbnZlcnNhdGlvbjxicj5pcyBhbHJlYWR5IHVuZGVyd2F5Ljxicj48YnI+SSBzYXcgdGhh dCBNYXJ0aW4gaXMgcXVlc3Rpb25pbmcgd2hldGhlciB0aGlzIGRvY3VtZW50IHNob3VsZCBiZTxi cj5JbmZvcm1hdGlvbmFsLCBidXQ8YnI+PGJyPjEuMi4mbmJzcDsgU2NvcGU8YnI+PGJyPiZuYnNw OyAmbmJzcDtXaGlsZSBbUkZDNzI1Ml0gc3VwcG9ydHMgdmFyaW91cyBtb2RlcyBvZiBEVExTIGJh c2VkIHNlY3VyaXR5IGZvcjxicj4mbmJzcDsgJm5ic3A7Q29BUCBvdmVyIHVuaWNhc3QgSVAsIGl0 IGRvZXMgbm90IHNwZWNpZnkgYW55IHNlY3VyaXR5IG1vZGVzIGZvciBDb0FQPGJyPiZuYnNwOyAm bmJzcDtvdmVyIElQIG11bHRpY2FzdC4mbmJzcDsgVGhhdCBpcywgW1JGQzcyNTJdIGFzc3VtZXMg dGhhdCBDb0FQIG92ZXIgSVA8YnI+Jm5ic3A7ICZuYnNwO211bHRpY2FzdCBpcyBub3QgZW5jcnlw dGVkLCBub3IgYXV0aGVudGljYXRlZCwgbm9yIGFjY2VzcyBjb250cm9sbGVkLjxicj4mbmJzcDsg Jm5ic3A7VGhpcyBkb2N1bWVudCBhc3N1bWVzIHRoZSBzYW1lIHNlY3VyaXR5IG1vZGVsIChzZWUg U2VjdGlvbiA1LjEpLjxicj4mbmJzcDsgJm5ic3A7SG93ZXZlciwgdGhlcmUgYXJlIHNldmVyYWwg cHJvbWlzaW5nIHNlY3VyaXR5IHNvbHV0aW9ucyBiZWluZzxicj4mbmJzcDsgJm5ic3A7ZGV2ZWxv cGVkIHRoYXQgc2hvdWxkIGJlIGNvbnNpZGVyZWQgaW4gdGhlIGZ1dHVyZSBmb3IgcHJvdGVjdGlu ZyBDb0FQPGJyPiZuYnNwOyAmbmJzcDtncm91cCBjb21tdW5pY2F0aW9ucyAoc2VlIFNlY3Rpb24g NS4zLjMpLjxicj48YnI+d291bGQgbWFrZSBtZSB1bmVhc3kgYWJvdXQgcHVibGlzaGluZyBpdCBh cyBzdGFuZGFyZHMtdHJhY2sgaW4gMjAxNC4gSWY8YnI+dGhpcyBzcGVjaWZpY2F0aW9uIHdhcyBF eHBlcmltZW50YWwsIEknZCBmZWVsIGJldHRlciwgYnV0IGFzIHRoZTxicj5zcGVjaWZpY2F0aW9u IGl0c2VsZiBjb3JyZWN0bHkgcG9pbnRzIG91dDo8YnI+PGJyPjUuNC4mbmJzcDsgUGVydmFzaXZl IE1vbml0b3JpbmcgQ29uc2lkZXJhdGlvbnM8YnI+PGJyPiZuYnNwOyAmbmJzcDtBIGtleSBhZGRp dGlvbmFsIHRocmVhdCBjb25zaWRlcmF0aW9uIGZvciBncm91cCBjb21tdW5pY2F0aW9uIGlzPGJy PiZuYnNwOyAmbmJzcDtwb2ludGVkIHRvIGJ5IFtSRkM3MjU4XSB3aGljaCB3YXJucyBvZiB0aGUg ZGFuZ2VycyBvZiBwZXJ2YXNpdmU8YnI+Jm5ic3A7ICZuYnNwO21vbml0b3JpbmcuJm5ic3A7IENv QVAgZ3JvdXAgY29tbXVuaWNhdGlvbiB3aGljaCBpcyBidWlsdCBvbiB0b3Agb2YgSVA8YnI+Jm5i c3A7ICZuYnNwO211bHRpY2FzdCBzaG91bGQgcGF5IHBhcnRpY3VsYXIgaGVlZCB0byB0aGVzZSBk YW5nZXJzLiZuYnNwOyBUaGlzIGlzPGJyPiZuYnNwOyAmbmJzcDtiZWNhdXNlIElQIG11bHRpY2Fz dCBpcyBlYXNpZXIgdG8gaW50ZXJjZXB0IChlLmcuLCBhbmQgdG8gc2VjcmV0bHk8YnI+Jm5ic3A7 ICZuYnNwO3JlY29yZCkgY29tcGFyZWQgdG8gdW5pY2FzdCB0cmFmZmljLiZuYnNwOyBBbHNvLCBD b0FQIHRyYWZmaWMgaXMgbWVhbnQgZm9yPGJyPiZuYnNwOyAmbmJzcDt0aGUgSW50ZXJuZXQgb2Yg VGhpbmdzLiZuYnNwOyBUaGlzIG1lYW5zIHRoYXQgQ29BUCB0cmFmZmljIGlzIG9mdGVuIHVzZWQ8 YnI+Jm5ic3A7ICZuYnNwO2ZvciB0aGUgY29udHJvbCBhbmQgbW9uaXRvcmluZyBvZiBjcml0aWNh bCBpbmZyYXN0cnVjdHVyZSAoZS5nLiw8YnI+Jm5ic3A7ICZuYnNwO2xpZ2h0cywgYWxhcm1zLCBl dGMuKSB3aGljaCBtYXkgYmUgcHJpbWUgdGFyZ2V0cyBmb3IgYXR0YWNrLjxicj48YnI+QXBwcm92 aW5nIGl0IGFzIGEgUHJvcG9zZWQgU3RhbmRhcmQgc2VlbXMgdG8gYmUgYmVnZ2luZyBmb3Igc29t ZW9uZSB0bzxicj5kZXBsb3kgaXQgd2l0aG91dCByZWFkaW5nIHRoZSB3YXJuaW5nIGxhYmVscyAu Li4gd291bGQgYW55b25lIHdobydzPGJyPnBsYW5uaW5nIHRvIHVzZSBDb0FQIGdyb3VwIGNvbW11 bmljYXRpb25zIHdpdGhvdXQgc2VjdXJpdHkgKGJleW9uZDxicj5zdWdnZXN0aW9ucyBzdWNoIGFz IGVuYWJsaW5nIFdpRmkgc2VjdXJpdHkpLCBiZSB1bndpbGxpbmcgdG8gdXNlIGl0IGF0PGJyPkV4 cGVyaW1lbnRhbD88YnI+PGJyPkluIHRoaXMgdGV4dDo8YnI+PGJyPjIuMy4mbmJzcDsgUG9ydCBh bmQgVVJJIENvbmZpZ3VyYXRpb248YnI+PGJyPiZuYnNwOyAmbmJzcDtBIENvQVAgc2VydmVyIHRo YXQgaXMgYSBtZW1iZXIgb2YgYSBncm91cCBsaXN0ZW5zIGZvciBDb0FQIG1lc3NhZ2VzPGJyPiZu YnNwOyAmbmJzcDtvbiB0aGUgZ3JvdXAncyBJUCBtdWx0aWNhc3QgYWRkcmVzcywgdXN1YWxseSBv biB0aGUgQ29BUCBkZWZhdWx0IFVEUDxicj4mbmJzcDsgJm5ic3A7cG9ydCwgNTY4My4mbmJzcDsg SWYgdGhlIGdyb3VwIHVzZXMgYSBzcGVjaWZpZWQgbm9uLWRlZmF1bHQgVURQIHBvcnQsIGJlPGJy PiZuYnNwOyAmbmJzcDtjYXJlZnVsIHRvIGVuc3VyZSB0aGF0IGFsbCBncm91cCBtZW1iZXJzIGFy ZSBjb25maWd1cmVkIHRvIHVzZSB0aGF0PGJyPiZuYnNwOyAmbmJzcDtzYW1lIHBvcnQuJm5ic3A7 IFRoZXJlZm9yZSBkaWZmZXJlbnQgcG9ydHMgZm9yIHRoZSBzYW1lIElQIG11bHRpY2FzdDxicj4m bmJzcDsgJm5ic3A7YWRkcmVzcyBjYW5ub3QgYmUgdXNlZCB0byBzcGVjaWZ5IGRpZmZlcmVudCBD b0FQIGdyb3Vwcy48YnI+PGJyPkknbSBwcm9iYWJseSBtaXNzaW5nIHNvbWV0aGluZywgYnV0IEkn bSBub3QgdW5kZXJzdGFuZGluZyB0aGlzLiBJZiBJPGJyPmhhdmUgdHdvIGdyb3VwcyBvZiBJb1Qg ZGV2aWNlcyBjb25maWd1cmVkIHRvIHVzZSB0aGUgc2FtZSBJUCBtdWx0aWNhc3Q8YnI+YWRkcmVz cywgYW5kIGVhY2ggZ3JvdXAgdXNlcyBpdHMgb3duIFVEUCBwb3J0LCB3aGF0IGRvZXNuJ3Qgd29y az88YnI+PGJyPjxicj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXzxicj5jb3JlIG1haWxpbmcgbGlzdDxicj48YSBocmVmPSJqYXZhc2NyaXB0OjsiPmNvcmVA aWV0Zi5vcmc8L2E+PGJyPjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vY29yZSIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vY29yZTwvYT48bzpwPjwvbzpwPjwvcD48L2Jsb2NrcXVvdGU+PC9kaXY+PC9ib2R5 PjwvaHRtbD4= ------_=_NextPart_001_01CFBC10.D8B3A651-- From nobody Tue Aug 19 18:22:47 2014 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E69871A06D9; Tue, 19 Aug 2014 18:22:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gk_sQukNx5QB; Tue, 19 Aug 2014 18:22:36 -0700 (PDT) Received: from mail-la0-x233.google.com (mail-la0-x233.google.com [IPv6:2a00:1450:4010:c03::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 918A61A0AFD; Tue, 19 Aug 2014 18:22:35 -0700 (PDT) Received: by mail-la0-f51.google.com with SMTP id pn19so6559216lab.38 for ; Tue, 19 Aug 2014 18:22:33 -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=hdEo5AQ92JPbwecsxAopQba34u8421i7x4JHq582K18=; b=VDnDOSVu9zhzw2VoW1yJsCjnJEOWitVS8xeyeanv1r32eqLjHnN6uoQiPWiDqamf+l WSBETKZyJuPV6ZwpGLkjiMNfKTH7L0KQ1bSe1gYPmgMkRAzIin76ukezk10UxSdA+Uus UFI+z8oILmgrrAYWTzZYUHt8xz1TlmSINaD2wRqw/EM8wTZScSrsIyNzKfvsyK8jogtX bOwixbChL77JJYj5KSAR2J08r8d8KXp6ZwOo5OXQExxhBlcn3HoIa0n1VRdav1MU2Tn+ J0OogdzqEEasurKJoPpPNX8u4FNpFT98Ko6SQm1AzH5c8uSZQWlodUTD+WfOCndoPBxx YPEg== MIME-Version: 1.0 X-Received: by 10.152.8.48 with SMTP id o16mr38793434laa.18.1408497753795; Tue, 19 Aug 2014 18:22:33 -0700 (PDT) Received: by 10.152.206.36 with HTTP; Tue, 19 Aug 2014 18:22:33 -0700 (PDT) In-Reply-To: References: <20140819214554.19309.61511.idtracker@ietfa.amsl.com> Date: Tue, 19 Aug 2014 20:22:33 -0500 Message-ID: From: Spencer Dawkins at IETF To: "Rahman, Akbar" Content-Type: multipart/alternative; boundary=001a11c3640e4830d00501057021 Archived-At: http://mailarchive.ietf.org/arch/msg/core/u6MzViA1N3zgsn34uVDLgKJuR6s Cc: "core-chairs@tools.ietf.org" , The IESG , "core@ietf.org" , "draft-ietf-core-groupcomm@tools.ietf.org" Subject: Re: [core] Spencer Dawkins' No Objection on draft-ietf-core-groupcomm-21: (with COMMENT) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Aug 2014 01:22:41 -0000 --001a11c3640e4830d00501057021 Content-Type: text/plain; charset=UTF-8 On Tuesday, August 19, 2014, Rahman, Akbar wrote: > Hi Spencer, > > > > > > >If I might make a suggestion, perhaps deleting the last sentence, and > saying something like this in its own paragraph? > > > > >"Because CoAP is often used with limited-power devices, it is RECOMMENDED > that disjoint groups do not attempt to share IP multicast addresses, > because all the devices using the same IP multicast address will see > traffic for all groups, only to discard traffic intended for other > groups based on UDP port." > > > > > > Response: > > ------------- > > Okay. Good suggestion. We will add it in that section. (Please leave us > editorial license to modify the wording slightly depending on what happens > on the other discussion regarding use of Normative language in the draft). > > Oh, heck, yeah! You folk are the experts on CoAP ... Spencer > > > > > Best Regards, > > > > > > Akbar > > > > > > *From:* Spencer Dawkins at IETF [mailto:spencerdawkins.ietf@gmail.com > ] > *Sent:* Tuesday, August 19, 2014 6:57 PM > *To:* Rahman, Akbar > *Cc:* The IESG; core-chairs@tools.ietf.org > ; > draft-ietf-core-groupcomm@tools.ietf.org > ; > core@ietf.org > *Subject:* Re: Spencer Dawkins' No Objection on > draft-ietf-core-groupcomm-21: (with COMMENT) > > > > Thank you for the quick response! > > On Tuesday, August 19, 2014, Rahman, Akbar > wrote: > > Hi Spencer, > > > Thanks for the good advice on the potential status for the document. > I'll wait for our AD (Barry) to make the final decision on that issue. > With regards to your final technical question: > > > > I'm probably missing something, but I'm not understanding this. If I > have two groups of IoT devices configured to use the same IP multicast > address, and each group uses its own UDP port, what doesn't work? > > Response: > ------------- > Yes, you could technically do this. But it would be a very inefficient > system as you would propagate multicast packets throughout the network > and have them received and decoded in a device's IP stack only to throw > it away at the last moment because it is on the wrong port. It would be > much saner/efficient to have different IP multicast addresses to > segregate the packets from the beginning instead of counting on > different UDP ports. > > > > This is up to you, but "cannot" doesn't mean "bad idea" to me :-) > > > > If I might make a suggestion, perhaps deleting the last sentence, and > saying something like this in its own paragraph? > > > > "Because CoAP is often used with limited-power devices, it is RECOMMENDED > that disjoint groups do not attempt to share IP multicast addresses, > because all the devices using the same IP multicast address will see > traffic for all groups, only to discard traffic intended for other > groups based on UDP port." > > > > Or maybe multicast people all know that? > > > > But do the right thing! > > > > Spencer > > > > > > Best Regards, > > > Akbar > > > > -----Original Message----- > From: core [mailto:core-bounces@ietf.org] On Behalf Of Spencer Dawkins > Sent: Tuesday, August 19, 2014 5:46 PM > To: The IESG > Cc: core-chairs@tools.ietf.org; > draft-ietf-core-groupcomm@tools.ietf.org; core@ietf.org > Subject: [core] Spencer Dawkins' No Objection on > draft-ietf-core-groupcomm-21: (with COMMENT) > > Spencer Dawkins has entered the following ballot position for > draft-ietf-core-groupcomm-21: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > http://datatracker.ietf.org/doc/draft-ietf-core-groupcomm/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > I share the concerns Martin listed in his Discuss, but that conversation > is already underway. > > I saw that Martin is questioning whether this document should be > Informational, but > > 1.2. Scope > > While [RFC7252] supports various modes of DTLS based security for > CoAP over unicast IP, it does not specify any security modes for CoAP > over IP multicast. That is, [RFC7252] assumes that CoAP over IP > multicast is not encrypted, nor authenticated, nor access controlled. > This document assumes the same security model (see Section 5.1). > However, there are several promising security solutions being > developed that should be considered in the future for protecting CoAP > group communications (see Section 5.3.3). > > would make me uneasy about publishing it as standards-track in 2014. If > this specification was Experimental, I'd feel better, but as the > specification itself correctly points out: > > 5.4. Pervasive Monitoring Considerations > > A key additional threat consideration for group communication is > pointed to by [RFC7258] which warns of the dangers of pervasive > monitoring. CoAP group communication which is built on top of IP > multicast should pay particular heed to these dangers. This is > because IP multicast is easier to intercept (e.g., and to secretly > record) compared to unicast traffic. Also, CoAP traffic is meant for > the Internet of Things. This means that CoAP traffic is often used > for the control and monitoring of critical infrastructure (e.g., > lights, alarms, etc.) which may be prime targets for attack. > > Approving it as a Proposed Standard seems to be begging for someone to > deploy it without reading the warning labels ... would anyone who's > planning to use CoAP group communications without security (beyond > suggestions such as enabling WiFi security), be unwilling to use it at > Experimental? > > In this text: > > 2.3. Port and URI Configuration > > A CoAP server that is a member of a group listens for CoAP messages > on the group's IP multicast address, usually on the CoAP default UDP > port, 5683. If the group uses a specified non-default UDP port, be > careful to ensure that all group members are configured to use that > same port. Therefore different ports for the same IP multicast > address cannot be used to specify different CoAP groups. > > I'm probably missing something, but I'm not understanding this. If I > have two groups of IoT devices configured to use the same IP multicast > address, and each group uses its own UDP port, what doesn't work? > > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > > --001a11c3640e4830d00501057021 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Tuesday, August 19, 2014, Rahman, Akbar <Akbar.Rahman@interdigital.com> wrote:

Hi Spencer,

=C2=A0

=C2=A0

= >If I might make a suggestion, perhaps deleting the last sentence, and s= aying something like=C2=A0this in its own paragraph?

=C2=A0

>&= quot;Because CoAP is=C2=A0often used with limited-power devices, it is RECO= MMENDED that=C2=A0disjoint groups do not attempt to share IP multicast addr= esses, because=C2=A0all the devices using =C2=A0the same IP multicast addre= ss will see traffic for all groups, only to discard traffic intended for ot= her groups=C2=A0based on UDP port."

=C2=A0

=C2=A0

Response:

-------------=

Okay.=C2=A0 Good suggesti= on.=C2=A0 We will add it in that section.=C2=A0 (Please leave us editorial = license to modify the wording slightly depending on what happens on the oth= er discussion regarding use of Normative language in the draft).<= /u>


Oh,= heck, yeah! You folk are the experts on CoAP ...

= Spencer
=C2=A0

=C2=A0<= /u>

=C2=A0

Best Regards,

=C2=A0

=C2=A0

Akbar

=C2=A0=

=C2=A0

From: Sp= encer Dawkins at IETF [mailto:spencerdawki= ns.ietf@gmail.com]
Sent: Tuesday, August 19, 2014 6:57 PM
To: Rahman, AkbarCc: The IESG; core-chairs@tools.ietf= .org; draft-ietf-core-group= comm@tools.ietf.org; core@ietf.org
Subject: Re: Spencer Dawkins' No Objection on draft-ietf-core-gr= oupcomm-21: (with COMMENT)

<= u>=C2=A0

Thank you for the quick respo= nse!

On Tuesday, August 19, 2014, Rahman, Akbar <Akbar.Rahman@interdigital.com> wrote:

Hi Spencer,


Thanks for the good advice on the potential status f= or the document.
I'll wait for our AD (Barry) to make the final deci= sion on that issue.
With regards to your final technical question:


> I'm probably missing something, but I'm not understand= ing this. If I
have two groups of IoT devices configured to use the same= IP multicast
address, and each group uses its own UDP port, what doesn&= #39;t work?

Response:
-------------
Yes, you could technically do this.=C2=A0= But it would be a very inefficient
system as you would propagate multic= ast packets throughout the network
and have them received and decoded in= a device's IP stack only to throw
it away at the last moment because it is on the wrong port.=C2=A0 It would = be
much saner/efficient to have different IP multicast addresses to
s= egregate the packets from the beginning instead of counting on
different= UDP ports.

=C2=A0

This is up to you, but "cannot" doesn't mean "= ;bad idea" to me :-)

=C2=A0

If I might make a suggestion, perhaps del= eting the last sentence, and saying something like=C2=A0this in its own par= agraph?

=C2=A0=

"Because CoAP is=C2=A0often used with limi= ted-power devices, it is RECOMMENDED that=C2=A0disjoint groups do not attem= pt to share IP multicast addresses, because=C2=A0all the devices using =C2= =A0the same IP multicast address will see traffic for all groups, only to d= iscard traffic intended for other groups=C2=A0based on UDP port."

=C2=A0

Or maybe multicast people all know that?

=

=C2=A0

But do the right thing!

= =C2=A0

Spencer=C2=A0<= /u>

=C2=A0

=C2=A0

Best Regards,


Akbar


-----Original Message-----
From: core [mailto:core-bounces@ietf.org] On Behalf Of Spencer Dawki= ns
Sent: Tuesday, August 19, 2014 5:46 PM
To: The IESG
Cc: core= -chairs@tools.ietf.org;
draft-ietf-core-groupcomm@tools.ietf.org<= /a>; core@ietf.org
Subject: [core] Spencer Dawkins' No Objection on
draft-ietf-core-gro= upcomm-21: (with COMMENT)

Spencer Dawkins has entered the following = ballot position for
draft-ietf-core-groupcomm-21: No Objection

When responding, please keep the subject line intact and reply to all
em= ail addresses included in the To and CC lines. (Feel free to cut this
in= troductory paragraph, however.)


Please refer to http= ://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


T= he document, along with other ballot positions, can be found here:
http://datatracker.ietf.org/doc/draft-ietf-core-groupcomm/



---------------------------------------------------------------= -------
COMMENT:
----------------------------------------------------= ------------------

I share the concerns Martin listed in his Discuss= , but that conversation
is already underway.

I saw that Martin is questioning whether this d= ocument should be
Informational, but

1.2.=C2=A0 Scope

=C2= =A0 =C2=A0While [RFC7252] supports various modes of DTLS based security for=
=C2=A0 =C2=A0CoAP over unicast IP, it does not specify any security mod= es for CoAP
=C2=A0 =C2=A0over IP multicast.=C2=A0 That is, [RFC7252] assumes that CoAP = over IP
=C2=A0 =C2=A0multicast is not encrypted, nor authenticated, nor = access controlled.
=C2=A0 =C2=A0This document assumes the same security = model (see Section 5.1).
=C2=A0 =C2=A0However, there are several promisi= ng security solutions being
=C2=A0 =C2=A0developed that should be considered in the future for protecti= ng CoAP
=C2=A0 =C2=A0group communications (see Section 5.3.3).

wo= uld make me uneasy about publishing it as standards-track in 2014. If
th= is specification was Experimental, I'd feel better, but as the
specification itself correctly points out:

5.4.=C2=A0 Pervasive Moni= toring Considerations

=C2=A0 =C2=A0A key additional threat considera= tion for group communication is
=C2=A0 =C2=A0pointed to by [RFC7258] whi= ch warns of the dangers of pervasive
=C2=A0 =C2=A0monitoring.=C2=A0 CoAP group communication which is built on t= op of IP
=C2=A0 =C2=A0multicast should pay particular heed to these dang= ers.=C2=A0 This is
=C2=A0 =C2=A0because IP multicast is easier to interc= ept (e.g., and to secretly
=C2=A0 =C2=A0record) compared to unicast traf= fic.=C2=A0 Also, CoAP traffic is meant for
=C2=A0 =C2=A0the Internet of Things.=C2=A0 This means that CoAP traffic is = often used
=C2=A0 =C2=A0for the control and monitoring of critical infra= structure (e.g.,
=C2=A0 =C2=A0lights, alarms, etc.) which may be prime t= argets for attack.

Approving it as a Proposed Standard seems to be b= egging for someone to
deploy it without reading the warning labels ... would anyone who's
= planning to use CoAP group communications without security (beyond
sugge= stions such as enabling WiFi security), be unwilling to use it at
Experi= mental?

In this text:

2.3.=C2=A0 Port and URI Configuration

=C2= =A0 =C2=A0A CoAP server that is a member of a group listens for CoAP messag= es
=C2=A0 =C2=A0on the group's IP multicast address, usually on the = CoAP default UDP
=C2=A0 =C2=A0port, 5683.=C2=A0 If the group uses a spec= ified non-default UDP port, be
=C2=A0 =C2=A0careful to ensure that all group members are configured to use= that
=C2=A0 =C2=A0same port.=C2=A0 Therefore different ports for the sa= me IP multicast
=C2=A0 =C2=A0address cannot be used to specify different= CoAP groups.

I'm probably missing something, but I'm not un= derstanding this. If I
have two groups of IoT devices configured to use the same IP multicast
a= ddress, and each group uses its own UDP port, what doesn't work?

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

--001a11c3640e4830d00501057021-- From nobody Tue Aug 19 19:37:51 2014 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81ABC1A871F for ; Tue, 19 Aug 2014 19:37:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.153 X-Spam-Level: X-Spam-Status: No, score=-0.153 tagged_above=-999 required=5 tests=[BAD_CREDIT=2.415, BAYES_00=-1.9, RP_MATCHES_RCVD=-0.668] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S4S4JrrHSOib for ; Tue, 19 Aug 2014 19:37:47 -0700 (PDT) Received: from smtp-in1.interdigital.com (smtp-in1.interdigital.com [64.208.228.133]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 992151A04AC for ; Tue, 19 Aug 2014 19:37:47 -0700 (PDT) X-ASG-Debug-ID: 1408502264-06daaa39bb0ac90001-aa7cYp Received: from smtp-out1.interdigital.com (sahara.interdigital.com [10.0.128.27]) by smtp-in1.interdigital.com with ESMTP id I93pEUyThKrhMEcD; Tue, 19 Aug 2014 22:37:44 -0400 (EDT) X-Barracuda-Envelope-From: Akbar.Rahman@InterDigital.com Received: from SAM.InterDigital.com ([10.30.2.11]) by smtp-out1.interdigital.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 19 Aug 2014 22:37:42 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 19 Aug 2014 22:37:07 -0400 X-ASG-Orig-Subj: RE: [core] Gen-ART LC Review of draft-ietf-core-groupcomm-21 Message-ID: In-Reply-To: <1AB489F7-A7AF-453F-93AF-98BBE1679891@nostrum.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [core] Gen-ART LC Review of draft-ietf-core-groupcomm-21 Thread-Index: Ac+79sP/tCK8+QxIRe+jgtQfDXgtLAAKHVqg References: <1AB489F7-A7AF-453F-93AF-98BBE1679891@nostrum.com> From: "Rahman, Akbar" To: "Ben Campbell" X-OriginalArrivalTime: 20 Aug 2014 02:37:42.0515 (UTC) FILETIME=[B7783430:01CFBC1F] X-Barracuda-Connect: sahara.interdigital.com[10.0.128.27] X-Barracuda-Start-Time: 1408502264 X-Barracuda-URL: http://10.1.245.3:8000/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at interdigital.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.33 X-Barracuda-Spam-Status: No, SCORE=0.33 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=9.0 tests=BAD_CREDIT, BSF_SC0_MISMATCH_TO X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.8636 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.33 BAD_CREDIT BODY: Eliminate Bad Credit 0.00 BSF_SC0_MISMATCH_TO Envelope rcpt doesn't match header Archived-At: http://mailarchive.ietf.org/arch/msg/core/gfsFyOtqMX-U-zRacWvVydtpdC0 Cc: gen-art@ietf.org, draft-ietf-core-groupcomm.all@tools.ietf.org, core@ietf.org Subject: Re: [core] Gen-ART LC Review of draft-ietf-core-groupcomm-21 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Aug 2014 02:37:49 -0000 Hi Ben, >I understood one of the purposes of this draft is to clarify the usage of group CoAP. I think it's reasonable to expect such clarification to include(normative or otherwise) guidance on how to use it safely. I recognize that there is some guidance there already, but I think you could take a stronger position on some aspects. Response: ------------- Okay. I agree with that suggestion. We will update the text to make stronger recommendations as per your previous comments once we get the guidance from Barry about how to handle the normative text. Best Regards, Akbar -----Original Message----- From: Ben Campbell [mailto:ben@nostrum.com]=20 Sent: Tuesday, August 19, 2014 5:44 PM To: Rahman, Akbar Cc: gen-art@ietf.org; core@ietf.org; draft-ietf-core-groupcomm.all@tools.ietf.org Subject: Re: [core] Gen-ART LC Review of draft-ietf-core-groupcomm-21 On Aug 14, 2014, at 5:12 PM, Rahman, Akbar wrote: > Hi Ben, >=20 >=20 > Thank you for your thorough review. Here is my initial feedback on=20 > the two major issues that you raised: >=20 >=20 >> The draft contains significant material that I do not believe is > appropriate for an informational RFC, at least without some clear=20 > explanations about why it appears. It purports to clarify the=20 > normative stuff in RFC 7252 concerning multicast, but it does quite a=20 > bit more than that. Section 2.7 defines protocol ... >=20 > Response: > ------------- > The majority of the document is geared towards explaining how RESTful=20 > group communications protocol should work based on the protocol=20 > primitives defined in CoAP (RFC 7252). This was certainly the=20 > original intent of the document (i.e. expand and explain CoAP group=20 > communications protocol processing defined in RFC 7252 but do not=20 > introduce any new functionality). Then at a late(r) stage of=20 > development of the document, the WG decided that we should also include > some "management" aspects of CoAP group communications. This resulted > in addition of Sections 2.6, 2.7, 3.6, 6.1, & 6.2. The offending=20 > (new) functionality is pretty clearly limited to these sections. >=20 > Therefore, I think we have two possible options to address your comment: > 1) Remove Sections 2.6, 2.7 & 3.6 that focus on the management aspects > from the current document and spawn a new document (or potentially=20 > migrate them to I-D.ietf-core-resource-directory if that makes sense). > 2) Change the status of the document from Informational to Standards=20 > Track or BCP (and clearly indicate that the new functionality beyond=20 > RFC > 7252 is introduced in Sections 2.6, 2.7, 3.6, 6.1, & 6.2). >=20 > Ben/Barry - Can you give us some guidance here? I think this is really up to you and Barry, but I think either approach would be okay. Option 1 would allow you to treat different sections differently, which might have some advantage. If you chose option 2, Standards Track seems the better option as long as the new functionality is included. >=20 >=20 >=20 >=20 >> The security aspects of group CoAP are pretty bad. To its credit, the > draft does a pretty good job of calling that out, and that work is in=20 > progress to improve it. But I have to wonder if we would be better off > not encouraging multicast CoAP at all until such improvements are=20 > available. >=20 > Response: > ------------- > Well, I think that we could definitely add stronger language=20 > recommending not to use CoAP group communication until stronger=20 > security solutions are developed in IETF. However, as you noted, the=20 > fact is that RFC 7252 already allows the current unsecured CoAP group=20 > communications. So I don't really appreciate how this could be a=20 > blocking issue on progression of this document. I agree that 7252 already has this issue. It also has some normative language around not using it without some type of authentication, but IIRC it doesn't say much about protection from eavesdroppers or privacy issues.=20 I understood one of the purposes of this draft is to clarify the usage of group CoAP. I think it's reasonable to expect such clarification to include(normative or otherwise) guidance on how to use it safely. I recognize that there is some guidance there already, but I think you could take a stronger position on some aspects.=20 For example, you mention how the smart grid example may be high risk. It would be helpful to also point out how it by nature cannot be secured by the mitigation approaches mentioned in section 5, nor the minimal scope recommendation in section 5.4. Therefore, perhaps group CoAP should not be used for that application? >=20 >=20 >=20 > Looking forward to your response, >=20 >=20 > Akbar >=20 >=20 > -----Original Message----- > From: core [mailto:core-bounces@ietf.org] On Behalf Of Ben Campbell > Sent: Thursday, August 14, 2014 5:06 PM > To: draft-ietf-core-groupcomm.all@tools.ietf.org > Cc: gen-art@ietf.org Team (gen-art@ietf.org); core@ietf.org > Subject: [core] Gen-ART LC Review of draft-ietf-core-groupcomm-21 >=20 > (Oops, I screwed up the CC list the first try. Please send any replies > to this distribution. Apologies for the repeat.) >=20 > I am the assigned Gen-ART reviewer for this draft. For background on=20 > Gen-ART, please see the FAQ at >=20 > . >=20 > Please resolve these comments along with any other Last Call comments=20 > you may receive. >=20 > Document: draft-ietf-core-groupcomm-21 > Reviewer: Ben Campbell > Review Date: 2014-08-14 > IETF LC End Date: 2014-08-14 > IESG Telechat date:=20 >=20 > Summary: This draft is not ready for publication as an informational=20 > RFC. It has some significant issues, detailed below. >=20 > **** Major issues: >=20 > -- The draft contains significant material that I do not believe is=20 > appropriate for an informational RFC, at least without some clear=20 > explanations about why it appears. It purports to clarify the=20 > normative stuff in RFC 7252 concerning multicast, but it does quite a=20 > bit more than that. >=20 > Section 2.7 defines protocol, in the form of a RESTful methods and=20 > attributes to manage multicast group membership.I agree in some cases=20 > it makes sense for an informational RFC to define protocol. A common=20 > example is when we want to document a proprietary protocol for some=20 > reason. As written, this does not seem to fall unto such a case. If=20 > the authors and working group believe it does, it would be helpful to=20 > add text explaining that, and how the reader should interpret the section. > (I recognize that this interface is optional--but I don't think making > it optional changes whether it should be standards track.) >=20 > In addition to that, the draft contains quite a bit of guidance that=20 > might be more appropriate BCP. For example, there is guidance here=20 > where not following it might do harm to the network. Additionally, I=20 > don't see how anyone could expect to achieve interoperability the=20 > multicast features of RFC 7252 without understanding this draft. (I=20 > have to wonder why RFC 7252 did not have a normative dependency on=20 > this draft.) >=20 > -- The security aspects of group CoAP are pretty bad. To its credit,=20 > the draft does a pretty good job of calling that out, and that work is > in progress to improve it. But I have to wonder if we would be better=20 > off not encouraging multicast CoAP at all until such improvements are=20 > available. Section 5.3 calls out some reasonable examples of=20 > mitigation approaches, but I am a little concerned at the guidance=20 > that one should worry about these for "sensitive" or "safety-critical" > data. People are not good at knowing what data is "sensitive" until it > gets used against them. I think this is especially true for IoT=20 > applications where we have less deployment experience. >=20 > Along those lines, the Pervasive Monitoring Considerations section=20 > (kudos for having one, btw), tries to balance application needs vs=20 > protecting information. But the smart-grid example seems to be a case=20 > where the two are really at odds. I am afraid people will interpret=20 > this along the lines of "well, the smart-grid application requirements > force me to send unprotected data all over the place", when I think=20 > the right answer is "Group CoAP should not be used for this sort of=20 > application until we can protect the data". >=20 >=20 >=20 >=20 > **** Minor issues: >=20 > -- 2.2, 5th paragraph: "For sending nodes, it is recommended to use=20 > the IP multicast address literal in a group URI." >=20 > Can you elaborate on why? I can guess, but anytime we suggest using=20 > literal IP addresses rather than DNS names, it's worth elaborating. >=20 > -- 2.4: " ... if the resource being POSTed to has been designed to=20 > cope with the unreliable and lossy nature of IP multicast." >=20 > Can you elaborate on what it means to be "designed to cope..."? (Or=20 > reference something that does?) >=20 > -- 2.6: >=20 > I think the Resource Directory reference needs to be normative. (I=20 > see the discussion of this from Barry's AD review, where the authors=20 > argued that the reference is optional for implementations. But our=20 > definition of normative references also includes things necessary to=20 > fully understand this draft. Fully understanding even optional=20 > features is part of that.) >=20 > -- 2.7.1, 2nd paragraph: >=20 > Does this imply a need to coordinate pre-configured group addresses to > avoid collisions? >=20 > -- 2.7.2.1: 2nd 2 last paragraph: >=20 > Are there any scenarios where a missing port might be determined from=20 > DNS, rather than just assuming the default? >=20 > -- 2.7.2.6, 1st paragraph: "This operation MUST only be used to delete > or update group membership objects for which the CoAP client, invoking > this operation, is responsible" >=20 > Do I understand correctly that this replaces the entire set? Is it=20 > possible for two different clients to be responsible for two different > subsets? If so, how? >=20 > -- 2.8 and (especially) 2.9: >=20 > Lack of 2119 language in the "additional guidlines" seems inconsistent > with other parts of this draft that do use 2119 language. (I agree the > places where you talk about what 7252 already says should not use 2119 > language.) I can maybe see the difference for 2.8, but the=20 > congestion-avoidance stuff in 2.9 seems as appropriate for 2119=20 > language as most anything else in the draft. >=20 > (To be clear, I'm not suggesting more or less normative language--only > consistency in its use.) >=20 >=20 >=20 >=20 > **** Nits/editorial comments: >=20 > -- Abstract: >=20 > Please expand CoAP on first use in abstract. (But don't remove the=20 > expansion in the body.) >=20 > -- 2.2, 4th paragraph: " ... it is recommended ..."=20 >=20 > Was that intended as normative?=20 >=20 > Along those lines, I see a number of sections where 2119 words are=20 > used in lower case where it looks like they were not intended as=20 > normative (e.g., where you talk about normative requirements from RFC=20 > 7252), but in other areas it's not as clear (like this one.) It would=20 > be best to either avoid lower case versions of 2119 words, or make it=20 > very clear whether they should be interpreted normatively or not. >=20 > -- 2.7.2, 2nd paragraph: >=20 > Wording is confusing. Do you mean MUST use the DTLS method, or MUST=20 > use some method, with DTLS an option? Sentence seems to mean the=20 > former, in which it would be more clear to say "MUST use DTLS as described in ..." >=20 > -- 2.7.2.1, 3rd paragraph: >=20 > Please expand JDON on first use. >=20 > -- 2.7.2.1, paragraph after examples: >=20 > You mention an optional port for "a" attributes, but not for "n" > attributes. The BNF for group-name seems to allow an optional port.=20 > (and you mention an optional port for "n" later. >=20 >=20 >=20 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core From nobody Wed Aug 20 04:11:12 2014 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D1821A01F9; Wed, 20 Aug 2014 04:11:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vcwoOXph7T3R; Wed, 20 Aug 2014 04:11:06 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 62B921A0217; Wed, 20 Aug 2014 04:11:05 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Jari Arkko" To: The IESG X-Test-IDTracker: no X-IETF-IDTracker: 5.6.2.p5 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140820111105.1912.10295.idtracker@ietfa.amsl.com> Date: Wed, 20 Aug 2014 04:11:05 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/core/6PwPq5jUTCkIwnJIt01QRTIW3Rw Cc: draft-ietf-core-observe@tools.ietf.org, core-chairs@tools.ietf.org, core@ietf.org Subject: [core] Jari Arkko's Yes on draft-ietf-core-observe-14: (with COMMENT) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Aug 2014 11:11:07 -0000 Jari Arkko has entered the following ballot position for draft-ietf-core-observe-14: Yes When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-ietf-core-observe/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thank you for this excellent and much needed work. I'm happy to recommend the publication of this specification as an RFC: From nobody Wed Aug 20 08:10:09 2014 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABE311A06DC; Wed, 20 Aug 2014 08:10:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.5 X-Spam-Level: X-Spam-Status: No, score=-100.5 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N8BptqmL7QOp; Wed, 20 Aug 2014 08:09:59 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DB0E1A06AD; Wed, 20 Aug 2014 08:09:56 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Adrian Farrel" To: The IESG X-Test-IDTracker: no X-IETF-IDTracker: 5.6.2.p5 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140820150956.17106.30570.idtracker@ietfa.amsl.com> Date: Wed, 20 Aug 2014 08:09:56 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/core/MS8SyBk_lWHMvUDdI-ucnZWvArY Cc: draft-ietf-core-observe@tools.ietf.org, core-chairs@tools.ietf.org, core@ietf.org Subject: [core] Adrian Farrel's No Objection on draft-ietf-core-observe-14: (with COMMENT) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Aug 2014 15:10:02 -0000 Adrian Farrel has entered the following ballot position for draft-ietf-core-observe-14: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-ietf-core-observe/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I have no objection to the publication of this document, but I note a number of issues below that may be documentation concerns or may be wrinkles in the protocol. I leave the authors, shepherd, and AD to work out if any action is needed. --- Section 1.1 needs to explain what is a "resource". There is a special meaning in the context of this document (I think) that is not the same as the "network resource" that other people working in constrained networks might consider. You should be able to slot this in to... The model of REST is that of a client exchanging representations of resources with a server, where a representation captures the current or intended state of a resource and the server is the authority for representations of the resources in its namespace. A client interested in the state of a resource initiates a request to the server; the server then returns a response with a representation of the resource that is current at the time of the request. --- I was doing well in understanding how this protocol was a trade-off in optimization. A repeated Get/response exchange is heavy on network resources. A register/push system (like hear) addresses that but trades it for state on the server. You can't win, but you can choose, and this document appears to make a choice. And then, in Section 1.2... A client remains on the list of observers as long as the server can determine the client's continued interest in the resource. The interest is determined from the client's acknowledgement of notifications sent in confirmable CoAP messages by the server. When the client deregisters, rejects a notification, or the transmission of a notification times out after several transmission attempts, the client is considered no longer interested and is removed from the list of observers by the server. So this has two problems: 1. It appears to say that the Get/response mode is replaced with register/push/ack which does not reduce the message flows and causes the server to retain even more state :-( 2. "client's acknowledgement of notifications sent in confirmable CoAP messages by the server" is ambiguous. It could be read to say that the aknowledgements are sent in confirmable messages by the server! I think you need some more clarity in this paragraph. How about... A client remains on the list of observers as long as the server can determine the client's continued interest in the resource. The may server send a notification in a confirmable CoAP messages to request an acknowledgement by the client. When the client deregisters, rejects a notification, fails to respond to a confirmable CoAP message, or when the transmission of a notification by the server times out after several transmission attempts, the client is considered to be no longer interested and is removed from the list of observers by the server. See also comments on Section 3.5. Maybe the document is also missing guidance about how often to seek confirmation. An acknowledgement message signals to the server that the client is alive and interested in receiving further notifications; if the server does not receive an acknowledgement in reply to a confirmable notification, it will assume that the client is no longer interested and will eventually remove the associated entry from the list of observers. --- Section 2 jumps in a little with some assumptions of how much the reader knows about CoAP. Of course, it is reasonable to assume familiarity, but maybe some references for what an Option is and how it is encoded? --- Section 3.1 A client ... MUST NOT register more than once for the same target resource. So, suppose a client does register a second time for the same resource. The server still has to handle it, notwithstanding the "MUST NOT". It can handle it by saying: - I see it is a duplicate, I'll ignore it or - I see it is a duplicate, I'll treat it as a protocol violation and reject it. But in Section 4.1 If an entry with a matching endpoint/token pair is already present in the list (which, for example, happens when the client wishes to reinforce its interest in a resource), the server MUST NOT add a new entry but MUST replace or update the existing one. So, you have written text to describe how a server handles this case and you have even described why a client might send a second registration. Can you clarify? --- Section 3.3.1 A client MAY store a notification like a response in its cache and use a stored notification that is fresh without contacting the server. This reads very much like an implementation detail rather than a protocol specification. >From a protocol point of view the information in the notification is fresh until it times out. What use the client makes of that is surely up to the client. --- Section 3.5 An acknowledgement message signals to the server that the client is alive and interested in receiving further notifications; if the server does not receive an acknowledgement in reply to a confirmable notification, it will assume that the client is no longer interested and will eventually remove the associated entry from the list of observers. Now. Suppose the notification or acknowledgement is lost (I think message loss is possible in CoAP, right?). Or suppose there is reordering so that the confirmable notification is overtaken by a subsequent non-confirmable notification? Shouldn't the server have a slightly more rigorous approach to determining that a client is no longer interested in notifications to avoid falsely removing an interested client? Perhaps that is what "eventually" is supposed to convey, but that is not a suitable word for including in a protocol spec. From nobody Wed Aug 20 09:14:44 2014 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17FEB1A6F53; Tue, 19 Aug 2014 15:29:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xzxqkK_nX32d; Tue, 19 Aug 2014 15:29:41 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CF171A6F59; Tue, 19 Aug 2014 15:29:41 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Kathleen Moriarty" To: The IESG X-Test-IDTracker: no X-IETF-IDTracker: 5.6.2.p5 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140819222941.32135.36513.idtracker@ietfa.amsl.com> Date: Tue, 19 Aug 2014 15:29:41 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/core/hB7GDCgRfyXJRy63ezWVC29QIws X-Mailman-Approved-At: Wed, 20 Aug 2014 09:14:42 -0700 Cc: draft-ietf-core-observe@tools.ietf.org, core-chairs@tools.ietf.org, core@ietf.org Subject: [core] Kathleen Moriarty's No Objection on draft-ietf-core-observe-14: (with COMMENT) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Aug 2014 22:29:42 -0000 Kathleen Moriarty has entered the following ballot position for draft-ietf-core-observe-14: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-ietf-core-observe/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I think it is worth adding a mention of Section 9 applying in addition to section 11 as a reference for security considerations in 7252. This would only add a couple of words and make it clear that you've covered session encryption options with explanations of why each option exists and the risks. From nobody Wed Aug 20 09:14:46 2014 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 394791A048C; Wed, 20 Aug 2014 09:10:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qXt9__JVcA7z; Wed, 20 Aug 2014 09:10:54 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 886521A047A; Wed, 20 Aug 2014 09:10:54 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Alia Atlas" To: The IESG X-Test-IDTracker: no X-IETF-IDTracker: 5.6.2.p5 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140820161054.16869.95223.idtracker@ietfa.amsl.com> Date: Wed, 20 Aug 2014 09:10:54 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/core/bj2dAFU9Q0DopsUyYzAOuTkzQ3Y X-Mailman-Approved-At: Wed, 20 Aug 2014 09:14:43 -0700 Cc: draft-ietf-core-observe@tools.ietf.org, core-chairs@tools.ietf.org, core@ietf.org Subject: [core] Alia Atlas' No Objection on draft-ietf-core-observe-14: (with COMMENT) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Aug 2014 16:10:56 -0000 Alia Atlas has entered the following ballot position for draft-ietf-core-observe-14: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-ietf-core-observe/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I do agree with Adrian's comments and concerns though. From nobody Wed Aug 20 11:51:27 2014 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 095891A069B; Wed, 20 Aug 2014 11:51:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BMrwljAX1BG4; Wed, 20 Aug 2014 11:51:23 -0700 (PDT) Received: from uillean.fuaim.com (uillean.fuaim.com [206.197.161.140]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2548C1A0678; Wed, 20 Aug 2014 11:51:22 -0700 (PDT) Received: from clairseach.fuaim.com (clairseach-high.fuaim.com [206.197.161.158]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by uillean.fuaim.com (Postfix) with ESMTP id D48CA8811E; Wed, 20 Aug 2014 11:51:22 -0700 (PDT) Received: from Littlejohn.local (c-76-21-129-88.hsd1.md.comcast.net [76.21.129.88]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by clairseach.fuaim.com (Postfix) with ESMTP id 1AEE371B0001; Wed, 20 Aug 2014 11:51:22 -0700 (PDT) Message-ID: <53F4EE21.4030207@innovationslab.net> Date: Wed, 20 Aug 2014 14:51:13 -0400 From: Brian Haberman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "Rahman, Akbar" , The IESG References: <20140819144334.30860.77254.idtracker@ietfa.amsl.com> <53F381B0.1040307@innovationslab.net> <53F3A8FA.2040703@innovationslab.net> In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="FgHP09B9WE93hbASS351k3wb2glCRe0g1" Archived-At: http://mailarchive.ietf.org/arch/msg/core/aYB9jO3n21_YXjer9ihvgUCE_Qg Cc: core-chairs@tools.ietf.org, draft-ietf-core-groupcomm@tools.ietf.org, core@ietf.org Subject: Re: [core] Brian Haberman's Discuss on draft-ietf-core-groupcomm-21: (with DISCUSS and COMMENT) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Aug 2014 18:51:25 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --FgHP09B9WE93hbASS351k3wb2glCRe0g1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Akbar, On 8/19/14 5:03 PM, Rahman, Akbar wrote: > Hi Brian, >=20 > =20 > Okay. Now I understand your point. The thing is that the only real > "publication" method would have been in the service discovery of item 2= =2E > So we could re-phrase item 2 to explicitly call this out as follows: >=20 > OLD: >=20 > 2. If the client is configured to use service discovery including > port discovery, it uses a port number obtained via a service > discovery lookup operation for the targeted CoAP group. >=20 >=20 > NEW: >=20 > 2. If the client is configured to use service discovery including > URI and/or port discovery, it uses the port number obtained via > the service > discovery lookup operation for the targeted CoAP group. >=20 >=20 > Does that address your question? >=20 Works for me. Thanks for taking the time to work through this. Regards, Brian --FgHP09B9WE93hbASS351k3wb2glCRe0g1 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.20 (Darwin) Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJT9O4oAAoJEBOZRqCi7goqsy0IAIz2opdybLe2BslvqPESAG8E k4cpQizIN1ibWdhvqACBkN5CS5Bjdlvi6aqxJTqXrmWqknFoQ3udG4ZHXhzRdzLi 7AKsz4TJnQ5f7aTPTjS9XtsAkJhDudcx9jvvze+71TCq4hHFA04m9OgUF/2CUPHZ EEk3cAKBQLsVQhiHOTKxDpKEVC6+uV8x2SjQvkH22apFxYb7nphoBsv2NXHey2et UzfnfXGTXirXWaAT2Gvs2geW1yohPLYy8hAdnvFMmU2445wzs7wthwSMlZJdy4Pb are1xDTmBrSQRNUeqkEzB572gYm8frqrp/6hqoWHa6bLSDG1TMSf3nVdZxcSpL4= =YB/E -----END PGP SIGNATURE----- --FgHP09B9WE93hbASS351k3wb2glCRe0g1-- From nobody Wed Aug 20 12:58:43 2014 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 615031A06A6; Wed, 20 Aug 2014 12:58:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z4gPIN6fM9RK; Wed, 20 Aug 2014 12:58:39 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D0F51A0676; Wed, 20 Aug 2014 12:58:39 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Richard Barnes" To: The IESG X-Test-IDTracker: no X-IETF-IDTracker: 5.6.2.p5 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140820195839.24268.61215.idtracker@ietfa.amsl.com> Date: Wed, 20 Aug 2014 12:58:39 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/core/C5rah0Ex8qtEb_SXUoEhWDz8O5s Cc: draft-ietf-core-observe@tools.ietf.org, core-chairs@tools.ietf.org, core@ietf.org Subject: [core] Richard Barnes' Discuss on draft-ietf-core-observe-14: (with DISCUSS and COMMENT) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Aug 2014 19:58:41 -0000 Richard Barnes has entered the following ballot position for draft-ietf-core-observe-14: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-ietf-core-observe/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- As usual, I'm impressed by the high quality of documents from the CORE WG. Thanks! There are just a few points that need clarification. One very temporary point: Has anyone done a comparison between this work and the server push aspects of HTTP/2? Is there any value in trying to align the two? It's unclear to me from the text of Section 2 how the 0/1 register/deregister values are used. Are these reserved values out of the sequence number space? Or are they carried somewhere else in the option? I infer from Section 3.6 that the answer is the former, but Section 2 should be explicit about this. In fact, it seems like it's not necessary to reserve the value 1 at all, since the server must interpret any positive value as deregistration. Calling out 1 as special invites server implementations to screw this up. "the time elapsed between the two incoming messages is not so large that the difference between V1 and V2 has become larger than the largest integer that it is meaningful to add to a 24-bit serial number" The text seems confused about whether the value of the Observe option is a serial number or a time value. The definition says that it's a serial number, but this sentence implies that it's somehow related to time. In order to avoid clients making unwarranted assumptions about the value of the Observe option, it seems important to clarify this. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- "And third, the server may erroneously come to the conclusion that the client is no longer interested" To mitigate this, might it be useful for a client to sometimes send "gratuitous ACKs"? That is, to periodically re-ACK the last notification to re-confirm its interest? "If the server returns a 2.xx response that includes an Observe Option as well..." Does the value of this option matter at all? Could the server, for example, simply mirror the client's option? "Notifications are additional responses..." Might be helpful to re-word to emphasize that the only difference between a "notification" and a normal response is the presence of the Observe option. "Non-2.xx responses do not include an Observe Option..." Should this be a MUST NOT? It seems like an interop requirement, in the sense of maintaining a consistent view of subscription state between server and client. From nobody Wed Aug 20 14:24:41 2014 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 946CF1A00AF; Wed, 20 Aug 2014 14:24:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dqsUzLnRSZ9W; Wed, 20 Aug 2014 14:24:36 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id AC8AD1A0B81; Wed, 20 Aug 2014 14:24:36 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Adrian Farrel" To: The IESG X-Test-IDTracker: no X-IETF-IDTracker: 5.6.2.p5 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140820212436.16876.14445.idtracker@ietfa.amsl.com> Date: Wed, 20 Aug 2014 14:24:36 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/core/N52Tc7u8xeUnpenfs1ar_Qypjn8 Cc: core-chairs@tools.ietf.org, draft-ietf-core-groupcomm@tools.ietf.org, core@ietf.org Subject: [core] Adrian Farrel's No Objection on draft-ietf-core-groupcomm-21: (with COMMENT) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Aug 2014 21:24:39 -0000 Adrian Farrel has entered the following ballot position for draft-ietf-core-groupcomm-21: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-ietf-core-groupcomm/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Martin has a good catch about updates to 7252 and I support his Discuss. --- It would have been nice to have heard about implementations of CoAP that do group communication and whether they consider themselves consistent with this I-D. From nobody Wed Aug 20 20:15:15 2014 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8B1B1A6F6B; Wed, 20 Aug 2014 20:15:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6WnkDlMaHYKL; Wed, 20 Aug 2014 20:15:08 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 87E371A00B2; Wed, 20 Aug 2014 20:15:08 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Kathleen Moriarty" To: The IESG X-Test-IDTracker: no X-IETF-IDTracker: 5.6.2.p5 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140821031508.17407.99588.idtracker@ietfa.amsl.com> Date: Wed, 20 Aug 2014 20:15:08 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/core/MvGlO111QSTbFgit6BGBLBVPQMU Cc: core-chairs@tools.ietf.org, draft-ietf-core-groupcomm@tools.ietf.org, core@ietf.org Subject: [core] Kathleen Moriarty's Discuss on draft-ietf-core-groupcomm-21: (with DISCUSS and COMMENT) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Aug 2014 03:15:10 -0000 Kathleen Moriarty has entered the following ballot position for draft-ietf-core-groupcomm-21: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-ietf-core-groupcomm/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Overall, the draft is well written and although security is not present, the threats and proposed future solution discussion is good. Section 5.4 is specific to pervasive monitoring, but I think monitoring is better as it casts a wider net and could include pervasive monitoring concerns, but other concerns as well related to monitoring. Monitoring could be targeted to observe specific organizations, people, or devices, that could also be used as part of a targeted attack. Monitoring could also lead to privacy concerns if patterns of behavior are observed for individuals. Thanks. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I support the comments by others on the document not really being informational. The lack of security controls is an issue, experimental would be good until it is resolved as there is a lot of work to be done in this space and it is active. From nobody Thu Aug 21 01:53:39 2014 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 515651A06C1; Wed, 20 Aug 2014 17:16:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.1 X-Spam-Level: X-Spam-Status: No, score=-1.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uUKFaAN4OJ8S; Wed, 20 Aug 2014 17:16:36 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 480F51A0720; Wed, 20 Aug 2014 17:16:26 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Alissa Cooper" To: The IESG X-Test-IDTracker: no X-IETF-IDTracker: 5.6.2.p5 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140821001626.21862.19047.idtracker@ietfa.amsl.com> Date: Wed, 20 Aug 2014 17:16:26 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/core/rVrWG-Er6dcQ3olZxhvXSXsRDjU X-Mailman-Approved-At: Thu, 21 Aug 2014 01:53:37 -0700 Cc: core-chairs@tools.ietf.org, draft-ietf-core-groupcomm@tools.ietf.org, core@ietf.org Subject: [core] Alissa Cooper's No Objection on draft-ietf-core-groupcomm-21: (with COMMENT) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Aug 2014 00:16:38 -0000 Alissa Cooper has entered the following ballot position for draft-ietf-core-groupcomm-21: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-ietf-core-groupcomm/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I agree with Richard/Martin that this doesn't seem like it is informational, and that experimental is probably the appropriate status. From nobody Thu Aug 21 05:14:39 2014 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBF171A6F85; Thu, 21 Aug 2014 05:14:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4gEJC12DxhRA; Thu, 21 Aug 2014 05:14:34 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B3CC21A6F87; Thu, 21 Aug 2014 05:14:34 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Pete Resnick" To: The IESG X-Test-IDTracker: no X-IETF-IDTracker: 5.6.2.p5 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140821121434.26081.28936.idtracker@ietfa.amsl.com> Date: Thu, 21 Aug 2014 05:14:34 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/core/XtHtiJuTrnIvO8ULIy3kLj7_8cM Cc: core-chairs@tools.ietf.org, draft-ietf-core-groupcomm@tools.ietf.org, core@ietf.org Subject: [core] Pete Resnick's No Objection on draft-ietf-core-groupcomm-21: (with COMMENT) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Aug 2014 12:14:36 -0000 Pete Resnick has entered the following ballot position for draft-ietf-core-groupcomm-21: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-ietf-core-groupcomm/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I agree with others: I sure would like to see this be Experimental, see some implementation experience, and, when security issues are sussed out, see it moved onto the Standards Track. A few small comments; nothing earth-shattering: 2.7.2.1/2.7.2.2/2.7.2.6/2.7.2.7: ...the endpoint MUST effect registration...as soon as possible. "MUST" do something "as soon as possible" does not seem like a testable requirement. What purpose is it serving? 2.8: These normative behaviors and guidelines look like they could use 2119 keywords. In particular, quite a few of those "should not"s look like they are meant as "SHOULD NOT"s. They obviously don't need to be, but I was wondering if there was something I was missing. From nobody Thu Aug 21 07:03:11 2014 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6BD21A02F5; Thu, 21 Aug 2014 07:03:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.568 X-Spam-Level: X-Spam-Status: No, score=-2.568 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.668] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kqIESxVdcCh7; Thu, 21 Aug 2014 07:03:00 -0700 (PDT) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by ietfa.amsl.com (Postfix) with ESMTP id A472C1A02E8; Thu, 21 Aug 2014 07:02:59 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id D8EBD2CED3; Thu, 21 Aug 2014 17:02:57 +0300 (EEST) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a5a9qjZWalQz; Thu, 21 Aug 2014 17:02:49 +0300 (EEST) Received: from [127.0.0.1] (p130.piuha.net [IPv6:2a00:1d50:2::130]) by p130.piuha.net (Postfix) with ESMTP id 38F1D2CD0E; Thu, 21 Aug 2014 17:02:49 +0300 (EEST) Content-Type: multipart/signed; boundary="Apple-Mail=_0AAF8FF2-E386-4D45-AC7D-A27B2A168382"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Jari Arkko In-Reply-To: Date: Thu, 21 Aug 2014 17:02:47 +0300 Message-Id: <505020FC-D864-4AF7-B451-799B37246680@piuha.net> References: <1AB489F7-A7AF-453F-93AF-98BBE1679891@nostrum.com> To: "Rahman, Akbar" X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/core/YnxK-MoPGv_qwLp3awZtdIRyf1I Cc: Ben Campbell , gen-art@ietf.org, draft-ietf-core-groupcomm.all@tools.ietf.org, core@ietf.org Subject: Re: [core] [Gen-art] Gen-ART LC Review of draft-ietf-core-groupcomm-21 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Aug 2014 14:03:07 -0000 --Apple-Mail=_0AAF8FF2-E386-4D45-AC7D-A27B2A168382 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Ben, Thank you very much for your on-spot review. I agree with your = comments. And thank you Akbar for starting to address Ben=92s questions. I have also reviewed the draft, and observe that a few other ADs have = raised the Informational classification as an issue as well. One of the = suggested ways out of the issue is to re-classify the document as = Experimental. Perhaps that might be a way forward, while being able to = retain some of the protocol definitions/extensions that this document = does. I will not hold a Discuss on this document, because other ADs already = do. However, I have a number of my own comments that you may consider if = you find them useful. I=92ll send them shortly. Jari=20 --Apple-Mail=_0AAF8FF2-E386-4D45-AC7D-A27B2A168382 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJT9fwHAAoJEM80gCTQU46qWKoP/0ARIhTPEXCNMd4p3LQ9rCeC 8Gv2TpHsZNc1W4u2394Drlod02za88MJrJVlQrmOO0cuS75FiJvZQKdubWFiZwHO /ZzMbTkRnXkTDCAT+/jvVqBblJeGDCqEEv8XMdA6j3A2Pqf69uqTK2UBYdWttji/ B1+++l/VIWYwQSUo8FAydJQ0Q2GfGUfvX4xPhiHPKYuqLgg6l3xJatDWsyPV16K3 IXj5ye0NOXiZN3+SaF0RycMRhA0t7WIUsIWvgFFFfgGhqMNBFpU7wABmJEVQimZx lyC9e3bfd5TGQylgb/hFS5DetvH+5HW0CQWHKODnNuH9Ic8brHo7qJuERiJSChZk HBhhc7hqSovt0IBJO/vnlTKqW1B/jexfkA3UuWLXics1arGviOW36Ocky0h5aQ7o mdlrrUx4eobLYuy7w/x1/WBkIomXJmKRdw4wgYMh7hxwHC56uX6AxMrSW94pBpHq Szf7BqvMJN+4bCNE29+bw973K6DTX6SXYhd5vbRIJmYSMbJVkvkSCgZgjpJ6zP6t miFHxnYTwWz0xiUV/NJlbbCtMj8PQKH9RbJHCobqgrgtHFA45WFMuqq7eVdXUNZH pR1Q6ljbKBINV4VO2Z7sanaLsoDuN9WLxi4IA6UZLirhit1c49AS9kxB6TAXPj02 6pNHgvKdxkoi/3a/zZ6h =ZBK8 -----END PGP SIGNATURE----- --Apple-Mail=_0AAF8FF2-E386-4D45-AC7D-A27B2A168382-- From nobody Thu Aug 21 07:08:11 2014 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F0CF1A032C; Thu, 21 Aug 2014 07:07:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yDQLVI0N84Vp; Thu, 21 Aug 2014 07:07:49 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 609201A0339; Thu, 21 Aug 2014 07:07:26 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Ted Lemon" To: The IESG X-Test-IDTracker: no X-IETF-IDTracker: 5.6.2.p5 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140821140726.22376.25254.idtracker@ietfa.amsl.com> Date: Thu, 21 Aug 2014 07:07:26 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/core/rbsDJiwFIVmKPy8ZS6t3seSsbHU Cc: draft-ietf-core-observe@tools.ietf.org, core-chairs@tools.ietf.org, core@ietf.org Subject: [core] Ted Lemon's No Objection on draft-ietf-core-observe-14: (with COMMENT) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Aug 2014 14:07:57 -0000 Ted Lemon has entered the following ballot position for draft-ietf-core-observe-14: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-ietf-core-observe/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- In section 3.2: In the event that the resource changes in a way that would cause a normal GET request at that time to return a non-2.xx response (for example, when the resource is deleted), the server sends a notification with an appropriate response code (such as 4.04 Not Found) and removes all clients from the list of observers of the resource. Would the 4.04 message be confirmable in cases where a 2.05 would be? If so, does the removal happen when the confirmation is received, or immediately? Also, this text implies that the server sends one message and then removes all the clients from the list of observers; wouldn't it make more sense to say that the server sends one message and removes the client to which it sent the message from the list of observers? Otherwise it seems as if only one client would be notified. From nobody Thu Aug 21 07:11:11 2014 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F2411A0337; Thu, 21 Aug 2014 07:11:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2rV-gABDNBKh; Thu, 21 Aug 2014 07:11:04 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 81AFE1A031D; Thu, 21 Aug 2014 07:11:04 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Jari Arkko" To: The IESG X-Test-IDTracker: no X-IETF-IDTracker: 5.6.2.p5 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140821141104.19087.95662.idtracker@ietfa.amsl.com> Date: Thu, 21 Aug 2014 07:11:04 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/core/BXARqyi-leJiD1bDNqpDj1qIQls Cc: ben Campbell , core-chairs@tools.ietf.org, draft-ietf-core-groupcomm@tools.ietf.org, core@ietf.org Subject: [core] Jari Arkko's No Objection on draft-ietf-core-groupcomm-21: (with COMMENT) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Aug 2014 14:11:07 -0000 Jari Arkko has entered the following ballot position for draft-ietf-core-groupcomm-21: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-ietf-core-groupcomm/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thank you for writing this document on this important topic. Iit is indeed something that many users of CoAP technology are wondering about. For context, the comments below are based on the in-depth Gen-ART review for this document, by Ben Campbell - thank you! I have also read the document myself. I have also implemented multicast-based functionality for CoAP devices. The document contains a lot very useful material. I do agree though with Ben and my esteemed Area Director colleagues who have raised Discusses: the document would be better classified as Experimental at this stage. The re-classification though is something that the IESG can easily do. But Martin and Ben, for instance, have provided additional useful suggestions on how to change the text itself; some changes are also necessary in my opinion. A few more detailed comments. These are provided as-is, in the hopes that they are useful. At this moment I have no specific Discuss-level requirements for the draft, mainly because Brian and Martin already hold Discusses that I would have otherwise held. all.bldg6.example.com "all nodes in building 6" all.west.bldg6.example.com "all nodes in west wing, I have found that it is often useful to separate communications addressing and grouping from conceptual or application-specific grouping. The gathering of nodes in a group - and the design of a network to subnets - should be done based on communications convenience and efficiency, but it should not necessarily dictate all application-level groups that may be needed. To do so might in some cases lead to inflexibility and undue constraints on the network design. It may not be convenient to put all nodes in building 6 in one group, for instance, for various reasons. I would like to advocate a two-level approach, multicast for efficient reachability, but the application decisions are still based on information about the resources (such as location), rather than who answered a particular query on this multicast address. This also makes it easy to perform queries of any complexity in a reasonable manner, e.g., "all sensors that have a reading higher than 27C". The non-idempotent CoAP method, POST, may only be used for group communication if the resource being POSTed to has been designed to cope with the unreliable and lossy nature of IP multicast. This is certainly possible, and in my experience, very useful. The document would be most helpful if it could provide more guidance regarding when a design is safe for use of POST. In the third case, typical in scenarios such as building control, a dynamic commissioning tool determines to which group a sensor or actuator node belongs, and writes this information to the node, which Please make sure the document recognises the possibility that a device may simultaneously belong to multiple groups. Also, a form of authorization (making use of DTLS-secured CoAP [RFC7252]) MUST be used such that only authorized controllers are allowed by an endpoint to configure its group membership. Is this "MUST use a form, e.g., DTLS" or "MUST use DTLS, a form"? I'd advocate the former... o A server should not accept an IP multicast request that cannot be "authenticated" in some way (cryptographically or by some multicast boundary limiting the potential sources) [RFC7252]. See Section 5.3 for examples of multicast boundary limiting methods. It is difficult for a server to know what boundary limitations may be in place in other devices around it. 2.9. Congestion Control This section talks mainly about what the servers should do. There is only one rule about clients. Perhaps some additional guidance for the frequency that clients can send multicast requests would be advisable, unless it is already specified somewhere else. 3. Use Cases and Corresponding Protocol Flows 3.1. Introduction I would have thought discovery of devices in the other direction, i.e., a GET ./well-kown to all-coap-nodes would have been an interesting use case as well. 5. Security Considerations I'm looking in particular at Sections 5.1 through 5.3. I'd like to say that I have had very positive experiences about using group communication with data object security, which is quite a lot better suited for group communication than transport layer solutions. No individual channels have to be established with the many group members. Messages can be signed with the authority of the sender rather than tying the security to the receiver. Forwarding through intermediaries retains security properties. And so on. Perhaps this alternative should be mentioned. Indeed, other than for low-security applications such as discovering network components, it is difficult to imagine completely unsecured operation, particularly considering that many if not most networks have a multitude of different devices in them, and it is not in my opinion a workable long-term solution to assume a firewall-based security model. 8. References The group communication draft does not mention the observe draft, and the observe draft does not mention multicast. Are there any feature interaction issues that you might want to cover? From nobody Thu Aug 21 07:11:50 2014 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3A051A032A; Thu, 21 Aug 2014 07:11:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gv7wnHX2YN-8; Thu, 21 Aug 2014 07:11:38 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 60F451A6FA3; Thu, 21 Aug 2014 07:11:22 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Jari Arkko" To: The IESG X-Test-IDTracker: no X-IETF-IDTracker: 5.6.2.p5 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140821141122.30374.71963.idtracker@ietfa.amsl.com> Date: Thu, 21 Aug 2014 07:11:22 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/core/UHZHyetkLhOowbNcf0h0KX5PI_M Cc: core-chairs@tools.ietf.org, draft-ietf-core-groupcomm@tools.ietf.org, core@ietf.org Subject: [core] Jari Arkko's No Objection on draft-ietf-core-groupcomm-21: (with COMMENT) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Aug 2014 14:11:45 -0000 Jari Arkko has entered the following ballot position for draft-ietf-core-groupcomm-21: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-ietf-core-groupcomm/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thank you for writing this document on this important topic. Iit is indeed something that many users of CoAP technology are wondering about. For context, the comments below are based on the in-depth Gen-ART review for this document, by Ben Campbell - thank you! I have also read the document myself. I have also implemented multicast-based functionality for CoAP devices. The document contains a lot very useful material. I do agree though with Ben and my esteemed Area Director colleagues who have raised Discusses: the document would be better classified as Experimental at this stage. The re-classification though is something that the IESG can easily do. But Martin and Ben, for instance, have provided additional useful suggestions on how to change the text itself; some changes are also necessary in my opinion. A few more detailed comments. These are provided as-is, in the hopes that they are useful. At this moment I have no specific Discuss-level requirements for the draft, mainly because Brian and Martin already hold Discusses that I would have otherwise held. all.bldg6.example.com "all nodes in building 6" all.west.bldg6.example.com "all nodes in west wing, I have found that it is often useful to separate communications addressing and grouping from conceptual or application-specific grouping. The gathering of nodes in a group - and the design of a network to subnets - should be done based on communications convenience and efficiency, but it should not necessarily dictate all application-level groups that may be needed. To do so might in some cases lead to inflexibility and undue constraints on the network design. It may not be convenient to put all nodes in building 6 in one group, for instance, for various reasons. I would like to advocate a two-level approach, multicast for efficient reachability, but the application decisions are still based on information about the resources (such as location), rather than who answered a particular query on this multicast address. This also makes it easy to perform queries of any complexity in a reasonable manner, e.g., "all sensors that have a reading higher than 27C". The non-idempotent CoAP method, POST, may only be used for group communication if the resource being POSTed to has been designed to cope with the unreliable and lossy nature of IP multicast. This is certainly possible, and in my experience, very useful. The document would be most helpful if it could provide more guidance regarding when a design is safe for use of POST. In the third case, typical in scenarios such as building control, a dynamic commissioning tool determines to which group a sensor or actuator node belongs, and writes this information to the node, which Please make sure the document recognises the possibility that a device may simultaneously belong to multiple groups. Also, a form of authorization (making use of DTLS-secured CoAP [RFC7252]) MUST be used such that only authorized controllers are allowed by an endpoint to configure its group membership. Is this "MUST use a form, e.g., DTLS" or "MUST use DTLS, a form"? I'd advocate the former... o A server should not accept an IP multicast request that cannot be "authenticated" in some way (cryptographically or by some multicast boundary limiting the potential sources) [RFC7252]. See Section 5.3 for examples of multicast boundary limiting methods. It is difficult for a server to know what boundary limitations may be in place in other devices around it. 2.9. Congestion Control This section talks mainly about what the servers should do. There is only one rule about clients. Perhaps some additional guidance for the frequency that clients can send multicast requests would be advisable, unless it is already specified somewhere else. 3. Use Cases and Corresponding Protocol Flows 3.1. Introduction I would have thought discovery of devices in the other direction, i.e., a GET ./well-kown to all-coap-nodes would have been an interesting use case as well. 5. Security Considerations I'm looking in particular at Sections 5.1 through 5.3. I'd like to say that I have had very positive experiences about using group communication with data object security, which is quite a lot better suited for group communication than transport layer solutions. No individual channels have to be established with the many group members. Messages can be signed with the authority of the sender rather than tying the security to the receiver. Forwarding through intermediaries retains security properties. And so on. Perhaps this alternative should be mentioned. Indeed, other than for low-security applications such as discovering network components, it is difficult to imagine completely unsecured operation, particularly considering that many if not most networks have a multitude of different devices in them, and it is not in my opinion a workable long-term solution to assume a firewall-based security model. 8. References The group communication draft does not mention the observe draft, and the observe draft does not mention multicast. Are there any feature interaction issues that you might want to cover? From nobody Thu Aug 21 07:19:14 2014 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CAED1A0300 for ; Thu, 21 Aug 2014 07:19:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.568 X-Spam-Level: X-Spam-Status: No, score=-2.568 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.668] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z5cSIMlPBQd9 for ; Thu, 21 Aug 2014 07:19:09 -0700 (PDT) Received: from smtp-in1.interdigital.com (smtp-in1.interdigital.com [64.208.228.133]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8F2C61A0339 for ; Thu, 21 Aug 2014 07:19:09 -0700 (PDT) X-ASG-Debug-ID: 1408630747-06daaa2edc0a390001-aa7cYp Received: from smtp-out1.interdigital.com (sahara.interdigital.com [10.0.128.27]) by smtp-in1.interdigital.com with ESMTP id Xp7BtOzvBFnjYBRE; Thu, 21 Aug 2014 10:19:07 -0400 (EDT) X-Barracuda-Envelope-From: Akbar.Rahman@InterDigital.com Received: from SAM.InterDigital.com ([10.30.2.11]) by smtp-out1.interdigital.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 21 Aug 2014 10:19:07 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 Date: Thu, 21 Aug 2014 10:18:41 -0400 X-ASG-Orig-Subj: RE: Jari Arkko's No Objection on draft-ietf-core-groupcomm-21: (with COMMENT) Message-ID: In-Reply-To: <20140821141122.30374.71963.idtracker@ietfa.amsl.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Jari Arkko's No Objection on draft-ietf-core-groupcomm-21: (with COMMENT) Thread-Index: Ac+9Se6K8UxsNVcsTtWxOmMjsaeXoQAAGBvg References: <20140821141122.30374.71963.idtracker@ietfa.amsl.com> From: "Rahman, Akbar" To: "Jari Arkko" , "The IESG" X-OriginalArrivalTime: 21 Aug 2014 14:19:07.0475 (UTC) FILETIME=[DE793A30:01CFBD4A] X-Barracuda-Connect: sahara.interdigital.com[10.0.128.27] X-Barracuda-Start-Time: 1408630747 X-Barracuda-URL: http://10.1.245.3:8000/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at interdigital.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=9.0 tests=BSF_SC0_MISMATCH_TO X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.8689 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 BSF_SC0_MISMATCH_TO Envelope rcpt doesn't match header Archived-At: http://mailarchive.ietf.org/arch/msg/core/uU-Nke27ocbMtFJLdKNW5Kkairc Cc: core-chairs@tools.ietf.org, draft-ietf-core-groupcomm@tools.ietf.org, core@ietf.org Subject: Re: [core] Jari Arkko's No Objection on draft-ietf-core-groupcomm-21: (with COMMENT) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Aug 2014 14:19:12 -0000 SGkgSmFyaSwNCg0KDQpUaGFuayB5b3UgdmVyeSBtdWNoIGZvciB0aGUgcmV2aWV3Lg0KDQoNCj50 aGUgZG9jdW1lbnQgd291bGQgYmUgYmV0dGVyIGNsYXNzaWZpZWQgYXMgRXhwZXJpbWVudGFsIGF0 IHRoaXMgc3RhZ2UuIFRoZSByZS1jbGFzc2lmaWNhdGlvbiB0aG91Z2ggaXMgc29tZXRoaW5nIHRo YXQgdGhlIElFU0cgY2FuIGVhc2lseSBkby4NCg0KWWVzLCB0aGlzIHNlZW1zIGxpa2UgYSBnb29k IHdheSBmb3J3YXJkIHRvIHByZXNlcnZlIHRoZSBpbmZvcm1hdGlvbiBpbiB0aGUgZHJhZnQgYW5k IGFsc28gbWFrZSBjbGVhciB0byByZWFkZXJzIHRoZSBzdGF0dXMgb2YgdGhlIHRlY2hub2xvZ3ku DQoNCg0KPkJ1dCBNYXJ0aW4gYW5kIEJlbiwgZm9yIGluc3RhbmNlLCBoYXZlIHByb3ZpZGVkIGFk ZGl0aW9uYWwgdXNlZnVsIHN1Z2dlc3Rpb25zIG9uIGhvdyB0byBjaGFuZ2UgdGhlIHRleHQgaXRz ZWxmOyBzb21lIGNoYW5nZXMgYXJlIGFsc28gbmVjZXNzYXJ5IGluIG15IG9waW5pb24uDQoNCkkg d2lsbCB3b3JrIHdpdGggbXkgY28tYXV0aG9yLCBFc2tvLCB0byB0cnkgdG8gYW5zd2VyIGFsbCB0 aGUgb3BlbiBpc3N1ZXMgYnkgKGFwcHJveGltYXRlbHkpIGVuZCBvZiBuZXh0IHdlZWsuICBJIGhv cGUgdGhhdCB0aGlzIGlzIGFjY2VwdGFibGUgdG8gZXZlcnlvbmUuDQoNCg0KDQoNCkJlc3QgUmVn YXJkcywNCg0KDQpBa2Jhcg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogSmFy aSBBcmtrbyBbbWFpbHRvOmphcmkuYXJra29AcGl1aGEubmV0XSANClNlbnQ6IFRodXJzZGF5LCBB dWd1c3QgMjEsIDIwMTQgMTA6MTEgQU0NClRvOiBUaGUgSUVTRw0KQ2M6IGNvcmUtY2hhaXJzQHRv b2xzLmlldGYub3JnOyBkcmFmdC1pZXRmLWNvcmUtZ3JvdXBjb21tQHRvb2xzLmlldGYub3JnOyBj b3JlQGlldGYub3JnDQpTdWJqZWN0OiBKYXJpIEFya2tvJ3MgTm8gT2JqZWN0aW9uIG9uIGRyYWZ0 LWlldGYtY29yZS1ncm91cGNvbW0tMjE6ICh3aXRoIENPTU1FTlQpDQoNCkphcmkgQXJra28gaGFz IGVudGVyZWQgdGhlIGZvbGxvd2luZyBiYWxsb3QgcG9zaXRpb24gZm9yDQpkcmFmdC1pZXRmLWNv cmUtZ3JvdXBjb21tLTIxOiBObyBPYmplY3Rpb24NCg0KV2hlbiByZXNwb25kaW5nLCBwbGVhc2Ug a2VlcCB0aGUgc3ViamVjdCBsaW5lIGludGFjdCBhbmQgcmVwbHkgdG8gYWxsIGVtYWlsIGFkZHJl c3NlcyBpbmNsdWRlZCBpbiB0aGUgVG8gYW5kIENDIGxpbmVzLiAoRmVlbCBmcmVlIHRvIGN1dCB0 aGlzIGludHJvZHVjdG9yeSBwYXJhZ3JhcGgsIGhvd2V2ZXIuKQ0KDQoNClBsZWFzZSByZWZlciB0 byBodHRwOi8vd3d3LmlldGYub3JnL2llc2cvc3RhdGVtZW50L2Rpc2N1c3MtY3JpdGVyaWEuaHRt bA0KZm9yIG1vcmUgaW5mb3JtYXRpb24gYWJvdXQgSUVTRyBESVNDVVNTIGFuZCBDT01NRU5UIHBv c2l0aW9ucy4NCg0KDQpUaGUgZG9jdW1lbnQsIGFsb25nIHdpdGggb3RoZXIgYmFsbG90IHBvc2l0 aW9ucywgY2FuIGJlIGZvdW5kIGhlcmU6DQpodHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9j L2RyYWZ0LWlldGYtY29yZS1ncm91cGNvbW0vDQoNCg0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpDT01NRU5U Og0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLQ0KDQpUaGFuayB5b3UgZm9yIHdyaXRpbmcgdGhpcyBkb2N1bWVudCBv biB0aGlzIGltcG9ydGFudCB0b3BpYy4gSWl0IGlzIGluZGVlZCBzb21ldGhpbmcgdGhhdCBtYW55 IHVzZXJzIG9mIENvQVAgdGVjaG5vbG9neSBhcmUgd29uZGVyaW5nIGFib3V0Lg0KDQpGb3IgY29u dGV4dCwgdGhlIGNvbW1lbnRzIGJlbG93IGFyZSBiYXNlZCBvbiB0aGUgaW4tZGVwdGggR2VuLUFS VCByZXZpZXcgZm9yIHRoaXMgZG9jdW1lbnQsIGJ5IEJlbiBDYW1wYmVsbCAtIHRoYW5rIHlvdSEg SSBoYXZlIGFsc28gcmVhZCB0aGUgZG9jdW1lbnQgbXlzZWxmLiBJIGhhdmUgYWxzbyBpbXBsZW1l bnRlZCBtdWx0aWNhc3QtYmFzZWQgZnVuY3Rpb25hbGl0eSBmb3IgQ29BUCBkZXZpY2VzLg0KDQpU aGUgZG9jdW1lbnQgY29udGFpbnMgYSBsb3QgdmVyeSB1c2VmdWwgbWF0ZXJpYWwuIEkgZG8gYWdy ZWUgdGhvdWdoIHdpdGggQmVuIGFuZCBteSBlc3RlZW1lZCBBcmVhIERpcmVjdG9yIGNvbGxlYWd1 ZXMgd2hvIGhhdmUgcmFpc2VkIERpc2N1c3NlczoNCnRoZSBkb2N1bWVudCB3b3VsZCBiZSBiZXR0 ZXIgY2xhc3NpZmllZCBhcyBFeHBlcmltZW50YWwgYXQgdGhpcyBzdGFnZS4NClRoZSByZS1jbGFz c2lmaWNhdGlvbiB0aG91Z2ggaXMgc29tZXRoaW5nIHRoYXQgdGhlIElFU0cgY2FuIGVhc2lseSBk by4NCkJ1dCBNYXJ0aW4gYW5kIEJlbiwgZm9yIGluc3RhbmNlLCBoYXZlIHByb3ZpZGVkIGFkZGl0 aW9uYWwgdXNlZnVsIHN1Z2dlc3Rpb25zIG9uIGhvdyB0byBjaGFuZ2UgdGhlIHRleHQgaXRzZWxm OyBzb21lIGNoYW5nZXMgYXJlIGFsc28gbmVjZXNzYXJ5IGluIG15IG9waW5pb24uDQoNCkEgZmV3 IG1vcmUgZGV0YWlsZWQgY29tbWVudHMuIFRoZXNlIGFyZSBwcm92aWRlZCBhcy1pcywgaW4gdGhl IGhvcGVzIHRoYXQgdGhleSBhcmUgdXNlZnVsLiBBdCB0aGlzIG1vbWVudCBJIGhhdmUgbm8gc3Bl Y2lmaWMgRGlzY3Vzcy1sZXZlbCByZXF1aXJlbWVudHMgZm9yIHRoZSBkcmFmdCwgbWFpbmx5IGJl Y2F1c2UgQnJpYW4gYW5kIE1hcnRpbiBhbHJlYWR5IGhvbGQgRGlzY3Vzc2VzIHRoYXQgSSB3b3Vs ZCBoYXZlIG90aGVyd2lzZSBoZWxkLg0KDQogICAgIGFsbC5ibGRnNi5leGFtcGxlLmNvbSAgICAg ICAgICAgICAgICAgICAiYWxsIG5vZGVzIGluIGJ1aWxkaW5nIDYiDQogICAgIGFsbC53ZXN0LmJs ZGc2LmV4YW1wbGUuY29tICAgICAgICAgICAgICAiYWxsIG5vZGVzIGluIHdlc3Qgd2luZywNCiAN CkkgaGF2ZSBmb3VuZCB0aGF0IGl0IGlzIG9mdGVuIHVzZWZ1bCB0byBzZXBhcmF0ZSBjb21tdW5p Y2F0aW9ucyBhZGRyZXNzaW5nIGFuZCBncm91cGluZyBmcm9tIGNvbmNlcHR1YWwgb3IgYXBwbGlj YXRpb24tc3BlY2lmaWMgZ3JvdXBpbmcuDQpUaGUgZ2F0aGVyaW5nIG9mIG5vZGVzIGluIGEgZ3Jv dXAgLSBhbmQgdGhlIGRlc2lnbiBvZiBhIG5ldHdvcmsgdG8gc3VibmV0cyAtIHNob3VsZCBiZSBk b25lIGJhc2VkIG9uIGNvbW11bmljYXRpb25zIGNvbnZlbmllbmNlIGFuZCBlZmZpY2llbmN5LCBi dXQgaXQgc2hvdWxkIG5vdCBuZWNlc3NhcmlseSBkaWN0YXRlIGFsbCBhcHBsaWNhdGlvbi1sZXZl bCBncm91cHMgdGhhdCBtYXkgYmUgbmVlZGVkLiBUbyBkbyBzbyBtaWdodCBpbiBzb21lIGNhc2Vz IGxlYWQgdG8gaW5mbGV4aWJpbGl0eSBhbmQgdW5kdWUgY29uc3RyYWludHMgb24gdGhlIG5ldHdv cmsgZGVzaWduLiBJdCBtYXkgbm90IGJlIGNvbnZlbmllbnQgdG8gcHV0IGFsbCBub2RlcyBpbiBi dWlsZGluZyA2IGluIG9uZSBncm91cCwgZm9yIGluc3RhbmNlLCBmb3IgdmFyaW91cyByZWFzb25z LiBJIHdvdWxkIGxpa2UgdG8gYWR2b2NhdGUgYSB0d28tbGV2ZWwgYXBwcm9hY2gsIG11bHRpY2Fz dCBmb3IgZWZmaWNpZW50IHJlYWNoYWJpbGl0eSwgYnV0IHRoZSBhcHBsaWNhdGlvbiBkZWNpc2lv bnMgYXJlIHN0aWxsIGJhc2VkIG9uIGluZm9ybWF0aW9uIGFib3V0IHRoZSByZXNvdXJjZXMgKHN1 Y2ggYXMgbG9jYXRpb24pLCByYXRoZXIgdGhhbiB3aG8gYW5zd2VyZWQgIGEgcGFydGljdWxhciBx dWVyeSBvbiB0aGlzIG11bHRpY2FzdCBhZGRyZXNzLiBUaGlzIGFsc28gbWFrZXMgaXQgZWFzeSB0 byBwZXJmb3JtIHF1ZXJpZXMgIG9mIGFueSBjb21wbGV4aXR5IGluIGEgcmVhc29uYWJsZSBtYW5u ZXIsIGUuZy4sICJhbGwgc2Vuc29ycyB0aGF0IGhhdmUgYSByZWFkaW5nIGhpZ2hlciB0aGFuIDI3 QyIuDQoNCiAgIFRoZSBub24taWRlbXBvdGVudCBDb0FQIG1ldGhvZCwgUE9TVCwgbWF5IG9ubHkN CiAgIGJlIHVzZWQgZm9yIGdyb3VwIGNvbW11bmljYXRpb24gaWYgdGhlIHJlc291cmNlIGJlaW5n IFBPU1RlZCB0byBoYXMNCiAgIGJlZW4gZGVzaWduZWQgdG8gY29wZSB3aXRoIHRoZSB1bnJlbGlh YmxlIGFuZCBsb3NzeSBuYXR1cmUgb2YgSVANCiAgIG11bHRpY2FzdC4NCg0KVGhpcyBpcyBjZXJ0 YWlubHkgcG9zc2libGUsIGFuZCBpbiBteSBleHBlcmllbmNlLCB2ZXJ5IHVzZWZ1bC4gVGhlIGRv Y3VtZW50IHdvdWxkIGJlICBtb3N0IGhlbHBmdWwgaWYgaXQgY291bGQgcHJvdmlkZSBtb3JlIGd1 aWRhbmNlIHJlZ2FyZGluZyB3aGVuIGEgZGVzaWduIGlzIHNhZmUgZm9yIHVzZSBvZiBQT1NULg0K DQogICBJbiB0aGUgdGhpcmQgY2FzZSwgdHlwaWNhbCBpbiBzY2VuYXJpb3Mgc3VjaCBhcyBidWls ZGluZyBjb250cm9sLCBhDQogICBkeW5hbWljIGNvbW1pc3Npb25pbmcgdG9vbCBkZXRlcm1pbmVz IHRvIHdoaWNoIGdyb3VwIGEgc2Vuc29yIG9yDQogICBhY3R1YXRvciBub2RlIGJlbG9uZ3MsIGFu ZCB3cml0ZXMgdGhpcyBpbmZvcm1hdGlvbiB0byB0aGUgbm9kZSwgd2hpY2gNCg0KUGxlYXNlIG1h a2Ugc3VyZSB0aGUgZG9jdW1lbnQgcmVjb2duaXNlcyB0aGUgcG9zc2liaWxpdHkgdGhhdCBhIGRl dmljZSBtYXkgc2ltdWx0YW5lb3VzbHkgYmVsb25nIHRvIG11bHRpcGxlIGdyb3Vwcy4NCg0KICAg QWxzbywgYSBmb3JtIG9mIGF1dGhvcml6YXRpb24gKG1ha2luZyB1c2Ugb2YgRFRMUy1zZWN1cmVk IENvQVANCiAgIFtSRkM3MjUyXSkgTVVTVCBiZSB1c2VkIHN1Y2ggdGhhdCBvbmx5IGF1dGhvcml6 ZWQgY29udHJvbGxlcnMgYXJlDQogICBhbGxvd2VkIGJ5IGFuIGVuZHBvaW50IHRvIGNvbmZpZ3Vy ZSBpdHMgZ3JvdXAgbWVtYmVyc2hpcC4NCg0KSXMgdGhpcyAiTVVTVCB1c2UgYSBmb3JtLCBlLmcu LCBEVExTIiBvciAiTVVTVCB1c2UgRFRMUywgYSBmb3JtIj8gSSdkIGFkdm9jYXRlIHRoZSBmb3Jt ZXIuLi4NCg0KICAgbyAgQSBzZXJ2ZXIgc2hvdWxkIG5vdCBhY2NlcHQgYW4gSVAgbXVsdGljYXN0 IHJlcXVlc3QgdGhhdCBjYW5ub3QgYmUNCiAgICAgICJhdXRoZW50aWNhdGVkIiBpbiBzb21lIHdh eSAoY3J5cHRvZ3JhcGhpY2FsbHkgb3IgYnkgc29tZQ0KICAgICAgbXVsdGljYXN0IGJvdW5kYXJ5 IGxpbWl0aW5nIHRoZSBwb3RlbnRpYWwgc291cmNlcykgW1JGQzcyNTJdLiAgU2VlDQogICAgICBT ZWN0aW9uIDUuMyBmb3IgZXhhbXBsZXMgb2YgbXVsdGljYXN0IGJvdW5kYXJ5IGxpbWl0aW5nIG1l dGhvZHMuDQoNCkl0IGlzIGRpZmZpY3VsdCBmb3IgYSBzZXJ2ZXIgdG8ga25vdyB3aGF0IGJvdW5k YXJ5IGxpbWl0YXRpb25zIG1heSBiZSBpbiBwbGFjZSBpbiBvdGhlciBkZXZpY2VzIGFyb3VuZCBp dC4NCg0KICAyLjkuICBDb25nZXN0aW9uIENvbnRyb2wNCg0KVGhpcyBzZWN0aW9uIHRhbGtzIG1h aW5seSBhYm91dCB3aGF0IHRoZSBzZXJ2ZXJzIHNob3VsZCBkby4gVGhlcmUgaXMgb25seSBvbmUg cnVsZSBhYm91dCBjbGllbnRzLiBQZXJoYXBzIHNvbWUgYWRkaXRpb25hbCBndWlkYW5jZSBmb3Ig dGhlIGZyZXF1ZW5jeSB0aGF0IGNsaWVudHMgY2FuIHNlbmQgbXVsdGljYXN0IHJlcXVlc3RzIHdv dWxkIGJlIGFkdmlzYWJsZSwgdW5sZXNzIGl0IGlzIGFscmVhZHkgc3BlY2lmaWVkIHNvbWV3aGVy ZSBlbHNlLg0KDQogIDMuICBVc2UgQ2FzZXMgYW5kIENvcnJlc3BvbmRpbmcgUHJvdG9jb2wgRmxv d3MNCg0KICAzLjEuICBJbnRyb2R1Y3Rpb24NCg0KSSB3b3VsZCBoYXZlIHRob3VnaHQgZGlzY292 ZXJ5IG9mIGRldmljZXMgaW4gdGhlIG90aGVyIGRpcmVjdGlvbiwgaS5lLiwgYSBHRVQgLi93ZWxs LWtvd24gIHRvIGFsbC1jb2FwLW5vZGVzIHdvdWxkIGhhdmUgYmVlbiBhbiBpbnRlcmVzdGluZyB1 c2UgY2FzZSBhcyB3ZWxsLg0KDQogIDUuICBTZWN1cml0eSBDb25zaWRlcmF0aW9ucw0KDQpJJ20g bG9va2luZyBpbiBwYXJ0aWN1bGFyIGF0IFNlY3Rpb25zIDUuMSB0aHJvdWdoIDUuMy4gSSdkIGxp a2UgdG8gc2F5IHRoYXQgSSBoYXZlIGhhZCB2ZXJ5IHBvc2l0aXZlIGV4cGVyaWVuY2VzIGFib3V0 IHVzaW5nIGdyb3VwIGNvbW11bmljYXRpb24gd2l0aCBkYXRhIG9iamVjdCBzZWN1cml0eSwgd2hp Y2ggaXMgcXVpdGUgYSBsb3QgYmV0dGVyIHN1aXRlZCBmb3IgZ3JvdXAgY29tbXVuaWNhdGlvbiB0 aGFuIHRyYW5zcG9ydCBsYXllciBzb2x1dGlvbnMuIE5vIGluZGl2aWR1YWwgY2hhbm5lbHMgaGF2 ZSB0byBiZSBlc3RhYmxpc2hlZCB3aXRoIHRoZSBtYW55IGdyb3VwIG1lbWJlcnMuIE1lc3NhZ2Vz IGNhbiBiZSBzaWduZWQgd2l0aCB0aGUgYXV0aG9yaXR5IG9mIHRoZSBzZW5kZXIgcmF0aGVyIHRo YW4gdHlpbmcgdGhlIHNlY3VyaXR5IHRvIHRoZSByZWNlaXZlci4gRm9yd2FyZGluZyB0aHJvdWdo IGludGVybWVkaWFyaWVzIHJldGFpbnMgc2VjdXJpdHkgcHJvcGVydGllcy4NCkFuZCBzbyBvbi4g DQoNClBlcmhhcHMgdGhpcyBhbHRlcm5hdGl2ZSBzaG91bGQgYmUgbWVudGlvbmVkLiBJbmRlZWQs IG90aGVyIHRoYW4gZm9yIGxvdy1zZWN1cml0eSBhcHBsaWNhdGlvbnMgc3VjaCBhcyBkaXNjb3Zl cmluZyBuZXR3b3JrIGNvbXBvbmVudHMsIGl0IGlzIGRpZmZpY3VsdCB0byBpbWFnaW5lIGNvbXBs ZXRlbHkgdW5zZWN1cmVkIG9wZXJhdGlvbiwgcGFydGljdWxhcmx5IGNvbnNpZGVyaW5nIHRoYXQg bWFueSBpZiBub3QgbW9zdCBuZXR3b3JrcyBoYXZlIGEgbXVsdGl0dWRlIG9mIGRpZmZlcmVudCBk ZXZpY2VzIGluIHRoZW0sIGFuZCBpdCBpcyBub3QgaW4gbXkgb3BpbmlvbiBhIHdvcmthYmxlIGxv bmctdGVybSBzb2x1dGlvbiB0byBhc3N1bWUgYSBmaXJld2FsbC1iYXNlZCBzZWN1cml0eSBtb2Rl bC4NCg0KICA4LiAgUmVmZXJlbmNlcw0KDQpUaGUgZ3JvdXAgY29tbXVuaWNhdGlvbiBkcmFmdCBk b2VzIG5vdCBtZW50aW9uIHRoZSBvYnNlcnZlIGRyYWZ0LCBhbmQgdGhlIG9ic2VydmUgZHJhZnQg ZG9lcyBub3QgbWVudGlvbiBtdWx0aWNhc3QuIEFyZSB0aGVyZSBhbnkgZmVhdHVyZSBpbnRlcmFj dGlvbiBpc3N1ZXMgdGhhdCB5b3UgbWlnaHQgd2FudCB0byBjb3Zlcj8NCg0KDQo= From nobody Thu Aug 21 07:27:16 2014 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BB071A02F1; Thu, 21 Aug 2014 07:27:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XbHpOm8RjLR3; Thu, 21 Aug 2014 07:27:06 -0700 (PDT) Received: from mail-lb0-x232.google.com (mail-lb0-x232.google.com [IPv6:2a00:1450:4010:c04::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1D9351A035D; Thu, 21 Aug 2014 07:27:05 -0700 (PDT) Received: by mail-lb0-f178.google.com with SMTP id c11so8286574lbj.9 for ; Thu, 21 Aug 2014 07:27:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=nOuCx8JmZh+9Q413LFFkMor3qu6rlvMD3xL2y1XlbRU=; b=yVDxAO50G+OXZEaDrPHTEv2JAhptyqvuji5EYIT+ISI07XZkj1elWId+eZ+YXTPRKI 7ofBOo7ZQ0EF+jFMU6PDcFvwMtDmscKoS9CqHhezTwiX9dQt1MZdsB1UeAZ+PSQX+/T9 Rd6wMp5cLAGFhKVjOxiCK2XrXO6Hjy8oeV/EFpf1qELygnattwB+TNvpwLZ7OctgzSEs s/P1586MWg2ydO1RlXjzWhLvQrVMQQNc44u44QuGF2z8zneNNNrXFE7WGGK+VddAa9fZ EMqjuwBY9h5zQnOmSDj4JEpvwNn5Kw7BI7Ptdkd6p2oLuhO26BLHdi/eEzdN4ADtkmW3 HpZw== MIME-Version: 1.0 X-Received: by 10.152.45.8 with SMTP id i8mr49047404lam.3.1408631224455; Thu, 21 Aug 2014 07:27:04 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.152.8.46 with HTTP; Thu, 21 Aug 2014 07:27:04 -0700 (PDT) In-Reply-To: <20140821121434.26081.28936.idtracker@ietfa.amsl.com> References: <20140821121434.26081.28936.idtracker@ietfa.amsl.com> Date: Thu, 21 Aug 2014 10:27:04 -0400 X-Google-Sender-Auth: p0iyczT_4ak7Qt0UklDfvXuXsGI Message-ID: From: Barry Leiba To: Pete Resnick Content-Type: text/plain; charset=ISO-8859-1 Archived-At: http://mailarchive.ietf.org/arch/msg/core/33nHoPERYUpZCCktYO3bxJk_shc Cc: "core-chairs@tools.ietf.org" , The IESG , core WG , draft-ietf-core-groupcomm@tools.ietf.org Subject: Re: [core] Pete Resnick's No Objection on draft-ietf-core-groupcomm-21: (with COMMENT) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Aug 2014 14:27:07 -0000 > 2.8: These normative behaviors and guidelines look like they could use > 2119 keywords. In particular, quite a few of those "should not"s look > like they are meant as "SHOULD NOT"s. They obviously don't need to be, > but I was wondering if there was something I was missing. That was actually due to my push-back: earlier versions had too much SHOULD/SHOULD NOT, and used some of them in ways I thought were inappropriate. The authors chose to resolve that by taking all the 2119 key words out of 2.8 and 2.9 entirely. I thought that was farther than they needed to go, but that it didn't make the result incorrect, so I accepted it. Barry From nobody Thu Aug 21 07:39:39 2014 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BD0E1A8963; Thu, 21 Aug 2014 07:39:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.669 X-Spam-Level: X-Spam-Status: No, score=-7.669 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4fJLkushei1k; Thu, 21 Aug 2014 07:39:35 -0700 (PDT) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CD6361A0334; Thu, 21 Aug 2014 07:39:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1408631975; x=1440167975; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=fXWWETVYwuJCCQZfAzygeT52L0WWYfLR3VsYWTsUUOg=; b=SVIcjXZho0YXHp46tVpyxXXDarMlDklIfdW8jToIMgpAp/UJBeEeLh9K ybH7jfSEPWbboCqrnfi42VljgmpxXrkGDvFTfXyDHTFs7w/Pszk54XnNC akc2stbbUSfSVOmllcgRwVzJxnVlwOn//6K2E4XnAs++Cdgo2FK1cfB+8 8=; X-IronPort-AV: E=McAfee;i="5600,1067,7536"; a="59577387" Received: from ironmsg04-r.qualcomm.com ([172.30.46.18]) by wolverine01.qualcomm.com with ESMTP; 21 Aug 2014 07:39:28 -0700 X-IronPort-AV: E=Sophos;i="5.01,909,1400050800"; d="scan'208";a="789197811" Received: from nasanexhc04.na.qualcomm.com ([172.30.48.17]) by Ironmsg04-R.qualcomm.com with ESMTP/TLS/RC4-SHA; 21 Aug 2014 07:39:28 -0700 Received: from presnick-mac.local (172.30.48.1) by qcmail1.qualcomm.com (172.30.48.17) with Microsoft SMTP Server (TLS) id 14.3.181.6; Thu, 21 Aug 2014 07:39:28 -0700 Message-ID: <53F6049E.8040600@qti.qualcomm.com> Date: Thu, 21 Aug 2014 09:39:26 -0500 From: Pete Resnick User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.7; en-US; rv:1.9.1.9) Gecko/20100630 Eudora/3.0.4 MIME-Version: 1.0 To: Barry Leiba References: <20140821121434.26081.28936.idtracker@ietfa.amsl.com> In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [172.30.48.1] Archived-At: http://mailarchive.ietf.org/arch/msg/core/iRy-PwsefbBTRfA6PTjX26PJ9fs Cc: "core-chairs@tools.ietf.org" , The IESG , core WG , draft-ietf-core-groupcomm@tools.ietf.org Subject: Re: [core] Pete Resnick's No Objection on draft-ietf-core-groupcomm-21: (with COMMENT) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Aug 2014 14:39:37 -0000 On 8/21/14 9:27 AM, Barry Leiba wrote: >> 2.8: These normative behaviors and guidelines look like they could use >> 2119 keywords. In particular, quite a few of those "should not"s look >> like they are meant as "SHOULD NOT"s. They obviously don't need to be, >> but I was wondering if there was something I was missing. >> > That was actually due to my push-back: earlier versions had too much > SHOULD/SHOULD NOT, and used some of them in ways I thought were > inappropriate. The authors chose to resolve that by taking all the > 2119 key words out of 2.8 and 2.9 entirely. I thought that was > farther than they needed to go, but that it didn't make the result > incorrect, so I accepted it. > "The AD said something! Quick! Change it!" :-D I agree, there's nothing actively bad about the current text. But if the authors want an excuse to say, "See Barry, I told you we should have more SHOULD NOTs!", I'm there to back you up. ;-) pr -- Pete Resnick Qualcomm Technologies, Inc. - +1 (858)651-4478 From nobody Thu Aug 21 08:15:41 2014 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C95C1A6F0B; Thu, 21 Aug 2014 08:15:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8Svy5SLptDFO; Thu, 21 Aug 2014 08:15:35 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id EC19D1A03CA; Thu, 21 Aug 2014 08:15:31 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Stephen Farrell" To: The IESG X-Test-IDTracker: no X-IETF-IDTracker: 5.6.2.p5 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140821151531.16939.8247.idtracker@ietfa.amsl.com> Date: Thu, 21 Aug 2014 08:15:31 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/core/Nre5kyDkSloeypqVYdh9sT_GNZA Cc: core-chairs@tools.ietf.org, draft-ietf-core-groupcomm@tools.ietf.org, core@ietf.org Subject: [core] Stephen Farrell's No Objection on draft-ietf-core-groupcomm-21: (with COMMENT) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Aug 2014 15:15:37 -0000 Stephen Farrell has entered the following ballot position for draft-ietf-core-groupcomm-21: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-ietf-core-groupcomm/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Sorry, I only had time to quickly scan this. - For a non MC IP addr, how does one know a URI is for a group? - 5.3.3: That draft-keoh draft is quite controversial in the DICE WG. The question there is whether or not its at all sensible to try do group security in the DTLS record layer. I think you really ought recognise that, since its quite possible that a very different solution will be needed in reality. - Thanks for 5.4! I think you should also note that even with encryption providing confidentiality, traffic analysis could be a powerful tool against CoAP and group communication, so future work with CoAP and developers/deployers should also take into account traffic analsyis. To use your fav example, its not hard to detect the lights being turned on or off even if that's done via ciphertext is it? From nobody Thu Aug 21 08:23:51 2014 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0815F1A0362; Thu, 21 Aug 2014 08:23:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N3AY8X0wEFAR; Thu, 21 Aug 2014 08:23:48 -0700 (PDT) Received: from uillean.fuaim.com (uillean.fuaim.com [206.197.161.140]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6CFC21A00C6; Thu, 21 Aug 2014 08:23:48 -0700 (PDT) Received: from clairseach.fuaim.com (clairseach-high.fuaim.com [206.197.161.158]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by uillean.fuaim.com (Postfix) with ESMTP id 493608811E; Thu, 21 Aug 2014 08:23:48 -0700 (PDT) Received: from 10252362.rudm2.ra.johnshopkins.edu (addr16212925014.ippl.jhmi.edu [162.129.250.14]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by clairseach.fuaim.com (Postfix) with ESMTP id B9BF371B0001; Thu, 21 Aug 2014 08:23:47 -0700 (PDT) Message-ID: <53F60F02.9070108@innovationslab.net> Date: Thu, 21 Aug 2014 11:23:46 -0400 From: Brian Haberman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Stephen Farrell , The IESG References: <20140821151531.16939.8247.idtracker@ietfa.amsl.com> In-Reply-To: <20140821151531.16939.8247.idtracker@ietfa.amsl.com> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="pOV8LUhJObRGQu29evLkqJHtba1oSHJEt" Archived-At: http://mailarchive.ietf.org/arch/msg/core/pU0lQFtVVj2qJlwhk-ZniyUtVwg Cc: core-chairs@tools.ietf.org, draft-ietf-core-groupcomm@tools.ietf.org, core@ietf.org Subject: Re: [core] Stephen Farrell's No Objection on draft-ietf-core-groupcomm-21: (with COMMENT) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Aug 2014 15:23:50 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --pOV8LUhJObRGQu29evLkqJHtba1oSHJEt Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 8/21/14 11:15 AM, Stephen Farrell wrote: > Stephen Farrell has entered the following ballot position for > draft-ietf-core-groupcomm-21: No Objection >=20 > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this= > introductory paragraph, however.) >=20 >=20 > Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.htm= l > for more information about IESG DISCUSS and COMMENT positions. >=20 >=20 > The document, along with other ballot positions, can be found here: > http://datatracker.ietf.org/doc/draft-ietf-core-groupcomm/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 >=20 > Sorry, I only had time to quickly scan this.=20 >=20 > - For a non MC IP addr, how does one know a URI is for a > group? >=20 The IP address is in a special range. If you have a domain name, you have to resolve it to the IP address to determine if it falls in the rang= e. Brian --pOV8LUhJObRGQu29evLkqJHtba1oSHJEt Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.20 (Darwin) Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJT9g8HAAoJEBOZRqCi7goqVcQIAMTBCc0GYxu9ZVkdz4uluNZS Rv6Zd2GOaXPZwuo87vohV90w3exOnUkMRDAfYhwy6yDBGkuBC/9hXkU7TomjAPij 8ebc85rdaEgTIYb7gUwmFXY60fH1IkjQ2TIchy+JnFcNkO40QUlbEaxQOKf2TuiQ 78hO2li2YAE24g9Akf8/wQ1kDMNjgOo9ezh+i1YRtMuOKM+fQgHsJsvCB86Fhrwg sMR2qL0NgUZKmHi9/OJ5Vo8zdbT1fjdptotRPqNq9jY4gf+Qlbh24IO6uYDwx6a3 dwJtVPqF1DC/A3cngApkhQb/K416JN21nnf6xfy6s7xTo72EtG5DRrdEQv1HfvU= =GhEL -----END PGP SIGNATURE----- --pOV8LUhJObRGQu29evLkqJHtba1oSHJEt-- From nobody Thu Aug 21 09:33:26 2014 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8AF151A0693 for ; Thu, 21 Aug 2014 09:33:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, TVD_SPACE_RATIO=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GK7TjeulxkAl; Thu, 21 Aug 2014 09:33:22 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6945B1A06C7; Thu, 21 Aug 2014 09:33:17 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: core-chairs@tools.ietf.org, draft-ietf-core-observe@tools.ietf.org, core@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.2.p5 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140821163317.24353.45184.idtracker@ietfa.amsl.com> Date: Thu, 21 Aug 2014 09:33:17 -0700 From: IETF Secretariat Archived-At: http://mailarchive.ietf.org/arch/msg/core/T0T6wizM8EI82lF2nermvCi5FnY Subject: [core] ID Tracker State Update Notice: X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Aug 2014 16:33:23 -0000 IESG state changed to IESG Evaluation::AD Followup from IESG Evaluation ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-core-observe/ From nobody Thu Aug 21 09:43:18 2014 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC51F1A06A3 for ; Thu, 21 Aug 2014 09:43:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CNimE-xrHsdf; Thu, 21 Aug 2014 09:43:16 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BFACE1A04AA; Thu, 21 Aug 2014 09:43:14 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: core-chairs@tools.ietf.org, draft-ietf-core-groupcomm@tools.ietf.org, core@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.2.p5 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140821164314.29242.13149.idtracker@ietfa.amsl.com> Date: Thu, 21 Aug 2014 09:43:14 -0700 From: IETF Secretariat Archived-At: http://mailarchive.ietf.org/arch/msg/core/oBHWS3hhMtUWlJ_OgzfSzE5jDzs Subject: [core] ID Tracker State Update Notice: X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Aug 2014 16:43:18 -0000 IESG state changed to IESG Evaluation::Revised I-D Needed from IESG Evaluation ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-core-groupcomm/ From nobody Thu Aug 21 10:26:29 2014 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2EE271A06D0 for ; Thu, 21 Aug 2014 10:26:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6g2XOCXZ-ZcS for ; Thu, 21 Aug 2014 10:26:18 -0700 (PDT) Received: from mail-la0-x22f.google.com (mail-la0-x22f.google.com [IPv6:2a00:1450:4010:c03::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 356891A06D1 for ; Thu, 21 Aug 2014 10:26:18 -0700 (PDT) Received: by mail-la0-f47.google.com with SMTP id mc6so8837015lab.20 for ; Thu, 21 Aug 2014 10:26:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:content-type; bh=dAv/AUXbwhKKVIhTKb4kSEaxG5K/DZlZicNsrr3e8lw=; b=Tr+KPun6pOy9KjO9i9q86V3APlfveT0fi9ydVT9KDu+dvqkxmYz/lfakHwBCq4MxXC VNpG0t23kKaF8aIllLs2cNP30VAMjcxEUPdgnx89vzX6oaJ3258kOVI8w3BTG/ms49Lh jcWJIHGFghAbwY6lyxLGzshtbD+RIHJMLvk/haNaDqdmYLTvf7iiKu392gczDqRK/JML fsFIlyv1TAt5q1RvD1avfJ+fJVzLD6yOpcXmCKdy7JmqPoD9f+rihxqCZ4k+lmPO4hFc y7IEOZ02h2Ml/Qox2LJF82NCABhX6iHjM38gGfxbeVfdBHty7krh4A19nEDWsXDM8x1N LGfQ== MIME-Version: 1.0 X-Received: by 10.152.18.166 with SMTP id x6mr23270763lad.1.1408641976484; Thu, 21 Aug 2014 10:26:16 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.152.8.46 with HTTP; Thu, 21 Aug 2014 10:26:16 -0700 (PDT) Date: Thu, 21 Aug 2014 13:26:16 -0400 X-Google-Sender-Auth: df1slhV2RW1xRXXccgtiZrqJKWo Message-ID: From: Barry Leiba To: core WG Content-Type: text/plain; charset=ISO-8859-1 Archived-At: http://mailarchive.ietf.org/arch/msg/core/8hyaDRdGM50ZGhlMdYxu1WT1Tqs Subject: [core] draft-ietf-core-observe status, post-telechat X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Aug 2014 17:26:20 -0000 As you can see, the "observe" document is in AD Followup state, while the authors respond to Richard's DISCUSS. Please also make sure that the non-blocking comments from the other ADs are addressed. I'll expect the document shepherd to track this, to prod as needed, and to let me know when the draft is ready for approval. Barry From nobody Thu Aug 21 10:29:49 2014 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C3531A0453 for ; Thu, 21 Aug 2014 10:29:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 843bmp_Pc6bK for ; Thu, 21 Aug 2014 10:29:45 -0700 (PDT) Received: from mail-lb0-x22d.google.com (mail-lb0-x22d.google.com [IPv6:2a00:1450:4010:c04::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 46EAE1A047D for ; Thu, 21 Aug 2014 10:29:45 -0700 (PDT) Received: by mail-lb0-f173.google.com with SMTP id u10so8436564lbd.4 for ; Thu, 21 Aug 2014 10:29:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:content-type; bh=p7dGzP1t0tc42wFZv7chokIJdVbmI5tje/iZc6GSjbw=; b=SbMdgElyRTJdz+nZNFbmD2b1BK9GWQ82QhTeYUwlsvvLd+M1adkUajzBfV56Bthw0A EPoLuM90aoiFQA0RgfG6r+FjzNTN7lYEOjgpYp2dIwtzv4bVaLfM6O4qQe8P0pE/QDC9 +rL3yWD/oiBG7IIvnwHkA2WVLrChUZwYugEgKR3jgYc0oByPHCXsiVgTvsFfhoDMLSR4 NvfQDBACeHdOH8zzy9uBS/e7DV8q169fjEWopoXpeLxSjbr/U0prBnXos8319iKgA+Hu X+B/30nT3TdZ7+1e3R5H7Y6JsjksB2Jlr6Rh7ym48dxuxV0ZFbAkWeHqxdmUp2Qv8YOj uhlg== MIME-Version: 1.0 X-Received: by 10.112.253.165 with SMTP id ab5mr47858850lbd.1.1408642183619; Thu, 21 Aug 2014 10:29:43 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.152.8.46 with HTTP; Thu, 21 Aug 2014 10:29:43 -0700 (PDT) Date: Thu, 21 Aug 2014 13:29:43 -0400 X-Google-Sender-Auth: ljoNrAG5IUmM_cxgmgWsepE-nKE Message-ID: From: Barry Leiba To: core WG Content-Type: text/plain; charset=ISO-8859-1 Archived-At: http://mailarchive.ietf.org/arch/msg/core/0ulwa9VPUtkwMgZIvoKFZGWnPtg Subject: [core] draft-ietf-core-groupcomm status, post-telechat X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Aug 2014 17:29:46 -0000 The "groupcomm" document still has several DISCUSS points on it, and is in Revised I-D Needed status after today's telechat. It's clear that the consensus of the IESG is to re-target the document at Experimental status. The authors should make that change in the next version, in addition to resolving the DISCUSS issues and addressing the other IESG comments. The document shepherd should pleas track this, prod as necessary, and make sure things get resolved and dealt with. Please let me know when the document is ready for approval. Please also confirm that the working group accepts the IESG's decision to go with Experimental, and if the working group doesn't, please explain why. Barry From nobody Thu Aug 21 13:35:50 2014 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D75A61A8737 for ; Thu, 21 Aug 2014 13:35:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.567 X-Spam-Level: X-Spam-Status: No, score=-2.567 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.668] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I00Np5TJYC9E for ; Thu, 21 Aug 2014 13:35:47 -0700 (PDT) Received: from smtp-in1.interdigital.com (smtp-in1.interdigital.com [64.208.228.133]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C2D111A89FD for ; Thu, 21 Aug 2014 13:35:47 -0700 (PDT) X-ASG-Debug-ID: 1408653346-06daaa2edb11d80001-aa7cYp Received: from smtp-out1.interdigital.com (sahara.interdigital.com [10.0.128.27]) by smtp-in1.interdigital.com with ESMTP id fzWdEHFCo8648q7a for ; Thu, 21 Aug 2014 16:35:46 -0400 (EDT) X-Barracuda-Envelope-From: Akbar.Rahman@InterDigital.com Received: from SAM.InterDigital.com ([10.30.2.11]) by smtp-out1.interdigital.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 21 Aug 2014 16:35:44 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CFBD7F.7B7B35DF" Date: Thu, 21 Aug 2014 16:35:44 -0400 X-ASG-Orig-Subj: RE: [core] draft-ietf-core-groupcomm status, post-telechat Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [core] draft-ietf-core-groupcomm status, post-telechat Thread-Index: Ac+9ZYOWUszfpWGGQEa7JP9tNwl0KQAGfiD3 References: From: "Rahman, Akbar" To: "Barry Leiba" , "core WG" X-OriginalArrivalTime: 21 Aug 2014 20:35:44.0751 (UTC) FILETIME=[7B7FE7F0:01CFBD7F] X-Barracuda-Connect: sahara.interdigital.com[10.0.128.27] X-Barracuda-Start-Time: 1408653346 X-Barracuda-URL: http://10.1.245.3:8000/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at interdigital.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=9.0 tests=HTML_MESSAGE X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.8700 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 HTML_MESSAGE BODY: HTML included in message Archived-At: http://mailarchive.ietf.org/arch/msg/core/XV1NChJUlj7DJjcc40QCPmDylIY Subject: Re: [core] draft-ietf-core-groupcomm status, post-telechat X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Aug 2014 20:35:50 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CFBD7F.7B7B35DF Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 SGkgQmFycnksDQoNCg0KVGhhbmsgeW91IGZvciB0aGUgdXBkYXRlLg0KDQpXZSB3aWxsIGFpbSB0 byBoYXZlIGFuIHVwZGF0ZSBvZiB0aGUgZHJhZnQgYnkgdGhlIGVuZCBvZiBuZXh0IHdlZWsgdGhh dCBhZGRyZXNzZXMgYWxsIHRoZSBESVNDVVNTIHBvaW50cyAoYXMgd2VsbCBhcyBvdGhlciBjb21t ZW50cykuIEknbSBhc3N1bWluZyB0aGF0IGlzIGFjY2VwdGFibGUgaW5zdGVhZCBvZiBtdWx0aXBs ZSBwYXJhbGxlbCBlbWFpbCBleGNoYW5nZXMgdHJ5aW5nIHRvIHJlc29sdmUgdGhlIGNvbW1lbnRz IGJ5IGVtYWlsLg0KDQpQbGVhc2Ugd3JpdGUgYmFjayBhbmQgdGVsbCB1cyBpZiB5b3UgYWdyZWUg d2l0aCB0aGlzIGFwcHJvYWNoIG9yIG5vdC4NCg0KDQpBa2JhciAmIEVza28NCg0KDQoNCg0KDQoN Ci0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBCYXJyeSBMZWliYSBbYmFycnlsZWli YUBjb21wdXRlci5vcmddDQpTZW50OiBUaHVyc2RheSwgQXVndXN0IDIxLCAyMDE0IDAxOjI5IFBN IEVhc3Rlcm4gU3RhbmRhcmQgVGltZQ0KVG86IGNvcmUgV0cNClN1YmplY3Q6IFtjb3JlXSBkcmFm dC1pZXRmLWNvcmUtZ3JvdXBjb21tIHN0YXR1cywgcG9zdC10ZWxlY2hhdA0KDQoNCg0KVGhlICJn cm91cGNvbW0iIGRvY3VtZW50IHN0aWxsIGhhcyBzZXZlcmFsIERJU0NVU1MgcG9pbnRzIG9uIGl0 LCBhbmQNCmlzIGluIFJldmlzZWQgSS1EIE5lZWRlZCBzdGF0dXMgYWZ0ZXIgdG9kYXkncyB0ZWxl Y2hhdC4gIEl0J3MgY2xlYXINCnRoYXQgdGhlIGNvbnNlbnN1cyBvZiB0aGUgSUVTRyBpcyB0byBy ZS10YXJnZXQgdGhlIGRvY3VtZW50IGF0DQpFeHBlcmltZW50YWwgc3RhdHVzLiAgVGhlIGF1dGhv cnMgc2hvdWxkIG1ha2UgdGhhdCBjaGFuZ2UgaW4gdGhlIG5leHQNCnZlcnNpb24sIGluIGFkZGl0 aW9uIHRvIHJlc29sdmluZyB0aGUgRElTQ1VTUyBpc3N1ZXMgYW5kIGFkZHJlc3NpbmcNCnRoZSBv dGhlciBJRVNHIGNvbW1lbnRzLg0KDQpUaGUgZG9jdW1lbnQgc2hlcGhlcmQgc2hvdWxkIHBsZWFz IHRyYWNrIHRoaXMsIHByb2QgYXMgbmVjZXNzYXJ5LCBhbmQNCm1ha2Ugc3VyZSB0aGluZ3MgZ2V0 IHJlc29sdmVkIGFuZCBkZWFsdCB3aXRoLiAgUGxlYXNlIGxldCBtZSBrbm93IHdoZW4NCnRoZSBk b2N1bWVudCBpcyByZWFkeSBmb3IgYXBwcm92YWwuICBQbGVhc2UgYWxzbyBjb25maXJtIHRoYXQg dGhlDQp3b3JraW5nIGdyb3VwIGFjY2VwdHMgdGhlIElFU0cncyBkZWNpc2lvbiB0byBnbyB3aXRo IEV4cGVyaW1lbnRhbCwgYW5kDQppZiB0aGUgd29ya2luZyBncm91cCBkb2Vzbid0LCBwbGVhc2Ug ZXhwbGFpbiB3aHkuDQoNCkJhcnJ5DQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fDQpjb3JlIG1haWxpbmcgbGlzdA0KY29yZUBpZXRmLm9yZw0KaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9jb3JlDQoNCg0K ------_=_NextPart_001_01CFBD7F.7B7B35DF Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDMuMi8vRU4iPg0KPGh0bWw+ DQo8aGVhZD4NCjxtZXRhIG5hbWU9ImdlbmVyYXRvciIgY29udGVudD0iSFRNTCBUaWR5IGZvciBX aW5kb3dzICh2ZXJzIDI1IE1hcmNoIDIwMDkpLCBzZWUgd3d3LnczLm9yZyI+DQo8bWV0YSBodHRw LWVxdWl2PSJDb250ZW50LVR5cGUiIGNvbnRlbnQ9InRleHQvaHRtbDsgY2hhcnNldD11dGYtOCI+ DQo8bWV0YSBuYW1lPSJHZW5lcmF0b3IiIGNvbnRlbnQ9Ik1TIEV4Y2hhbmdlIFNlcnZlciB2ZXJz aW9uIDYuNS43NjU0LjEyIj4NCjx0aXRsZT5bY29yZV0gZHJhZnQtaWV0Zi1jb3JlLWdyb3VwY29t bSBzdGF0dXMsIHBvc3QtdGVsZWNoYXQ8L3RpdGxlPg0KPC9oZWFkPg0KPGJvZHk+DQpIaSBCYXJy eSw8YnI+DQo8YnI+DQo8YnI+DQpUaGFuayB5b3UgZm9yIHRoZSB1cGRhdGUuPGJyPg0KPGJyPg0K V2Ugd2lsbCBhaW0gdG8gaGF2ZSBhbiB1cGRhdGUgb2YgdGhlIGRyYWZ0IGJ5IHRoZSBlbmQgb2Yg bmV4dCB3ZWVrIHRoYXQgYWRkcmVzc2VzIGFsbCB0aGUgRElTQ1VTUyBwb2ludHMgKGFzIHdlbGwg YXMgb3RoZXIgY29tbWVudHMpLiBJJ20gYXNzdW1pbmcgdGhhdCBpcyBhY2NlcHRhYmxlIGluc3Rl YWQgb2YgbXVsdGlwbGUgcGFyYWxsZWwgZW1haWwgZXhjaGFuZ2VzIHRyeWluZyB0byByZXNvbHZl IHRoZSBjb21tZW50cyBieSBlbWFpbC48YnI+DQo8YnI+DQpQbGVhc2Ugd3JpdGUgYmFjayBhbmQg dGVsbCB1cyBpZiB5b3UgYWdyZWUgd2l0aCB0aGlzIGFwcHJvYWNoIG9yIG5vdC48YnI+DQo8YnI+ DQo8YnI+DQpBa2JhciAmYW1wOyBFc2tvPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KPGJy Pg0KPGJyPg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08YnI+DQo8Yj5Gcm9tOiZuYnNwOzwv Yj5CYXJyeSBMZWliYSBbPGEgaHJlZj0ibWFpbHRvOmJhcnJ5bGVpYmFAY29tcHV0ZXIub3JnIj5i YXJyeWxlaWJhQGNvbXB1dGVyLm9yZzwvYT5dPGJyPg0KPGI+U2VudDombmJzcDs8L2I+VGh1cnNk YXksIEF1Z3VzdCAyMSwgMjAxNCAwMToyOSBQTSBFYXN0ZXJuIFN0YW5kYXJkIFRpbWU8YnI+DQo8 Yj5UbzombmJzcDs8L2I+Y29yZSBXRzxicj4NCjxiPlN1YmplY3Q6Jm5ic3A7PC9iPltjb3JlXSBk cmFmdC1pZXRmLWNvcmUtZ3JvdXBjb21tIHN0YXR1cywgcG9zdC10ZWxlY2hhdDxicj4NCjxicj4N CjwhLS0gQ29udmVydGVkIGZyb20gdGV4dC9wbGFpbiBmb3JtYXQgLS0+DQo8cD48Zm9udCBzaXpl PSIyIj5UaGUgImdyb3VwY29tbSIgZG9jdW1lbnQgc3RpbGwgaGFzIHNldmVyYWwgRElTQ1VTUyBw b2ludHMgb24gaXQsIGFuZDxicj4NCmlzIGluIFJldmlzZWQgSS1EIE5lZWRlZCBzdGF0dXMgYWZ0 ZXIgdG9kYXkncyB0ZWxlY2hhdC4mbmJzcDsgSXQncyBjbGVhcjxicj4NCnRoYXQgdGhlIGNvbnNl bnN1cyBvZiB0aGUgSUVTRyBpcyB0byByZS10YXJnZXQgdGhlIGRvY3VtZW50IGF0PGJyPg0KRXhw ZXJpbWVudGFsIHN0YXR1cy4mbmJzcDsgVGhlIGF1dGhvcnMgc2hvdWxkIG1ha2UgdGhhdCBjaGFu Z2UgaW4gdGhlIG5leHQ8YnI+DQp2ZXJzaW9uLCBpbiBhZGRpdGlvbiB0byByZXNvbHZpbmcgdGhl IERJU0NVU1MgaXNzdWVzIGFuZCBhZGRyZXNzaW5nPGJyPg0KdGhlIG90aGVyIElFU0cgY29tbWVu dHMuPGJyPg0KPGJyPg0KVGhlIGRvY3VtZW50IHNoZXBoZXJkIHNob3VsZCBwbGVhcyB0cmFjayB0 aGlzLCBwcm9kIGFzIG5lY2Vzc2FyeSwgYW5kPGJyPg0KbWFrZSBzdXJlIHRoaW5ncyBnZXQgcmVz b2x2ZWQgYW5kIGRlYWx0IHdpdGguJm5ic3A7IFBsZWFzZSBsZXQgbWUga25vdyB3aGVuPGJyPg0K dGhlIGRvY3VtZW50IGlzIHJlYWR5IGZvciBhcHByb3ZhbC4mbmJzcDsgUGxlYXNlIGFsc28gY29u ZmlybSB0aGF0IHRoZTxicj4NCndvcmtpbmcgZ3JvdXAgYWNjZXB0cyB0aGUgSUVTRydzIGRlY2lz aW9uIHRvIGdvIHdpdGggRXhwZXJpbWVudGFsLCBhbmQ8YnI+DQppZiB0aGUgd29ya2luZyBncm91 cCBkb2Vzbid0LCBwbGVhc2UgZXhwbGFpbiB3aHkuPGJyPg0KPGJyPg0KQmFycnk8YnI+DQo8YnI+ DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCmNv cmUgbWFpbGluZyBsaXN0PGJyPg0KY29yZUBpZXRmLm9yZzxicj4NCjxhIGhyZWY9Imh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vY29yZSI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9jb3JlPC9hPjxicj48L2ZvbnQ+PC9wPg0KPC9ib2R5Pg0KPC9odG1s Pg0K ------_=_NextPart_001_01CFBD7F.7B7B35DF-- From nobody Thu Aug 21 14:31:37 2014 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C2E71A0AD1 for ; Thu, 21 Aug 2014 14:31:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9tMuP9UfaBpm for ; Thu, 21 Aug 2014 14:31:35 -0700 (PDT) Received: from mail-lb0-x22b.google.com (mail-lb0-x22b.google.com [IPv6:2a00:1450:4010:c04::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 19DBB1A0AD0 for ; Thu, 21 Aug 2014 14:31:34 -0700 (PDT) Received: by mail-lb0-f171.google.com with SMTP id l4so8784259lbv.16 for ; Thu, 21 Aug 2014 14:31:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=820zWuk77PTLUNkzRKVIGybmZA753NfkQWfCzLfGhM4=; b=iQ52bCPAH0ftIrcbfUs3tPDOO4wgwdfQ9m0qarjw/70hMgG+tUVRLUfbEcu2N9lOcq 634wgpj78byYqUyDkVY0KfXX3CUDisLZo7yGlJp9dqunVsDZ3zniIGCZGCeGlVUKPFrm aEu7qCFprVvH0Q8xxLUJGkD+0HLq/+wXqspvqeu4FBTq2O6rJni2/RhrT0NDbveo+B8l eIFO8K07bnHFc5EJ7ypP1QTkKq6Mla8VmUuTuCRx0p5IeMwbIZfmPeBk3+bMKeT9Bxhd k8AlH2/4h1rof0gbodw0faz6NdQK6ZfSu4cwXOW5RNuqflpcODnXeCTBOdrBqkQDv3I0 it6w== MIME-Version: 1.0 X-Received: by 10.112.184.161 with SMTP id ev1mr903955lbc.82.1408656692789; Thu, 21 Aug 2014 14:31:32 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.152.8.46 with HTTP; Thu, 21 Aug 2014 14:31:32 -0700 (PDT) In-Reply-To: References: Date: Thu, 21 Aug 2014 17:31:32 -0400 X-Google-Sender-Auth: 7XxFmnqwht_T4QKkW_Tam3dXDX8 Message-ID: From: Barry Leiba To: "Rahman, Akbar" Content-Type: multipart/alternative; boundary=001a11c31d0ec8c69305012a7194 Archived-At: http://mailarchive.ietf.org/arch/msg/core/Nn03MCYkOqibYwRH7V4c8W0qJRQ Cc: core WG Subject: Re: [core] draft-ietf-core-groupcomm status, post-telechat X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Aug 2014 21:31:36 -0000 --001a11c31d0ec8c69305012a7194 Content-Type: text/plain; charset=ISO-8859-1 That's fine, but please do engage with the ADs whose comments you're addressing, to make sure that they know you're working on it, and, if necessary, that they agree with your plan. Barry On Thursday, August 21, 2014, Rahman, Akbar wrote: > Hi Barry, > > > Thank you for the update. > > We will aim to have an update of the draft by the end of next week that > addresses all the DISCUSS points (as well as other comments). I'm assuming > that is acceptable instead of multiple parallel email exchanges trying to > resolve the comments by email. > > Please write back and tell us if you agree with this approach or not. > > > Akbar & Esko > > > > > > > -----Original Message----- > *From: *Barry Leiba [barryleiba@computer.org > ] > *Sent: *Thursday, August 21, 2014 01:29 PM Eastern Standard Time > *To: *core WG > *Subject: *[core] draft-ietf-core-groupcomm status, post-telechat > > The "groupcomm" document still has several DISCUSS points on it, and > is in Revised I-D Needed status after today's telechat. It's clear > that the consensus of the IESG is to re-target the document at > Experimental status. The authors should make that change in the next > version, in addition to resolving the DISCUSS issues and addressing > the other IESG comments. > > The document shepherd should pleas track this, prod as necessary, and > make sure things get resolved and dealt with. Please let me know when > the document is ready for approval. Please also confirm that the > working group accepts the IESG's decision to go with Experimental, and > if the working group doesn't, please explain why. > > Barry > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > --001a11c31d0ec8c69305012a7194 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable That's fine, but please do engage with the ADs whose comments you'r= e addressing, to make sure that they know you're working on it, and, if= necessary, that they agree with your plan.

Barry<= /span>

On Thursday, August 21, 2014, Rahman, Akbar <Akbar.Rahman@interdigital.com> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">
Hi Barry,


Thank you for the update.

We will aim to have an update of the draft by the end of next week that add= resses all the DISCUSS points (as well as other comments). I'm assuming= that is acceptable instead of multiple parallel email exchanges trying to = resolve the comments by email.

Please write back and tell us if you agree with this approach or not.


Akbar & Esko






-----Original Message-----
From:=A0Barry Leiba [barryleiba@computer.= org]
Sent:=A0Thursday, August 21, 2014 01:29 PM Eastern Standard Time
To:=A0core WG
Subject:=A0[core] draft-ietf-core-groupcomm status, post-telechat

The "groupcomm" document still has several DISCUSS point= s on it, and
is in Revised I-D Needed status after today's telechat.=A0 It's cle= ar
that the consensus of the IESG is to re-target the document at
Experimental status.=A0 The authors should make that change in the next
version, in addition to resolving the DISCUSS issues and addressing
the other IESG comments.

The document shepherd should pleas track this, prod as necessary, and
make sure things get resolved and dealt with.=A0 Please let me know when the document is ready for approval.=A0 Please also confirm that the
working group accepts the IESG's decision to go with Experimental, and<= br> if the working group doesn't, please explain why.

Barry

_______________________________________________
core mailing list
core@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/core

--001a11c31d0ec8c69305012a7194-- From nobody Thu Aug 21 15:48:41 2014 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 361FC1A0B7A for ; Thu, 21 Aug 2014 15:48:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.567 X-Spam-Level: X-Spam-Status: No, score=-2.567 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.668] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IsLQABHh-Q8G for ; Thu, 21 Aug 2014 15:48:38 -0700 (PDT) Received: from smtp-in1.interdigital.com (smtp-in1.interdigital.com [64.208.228.133]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2A5521A0B74 for ; Thu, 21 Aug 2014 15:48:38 -0700 (PDT) X-ASG-Debug-ID: 1408661316-06daaa2edb13440001-aa7cYp Received: from smtp-out1.interdigital.com (sahara.interdigital.com [10.0.128.27]) by smtp-in1.interdigital.com with ESMTP id 22UkRK2intHA2cSl for ; Thu, 21 Aug 2014 18:48:36 -0400 (EDT) X-Barracuda-Envelope-From: Akbar.Rahman@InterDigital.com Received: from SAM.InterDigital.com ([10.30.2.11]) by smtp-out1.interdigital.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 21 Aug 2014 18:48:34 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CFBD92.09D3CFF7" Date: Thu, 21 Aug 2014 18:48:34 -0400 X-ASG-Orig-Subj: RE: draft-ietf-core-groupcomm status, post-telechat Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-ietf-core-groupcomm status, post-telechat Thread-Index: Ac+9h0hHDqh8LIwQSfq5LNTSNwsX4AACsDrw References: From: "Rahman, Akbar" To: "Barry Leiba" X-OriginalArrivalTime: 21 Aug 2014 22:48:34.0571 (UTC) FILETIME=[09E1EDB0:01CFBD92] X-Barracuda-Connect: sahara.interdigital.com[10.0.128.27] X-Barracuda-Start-Time: 1408661316 X-Barracuda-URL: http://10.1.245.3:8000/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at interdigital.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=9.0 tests=BSF_SC0_MISMATCH_TO, HTML_MESSAGE X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.8705 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 BSF_SC0_MISMATCH_TO Envelope rcpt doesn't match header 0.00 HTML_MESSAGE BODY: HTML included in message Archived-At: http://mailarchive.ietf.org/arch/msg/core/nVaVd9JusCHDviFzqIadBziPcVw Cc: core WG Subject: Re: [core] draft-ietf-core-groupcomm status, post-telechat X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Aug 2014 22:48:40 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CFBD92.09D3CFF7 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 T2ssIHdlIHdpbGwgbWFrZSBzdXJlIHRvIGVuZ2FnZSB0aGUgQURzIGR1cmluZyB0aGUgcHJvY2Vz cy4gVGhhbmtzIGZvciB0aGUgZ3VpZGFuY2UuDQoNCg0KDQoNCg0KDQotLS0tLU9yaWdpbmFsIE1l c3NhZ2UtLS0tLQ0KRnJvbTogQmFycnkgTGVpYmEgW2JhcnJ5bGVpYmFAY29tcHV0ZXIub3JnXQ0K U2VudDogVGh1cnNkYXksIEF1Z3VzdCAyMSwgMjAxNCAwNTozMSBQTSBFYXN0ZXJuIFN0YW5kYXJk IFRpbWUNClRvOiBSYWhtYW4sIEFrYmFyDQpDYzogY29yZSBXRw0KU3ViamVjdDogUmU6IGRyYWZ0 LWlldGYtY29yZS1ncm91cGNvbW0gc3RhdHVzLCBwb3N0LXRlbGVjaGF0DQoNClRoYXQncyBmaW5l LCBidXQgcGxlYXNlIGRvIGVuZ2FnZSB3aXRoIHRoZSBBRHMgd2hvc2UgY29tbWVudHMgeW91J3Jl IGFkZHJlc3NpbmcsIHRvIG1ha2Ugc3VyZSB0aGF0IHRoZXkga25vdyB5b3UncmUgd29ya2luZyBv biBpdCwgYW5kLCBpZiBuZWNlc3NhcnksIHRoYXQgdGhleSBhZ3JlZSB3aXRoIHlvdXIgcGxhbi4g DQoNCkJhcnJ5DQoNCk9uIFRodXJzZGF5LCBBdWd1c3QgMjEsIDIwMTQsIFJhaG1hbiwgQWtiYXIg PEFrYmFyLlJhaG1hbkBpbnRlcmRpZ2l0YWwuY29tPiB3cm90ZToNCg0KDQoJSGkgQmFycnksDQoJ DQoJDQoJVGhhbmsgeW91IGZvciB0aGUgdXBkYXRlLg0KCQ0KCVdlIHdpbGwgYWltIHRvIGhhdmUg YW4gdXBkYXRlIG9mIHRoZSBkcmFmdCBieSB0aGUgZW5kIG9mIG5leHQgd2VlayB0aGF0IGFkZHJl c3NlcyBhbGwgdGhlIERJU0NVU1MgcG9pbnRzIChhcyB3ZWxsIGFzIG90aGVyIGNvbW1lbnRzKS4g SSdtIGFzc3VtaW5nIHRoYXQgaXMgYWNjZXB0YWJsZSBpbnN0ZWFkIG9mIG11bHRpcGxlIHBhcmFs bGVsIGVtYWlsIGV4Y2hhbmdlcyB0cnlpbmcgdG8gcmVzb2x2ZSB0aGUgY29tbWVudHMgYnkgZW1h aWwuDQoJDQoJUGxlYXNlIHdyaXRlIGJhY2sgYW5kIHRlbGwgdXMgaWYgeW91IGFncmVlIHdpdGgg dGhpcyBhcHByb2FjaCBvciBub3QuDQoJDQoJDQoJQWtiYXIgJiBFc2tvDQoJDQoJDQoJDQoJDQoJ DQoJDQoJLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCglGcm9tOu+/vUJhcnJ5IExlaWJhIFti YXJyeWxlaWJhQGNvbXB1dGVyLm9yZyA8amF2YXNjcmlwdDpfZSglN0IlN0QsJ2N2bWwnLCdiYXJy eWxlaWJhQGNvbXB1dGVyLm9yZycpOz4gXQ0KCVNlbnQ677+9VGh1cnNkYXksIEF1Z3VzdCAyMSwg MjAxNCAwMToyOSBQTSBFYXN0ZXJuIFN0YW5kYXJkIFRpbWUNCglUbzrvv71jb3JlIFdHDQoJU3Vi amVjdDrvv71bY29yZV0gZHJhZnQtaWV0Zi1jb3JlLWdyb3VwY29tbSBzdGF0dXMsIHBvc3QtdGVs ZWNoYXQNCgkNCgkNCg0KCVRoZSAiZ3JvdXBjb21tIiBkb2N1bWVudCBzdGlsbCBoYXMgc2V2ZXJh bCBESVNDVVNTIHBvaW50cyBvbiBpdCwgYW5kDQoJaXMgaW4gUmV2aXNlZCBJLUQgTmVlZGVkIHN0 YXR1cyBhZnRlciB0b2RheSdzIHRlbGVjaGF0Lu+/vSBJdCdzIGNsZWFyDQoJdGhhdCB0aGUgY29u c2Vuc3VzIG9mIHRoZSBJRVNHIGlzIHRvIHJlLXRhcmdldCB0aGUgZG9jdW1lbnQgYXQNCglFeHBl cmltZW50YWwgc3RhdHVzLu+/vSBUaGUgYXV0aG9ycyBzaG91bGQgbWFrZSB0aGF0IGNoYW5nZSBp biB0aGUgbmV4dA0KCXZlcnNpb24sIGluIGFkZGl0aW9uIHRvIHJlc29sdmluZyB0aGUgRElTQ1VT UyBpc3N1ZXMgYW5kIGFkZHJlc3NpbmcNCgl0aGUgb3RoZXIgSUVTRyBjb21tZW50cy4NCgkNCglU aGUgZG9jdW1lbnQgc2hlcGhlcmQgc2hvdWxkIHBsZWFzIHRyYWNrIHRoaXMsIHByb2QgYXMgbmVj ZXNzYXJ5LCBhbmQNCgltYWtlIHN1cmUgdGhpbmdzIGdldCByZXNvbHZlZCBhbmQgZGVhbHQgd2l0 aC7vv70gUGxlYXNlIGxldCBtZSBrbm93IHdoZW4NCgl0aGUgZG9jdW1lbnQgaXMgcmVhZHkgZm9y IGFwcHJvdmFsLu+/vSBQbGVhc2UgYWxzbyBjb25maXJtIHRoYXQgdGhlDQoJd29ya2luZyBncm91 cCBhY2NlcHRzIHRoZSBJRVNHJ3MgZGVjaXNpb24gdG8gZ28gd2l0aCBFeHBlcmltZW50YWwsIGFu ZA0KCWlmIHRoZSB3b3JraW5nIGdyb3VwIGRvZXNuJ3QsIHBsZWFzZSBleHBsYWluIHdoeS4NCgkN CglCYXJyeQ0KCQ0KCV9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQoJY29yZSBtYWlsaW5nIGxpc3QNCgljb3JlQGlldGYub3JnIDxqYXZhc2NyaXB0Ol9lKCU3 QiU3RCwnY3ZtbCcsJ2NvcmVAaWV0Zi5vcmcnKTs+IA0KCWh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vY29yZQ0KCQ0KDQo= ------_=_NextPart_001_01CFBD92.09D3CFF7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: base64 PCFET0NUWVBFIGh0bWwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMDEgVHJhbnNpdGlvbmFs Ly9FTiI+DQo8aHRtbD4NCjxoZWFkPg0KPG1ldGEgbmFtZT0iZ2VuZXJhdG9yIiBjb250ZW50PSJI VE1MIFRpZHkgZm9yIFdpbmRvd3MgKHZlcnMgMjUgTWFyY2ggMjAwOSksIHNlZSB3d3cudzMub3Jn Ij4NCjx0aXRsZT48L3RpdGxlPg0KPC9oZWFkPg0KPGJvZHk+DQpPaywgd2Ugd2lsbCBtYWtlIHN1 cmUgdG8gZW5nYWdlIHRoZSBBRHMgZHVyaW5nIHRoZSBwcm9jZXNzLiBUaGFua3MgZm9yIHRoZSBn dWlkYW5jZS48YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQotLS0tLU9y aWdpbmFsIE1lc3NhZ2UtLS0tLTxicj4NCjxiPkZyb206Jm5ic3A7PC9iPkJhcnJ5IExlaWJhIFs8 YSBocmVmPSJtYWlsdG86YmFycnlsZWliYUBjb21wdXRlci5vcmciPmJhcnJ5bGVpYmFAY29tcHV0 ZXIub3JnPC9hPl08YnI+DQo8Yj5TZW50OiZuYnNwOzwvYj5UaHVyc2RheSwgQXVndXN0IDIxLCAy MDE0IDA1OjMxIFBNIEVhc3Rlcm4gU3RhbmRhcmQgVGltZTxicj4NCjxiPlRvOiZuYnNwOzwvYj5S YWhtYW4sIEFrYmFyPGJyPg0KPGI+Q2M6Jm5ic3A7PC9iPmNvcmUgV0c8YnI+DQo8Yj5TdWJqZWN0 OiZuYnNwOzwvYj5SZTogZHJhZnQtaWV0Zi1jb3JlLWdyb3VwY29tbSBzdGF0dXMsIHBvc3QtdGVs ZWNoYXQ8YnI+DQo8YnI+DQpUaGF0J3MgZmluZSwgYnV0IHBsZWFzZSBkbyBlbmdhZ2Ugd2l0aCB0 aGUgQURzIHdob3NlIGNvbW1lbnRzIHlvdSdyZSBhZGRyZXNzaW5nLCB0byBtYWtlIHN1cmUgdGhh dCB0aGV5IGtub3cgeW91J3JlIHdvcmtpbmcgb24gaXQsIGFuZCwgaWYgbmVjZXNzYXJ5LCB0aGF0 IHRoZXkgYWdyZWUgd2l0aCB5b3VyIHBsYW4uDQo8ZGl2Pjxicj48L2Rpdj4NCjxkaXY+QmFycnk8 YnI+DQo8YnI+DQpPbiBUaHVyc2RheSwgQXVndXN0IDIxLCAyMDE0LCBSYWhtYW4sIEFrYmFyICZs dDs8YSBocmVmPSJtYWlsdG86QWtiYXIuUmFobWFuQGludGVyZGlnaXRhbC5jb20iPkFrYmFyLlJh aG1hbkBpbnRlcmRpZ2l0YWwuY29tPC9hPiZndDsgd3JvdGU6PGJyPg0KPGJsb2NrcXVvdGUgY2xh c3M9ImdtYWlsX3F1b3RlIiBzdHlsZT0ibWFyZ2luOjAgMCAwIC44ZXg7Ym9yZGVyLWxlZnQ6MXB4 ICNjY2Mgc29saWQ7cGFkZGluZy1sZWZ0OjFleCI+DQo8ZGl2PkhpIEJhcnJ5LDxicj4NCjxicj4N Cjxicj4NClRoYW5rIHlvdSBmb3IgdGhlIHVwZGF0ZS48YnI+DQo8YnI+DQpXZSB3aWxsIGFpbSB0 byBoYXZlIGFuIHVwZGF0ZSBvZiB0aGUgZHJhZnQgYnkgdGhlIGVuZCBvZiBuZXh0IHdlZWsgdGhh dCBhZGRyZXNzZXMgYWxsIHRoZSBESVNDVVNTIHBvaW50cyAoYXMgd2VsbCBhcyBvdGhlciBjb21t ZW50cykuIEknbSBhc3N1bWluZyB0aGF0IGlzIGFjY2VwdGFibGUgaW5zdGVhZCBvZiBtdWx0aXBs ZSBwYXJhbGxlbCBlbWFpbCBleGNoYW5nZXMgdHJ5aW5nIHRvIHJlc29sdmUgdGhlIGNvbW1lbnRz IGJ5IGVtYWlsLjxicj4NCjxicj4NClBsZWFzZSB3cml0ZSBiYWNrIGFuZCB0ZWxsIHVzIGlmIHlv dSBhZ3JlZSB3aXRoIHRoaXMgYXBwcm9hY2ggb3Igbm90Ljxicj4NCjxicj4NCjxicj4NCkFrYmFy ICZhbXA7IEVza288YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQotLS0t LU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxicj4NCjxiPkZyb20677+9PC9iPkJhcnJ5IExlaWJhIFs8 YSBocmVmPSJqYXZhc2NyaXB0Ol9lKCU3QiU3RCwnY3ZtbCcsJ2JhcnJ5bGVpYmFAY29tcHV0ZXIu b3JnJyk7IiB0YXJnZXQ9Il9ibGFuayI+YmFycnlsZWliYUBjb21wdXRlci5vcmc8L2E+XTxicj4N CjxiPlNlbnQ677+9PC9iPlRodXJzZGF5LCBBdWd1c3QgMjEsIDIwMTQgMDE6MjkgUE0gRWFzdGVy biBTdGFuZGFyZCBUaW1lPGJyPg0KPGI+VG8677+9PC9iPmNvcmUgV0c8YnI+DQo8Yj5TdWJqZWN0 Ou+/vTwvYj5bY29yZV0gZHJhZnQtaWV0Zi1jb3JlLWdyb3VwY29tbSBzdGF0dXMsIHBvc3QtdGVs ZWNoYXQ8YnI+DQo8YnI+DQo8cD48Zm9udD5UaGUgImdyb3VwY29tbSIgZG9jdW1lbnQgc3RpbGwg aGFzIHNldmVyYWwgRElTQ1VTUyBwb2ludHMgb24gaXQsIGFuZDxicj4NCmlzIGluIFJldmlzZWQg SS1EIE5lZWRlZCBzdGF0dXMgYWZ0ZXIgdG9kYXkncyB0ZWxlY2hhdC7vv70gSXQncyBjbGVhcjxi cj4NCnRoYXQgdGhlIGNvbnNlbnN1cyBvZiB0aGUgSUVTRyBpcyB0byByZS10YXJnZXQgdGhlIGRv Y3VtZW50IGF0PGJyPg0KRXhwZXJpbWVudGFsIHN0YXR1cy7vv70gVGhlIGF1dGhvcnMgc2hvdWxk IG1ha2UgdGhhdCBjaGFuZ2UgaW4gdGhlIG5leHQ8YnI+DQp2ZXJzaW9uLCBpbiBhZGRpdGlvbiB0 byByZXNvbHZpbmcgdGhlIERJU0NVU1MgaXNzdWVzIGFuZCBhZGRyZXNzaW5nPGJyPg0KdGhlIG90 aGVyIElFU0cgY29tbWVudHMuPGJyPg0KPGJyPg0KVGhlIGRvY3VtZW50IHNoZXBoZXJkIHNob3Vs ZCBwbGVhcyB0cmFjayB0aGlzLCBwcm9kIGFzIG5lY2Vzc2FyeSwgYW5kPGJyPg0KbWFrZSBzdXJl IHRoaW5ncyBnZXQgcmVzb2x2ZWQgYW5kIGRlYWx0IHdpdGgu77+9IFBsZWFzZSBsZXQgbWUga25v dyB3aGVuPGJyPg0KdGhlIGRvY3VtZW50IGlzIHJlYWR5IGZvciBhcHByb3ZhbC7vv70gUGxlYXNl IGFsc28gY29uZmlybSB0aGF0IHRoZTxicj4NCndvcmtpbmcgZ3JvdXAgYWNjZXB0cyB0aGUgSUVT RydzIGRlY2lzaW9uIHRvIGdvIHdpdGggRXhwZXJpbWVudGFsLCBhbmQ8YnI+DQppZiB0aGUgd29y a2luZyBncm91cCBkb2Vzbid0LCBwbGVhc2UgZXhwbGFpbiB3aHkuPGJyPg0KPGJyPg0KQmFycnk8 YnI+DQo8YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xzxicj4NCmNvcmUgbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0iamF2YXNjcmlwdDpfZSglN0Il N0QsJ2N2bWwnLCdjb3JlQGlldGYub3JnJyk7IiB0YXJnZXQ9Il9ibGFuayI+Y29yZUBpZXRmLm9y ZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L2NvcmUiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL2NvcmU8L2E+PGJyPjwvZm9udD48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2 Pg0KPC9ib2R5Pg0KPC9odG1sPg0K ------_=_NextPart_001_01CFBD92.09D3CFF7-- From nobody Sun Aug 24 16:33:15 2014 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5A2F1A88AA; Sun, 24 Aug 2014 16:33:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U-v47jJetc7b; Sun, 24 Aug 2014 16:33:10 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C38441A88B2; Sun, 24 Aug 2014 16:33:05 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.2.p5 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140824233305.23444.3554.idtracker@ietfa.amsl.com> Date: Sun, 24 Aug 2014 16:33:05 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/core/fxuofQ1ziFlFlD-CMlK0ma3ghHo Cc: core@ietf.org Subject: [core] I-D Action: draft-ietf-core-groupcomm-22.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Aug 2014 23:33:12 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Constrained RESTful Environments Working Group of the IETF. Title : Group Communication for CoAP Authors : Akbar Rahman Esko Dijk Filename : draft-ietf-core-groupcomm-22.txt Pages : 55 Date : 2014-08-24 Abstract: The Constrained Application Protocol (CoAP) is a specialized web transfer protocol for constrained devices and constrained networks. It is anticipated that constrained devices will often naturally operate in groups (e.g., in a building automation scenario all lights in a given room may need to be switched on/off as a group). This specification defines how the CoAP protocol should be used in a group communication context. An approach for using CoAP on top of IP multicast is detailed based on both existing CoAP functionality as well as new features introduced in this specification. Also, various use cases and corresponding protocol flows are provided to illustrate important concepts. Finally, guidance is provided for deployment in various network topologies. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-core-groupcomm/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-core-groupcomm-22 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-core-groupcomm-22 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sun Aug 24 16:33:19 2014 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B52C21A88AC for ; Sun, 24 Aug 2014 16:33:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6oyUah7_jiKL; Sun, 24 Aug 2014 16:33:11 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D96F01A88B4; Sun, 24 Aug 2014 16:33:05 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: core-chairs@tools.ietf.org, draft-ietf-core-groupcomm@tools.ietf.org, core@ietf.org, barryleiba@computer.org, mls.ietf@gmail.com, Kathleen.Moriarty.ietf@gmail.com, brian@innovationslab.net X-Test-IDTracker: no X-IETF-IDTracker: 5.6.2.p5 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140824233305.23444.48153.idtracker@ietfa.amsl.com> Date: Sun, 24 Aug 2014 16:33:05 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/core/WcVMIfl6yfpC7kmUHlY6n_sD94I Subject: [core] New Version Notification - draft-ietf-core-groupcomm-22.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Aug 2014 23:33:12 -0000 A new version (-22) has been submitted for draft-ietf-core-groupcomm: http://www.ietf.org/internet-drafts/draft-ietf-core-groupcomm-22.txt Sub state has been changed to AD Followup from Revised ID Needed The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-core-groupcomm/ Diff from previous version: http://www.ietf.org/rfcdiff?url2=draft-ietf-core-groupcomm-22 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. IETF Secretariat. From nobody Sun Aug 24 16:48:01 2014 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47F171A88AB for ; Sun, 24 Aug 2014 16:47:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.568 X-Spam-Level: X-Spam-Status: No, score=-2.568 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.668] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qUiovjmX7Ti1 for ; Sun, 24 Aug 2014 16:47:57 -0700 (PDT) Received: from smtp-in1.interdigital.com (smtp-in1.interdigital.com [64.208.228.133]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 681011A0B81 for ; Sun, 24 Aug 2014 16:47:57 -0700 (PDT) X-ASG-Debug-ID: 1408924072-06daaa2ed9395c0001-aa7cYp Received: from smtp-out1.interdigital.com (sahara.interdigital.com [10.0.128.27]) by smtp-in1.interdigital.com with ESMTP id XwhwYm55dws0Uzb2 for ; Sun, 24 Aug 2014 19:47:52 -0400 (EDT) X-Barracuda-Envelope-From: Akbar.Rahman@InterDigital.com Received: from SAM.InterDigital.com ([10.30.2.11]) by smtp-out1.interdigital.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 24 Aug 2014 19:47:46 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Sun, 24 Aug 2014 19:47:21 -0400 X-ASG-Orig-Subj: RE: [core] New Version Notification - draft-ietf-core-groupcomm-22.txt Message-ID: In-Reply-To: <20140824233305.23444.48153.idtracker@ietfa.amsl.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [core] New Version Notification - draft-ietf-core-groupcomm-22.txt Thread-Index: Ac+/89viHIPTXPLvSdeZbUQHAz3iHwAAG6LA References: <20140824233305.23444.48153.idtracker@ietfa.amsl.com> From: "Rahman, Akbar" To: , , , X-OriginalArrivalTime: 24 Aug 2014 23:47:46.0586 (UTC) FILETIME=[CE49A7A0:01CFBFF5] X-Barracuda-Connect: sahara.interdigital.com[10.0.128.27] X-Barracuda-Start-Time: 1408924072 X-Barracuda-URL: http://10.1.245.3:8000/cgi-mod/mark.cgi X-Barracuda-BRTS-Status: 1 X-Virus-Scanned: by bsmtpd at interdigital.com X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=9.0 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.8799 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- Archived-At: http://mailarchive.ietf.org/arch/msg/core/j3g9X-NhIMUjMlW8pB4rQZXyqAg Cc: Ben Campbell , core-chairs@tools.ietf.org, draft-ietf-core-groupcomm@tools.ietf.org, core@ietf.org Subject: Re: [core] New Version Notification - draft-ietf-core-groupcomm-22.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Aug 2014 23:47:59 -0000 Hi Barry/Martin/Kathleen/Brian, We have produced a new version of groupcomm that tries to address all the IESG DISCUSS comments as well as the major comments from the GEN-ART review.=20 The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-core-groupcomm/ Diff from previous version: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-core-groupcomm-22 The changes are detailed in the Change log of the draft and are summarized here for your convenience: - Brian's comments: Please see points 1-6 (of the change log) - Kathleen's comments: Please see point 7 (of the change log) - Martin's comments: Please see points 8-9 (of the change log) ------------------------------------------------------------------------ ------------------------- Groupcomm Change log Changes from ietf-21 to ietf-22: o Updated with comments from IESG review as follows: 1. Changed Status from Informational to Experimental. 2. Addressed Brian Haberman's DISCUSS (to put in reference to ASM) in section 1.2 as called out in "http://www.ietf.org/ mail-archive/web/core/current/msg05547.html". 3. Addressed Brian Haberman's DISCUSS (to put in reference to multicast forwarding proxies) in section 2.1 as called out in "http://www.ietf.org/mail-archive/web/core/current/ msg05547.html". 4. Addressed Brian Haberman's DISCUSS (to put in reference to getting port numbers from URIs) in section 2.3 as called out in "http://www.ietf.org/mail-archive/web/core/current/ msg05563.html". 5. Addressed Brian Haberman's DISCUSS (to put in reference to IGMP/MLD API) in section 2.7.2.1, 2.7.2.2, 2.7.2.6 and 2.7.2.7 as called out in "http://www.ietf.org/mail- archive/web/core/current/msg05547.html". 6. Addressed Brian Haberman's COMMENT (to put in reference to reliable multicast RFC) in section 1.3 as called out in "http://www.ietf.org/mail-archive/web/core/current/ msg05545.html". 7. Addressed Kathleen Moriarty's DISCUSS (to broaden to cover general monitoring) in section 5.4 as called out in "http://www.ietf.org/mail-archive/web/core/current/ msg05566.html". 8. Addressed Martin Stiemerling's DISCUSS (to clearly indicate that the draft introduces new CoAP protocol functionality) in the Abstract and section 1.2 as called out in "http://www.ietf.org/mail-archive/web/core/current/ msg05542.html". 9. Addressed Martin Stiemerling's DISCUSS (to clarify selected requirements language) in section 2.7.2 as called out in "http://www.ietf.org/mail-archive/web/core/current/ msg05542.html". (Note that the other sections are not impacted as they truly are new requirements and not repetition of the CoAP RFC 7252) 10. Addressed Spencer Dawkins' COMMENT as called out in "http://www.ietf.org/mail-archive/web/core/current/ msg05557.html". 11. Addressed Alissa Cooper's COMMENT as called out in "http://www.ietf.org/mail-archive/web/core/current/ msg05567.html". 12. Addressed selected Stephen Farrell's COMMENTs as called out in "http://www.ietf.org/mail-archive/web/core/current/ msg05576.html". 13. Addressed selected Pete Resnick's COMMENTs as called out in "http://www.ietf.org/mail-archive/web/core/current/ msg05568.html". 14. Addressed selected Adrian Farrel's COMMENTs as called out in "http://www.ietf.org/mail-archive/web/core/current/ msg05565.html". 15. Addressed selected Jari Arkko's COMMENTs as called out in "http://www.ietf.org/mail-archive/web/core/current/ msg05572.html". o Updated with comments from GEN-ART review as follows: 1. Addressed major issue #1 from Ben Campbell's GEN-ART review (about introducing new functionality beyond CoAP RFC 7252) by changing the status of document to Experimental, and updating Abstract and section 2.1 as called out in "http://www.ietf.org/mail-archive/web/core/current/ msg05551.html". 2. Addressed major issue #2 from Ben Campbell's GEN-ART review (about giving a stronger recommendation not to use CoAP group communication in many scenarios until stronger security solutions are available) in section 5.1 and section 5.4 as called out in "http://www.ietf.org/mail- archive/web/core/current/msg05551.html". 3. Addressed selected minor issues and nits from Ben Campbell's GEN-ART review comments from "http://www.ietf.org/mail- archive/web/core/current/msg05535.html". o Various minor editorial updates. -----Original Message----- From: core [mailto:core-bounces@ietf.org] On Behalf Of internet-drafts@ietf.org Sent: Sunday, August 24, 2014 7:33 PM To: core-chairs@tools.ietf.org; draft-ietf-core-groupcomm@tools.ietf.org; core@ietf.org; barryleiba@computer.org; mls.ietf@gmail.com; Kathleen.Moriarty.ietf@gmail.com; brian@innovationslab.net Subject: [core] New Version Notification - draft-ietf-core-groupcomm-22.txt A new version (-22) has been submitted for draft-ietf-core-groupcomm: http://www.ietf.org/internet-drafts/draft-ietf-core-groupcomm-22.txt Sub state has been changed to AD Followup from Revised ID Needed The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-core-groupcomm/ Diff from previous version: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-core-groupcomm-22 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. IETF Secretariat. _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core From nobody Mon Aug 25 05:15:04 2014 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE4241A9043; Mon, 25 Aug 2014 05:15:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fJSx1YhuDpxz; Mon, 25 Aug 2014 05:14:59 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F6151A9051; Mon, 25 Aug 2014 05:14:58 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Brian Haberman" To: The IESG X-Test-IDTracker: no X-IETF-IDTracker: 5.6.2.p5 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140825121458.2950.93492.idtracker@ietfa.amsl.com> Date: Mon, 25 Aug 2014 05:14:58 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/core/N9mhNAuoEESMjsuxJVahtmVvStM Cc: core-chairs@tools.ietf.org, draft-ietf-core-groupcomm@tools.ietf.org, core@ietf.org Subject: [core] Brian Haberman's No Objection on draft-ietf-core-groupcomm-22: (with COMMENT) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Aug 2014 12:15:01 -0000 Brian Haberman has entered the following ballot position for draft-ietf-core-groupcomm-22: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-ietf-core-groupcomm/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for quickly addressing the issues raised. From nobody Tue Aug 26 02:30:26 2014 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F7001A6EF3 for ; Tue, 26 Aug 2014 02:30:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.927 X-Spam-Level: **** X-Spam-Status: No, score=4.927 tagged_above=-999 required=5 tests=[BAYES_99=3.5, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.668] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qPabBVcyEFM9 for ; Tue, 26 Aug 2014 02:30:24 -0700 (PDT) Received: from smtp-vbr13.xs4all.nl (smtp-vbr13.xs4all.nl [194.109.24.33]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BBDBF1A6EF2 for ; Tue, 26 Aug 2014 02:30:23 -0700 (PDT) Received: from roundcube.xs4all.nl (roundcube10.xs4all.net [194.109.20.208]) by smtp-vbr13.xs4all.nl (8.13.8/8.13.8) with ESMTP id s7Q9UKtk002478; Tue, 26 Aug 2014 11:30:21 +0200 (CEST) (envelope-from stokcons@xs4all.nl) Received: from a82-95-140-48.adsl.xs4all.nl ([82.95.140.48]) by roundcube.xs4all.nl with HTTP (HTTP/1.1 POST); Tue, 26 Aug 2014 11:30:20 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Tue, 26 Aug 2014 11:30:20 +0200 From: peter van der Stok To: Core , zach shelby Organization: vanderstok consultancy Mail-Reply-To: consultancy@vanderstok.org Message-ID: <20515e60b7cea25f200748e2f29ba779@xs4all.nl> X-Sender: stokcons@xs4all.nl (G/cAU75W0b8z7asT0hf3AO60G296CFmx) User-Agent: XS4ALL Webmail X-Virus-Scanned: by XS4ALL Virus Scanner Archived-At: http://mailarchive.ietf.org/arch/msg/core/DqZyc27pDhhWgYZEiqY2htaPThk Subject: [core] resource directory version X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: consultancy@vanderstok.org List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Aug 2014 09:30:25 -0000 Hi Zach, A message to re-iterate my interest in the resource directory draft. I went through the latest expired version and noted a few inconsistencies, but then I realized, we may already have sent these to you. When may we expect a new version, possibly one with all nits and already known inconsistencies removed, but with 1-2 TODOs remaining. Thanks, Cheerio, Peter -- Peter van der Stok mailto: consultancy@vanderstok.org www: www.vanderstok.org tel NL: +31(0)492474673 F: +33(0)966015248 From nobody Thu Aug 28 01:59:42 2014 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8D311A0435; Thu, 28 Aug 2014 01:59:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xxTQFi9a3QDY; Thu, 28 Aug 2014 01:59:36 -0700 (PDT) Received: from emea01-db3-obe.outbound.protection.outlook.com (mail-db3lrp0081.outbound.protection.outlook.com [213.199.154.81]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DBC571A06F6; Thu, 28 Aug 2014 01:59:34 -0700 (PDT) Received: from DBXPR04CA006.eurprd04.prod.outlook.com (10.255.191.154) by AM2PR04MB0626.eurprd04.prod.outlook.com (25.160.32.152) with Microsoft SMTP Server (TLS) id 15.0.1015.19; Thu, 28 Aug 2014 08:59:32 +0000 Received: from AM1FFO11FD046.protection.gbl (2a01:111:f400:7e00::104) by DBXPR04CA006.outlook.office365.com (2a01:111:e400:9800::26) with Microsoft SMTP Server (TLS) id 15.0.1015.19 via Frontend Transport; Thu, 28 Aug 2014 08:59:31 +0000 Received: from mail.philips.com (206.191.242.68) by AM1FFO11FD046.mail.protection.outlook.com (10.174.65.209) with Microsoft SMTP Server (TLS) id 15.0.1010.11 via Frontend Transport; Thu, 28 Aug 2014 08:59:31 +0000 Received: from AMSPRD9003MB066.MGDPHG.emi.philips.com ([169.254.5.99]) by AMSPRD9003HT001.MGDPHG.emi.philips.com ([141.251.33.78]) with mapi id 14.16.0466.000; Thu, 28 Aug 2014 08:59:30 +0000 From: "Dijk, Esko" To: Pete Resnick , Barry Leiba Thread-Topic: Pete Resnick's No Objection on draft-ietf-core-groupcomm-21: (with COMMENT) Thread-Index: AQHPvU29pK3Y6qAigkiDJzR8fNmJSpvlu1yA Date: Thu, 28 Aug 2014 08:59:30 +0000 Message-ID: <031DD135F9160444ABBE3B0C36CED61836E3B99E@AMSPRD9003MB066.MGDPHG.emi.philips.com> References: <20140821121434.26081.28936.idtracker@ietfa.amsl.com> <53F6049E.8040600@qti.qualcomm.com> In-Reply-To: <53F6049E.8040600@qti.qualcomm.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [194.171.252.104] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:206.191.242.68; CTRY:US; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(6009001)(428002)(479174003)(377454003)(189002)(199003)(51704005)(374574003)(24454002)(13464003)(81542001)(90102001)(77096002)(31966008)(106466001)(107046002)(81156004)(104016003)(46102001)(74502001)(85306004)(81342001)(4396001)(230783001)(64706001)(20776003)(47776003)(66066001)(80022001)(76176999)(99396002)(561944003)(2656002)(85852003)(86362001)(55846006)(83072002)(54356999)(21056001)(50986999)(101416001)(69596002)(68736004)(19580405001)(83322001)(19580395003)(6806004)(44976005)(87936001)(15202345003)(95666004)(106116001)(105586002)(92566001)(79102001)(77982001)(76482001)(23726002)(50466002)(46406003)(97736001)(97756001)(33656002)(92726001)(15975445006)(84676001)(567094001); DIR:OUT; SFP:; SCL:1; SRVR:AM2PR04MB0626; H:mail.philips.com; FPR:; MLV:sfv; PTR:ErrorRetry; MX:1; A:1; LANG:en; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;UriScan:; X-Forefront-PRVS: 031763BCAF Received-SPF: None (protection.outlook.com: philips.com does not designate permitted sender hosts) Authentication-Results: spf=none (sender IP is 206.191.242.68) smtp.mailfrom=esko.dijk@philips.com; X-OriginatorOrg: philips.com Archived-At: http://mailarchive.ietf.org/arch/msg/core/CReVnn8kkjhN8Cp5pJBT8qBu598 Cc: "core-chairs@tools.ietf.org" , The IESG , core WG , "draft-ietf-core-groupcomm@tools.ietf.org" Subject: Re: [core] Pete Resnick's No Objection on draft-ietf-core-groupcomm-21: (with COMMENT) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Aug 2014 08:59:39 -0000 Hello Pete, Barry, Ben, (all reviewers,) Thanks for your input. Due to holidays I wasn't able to follow the groupcom= m discussion (regarding RFC2119 language) in detail; hence my late entry in= the discussion - see below. There is a consistency problem in the current text (-22). Sometimes capital= s MUST/SHOULD are used to restate an existing requirement from another RFC = (such as 7252), in other cases lowercase is used. I would like to see this = made consistent if possible. Martin prefers not repeating requirements from 7252. Ben prefers not repeat= ing requirements from 7252; but also suggests to avoid lower case versions = of 2119 words. This makes it a bit of a challenge to find the right words. = Barry did not seem to favor either approach, as long as consistent. The authors preference was repeat capitals and indicating clearly in the pa= ragraph intro that these requirements are from 7252. But given the comments= , we can remove the 2119 language in the whole document wherever a MUST/SHO= ULD/etc requirement is already specified in 7252 or another referred RFC. W= e then use the lower case version of the same word; to make it easier for u= s & future readers. Let me know whether this proposal is okay for you. Regards, Esko -----Original Message----- From: Pete Resnick [mailto:presnick@qti.qualcomm.com] Sent: Thursday, August 21, 2014 16:39 To: Barry Leiba Cc: core-chairs@tools.ietf.org; The IESG; core WG; draft-ietf-core-groupcom= m@tools.ietf.org Subject: Re: Pete Resnick's No Objection on draft-ietf-core-groupcomm-21: (= with COMMENT) On 8/21/14 9:27 AM, Barry Leiba wrote: >> 2.8: These normative behaviors and guidelines look like they could >> use >> 2119 keywords. In particular, quite a few of those "should not"s look >> like they are meant as "SHOULD NOT"s. They obviously don't need to >> be, but I was wondering if there was something I was missing. >> > That was actually due to my push-back: earlier versions had too much > SHOULD/SHOULD NOT, and used some of them in ways I thought were > inappropriate. The authors chose to resolve that by taking all the > 2119 key words out of 2.8 and 2.9 entirely. I thought that was > farther than they needed to go, but that it didn't make the result > incorrect, so I accepted it. > "The AD said something! Quick! Change it!" :-D I agree, there's nothing actively bad about the current text. But if the au= thors want an excuse to say, "See Barry, I told you we should have more SHO= ULD NOTs!", I'm there to back you up. ;-) pr -- Pete Resnick Qualcomm Technologies, Inc. - +1 (858)651-4478 ________________________________ The information contained in this message may be confidential and legally p= rotected under applicable law. The message is intended solely for the addre= ssee(s). If you are not the intended recipient, you are hereby notified tha= t any use, forwarding, dissemination, or reproduction of this message is st= rictly prohibited and may be unlawful. If you are not the intended recipien= t, please contact the sender by return e-mail and destroy all copies of the= original message. From nobody Thu Aug 28 05:45:23 2014 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E27D31A03E6; Thu, 28 Aug 2014 05:45:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yx5LA1Vznffm; Thu, 28 Aug 2014 05:45:08 -0700 (PDT) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1lrp0013.outbound.protection.outlook.com [213.199.154.13]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 35FE61A03E0; Thu, 28 Aug 2014 05:45:07 -0700 (PDT) Received: from DB3PR04CA008.eurprd04.prod.outlook.com (10.242.134.28) by AM3PR04MB0631.eurprd04.prod.outlook.com (10.255.133.152) with Microsoft SMTP Server (TLS) id 15.0.1015.19; Thu, 28 Aug 2014 12:45:04 +0000 Received: from AM1FFO11FD044.protection.gbl (2a01:111:f400:7e00::159) by DB3PR04CA008.outlook.office365.com (2a01:111:e400:9814::28) with Microsoft SMTP Server (TLS) id 15.0.1015.19 via Frontend Transport; Thu, 28 Aug 2014 12:45:03 +0000 Received: from mail.philips.com (206.191.242.68) by AM1FFO11FD044.mail.protection.outlook.com (10.174.64.233) with Microsoft SMTP Server (TLS) id 15.0.1010.11 via Frontend Transport; Thu, 28 Aug 2014 12:45:03 +0000 Received: from AMSPRD9003MB066.MGDPHG.emi.philips.com ([169.254.5.99]) by AMSPRD9003HT001.MGDPHG.emi.philips.com ([141.251.33.78]) with mapi id 14.16.0466.000; Thu, 28 Aug 2014 12:45:03 +0000 From: "Dijk, Esko" To: Jari Arkko , The IESG Thread-Topic: [core] Jari Arkko's No Objection on draft-ietf-core-groupcomm-21: (with COMMENT) Thread-Index: AQHPvUnGBjXIiqeGlkWUeHBMGNRtUpvl+LcA Date: Thu, 28 Aug 2014 12:45:03 +0000 Message-ID: <031DD135F9160444ABBE3B0C36CED61836E3BA68@AMSPRD9003MB066.MGDPHG.emi.philips.com> References: <20140821141104.19087.95662.idtracker@ietfa.amsl.com> In-Reply-To: <20140821141104.19087.95662.idtracker@ietfa.amsl.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [194.171.252.104] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:206.191.242.68; CTRY:US; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(6009001)(428002)(13464003)(52044002)(189002)(85714005)(199003)(374574003)(77096002)(97756001)(85852003)(46102001)(83072002)(76176999)(6806004)(92726001)(15975445006)(99396002)(19580395003)(86362001)(55846006)(66066001)(106116001)(80022001)(95666004)(15202345003)(64706001)(50986999)(54356999)(104016003)(74662001)(47776003)(105586002)(106466001)(230783001)(81156004)(81342001)(69596002)(33656002)(21056001)(87936001)(92566001)(68736004)(76482001)(31966008)(97736001)(74502001)(19580405001)(101416001)(79102001)(90102001)(77982001)(83322001)(84676001)(23726002)(81542001)(20776003)(46406003)(4396001)(85306004)(107046002)(50466002)(44976005)(2656002)(567094001); DIR:OUT; SFP:; SCL:1; SRVR:AM3PR04MB0631; H:mail.philips.com; FPR:; MLV:sfv; PTR:ErrorRetry; MX:1; A:1; LANG:en; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;UriScan:; X-Forefront-PRVS: 031763BCAF Received-SPF: None (protection.outlook.com: philips.com does not designate permitted sender hosts) Authentication-Results: spf=none (sender IP is 206.191.242.68) smtp.mailfrom=esko.dijk@philips.com; X-OriginatorOrg: philips.com Archived-At: http://mailarchive.ietf.org/arch/msg/core/FMzI1ENt-U2NFQzYZmcwJ_0mbmg Cc: ben Campbell , "core-chairs@tools.ietf.org" , "draft-ietf-core-groupcomm@tools.ietf.org" , "core@ietf.org" Subject: Re: [core] Jari Arkko's No Objection on draft-ietf-core-groupcomm-21: (with COMMENT) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Aug 2014 12:45:13 -0000 Hello Jari, To respond on your last review remark: > The group communication draft does not mention the observe draft, and the= observe draft does not mention multicast. Are there any feature interactio= n issues that you might want to cover? The -observe draft does not support multicast operation. It was studied a w= hile ago, but not in scope (see http://trac.tools.ietf.org/wg/core/trac/tic= ket/237 ). So at present no interaction issues. Regards, Esko -----Original Message----- From: core [mailto:core-bounces@ietf.org] On Behalf Of Jari Arkko Sent: Thursday, August 21, 2014 16:11 To: The IESG Cc: ben Campbell; core-chairs@tools.ietf.org; draft-ietf-core-groupcomm@too= ls.ietf.org; core@ietf.org Subject: [core] Jari Arkko's No Objection on draft-ietf-core-groupcomm-21: = (with COMMENT) Jari Arkko has entered the following ballot position for draft-ietf-core-groupcomm-21: No Objection When responding, please keep the subject line intact and reply to all email= addresses included in the To and CC lines. (Feel free to cut this introduc= tory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-ietf-core-groupcomm/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thank you for writing this document on this important topic. Iit is indeed = something that many users of CoAP technology are wondering about. For context, the comments below are based on the in-depth Gen-ART review fo= r this document, by Ben Campbell - thank you! I have also read the document= myself. I have also implemented multicast-based functionality for CoAP dev= ices. The document contains a lot very useful material. I do agree though with Be= n and my esteemed Area Director colleagues who have raised Discusses: the document would be better classified as Experimental at this stage. The re-classification though is something that the IESG can easily do. But Martin and Ben, for instance, have provided additional useful suggestio= ns on how to change the text itself; some changes are also necessary in my = opinion. A few more detailed comments. These are provided as-is, in the hopes that t= hey are useful. At this moment I have no specific Discuss-level requirement= s for the draft, mainly because Brian and Martin already hold Discusses tha= t I would have otherwise held. all.bldg6.example.com "all nodes in building 6" all.west.bldg6.example.com "all nodes in west wing, I have found that it is often useful to separate communications addressing = and grouping from conceptual or application-specific grouping. The gathering of nodes in a group - and the design of a network to subnets = - should be done based on communications convenience and efficiency, but it= should not necessarily dictate all application-level groups that may be ne= eded. To do so might in some cases lead to inflexibility and undue constrai= nts on the network design. It may not be convenient to put all nodes in bui= lding 6 in one group, for instance, for various reasons. I would like to ad= vocate a two-level approach, multicast for efficient reachability, but the = application decisions are still based on information about the resources (s= uch as location), rather than who answered a particular query on this mult= icast address. This also makes it easy to perform queries of any complexit= y in a reasonable manner, e.g., "all sensors that have a reading higher tha= n 27C". The non-idempotent CoAP method, POST, may only be used for group communication if the resource being POSTed to has been designed to cope with the unreliable and lossy nature of IP multicast. This is certainly possible, and in my experience, very useful. The document= would be most helpful if it could provide more guidance regarding when a = design is safe for use of POST. In the third case, typical in scenarios such as building control, a dynamic commissioning tool determines to which group a sensor or actuator node belongs, and writes this information to the node, which Please make sure the document recognises the possibility that a device may = simultaneously belong to multiple groups. Also, a form of authorization (making use of DTLS-secured CoAP [RFC7252]) MUST be used such that only authorized controllers are allowed by an endpoint to configure its group membership. Is this "MUST use a form, e.g., DTLS" or "MUST use DTLS, a form"? I'd advoc= ate the former... o A server should not accept an IP multicast request that cannot be "authenticated" in some way (cryptographically or by some multicast boundary limiting the potential sources) [RFC7252]. See Section 5.3 for examples of multicast boundary limiting methods. It is difficult for a server to know what boundary limitations may be in pl= ace in other devices around it. 2.9. Congestion Control This section talks mainly about what the servers should do. There is only o= ne rule about clients. Perhaps some additional guidance for the frequency t= hat clients can send multicast requests would be advisable, unless it is al= ready specified somewhere else. 3. Use Cases and Corresponding Protocol Flows 3.1. Introduction I would have thought discovery of devices in the other direction, i.e., a G= ET ./well-kown to all-coap-nodes would have been an interesting use case a= s well. 5. Security Considerations I'm looking in particular at Sections 5.1 through 5.3. I'd like to say that= I have had very positive experiences about using group communication with = data object security, which is quite a lot better suited for group communic= ation than transport layer solutions. No individual channels have to be est= ablished with the many group members. Messages can be signed with the autho= rity of the sender rather than tying the security to the receiver. Forwardi= ng through intermediaries retains security properties. And so on. Perhaps this alternative should be mentioned. Indeed, other than for low-se= curity applications such as discovering network components, it is difficult= to imagine completely unsecured operation, particularly considering that m= any if not most networks have a multitude of different devices in them, and= it is not in my opinion a workable long-term solution to assume a firewall= -based security model. 8. References The group communication draft does not mention the observe draft, and the o= bserve draft does not mention multicast. Are there any feature interaction = issues that you might want to cover? _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core ________________________________ The information contained in this message may be confidential and legally p= rotected under applicable law. The message is intended solely for the addre= ssee(s). If you are not the intended recipient, you are hereby notified tha= t any use, forwarding, dissemination, or reproduction of this message is st= rictly prohibited and may be unlawful. If you are not the intended recipien= t, please contact the sender by return e-mail and destroy all copies of the= original message. From nobody Thu Aug 28 05:47:05 2014 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B3D21A03E6; Thu, 28 Aug 2014 05:47:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.955 X-Spam-Level: X-Spam-Status: No, score=0.955 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.793] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zeLoiL9pG3Z8; Thu, 28 Aug 2014 05:47:02 -0700 (PDT) Received: from p130.piuha.net (unknown [IPv6:2001:14b8:400::130]) by ietfa.amsl.com (Postfix) with ESMTP id 32B4A1A03E0; Thu, 28 Aug 2014 05:47:02 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id E2FA82CEED; Thu, 28 Aug 2014 15:47:00 +0300 (EEST) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l3MKT4vpeeE8; Thu, 28 Aug 2014 15:46:57 +0300 (EEST) Received: from [127.0.0.1] (p130.piuha.net [IPv6:2a00:1d50:2::130]) by p130.piuha.net (Postfix) with ESMTP id EE88D2CEB0; Thu, 28 Aug 2014 15:46:56 +0300 (EEST) Content-Type: multipart/signed; boundary="Apple-Mail=_42842DFE-2120-4505-A82A-2357187064A9"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Jari Arkko In-Reply-To: <031DD135F9160444ABBE3B0C36CED61836E3BA68@AMSPRD9003MB066.MGDPHG.emi.philips.com> Date: Thu, 28 Aug 2014 15:46:55 +0300 Message-Id: <84034D55-095C-4A3F-A272-F54F5CD66E6D@piuha.net> References: <20140821141104.19087.95662.idtracker@ietfa.amsl.com> <031DD135F9160444ABBE3B0C36CED61836E3BA68@AMSPRD9003MB066.MGDPHG.emi.philips.com> To: "Dijk, Esko" X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/core/7Xq9apTBk7LINVrILqwnLCBqcuA Cc: ben Campbell , "core-chairs@tools.ietf.org" , The IESG , "core@ietf.org" , "draft-ietf-core-groupcomm@tools.ietf.org" Subject: Re: [core] Jari Arkko's No Objection on draft-ietf-core-groupcomm-21: (with COMMENT) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Aug 2014 12:47:04 -0000 --Apple-Mail=_42842DFE-2120-4505-A82A-2357187064A9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On 28 Aug 2014, at 15:45, Dijk, Esko wrote: > Hello Jari, >=20 > To respond on your last review remark: >> The group communication draft does not mention the observe draft, and = the observe draft does not mention multicast. Are there any feature = interaction issues that you might want to cover? >=20 > The -observe draft does not support multicast operation. It was = studied a while ago, but not in scope (see = http://trac.tools.ietf.org/wg/core/trac/ticket/237 ). So at present no = interaction issues. Ok, that makes sense. Thanks.=20 (Although the fact that it does not support multicast should perhaps be = mentioned somewhere=85 IIRC the RFC doesn=92t say that.) Jari --Apple-Mail=_42842DFE-2120-4505-A82A-2357187064A9 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJT/yS/AAoJEM80gCTQU46q4BcP/Rx6U5IIKE1dvJYM+ln2TND6 W6uwIiavwwVRPrPM4P8RouENy3Hay6KeOrBKCzSWB6cgLq67M5WBpIna24hsuF4w j6qNa4/N4M1QOn9+r0T90Kej36mGX0p6/WgtdCY56tHEYj7KPxrwiIH8Nbja2jxu 1amwVa40tRM6oBDihBMuM56VcPl9R/K8UjjKnurWjGSp4Z97wj19C196SKu3YChP Xbsjr9oxIOx4EzFlA32VdT690t0vYPjcvQpzpioJ31tDDRNeFVjbzlwVAWu55cv6 zvkfCUid+RnhyZLTYZmWqYS8jiyN1fGUGleKxeCAzDum5R19dH2GBs8kq+0pfEnE nRI768SgnhyOj865WLDGs2Eqql/M9SFTos85i+kOE1UB6ROqyqNwUMDlE6URgVwo c8cgQbjeV/Km21Lnvc6E0OIwSfoRvksEYFG9uk4gIFopZVptOHn1lmlSwTMLOs0N GQMFsZJ4OKLWdmhd6IQARt7qx1mREWjVP8zAwdpiY3APqjdOhLrbnYJ3iMll9UtK 9qX7vAfpWub7qcSom4sBSYWrHzs3Zy83qgdqlykLbvs5Wo4yiclbSUZZ0bDw27ES MOxw2nmC+bQ26TT96tgZvRnfREHMkDsgd0ajgcaWSZ3Bja/5vzvlsUTCJ0Q0EJjh xZpycd6LHzW3CfuED9Qy =EtJO -----END PGP SIGNATURE----- --Apple-Mail=_42842DFE-2120-4505-A82A-2357187064A9-- From nobody Thu Aug 28 06:53:39 2014 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7754E1A0467; Thu, 28 Aug 2014 06:53:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b5NwGnUJ83CS; Thu, 28 Aug 2014 06:53:35 -0700 (PDT) Received: from mail-la0-x22a.google.com (mail-la0-x22a.google.com [IPv6:2a00:1450:4010:c03::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F25A31A0462; Thu, 28 Aug 2014 06:53:34 -0700 (PDT) Received: by mail-la0-f42.google.com with SMTP id mc6so988656lab.15 for ; Thu, 28 Aug 2014 06:53:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=NphTPsL3XfNphE/g+8HOlyXnoWDhoMkuwktCdyOTfRs=; b=OqIc3HlO0Mu8gcXZS+5Vw+xQjqZOwFjWCwbvrVPghRefxVrShCVx5pPX+F8zqGupwM NU6xc+pmUChd86Ieis06xvmZ+YPXDB4/xSnIAL6UtRrcABjBi+jZH6x5Zg1dQhBzQrUM lDflE/HH26b4/30bPYmuEfu+2JY4qrDCTZD1gXSkjMbZtJSfYlDr78wPhAj5ipuwgEP0 813ezGKAU6FoAioDvEv1uXSD5CMfOqVBuHa1C/V02Abd6Gd9d1IR1vqzyHg0KOn88h0r wOgx780TTIEATOi5Wl59yS4PSYC5wW0ZAE3UF2x9BFWe8wZGCX854zvMCdxSvWNkKH/f m9Gg== MIME-Version: 1.0 X-Received: by 10.152.45.8 with SMTP id i8mr4502111lam.3.1409234013270; Thu, 28 Aug 2014 06:53:33 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.152.1.106 with HTTP; Thu, 28 Aug 2014 06:53:33 -0700 (PDT) In-Reply-To: <031DD135F9160444ABBE3B0C36CED61836E3B99E@AMSPRD9003MB066.MGDPHG.emi.philips.com> References: <20140821121434.26081.28936.idtracker@ietfa.amsl.com> <53F6049E.8040600@qti.qualcomm.com> <031DD135F9160444ABBE3B0C36CED61836E3B99E@AMSPRD9003MB066.MGDPHG.emi.philips.com> Date: Thu, 28 Aug 2014 09:53:33 -0400 X-Google-Sender-Auth: L9Bi47RomF1zcCNsvytHgm_bTYQ Message-ID: From: Barry Leiba To: "Dijk, Esko" Content-Type: text/plain; charset=ISO-8859-1 Archived-At: http://mailarchive.ietf.org/arch/msg/core/JUXeswLfF8bVKv2PcqwnxbloBRE Cc: Pete Resnick , "core-chairs@tools.ietf.org" , The IESG , core WG , "draft-ietf-core-groupcomm@tools.ietf.org" Subject: Re: [core] Pete Resnick's No Objection on draft-ietf-core-groupcomm-21: (with COMMENT) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Aug 2014 13:53:36 -0000 Hi, Esko. I hope you enjoyed your holidays. > Martin prefers not repeating requirements from 7252. Ben prefers not > repeating requirements from 7252; but also suggests to avoid lower > case versions of 2119 words. This makes it a bit of a challenge to > find the right words. Barry did not seem to favor either approach, as > long as consistent. > > The authors preference was repeat capitals and indicating clearly in > the paragraph intro that these requirements are from 7252. But given > the comments, we can remove the 2119 language in the whole document > wherever a MUST/SHOULD/etc requirement is already specified in 7252 or > another referred RFC. We then use the lower case version of the same > word; to make it easier for us & future readers. For my part, I think this: 1. Avoiding the use of "may", "should", and "must" as plain English words is silly, and an unfortunate artifact. I would prefer to use the right word, and explain in the 2119 boilerplate that it only applies to words in ALL CAPS. We have a number of examples where this has been done, and Ted Lemon drafted a statement about that, which the IESG never agreed upon, but which you can use as an example: http://trac.tools.ietf.org/group/iesg/trac/wiki/Draft2119BoilerplateSuggestions 2. If the main requirements really are in another document, I prefer handling it in one of two ways: 2a. Quote the requirement verbatim, and include it indented (as in a blockquote). That would include the 2119 key words, but would make it clear that it was a direct quote from 7252 (or wherever). 2b. Paraphrase the requirement from 7252, giving the sense of it but not using an exact quote. Use no 2119 key words, but send people to 7252 for the details. 2.1. In either case of 2a or 2b, include the section number(s) in the 7252 citation(s). 7252 is a big document, and it needs to be easy for the reader to find exactly what you're pointing to. (Actually, 2.1 is a good general rule here: Whenever you cite 7252 for something specific, please include a section number where the specific thing can be found. Obviously, if you're just referring to "the CoAP specification [RFC7252]", that's not specific, and this doesn't apply to that.) Barry From nobody Fri Aug 29 08:40:12 2014 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E57091A0645; Fri, 29 Aug 2014 08:39:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c3XlbaP3e87t; Fri, 29 Aug 2014 08:39:48 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2ACB21A0574; Fri, 29 Aug 2014 08:39:42 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.2.p5 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140829153942.21792.86561.idtracker@ietfa.amsl.com> Date: Fri, 29 Aug 2014 08:39:42 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/core/9_UFm7ILoxei6t0P6QqTgjwVgmE Cc: core@ietf.org Subject: [core] I-D Action: draft-ietf-core-groupcomm-23.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Aug 2014 15:39:56 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Constrained RESTful Environments Working Group of the IETF. Title : Group Communication for CoAP Authors : Akbar Rahman Esko Dijk Filename : draft-ietf-core-groupcomm-23.txt Pages : 57 Date : 2014-08-29 Abstract: The Constrained Application Protocol (CoAP) is a specialized web transfer protocol for constrained devices and constrained networks. It is anticipated that constrained devices will often naturally operate in groups (e.g., in a building automation scenario all lights in a given room may need to be switched on/off as a group). This specification defines how the CoAP protocol should be used in a group communication context. An approach for using CoAP on top of IP multicast is detailed based on both existing CoAP functionality as well as new features introduced in this specification. Also, various use cases and corresponding protocol flows are provided to illustrate important concepts. Finally, guidance is provided for deployment in various network topologies. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-core-groupcomm/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-core-groupcomm-23 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-core-groupcomm-23 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Aug 29 08:40:16 2014 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFD131A0645 for ; Fri, 29 Aug 2014 08:39:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r0FoWyRVcJQy; Fri, 29 Aug 2014 08:39:55 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 984FC1A063C; Fri, 29 Aug 2014 08:39:43 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: core-chairs@tools.ietf.org, draft-ietf-core-groupcomm@tools.ietf.org, core@ietf.org, barryleiba@computer.org, mls.ietf@gmail.com, Kathleen.Moriarty.ietf@gmail.com X-Test-IDTracker: no X-IETF-IDTracker: 5.6.2.p5 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140829153943.21792.39009.idtracker@ietfa.amsl.com> Date: Fri, 29 Aug 2014 08:39:43 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/core/rrWse9HfUHJk951cieodLLT8JuE Subject: [core] New Version Notification - draft-ietf-core-groupcomm-23.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Aug 2014 15:39:57 -0000 A new version (-23) has been submitted for draft-ietf-core-groupcomm: http://www.ietf.org/internet-drafts/draft-ietf-core-groupcomm-23.txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-core-groupcomm/ Diff from previous version: http://www.ietf.org/rfcdiff?url2=draft-ietf-core-groupcomm-23 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. IETF Secretariat. From nobody Fri Aug 29 08:46:23 2014 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D0CB1A053B for ; Fri, 29 Aug 2014 08:46:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.568 X-Spam-Level: X-Spam-Status: No, score=-2.568 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.668] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C5tT4CxzQEDo for ; Fri, 29 Aug 2014 08:46:21 -0700 (PDT) Received: from smtp-in1.interdigital.com (smtp-in1.interdigital.com [64.208.228.133]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 23ECF1A0535 for ; Fri, 29 Aug 2014 08:46:21 -0700 (PDT) X-ASG-Debug-ID: 1409327178-06daaa2edb99320001-aa7cYp Received: from smtp-out1.interdigital.com (sahara.interdigital.com [10.0.128.27]) by smtp-in1.interdigital.com with ESMTP id G7GehdTFkhlMYMK9; Fri, 29 Aug 2014 11:46:18 -0400 (EDT) X-Barracuda-Envelope-From: Akbar.Rahman@InterDigital.com Received: from SAM.InterDigital.com ([10.30.2.12]) by smtp-out1.interdigital.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 29 Aug 2014 11:46:16 -0400 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Date: Fri, 29 Aug 2014 11:46:15 -0400 X-ASG-Orig-Subj: RE: New Version Notification - draft-ietf-core-groupcomm-23.txt X-MimeOLE: Produced By Microsoft Exchange V6.5 Message-ID: In-Reply-To: <20140829153943.21792.39009.idtracker@ietfa.amsl.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: New Version Notification - draft-ietf-core-groupcomm-23.txt Thread-Index: Ac/Dn4csEseYG4zrT0Wuh5eq9QiKJgAAIvAA References: <20140829153943.21792.39009.idtracker@ietfa.amsl.com> From: "Rahman, Akbar" To: , , X-OriginalArrivalTime: 29 Aug 2014 15:46:16.0910 (UTC) FILETIME=[5EC3AEE0:01CFC3A0] X-Barracuda-Connect: sahara.interdigital.com[10.0.128.27] X-Barracuda-Start-Time: 1409327178 X-Barracuda-URL: http://10.1.245.3:8000/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at interdigital.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=9.0 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.8955 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- Archived-At: http://mailarchive.ietf.org/arch/msg/core/rnpevwkzq-vYz_BGLXXcaiGGGgo Cc: Ben Campbell , core-chairs@tools.ietf.org, draft-ietf-core-groupcomm@tools.ietf.org, core@ietf.org, The IESG Subject: Re: [core] New Version Notification - draft-ietf-core-groupcomm-23.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Aug 2014 15:46:22 -0000 SGkgTWFydGluL0thdGhsZWVuL0JhcnJ5LA0KDQoNCg0KRXNrbyBhbmQgSSBoYXZlIG1hZGUgc29t ZSBtb3JlIGNsYXJpZmljYXRpb25zIGluIHRoZSBkb2N1bWVudCAoZ3JvdXBjb21tLTIzKS4gIFRo ZSBwcmltYXJ5IG9uZXMgYmVpbmc6DQoNCiAgIG8gIFVwZGF0ZWQgcmVxdWlyZW1lbnRzIGxhbmd1 YWdlIChSRkMgMjExOSkgdG8gZm9sbG93IEJhcnJ5IExlaWJhJ3MNCiAgICAgIHN1Z2dlc3Rpb25z ICMxLCAjMmIsIGFuZCAjMi4xIGFzIHBlciAiaHR0cDovL3d3dy5pZXRmLm9yZy9tYWlsLQ0KICAg ICAgYXJjaGl2ZS93ZWIvY29yZS9jdXJyZW50L21zZzA1NTkzLmh0bWwiLg0KDQogICBvICAoVmFy aW91cyBjb21tZW50cyBmcm9tIEphcmkgb24gY2xhcmlmeWluZyByZWxhdGlvbiB0byBPYnNlcnZl LCBldGMuKQ0KDQoNCg0KQ2FuIHlvdSBwbGVhc2UgcmV2aWV3IGFuZCB0ZWxsIHVzIGlmIHlvdSBo YXZlIGFueSByZW1haW5pbmcgY29tbWVudHMgb24gdGhlIGRvY3VtZW50PyAgDQoNCkFsc28sIGFz IGEgcmVtaW5kZXI6DQoNCi0gS2F0aGxlZW4ncyBESUNTVVNTOiBQbGVhc2Ugc2VlIHBvaW50IDcg KG9mIHRoZSBjaGFuZ2UgbG9nIG9mIFJldi4gMjIpDQotIE1hcnRpbidzIERJU0NVU1M6IFBsZWFz ZSBzZWUgcG9pbnRzIDgtOSAob2YgdGhlIGNoYW5nZSBsb2cgb2YgUmV2LiAyMilhbmQgdGhlIGZp cnN0IGNoYW5nZSBhYm92ZSAoaW4gUmV2LiAyMykuDQoNCg0KDQpCZXN0IFJlZ2FyZHMsDQoNCg0K QWtiYXIgJiBFc2tvDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBpbnRlcm5l dC1kcmFmdHNAaWV0Zi5vcmcgW21haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmddIA0KU2Vu dDogRnJpZGF5LCBBdWd1c3QgMjksIDIwMTQgMTE6NDAgQU0NClRvOiBjb3JlLWNoYWlyc0B0b29s cy5pZXRmLm9yZzsgZHJhZnQtaWV0Zi1jb3JlLWdyb3VwY29tbUB0b29scy5pZXRmLm9yZzsgY29y ZUBpZXRmLm9yZzsgYmFycnlsZWliYUBjb21wdXRlci5vcmc7IG1scy5pZXRmQGdtYWlsLmNvbTsg S2F0aGxlZW4uTW9yaWFydHkuaWV0ZkBnbWFpbC5jb20NClN1YmplY3Q6IE5ldyBWZXJzaW9uIE5v dGlmaWNhdGlvbiAtIGRyYWZ0LWlldGYtY29yZS1ncm91cGNvbW0tMjMudHh0DQoNCg0KQSBuZXcg dmVyc2lvbiAoLTIzKSBoYXMgYmVlbiBzdWJtaXR0ZWQgZm9yIGRyYWZ0LWlldGYtY29yZS1ncm91 cGNvbW06DQpodHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1pZXRmLWNv cmUtZ3JvdXBjb21tLTIzLnR4dA0KDQoNClRoZSBJRVRGIGRhdGF0cmFja2VyIHBhZ2UgZm9yIHRo aXMgSW50ZXJuZXQtRHJhZnQgaXM6DQpodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9k cmFmdC1pZXRmLWNvcmUtZ3JvdXBjb21tLw0KDQpEaWZmIGZyb20gcHJldmlvdXMgdmVyc2lvbjoN Cmh0dHA6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWlldGYtY29yZS1ncm91cGNv bW0tMjMNCg0KUGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVz IGZyb20gdGhlIHRpbWUgb2Ygc3VibWlzc2lvbiB1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBh bmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IHRvb2xzLmlldGYub3JnLg0KDQpJRVRGIFNlY3JldGFy aWF0Lg0KDQo=