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

From: Kishore Tiruveedhula <[email-masked]>
Date: Tue, 13 Oct 2015 02:17:26 +0000

Hi Loa, Joan

I updated the draft for the below comments from "Joan Cucchiara² and
posted the new version draft-tiruveedhula-mpls-mldp-mib-05.
Please let me know what would be the next steps for making the working
group adoption ?

-------------------
Name:		draft-tiruveedhula-mpls-mldp-mib
Revision:	05
Title:		Definitions of Managed Objects for the LDP Point-to-Multipoint and
Multipoint-to-Multipoint Label Switched Paths
Document date:	2015-10-12
Group:		Individual Submission
Pages:		37
URL:            
https://www.ietf.org/internet-drafts/draft-tiruveedhula-mpls-mldp-mib-05.tx
t
Status:         
https://datatracker.ietf.org/doc/draft-tiruveedhula-mpls-mldp-mib/
Htmlized:       
https://tools.ietf.org/html/draft-tiruveedhula-mpls-mldp-mib-05
Diff:           
https://www.ietf.org/rfcdiff?url2=draft-tiruveedhula-mpls-mldp-mib-05
----------------------

Thanks,
Kishore

On 5/21/15, 12:38 PM, "Kishore Tiruveedhula" <[email-masked]> wrote:

>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:
>
>>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
>>
>