NO SUBJECT

gardo@vnet.ibm.com Thu, 02 November 1995 20:13 UTC

Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa20491; 2 Nov 95 15:13 EST
Received: from guelah.nexen.com by IETF.CNRI.Reston.VA.US id aa20487; 2 Nov 95 15:13 EST
Received: from maelstrom.nexen.com ([204.249.99.5]) by guelah.nexen.com (8.6.12/8.6.12) with ESMTP id OAA04606; Thu, 2 Nov 1995 14:45:36 -0500
Received: (from root@localhost) by maelstrom.nexen.com (8.6.12/8.6.12) id OAA11016 for rolc-out; Thu, 2 Nov 1995 14:54:01 -0500
Received: from guelah.nexen.com (guelah.nexen.com [204.249.96.19]) by maelstrom.nexen.com (8.6.12/8.6.12) with ESMTP id OAA11007 for <rolc@nexen.com>; Thu, 2 Nov 1995 14:53:58 -0500
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: gardo@vnet.ibm.com
Received: from vnet.IBM.COM (vnet.ibm.com [199.171.26.4]) by guelah.nexen.com (8.6.12/8.6.12) with SMTP id OAA04558 for <rolc@nexen.com>; Thu, 2 Nov 1995 14:41:09 -0500
Message-Id: <199511021941.OAA04558@guelah.nexen.com>
Received: from RALVM29.VNET.IBM.COM by vnet.IBM.COM (IBM VM SMTP V2R3) with BSMTP id 8341; Thu, 02 Nov 95 14:48:05 EST
Date: Thu, 02 Nov 95 14:48:05 EST
To: bcole@cisco.com, rolc@nexen.com, cdebruin@vnet.ibm.com, genecox@vnet.ibm.com
Subject: NO SUBJECT
X-Orig-Sender: owner-rolc@nexen.com
Precedence: bulk
X-Info: Submissions to rolc@nexen.com
X-Info: [Un]Subscribe requests to rolc-request@nexen.com
X-Info: Archives for rolc via ftp://ietf.cnri.reston.va.us/ietf-mail-archive/rolc/
Sender: ietf-archive-request@vnet.ibm.com
FROM: Russell.Gardo@nexen.com

*** Resending note of 11/02/95 14:20                                           
      telephone: (919) 254-0896                                                
      ........................................................                 
SUBJECT: NO SUBJECT                                                            
                                                                               
Bruce,                                                                         
                                                                               
>>    Why don't we move the mask into the mandatory part                       
>                                                                              
>I thought we didn't have consensus, or even a clear description of the        
>semantics of this.  (I'm not objecting however...)                            
                                                                               
This would solve my concerns with the prefix extension in the Purge.           
The mask should immediately follow the protocol destination address            
field in the Purge packet with the same length.                                
Any objections?                                                                
                                                                               
I believe this was someone's anticipation of objections.  There was            
never any real objections.                                                     
                                                                               
>                                                                              
>> and remove the Request ID field                                             
>                                                                              
>Yes, I'm all for removing this field from purge packets also.                 
                                                                               
This change is long overdue.  I think the request-id should be                 
removed also...