Subject: [MIB-DOCTORS] IfTypeReferences - ds3 and sip (SMDS) and coffee

From: "Wijnen, Bert (Bert)" <[email-masked]>
Date: Fri, 4 Aug 2006 21:16:10 +0200

Interesting and strange stuff that I am finding.

Keith answered:
> > > 5. RFC 1694 is a later (than RFC 1304) reference for 
> > > 'sip(31)', and RFC 2325 is needed as a reference if "coffee"
> > > is included in the row.
> > > I suggest it would be useful to expand the acronym to be: SIP (SMDS
> > > Interface Protocol), but perhaps that negates the reference 
> > > to "coffee" ??
> > 
> > Hmmmm 2325 is an April 1st RFC. Should we list it at all?
> > Cause I do not think that the sip IfType applies at all, it is more of
> > a joke and might confuse people who do not understand the APril 1st RFCs.
> > 

So I have for coffee:
      <!--label-->     <c>coffee</c>
      <!--ifType-->    <c>132</c>
      <!--MIBoid-->    <c>transmission 132</c>
      <!--MIBmodule--> <c>COFFEE-POT-MIB</c>
      <!--Reference--> <c><xref target='RFC2325'/></c>
      <!--comment-->   <c>April 1st RFC
                         <vspace blanklines='0' />
                          It does mention ifType sip(31) too.
                       </c>

So that one does list sip(31), but I think that was a joke
(e.g. take a sip of coffee).

> > So I'd prefer to just list 1694.
>  
> So, why aren't/haven't they been confused by:
> 
>                    sip(31),            -- SMDS, coffee
> 
> in http://www.iana.org/assignments/ianaiftype-mib ??  Shouldn't we
> be consistent ??
> 

The sip(31) SMDS documents (RFC1304 and RFC1694) do not contain the word
coffee or Coffee. So I'd suggest to the iana to remove coffee from sip(31)
comment. 

For sip(31) I now have:

      <!--label-->     <c>sip</c>
      <!--ifType-->    <c>31</c>
      <!--MIBoid-->    <c>mib2.36</c>
      <!--MIBmodule--> <c>SIP-MIB</c>
      <!--Reference--> <c><xref target='RFC1694'/> (DS)</c>
      <!--comment-->   <c>SMDS
                         <vspace blanklines='0' />
                          initial: RFC1304-MIB <xref target='RFC1304'/>
                         <vspace blanklines='0' />
                          obsoleted by: SIP-MIB <xref target='RFC1407'/> (PS)
                         <vspace blanklines='0' />
                          sip OBJECT IDENTIFIER ::= { transmission 31 }
                       </c>

Do people think that the it is handy/useful to:
- have the reference to the most current RFC 
- include the status (PS, DS...)
- list the obsoleted RFCs as well
- add the OID for "sip" (last line) ??

The reason I ask is that, now that I am going through all this in detail, it is
easy to add. Problem might be: maintenance in the future.

I wondered about this when I also composed the data for ds3(30):

     <!--label-->     <c>ds3</c>
     <!--ifType-->    <c>30</c>
     <!--MIBoid-->    <c>transmission.30</c>
     <!--MIBmodule--> <c>DS3-MIB</c>
     <!--Reference--> <c><xref target='RFC3896'/> (PS)</c>
     <!--comment-->   <c>DS3/E3 MIB
                        <vspace blanklines='0' />
                         experimental: RFC1288-MIB <xref target='RFC1288'/>
                        <vspace blanklines='0' />
                         obsoleted by: RFC1407-MIB <xref target='RFC1407'/>
                        <vspace blanklines='0' />
                         obsoleted by: DS3-MIB <xref target='RFC2496'/>
                        <vspace blanklines='0' />
                         obsoleted by: DS3-MIB <xref target='RFC3896'/> (PS)
                        <vspace blanklines='0' />
                         ds3 MODULE-IDENTITY ::= { transmission 30 }
                      </c>

Oh well, comments always welcome.

The more I poke into this, the more I see that it is a big hodge podge of
approaches. And I wonder how a NMS can make sense out of it.

Bert

_______________________________________________
MIB-DOCTORS mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mib-doctors

---

From: "Romascanu, Dan \(Dan\)" <[email-masked]>
Date: Sun, 6 Aug 2006 13:58:25 +0300

Expanding SIP in this case seems to me extremely important. I am almost
tempted to suggest to add to the comment something like 'Warning: this
is NOT the Session Initiation Protocol'. 

Dan

> -----Original Message-----
> From: Wijnen, Bert (Bert) [mailto:[email-masked]] 
> Sent: Friday, August 04, 2006 10:16 PM
> To: Keith McCloghrie
> Cc: [email-masked]
> Subject: [MIB-DOCTORS] IfTypeReferences - ds3 and sip (SMDS) 
> and coffee
> 
> > > > 5. RFC 1694 is a later (than RFC 1304) reference for 'sip(31)', 
> > > > and RFC 2325 is needed as a reference if "coffee"
> > > > is included in the row.
> > > > I suggest it would be useful to expand the acronym to be: SIP 
> > > > (SMDS Interface Protocol), but perhaps that negates the 
> reference 
> > > > to "coffee" ??
> > > 
> > > Cause I do not think that the sip IfType applies at all, 
> it is more 
> > > of a joke and might confuse people who do not understand 
> the APril 1st RFCs.
> > > 
> 
> So I have for coffee:
> > in http://www.iana.org/assignments/ianaiftype-mib ??  
> Shouldn't we be 
> > consistent ??
> > 
> 
> The sip(31) SMDS documents (RFC1304 and RFC1694) do not 
> contain the word coffee or Coffee. So I'd suggest to the iana 
> to remove coffee from sip(31) comment. 
> 
> For sip(31) I now have:
> 
>       <!--label-->     <c>sip</c>
>       <!--ifType-->    <c>31</c>
> The reason I ask is that, now that I am going through all 
> this in detail, it is easy to add. Problem might be: 
> maintenance in the future.
> 
> The more I poke into this, the more I see that it is a big 
> hodge podge of approaches. And I wonder how a NMS can make 
> sense out of it.
> 
> Bert
>