<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=Windows-1252">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<p><font face="Helvetica, Arial, sans-serif">Thank you for the contribution. I have a few comments for consideration of the proposers and the group based on review of the document.</font></p>
<p><font face="Helvetica, Arial, sans-serif">Figure 4.1-1 titled "Scope defined by this section" indicates MAC and RLMM interface parts are included in scope. This conflicts with the text in 4.1 which states that this section defines the PHY layer. This may
be the wrong figure for this document?</font></p>
<p>Table 4.3-2 titled "RF Capabilities:</p>
<p>(1) RF12.4 clause 8.1.2.10.2 does not define an RF capability. It describes PIB structure for which there is no defined operation or behavior (essentially a "write and ignore" set of PIB attributes). Thus it is unclear what is proposed.
<br>
</p>
<p>(2) RF 12.5, 12.6 and RF13 suggest a small subset of bands defined in the current standard and the current Wi-SUN PHY specification. Is the intention to limit RLMM to a single band as indicated in RF13.4? Would it be more appropriate to reference the Wi-SUN
PHY specification, indicating the PHY modes and bands expected to be implemented by an RLMM device?</p>
<p>(3) RF14.4 The "MR-FKS mode switching" as defined in 802.15.4 is not safe to enable in a receive;, it is highly advisable to instead mandate that the MS field in the PHR be ignored upon reception (treated as defined for RESERVED fields in the standard).<br>
</p>
Table 4.3-3 Functional Device Types: all entries except FD8 in this table are referencing MAC features, and seems out of scope as stated in 4.1 of this document (PHY layer). The last entry, FD8, is does not indicate a specific normative requirement. The
term "SUN PHY device" is not defined in clause 8.1 of 802.15.4g-2012, only in the PICS pro-forma which is an informative clause and does not define specific requirements; the term "SUN device" is defined informatively in 3.1, and used in specific normative
requirements throughout clause 5 and in 18.1, which is my guess as to what was intended, however in 18.1 the specific requirement is to support CSM, which is covered in RF12.5 in Table 4.3-2 of the document.
<br>
<br>
Hope that the proposers and group find this helpful.<br>
Best regards and HAPPY NEW YEAR!<br>
Ben<br>
<br>
<div class="WordSection1">
<hr>
<table class="MsoNormalTable" style="width:265.5pt;margin-left:10pt;background:#F7F3E5;border-collapse:
collapse;border:none" border="1" cellpadding="0" cellspacing="0" width="443">
<tbody>
<tr style="height:52.5pt">
<td style="width:117.0pt;border:none;border-top:solid
#FFF2CC 1.5pt; padding:0in 5.4pt 0in 5.4pt;height:52.5pt" width="195">
<p class="MsoNormal"><br>
Benjamin A. Rolfe<br>
408-332-0725 Mobile<br>
408-395-7207 Office</p>
</td>
<td style="width:148.5pt;border:none;border-top:solid
#FFF2CC 1.5pt; padding:0in 5.4pt 0in 5.4pt;height:52.5pt" width="248">
<p class="MsoNormal"><span style="position:absolute;z-index:251657216;
margin-left:2px;margin-top:0px;width:226px;height:133px"><br>
</span></p>
</td>
</tr>
</tbody>
</table>
<p class="MsoNormal"> </p>
</div>
<br>
<br>
<div class="moz-cite-prefix">On 12/27/2016 6:54 PM, Ryota Yamada wrote:<br>
</div>
<blockquote cite="mid:8d8ff0e6-734e-d47f-aeba-b8ef62c785ad@ari.ncl.omron.co.jp" type="cite">
Dear Kunal-san, <br>
<br>
I am sorry to be late. The proposal for PHY WG to include RLMM Profile in PHY TPS has been reviewed in RLMM WG. I would like to provide the latest version of the proposal as an official input from RLMM WG to PHY WG. The document is available from here:
<br>
<a class="moz-txt-link-freetext" href="https://dms.wi-sun.org/htcomnet/Handlers/Download.ashx?action=download&file=M2MIG%2F20161228-Wi-SUN-RLMM-Profile-1v00-PHY-0v03.doc">https://dms.wi-sun.org/htcomnet/Handlers/Download.ashx?action=download&file=M2MIG%2F20161228-Wi-SUN-RLMM-Profile-1v00-PHY-0v03.doc</a>
<br>
<br>
Best regards, <br>
Ryota <br>
<br>
<br>
</blockquote>
<br>
</body>
</html>