[grobj] FW: [Fwd: Re: Problem statement] - 2nd 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 2nd out of 7.

Regards,

Sheng

> -----Original Message-----
> From: Sheng Jiang [mailto:[e-mail]] 
> Sent: Thursday, January 21, 2010 6:09 AM
> To: Brian E Carpenter
> Cc: Dan Wing; [e-mail]
> Subject: Re: [Fwd: Re: [grobj] Problem statement]
> 
> Hi, Simon,
> 
> Thanks for your comments. It is very helpful for all of us to 
> understand GROBJ and what we may be able to achieve. For your 
> information, we are actually NOT to have a BoF in Anaheim. 
> Let's discuss it through emails, also f2f meeting in Anaheim.
> 
> > 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.
> 
> I will a thrid side for R1. "all available information" is 
> not a good start in my eyes. It may take us to get a 1kB data 
> in a situation that
> IP/IPv6 addr is enough to work out. "minimum amount of 
> information that is necessary in all cases" is also a problem 
> for me. To be able to work in ALL cases, "all available 
> information" seems the only choice. 
> Actually, even all available information may not be enough 
> for some cases.
> 
> Can we forget about ALL at the beginning stage? We should 
> focus on necessary information for most cases we count so far 
> and then make the GROBJ extensiable for further use. If we 
> can agree on this, we can sit down discussion what the 
> nessary information is and in which cases.
> 
>  > 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.
> 
> Basically, for my understanding, what we do here is "the best 
> efforts". 
> We cannot guarantee the reachability. It can be only test 
> when a receiving entity actually have the GROBJ.
> 
> > 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.
> 
> Again, we cannot sure at all. From the view of the 
> constructor of a GROBJ, it just selects the most useful item 
> from its pwespective. We make the best efforts, it may not 
> work out at the end.
> 
> > I don't understand why R4 is needed, and I cannot imagine a 
> protocol 
> > that would pass this test.
> 
> My understanding for this R4 is that we are going to define a 
> single universal format. And the discription of its options 
> is independent from network situations.
> 
> > 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."
> 
> R5 takes me back to R1 again. All information is definitely 
> not efficiency. We don't want send 1kB data in the situation 
> that 10B can work out. It is efficiency. It is also necessay 
> vs enough.
> 
> That's it for now. We should keep our discussion continue 
> until we feel we understand and consensus. Then, we may be in 
> next stage to attract more attension with better requirement 
> descriptions.
> 
> Best regards,
> 
> Sheng
> 
> > 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.
> >
> >
> >
> >
> >
>