Re: [lp-wan] Review of draft-ietf-lpwan-ipv6-static-context-hc-03

Hello Diego, 

thanks for the comments, perhaps some clarifications

> On 22 May 2017, at 04:35, Prof. Diego Dujovne <diego.dujovne@mail.udp.cl> wrote:
> 
> Dear all,
>              I post here the review of draft-ietf-lpwan-ipv6-static-context-hc-03
> from the beginning until Section 7 (included). I will go on with the remaining part of
> the draft in the following days.
> Regards,
> 
>                                                Diego
> 
> 
> 
> Abstract
> 
> - "Static context means that information stored in the context which, describes field values," 
> 
> I would take out the first comma.
> 
> - "does not change during the packet transmission"
> 
> I would remove "the"
> 
> - " Similar mechanisms for other protocols such as CoAP will be described in a separate document."
> 
> I would put "separate documents" since you are talking about other protocols, no only CoAP.
> 
> - "the L2 pdu size"
> 
> I would put PDU with capital letters.
> 
> 
> 
> Introduction
> 
> - "Topology is star oriented, therefore all the packets follow the same path."
> 
> First, I would add a hyphen: star-oriented. 
> Second, there is no specific discussion if stars of stars will ever be supported, or if this draft only applies to a star topology. In this case, star-oriented can be both star of stars and star.
> 
> - "SCHC uses a context where header information is kept in order." 
> 
> Is there any other scheme where the header information is not kept in order?

The idea was to be clear about how to put information on the context, there is no other scheme, but the information can be put in any order if it is not specified, so we believe that to be clear we need to said at least once that the information is kept in the format order of the original protocol.
> 
> -  "(the values on the header fields do not change during time)"
> 
> I would suggest "do not change over time"
> 
> The introduction does not introduce fragmentation as the abstract does.
> 
> - "The SCHC header compression is indedependent"
> 
> Typo: independent.
> 
> - "On the other hand,"
> 
> Is it needed the "On the one hand" statement previously to use this expression?
> 
> - "not support layer two fragmentation"
> 
> This is not coherent with the notation on the abstract -> change to L2.
> 
> Just for the sake of clarity, from the introduction, I can deduce this draft only concentrates on a protocol and a mechanism. The protocol is SCHC and the mechanism is Fragmentation. The protocol usage is justified by two properties of LPWANs and the mechanism is justified by the lack of support on part of the LPWAN technologies.    

I’m not sure I have understand you. But the SCHC header compression must be used always, and only if needed the fragmentation part will be applied. Both may be considered as protocols, or mechanisms, both parts are together in the same place and you will use one or both as needed. 
Perhaps we need to modify the introduction to be clear
> 
> Vocabulary
> -"Vocabulary"
> Isn't this "Terminology"?
> - "DEV: Device.  Node connected to the LPWAN.  A DEV may implement SCHC."
> I can conclude that devices with and without SCHC can coexist. This should be mentioned on the Introduction.
> - "An application sending/consuming IPv6"
> AFAIK, the term "consumer" comes from the Content-Centric Networking environment; I think this should be changed to "receiving", or, the other way round, "sending/consuming" should be changed to "producing/consuming", just to keep coherence. 
> - "flow.  Rule ID is sent on the LPWAN."
> "The Rule ID is"...
> - "MO: Matching Operator.  An operator used to compare a value contained in a header field with a value contained in a rule." 
> - "TV: Target value.  A value contained in the rule that will be      matched with the value of a header field."
> Does the matching operator compare the Target Value (TV) with the value of the header field? I think it would be better to use the terminology already on MO. Do you use "match" and "compare" as synonyms?
> 
> Static Context Header Compression
> - "compression mechanisms such as RoHC." 
> 
> This is the first time RoHC appears on the text. Can you put a reference to the corresponding RFC?
> 
> - "provisionning protocol"
> 
> provisioning
> 
> - From figure 1, 
> 
> The Radio Gateway was not defined on the local Terminology, while the rest of the used blocks is defined there.
> 
> - "applications which produce IPv6"
> 
> Here the term producer is used as I mentioned before. Maybe the idea to "produce" is better than to "send" flows.
> 
> - "the headers size"
> 
> I would keep here "header size" as a generic expression.
> 
> - "shares the same rules with the DEV"
> 
> Then, on Figure 1 it should say "DEV" instead of "DEVICE"
> 
> - " or in another places"
> 
> I would write "or in another place" or in "or in another intermediate place"
> 
> - "if a tunnel is established between the NGW and the SCHC C/D"
> 
> I would write "as long as a tunnel is" I think it shows better the need to put a tunnel because of the placement of the SCHC C/D far away from the NGW. The "if" statement makes  me understand that the tunnel was before the SCHC C/D location and not as a consequence of this action.
> 
> - "This architecture forms a star topology."
> 
> This architecture is applicable only to a star topology. Is the star topology a consequence of SCHC?
> 
> - "After decompression, the packet can be sent on the Internet to one or several LPWAN Application Servers (APP)."
> 
> On this stage, the packet is rebuilt according to the IPv6 structure. The draft does not mention any multicast capability or if the resulting packets will be unicast only. If one or many application servers can be reached, this should be specified.
> 
> - "The principle is exactly the same in the other direction."
> 
> This means that unicast or multicast are possible towards the node side.
> 
> - "field identifier (FID), a field position (FP), a direction indicator (DI)" 
> 
> Although it is defined just after, this should be on the terminology too, as the other terms used on the draft.  
> 
> - " Figure 2: Compression Decompression Context" 
> 
> To be coherent to the rest of the text, this should be "Compression/Decompression"
> 
> - "the description of the header field must be done in the same order they appear in the packet."
> 
> "must be executed in the same order that appears on the packet"
> 
> I think that it must be said somewhere that both the SCHC Compressor / Decompressor MUST share the same set of rules. 
> 
> - "On the other hand, the rule describes the compressed header which are
>    transmitted regarding their position in the rule which is used for
>    data serialization on the compressor side and data deserialization on
>    the decompressor side."
> 
> "describes the compressed header which is"
> 
> - "Regarding their" 
> 
> Who are they?
> 
> I do not understand what can be in a different order than the order established by the packet header.  Being the SCHC C/D, I will not understand what to decompress and how if the order is changed. 

