Re: [Roll] About merging two RFC drafts: draft-ietf-roll-enrollment-priority and DODAG size

["Pascal Thubert (pthubert)" <[e-mail]>]

Hello Michael 

There’s always room for future improvements. But do we necessarily need to point it out ? I’ve had to rewrite / remove similar text in recent IESG reviews and I now believe in focusing on what’s there not what could have been or may be one day.


Regards,

Pascal

> Le 6 févr. 2021 à 22:56, Michael Richardson <[e-mail]> a écrit :
> 
> 
> Pascal, thanks for starting this process!
> I'm going to wait for Huimin to add his name to the author list, and
> then I'll push an update document.
> 
> Your text puts both values into a single Metric.
> I was thinking it would be two metrics, but upon reflection, it probably does
> belong in a single metric object.
> 

Not sure what you mean by this. Same record ?

> What would an appropriate default be if the metric is introduced in the
> middle of the DODAG?
>   https://datatracker.ietf.org/doc/html/draft-ietf-roll-enrollment-priority-03#section-2.1
> 
> 

Not sure it should be ; that’s the text I commented out and wanted to discuss with you. My initial understanding was that it didn’t happen but rereading I found the text allowed it. Same as above allowing that it is injected in the middle raises many questions for which I have no answer like on which occasion that happens, and what sense it makes. Eg the dodag size cannot be invented by a node in the middle; realistically not can a meaningful priority for the same reasons.


> 
> doc> The size of the DODAG is measured by the Root based one the DAO
> doc> activity. It represents a number of routes not a number of nodes, and
> doc> can only be used to infer a load in an homogeneous network where each
> doc> node advertises the same number of addresses and generates roughly the
> doc> same amount of traffic
> 
> I really that we would measure in terms of number of routes.

You mean nodes not routes? Sadly we have no way to know that, do we?


> 
> pt> I'm concerned that the undocumented/future behavior will create comments
> pt> at the IESG.  My observation is that we should either define the process
> pt> fully or not mention it at all.
> 
> I concur that we will get comments, and yet, I think that we really do want
> to allow for "future work".

More than comments; they ask for crisp specification, backward compatibility and security issues...

Take care,

Pascal 
> 
> --
> Michael Richardson <[e-mail]>   . o O ( IPv6 IøT consulting )
>           Sandelman Software Works Inc, Ottawa and Worldwide