[grobj] FW: [Fwd: Re: Problem statement] - 1st out of 7

[Sheng Jiang <[e-mail]>]

FYI, there were some private discussion regarding to the new GROBJ problem
statement draft. Resend it to the grobj maillist with permission. Wish to
light wider discussion.

There are 7 emails in this thread. This is 1st out of 7.

Regards,

Sheng

> Subject: Re: [grobj] Problem statement
> Date: Thu, 14 Jan 2010 12:43:09 +1100
> From: Simon Perreault <[e-mail]>
> To: Brian E Carpenter <[e-mail]>
> References: <[e-mail]> 
> <[e-mail]>
> 
> Hi Brian,
> 
> It's good to hear from you. I was thinking that you had 
> decided to ignore me and go forward (which might not be a bad 
> idea at all). ;)
> 
> Brian E Carpenter wrote, on 14/01/10 12:02 PM:
> > Interestingly, I haven't seen any debate on your comment. 
> Of course, 
> > one could argue that a generic referral object is just what your 
> > proposed superICE would need.
> 
> Well, to be frank, the reason is that I don't understand how 
> GROBJ could be useful on its own. Sure, it would be a part of 
> superICE, but I don't see the point of focusing only on that 
> part. After asking a few times I got tired and decided I 
> wouldn't understand it until it had progressed further. So I 
> stepped back and let it progress.
> 
> > Anyway, can you do a big favour? Sanity check the attached draft.
> > I need to post it very soon to meet the BOF request deadline, but 
> > another pair of eyes would be very useful.
> 
> I'm not sure I'm in a good position to do that. It's just 
> that I have no idea where you're going. I don't understand 
> GROBJ. I read the requirements and I couldn't imagine how 
> they would translate into bits.
> 
> Take for example R1. I disagree with it. If I was to design 
> GROBJ in the context of superICE, the requirement would be 
> that the GROBJ should have the minimum amount of information 
> that is necessary in all cases. The goal would not be to 
> design a way to convey the maximum amount of information and 
> hope it all works out. The goal would be to design a protocol 
> that works in all cases and figure out the minimum amount of 
> information necessary to make it work. This is why I also 
> disagree with R2. But I also disagree with R2 because I find 
> it too fluffy.
> I can't derive a test from it that could be used to evaluate 
> candidate protocols.
> 
> I don't understand R3. How can we be sure that such a 
> Reference item "can be used to find a path to the referred 
> entry"? In my understanding, an IP address doesn't fit this 
> requirement because we often cannot find a path (or we find 
> the wrong path) for e.g. RFC1918 addresses.
> 
> I don't understand why R4 is needed, and I cannot imagine a 
> protocol that would pass this test.
> 
> I disagree with R5. Efficiency should never be a requirement. 
> It should be a criteria by which protocol proposals that 
> otherwise fulfil all requirements are evaluated. E.g. 
> "efficiency will be preferred."
> 
> I agree with R6.
> 
> I agree with R7, but I would also add forward compatibility.
> 
> I'm ambivalent about R8. To me it feels like R7 covers it.
> 
> Same with R9. It seems to me that qualifying the amount 
> needed with "reasonable"
> makes this requirement intangible.
> 
> I think I agree with R11 and R12.
> 
> Aren't R13 and R14 covered by R9?
> 
> R15, R16, and R17 have no meaning to me until I understand 
> how this scope thing will translate into bits.
> 
> I very much agree with Rxx.
> 
> Take all this with a grain of salt. Maybe eventually I will 
> understand it all and realize it was a good idea. For now I 
> just feel lost.
> 
> Hoping you find this useful,
> and hoping we can discuss this in Anaheim, Simon
> 
> P.S. Feel free to forward this email to [e-mail] if you 
> think it's worthwhile.
> 
> 
> 
>