Re: [core] New Version Notification - draft-ietf-core-groupcomm-24.txt

"Rahman, Akbar" <Akbar.Rahman@InterDigital.com> Thu, 11 September 2014 03:53 UTC

Return-Path: <Akbar.Rahman@interdigital.com>
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 7FE641A03C3 for <core@ietfa.amsl.com>; Wed, 10 Sep 2014 20:53:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.551
X-Spam-Level:
X-Spam-Status: No, score=-3.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-1.652] 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 TR3E-cu4MyNm for <core@ietfa.amsl.com>; Wed, 10 Sep 2014 20:53: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 2EF901A03BF for <core@ietf.org>; Wed, 10 Sep 2014 20:53:47 -0700 (PDT)
X-ASG-Debug-ID: 1410407624-06daaa6b7338210001-aa7cYp
Received: from smtp-out1.interdigital.com (sahara.interdigital.com [10.0.128.27]) by smtp-in1.interdigital.com with ESMTP id GtoILafzbs6Tyqp6 for <core@ietf.org>; Wed, 10 Sep 2014 23:53:44 -0400 (EDT)
X-Barracuda-Envelope-From: Akbar.Rahman@InterDigital.com
Received: from interdigital.com ([10.0.128.12]) by smtp-out1.interdigital.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 10 Sep 2014 23:53:39 -0400
Received: from KYANITE.InterDigital.com ([10.1.64.253]) by interdigital.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 10 Sep 2014 23:53:39 -0400
Received: from KAINITE.InterDigital.com (10.1.64.252) by KYANITE.InterDigital.com (10.1.64.253) with Microsoft SMTP Server (TLS) id 14.3.195.1; Wed, 10 Sep 2014 23:53:38 -0400
Received: from NISSONITE.InterDigital.com (10.2.64.252) by KAINITE.InterDigital.com (10.1.64.252) with Microsoft SMTP Server (TLS) id 14.3.195.1; Wed, 10 Sep 2014 23:53:38 -0400
Received: from NABESITE.InterDigital.com ([fe80::4d8a:a889:67c2:f009]) by NISSONITE.InterDigital.com ([::1]) with mapi id 14.03.0195.001; Wed, 10 Sep 2014 23:53:36 -0400
From: "Rahman, Akbar" <Akbar.Rahman@InterDigital.com>
To: Badis Djamaa <badis.djamaa@gmail.com>
Thread-Topic: [core] New Version Notification - draft-ietf-core-groupcomm-24.txt
X-ASG-Orig-Subj: RE: [core] New Version Notification - draft-ietf-core-groupcomm-24.txt
Thread-Index: Ac/GKXB9FbEdoevsQX+Xo2p7NVSgAAAAGgNwAMThTQAA+N42AAABz45wAAzdxoAABYB+kA==
Date: Thu, 11 Sep 2014 03:53:34 +0000
Message-ID: <36F5869FE31AB24485E5E3222C288E1FBD22@NABESITE.InterDigital.com>
References: <20140901211215.4887.37463.idtracker@ietfa.amsl.com> <D60519DB022FFA48974A25955FFEC08C05E3F414@SAM.InterDigital.com> <CAHbuEH5Y7LQvRPKNJGnmPZSxNd4HM=ztK=SgmvHyL-XajV9SVQ@mail.gmail.com> <CAPm4LDTJ8-LkNiFURW24qNX-t1Xj6uC8yBTTjX8iiumiJEmXgw@mail.gmail.com> <36F5869FE31AB24485E5E3222C288E1FBB16@NABESITE.InterDigital.com> <CAPm4LDRqo-Jw82o5VhoJawvdjO5Vw7m7EtT51nMyB168ni7_OA@mail.gmail.com>
In-Reply-To: <CAPm4LDRqo-Jw82o5VhoJawvdjO5Vw7m7EtT51nMyB168ni7_OA@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.1.247.32]
Content-Type: multipart/alternative; boundary="_000_36F5869FE31AB24485E5E3222C288E1FBD22NABESITEInterDigita_"
MIME-Version: 1.0
X-OriginalArrivalTime: 11 Sep 2014 03:53:39.0570 (UTC) FILETIME=[F8C61D20:01CFCD73]
X-Barracuda-Connect: sahara.interdigital.com[10.0.128.27]
X-Barracuda-Start-Time: 1410407624
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.9361 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/tbp-Zvd9NefJu0lHV5kk7uem0p4
Cc: "core@ietf.org" <core@ietf.org>
Subject: Re: [core] New Version Notification - draft-ietf-core-groupcomm-24.txt
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" <core.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/core>, <mailto:core-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/core/>
List-Post: <mailto:core@ietf.org>
List-Help: <mailto:core-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/core>, <mailto:core-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 11 Sep 2014 03:53:50 -0000

