Check if east-west traffic is encrypted as well.

Understand how Nydus might impact the threat model for the CRI.

Understand how identity/tokens are established/rotated/stored.

1. Are tokens short spanned by default?
2. What is the blast radius of the token compromise?
3. How are tokens/cred stored locally?
4. What is the revocation logic that it is dependent on?

What does this term mean?

This is old architecture diagram.

Lets call this "Network Microsegmentation"

Need an Architecture diagram here.

CNAPP

Lets call it "Multi Cluster Policy Management"

Add a diagram for this

CNAPP is not a tool.

This can be Added

How to know this?

This policy does not makes sense. It denies access to serviceaccount for all. For cat the access is enabled by allowing access to / recursively.

What happens if we have two rules? 1. allow serviceaccount access to cat only 2. allow /etc/passwd access to more only

With the given rule, cat and more will still have direct access to / recursively.

It is not possible to hold multiple addresses in a single RTO. Do you mean multiple RTO each containing a multicast address?

This is not clear to me.

How can C deliver packet to F using Neighbor Cache Entry?

Is it E delivers the packet to F?

where

comprises of

section is a new term

there is no way to ensure that no packet is lost.

why to ignore the SenderRank if the 'P' flag is set?

As I understand, this flag is only for additional information. This P flag is not used for processing in the RPI. Is this correct?

What exactly is the Step of Rank? Is it:

1. Difference between the rank of this node and the sibling?
2. DAGRank() as computed in Section 3.5.1 in RFC 6550? This needs to be explained with an example.

I got very much confused between Projected DAO Request and Projected DAO Object (Figure 6 and Figure 9).

Projected DAO Request is sent from the node to the Root (Figure 9). Projected DAO message is sent from the root to the nodes to install P-routes (Figure 6) and this message is a updated DAO message with the P flag (thus updating 6550).

E delivers packets to F or G.

XInX

E delivers packets to F or G.

Section 2.4 "Domain Terms" states for Track Segment would typically be installed using Storing Mode P-DAO messages .. But in this example, P-DAO 3 is a NSM P-DAO.

Why is it stated in Section 2.4 that, "With this specification, a Segment is typically installed by the Root of the main DODAG using Storing Mode P-DAO messages."

XXwhatXX

??

Destination

need to converge

Segment is used

This is a new term! Does the line mean that the TrackID is local to the Track Ingress?

by the

Add this to terminology section above.

Anisotropic?

Why anisotropic?

Move this para to the end of the section.

Add terms used in the document.

This should isolate-ns1

The example is all about non-tunnelled deployments but the tcpdump shows vxlan interface?

the

to be transmitted

disabling

would use this

cannot

selectively

as available

Requirements

This reference is broken. There is no section 2.17.

"cannot continue to read data from the connection" ...

shouldn't this be "can continue to read data from the connection"

Interesting to note.

sequence numbers

Difficult to understand.

Checksum is carried in IP headers and is transferred across the TCP/Network interface in the arguments or results of calls by the TCP implementation on the IP layer.

"now work" ... is it "not work"?

Also what does MUST - 1 indicate?

loved to see some references in the context.

Is it necessary that each TCP segment is sent as in IP datagram?

from the

current one

RPLInstanceID = 0 is a valid instance ID as per 6550. This draft uses value 0 as a special purpose ID to instantiate a new TrackID.

or

Which regulation is to be respected?

What does "applicative uplink" means?

In this case the device is the fragments receiver, and the SCHC gateway is the fragments transmitter.

For details about what tile is please provide ref to specific section in RFC 8724.

Please provide reference to Section 8.2.4 in RFC 8724 for DTag.

In this case the device is the fragment transmitter, and the SCHC gateway is the fragment receiver.

IID collision can be detected only by the Network Gateway. How would the Network Gateway initiate a LoRaWAN join?

Section 4.4 defines that only the end device can initiate a JoinRequest frame.

Turns out it is not possible to use the same FPort number for both uplink and downlink in order to facilitate fragmentation as described in Section 5.2. Thus it may be better to use MUST here for specifying the different FPortDown i.e., mandating the the sets of FPortUp and FPortDown are fully disjoint.

interoperability, recommended

The diagram shows that the LoRaWAN payload is separate from the SCHC packet. How to determine the size of LoRaWAN payload?

I believe the term "fragmented datagram" should be used in place of "fragmentation datagram" in whole of this para.

rephrase.

sent

What is "major network's settings"? Was it supposed to be "network's major settings"?