We want to block the order you put information in the context, so that’s why we talk about order, if the ML think it is not important to leave this clear, we can delete this part, but I believe that if it is not define you can create your context as you want.
> 
> - "The main idea of the compression scheme is to send the rule id to the
>    other end instead of known field values.  When a value is known by
>    both ends, it is not necessary to send it on the LPWAN network."
> 
> I think this is the key to this draft. This should be on the 
> introduction/abstract too.
> 
> - "A Field Position (FP) indicating if several instances of the field
>       exist in the headers which one is targeted."
> 
> This expression is not clear. I imagine that this is an index to
> reference each of the instances of the field.

In some protocols the value of a field may be divided in different parts of the header, so you need too specify to which part you are referring. 

In this part we are trying to develop the complete tools for the SCHC compression of any protocol
> 
> - "A Target Value (TV) is the value used to make the comparison with
>       the packet header field.  The Target Value can be of any type
>       (integer, strings,...).  It can be a single value or a more
>       complex structure (array, list,...).  It can be considered as a
>       CBOR structure."
> 
> Here I have a conflict on the idea of header field and value. I can 
> interpret that the intention is that a field has a value and 
> the target value is compared against the field value, and not the
> name of the field. But it needs to be rewritten.
One thing is the field name and other thing is its value.
The TV is the value that is in the Context, this value has been given to this context before transmission as a configuration and it is not the value in the packet header. 
> When is it going to be represented as a CBOR structure and when not?
When you want
> Is there a bit for each field on each rule saying so? If not, it is
No, the Rule-ID will give this difference
> not clear when to interpret it as a CBOR structure and when not. This
> applies to all the cases when the text says CBOR can be used.
> Another general question is why it is specified that the TV, MO and
> CDA may require some parameters which can be CBOR: Are these parameters specified on this draft or in any other draft? If they are, they should be referenced. On the end of section 4 there are a number
> of parameters specified, but none of them are defined if they are CBOR or not.
> 
> - "The size of the rule ID is not specified in this document and can
>    vary regarding the LPWAN technology, the number of flows,…"
> 
> This text must state that the rule ID value is implementation-specific.
> If there are no more items to add at the end, it is better to replace 
> the "..." with "among others".
> 
> - "Some values in the rule ID space may be reserved for goals other than
>    header compression, for example fragmentation."
> 
> Fragmentation was added to this draft recently. It can be specified here
> if there are any Rule IDs reserved for fragmentation and remove the
> example.
> 
> 
> Packet processing
> 
> - "(excluding unappropriate direction or position)"
> 
> The text before this expression says that the matching is done
> using direction and position, and this excludes this from the
> comparison (saying even unapproriate direction or position will
> match). If this is not the correct interpretation, it is misleading.
> 
> - "In the downstrean direction, the rule is also used to find the
>       device ID."
> 
> Better to add "as explained on section 5.5
>  
> - "sent in the first byte of the L2 payload." 
> 
> This is the first limitation: It must be said here that, if there
> are compressed values to include in the payload, they MUST use, at most 1 byte. Is it
> the correct way to interpret this limitation?
> 
> -  "associates these values to header fields"
> 
> Which values? It may better to write: "associates the values to header fields"
> 
> Matching operators
> 
> - "This document describes basic matching operators" 
> 
> "This section describes"...
> 
> - "SCHC C/D, endpoints"
> 
> Eliminate the comma.
> 
> - "equal: a field value in a packet matches with a field value in a
>       rule if they are equal"
> 
> Is any of those values a TV?
No, The SCHC C/D are actions in order to decide which information will be sent
> 
> - "MSB(length): a field value of a size equal to "length" bits in a
>       packet matches with a field value in a rule if the most
>       significant "length" bits are equal."
> 
> Can this be rewritten to: "TV where the <length> MSBs match 
> the <length> MSBs of the field value on a rule" ? 
> Am I missing something?   
> 
> - "match-mapping: The goal of mapping-sent is to reduce"
> 
> mapping-sent is defined after as an action. It may be better to write 
> "The goal of match-mapping is"...
> Furthermore, it must be said that the field values MUST be unique, or 
> that the it matches the first occurrence, in order to avoid ambiguities.
> 
> - "Matching Operators and match-mapping needs"
> 
> match-mapping is a matching operator: "Matching operators need"
> 
> - "Figure 4: Compression and Decompression Functions"
> 
> Are tables used or only figures? This should be a Table.
> 
> - "may be sent with the compressed header."
> 
> How to add the field size on the compressed header?
> 
> - "for that field on which compression is applied."
> 
> "for the field"...
> 
> - "number of bit sent"
> 
> number of bits sent
> 
> - "Compute-*"
> 
> Is not on the table. (Figure 4)
> 
> - "These functions are used by the decompressor"
> 
> I think it may be better to rewrite it as: "This class of functions is used by the decompressor"...
> 
> - "during the compression and reconstructed during the decompression."
> 
> Remove "the" on both instances.
> 
> - "compute a checksum from the information already received by the SCHC C/D"
> 
> "compute the checksum". "a checksum" is too generic. Also "the information" is too generic. Is
> it the packet? 
> 
> 
> Application to IPv6 and UDP headers
> 
> 
> -"CDA must be "not-sent."
> 
> Double quote is missing.
> 
> - "the first one there is
>    without compression and the original value is sent, or the sencond
>    where the values can be computed by sending only the LSB bits:"
> 
> "the first one is not to use compression, thus the original"... 
> change "sencond" for "second"
> 
> - "TV is not set"
> 
> Does this mean it is empty?
> 
> - "The SCHC C/D recompute the original"
> 
> "recomputes"
> 
> -  "If the payload is small"
> 
> It is not clear what is small: there may be gain even with a 15-bit
> payload length, however, the packet becomes too long and will need
> fragmentation.
> 
> - "since there is no IP forwarding between the DEV and the
>    SCHC C/D"
> 
> However, the Hop limit can be set by the DEV to forward
> a packet towards beyond the SCHC C/D to any value.
> 
> - "For privacy reasons or if the DEV address is changing over time, it
>    maybe better to use a static value."
> 
> This means that there is an internal mapping function that
> matches the static value to each of the addresses the DEV acquires
> over time.
> 
> - "the list of possible IID"
> 
> "IIDs"
> 
> - "CDF is set to LSB"
> 
> I think it is "CDA" instead of "CDF".
> 
> - "If both ends knows the port number"
> 
> "know"
> 
> - "(such as in the LPWAN fragmentation process (see XXXX))"
> 
> Now that fragmentation is included on the draft, XXXX can 
> be changed to "Section 8"
> 
> 
> Examples
> 
> - "when such technologie are used"
> 
> "technologies"
> 
> - "the three rules Figure 6"
> 
> "the three rules depicted on Figure 6"
> 
> 
>   
> -- 
> DIEGO DUJOVNE
> Profesor Asociado
> Escuela de Informática y Telecomunicaciones
> Facultad de Ingeniería - Universidad Diego Portales - Chile
> www.ingenieria.udp.cl <http://www.ingenieria.udp.cl/>
> (56 2) 676 8125
> _______________________________________________
> lp-wan mailing list
> lp-wan@ietf.org
> https://www.ietf.org/mailman/listinfo/lp-wan

Ana