Hiya, Thanks for the review. On 19/01/18 16:47, Abdussalam Baryun wrote: > A Review for the draft > 19/01/2018 sorry for sending later than the required date. > > Thanks for the draft and hard work, and is very intersting. IMHO, the draft > needs more details to better overview, I don't think it is up to date, or > covers most gaps, we still need more references that are related more than > the draft's references used. The terminology needs to be well defining > terms for the different technologies of lpwan. The draft language needs to > be more sure, as to delete the words as possible/maybe/probable/etc. If you have specific errors you'd like to highlight or changes you'd like to suggest, as editor, I'd be happy to look those over, but for now the above isn't actionable. > > I don't think wireless technologies are better to be fixed to a star > topology. Why does the draft make LPWAN tech or the WG only for STAR > topology? please answer me. The task of the WG is not to re-invent or change LPWAN lower layers, but to figure out how to run IP over those. A star topology is what is used by some of these technologies as is mentioned in the WG charter [1] so it is IMO correct that the overview draft describes that. [1] https://tools.ietf.org/wg/lpwan/charters > IMO wireless WAN should not be fixed to STAR > topologies. usually LPWAN has advantage over the wired WAN because it can > use some different topologies not fixed. > > The draft needs to clarify the control plane and data plan issues. The > draft mixes them without focus on their implications or technology needs or > use-cases requirements. Sorry, again that's not actionable. If you have specific wording changes to suggest, or text to criticise I'll be happy to look at such comments. > > The draft should present the reasons for lack of IPv6 use in the available > technologies, That is there already, see section 4.1, paragraph 1. If that is not sufficiently obvious I'd be happy to see suggested additional text. > but also the advantages of using IPv6 in such network. I don't believe there is text for that in the document, I guess due to WG participants considering that obvious. There is text like that in the charter where it says: "To unleash the full power of LPWA technologies and their ecosystems, there is a need to couple them with other ecosystems that will guarantee the inter-working by introducing a network layer, and enable common components for management and security, as well as shared application profiles. The IETF can contribute by providing IPv6 connectivity, and propose technologies to secure the operations and manage the devices and their gateways." I'd be fine if a variant of that were included in the introduction, if that's considered useful. I guess the argument to include it is that it might make the RFC more long self-contained after the WG has finished up. OTOH, it is obvious for IETF participants, so maybe it's redundant. I'll be guided by subsequent mails, the WG chairs and AD as to whether to add such text. > > The draft needs to be sure is this LPWAN using both IPv4 and/or IPv6, and > IMO it should be only IPv6 , if so then please delete the old references of > protocols related with IPv4 (as first reference is related to IPv4). The > draft MUST reference IPv6 rfc8200 and other related technologies to the > LPWAN in gap analysis sections. I don't believe it'd be a good plan to remove the references to IPv4 protocols in this draft. If there are specific ones that you want to argue ought not be present feel free to offer specific arguments for each. Good catch on RFC8200, I'd added that as the reference for IPv6 in section 4.1. (I believe 2460 is likely still needed as I'm guessing the FAN profile is based on that and not on 8200 but I'm open to correction on that.) That change is made in the editor's copy at [2], I'll post version -08 including that when the WG chairs/AD figure it's time for that. [2] https://github.com/sftcd/lpwan-ov/blob/master/draft-ietf-lpwan-overview.txt > > The Goal stated in the draft: > The goal of the IETF LPWAN working group is to, where > necessary, adapt IETF-defined protocols, addressing schemes and > naming to this particular constrained environment. > > IMO the adaptation needs to be by both parts/directions, the environment > technologies and the IP technologies. The adaptation direction/approach > needs good reasons for best practice. You may be correct, but any adaptation of lower layers will take place elsewhere (outside the IETF) and so isn't a proper subject for this draft. > Usually the draft needs to show the > use-cases or the lpwan technologies purposes or services to users. I'd argue that more is not really needed here and that the readers of this draft are sufficiently aware of use-cases for LPWANs. But as always I'd be happy to consider suggested text. > The > draft needs to reference some work in IETF or IRTF related to network > purpose (I am not sure which now but can find..) as the TCP/IP was > developed for host to host network communication and new networks are > developed with different purposes and needs IPv6 adaptations. This > explanation needs to be solved in gap analysis. Sorry, but I don't understand what point you're making above. If you're asking that we document why we're doing IP/<foo> work for this <foo> then I don't think that's specifically needed, as defining how to run IP/<foo> seems like a core IETF thing that doesn't need justification (once we've chartered a WG for the specific <foo> thing). I'd be happy to copy text used in similar documents for previous cases where the IETF defined IP/<bar>, though I don't think that's needed or would be that useful. > > There are some protocols in page 13 or in the figure which is related to ip > but not discussed. IMO what can be missing the each lpwan technology under > IP what does it provide to IPv6/upper-layer and what does the IPv6 provides > to the under lpwan-technology? I think the answers is not clearly covered. I'm not sure what protocols or services you mean. I'd be happy to consider specific suggested text though. > > However, this work is a great work as informational, thanks It is indeed intended to be an informational document. Thanks again for the review, Cheers, S > > AB > > > > > > > On Tue, Jan 2, 2018 at 2:34 AM, The IESG <iesg-secretary@xxxxxxxx> wrote: > >> >> The IESG has received a request from the IPv6 over Low Power Wide-Area >> Networks WG (lpwan) to consider the following document: - 'LPWAN Overview' >> <draft-ietf-lpwan-overview-07.txt> as Informational RFC >> >> The IESG plans to make a decision in the next few weeks, and solicits final >> comments on this action. Please send substantive comments to the >> ietf@xxxxxxxx mailing lists by 2018-01-16. Exceptionally, comments may be >> sent to iesg@xxxxxxxx instead. In either case, please retain the >> beginning of >> the Subject line to allow automated sorting. >> >> Abstract >> >> >> Low Power Wide Area Networks (LPWAN) are wireless technologies with >> characteristics such as large coverage areas, low bandwidth, possibly >> very small packet and application layer data sizes and long battery >> life operation. This memo is an informational overview of the set of >> LPWAN technologies being considered in the IETF and of the gaps that >> exist between the needs of those technologies and the goal of running >> IP in LPWANs. >> >> >> >> >> The file can be obtained via >> https://datatracker.ietf.org/doc/draft-ietf-lpwan-overview/ >> >> IESG discussion can be tracked via >> https://datatracker.ietf.org/doc/draft-ietf-lpwan-overview/ballot/ >> >> >> No IPR declarations have been submitted directly on this I-D. >> >> >> >> >> > -- PGP key change time for me. New-ID 7B172BEA; old-ID 805F8DA2 expires Jan 24 2018. NewWithOld sigs in keyservers. Sorry if that mucks something up;-)
Attachment:
0x7B172BEA.asc
Description: application/pgp-keys
Attachment:
signature.asc
Description: OpenPGP digital signature