SCHC: Generic Framework for Static Context Header Compression and Fragmentation
draft-ietf-lpwan-ipv6-static-context-hc-24
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2020-04-08
|
24 | (System) | RFC Editor state changed to AUTH48-DONE from AUTH48 |
2020-01-30
|
24 | (System) | RFC Editor state changed to AUTH48 from RFC-EDITOR |
2020-01-29
|
24 | (System) | RFC Editor state changed to RFC-EDITOR from EDIT |
2019-12-11
|
24 | (System) | RFC Editor state changed to EDIT |
2019-12-11
|
24 | (System) | IESG state changed to RFC Ed Queue from Approved-announcement sent |
2019-12-11
|
24 | (System) | Announcement was received by RFC Editor |
2019-12-11
|
24 | (System) | IANA Action state changed to No IANA Actions from In Progress |
2019-12-11
|
24 | (System) | IANA Action state changed to In Progress |
2019-12-11
|
24 | Amy Vezza | IESG state changed to Approved-announcement sent from Approved-announcement to be sent |
2019-12-11
|
24 | Amy Vezza | IESG has approved the document |
2019-12-11
|
24 | Amy Vezza | Closed "Approve" ballot |
2019-12-11
|
24 | Amy Vezza | Ballot approval text was generated |
2019-12-11
|
24 | Suresh Krishnan | IESG state changed to Approved-announcement to be sent from IESG Evaluation::Point Raised - writeup needed |
2019-12-05
|
24 | Dominique Barthel | New version available: draft-ietf-lpwan-ipv6-static-context-hc-24.txt |
2019-12-05
|
24 | (System) | New version accepted (logged-in submitter: Dominique Barthel) |
2019-12-05
|
24 | Dominique Barthel | Uploaded new revision |
2019-11-28
|
23 | Dominique Barthel | New version available: draft-ietf-lpwan-ipv6-static-context-hc-23.txt |
2019-11-28
|
23 | (System) | New version accepted (logged-in submitter: Dominique Barthel) |
2019-11-28
|
23 | Dominique Barthel | Uploaded new revision |
2019-11-21
|
22 | Suresh Krishnan | Authors working on converting xml source to v3 |
2019-11-21
|
22 | Suresh Krishnan | IESG state changed to IESG Evaluation::Point Raised - writeup needed from IESG Evaluation::AD Followup |
2019-11-16
|
22 | Ari Keränen | Assignment of request for Early review by IOTDIR to Carsten Bormann was marked no-response |
2019-11-11
|
22 | Roman Danyliw | [Ballot comment] Thank you for addressing my DISCUSSes and COMMENTs. |
2019-11-11
|
22 | Roman Danyliw | [Ballot Position Update] Position for Roman Danyliw has been changed to No Objection from Discuss |
2019-11-01
|
22 | Benjamin Kaduk | [Ballot comment] Thank you for addressing my Discuss points! |
2019-11-01
|
22 | Benjamin Kaduk | [Ballot Position Update] Position for Benjamin Kaduk has been changed to No Objection from Discuss |
2019-10-31
|
22 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2019-10-31
|
22 | (System) | IANA Review state changed to Version Changed - Review Needed from IANA OK - No Actions Needed |
2019-10-31
|
22 | Dominique Barthel | New version available: draft-ietf-lpwan-ipv6-static-context-hc-22.txt |
2019-10-31
|
22 | (System) | New version accepted (logged-in submitter: Dominique Barthel) |
2019-10-31
|
22 | Dominique Barthel | Uploaded new revision |
2019-10-18
|
21 | Bernie Volz | Assignment of request for Early review by INTDIR to Jouni Korhonen was marked no-response |
2019-10-09
|
21 | Pascal Thubert | As required by RFC 4858, this is the current template for the Document Shepherd Write-Up. Changes are expected over time. This version is dated … As required by RFC 4858, this is the current template for the Document Shepherd Write-Up. Changes are expected over time. This version is dated 24 February 2012. (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header? => Proposed Standard. This document specifies the behaviour of a stateful encoder/decoder and fragmenter/defragmenter for extreme types of ioT links. The type is correctly indicated in the document. (2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary This document defines the Static Context Header Compression (SCHC) framework, which provides both header compression and fragmentation functionalities. SCHC has been tailored for Low Power Wide Area Networks (LPWAN). SCHC compression is based on a common static context stored in both the LPWAN devices and the network side. This document defines a header compression mechanism and its application to compress IPv6/UDP headers. This document also specifies a fragmentation and reassembly mechanism that is used to support the IPv6 MTU requirement over the LPWAN technologies. Fragmentation is needed for IPv6 datagrams that, after SCHC compression or when such compression was not possible, still exceed the layer two maximum payload size. The SCHC header compression and fragmentation mechanisms are independent of the specific LPWAN technology over which they are used. Note that this document defines generic functionalities and advisedly offers flexibility with regard to parameter settings and mechanism choices. Such settings and choices are expected to be made in other technology-specific documents. Working Group Summary => There was nothing rough about it. The WGLC comments were rich but did not show fundamental issues in the design. The 30 open tickets lead mostly to editorial changes that helped clarify the text ann avoid misinterpretation. We spent the last IETF meeting and multiple interim going through the tickets and addressed them consensually. Document Quality => The protocol was implemented and demonstrated over LoRa and SigFox technologies. There is only one vendor proposing a stack at this point. The reviewers are acknowledged in the document. The original shepherd was Dominique Barthel. He went so deep in the process, proposing edits and helping with the corrected text, that the chairs asked him to move to a co-author position, and took over shepherding, not because he was not good enough, but because he did too well at it. Personnel Document Shepherd: Pascal Thubert Responsible Area Director: Suresh Krishnan (3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG. => The shepherd performed 2 reviews, one at WGLC time, and one on version 16 which was pubished after WGLC comments wer all addressed. Considering the extent of the edition work, the chairs asked for a second WGLC, extending the WGLC to 3 weeks till the LPWAN meeting at IETF 102. (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? => No doubt. This was implemented by a team working together and layed with at IETF hackathons. (5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place. => The one element that may trigget discussion is the UDP checksum. This document emulates RFC 6282 and an implementation may elide the UDP checkum if a better protection such as a Message Inergety check of a same or larger size protects the compressed form of the UDP pseudo header and data. (6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. => The shepherd is perfectly happy with the document as it stands. Note that additional work is pending to adapt this to particular technologies, as well as to compress CoAP and other upper layer protocols. (7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why. => Yes (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. => No IPR disclosures have been submitted directly on draft-toutain-lpwan-ipv6-static-context-hc. No IPR disclosures have been submitted directly on draft-ietf-lpwan-ipv6-static-context-hc. (9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? => It is mostly the former, but there was a large working group following. (10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.) => No conflict (11) Identify any ID nits the Document Shepherd has found in this document. (See https://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough. => No nit on version 16 (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews. => No such required formal review (13) Have all references within this document been identified as either normative or informative? => Yes (14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion? => No such case (15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure. => None (16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary. => No such case (17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 5226). => No IANA requirement (18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries. => No IANA requirement (19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, etc. => No such case |
2019-09-18
|
21 | Wesley Eddy | Request closed, assignment withdrawn: Martin Stiemerling Last Call TSVART review |
2019-09-18
|
21 | Wesley Eddy | Closed request for Last Call review by TSVART with state 'Overtaken by Events' |
2019-08-26
|
21 | Gunter Van de Velde | Assignment of request for Last Call review by OPSDIR to Sheng Jiang was marked no-response |
2019-08-22
|
21 | Éric Vyncke | [Ballot comment] Thank you for addressing all my DISCUSS and COMMENTS and writing a useful and clear document. -éric |
2019-08-22
|
21 | Éric Vyncke | [Ballot Position Update] Position for Éric Vyncke has been changed to No Objection from Discuss |
2019-08-22
|
21 | Cindy Morgan | IESG state changed to IESG Evaluation::Revised I-D Needed from IESG Evaluation |
2019-08-21
|
21 | Barry Leiba | [Ballot comment] Just a couple of things that didn’t show up in other reviews: — Section 3 — LPWAN technologies have similar network architectures … [Ballot comment] Just a couple of things that didn’t show up in other reviews: — Section 3 — LPWAN technologies have similar network architectures but different terminologies. Similar to what? Do you mean “Different LPWAN technologies”, or are you comparing LPWAN technologies to something else? — Section 8.2.2.2 — o their numbers MUST increase from 0 upward, from the start of the SCHC Packet to its end. Just increase? Or increase by 1? The example in Figure 11 shows increasing by 1. If that’s a requirement, it should say. Figure 11 appears to have 29 windows, not 28, as it says. |
2019-08-21
|
21 | Barry Leiba | [Ballot Position Update] New position, No Objection, has been recorded for Barry Leiba |
2019-08-21
|
21 | Alissa Cooper | [Ballot comment] Please respond to the Gen-ART review. It seems as though RFC 8376 should be a normative reference given its use in the terminology … [Ballot comment] Please respond to the Gen-ART review. It seems as though RFC 8376 should be a normative reference given its use in the terminology section. |
2019-08-21
|
21 | Alissa Cooper | [Ballot Position Update] New position, No Objection, has been recorded for Alissa Cooper |
2019-08-21
|
21 | Benjamin Kaduk | [Ballot discuss] I wavered a lot about whether to ballot Discuss or No Objection; there are a lot of important technical and clarity-of-writing points that … [Ballot discuss] I wavered a lot about whether to ballot Discuss or No Objection; there are a lot of important technical and clarity-of-writing points that remain in the Comment section, but only a few points seemed to merit elevating to the Discuss level. That said, this remains a generally clear and useful document, so I'm looking forward to seeing it further improved. (1) I'm concerned about Section 8.2.4's recommendation for the use of a sequential counter: A sequence counter that is incremented for each new fragmented SCHC Packet, counting from 0 to up to (2^T)-1 and wrapping back to 0 is RECOMMENDED for maximum traceability and avoidance of ambiguity. It seems like there may be substantial privacy and security considerations, here -- draft-gont-numeric-ids-history has some background about similar cases in the past and links to other documents with analysis and guidance for future protocols. Shall we discuss to what extent those concerns apply here? (2) In Section 8.3.1.2, does the use of the All-1 fragment to signify the end of the packet, combined with the lack of an explicit "number of fragments" field, imply that the RCS value is the only thing (at this protocol level) preventing an attacker from inserting, from off-path, additional fragments between the penultimate "legitimate" fragment and the final fragment? (I understand that the LPWAN radio technologies generally do have some physical-layer cryptographic mechanisms, though they sometimes involve shared symmetric keys.) If the RCS is to play this pivotal a role, we need to at least document that, and arguably give stronger guidance about how it should be computed. (3) There are several places (noted, for the most part, in the Comment section) where we say that some field is optional. I think this means "optional at the profile level" as opposed to "optional at runtime", but we should be clear in the document about that. (4) There's an internal inconsistency in Section 8.4.3: In ACK-on-Error mode, windows are used. All tiles MUST be of equal size, except for the last one, which MUST be of the same size or smaller than the regular ones. If allowed in a Profile, the penultimate tile MAY be exactly one L2 Word smaller than the regular tile size. We need to reword this, as the subsequent text contradicts the initial "MUST". |
2019-08-21
|
21 | Benjamin Kaduk | [Ballot comment] It's perhaps a little interesting/surprising to see this document describe itself as just "header compression [with some fragmentation support]". Is this intended (after … [Ballot comment] It's perhaps a little interesting/surprising to see this document describe itself as just "header compression [with some fragmentation support]". Is this intended (after profiling) to be the entire IPv6 adaptation layer for the LPWAN technologies in question, or would there need to be an additional adaptation layer? If yes, would the fragmentation be a better fit there? If no, perhaps the document should reframe itself as such? Some discussion in the security considerations about detecting malformed packets by unknown Rule ID prompted me to wonder about whether there is any possibility of SCHC (i.e., IPv6) traffic coexisting with non-IP LPWAN traffic on the same (device) interface. My naive expectation is that a device would need separate interfaces for IP and non-IP traffic, but I'm not sure. Is there any benefit from mentioning such scenarios in this document? Section 1 Header compression is needed for efficient Internet connectivity to the node within an LPWAN network. The following properties of LPWAN nit: s/the node/a node/ or s/the node/nodes/ -- there's more than one node within a given LPWAN network, in the general case. This document defines generic functionality and offers flexibility with regard to parameters settings and mechanism choices. Technology-specific settings and product-specific choices are expected to be grouped into Profiles specified in other documents. Having looked briefly at RFC 8376 and the rest of this document, I worry a little bit about enabling vendor-locked "walled gardens" there a specific product defines a custom protcol and does not provide sufficient information for others to interoperate with networks of the corresponding devices. Can we do more to ensure that the resulting profiles/protocols will be interoperable with independent implementations? Section 4 o Padding (P). Extra bits that may be appended by SCHC to a data unit that it passes to the underlying Layer 2 for transmission. SCHC itself operates on bits, not bytes, and does not have any alignment prerequisite. See Section 9. Do we mandate the value of the padding bits? A forward-reference to Section 9 might be helpful. Section 5 Should there be an indication in Figure 3 that the SCHC ACK is optional (as may be made necessary by the radio technology)? Section 5.2 The operation in the Downlink direction is similar to that in the Uplink direction, only reverting the order in which the architecture elements are traversed. nit: s/reverting/reversing/ Section 6 Rule IDs identify the Rules used for Compression/Decompression or for Fragmentation/Reassembly. Is the Rule ID name(number)space shared between C/D and F/R, or do they have distinct Rule ID tables? The scope of a Rule ID is the link between the SCHC Compressor and the SCHC Decompressor, or between the SCHC Fragmenter and the SCHC Reassembler. It seems that Section 7.2 clarifies that this scope is available per-device, and the rule IDs are not shared across all devices in the LPWAN application. Would it be worth putting "per-device" in here as well? o In SCHC F/R, to identify the specific mode and settings of F/R for one direction of traffic (Up or Dw). * When F/R is used for both communication directions, at least two Rule ID values are needed for F/R, one per direction of traffic. It might be worth a forward reference here, or a note that this is so we can tell what header format to use for parsing (e.g., fragment vs. ack). Section 7.2 [...] On the network side, in order to identify the correct Rule to be applied, the SCHC Decompressor needs to associate the Rule ID with the Dev identifier. Similarly, the SCHC Compressor on the network side first identifies the destination Dev before looking for the appropriate compression Rule (and associated Rule ID) in the Context of that Dev. Does this imply that the set of Devices is known in advance at provisioning time, or will part of device onboarding be to synchronize these Rule IDs+device ID state (or are they expected to be determinable algorithmically)? Section 7.3 * The first step is to check the Field Identifiers (FID). If any header field of the packet being examined cannot be matched with a Field Description with the correct FID, the Rule MUST be disregarded. If any Field Description in the Rule has a FID that cannot be matched to one of the header fields of the packet being examined, the Rule MUST be disregarded. This seems to imply that a given Rule must encompass the entire header structure considered as input to compression, since any field in the packet not having a corresponding FID in the Rule means that the Rule is disregarded. It would be good to state this requiremnet more plainly. example could be uri-queries in CoAP. Care needs to be exercised when writing Rules containing FP=0 values. Inded, it may result in decompressed packets having fields ordered differently compared to the original packet. There may be security consequences of this if there is a checksum or other integrity protection on the original packet! * If no eligible compression Rule is found, then the header MUST be sent in its entirety using the Rule ID of the "default" Rule dedicated to this purpose. Sending an uncompressed header may require SCHC F/R. It feels like s/may require/will likely require/ might be justified, given the description of LPWAN technologies here and in RFC 8376. o Compression: each field of the header is compressed according to the Compression/Decompression Actions (CDAs). The fields are compressed in the order that the Field Descriptions appear in the Rule. [...] Compressed in the order of Field Descriptions in the rule, not the order the fields appear in in the packet, interesting. This means that the ordering of fields in the Rule is semantically important (and we should say so explicitly) but perhaps also provides a bit more flexibility of compression in the cases where the protocol header being compressed allows flexibility of representation/field ordering. o Decompression: when decompressing, on the network side the SCHC C/ D needs to find the correct Rule based on the L2 address; in this nit: the L2 address of the Dev. The receiver identifies the sender through its device-id or source identifier (e.g. MAC address, if it exists) and selects the Rule using the Rule ID. This Rule describes the compressed header format and associates the received residues to each of the header fields. For each field in the header, the receiver applies the We could perhaps stand to say a bit more about "associates the received residues to each of the header fields", since even the boundaries between received residues need to be determined based on the Rule ID and any variable field lengths. Section 7.5.3 The not-sent action can be used when the field value is specified in a Rule and therefore known by both the Compressor and the Decompressor. This action SHOULD be used with the "equal" MO. If MO is "ignore", there is a risk to have a decompressed field value different from the original field that was compressed. The security considerations should talk about the consequences of that risk. Section 7.5.5 The mapping-sent action is used to send an index (the index into the Target Value list of values) instead of the original value. This Do we need to say this is zero-indexed? Section 8.1 The L2 Word size (see Section 4) determines the encoding of some messages. SCHC F/R usually generates SCHC Fragments and SCHC ACKs that are multiples of L2 Words. Do we want to say anything about the unusual cases where it does not? Section 8.2.2.1 The figure implies that the tiles need not all be the same length; is that worth stating explicitly (in contrast to Windows, which do need to have a consistent cardinality)? Section 8.2.3 The CRC32 polynomial 0xEDB88320 (i.e. the reverse representation of the polynomial used e.g. in the Ethernet standard [RFC3385]) is I don't think that RFC 3385 is a good reference for how to interpret the hex constant as a CRC polynomial. Given the parenthetical, perhaps it's not trying to be, but I'd suggest having a CRC32 reference. Note that the concatenation of the complete SCHC Packet and the potential padding bits of the last SCHC Fragment does not generally nit(?): I keep trying to read "potential padding bits" as "these bits exist but are potentially padding bits", as opposed to the intended "any padding bits [that may potentially be present]". (Also in the rest of this paragraph.) Section 8.2.4 The Rule ID allows SCHC F/R interleaving non-fragmented SCHC Packets and SCHC Fragments that carry other SCHC Packets, or interleaving SCHC Fragments that use different SCHC F/R modes or nit(?): I don't see how just the Rule ID allows identifying Fragments that carry other Packets, in the general case (i.e., including when the same F/R mode+parameters are used for both packets). The DTag seems necessary in this case. A flow of SCHC F/R messages with a given Rule ID and DTag value pair MUST NOT interfere with the operation of a SCHC F/R instance that uses another Rule ID and DTag value pair. What does "interfere with the operation of" mean? Is this supposed to be at a spectrum level or in the reassembly process? o C (integrity Check): C is a 1-bit field. This field is used in the SCHC ACK message to report on the reassembled SCHC Packet integrity check (see Section 8.2.3). A value of 1 tells that the integrity check was performed and is successful. A value of 0 tells that the integrity check was not performed, or that is was a failure. What is the recipient of this field expected to do in response to a 1 or 0 value? (E.g., some forward references might help.) A perhaps-related question is whether "not performed" is always due to "not all fragments were present" or could be "my software is configured to not check the RCS". Figure 39 suggests that it's the former, but if so that's probably worth saying explicitly. Section 8.3.1.1 The Regular SCHC Fragment format is shown in Figure 13. Regular SCHC Fragments are generally used to carry tiles that are not the last one of a SCHC Packet. The DTag field and the W field are optional. Optional at a Profile level, or at runtime? The Fragment Payload of a SCHC Fragment with FCN equal to 0 (called an All-0 SCHC Fragment) MUST be distinguishable by size from a SCHC ACK REQ message (see Section 8.3.3) that has the same T, M and N values, even in the presence of padding. This condition is met if the Payload is at least the size of an L2 Word. This condition is also met if the SCHC Fragment Header is a multiple of L2 Words. (I think there's an implicit "and the payload is at least one bit long" in here, which may actually go without saying, but I had to think about it while verifying the last sentence.) Section 8.3.1.2 The All-1 SCHC Fragment format is shown in Figure 14. The sender generally uses the All-1 SCHC Fragment format for the message that completes the emission of a fragmented SCHC Packet. The DTag field, the W field, the RCS field and the Payload are optional. At least What does "generally" mean? When would it be used for other things? As above, are W/RCS/Payload optional at the Profile level or at runtime? Section 8.3.2 The SCHC ACK message is shown in Figure 15. The DTag field, the W field and the Compressed Bitmap field are optional. The Compressed As above, optional at the Profile level or runtime? Section 8.3.4 The SCHC Sender-Abort format is shown in Figure 21. The DTag field and the W field are optional. The FCN field is all ones. [same comment] If the W field is present, o the fragment sender MUST set it to all ones. Other values are RESERVED. o the fragment receiver MUST check its value. If the value is different from all ones, the message MUST be ignored. I'm pretty sure there are some other preconditions here, maybe including "the SCHC Fragment has no payload", as ignoring all fragments that are not All-1s is unlikely to work very well. Section 8.3.5 The SCHC Receiver-Abort format is shown in Figure 22. The DTag field and the W field are optional. As above, optional at the Profile level or runtime? o if the value is different from all ones, the fragment sender MUST ignore the message. As above, are there other preconditions here? I guess the SCHC Receiver does not send many types of fragment, so the requirements here may actually be fairly weak. (Perhaps this requirement goes better rhetorically after the final paragraph of this section?) That does raise another question, of whether (when bidirectional traffic is used) it is needed or recommended to have the traffic direction be implicit in Rule ID. Section 8.4.1 For each active pair of Rule ID and DTag values, the receiver MUST maintain an Inactivity Timer. What happens if the receiver is under-resourced to do this? Section 8.4.1.1 Each SCHC Fragment MUST contain exactly one tile in its Payload. The tile MUST be at least the size of an L2 Word. The sender MUST Including the last tile? Section 8.4.2 o Data unit out-of-sequence delivery does not occur between the entity performing fragmentation and the entity performing reassembly Is there an implicit "but data units may be lost or otherwise not delivered" here? Section 8.4.2.1 o upon receiving a SCHC ACK, * if the SCHC ACK indicates that some tiles are missing at the receiver, then the sender MUST transmit all the tiles that have been reported missing, it MUST increment Attempts, it MUST reset the Retransmission Timer and MUST await the next SCHC ACK. Are there any ACK REQs involved here? How will the receiver know to send a second SCHC ACK if only some tiles (potentially not including the last tile of the window) are being retransmitted? o on Retransmission Timer expiration, * if Attempts is strictly less that MAX_ACK_REQUESTS, the fragment sender MUST send a SCHC ACK REQ and MUST increment the Attempts counter. E.g., this text would suggest that after sending the last tile of a window, we wait for the retransmission timer's delay before sending an ACK REQ and thus inherently stall the transaction for that long. (Later on we see that the All-0 Fragment has an implicit ACK REQ semantics, but it's unclear that this works for the last tile of a retransmitted window when the bitmap remains incomplete at the receiver.) Section 8.4.2.2 On receiving a SCHC Fragment with a Rule ID and DTag pair not being processed at that time [...] On reception of any SCHC F/R message, the receiver MUST reset the Inactivity Timer. I think these statements are inconsistent about the scope of the Inactivity Timer. The latter implies that the timer is global to the recipient, but the former implies it is specific to a Rule ID/DTag pair. (Section 8.4.2, of course, is clear that it is per-Rule ID/DTag pair.) + If the Bitmap indicates that all the tiles of the current window have been correctly received, the receiver MUST increment its window counter and it enters the "acceptance phase" for that new window. Is this going to leave us in a bad state if our ACK gets dropped? * on the Bitmap becoming fully populated with 1's, the receiver MUST send a SCHC ACK for this window, it MUST increment its window counter and it enters the "acceptance phase" for the new window. [same comment] o if the window is the last window [...] * on receiving a SCHC Fragment with a W bit equal to the local W bit, [...] + otherwise, the receiver MUST update the Bitmap and it MUST assemble the tile received. If the SCHC Fragment received is an All-1 SCHC Fragment, the receiver MUST assemble the padding bits of the All-1 SCHC Fragment after the received tile. It MUST perform the integrity check. Then - if the integrity check indicates that the full SCHC Packet has been correctly reassembled, the receiver MUST send a SCHC ACK and it enters the "clean-up phase". - if the integrity check indicates that the full SCHC Packet has not been correctly reassembled, It seems that there will be some cases where we know that there remain missing tiles; do we want to say anything about that (and skipping the integrity check validation) here? Section 8.4.3.1 On Retransmission Timer expiration o if Attempts is strictly less than MAX_ACK_REQUESTS, the fragment sender MUST send either the All-1 SCHC Fragment or a SCHC ACK REQ with the W field corresponding to the last window, o otherwise the fragment sender MUST send a SCHC Sender-Abort and it MAY exit with an error condition. Having a heads-up here that there's special behavior for the receiver where the window that gets ACK'd in response to an ACK REQ may be a different window than the one indicated in the ACK REQ would help me out, as there's a few places in this section where that behavior is implicitly relied upon but it's not otherwise stated until we get o the following subsection. In a few places in this section we talk about "the All-1 SCHC Fragment", but I'm not entirely clear on whether this will always include the last tile or, in the case where the profile directs that the last tile be included in a regular fragment, there is some special format for the All-1 fragment that does not include (much) payload. Section 8.4.3.2 On receiving any SCHC F/R message, the receiver MUST reset the Inactivity Timer. As mentioned above, this statement is overly broad (and should be scoped to Rule ID/DTag matching). After receiving an All-1 SCHC Fragment, a receiver MUST check the integrity of the reassembled SCHC Packet at least every time it prepares for sending a SCHC ACK for the last window. As mentioned previously, the receiver may already know it lacks some tiles, which makes checking the integrity kind of pointless. Section 10.7.2 As described in [RFC8065], it may be undesirable to build the Dev IPv6 IID out of the Dev address. Another static value is used instead. In that case, the TV contains the static value, the MO What's the scope/duration of this other static value's usage? Section 12 Do we want/expect the network gateway to be running a firewall that only allows traffic from the Application to be relayed down to the radio network? If so, what kind of authentication mechanism could it use? In a similar vein, I note that some of the examples show the use of link-local IPv6 addressing; if the device is one end of that "link", what node is the other end, and to what extent does the link-local nature of the addressing prevent off-path traffic injection? Wireless networks are subjects to various sorts of attacks, which are not specific to SCHC. In this section, we'll assume that an attacker was able to break into the network despite the latter's security measures and that it can now send packets to a target node. What is Since this is radio, is it implicit that the send-packets ability is "from off-path"? Section 12.1 It feels like we should say something about what the endpoint will do with the bogus packet after SCHC Decompression -- does it just get passed to the application with the application left to do any sanity/authenticity checking? I sympathize with the secdir reviewer's point about mixing secret information with attacker-controlled information as compression input. That said, my sense from reading the document is that compression is applied on a per-protocol-header-field basis, which makes it unlikely that there will be secret data combined with attacker-controlled data, but I would appreciate a confirmation of that. Section 12.2 This is a really great discussion of the risks affecting the fragmentation/reassembly mechanism; thank you! I suppose we could also mention the possibility of a spoofed ACK that claims all data is received when it was not successfully received, though in practice it does not seem like that would be particularly valuable to the attacker (not least since they would probably also need to suppress the legitimate ACK that indicates some fragment loss). I also note the secdir reviewer's remark about fragmentation and packet inspection devices. I mostly expect any such devices to not be at the radio layer for these application traffic flows, but please confirm. Appendix A What is the Rule ID for "no compression applied"? Appendix C Some of these are so hard to follow that I couldn't really verify them completely. I don't really have suggestions for improving them that don't involve using substantially more vertical space, though. Appendix D What about MAX_ACK_RETRIES? Appendix E tiles. If multiple window sizes are supported, the Rule ID may signal the window size in use for a specific packet transmission. Is this really a "may" or a "must"? I don't see what else would be used to determine what width to use when parsing the fragment. Appendix F When the SCHC Fragment sender transmits the All-1 SCHC Fragment, it starts its Retransmission Timer with a large timeout value (e.g. several times that of the initial Inactivity Timer). If a SCHC ACK is received before expiration of this timer, the SCHC Fragment sender retransmits any lost SCHC Fragments reported by the SCHC ACK, or if the SCHC ACK confirms successful reception of all SCHC Fragments of the last window, the transmission of the fragmented SCHC Packet is considered complete. If the timer expires, and no SCHC ACK has been received since the start of the timer, the SCHC Fragment sender assumes that the All-1 SCHC Fragment has been successfully received (and possibly, the last SCHC ACK has been lost: this mechanism [...] This seems like it's no longer a *retransmission* timer for the All-1 fragment, since we don't retransmit when it expires; we just assume success and stop. |
2019-08-21
|
21 | Benjamin Kaduk | [Ballot Position Update] New position, Discuss, has been recorded for Benjamin Kaduk |
2019-08-21
|
21 | Mirja Kühlewind | [Ballot comment] Thanks for the well-written document! A few quick comments: 1) This text on ECN in sec 10.3: " ECN functionality depends … [Ballot comment] Thanks for the well-written document! A few quick comments: 1) This text on ECN in sec 10.3: " ECN functionality depends on both bits of the ECN field, which are the 2 LSBs of this field, hence sending only a single LSB of this field is NOT RECOMMENDED." probably belongs in section 10.2 instead, no? 2) If I understand the protocol correctly, I believe it should be a normative requirement that the Inactivity Timer is always larger than the Retransmission Timer? Related to this, Appendix F says: "The initial value of the Inactivity timer is expected to be greater than that of the Retransmission timer, in order to make sure that a (buffered) SCHC Fragment to be retransmitted can find an opportunity for that transmission. One exception to this recommendation is the special case of the All-1 SCHC Fragment transmission." I think this section should be moved into the body of the document. Further, if you need a different timer value for the All-1 SCHC Fragment, you should give this timer a distinct name and value. 3) I also agree with Alvaro that appendix E should be moved into the body of the document if you intent to specify something normatively there. 4) Editorial in Sec 10.11: "...with a strength that is identical or better to the UDP checksum." Not sure what you mean by "better"...? 5) I wondering if you want to say maybe something about pacing out different fragments (mostly when a window is used). I know that any recommendation would be technology dependent but in some cases sending a burst of packets e.g. could overload some network queues; therefore it could be good to at least mention it...? 6) Without having thought too hard about it: is it possible with this compression scheme to specify a rule that increases a counter/sequence number by 1 (given the initial value is known)? Would maybe be nice to say something about this in the document... |
2019-08-21
|
21 | Mirja Kühlewind | [Ballot Position Update] Position for Mirja Kühlewind has been changed to No Objection from No Record |
2019-08-21
|
21 | Mirja Kühlewind | [Ballot comment] 1) This text on ECN in sec 10.3: " ECN functionality depends on both bits of the ECN field, which are … [Ballot comment] 1) This text on ECN in sec 10.3: " ECN functionality depends on both bits of the ECN field, which are the 2 LSBs of this field, hence sending only a single LSB of this field is NOT RECOMMENDED." probably belongs in section 10.2 instead, no? 2) If I understand the protocol correctly, I believe it should be a normative requirement that the Inactivity Timer is always larger than the Retransmission Timer? Related to this, Appendix F says: "The initial value of the Inactivity timer is expected to be greater than that of the Retransmission timer, in order to make sure that a (buffered) SCHC Fragment to be retransmitted can find an opportunity for that transmission. One exception to this recommendation is the special case of the All-1 SCHC Fragment transmission." I think this section should be moved into the body of the document. Further, if you need a different timer value for the All-1 SCHC Fragment, you should give this timer a distinct name and value. 3) I also agree with Alvaro that appendix E should be moved into the body of the document if you intent to specify something normatively there. 4) Editorial in Sec 10.11: "...with a strength that is identical or better to the UDP checksum." Not sure what you mean by "better"...? 5) I wondering if you want to say maybe something about pacing out different fragments (mostly when a window is used). I know that any recommendation would be technology dependent but in some cases sending a burst of packets e.g. could overload some network queues; therefore it could be good to at least mention it...? 6) Without having thought too hard about it: is it possible with this compression scheme to specify a rule that increases a counter/sequence number by 1 (given the initial value is known)? Would maybe be nice to say something about this in the document... |
2019-08-21
|
21 | Mirja Kühlewind | Ballot comment text updated for Mirja Kühlewind |
2019-08-21
|
21 | Éric Vyncke | [Ballot discuss] Thank you for the hard work put into this extensive document. I have a couple of DISCUSSes and COMMENTs, all easy to be … [Ballot discuss] Thank you for the hard work put into this extensive document. I have a couple of DISCUSSes and COMMENTs, all easy to be fixed except perhaps the DISCUSS around secrion 10.7.2. Regards, -éric == DISCUSS == -- Section 10.7.2 -- It is unclear to me how the gateway and the device can share the required 'shared secret' and especially the 'DAD counter' of RFC 7217... This render the 2 paragraph confusing at best and possibly impossible to implement. |
2019-08-21
|
21 | Éric Vyncke | Ballot discuss text updated for Éric Vyncke |
2019-08-21
|
21 | Éric Vyncke | [Ballot discuss] Thank you for the hard work put into this extensive document. I have a couple of DISCUSSes and COMMENTs, all easy to be … [Ballot discuss] Thank you for the hard work put into this extensive document. I have a couple of DISCUSSes and COMMENTs, all easy to be fixed except perhaps the DISCUSS around secrion 10.7.2. Regards, -éric == DISCUSS == -- Section 3.2 -- What is the expected behavior when the "link identifier data item" does not match the length of this field? -- Section 10.3 -- I am not a transport expert but I wonder whether the text "ECN functionality depends on both bits of the ECN field,..." is at the right place? Section 10.2 would appear better to me but again I am not an transport/ECN expert. -- Section 10.7.2 -- It is unclear to me how the gateway and the device can share the required 'shared secret' and especially the 'DAD counter' of RFC 7217... This render the 2 paragraph confusing at best and possibly impossible to implement. |
2019-08-21
|
21 | Éric Vyncke | [Ballot comment] Thank you for the hard work put into this extensive document. I have a couple of DISCUSSes and COMMENTs, all easy to be … [Ballot comment] Thank you for the hard work put into this extensive document. I have a couple of DISCUSSes and COMMENTs, all easy to be fixed except perhaps the DISCUSS around secrion 10.7.2. Regards, -éric == COMMENTS == -- Section 3.1 -- Is there any use of the "link identifier length data item" as in section 3.2 the link identifier has a field for its length? -- Section 8 -- Several F/R modes are defined but none is specified as mandatory to implement. Is it worth repeating that the 'out-of-band' initialization of devices include the selected mode(s) ? -- section 8 -- It is unclear to me whether multiple fragmented packets can be sent in parallel with other fragmented or non-fragmented packets (such as fragment & interleave in order to deliver a small packet with priority). Some text around this feature (or lack of feature) would be welcome. -- section 10.8 -- If you refer to 'extension headers', then use the complete wording 'extension headers' rather than 'extensions'. == NITS == -- Section 8.4 -- Multiple figures are referred to but do not appear on the same page as the reference. This hinders the reading. -- section 10.9 -- s/port/ports/ in the title |
2019-08-21
|
21 | Éric Vyncke | [Ballot Position Update] New position, Discuss, has been recorded for Éric Vyncke |
2019-08-20
|
21 | Adam Roach | [Ballot Position Update] New position, No Objection, has been recorded for Adam Roach |
2019-08-20
|
21 | Deborah Brungard | [Ballot Position Update] New position, No Objection, has been recorded for Deborah Brungard |
2019-08-20
|
21 | Roman Danyliw | [Ballot comment] (2) Section 5.2. The text notes that the “SCHC F/R and C/D on the Network side can be located in the NGW or … [Ballot comment] (2) Section 5.2. The text notes that the “SCHC F/R and C/D on the Network side can be located in the NGW or somewhere else …”. Given the reference architecture (per Figure 1) to what part of the architecture does “somewhere else” refer? (3) Section 7.4 and 7.5, was there any WG discussion around extensibility if one wanted to add additional MOs and CDAs in the future (I have no leading suggestions on what one of these extensions might be)? Is the thinking to write another draft which updates this RFC? (4) Section 8.2.2.2. What happens if a given window doesn’t have the same number of tiles as the others? I assume you silently drop the frames. It might be worth saying that. (5) Section 8.2.3. A citation is needed for “Reassembly Check Sequence”. (6) Section 8.2.4. Per “if windows are used and what the value of WINDOW_SIZE is”, to clarify, WINDOW_SIZE is actually set via profile (per Section 8.2.2.2), and this text is simply stating that there might be a per rule WINDOW_SIZE? (7) Section 8.4.3. Per “All tiles MUST be of equal size, except for the last one, which MUST be of the same size or smaller than the regular ones. If allowed in a Profile, the penultimate tile MAY be exactly one L2 Word smaller than the regular tile size.”, it seems like these two sentences conflict. The first sentence appears to state that all MUST be of equal size (but the last one) but the second sentence then says, the second from last tile could be shorter. (8) Section 12.1. Per “As a consequence, SCHC Decompression does not amplify attacks, beyond adding a bounded …”, but also a slight increase in processing to conduct the decompression too, no? Section 12. Do LPWAN environments have the equivalent of NIDS that which could be evaded with SDHC fragmentation per Joe Salowey’s SECDIR review (https://mailarchive.ietf.org/arch/msg/secdir/p-D9T5Z2nOJ9DHox1nqLCkd2z0A) and Section 3.7 of https://tools.ietf.org/html/draft-ietf-intarea-frag-fragile-15? (9) Editorial ** The term “on the network side” is used a number of places in the document. This isn’t precisely defined anywhere. ** Section 1. Perhaps s/computer or smartphone/general-purpose computer or smartphone/, as the Devs are computers. ** Section 3. This section provides a list and simple definition of elements of the architecture and depicts their relationship in Figure 1. -- Inconsistent with the others, the Application Server has no explanation in the bulleted list -- The LPWAN-AAA is depicted in Figure 1, but not enumerated in the bulleted list of elements ** In multiple places. Typo. s/occurence/occurrence/g ** Section 7.3. Typo. s/Inded/Indeed/ ** Section 7.5.1 and 7.5.2. Typo. s/aplying/applying/ ** Figure 3 and 24: Perhaps note that the SCHC ACK is optional/as needed (given that it isn’t used by all of the modes) |
2019-08-20
|
21 | Roman Danyliw | Ballot comment text updated for Roman Danyliw |
2019-08-20
|
21 | Roman Danyliw | [Ballot discuss] (1) Section 12. The introductory text needs a bit more precision. Specifically: -- Per “Wireless networks are subjects to various sorts of attacks … [Ballot discuss] (1) Section 12. The introductory text needs a bit more precision. Specifically: -- Per “Wireless networks are subjects to various sorts of attacks , which are not specific to SCHC.”, which other security considerations are being cited here? An alternative construct would be to state that “SCHC Packets rely on the security mechanisms of … [insert relevant references]” -- Section 12. “[W]e’ll assume that an attacker was able to break into the network”, what is that precisely? Is this simply join the network? -- Section 12. Per “Our analysis equally applies to legitimate nodes ‘going crazy’”, what does that mean – compromised nodes? unexplained behavior? |
2019-08-20
|
21 | Roman Danyliw | [Ballot comment] (2) Section 5.2. The text notes that the “SCHC F/R and C/D on the Network side can be located in the NGW or … [Ballot comment] (2) Section 5.2. The text notes that the “SCHC F/R and C/D on the Network side can be located in the NGW or somewhere else …”. Given the reference architecture (per Figure 1) to what part of the architecture does “somewhere else” refer? (3) Section 7.4 and 7.5, was there any WG discussion around extensibility if one wanted to add additional MOs and CDAs in the future? Is the thinking to write another draft which updates this RFC? (4) Section 8.2.2.2. What happens if a given window doesn’t have the same number of tiles as the others? I assume you silently drop the frames. It might be worth saying that. (5) Section 8.2.3. A citation is needed for “Reassembly Check Sequence”. (6) Section 8.2.3. What is the basis of choosing that particular CRC32 polynomial? (7) Section 8.2.4. Per “if windows are used and what the value of WINDOW_SIZE is”, to clarify, WINDOW_SIZE is actually set via profile (per Section 8.2.2.2), and this text is simply stating that there might be a per rule WINDOW_SIZE? (8) Section 8.4.3. Per “All tiles MUST be of equal size, except for the last one, which MUST be of the same size or smaller than the regular ones. If allowed in a Profile, the penultimate tile MAY be exactly one L2 Word smaller than the regular tile size.”, it seems like these two sentences conflict. The first sentence appears to state that all MUST be of equal size (but the last one) but the second sentence then says, the second from last tile could be shorter. (9) Section 12.1. Per “As a consequence, SCHC Decompression does not amplify attacks, beyond adding a bounded …”, but also a slight increase in processing to conduct the decompression too, no? Section 12. Do LPWAN environments have the equivalent of NIDS that which could be evaded with SDHC fragmentation per Joe Salowey’s SECDIR review (https://mailarchive.ietf.org/arch/msg/secdir/p-D9T5Z2nOJ9DHox1nqLCkd2z0A) and Section 3.7 of https://tools.ietf.org/html/draft-ietf-intarea-frag-fragile-15? (10) Editorial ** The term “on the network side” is used a number of places in the document. This isn’t precisely defined anywhere. ** Section 1. Perhaps s/computer or smartphone/general-purpose computer or smartphone/, as the Devs are computers. ** Section 3. This section provides a list and simple definition of elements of the architecture and depicts their relationship in Figure 1. -- Inconsistently with the others, the Application Server has no explanation in the bulleted list -- The LPWAN-AAA is depicted in Figure 1, but not enumerated in the bulleted list of elements ** In multiple places. Typo. s/occurence/occurrence/g ** Section 7.3. Typo. s/Inded/Indeed/ ** Section 7.5.1 and 7.5.2. Typo. s/aplying/applying/ ** Figure 3 and 24: Perhaps note that the SCHC ACK is optional/as needed (given that it isn’t used by all of the modes) |
2019-08-20
|
21 | Roman Danyliw | [Ballot Position Update] New position, Discuss, has been recorded for Roman Danyliw |
2019-08-20
|
21 | Alvaro Retana | [Ballot comment] Please reference the appendices from the text -- only D is referenced. Are E and F intended to be normative? |
2019-08-20
|
21 | Alvaro Retana | [Ballot Position Update] New position, No Objection, has been recorded for Alvaro Retana |
2019-08-19
|
21 | Alexey Melnikov | [Ballot Position Update] New position, No Objection, has been recorded for Alexey Melnikov |
2019-08-16
|
21 | (System) | IANA Review state changed to IANA OK - No Actions Needed from Version Changed - Review Needed |
2019-08-09
|
21 | Cindy Morgan | Placed on agenda for telechat - 2019-08-22 |
2019-08-08
|
21 | Suresh Krishnan | IESG state changed to IESG Evaluation from Waiting for Writeup |
2019-08-08
|
21 | Suresh Krishnan | Ballot has been issued |
2019-08-08
|
21 | Suresh Krishnan | [Ballot Position Update] New position, Yes, has been recorded for Suresh Krishnan |
2019-08-08
|
21 | Suresh Krishnan | Created "Approve" ballot |
2019-08-08
|
21 | Suresh Krishnan | Ballot writeup was changed |
2019-08-06
|
21 | Pete Resnick | Request for Last Call review by GENART Completed: Ready with Issues. Reviewer: Pete Resnick. Sent review to list. |
2019-07-31
|
21 | Joseph Salowey | Request for Last Call review by SECDIR Completed: Ready. Reviewer: Joseph Salowey. Sent review to list. |
2019-07-23
|
21 | Dominique Barthel | New version available: draft-ietf-lpwan-ipv6-static-context-hc-21.txt |
2019-07-23
|
21 | (System) | New version approved |
2019-07-23
|
21 | (System) | Request for posting confirmation emailed to previous authors: Laurent Toutain , Ana Minaburo , Juan Zuniga , lpwan-chairs@ietf.org, Dominique Barthel , Carles Gomez |
2019-07-23
|
21 | Dominique Barthel | Uploaded new revision |
2019-07-22
|
20 | (System) | IANA Review state changed to Version Changed - Review Needed from IANA OK - No Actions Needed |
2019-07-22
|
20 | Dominique Barthel | New version available: draft-ietf-lpwan-ipv6-static-context-hc-20.txt |
2019-07-22
|
20 | (System) | New version approved |
2019-07-22
|
20 | (System) | Request for posting confirmation emailed to previous authors: Laurent Toutain , Ana Minaburo , Juan Zuniga , lpwan-chairs@ietf.org, Dominique Barthel , Carles Gomez |
2019-07-22
|
20 | Dominique Barthel | Uploaded new revision |
2019-07-19
|
19 | (System) | IESG state changed to Waiting for Writeup from In Last Call |
2019-07-15
|
19 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Joseph Salowey |
2019-07-15
|
19 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Joseph Salowey |
2019-07-15
|
19 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Sheng Jiang |
2019-07-15
|
19 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Sheng Jiang |
2019-07-12
|
19 | (System) | IANA Review state changed to IANA OK - No Actions Needed from IANA - Review Needed |
2019-07-12
|
19 | Amanda Baber | (Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs: The IANA Functions Operator has reviewed draft-ietf-lpwan-ipv6-static-context-hc-19, which is currently in Last Call, and has the following comments: We … (Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs: The IANA Functions Operator has reviewed draft-ietf-lpwan-ipv6-static-context-hc-19, which is currently in Last Call, and has the following comments: We understand that this document doesn't require any registry actions. While it's often helpful for a document's IANA Considerations section to remain in place upon publication even if there are no actions, if the authors strongly prefer to remove it, we do not object. If this assessment is not accurate, please respond as soon as possible. Thank you, Amanda Baber Lead IANA Services Specialist |
2019-07-11
|
19 | Jean Mahoney | Request for Last Call review by GENART is assigned to Pete Resnick |
2019-07-11
|
19 | Jean Mahoney | Request for Last Call review by GENART is assigned to Pete Resnick |
2019-07-10
|
19 | Wesley Eddy | Request for Last Call review by TSVART is assigned to Martin Stiemerling |
2019-07-10
|
19 | Wesley Eddy | Request for Last Call review by TSVART is assigned to Martin Stiemerling |
2019-07-05
|
19 | Amy Vezza | IANA Review state changed to IANA - Review Needed |
2019-07-05
|
19 | Amy Vezza | The following Last Call announcement was sent out (ends 2019-07-19): From: The IESG To: IETF-Announce CC: pthubert@cisco.com, Pascal Thubert , lpwan-chairs@ietf.org, Dominique Barthel … The following Last Call announcement was sent out (ends 2019-07-19): From: The IESG To: IETF-Announce CC: pthubert@cisco.com, Pascal Thubert , lpwan-chairs@ietf.org, Dominique Barthel , lp-wan@ietf.org, suresh@kaloom.com, draft-ietf-lpwan-ipv6-static-context-hc@ietf.org Reply-To: ietf@ietf.org Sender: Subject: Last Call: (Static Context Header Compression (SCHC) and fragmentation for LPWAN, application to UDP/IPv6) to Proposed Standard The IESG has received a request from the IPv6 over Low Power Wide-Area Networks WG (lpwan) to consider the following document: - 'Static Context Header Compression (SCHC) and fragmentation for LPWAN, application to UDP/IPv6' as Proposed Standard 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@ietf.org mailing lists by 2019-07-19. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document defines the Static Context Header Compression (SCHC) framework, which provides both header compression and fragmentation functionalities. SCHC has been designed for Low Power Wide Area Networks (LPWAN). SCHC compression is based on a common static context stored in both the LPWAN device and the network side. This document defines a header compression mechanism and its application to compress IPv6/UDP headers. This document also specifies a fragmentation and reassembly mechanism that is used to support the IPv6 MTU requirement over the LPWAN technologies. Fragmentation is needed for IPv6 datagrams that, after SCHC compression or when such compression was not possible, still exceed the layer-2 maximum payload size. The SCHC header compression and fragmentation mechanisms are independent of the specific LPWAN technology over which they are used. This document defines generic functionalities and offers flexibility with regard to parameter settings and mechanism choices. This document standardizes the exchange over the LPWAN between two SCHC entities. Settings and choices specific to a technology or a product are expected to be grouped into profiles, which are specified in other documents. Data models for the context and profiles are out of scope. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-lpwan-ipv6-static-context-hc/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-lpwan-ipv6-static-context-hc/ballot/ No IPR declarations have been submitted directly on this I-D. |
2019-07-05
|
19 | Amy Vezza | IESG state changed to In Last Call from Last Call Requested |
2019-07-05
|
19 | Suresh Krishnan | Last call was requested |
2019-07-05
|
19 | Suresh Krishnan | Last call announcement was generated |
2019-07-05
|
19 | Suresh Krishnan | Ballot approval text was generated |
2019-07-05
|
19 | Suresh Krishnan | Ballot writeup was generated |
2019-07-05
|
19 | Suresh Krishnan | IESG state changed to Last Call Requested from AD Evaluation::AD Followup |
2019-07-05
|
19 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2019-07-05
|
19 | Dominique Barthel | New version available: draft-ietf-lpwan-ipv6-static-context-hc-19.txt |
2019-07-05
|
19 | (System) | New version approved |
2019-07-05
|
19 | (System) | Request for posting confirmation emailed to previous authors: Laurent Toutain , Ana Minaburo , Juan Zuniga , lpwan-chairs@ietf.org, Dominique Barthel , Carles Gomez |
2019-07-05
|
19 | Dominique Barthel | Uploaded new revision |
2019-03-05
|
18 | Suresh Krishnan | The partial IoT-Dir review from Carsten Bormann requires updates to the draft. |
2019-03-05
|
18 | Suresh Krishnan | IESG state changed to AD Evaluation::Revised I-D Needed from AD Evaluation |
2019-02-25
|
18 | Ari Keränen | Request for Early review by IOTDIR is assigned to Carsten Bormann |
2019-02-25
|
18 | Ari Keränen | Request for Early review by IOTDIR is assigned to Carsten Bormann |
2019-01-21
|
18 | Ari Keränen | Request for Early review by IOTDIR is assigned to Jaime Jimenez |
2019-01-21
|
18 | Ari Keränen | Request for Early review by IOTDIR is assigned to Jaime Jimenez |
2019-01-21
|
18 | Carlos Jesús Bernardos | Request for Early review by INTDIR is assigned to Jouni Korhonen |
2019-01-21
|
18 | Carlos Jesús Bernardos | Request for Early review by INTDIR is assigned to Jouni Korhonen |
2019-01-16
|
18 | Carlos Jesús Bernardos | Request for Early review by INTDIR is assigned to Brian Haberman |
2019-01-16
|
18 | Carlos Jesús Bernardos | Request for Early review by INTDIR is assigned to Brian Haberman |
2019-01-16
|
18 | Carlos Pignataro | Assignment of request for Early review by INTDIR to Carlos Pignataro was rejected |
2019-01-16
|
18 | Carlos Jesús Bernardos | Request for Early review by INTDIR is assigned to Carlos Pignataro |
2019-01-16
|
18 | Carlos Jesús Bernardos | Request for Early review by INTDIR is assigned to Carlos Pignataro |
2019-01-13
|
18 | Carlos Jesús Bernardos | Request for Early review by INTDIR is assigned to Ron Bonica |
2019-01-13
|
18 | Carlos Jesús Bernardos | Request for Early review by INTDIR is assigned to Ron Bonica |
2019-01-08
|
18 | Carlos Jesús Bernardos | Request for Early review by INTDIR is assigned to Ted Lemon |
2019-01-08
|
18 | Carlos Jesús Bernardos | Request for Early review by INTDIR is assigned to Ted Lemon |
2019-01-05
|
18 | Carlos Jesús Bernardos | Request for Early review by INTDIR is assigned to David Lamparter |
2019-01-05
|
18 | Carlos Jesús Bernardos | Request for Early review by INTDIR is assigned to David Lamparter |
2019-01-03
|
18 | Suresh Krishnan | Requested Early review by IOTDIR |
2019-01-03
|
18 | Suresh Krishnan | Requested Early review by INTDIR |
2019-01-03
|
18 | Suresh Krishnan | IESG state changed to AD Evaluation from Publication Requested |
2018-12-14
|
18 | Pascal Thubert | As required by RFC 4858, this is the current template for the Document Shepherd Write-Up. Changes are expected over time. This version is dated … As required by RFC 4858, this is the current template for the Document Shepherd Write-Up. Changes are expected over time. This version is dated 24 February 2012. (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header? => Proposed Standard. This document specifies the behaviour of a stateful encoder/decoder and fragmenter/defragmenter for extreme types of ioT links. The type is correctly indicated in the document. (2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary This document defines the Static Context Header Compression (SCHC) framework, which provides both header compression and fragmentation functionalities. SCHC has been tailored for Low Power Wide Area Networks (LPWAN). SCHC compression is based on a common static context stored in both the LPWAN devices and the network side. This document defines a header compression mechanism and its application to compress IPv6/UDP headers. This document also specifies a fragmentation and reassembly mechanism that is used to support the IPv6 MTU requirement over the LPWAN technologies. Fragmentation is needed for IPv6 datagrams that, after SCHC compression or when such compression was not possible, still exceed the layer two maximum payload size. The SCHC header compression and fragmentation mechanisms are independent of the specific LPWAN technology over which they are used. Note that this document defines generic functionalities and advisedly offers flexibility with regard to parameter settings and mechanism choices. Such settings and choices are expected to be made in other technology-specific documents. Working Group Summary => There was nothing rough about it. The WGLC comments were rich but did not show fundamental issues in the design. The 30 open tickets lead mostly to editorial changes that helped clarify the text ann avoid misinterpretation. We spent the last IETF meeting and multiple interim going through the tickets and addressed them concensualy. Document Quality => The protocol was implemented and demonstrated over LoRa and SigFox technologies. There is only one vendor proposing a stack at this point. The reviewers are acknowledged in the document. The original shepherd was Dominique Barthel. He went so deep in the process, proposing edits and helping with the corrected text, that the chairs asked him to move to a co-author position, and took over shepherding, not because he was not good enough, but because he did too well at it. Personnel Document Shepherd: Pascal Thubert Responsible Area Director: Suresh Krishnan (3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG. => The shepherd performed 2 reviews, one at WGLC time, and one on version 16 which was pubished after WGLC comments wer all addressed. Considering the extent of the edition work, the chairs asked for a second WGLC, extending the WGLC to 3 weeks till the LPWAN meeting at IETF 102. (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? => No doubt. This was implemented by a team working together and layed with at IETF hackathons. (5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place. => The one element that may trigget discussion is the UDP checksum. This document emulates RFC 6282 and an implementation may elide the UDP checkum if a better protection such as a Message Inergety check of a same or larger size protects the compressed form of the UDP pseudo header and data. (6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. => The shepherd is perfectly happy with the document as it stands. Note that additional work is pending to adapt this to particular technologies, as well as to compress CoAP and other upper layer protocols. (7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why. => Yes (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. => No IPR disclosures have been submitted directly on draft-toutain-lpwan-ipv6-static-context-hc. No IPR disclosures have been submitted directly on draft-ietf-lpwan-ipv6-static-context-hc. (9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? => It is mostly the former, but there was a large working group following. (10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.) => No conflict (11) Identify any ID nits the Document Shepherd has found in this document. (See https://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough. => No nit on version 16 (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews. => No such required formal review (13) Have all references within this document been identified as either normative or informative? => Yes (14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion? => No such case (15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure. => None (16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary. => No such case (17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 5226). => No IANA requirement (18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries. => No IANA requirement (19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, etc. => No such case |
2018-12-14
|
18 | Pascal Thubert | Responsible AD changed to Suresh Krishnan |
2018-12-14
|
18 | Pascal Thubert | IETF WG state changed to Submitted to IESG for Publication from WG Document |
2018-12-14
|
18 | Pascal Thubert | IESG state changed to Publication Requested |
2018-12-14
|
18 | Pascal Thubert | IESG process started in state Publication Requested |
2018-12-14
|
18 | Dominique Barthel | New version available: draft-ietf-lpwan-ipv6-static-context-hc-18.txt |
2018-12-14
|
18 | (System) | New version approved |
2018-12-14
|
18 | (System) | Request for posting confirmation emailed to previous authors: Laurent Toutain , Ana Minaburo , Juan Zuniga , lpwan-chairs@ietf.org, Dominique Barthel , Carles Gomez |
2018-12-14
|
18 | Dominique Barthel | Uploaded new revision |
2018-10-22
|
17 | Dominique Barthel | New version available: draft-ietf-lpwan-ipv6-static-context-hc-17.txt |
2018-10-22
|
17 | (System) | New version approved |
2018-10-22
|
17 | (System) | Request for posting confirmation emailed to previous authors: Laurent Toutain , Ana Minaburo , lpwan-chairs@ietf.org, Carles Gomez , Dominique Barthel |
2018-10-22
|
17 | Dominique Barthel | Uploaded new revision |
2018-06-29
|
16 | Laurent Toutain | New version available: draft-ietf-lpwan-ipv6-static-context-hc-16.txt |
2018-06-29
|
16 | (System) | New version approved |
2018-06-29
|
16 | (System) | Request for posting confirmation emailed to previous authors: Laurent Toutain , Ana Minaburo , lpwan-chairs@ietf.org, Carles Gomez , Dominique Barthel |
2018-06-29
|
16 | Laurent Toutain | Uploaded new revision |
2018-06-29
|
15 | Pascal Thubert | Changed document writeup |
2018-06-29
|
15 | Laurent Toutain | New version available: draft-ietf-lpwan-ipv6-static-context-hc-15.txt |
2018-06-29
|
15 | (System) | New version approved |
2018-06-29
|
15 | (System) | Request for posting confirmation emailed to previous authors: Laurent Toutain , Ana Minaburo , lpwan-chairs@ietf.org, Carles Gomez , Dominique Barthel |
2018-06-29
|
15 | Laurent Toutain | Uploaded new revision |
2018-06-29
|
14 | Laurent Toutain | New version available: draft-ietf-lpwan-ipv6-static-context-hc-14.txt |
2018-06-29
|
14 | (System) | New version approved |
2018-06-29
|
14 | (System) | Request for posting confirmation emailed to previous authors: Laurent Toutain , Ana Minaburo , lpwan-chairs@ietf.org, Carles Gomez |
2018-06-29
|
14 | Laurent Toutain | Uploaded new revision |
2018-06-27
|
13 | Alexander Pelov | Notification list changed to Dominique Barthel <dominique.barthel@orange.com>, Pascal Thubert <pthubert@cisco.com> from Dominique Barthel <dominique.barthel@orange.com> |
2018-06-27
|
13 | Alexander Pelov | Document shepherd changed to Pascal Thubert |
2018-05-22
|
13 | Ana Minaburo | New version available: draft-ietf-lpwan-ipv6-static-context-hc-13.txt |
2018-05-22
|
13 | (System) | New version approved |
2018-05-22
|
13 | (System) | Request for posting confirmation emailed to previous authors: Laurent Toutain , Ana Minaburo , lpwan-chairs@ietf.org, Carles Gomez |
2018-05-22
|
13 | Ana Minaburo | Uploaded new revision |
2018-05-18
|
12 | Ana Minaburo | New version available: draft-ietf-lpwan-ipv6-static-context-hc-12.txt |
2018-05-18
|
12 | (System) | New version approved |
2018-05-18
|
12 | (System) | Request for posting confirmation emailed to previous authors: Laurent Toutain , Ana Minaburo , lpwan-chairs@ietf.org, Carles Gomez |
2018-05-18
|
12 | Ana Minaburo | Uploaded new revision |
2018-04-13
|
11 | Ana Minaburo | New version available: draft-ietf-lpwan-ipv6-static-context-hc-11.txt |
2018-04-13
|
11 | (System) | New version approved |
2018-04-13
|
11 | (System) | Request for posting confirmation emailed to previous authors: Laurent Toutain , Ana Minaburo , lpwan-chairs@ietf.org, Carles Gomez |
2018-04-13
|
11 | Ana Minaburo | Uploaded new revision |
2018-02-28
|
10 | Ana Minaburo | New version available: draft-ietf-lpwan-ipv6-static-context-hc-10.txt |
2018-02-28
|
10 | (System) | New version approved |
2018-02-28
|
10 | (System) | Request for posting confirmation emailed to previous authors: Laurent Toutain , Ana Minaburo , lpwan-chairs@ietf.org, Carles Gomez |
2018-02-28
|
10 | Ana Minaburo | Uploaded new revision |
2017-12-22
|
09 | Laurent Toutain | New version available: draft-ietf-lpwan-ipv6-static-context-hc-09.txt |
2017-12-22
|
09 | (System) | New version approved |
2017-12-22
|
09 | (System) | Request for posting confirmation emailed to previous authors: Laurent Toutain , Ana Minaburo , lpwan-chairs@ietf.org, Carles Gomez |
2017-12-22
|
09 | Laurent Toutain | Uploaded new revision |
2017-12-17
|
08 | Ana Minaburo | New version available: draft-ietf-lpwan-ipv6-static-context-hc-08.txt |
2017-12-17
|
08 | (System) | New version approved |
2017-12-17
|
08 | (System) | Request for posting confirmation emailed to previous authors: Laurent Toutain , Ana Minaburo , lpwan-chairs@ietf.org, Carles Gomez |
2017-12-17
|
08 | Ana Minaburo | Uploaded new revision |
2017-10-20
|
07 | Ana Minaburo | New version available: draft-ietf-lpwan-ipv6-static-context-hc-07.txt |
2017-10-20
|
07 | (System) | New version approved |
2017-10-20
|
07 | (System) | Request for posting confirmation emailed to previous authors: Laurent Toutain , Ana Minaburo , lpwan-chairs@ietf.org, Carles Gomez |
2017-10-20
|
07 | Ana Minaburo | Uploaded new revision |
2017-09-12
|
06 | Ana Minaburo | New version available: draft-ietf-lpwan-ipv6-static-context-hc-06.txt |
2017-09-12
|
06 | (System) | New version approved |
2017-09-12
|
06 | (System) | Request for posting confirmation emailed to previous authors: Ana Minaburo , Laurent Toutain , lpwan-chairs@ietf.org, Carles Gomez |
2017-09-12
|
06 | Ana Minaburo | Uploaded new revision |
2017-07-01
|
05 | Laurent Toutain | New version available: draft-ietf-lpwan-ipv6-static-context-hc-05.txt |
2017-07-01
|
05 | (System) | New version approved |
2017-07-01
|
05 | (System) | Request for posting confirmation emailed to previous authors: Ana Minaburo , Laurent Toutain , lpwan-chairs@ietf.org, Carles Gomez |
2017-07-01
|
05 | Laurent Toutain | Uploaded new revision |
2017-06-16
|
04 | Ana Minaburo | New version available: draft-ietf-lpwan-ipv6-static-context-hc-04.txt |
2017-06-16
|
04 | (System) | New version approved |
2017-06-16
|
04 | (System) | Request for posting confirmation emailed to previous authors: Ana Minaburo , Laurent Toutain , lpwan-chairs@ietf.org, Carles Gomez |
2017-06-16
|
04 | Ana Minaburo | Uploaded new revision |
2017-05-05
|
03 | Ana Minaburo | New version available: draft-ietf-lpwan-ipv6-static-context-hc-03.txt |
2017-05-05
|
03 | (System) | New version approved |
2017-05-05
|
03 | (System) | Request for posting confirmation emailed to previous authors: Ana Minaburo , Laurent Toutain , lpwan-chairs@ietf.org, Carles Gomez |
2017-05-05
|
03 | Ana Minaburo | Uploaded new revision |
2017-03-27
|
02 | Pascal Thubert | Added to session: IETF-98: lpwan Wed-1300 |
2017-03-21
|
02 | Alexander Pelov | Notification list changed to Dominique Barthel <dominique.barthel@orange.com> |
2017-03-21
|
02 | Alexander Pelov | Document shepherd changed to Dominique Barthel |
2017-03-10
|
02 | Carles Gomez | New version available: draft-ietf-lpwan-ipv6-static-context-hc-02.txt |
2017-03-10
|
02 | (System) | New version approved |
2017-03-10
|
02 | (System) | Request for posting confirmation emailed to previous authors: Ana Minaburo , Laurent Toutain , lpwan-chairs@ietf.org, Carles Gomez |
2017-03-10
|
02 | Carles Gomez | Uploaded new revision |
2017-03-01
|
01 | Ana Minaburo | New version available: draft-ietf-lpwan-ipv6-static-context-hc-01.txt |
2017-03-01
|
01 | (System) | New version approved |
2017-03-01
|
01 | (System) | Request for posting confirmation emailed to previous authors: Ana Minaburo , lpwan-chairs@ietf.org, Laurent Toutain |
2017-03-01
|
01 | Ana Minaburo | Uploaded new revision |
2017-03-01
|
01 | (System) | Request for posting confirmation emailed to previous authors: Ana Minaburo , lpwan-chairs@ietf.org, Laurent Toutain |
2017-03-01
|
01 | Ana Minaburo | Uploaded new revision |
2016-12-05
|
00 | Pascal Thubert | Changed consensus to Yes from Unknown |
2016-12-05
|
00 | Pascal Thubert | Intended Status changed to Proposed Standard from None |
2016-12-05
|
00 | Pascal Thubert | This document now replaces draft-toutain-lpwan-ipv6-static-context-hc instead of None |
2016-12-05
|
00 | Ana Minaburo | New version available: draft-ietf-lpwan-ipv6-static-context-hc-00.txt |
2016-12-05
|
00 | (System) | WG -00 approved |
2016-12-05
|
00 | Ana Minaburo | Set submitter to "Ana Minaburo ", replaces to (none) and sent approval email to group chairs: lpwan-chairs@ietf.org |
2016-12-05
|
00 | Ana Minaburo | Uploaded new revision |