Re: [homenet] Stephen Farrell's No Objection on draft-ietf-homenet-prefix-assignment-07: (with COMMENT)

[Stephen Farrell <[e-mail]>]

Hiya,

On 08/07/15 22:52, Pierre Pfister wrote:
> Hello Stephen
> 
> Thanks for the comments,
> 
> See inline for my proposals.
> 
> 
>> Le 8 juil. 2015 à 17:37, Stephen Farrell
>> <[e-mail]> a écrit :
>> 
>> Stephen Farrell has entered the following ballot position for 
>> draft-ietf-homenet-prefix-assignment-07: No Objection
>> 
>> When responding, please keep the subject line intact and reply to
>> all email addresses included in the To and CC lines. (Feel free to
>> cut this introductory paragraph, however.)
>> 
>> 
>> Please refer to
>> https://www.ietf.org/iesg/statement/discuss-criteria.html for more
>> information about IESG DISCUSS and COMMENT positions.
>> 
>> 
>> The document, along with other ballot positions, can be found
>> here: 
>> https://datatracker.ietf.org/doc/draft-ietf-homenet-prefix-assignment/
>>
>>
>>
>>
>> 
----------------------------------------------------------------------
>> COMMENT: 
>> ----------------------------------------------------------------------
>>
>>
>>
>> 
- section 3: I expected some security text here, not to say that
>> this all needs to be encrypted but rather to say that because this
>> is flooding, you can't really encrypt it and that hence this scheme
>> is only suited for smaller deployments and/or those with lower
>> layer security already in place. (And hence also probably small.)
>> 
>> - section 3: Similarly, you could also add some privacy text to the
>> effect that this scheme only applies where the privacy 
>> characteristics of the various prefixes involved are all roughtly
>> similar, that is, where there's no real privacy difference in which
>> prefixes end up with which nodes. (Mind you, I need to ponder that
>> a bit myself to see if it's really the case;-)
> 
> What about this addition to the applicability statement section:
> 
> NEW: Finally, leaving the Flooding Mechanism or Node ID assignment
> process unsecured makes the network vulnerable to deny of service
> attacks, as detailed in Section 8.

That's good.

> Additionally, as this algorithm requires all Nodes to know which Node
> has made which assignment, it may be unsuitable depending on privacy
> requirements among participating Nodes.

I'm less sure of that. I think the main point is that given how the
algorithm distributes prefixes one cannot assume there are any
privacy-relevant differences between any of the prefixes. (But again,
I'd need to think more to be sure that's correct.)

> 
>> 
>> - sections 4 & 5: I found this impossible to understand in a 
>> (quick) linear reading. I'd find actual code easier tbh. It's 
>> interesting that Barry found this clear though (I did not, 
>> clearly:-) so this isn't a discuss. But why didn't you first 
>> provide an overview of the algorithm?
> 
> It is, indeed, not straightforward, but I personally believe the text
> has the merit of being unambiguous.

Well, I cannot tell of course, given that I don't find it very
comprehensible;-) But I'm quite willing to believe that's just
my too-quick reading.

> I would recommend multiple pass anyway. 

I would recommend trying to make it easier for the reader. Adding
an overview at the front should do that.

> And I believe it gets clearer
> when you try to implement it.

Sure.

>> - Where is the evidence that the algorithm converges? I'd have 
>> thought there would be a reference to an academic publication that
>> also described the algorithm and a proof for convergence.
>> 
> 
> I wrote a proof, but could not find the time to publish it in a
> scientific paper.

Hmmm. Those sound like famous last words don't they? I think if we
can't point at any evidence for the claim then we ought not make
the claim. (The evidence doesn't have to be a peer-reviewed academic
publication of course - if it has been discussed on the WG list
in enough detail that'd be perfectly fine.)

> I am not sure describing the algorithm in a paper would be
> interesting, but the proof as well as best and worst case behaviors 
> might be nice to have.

Sure, but not here. And if they're not published anywhere so far
then better to not refer to it at all for now.

Cheers,
S

> 
> 
> Thanks,
> 
> - Pierre
> 
> 
> 
> 
> _______________________________________________ homenet mailing list 
> [e-mail] https://www.ietf.org/mailman/listinfo/homenet
>