Hi Glenn,
-----Original Message-----
From: Glenn Mansfield Keeni [mailto:[email protected]]
Sent: Sunday, May 08, 2016 11:02 AM
To: Jeffrey (Zhaohui) Zhang <[email protected]>; Benoit Claise
<[email protected]>; EXT - [email protected]
<[email protected]>
Cc: Mach Chen <[email protected]>; [email protected]; Martin
Vigoureux
<[email protected]>; [email protected]; [email protected]
Subject: Re: [bess] MIBDoc review of
draft-ietf-bess-l2l3-vpn-mcast-mib-
02.txt
Jeffrey,
> Thanks for your comments. I've addressed most of your comments
> in the new revision:
Thanks for your cooperation. I will need at least one more revision
with the following comments/recommendations addressed before I will
be able to complete the detailed review. In the following the numbers
refer to the issue numbers in the initial review. The issues that are
addressed and closed are not listed. For brevity, the issue
descriptions have been trimmed. In case of doubts please look at the
response mail appended below.
Hope this helps.
Thanks for your detailed comments/suggestions. I posted a new revision
with the following issues addressed.
URL:
https://www.ietf.org/internet-drafts/draft-ietf-bess-l2l3-vpn-mcast-mib-04.txt
Status:
https://datatracker.ietf.org/doc/draft-ietf-bess-l2l3-vpn-mcast-mib/
Htmlized:
https://tools.ietf.org/html/draft-ietf-bess-l2l3-vpn-mcast-mib-04
Diff:
https://www.ietf.org/rfcdiff?url2=draft-ietf-bess-l2l3-vpn-mcast-mib-04
Please see some notes below.
Glenn
-------------------------------------------------------------------
Comments:
1.1
> I had thought this would be standard/obvious for all MIB
objects -
We will comeback to this time and again, whereever possible make
matters explicit and clear. That will help.
> Is it enough to say something similar? For example:
> In particular, it describes common managed objects used
> to configure and/or monitor both L2 and L3 VPN Multicast.
That is better.
I take it that this is already closed in -03 revision.
2.2
> Having said that, I'll explain PMSI a bit further.
PMSI explanation is good.
Please use the same style/format for I-PMSI and S-PMSI.
I think -03 revision already use the same style/format for I-PMSI and
S-PMSI?
2.3
> No difference. I was using "Layer 3" or "L3" but it was
pointed out
> that the layer 3 VPN is often referred to IP VPN in other RFCs
and I
> was advised to change it accordingly. Looks like I did not change
all
> the cases.
> On the other hand, I noticed that RFC 4382 does use "Layer 3
VPN" so
> I'll change it back.
No problems. just make sure that the same expression/notation is used
uniformly.
I take it that this is also addressed in -03 already.
3.
> > > 3. Summary of MIB Module.
> > > An overview of the L2L3-VPN-MCAST-MIB will be good- the
> > > structure of the MIB, short descriptions of the table(s)
> > > including usage of the table(s) for management and/or by
> > > other MIB(s).
>
> I had that, but have added one sentence about the only table.
A sentence or two about the textual convention will be good.
Added in -04.
> > > 4. MIB syntax checking:
> > > smilint -s -e -l 5 mibs/L2L3-VPN-MCAST-MIB
2>L2L3-VPN-MCAST-MIB.txt
>
> I used simpleweb's validation tool but looks like I did not
use the
> strictest level of validation. I've now fixed the following issues
and
> verified.
Good.
5.
> > >
> > > 5. REFERENCE clauses: Please use REFERENCE clauses liberally.
> > > Wherever possible, provide references for objects used in
> > > the MIB. The references will point to specific sections/
> > > sub-sections of the RFCs defining the protocol for
which the
> > > MIB is being designed. It will greatly improve the
readability
> > > of the document.
>
> Added.
I would recommend using the REFERENCE clause as in rfs4382 and
improve on it.
Specifically, instead of keeping the reference in the DESCRIPTION
clause move it to a separate REFERENCE clause. The addition of the
section number is an improvement. It is friendlier to the reader.
Note. Same comment for other OBJECTs too.
Oh I missed that. All fixed.
7.1
> > > 7.1 CONTACT-INFO
> > > Following the conventions (including indentation style)
will
> > > improve the readability. (e.g. RFC4382, RFC5132).
> > > Will be good if it does not overflow into the next page.
>
> Fixed.
The format is OK. The Postal address etc., need not have been
deleted. Please put the complete contact information as in the
Author's Address. (RFC 2578 section 5.7 gives a usage example).
Fixed.
7.3
> I kept "experimental 99" so that I could continue to use mib
tools
> to validate; but I added notes for the editor to replace them
as you
> indicated.
Use of "experimental 99" is not recommended.
Do you mean 99 is not a good number? What about 9999? As I explained,
I kept it so that we can use mib tools to validate, and I've added
detailed notes for the editor.
8
> > > 8. Specific MO and TC related comments.
> Are spaces allowed? I don't know so I used hyphen. For now I
replace
> with things like rsvpP2mp.
Yes. Camelcase is an allowed practice. SMI does not mind it.
Ok this is closed already then.
8.2
> > > 8.2 l2L3VpnMcastPmsiTunnelAttributeFlags OBJECT-TYPE
> The intent is to simply return the octet value of the flags
> field, w/o listing individual bits like "Leaf Information
Required".
> More bits could be defined in the future but the MIB would not
change.
>
> Is that OK?
As far as possible, the meaning of the objects must be made clear.
That will help implementors and operators- users of the MIB.
I added the definition for one existing bit and reference to the IANA
registry being created for this flag field.
8.3
> > > 8.3 l2L3VpnMcastPmsiTunnelAttributeId OBJECT-TYPE
> Depending on the tunnel type, there could be different sizes.
> Future tunnel types could have other sizes that not specified
> today. I was thinking to just give a size
> tPmsiTunnelAttributeId OBJECT-TYPE range so that it is flexible.
> Is that ok?
I see that you have changed the size upper limit to 50.
If the size varies continuously from 0 to 50 the above description
is correct.
Please confirm, explain and cite appropriate reference. If the size
may change in the future that must be stated too.
I changed to discrete sizes for currently defined tunnel types.
8.4
> > > 8.4 l2L3VpnMcastPmsiTunnelIf OBJECT-TYPE
> > > SYNTAX RowPointer
> > > MAX-ACCESS read-only
> > > STATUS current
> > > DESCRIPTION
> > > "If the tunnel has a corresponding interface,
> > > this is the row pointer to the ifName table."
> > > o DESCRIPTION looks incorrect. Please fix it. Do you
> > > want to say this object points to the corresponding
> > > row in the ifTable?
>
> Yes. Fixed.
Not quite.
What is ifName table ? ifName is a columnar object in the
ifXTable.
Is l2L3VpnMcastPmsiTunnelIf a pointer to the corresponding row in
the
ifXTable table ? Please fix accordingly.
You're right. Fixed.
9.
> > > 9. The Security Considerations section does not follow
> > > the Security Guidelines for IETF MIB Modules
> > > http://trac.tools.ietf.org/area/ops/trac/wiki/mib-security.
> > > Please fix.
>
> I was really hoping that it would not have to be that
> tedious. SNMP/MIB secur
ity should be no different from the
> CLI security - once you secure the infrastructure
> then what's more to do?
>
> I'll need more time to work on this. Let me try to address
> the issues in the other mib first and come back to this.
Please take your time. Looking at examples will help. And let me
know where I can help.
I will need to work on that later.
10.1
> > > 10.1 Checking nits according to
> > > http://www.ietf.org/id-info/checklist :
> Should I break them into different lines or just keep them
> as is? Any example of expected indentation if I break the
> lines?
No problems at all to break lines.
l2L3VpnMcastGroups OBJECT IDENTIFIER
::= {l2L3VpnMcastConformance 1}
Should do.
Done.
10.2
> > > 10.2 Checking references for intended status: Proposed
Standard
> > > == Missing Reference: 'RFC 7117' is mentioned on line
76,
> > > but not defined
> > > 'described in [RFC6513, RFC6514, RFC 7117] and other
> I hope I understood and fixed it (removing the space in "RFC
7117").
I would recommend that you put it as [RFC6513], [RFC6514], [RFC7117]
That is simpler to parse.
I see some other documents do not have comma between multiple
references so I followed that.
> > > 11. There is another WIP MVPN-MIB in
> > > draft-ietf-bess-mvpn-mib-02.txt
> > > MVPN-MIB has objects that refer to L2L3-VPN-MCAST-MIB.
> > > Is there a good reason for not merging the 2 documents?
> > > I have not seen any discussion or explanation on this.
> > > I may have missed it.
> > > Please clarify or, give some pointers.
>
> As mentioned in the introduction:
>
> this memo describes managed objects common to both VPLS
> Multicast [RFC7117] and MVPN [RFC6513, RFC6514].
> MVPN-MIB is for MVPN. There was another VPLS Multicast MIB
> in the work and both would reference common
> objects defined in this MIB.
OK. So you are saying that this MIB contains core objects that
will be used to manage implementations of various multicast VPN
protocols e.g. [RFC7117], [RFC6513],[RFC6514] ? It will help if
you spell it out at the beginning.
Yes. I thought I did it already:
1. Introduction
... and this memo describes managed objects common to both VPLS
Multicast [RFC7117] and MVPN [RFC6513, RFC6514].
Thanks!
Jeffrey
----------------------------------------------------------------------
On 2016/04/16 21:47, Jeffrey (Zhaohui) Zhang wrote:
Glenn,
Thanks for your comments. I've addressed most of your comments in
the
new revision:
URL: https://www.ietf.org/internet-drafts/draft-ietf-bess-
l2l3-vpn-mcast-mib-03.txt
Status: https://datatracker.ietf.org/doc/draft-ietf-bess-l2l3-
vpn-mcast-mib/
Htmlized: https://tools.ietf.org/html/draft-ietf-bess-l2l3-vpn-
mcast-mib-03
Diff:
https://www.ietf.org/rfcdiff?url2=draft-ietf-bess-l2l3-
vpn-mcast-mib-03
Please see below.
1. Abstract:
1.1 A sentence on how the managed objects will be used by
applications for operations, monitoring and management
would be good.
I had thought this would be standard/obvious for all MIB objects
- the
read-write ones are used to control how a device works, and the
read-only
ones are used for monitoring. Do I really need to say it explicitly?
I see RFC 4382 has the following:
This memo defines a portion of the Management Information Base
(MIB)
for use with network management protocols in the Internet
community.
In particular, it describes managed objects to configure and/or
monitor Multiprotocol Label Switching Layer-3 Virtual Private
Networks on a Multiprotocol Label Switching (MPLS) Label
Switching
Router (LSR) supporting this feature.
Is it enough to say something similar? For example:
In particular, it describes common managed objects used to
configure
and/or monitor both L2 and L3 VPN Multicast.
2. Introduction
2.1 Please give the full expansion of the abbreviations
appearing for the first time. (PE, VPLS,..)
Fixed.
2.2 The terminology section is a bit terse. Explaining the
terms that are used, nicely with reference to the protocol
documents will improve readability.
e.g.
- PMSI, I-PMSI, S-PMSI, provider tunnels
As the paragraph alluded to, this MIB needs to be understood in the
general context of L2/L3 multicast VPN and providing good
explanation of
the terms is not attempted. The references for the terms are the the
RFCs
for the relevant technologies.
Having said that, I'll explain PMSI a bit further.
2.3 Is there a difference between
"multicast in Layer 2 and Layer 3 VPNs , defined by
RFC 7117 and RFC 6513/6514"
used in the DESCRIPTION in the MODULE-IDENTITY
and
"multicast in BGP/MPLS L2 or IP VPN"
used in the DESCRIPTION of L2L3VpnMcastProviderTunnelType ?
If these are the same, it will be helpful to stick to the
same expression. If these are not the same, the dictinction
should be clarified.
No difference. I was using "Layer 3" or "L3" but it was pointed out
that
the layer 3 VPN is often referred to IP VPN in other RFCs and I was
advised to change it accordingly. Looks like I did not change all the
cases.
On the other hand, I noticed that RFC 4382 does use "Layer 3 VPN" so
I'll change it back.
3. Summary of MIB Module.
An overview of the L2L3-VPN-MCAST-MIB will be good- the
structure of the MIB, short descriptions of the table(s)
including usage of the table(s) for management and/or by
other MIB(s).
I had that, but have added one sentence about the only table.
MIB definitions:
4. MIB syntax checking:
smilint -s -e -l 5 mibs/L2L3-VPN-MCAST-MIB
2>L2L3-VPN-MCAST-MIB.txt
I used simpleweb's validation tool but looks like I did not use the
strictest level of validation. I've now fixed the following issues
and
verified.
mibs/L2L3-VPN-MCAST-MIB:63: [4] {hyphen-in-label} warning: named
number `rsvp-p2mp' must not include a hyphen in SMIv2
mibs/L2L3-VPN-MCAST-MIB:64: [4] {hyphen-in-label} warning: named
number `ldp-p2mp' must not include a hyphen in SMIv2
mibs/L2L3-VPN-MCAST-MIB:65: [4] {hyphen-in-label} warning: named
number `pim-asm' must not include a hyphen in SMIv2
mibs/L2L3-VPN-MCAST-MIB:66: [4] {hyphen-in-label} warning: named
number `pim-ssm' must not include a hyphen in SMIv2
mibs/L2L3-VPN-MCAST-MIB:67: [4] {hyphen-in-label} warning: named
number `pim-bidir' must not include a hyphen in SMIv2
mibs/L2L3-VPN-MCAST-MIB:68: [4] {hyphen-in-label} warning: named
number `ingress-replication' must not include a hyphen in SMIv2
mibs/L2L3-VPN-MCAST-MIB:69: [4] {hyphen-in-label} warning: named
number `ldp-mp2mp' must not include a hyphen in SMIv2
See later question/comments below.
mibs/L2L3-VPN-MCAST-MIB:215: [5] {group-unref} warning: current
group `l2L3VpnMcastOptionalGroup' is not referenced in this module
mibs/L2L3-VPN-MCAST-MIB:4: [5] {import-unused} warning:
identifier
`NOTIFICATION-TYPE' imported from module `SNMPv2-SMI' is never used
mibs/L2L3-VPN-MCAST-MIB:5: [5] {import-unused} warning:
identifier
`Unsigned32' imported from module `SNMPv2-SMI' is never used
mibs/L2L3-VPN-MCAST-MIB:8: [5] {import-unused} warning:
identifier
`NOTIFICATION-GROUP' imported from module `SNMPv2-CONF' is never used
mibs/L2L3-VPN-MCAST-MIB:11: [5] {import-unused} warning:
identifier
`TruthValue' imported from module `SNMPv2-TC' is never used
mibs/L2L3-VPN-MCAST-MIB:11: [5] {import-unused} warning:
identifier
`RowStatus' imported from module `SNMPv2-TC' is never used
mibs/L2L3-VPN-MCAST-MIB:12: [5] {import-unused} warning:
identifier
`TimeStamp' imported from module `SNMPv2-TC' is never used
mibs/L2L3-VPN-MCAST-MIB:12: [5] {import-unused} warning:
identifier
`TimeInterval' imported from module `SNMPv2-TC' is never used
mibs/L2L3-VPN-MCAST-MIB:15: [5] {import-unused} warning:
identifier
`SnmpAdminString' imported from module `SNMP-FRAMEWORK-MIB' is never
used
mibs/L2L3-VPN-MCAST-MIB:18: [5] {import-unused} warning:
identifier
`InetAddress' imported from module `INET-ADDRESS-MIB' is never used
mibs/L2L3-VPN-MCAST-MIB:18: [5] {import-unused} warning:
identifier
`InetAddressType' imported from module `INET-ADDRESS-MIB' is never
used
Removed the above unused imports.
5. REFERENCE clauses: Please use REFERENCE clauses liberally.
Wherever possible, provide references for objects used in
the MIB. The references will point to specific sections/
sub-sections of the RFCs defining the protocol for which the
MIB is being designed. It will greatly improve the readability
of the document.
Added.
6. IMPORTS clause
MIB modules from which items are imported must be cited and
included in the normative references.
The conventional style is
mplsStdMIB
FROM MPLS-TC-STD-MIB -- [RFC3811]
Added.
7. Please update the MODULE-IDENTITY. (There are no syntantic
errors.)
7.1 CONTACT-INFO
Following the conventions (including indentation style) will
improve the readability. (e.g. RFC4382, RFC5132).
Will be good if it does not overflow into the next page.
Fixed.
7.2 REVISION clause: follow the convention recommended in RFC4181
sec 4.5
REVISION "200212132358Z" -- December 13, 2002
DESCRIPTION "Initial version, published as RFC yyyy."
-- RFC Ed.: replace yyyy with actual RFC number & remove this
note:
Fixed.
7.3 OID assignment: follow the convention recommended in RFC4181
sec 4.5 i
replace
::= { experimental 99 } -- number to be assigned
by
::= { <subtree> XXX }
-- RFC Ed.: replace XXX with IANA-assigned number & remove this
note
<subtree> will be the subtree under which the module will be
registered.
I kept "experimental 99" so that I could continue to use mib
tools to
validate; but I added notes for the editor to replace them as you
indicated.
8. Specific MO and TC related comments.
L2L3VpnMcastProviderTunnelType ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"Types of provider tunnels used for multicast in
BGP/MPLS L2 or IP VPN."
SYNTAX INTEGER { unconfigured (0),
rsvp-p2mp (1),
ldp-p2mp (2),
pim-asm (3),
pim-ssm (4),
pim-bidir (5),
ingress-replication (6),
ldp-mp2mp (7)
o Would be nice to align the enumeration labels with the
labels in the protocol document RFC 6514 unless there is
a good reason for not doing so. (You will have to take
care of the smi compilation errors too; '-' is not allowed ).
Are spaces allowed? I don't know so I used hyphen. For now I replace
with things like rsvpP2mp.
Or could/should I just remove the definitions, so that if a new
type is
defined in the future there is no need to update the MIB?
8.1 l2L3VpnMcastPmsiTunnelAttributeEntry OBJECT-TYPE
SYNTAX L2L3VpnMcastPmsiTunnelAttributeEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"An entry in this table corresponds to an PMSI
attribute
that is advertised/received on this router.
For BGP-based signaling (for I-PMSI via
auto-discovery
procedure, or for S-PMSI via S-PMSI A-D routes),
they are just as signaled by BGP (RFC 6514 section 5,
'PMSI Tunnel attribute').
For UDP-based S-PMSI signaling for PIM-MVPN,
they're derived from S-PMSI Join Message
(RFC 6513 section 7.4.2, 'UDP-based Protocol')..
Note that BGP-based signaling may be used for
PIM-MVPN as well."
o Fix the ".." in "'UDP-based Protocol').." above.
o Please give the reference for this Table.
Is it- "PMSI Tunnel attribute" in RFC 6513 Sec.4 ?
"PMSI Tunnel attribute" in RFC 6514 Sec.5 ?
both?
Any other pointers?
Fixed.
8.2 l2L3VpnMcastPmsiTunnelAttributeFlags OBJECT-TYPE
SYNTAX OCTET STRING (SIZE (1))
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"For UDP-based S-PMSI signaling for PIM-MVPN, this
is 0.
For BGP-based I/S-PMSI signaling, this is the Flags
field in PMSI Tunnel Attribute of the corresponding
I/S-PMSI A-D route."
::= { l2L3VpnMcastPmsiTunnelAttributeEntry 1 }
o Please confirm that the above is a complete enumeration
of the
types of signalling.
o RFC 6514 Sec.5 says that the Flags field indicates
"Leaf Information Required". That is useful information.
Please include in the description.
The intent is to simply return the octet value of the flags
field, w/o
listing individual bits like "Leaf Information Required". More bits
could
be defined in the future but the MIB would not change.
Is that OK?
8.3 l2L3VpnMcastPmsiTunnelAttributeId OBJECT-TYPE
SYNTAX OCTET STRING ( SIZE (0..37) )
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"For UDP-based S-PMSI signaling for PIM-MVPN, the
first
four or sixteen octets of this attribute are filled
with
the provider tunnel group address (IPv4 or IPv6)..
For BGP-based I/S-PMSI signaling, this is the Tunnel
Identifier
Field in PMSI Tunnel Attribute of the corresponding
I/S-
PMSI
A-D route."
o Check the size specifications. The specs above say it can be
all sizes 0..37. That is not clear from the DESCRIPTION
clause.
o Fix the ".." in "(IPv4 or IPv6).." above.
o RFC 6514 Sec 5. PMSI Tunnel Attribute gives the Tunnel
Identifiers
for mLDP, PIM-SM, PIM-SSM, BIDIR-PIM,Ingress
Replication,MP2MP.
It appears that the sizes (range) for each case will be
different.
Please clarify that, and if there are discrete sizes, specify
accordingly.
Depending on the tunnel type, there could be different sizes. Future
tunnel types could have other sizes that not specified today. I was
thinking to just give a size range so that it is flexible. Is that
ok?
8.3 l2L3VpnMcastPmsiTunnelPointer OBJECT-TYPE
SYNTAX RowPointer
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"If the tunnel exists in some MIB table, this is the
row pointer to it."
o "some MIB table" : specify which MIB table.
I can give an example, like mplsTunnelTable [RFC 3812]. It could be
whatever table that a tunnel may be put into.
o In what case will the tunnel exist and in what case will it
not?
If a device supports mplsTunnelTable and the tunnel is represented
there,
then it exists.
o What will be the behaviour if the above condition is not
satisfied?
A null pointer should be given.
8.4 l2L3VpnMcastPmsiTunnelIf OBJECT-TYPE
SYNTAX RowPointer
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"If the tunnel has a corresponding interface, this
is the
row pointer to the ifName table."
o DESCRIPTION looks incorrect. Please fix it. Do you want
to say
this object points to the corresponding row in the ifTable?
Yes. Fixed.
o In what case does the TunnelIf exist and in what case
will it
not?
Some tunnels may not have a corresponding interface.
o What will be expected if the tunnel does not have a
corresponding
interface?
Null row pointer.
9. The Security Considerations section does not follow the Security
Guidelines for IETF MIB Modules
http://trac.tools.ietf.org/area/ops/trac/wiki/mib-security.
Please fix.
I was really hoping that it would not have to be that tedious.
SNMP/MIB
security should be no different from the CLI security - once you
secure
the infrastructure then what's more to do?
I'll need more time to work on this. Let me try to address the
issues in
the other mib first and come back to this.
10.ID-nits
10.1 Checking nits according to
http://www.ietf.org/id-info/checklist :
------------------------------------------------------------------
---------
** There are 4 instances of too long lines in the document,
the
longest one
being 3 characters in excess of 72.
I fixed some but there still three too long lines:
l2L3VpnMcastPmsiTunnelAttributeType
L2L3VpnMcastProviderTunnelType,
l2L3VpnMcastGroups OBJECT IDENTIFIER ::=
{l2L3VpnMcastConformance
1}
l2L3VpnMcastCompliances OBJECT IDENTIFIER ::=
{l2L3VpnMcastConformance
2}
Should I break them into different lines or just keep them as is?
Any
example of expected indentation if I break the lines?
10.2 Checking references for intended status: Proposed Standard
------------------------------------------------------------------
---------
== Missing Reference: 'RFC 7117' is mentioned on line 76, but
not
defined
'described in [RFC6513, RFC6514, RFC 7117] and other
documents
tha...'
I hope I understood and fixed it (removing the space in "RFC 7117").
11. There is another WIP MVPN-MIB in
draft-ietf-bess-mvpn-mib-02.txt
MVPN-MIB has objects that refer to L2L3-VPN-MCAST-MIB.
Is there a good reason for not merging the 2 documents? I have
not
seen
any discussion or explanation on this. I may have missed it.
Please
clarify or, give some pointers.
As mentioned in the introduction:
this memo describes managed objects common to both VPLS
Multicast [RFC7117] and MVPN [RFC6513, RFC6514].
MVPN-MIB is for MVPN. There was another VPLS Multicast MIB in the
work
and both would reference common objects defined in this MIB.
Thanks!
Jeffrey
-----Original Message-----
From: BESS [mailto:[email protected]] On Behalf Of Glenn
Mansfield
Keeni
Sent: Tuesday, April 12, 2016 2:28 AM
To: Benoit Claise <[email protected]>; EXT -
[email protected]
<[email protected]>
Cc: Jeffrey (Zhaohui) Zhang <[email protected]>; [email protected];
Martin
Vigoureux <[email protected]>; [email protected]; Mach Chen
<[email protected]>
Subject: [bess] MIBDoc review of
draft-ietf-bess-l2l3-vpn-mcast-mib-
02.txt
Hi,
I have been asked to do a MIB Doctors review of
draft-ietf-bess-l2l3-vpn-mcast-mib-02.txt.
My knowledge of L2L3VPN Multicast is limited to the reading
of this document and browsing through the documents referred
to in the draft and bess-wg mailing list archives.( read
"shallow").
So some of the doubts and questions may sound trivial or
strange. Please bear with me and help me help you make
this into a better document :-)
The comments are attached.
Glenn
_______________________________________________
BESS mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/bess
