Re: RE: dyn part draft

Comments inline -

Anderson, Todd A wrote:
> Comments below.  New draft attached.

thanks

> 
> Todd
> 

> 
>>--Implicit Reactive Notification:  it is not really some unspecified 
>>error - i expect the error to be a resource not available 
>>error. it is 
>>non reallocation specific error message.
> 
> 
> The idea was that explicit reactive notification would have an error
> such as "resource unavailable."  In an implicit notification, all the
> controller would get is "general error" or "unknown error" the controller
> could then possibly infer it was from a resource reapportionment.
> 
> I added some text to try to clarify these two definitions.

That wasn't what I thought it was.
I thought Explicit was - resources aren't available - they were reassigned
I thought Implicit was - resources aren't available - no idea why

> 
> 
>>-on page 5 last sentence of 1st para of Dynamic Partitioning: 
>>While the 
>>point is true, isn't it the obverse of what the comment was about.  I 
>>think he was arguing that partitions not involved in the 
>>reapportionment 
>>would not be affected.
> 
> 
> I don't like this sentence either.  I think the gist of this
> statement is that we have two partitions, A and B, and A has
> excess resources (some resources unused) and B has no free
> resources.  If we transfer resources from A to B then both
> A and B would have to be shutdown if all we had was static
> partitioning.  I think the previous paragraph makes this point
> clear and this sentence only confuses things so I'll remove it.
> 
> I added paranthetical statement earlier in the paragraph to try to
> enforce this point.


But what about partition C that has no role in the reapportionment at all.
I thought that was what was being asked about.

> 
> 
>>-i am confused by your reference on starvation in Req. 4/8.  
>>what are we 
>>trying to avoid starving, the PM or the controller/SE.  i read your 
>>answer as relating to starvation of the PM.
> 
> 
> Yes, my modifications were with respect to starvation of the PM in
> its attempts to reapportion.  Is there another kind of starvation
> at work here?
> 

Yeah, starvation of the Controller.  It has resources it has been tracking
and then all of a sudden doesn't.

> 
>>- and a trivial point, but i don't know if the header is legitimate. 
>>doesn't it need to be something like:
>>Internet Draft    the_name_of_the_draft    date
>>especially if we are sending it on to the RFC editor.
> 
> 
> I looked at a bunch of drafts and most of them had different headers.
> RFCs have a different header section that to my knowledge is applied
> by the RFC editor so I don't think the exact format is all that
> important so long as it contains the relevant information.
> 

I know i am being pedantic here, but according to the guidelines for
ID authors  the ID is supposed to look like an RFC - as much as possible.

I.e. good pagination, header, footers etc...

Just a nit.  But some care about nits - especially when it is time
to ask for IETF last call and consideration for RFC.
In fact we should probably go back and reread nits for RFC authors and
make sure  all the nits have been taken care of.

thanks again
a.