Subject: [MIB-DOCTORS] Is the following an Editorial Change?

From: "Joan Cucchiara" <[email-masked]>
Date: Wed, 4 Apr 2007 00:14:04 -0400

Hello,

I'm reviewing a draft MIB which has some tables which sparse augment 
tables in an RFC MIB.

One of these sparse augmenting tables contains a TruthValue object such
that if the object is true(1), then the DESCRIPTION clauses of some of the
objects in the BASE table are changed.

These redefinitions of the BASE table objects are in the draft MIB in
the text of the document (not in a MIB Module).

Here is an example which appears in the text of the new draft:
mplsTunnelEgressLSRId  <---- object from the BASE table in the RFC MIB.

      This object continues to map to the field in the RSVP-TE Session
      Object that occupies the space used by the IPv4 Tunnel Endpoint
      Address [RFC3209], but for a P2MP tunnel, this object does not
      identify an address of the egress of the tunnel. Instead it
      contains the P2MP ID value that identifies the identifier of the
      set of destinations for the P2MP tunnel and is carried in the P2MP
      Session Object [P2MP-TE]. The Description clause for this object
      can be read as follows.

         "Identity of the egress LSR associated with this tunnel
          instance.

          When an entry in the mplsTeP2mpTunnelTable is present
          corresponding to this entry in the mplsTunnelTable and when
          the mplsTeP2mpTunnel object in that table entry is present
          with the value true(1), this object contains the P2MP ID that
          identifies the set of destinations of this tunnel and that is
          signaled in the P2MP ID field of the P2MP Session Object if
          the MPLS signaling protocol for this tunnel indicated by
          mplsTunnelSignallingProto in MPLS-TE-STD-MIB is rsvp(2)."

      The destinations of the P2MP tunnel are found in the new
      mplsTeP2mpTunnelDestTable.

Currently, I believe that this is "not legal" and I should advise the authors of the
draft MIB, to rework the RFC (as painful as this may be), but wanted to get some 
advice on this myself.

Thank you,
   Joan

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

---

From: "Romascanu, Dan \(Dan\)" <[email-masked]>
Date: Mon, 9 Apr 2007 13:00:24 +0300

If I understand well, this looks to me like a semantic change that is
not backwards compatible. Does this reflect a change in the protocol? If
so how is backwards compatibility ensured in the protocol? 
 
MIB-wise, for the case where the TruthValue object is true(1) why not
point to a new object for the respective case instead of changing the
semantics of the objects already defined in the RFC? The price is adding
a new object, but the change would be incremental, thus acceptable,
wouldn't it? 
 
Dan

  _____  

	From: Joan Cucchiara [mailto:[email-masked]] 
	Sent: Wednesday, April 04, 2007 7:14 AM
	To: MIB Doctors (E-mail)
	Subject: [MIB-DOCTORS] Is the following an Editorial Change?

	Hello,
	 
	I'm reviewing a draft MIB which has some tables which sparse
augment 
	tables in an RFC MIB.
	 
	One of these sparse augmenting tables contains a TruthValue
object such
	that if the object is true(1), then the DESCRIPTION clauses of
some of the
	objects in the BASE table are changed.
	 
	These redefinitions of the BASE table objects are in the draft
MIB in
	the text of the document (not in a MIB Module).
	 
	Here is an example which appears in the text of the new draft:
	mplsTunnelEgressLSRId  <---- object from the BASE table in the
RFC MIB.
	
	      This object continues to map to the field in the RSVP-TE
Session
	      Object that occupies the space used by the IPv4 Tunnel
Endpoint
	      Address [RFC3209], but for a P2MP tunnel, this object does
not
	      identify an address of the egress of the tunnel. Instead
it
	      contains the P2MP ID value that identifies the identifier
of the
	      set of destinations for the P2MP tunnel and is carried in
the P2MP
	      Session Object [P2MP-TE]. The Description clause for this
object
	      can be read as follows.

	          When an entry in the mplsTeP2mpTunnelTable is present
	          corresponding to this entry in the mplsTunnelTable and
when
	          the mplsTeP2mpTunnel object in that table entry is
present
	          with the value true(1), this object contains the P2MP
ID that
	          identifies the set of destinations of this tunnel and
that is
	          signaled in the P2MP ID field of the P2MP Session
Object if
	          the MPLS signaling protocol for this tunnel indicated
by
	          mplsTunnelSignallingProto in MPLS-TE-STD-MIB is
rsvp(2)."

	Currently, I believe that this is "not legal" and I should
advise the authors of the
	draft MIB, to rework the RFC (as painful as this may be), but
wanted to get some 
	advice on this myself.
	 
	Thank you,
	   Joan

---

From: "David B Harrington" <[email-masked]>
Date: Mon, 9 Apr 2007 11:03:34 -0400