Section 4.3, 4.4 uses the term frames and messages interchangeably. It would be better to use a single term, ideally frame for all the purposes of section 4.3/4.4.

I dont think you meant downlink latency here. I think you meant downlink frequency or listen periodicity.

Join Server is not explained in the list of entities in the architecture.

C/D rules is understood, but what are F/R rules?

is

Destination-Oriented

Not clear about this. Revisit Later.

If Root sets the "P" flag then the 6LR should refrain from doing EDAR directly. But in the general flows the 6LR is doing EDAR.

by an absence of ROVR field.

It is possible to send complete target address but only partial prefix before. But with the new format this is not possible. For e.g., lets say the 6LR has IPv6 address FD00::1234/128 and manages the prefix fd00::/64. It was possible to send complete address fd00::1234 but only mentioning the prefix length as 64. But now it is no more possible.

Why is alignment to 4Byte boundary needed? Alignment to octet should be enough and saves bytes for odd prefixes.

Section 5 states that the 6LR should refrain from sending EDAR messages if the Root signals 'P' flag. Should the 6LR in that case directly originate the DAO to the Root even for first registration? There is no flow diagram depicting or detailed clarification regarding the signaling to do when 'P' flag is set.

This indicates DAO Storing MOP behaviour.

Rather than changing the DIS Base Object for a specific cause it may be better to update the Solicited Information Option.

Modified

The abbreviated version can be sent only once the end to end path of the target is established.

Rather than calling "Protected Options" we should call them "Elided Options"

Here it is implied that RCSS is Instance-specific while above it was implied that it is DODAG specific.

How can the node decide that the network has sufficiently settled? Any example ways?

This draft updates 6550. The abstract needs to reflect that.

The scope of the RCSS should be RPLInstance. Even if the node switches a DODAG in the same RPLInstance the RCSS should be applicable since all the options are still valid.

Not sure how AOO is used ?

1. Is AOO used only in DIS messages?

It is better to clarify what all can be elided with A flag set.

• DODAGID
• Tgt Opt
• TgtDesc
• TIO

The DAO options could be easily elided in NS MOP but in Storing MOP it is difficult to apply the same logic especially for 6LRs.

better to calls this Cap option

6LRs do not keep DAO states... they maintain states based on targets. Using DAO + DAOSequence may not be helpful.

AOO option full form is Abbr Option Option Option :-)

unused term

remove these terms

These paras have no relevance to the drafts core content. I think these paras are simply copy-forwards from previous draft used as a template.

Calling DODAG Configuration Option as DCO may be confusing since the DCO is used for Destination Cleanup Object .. Can we call DODAG Configuration Option as CfgOpt instead?

How is DAO message options elided? RCSS is only controlled by Root and only applies for Root-related options.

Can we call this Root-Configuration-State-Sequence (RCSS) in place of RPL-Configuration....

I want to reuse the term in Caps as Node-Configuration-State-Sequence (NCSS) ..

What value should the DIS-sender send if the previous RCSS is not known?

What is Done?

Figure 8 does not show first time registration

Shouldnt this be called RAN.

DCO

syntax problem

acknowledgement

of

The units of RPL may not be units of 60s (as for 6lo).

Can the NCE be purged?

If

sent

Why EDAR is directly invoked by the 6LR in NS MOP case for first registration? Isnt the implementation simpler if the root does it for all the cases? The 6LR can just initiate the DAO in all cases and root takes care of sending anonEDAR to 6LBR.

embeds

How will we deal with enrollment draft once it kicks in? Enrollment priority won't be honored by the RULs.

Sentence seemed to be cutoff.

Destination

ON

What is ships-in-the-night? Didn't find any explaination in the given ref.

uncompressed

When it

join

Refrain from joining an instance is not same as "join as leaf". A node which joins as leaf, still is joining the instance.

Not clear.

spelling mistake

Typo! sentence wrong.

caps

caps

This term is never used in the document.

What is RCO ? Did you mean DCO? Same in the next section.

Isnt this supposed to be one?

We need a way to compress parent set because we are dealing with DIOs here.

A new register for the NSA TLV type has to be created.

Should the parent node send PS IPv6 addresses in the order of preference? i.e. preferrend parent first and so on ... The parent preference needs to be known for the child node to define the policy to use.

RFC 6551 does not define the TLV structure. This document should first define the TLV structure and then specify the PS TLV.

Make it clear how these A|O bits should be handled with PS.

This statement is out of order

