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

From: Brian Adamson <[email-masked]>
Date: Fri, 18 Jul 2008 17:12:24 -0400

Hello Pekka,

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-masked]

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.

_______________________________________________
Rmt mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/rmt

---

From: Brian Adamson <[email-masked]>
Date: Wed, 23 Jul 2008 09:36:26 -0400

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-masked]

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:
>> 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-masked]
>>
>>
>>
>>
>>>> I appreciate your comments here.  I plan to issue a new version  
>>>> of the draft
> -- 
> Pekka Savola                 "You each name yourselves king, yet the
> Netcore Oy                    kingdom bleeds."
> Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
>