Hi Badis,


Here is my feedback for your two comments:

- Page 8

"However the port number is selected, the same port MUST be used across all CoAP servers in a group and across all
CoAP clients performing the group requests."
I did not quite get it. I think there is a missing ", if": "However the port number is selected,..." -> "However, if the port number is selected,..."

[Akbar] – Okay.  I see now how it (i.e. in Section 2.3) could be misinterpreted.  We will re-word it.  What was meant was:

“Regardless of the method of selecting the port number, the same port MUST be used across all CoAP servers in a group and across all CoAP clients performing the group requests.”



- Page 11, paragraph 2, it might be better to reference DNS-SD (RFC 6763).
[Akbar] – Somehow, I think you must be seeing a different pagination scheme then I do on my screen.  Can you clarify exactly which Section number (and paragraph) that you are referring to?   Also, please note that we did have another (perhaps related?) comment on adding RFC 6763 in the Gen-Art comment resolution:

http://www.ietf.org/mail-archive/web/core/current/msg05604.html

---------------------------------------------------------------------------------------------------------------
>> -- 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?
>>


####[Author's reply] -  Indeed, using SRV records or DNS-SD an IP
address and the port number can be returned. So we will rephrase to:
  "If the port number is not provided, then the endpoint will attempt to
look up the port number from DNS if it supports a method to do this
(e.g. SRV records or DNS-SD).   If port lookup is not supported or not
provided by DNS, the default CoAP port (5683) is assumed."
We would also need to add RFCs RFC2782 (SRV records) and RFC6763
(DNS-SD) as normative references.   We can add this in the next update
of the draft (after we hear back from the remaining IESG members).

----------------------------------------------------------------------------------------------------------------



Best Regards,


Akbar



From: Badis Djamaa [mailto:badis.djamaa@gmail.com]
Sent: Wednesday, September 10, 2014 4:59 PM
To: Rahman, Akbar
Cc: core@ietf.org
Subject: Re: [core] New Version Notification - draft-ietf-core-groupcomm-24.txt

Hi Akbar,

Thank you for the clarifications.
BTW, I have two other comments
- Page 8,

"However the port number is selected, the same port MUST be used across all CoAP servers in a group and across all
CoAP clients performing the group requests."
I did not quite get it. I think there is a missing ", if": "However the port number is selected,..." -> "However, if the port number is selected,..."

- Page 11, paragraph 2, it might be better to reference DNS-SD (RFC 6763).
All the best,
badis

On 10 September 2014 20:26, Rahman, Akbar <Akbar.Rahman@interdigital.com<mailto:Akbar.Rahman@interdigital.com>> wrote:
Hi Badis,


Thank you for your concern and question.  The current wording in the groupcomm-24 is correct (i.e. referring to running CoAP in an IP network).  This is because:



