Re: Last Call: draft-ietf-rmt-bb-norm-revised (MulticastNegative-Acknowledgment (NACK) Building Blocks) to Proposed Standard

Thanks Pekka,

I will take a stab to include something that can at least mention the  
potential for such future extensions for protocol designers to  
consider, but caveat it carefully. I agree that the text as it stood  
perhaps was a bit presumptious with respect to such capability being  
in place.   For example, the NORM PI was developed while there was  
still active work on the "Generic Router Assist" draft within RMT and  
some of its design (the format of its NACK repair request content,  
etc) was driven in part in consideration of the potential for some  
form of intermediate system assistance with limited state on protocol  
operation.


Brian Adamson
[email protected]




On Jul 23, 2008, at 7:45 AM, Pekka Savola wrote:

> Hi,
>
> Please note that Dave may also be willing to change his discuss  
> position on this if he learns that parts of this text were  
> intentionally omitted.
>
> I'm OK with readding some text.  It would seem that the text  
> originally in section 3.10 would be better to include than the one  
> that was originally in 2.7.  If something along the lines of  
> previous section 2.7 were to be included, I think the text (and  
> keywords) would need to be revised to make its speculative / "food  
> for thought in the future" nature clearer.
>
> On Fri, 18 Jul 2008, Brian Adamson wrote:
>> The current posted version of the NORM BB draft has removed the  
>> discussion of intermediate system/ router assistance as you had  
>> suggested.  As you may have seen in another email, an IESG reviewer  
>> (Dave Ward) has requested:
>>
>> "  a discussion about the applicability of network based NAK
>> 	  implosion and/or local retransmitter based optimizations
>> 	  to this building block, and whether or not it would be
>> 	  possible to do this such that it can be added as an
>> 	  afterthought into deployments without changes to senders
>> 	  and/or receivers to better scale them upon increase of
>> 	  topology and/or group-size. "
>>
>>
>> To satisfy this request, I am inclined to re-include some form of  
>> this discussion that was omitted in response to your comment.  BUT,  
>> I think it could be clarified that it would not necessarily be  
>> _router_ assistance?  And to qualify the discussion more with  
>> respect to the pragmatics of deployment, etc ...  I think the  
>> discussion is merited since it will occur to people reading the  
>> document and the "NACK" building block is potentially _compatible_  
>> with such mechanisms, but I agree with you that it is not  
>> sufficiently mature and the document should not explicitly  
>> _recommend_ anything here other than to discuss the associate  
>> points ...
>>
>> What is your opinion on this?  I am updating the draft and I wanted  
>> to make sure we addressed your concerns if we adjusted the document  
>> to re-include some form of this discussion.
>>
>> best regards,
>>
>>
>>
>> Brian Adamson
>> [email protected]
>>
>>
>>
>>
>> On Apr 14, 2008, at 2:35 AM, Pekka Savola wrote:
>>
>>> Hi Brian,
>>> On Fri, 11 Apr 2008, Brian Adamson wrote:
>>>> I appreciate your comments here.  I plan to issue a new version  
>>>> of the draft
>>>> that addresses these to the extent I can.  I have some questions  
>>>> about your
>>>> concerns with comments in-line below:
>>> Thanks for your quick response.  Below I won't quote all the text if
>>> additional clarification doesn't seem warranted.
>>>> But this is certainly not a "fully-baked" area.  So [router
>>>> assistance] discussion _could_ be removed ... I suppose it will
>>>> persist in the RFC 3941 for historical purposes until there is
>>>> further interest in the area?
>>> That would be my preference.
>
> -- 
> Pekka Savola                 "You each name yourselves king, yet the
> Netcore Oy                    kingdom bleeds."
> Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
>