Subject: Re: [MIB-DOCTORS] MPLS-RT review of draft-tiruveedhula-mpls-mldp-mib-04

From: "Joan Cucchiara" <[email-masked]>
Date: Thu, 21 May 2015 11:52:35 -0400

Hello,  (also cc'ing MIB Doctors)

To the question of is this MIB Module ready for WG adoption, unfortunately,  I would say "no" due to some very outdated practices that the authors are using which make the MIB Module NOT technically sound.    The following two issues are very well-documented in the MIB Review guidelines (RFC418).   These should be extremely easy fixes, but I would implore that the authors  take care NOT to repeat these outdated practices in future draft versions.  

1) The  sub-id MUST be requested from IANA when the document becomes an RFC.  Please do NOT assign a sub-id yourselves.   
Please refer to  RFC4181.

         ::= { mplsStdMIB 99 }

2) LAST-UPDATED and (latest) REVISION clause dates do not agree.   They should always agree.  Again, please refer to RFC4181.

Also, since the above needs to be updated, would also ask that the authors use the word "Notifications" instead of "Traps" in Section 4.  and also put the "END" clause on the MIB Module.

General Comments:
------------------------------

The approach of extending/Augmenting with existing MIB Modules, RFC3815 and RFC3813 is a good way to  approach this MIB Module in my opinion.   Also, glad to see that the REFERENCE Clauses are used as this helps out tremendously with reviewing and implementing.

Potential Unknown:

Would caution that NOT all of the tables seem to contain valid indices, as such, I do not completely understand all of the relationships between tables in this MIB and the other MIB Modules.  This may not be an issue at all, but just something to be aware of for future MIB reviews.   Having said that, it does seem that the authors are heading in a good direction by making use of existing MIB Modules with extending/augmenting tables in this draft.   At this point, I do not have a specific concern and think that this will be developed during the WG group process.

Review Considerations for Reviewers, specifically:
=========================================
"whether the document is coherent, is it useful
(ie, is it likely to be actually useful in operational networks), and is the
document technically sound?  We are interested in knowing whether the
document is ready to be considered for WG adoption (ie, it doesn't have to
be perfect at this point, but should be a good start)."

Document is coherent in that the objects defined are useful and support new features of LDP.  Also, the overall organization seems like a good approach.   I think a good deal of thought went into the proposed MIB Module with regard to leveraging from existing MIB Modules.

I do think that it would be useful in an operational network as this MIB Module extends/augments existing MIB Modules which are widely deployed.

Thanks,
 -Joan

> -----Original Message-----
> From: Loa Andersson [mailto:[email-masked]]
> Sent: Monday, May 11, 2015 9:59 AM
> To: [email-masked]; Young Lee; Joan Cucchiara
> Cc: [email-masked]; Mach Chen; draft-tiruveedhula-mpls-mldp-
> [email-masked]
> Subject: MPLS-RT review of draft-tiruveedhula-mpls-mldp-mib-04
> 
> Sam, Young and Joan,
> 
> 
> You have be selected as MPLS-RT reviewers for draft-tiruveedhula- mpls-
> mldp-mib.
> 
> Note to authors: You have been CC'd on this email so that you can know that
> this review is going on. However, please do not review your own document.
> 
> Reviews should comment on whether the document is coherent, is it useful
> (ie, is it likely to be actually useful in operational networks), and is the
> document technically sound?  We are interested in knowing whether the
> document is ready to be considered for WG adoption (ie, it doesn't have to
> be perfect at this point, but should be a good start).
> 
> Reviews should be sent to the document authors, WG co-chairs and WG
> secretary, and CC'd to the MPLS WG email list. If necessary, comments may
> be sent privately to only the WG chairs.
> 
> Mach Chen is the document shepherd for this draft, the reviews should be
> sent to him also.
> 
> If you have technical comments you should try to be explicit about what
> *really* need to be resolved before adopting it as a working group
> document, and what can wait until the document is a working group
> document and the working group has the revision control.
> 
> Are you able to review this draft by May 26, 2015? Please respond in a timely
> fashion.
> 
> 
> Thanks, Loa
> (as MPLS WG chair)
> --
> 
> 
> Loa Andersson                        email: [email-masked]
> Senior MPLS Expert                          [email-masked]
> Huawei Technologies (consultant)     phone: +46 739 81 21 64
> 
> 
> -----
> No virus found in this message.
> Checked by AVG - www.avg.com
> Version: 2014.0.4800 / Virus Database: 4311/9748 - Release Date: 05/11/15

---

From: Kishore Tiruveedhula <[email-masked]>
Date: Thu, 21 May 2015 16:38:24 +0000

Thanks Joan for reviewing this. I will update the doc for the comments.

Thanks,
Kishore

On 5/21/15, 11:52 AM, "Joan Cucchiara" <[email-masked]> wrote:

>To the question of is this MIB Module ready for WG adoption,
>unfortunately,  I would say "no" due to some very outdated practices that
>the authors are using which make the MIB Module NOT technically sound.
>The following two issues are very well-documented in the MIB Review
>guidelines (RFC418).   These should be extremely easy fixes, but I would
>implore that the authors  take care NOT to repeat these outdated
>practices in future draft versions.
>
>1) The  sub-id MUST be requested from IANA when the document becomes an
>RFC.  Please do NOT assign a sub-id yourselves.
>Please refer to  RFC4181.
>
>         ::= { mplsStdMIB 99 }
>
>2) LAST-UPDATED and (latest) REVISION clause dates do not agree.   They
>should always agree.  Again, please refer to RFC4181.
>
>Also, since the above needs to be updated, would also ask that the
>authors use the word "Notifications" instead of "Traps" in Section 4.
>and also put the "END" clause on the MIB Module.
>
>General Comments:
>The approach of extending/Augmenting with existing MIB Modules, RFC3815
>and RFC3813 is a good way to  approach this MIB Module in my opinion.
>Also, glad to see that the REFERENCE Clauses are used as this helps out
>tremendously with reviewing and implementing.
>
>Potential Unknown:
>
>Would caution that NOT all of the tables seem to contain valid indices,
>as such, I do not completely understand all of the relationships between
>tables in this MIB and the other MIB Modules.  This may not be an issue
>at all, but just something to be aware of for future MIB reviews.
>Having said that, it does seem that the authors are heading in a good
>direction by making use of existing MIB Modules with extending/augmenting
>tables in this draft.   At this point, I do not have a specific concern
>and think that this will be developed during the WG group process.
>
>Document is coherent in that the objects defined are useful and support
>new features of LDP.  Also, the overall organization seems like a good
>approach.   I think a good deal of thought went into the proposed MIB
>Module with regard to leveraging from existing MIB Modules.
>
>I do think that it would be useful in an operational network as this MIB
>Module extends/augments existing MIB Modules which are widely deployed.
>
>Thanks,
> -Joan
>
>