RE: [Adslmib] RE: xDSL Bonding - Reuse of the hubmib-efm-cu-mib work

Edward,
 
    Thank you for good work in separating out the Capability Stack
tables into a separate module and providing
the HTML and MIB modules.
 
    The xDSL Bonding MIBs will be able to make use of these tables and
reference the efm-cu-mib document.
 
Best Regards,
Menachem 

 
________________________________

From: Edward Beili [mailto:[email protected]] 
Sent: Friday, October 13, 2006 7:07 PM
To: Romascanu, Dan (Dan); Menachem Dodge
Cc: [email protected]; David Kessens (E-mail); [email protected];
[email protected]
Subject: RE: [Adslmib] RE: xDSL Bonding - Reuse of the hubmib-efm-cu-mib
work


Dan, Menachem,
I've submitted the next version of the EFM Copper MIB draft, putting the
ifAvailableStackTable (renamed to ifCapStackTable) into a separate MIB
module, together with a new inverse ifInvCapStackTable.
 
I've also modified the text to describe the new IF-CAP-STACK-MIB module,
changed the conformance and compliance objects and added counter
discontinuity handling paragraph (use of ifCounterDiscontinuityTime) to
all counters.
 
The .txt version is available at
http://www.ietf.org/internet-drafts/draft-ietf-hubmib-efm-cu-mib-06.txt
<http://www.ietf.org/internet-drafts/draft-ietf-hubmib-efm-cu-mib-06.txt
> 

I've attached the .html version together with two extracted MIB modules
for your convenience.

Regards,

-E.


________________________________

	From: Romascanu, Dan (Dan) [mailto:[email protected]] 
	Sent: Sunday, August 27, 2006 21:35
	To: Edward Beili; [email protected]
	Cc: [email protected]; David Kessens (E-mail);
[email protected]; [email protected]
	Subject: RE: [Adslmib] RE: xDSL Bonding - Reuse of the
hubmib-efm-cu-mib work
	
	
	Ed,
	 
	Please issue a revised I-D, including the two tables in a
distinct MIB module, revised DESCRIPTION clause and smilint fixes.
	 
	My suggestion is to do a one week fast track Last Call to make
sure that everybody in the WG has an opportunity to see and react to the
changes before we submit the draft to the IESG. 
	 
	Regards,
	 
	Dan
	 
	 
	 
	 


________________________________

		From: Edward Beili [mailto:[email protected]] 
		Sent: Sunday, August 27, 2006 9:04 PM
		To: Romascanu, Dan (Dan); [email protected]
		Cc: [email protected]; David Kessens (E-mail);
[email protected]; [email protected]
		Subject: RE: [Adslmib] RE: xDSL Bonding - Reuse of the
hubmib-efm-cu-mib work
		
		
		Dan,
		I don't have any problem with the suggested change, and,
personally, see this as an editorial change.
		 
		While moving the ifAvailableStackTable to a distinct MIB
module (say IF-AVAILABLE-STACK-MIB, seating directly under MIB-2), I
would also add an inverse table ifInvAvailableStackTable.
		 
		Please advise how do you want me to proceed.
		 
		Regards,
		-Edward
		 

			-----Original Message-----
			From: Romascanu, Dan (Dan)
[mailto:[email protected]]
			Sent: Sunday, August 27, 2006 6:09 PM
			To: [email protected]
			Cc: [email protected]; David Kessens (E-mail);
Edward Beili; [email protected]; [email protected]
			Subject: RE: [Adslmib] RE: xDSL Bonding - Reuse
of the hubmib-efm-cu-mib work
			
			
			 
			So this will be a distinct MIB module. 
			 
			I am copying the hubmib WG list, because I am
not convinced that such a change can be treated as editorial and that we
can or should avoid another WGLC for draft-hubmib-efm-cu-mib. 
			 
			Dan
			 
			 
			 
			 


________________________________

				From: [email protected]
[mailto:[email protected]] 
				Sent: Sunday, August 27, 2006 4:28 PM
				To: Romascanu, Dan (Dan)
				Cc: [email protected]; David Kessens
(E-mail); [email protected]; [email protected]
				Subject: Re: [Adslmib] RE: xDSL Bonding
- Reuse of the hubmib-efm-cu-mib work
				
				

				Hello Dan, 
				
				        What you suggest is fine, but I
would rather that the table be placed under the ifMIB - ifMIBObjects
branch together with 
				the ifStack Table or perhaps directly
under MIB-2 as the ifInvertedStack MIB is situated. Being placed inside
the efmCuMIB branch 
				seems to suggest  that it is  for the
sole use of the efmCuMIB and this is no longer the case if the xDSL MIB
modules import it. 
				        
				
				Best Regards, 
				Menachem Dodge
				
				
				
				
"Romascanu, Dan \(Dan\)" <[email protected]> 

27/08/2006 12:47 

To
<[email protected]>, <[email protected]> 
cc
[email protected], "David Kessens \(E-mail\)" <[email protected]>,
[email protected] 
Subject
[Adslmib] RE: xDSL Bonding - Reuse of the hubmib-efm-cu-mib work	

		




				Menachem, 
				  
				I am adding David Kessens who is the
shepherding AD for hubmib (I, being the chair, cannot play both roles). 
				  
				Why should ifAvailableStack be defined
in a separate MIB module, rather than changing the text in DESCRIPTION
clauses and having it imported by ADSL MIB modules from EFM-CU-MIB? 
				  
				Speaking as WG chair, I feel that in
case a major change is introduced in the document the WGLC needs to be
redone. At this moment we agreed for a technical iteration to fix some
smilint problems without redoing the LC. 
				  
				Dan 
				  
				  
				  
				
				
________________________________

				From: [email protected]
[mailto:[email protected]] 
				Sent: Thursday, August 24, 2006 8:08 PM
				To: Romascanu, Dan (Dan);
[email protected]
				Cc: [email protected];
[email protected]
				Subject: xDSL Bonding - Reuse of the
hubmib-efm-cu-mib work
				
				
				Hello Dan, 
				
				
				       Recently the issue of xDSL
bonding has been raised on the ADSL MIB WG mailing list. 
				
				       I have spoken briefly with Edward
and we think that it should be possible for us to re-use the
ifAvailableStack table defined in 
				draft-ietf-hubmib-efm-cu-mib-05. 
				
				       I would like to ask Edward to
separate out this table into a separate MIB (possibly in the same
document) generalizing the comments, 
				that would allow the ADSL MIB WG  to
make use of these tables, if this work becomes chartered. 
				
				       I would appreciate your advice on
this issue. 
				
				Best Regards, 
				Menachem
Dodge_______________________________________________
				Adslmib mailing list
				[email protected]
	
https://www1.ietf.org/mailman/listinfo/adslmib

_______________________________________________
Hubmib mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/hubmib