Re: [paws] Review of draft-ietf-paws-protocol-12 (by the other APPAD)
"Luzango Mfupe" <LMfupe@csir.co.za> Mon, 11 August 2014 12:51 UTC
Return-Path: <LMfupe@csir.co.za>
X-Original-To: paws@ietfa.amsl.com
Delivered-To: paws@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F1F01A0296 for <paws@ietfa.amsl.com>; Mon, 11 Aug 2014 05:51:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.568
X-Spam-Level:
X-Spam-Status: No, score=-0.568 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 5TAkU3yEml4s for <paws@ietfa.amsl.com>; Mon, 11 Aug 2014 05:51:18 -0700 (PDT)
Received: from ls-mx3.csir.co.za (mx-3.csir.co.za [146.64.10.248]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C06301A03CA for <paws@ietf.org>; Mon, 11 Aug 2014 05:51:12 -0700 (PDT)
Received: from pta-emo.csir.co.za (pta-emo.csir.co.za [146.64.100.109]) by ls-mx3.csir.co.za (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id s7BCowSU023242 for <paws@ietf.org>; Mon, 11 Aug 2014 14:51:00 +0200
Received: from PTA-EMO-MTA by pta-emo.csir.co.za with Novell_GroupWise; Mon, 11 Aug 2014 14:50:39 +0200
Message-Id: <53E8D83B0200009E0009B0DC@pta-emo.csir.co.za>
X-Mailer: Novell GroupWise Internet Agent 12.0.2
Date: Mon, 11 Aug 2014 14:50:35 +0200
From: Luzango Mfupe <LMfupe@csir.co.za>
To: vchen@google.com
References: <53E8D5260200009E0009B0D8@pta-emo.csir.co.za> <53E8D83B0200009E0009B0DC@pta-emo.csir.co.za>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__Part6456D20B.4__="
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.3.9 (ls-mx3.csir.co.za [146.64.10.248]); Mon, 11 Aug 2014 14:51:00 +0200 (SAST)
X-CSIR-MailScanner-Information: Please contact the ISP for more information
X-CSIR-MailScanner-ID: s7BCowSU023242
X-CSIR-MailScanner: Found to be clean
X-CSIR-MailScanner-From: lmfupe@csir.co.za
X-CSIR-MailScanner-Watermark: 1408366260.73914@Fo/58C/KoPvBpS+LLPhZrg
Archived-At: http://mailarchive.ietf.org/arch/msg/paws/WYRdVxAJ5UHtFIrDZx-WeUPZ9bE
Cc: paws@ietf.org, barryleiba@computer.org
Subject: Re: [paws] Review of draft-ietf-paws-protocol-12 (by the other APPAD)
X-BeenThere: paws@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Protocol to Access White Space database \(PAWS\)" <paws.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/paws>, <mailto:paws-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/paws/>
List-Post: <mailto:paws@ietf.org>
List-Help: <mailto:paws-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/paws>, <mailto:paws-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 11 Aug 2014 12:51:22 -0000
Hi Vince, Folks, It seems the issue of adding the single-resolution bandwidth example slipped off the cracks some how as it was supposed to be included in the current draft. Today I am presenting another burning issue relevant to the following Sections: SECTION 5.5 DeviceOwner SECTION 6.4 Example Encoding Device Owner vCard Can you please elaborate how the device owner jcard/vCard fragments should be handled within the JSON registration request message body; what primitive type(s) should be applied( i.e, String, int etc...). Apparently there is already a great deal of confusion in this area as some would thinks the card fragments should just be sent as-it-is in an array format with the rest of the JSON registration request body To the best of my understanding jcards are supposed to be written as String primitive types this allows to preserve the formatting when they are parse/read by the spectrum database/server or any other application that would wish to extract the contact information in a standardised format. Section 5.5 is silent on the definition of vCard data type(s), while the example provided in Section 6.4 shows the vCard in an array. May I suggest that we should also explicitly state the data type of jcard similar to the way we have defined data types for other aspects throughout the document (e.g., In Section 5.2 Device Descriptor)...In doing so this will clear any future confusions in the implementation of our standard. Kind Regards, Luzango. >>> Vincent Chen <vchen@google.com> 28/07/2014 18:54 >>> Hi Luzango, Thanks for your suggestions. On Sat, Jul 26, 2014 at 9:51 AM, Luzango Mfupe <lmfupe@csir.co.za> wrote: Hi Vince, Folks, I am glad to see things are moving to the right direction and hopefully soon we will finalise this work. I just found some few not very critical issues that needs some fixing in in my opinion: 5.11. Spectrum Here the document talk about the FCC and OFCOM/ETSI spectral profile presentation requirements (i.e, power levels over a set of frequency ranges. However, there is only one type of example (OFCOM/ETSI specific) that is provided throughout the document. I think we need to add another set of example that is FCC specific. Would something like this below suffice for the FCC specific example? “resolutionBwHz”: 1e5, “profiles”: [ { "Hz": 5.18e8, "Hz": 5.24e8, “dbm”: 24 ] }, Ah. I see. We can add a single resolution-bandwidth example for completeness. -- This message is subject to the CSIR's copyright terms and conditions, e-mail legal notice, and implemented Open Document Format (ODF) standard. The full disclaimer details can be found at http://www.csir.co.za/disclaimer.html. This message has been scanned for viruses and dangerous content by MailScanner ( http://www.mailscanner.info/) , and is believed to be clean. Please consider the environment before printing this email. -- This message is subject to the CSIR's copyright terms and conditions, e-mail legal notice, and implemented Open Document Format (ODF) standard. The full disclaimer details can be found at http://www.csir.co.za/disclaimer.html. This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. Please consider the environment before printing this email.
- Re: [paws] Review of draft-ietf-paws-protocol-12 … Luzango Mfupe
- Re: [paws] Review of draft-ietf-paws-protocol-12 … Vincent Chen
- Re: [paws] Review of draft-ietf-paws-protocol-12 … Luzango Mfupe
- Re: [paws] Review of draft-ietf-paws-protocol-12 … Vincent Chen