Hi Pascal, 

I am glad that the review is useful. 
I was thinking about a functional diagram, something like the below. 
I am really not good at drawing, just for your reference. :) 
Anyway this is not a big deal. Your updated diagram is also good. It is up to 
you. 

                                        +------------------+
                                        |        6LBR        | 
                                        |        (Root)      |
                                        |   (Registrar)   |
                                        +-------------------+
                                   /                                    \
                                /                                          \
              +------------------+                           
+------------------+
             |          6LR        |                           |          6LR   
     |
             | (RPL Router) |                           | (RPL Router) |
         +-------------------+           LLN         +-------------------+
         register /|\                                                    /|\ 
register
L2 NS (EARO)  |                                                        |  L2 NS 
(EARO)
         +-----------------+                                        
+-----------------+          
        |          6LN        |                                       |         
 6LN        |
        |  (RPL leaf L)  |                                        |  (RPL leaf 
L)  |
        +------------------+                                        
+------------------+

BR,
Shuping 




From: Pascal Thubert [mailto:[email protected]] 
Sent: Tuesday, April 29, 2025 4:46 PM
To: Pengshuping (Peng Shuping) <[email protected]>
Cc: [email protected]; [email protected]; 
[email protected]; [email protected]
Subject: Re: Rtgdir ietf last call review of 
draft-ietf-6lo-prefix-registration-10

Hello Shuping :)

Many thanks for your review!

I pushed to Github the proposed whanges, please see IETF LV comments by Shuping 
Peng · pthubert/6lo-prefix-registration@6703f50

For details, please see below:



Summary:
I have some minor concerns about this document that I think should be resolved
before publication.

Comments:
Overall this draft is well-written.
 
: ) 

Major Issues:

No major issues found.

Minor Issues:

2.4 New terms

Merge/merging

"merging" is not shown in any other place within the draft. Maybe it as a new
term is not needed here?

The verb merge (in the merges form) is used quite a bit. To your point I 
removed 'merging' from the definition.
 
3.1

1) Figure 1 is still not very clear although I noticed that the authors had
updated it in the latest version. Instead of using a illustrative diagram, I
wonder whether a diagram with the relevant elements named in this draft and the
connections in-between would be much clearer.

The drawing was indeed improved based on comments and names added. Not sure 
what diagram you have in mind?
 

2) 'z' and '|' meant different types of connections? '|' is not explained.

Removed the z, the type of link is not that relevant anyway

3) "Access Point" in this figure is not mentioned anywhere in this subsection.

also removed
 

4) The caption of Figure 1 is "Wireless Mesh". How about "RPL-Based Route-Over
LLN"?

Great suggestion, applied.
 
5.

"
- to be confirmed by IANA

- and updated by RFC Editor if needed.

"
Would this part be better to be marked as "to be deleted before publication"?
Since this is a Last call review, I mentioned about this.

The point is the location in the figure may vary and need updating; but no 
worries, we'll do the needful things with the editor :)
 

"
New Option Field:

X  1-bit flag: "Registration for prefixes Supported"
"
Should this 'X' be 'F'?

oups, thanks for catching this one
 

Nits:

4.
s/This specification Amends/This specification amends

6.
s/This specification Extends/This specification extends

Actually not, see section 2.1
 

7.
s/it SHOULD register all those prefixes with on all interfaces from which it
might be needed to relay traffic to that prefix./it SHOULD register all those
prefixes on all interfaces from which it might be needed to relay traffic to
that prefix.
fixed
 
10.
s/This specification Extends/This specification extends

same as above
 

11.
s/if the values of the ROVR they use is known in advance/if the values of the
ROVR they use are known in advance
applied

 Again, many thanks.



-- 
Pascal
_______________________________________________
6lo mailing list -- [email protected]
To unsubscribe send an email to [email protected]

Reply via email to