Hi,
 
I looked at the change fairly quickly, and have not done a thorough
analysis.
 
My impression is that the original object is a union for EgressIDs.
The TruthValue serves as the discriminator in a discriminated union.
When true, the EgressId should be interpreted as a specific type of
EgressId.
So on my quick analysis, it appeared this was not illegal according to
SMIv2 rules.
 
The description that says it changes the DESCRIPTION clause would make
it illegal because it changes the semantics, but I think that is a
document wordsmithing problem, not a real SMIv2 legality problem.
 
I have concerns it may be a bad design however.
I am not sure that when the Truthvalue is true, the EgressId ALWAYS
represents a P2MP ID.
If not, there is potential for conflicting values among multiple
types, and the MIB only has a binary discriminator.
It does strike me that this is redefining the original purpose of the
field, to cover a case not considered originally.
 
David Harrington
[email-masked]
[email-masked]
[email-masked]

  _____  

From: Romascanu, Dan (Dan) [mailto:[email-masked]] 
Sent: Monday, April 09, 2007 6:00 AM
To: Joan Cucchiara; MIB Doctors (E-mail)
Subject: RE: [MIB-DOCTORS] Is the following an Editorial Change?

If I understand well, this looks to me like a semantic change that is
not backwards compatible. Does this reflect a change in the protocol?
If so how is backwards compatibility ensured in the protocol? 
 
MIB-wise, for the case where the TruthValue object is true(1) why not
point to a new object for the respective case instead of changing the
semantics of the objects already defined in the RFC? The price is
adding a new object, but the change would be incremental, thus
acceptable, wouldn't it? 
 
Dan

  _____  

 
Hello,

One of these sparse augmenting tables contains a TruthValue object
such
that if the object is true(1), then the DESCRIPTION clauses of some of
the
objects in the BASE table are changed.

Here is an example which appears in the text of the new draft:
mplsTunnelEgressLSRId  <---- object from the BASE table in the RFC
MIB.

      set of destinations for the P2MP tunnel and is carried in the
P2MP

          When an entry in the mplsTeP2mpTunnelTable is present
          corresponding to this entry in the mplsTunnelTable and when
          the mplsTeP2mpTunnel object in that table entry is present
          with the value true(1), this object contains the P2MP ID
that
          identifies the set of destinations of this tunnel and that
is
          signaled in the P2MP ID field of the P2MP Session Object if
          the MPLS signaling protocol for this tunnel indicated by
          mplsTunnelSignallingProto in MPLS-TE-STD-MIB is rsvp(2)."

Currently, I believe that this is "not legal" and I should advise the
authors of the
draft MIB, to rework the RFC (as painful as this may be), but wanted
to get some 
advice on this myself.
 
Thank you,
   Joan

---

From: "Romascanu, Dan \(Dan\)" <[email-masked]>
Date: Mon, 9 Apr 2007 18:41:02 +0300

This was exactly my impression as well, and this is why I was wondering
how do two entities supporting one the older version and the other the
new version of the protocol interoperate on the wire. 
 
Dan

  _____  

	From: David B Harrington [mailto:[email-masked]] 

	It does strike me that this is redefining the original purpose
of the field, to cover a case not considered originally.
	 
	David Harrington
	[email-masked]
	[email-masked]
	[email-masked]

---

From: "Joan Cucchiara" <[email-masked]>
Date: Tue, 10 Apr 2007 18:11:53 -0400

Dan and David,

Thank you for your comments.  The original protocol did not define point-2-multipoint because the
working group agreed to do this in subsequent documents (as an extension to the protocol).  
I don't know if anything in the original protocol was invalidated due to adding the point-2-multipoint
extension.

Wrt the new MIB I agree with the approach of having new objects, since, as Dan points out, 
there appears to be the potential for interoperability using the same objects from the original RFC.  
This approach might make some of the objects in the original (point-2-point) MIB meaningless 
but that should be acceptable as long as it is documented.  In fact, I could advise the authors
to  show what objects from the RFC MIB need to be supported in the conformance 
section of the new MIB.

-Joan

  ----- Original Message ----- 
  From: Romascanu, Dan (Dan) 
  To: David B Harrington ; Joan Cucchiara ; MIB Doctors (E-mail) 
  Sent: Monday, April 09, 2007 11:41 AM
  Subject: RE: [MIB-DOCTORS] Is the following an Editorial Change?

  This was exactly my impression as well, and this is why I was wondering how do two entities supporting one the older version and the other the new version of the protocol interoperate on the wire. 

  Dan

----------------------------------------------------------------------------
    From: David B Harrington [mailto:[email-masked]] 

    It does strike me that this is redefining the original purpose of the field, to cover a case not considered originally.

    David Harrington
    [email-masked]
    [email-masked]
    [email-masked]