1)      Groupcomm-24 assumes CoAP runs over UDP over IP as per RFC7252 (section 3):

   “CoAP is based on the exchange of compact messages that, by default,
   are transported over UDP (i.e., each CoAP message occupies the data
   section of one UDP datagram) …  It could also be
   used over other transports such as SMS, TCP, or SCTP, the
   specification of which is out of this document's scope …”

        http://tools.ietf.org/html/rfc7252#section-3



2)      The draft that  you referenced (http://tools.ietf.org/html/draft-becker-core-coap-sms-gprs-05) is very interesting but it is not adopted as a WG draft yet.  Also, please note that even section 12 of that draft says:



   “Multicast is not possible with SMS transports.”

          http://tools.ietf.org/html/draft-becker-core-coap-sms-gprs-05#section-12




Best Regards,


Akbar



From: Badis Djamaa [mailto:badis.djamaa@gmail.com<mailto:badis.djamaa@gmail.com>]
Sent: Wednesday, September 10, 2014 9:59 AM
To: Rahman, Akbar
Cc: core@ietf.org<mailto:core@ietf.org>
Subject: Re: [core] New Version Notification - draft-ietf-core-groupcomm-24.txt

Hi Akbar,
I am reading draft-ietf-core-groupcomm-24.txt.

In the background section of the introduction you write:

"Constrained Application Protocol (CoAP) is a Representational State Transfer (REST) based web transfer protocol for      resource constrained devices operating in an IP network [RFC7252]."
I have a worry about the term "IP" in the above as CoAP can be deployed over non-IP links such as SMS (CoAP over SMS draft: http://www.ietf.org/id/draft-becker-core-coap-sms-gprs-05.txt)

best,
badis
On 5 September 2014 16:12, Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com<mailto:kathleen.moriarty.ietf@gmail.com>> wrote:
Thank you for the additional text to expand the pervasive monitoring to also include targeted monitoring threats.  The updated text looks great and I cleared my discuss.

On Mon, Sep 1, 2014 at 5:20 PM, Rahman, Akbar <Akbar.Rahman@interdigital.com<mailto:Akbar.Rahman@interdigital.com>> wrote:
Hi Martin/Kathleen/Barry,



We fixed one small but important point (in groupcomm-24):

   o  Clarified in section 2.6.1.2 (Configuring Members) that ABNF rules
      from Section 3.2.2 of [RFC 3986] should be used for the IP address
      parsing.


Can you please review and tell us if you have any remaining comments on the document?

Also, as a reminder:

- Kathleen's DICSUSS: Please see point 7 (of the change log of Rev. 22)
- Martin's DISCUSS: Please see points 8-9 (of the change log of Rev. 22)and point 1 (of the change log of Rev. 23).



Best Regards,


Akbar & Esko

-----Original Message-----
From: internet-drafts@ietf.org<mailto:internet-drafts@ietf.org> [mailto:internet-drafts@ietf.org<mailto:internet-drafts@ietf.org>]
Sent: Monday, September 01, 2014 5:12 PM
To: core-chairs@tools.ietf.org<mailto:core-chairs@tools.ietf.org>; draft-ietf-core-groupcomm@tools.ietf.org<mailto:draft-ietf-core-groupcomm@tools.ietf.org>; core@ietf.org<mailto:core@ietf.org>; barryleiba@computer.org<mailto:barryleiba@computer.org>; mls.ietf@gmail.com<mailto:mls.ietf@gmail.com>; Kathleen.Moriarty.ietf@gmail.com<mailto:Kathleen.Moriarty.ietf@gmail.com>
Subject: New Version Notification - draft-ietf-core-groupcomm-24.txt


A new version (-24) has been submitted for draft-ietf-core-groupcomm:
http://www.ietf.org/internet-drafts/draft-ietf-core-groupcomm-24.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-24

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<http://tools.ietf.org>.

IETF Secretariat.



--

Best regards,
Kathleen

_______________________________________________
core mailing list
core@ietf.org<mailto:core@ietf.org>
https://www.ietf.org/mailman/listinfo/core