CA Strict/Medium/Relaxed policies should be explained before the CA OF is defined. CAOF often references those and thus the reader needs to know the policies before understanding CAOF.

What additional state is expected to be stored by RPL for handling this? Set of APs?

This needs to be elaborated. What is cur_ap_min_path_cost?

What is MAX_PATH_COST? Where is it defined?

Multiple AP nodes could be selected.

better to call it host as per RFC 4861

Also provide ref to RFC 4861 for the roles.

BLE IPSP defines Node role and Router role. Is that what is referenced here? Regardless, it is better to add a ref.

Contradicts with a SHOULD below.

Contradicts with a MUST above.

Can the Path Control bits be used in context to Storing MOP?

This is not correct. It should be "frames that do not increase MAX_STREAM_DATA offset limit" .. it is not same as flow control limits.

what is SCID? Source Connection ID?

Why should "Parent Address" be present in the Transit Information Option of the DCO?

This should be Transit Information Option.

How can these descriptors/tags be used subsequently? Would be best if RPL could give some sample use-cases.

Is it possible to have a DAO message without a target in RPL ? what are the use-cases ?

Transit Information is a MAY .. Transit information contains PathSeq/Lifetime which seems mandatory. Also Parent Address is mandatory with NS-MOP, isnt it?

When sending NPDAO, one has to insert Transit Info Option to signal lifetime of zero.

Why NS-MOP needs multiple Transit Information options while storing-MOP doesn't need one?

I am wondering if it is possible to attach a field "such as min-priority" field which is a derivative of the metric calculation in context to every parent in the parent-set. This greatly helps the child nodes in deciding the CA policy to use.

I think a section on reparenting is needed here. During reparenting, the parent might send its updated DIO with its new parent set. The implications of use CA strict policy in this case might result in child choosing a different AP which certainly is not desirable if the parent still has connectivity to its old parent and the reparenting is done based on metric changes.

How would the receiver node knows whether the addresses are compressed using 6lorh or not? Should there be a flag depicting this as part of PS TLV?

As i understand, the node should ideally use strict mode. If the clauses of strict mode are not satisfied by the parent set then it should go for CA medium and relaxed mode respectively ? Different nodes can choose different modes in the same network.

How would the PRE be applied only to a subset of the traffic ?

Most of the text is catered to 6TiSCH usage. But I believe the PRE technique can as well be used in non-6tisch context. Is that right ?

Some problem with this text!

what is CCN?

These numbers are no longer true. The total code size of LWIP ver 2.1 exceeds 70KB for Cortex-M3 MCU.

LWIP is widely used on 32 bit MCUs.

Editorial

This statement does not make sense!

It is better you clarify the bits in RT context. I am specifically interested in understanding in how to handle this metric at multiple hops. How to do additive RT metric?

DIO may need to carry OF configuration parameters .. i.e. all the nodes need to agree on the unit of the traffic measurement for e.g. THROUGHPUT_PERIOD defined in the draft. It is necessary that all the nodes agree on the time unit. Secondly if we use hysteresis, we need thresholds to be carried as well.

During ROLL session, Pascal mentioned that parent oscillations should be avoided and suggested use of multiple parents while the transition is in progress. Other way to handle this is to involve hysteresis right in this draft and give guidelines/recommendations for configuring thresholds.

I dont understand why enrollment aspect was brought in here .. The relay chosen during enrollment and preferred parent chosen during routing protocol operaion could be different. Enrollment can choose a different set of metrics from routing metrics .. Enrollment of nodes happens few times during the lifetime of the device. The metrics enrollment could consider could be completely different from routing metrics.

Certain deployments have roughly similar data stream generated from all nodes .. for e.g. metering solutions .. Current draft requires throughtput measurement on 6LRs .. Now in all cases this throughput calc may not be required .. But there is still a case to balance the network nonetheless .. Is it possible to consider balancing based on the sub-dodag size rooted at 6lr (naturally works only for storing MOP) ? In this sense, the work qasem-load-balancing was trying to do was similar considering nodes have similar traffic patterns.

Editorial fix.

How would intermediate 6LR nodes react to these shiftings? Is there any way to quickly recover the routing adjacencies previously estalished with old instance IDs ? I think for symmetric routes this can still be handled (by 6LRs checking the shifted instance ID in RREP_DIO). But for asymmetric its not clear on how to handle. I think this handling warrants a separate section!

I think it is fairly reasonable for this situation to occur in real networks. The instance id size is 7 bits and good chances multiple nodes might end using the same local instance id.

P-DAO