Subject: Re: [MIB-DOCTORS] New Version Notification for draft-ietf-mpls-tp-oam-id-mib-07.txt

From: Benoit Claise <[email-masked]>
Date: Sun, 01 Mar 2015 18:03:42 +0100

On 01/03/2015 05:53, Loa Andersson wrote:
> Joan,
>
> thanks - you are right about fixing this later in the process, however
> the publication request is not yet sent, so the next substantial step
> is AD evaluation. I'll ask Mach to make sure this is addressed as part
> of the AD evaluation.
Even better than AUTH48, which might be forgotten.

Regards, Benoit
>
> Mach,
>
> feel pinged.
>
> /Loa
>
> On 2015-03-01 05:50, Joan Cucchiara wrote:
>> Authors,
>>
>> This looks good!  Thanks!   A couple of warnings were detected and
>> perhaps could be fixed during RFC editor process?
>>
>> Thanks,
>>
>> -Joan
>>
>> Warning with SMICNG compiler:
>>
>> W: f(MPLS-TP-OAM-MIB.my), (883,22) MIN-ACCESS value identical to access
>> specified for "mplsOamIdMegOperStatus"
>>
>> W: f(MPLS-TP-OAM-MIB.my), (888,22) MIN-ACCESS value identical to access
>> specified for "mplsOamIdMegSubOperStatus"
>>
>> *From:*Mach Chen [mailto:[email-masked]]
>> *Sent:* Friday, February 27, 2015 8:28 PM
>> *To:* Venkatesan Mahalingam; Joan Cucchiara
>> *Cc:* Sam Aldrin; Joan Cucchiara; [email-masked]; MIB
>> Doctors (E-mail)
>> *Subject:* RE: New Version Notification for
>> draft-ietf-mpls-tp-oam-id-mib-07.txt
>>
>> Hi Joan,
>>
>> The version-08 is available, could you please take a look at this
>> version to see whether you are OK with it?
>>
>> Many thanks,
>>
>> Mach
>>
>> *From:*Venkatesan Mahalingam [mailto:[email-masked]]
>> *Sent:* Friday, February 27, 2015 2:05 AM
>> *To:* Joan Cucchiara
>> *Cc:* Mach Chen; Sam Aldrin; Joan Cucchiara; [email-masked];
>> MIB Doctors (E-mail)
>> *Subject:* Re: New Version Notification for
>> draft-ietf-mpls-tp-oam-id-mib-07.txt
>>
>> Hi,
>>
>> New version 08 is available now. let us know if you have any further
>> questions/comments.
>>
>> https://tools.ietf.org/id/draft-ietf-mpls-tp-oam-id-mib-08.txt
>>
>> -Venkat.
>>
>> On Thu, Feb 26, 2015 at 8:14 AM, Joan Cucchiara
>> <[email-masked] <mailto:[email-masked]>> wrote:
>>
>> Sam and authors,
>>
>> Please make sure that the MIB Modules are compiled cleanly PRIOR to
>> submission.    Please let me know if I can help with that.
>>
>> Security section looks okay, so thanks for the update.
>>
>> Thanks,
>>
>> -Joan
>>
>> *From:*Mach Chen [mailto:[email-masked]
>> <mailto:[email-masked]>]
>> *Sent:* Thursday, February 26, 2015 2:50 AM
>> *To:* Sam Aldrin
>> *Cc:* Venkatesan Mahalingam; Joan Cucchiara; [email-masked]
>> <mailto:[email-masked]>; [email-masked]
>> <mailto:[email-masked]>; Joan Cucchiara
>>
>> *Subject:*RE: New Version Notification for
>> draft-ietf-mpls-tp-oam-id-mib-07.txt
>>
>> Sam,
>>
>> OK, please go ahead, looking forward to seeing the new revision.
>>
>> Best regards,
>>
>> Mach
>>
>> *From:*Sam Aldrin [mailto:[email-masked]
>> <mailto:[email-masked]>]
>> *Sent:* Thursday, February 26, 2015 3:42 PM
>> *To:* Mach Chen
>> *Cc:* Venkatesan Mahalingam; Joan Cucchiara; [email-masked]
>> <mailto:[email-masked]>; [email-masked]
>> <mailto:[email-masked]>; Joan Cucchiara
>> *Subject:* Re: New Version Notification for
>> draft-ietf-mpls-tp-oam-id-mib-07.txt
>>
>> Mach,
>>
>> If Readonly compliance is all that is remaining, then we will go ahead
>> and work to get a new rev published.
>>
>> As far as Read-write is concerned, we added the text like in TP-TE MIB
>> (RFC 7453), because it is essential and was implemented as well.
>>
>> Not only that, this MIB goes along with the TP-TE MIB, hence retained
>> the write option from day 1.
>>
>> cheers
>>
>> -sam
>>
>>     On Feb 25, 2015, at 11:36 PM, Mach Chen <[email-masked]
>>     <mailto:[email-masked]>> wrote:
>>
>>     Sam,
>>
>>     OK, I’m glad to hear that you are still working on the draft.  Both
>>     Joan and I asked your plan three weeks ago, but no response received
>>     yet. The draft has been reviewed several time, in my understanding,
>>     except the “Read-only” compliance one, almost all comments are
>>     addressed.
>>
>>     Best regards,
>>
>>     Mach
>>
>>     *From:*Sam Aldrin [mailto:[email-masked]]
>>     *Sent:* Thursday, February 26, 2015 2:22 PM
>>     *To:* Mach Chen
>>     *Cc:* Venkatesan Mahalingam; Joan Cucchiara;
>>     [email-masked] <mailto:[email-masked]>;
>>     [email-masked] <mailto:[email-masked]>; Joan Cucchiara
>>     *Subject:* Re: New Version Notification for
>>     draft-ietf-mpls-tp-oam-id-mib-07.txt
>>
>>     Mach,
>>
>>     What do you mean by stall state?
>>
>>     MIB’s do take time for the well known reasons. Check the ID’s in the
>>     WG history.
>>
>>     We have indicated 3 weeks ago that ‘Read only’ compliance, as
>>     pointed by Joan, will be added.
>>
>>     Once we receive review comments, which we are waiting, will revise a
>>     new ID along with the compliance statement.
>>
>>     Are you asking to publish a new version first and one more after?
>>
>>     -sam
>>
>>         On Feb 25, 2015, at 9:59 PM, Mach Chen <[email-masked]
>>         <mailto:[email-masked]>> wrote:
>>
>>         Hi Authors,
>>
>>         The draft has been in a stall state for a while, do you still
>>         have interest and energy to keep progressing it further? If so,
>>         could you provide the status and your plan of the draft?
>>         Otherwise, I may suggest the WG to abandon the draft.
>>
>>         Best regards,
>>
>>         Mach
>>
>>         *From:*Joan Cucchiara [mailto:[email-masked]]
>>         *Sent:* Wednesday, February 04, 2015 12:15 AM
>>         *To:* Mach Chen; 'Venkatesan Mahalingam'; 'Joan Cucchiara'; 'Sam
>>         Aldrin'
>>         *Cc:* [email-masked]
>>         <mailto:[email-masked]>; [email-masked]
>>         <mailto:[email-masked]>
>>         *Subject:* RE: New Version Notification for
>>         draft-ietf-mpls-tp-oam-id-mib-07.txt
>>
>>         Mach,
>>
>>         I will take a look soon.
>>
>>         Authors,
>>
>>         Could you let me know your plan also?   I am cc’ing the MIB
>>         Dr.’s  too.   SNMP sets come up over and over again and better
>>         to understand what the authors decide sooner rather than later,
>>         IMHO.
>>
>>         As I have said from the beginning reviews of this doc, that I
>>         think the addition  of a read-only compliance would be 
>> preferable.
>>
>>         Thanks,
>>
>>         -Joan
>>
>>         *From:*Mach Chen [mailto:[email-masked]]
>>         *Sent:* Tuesday, February 03, 2015 12:54 AM
>>         *To:* Venkatesan Mahalingam; Joan Cucchiara; Joan Cucchiara; Sam
>>         Aldrin
>>         *Cc:* [email-masked] 
>> <mailto:[email-masked]>
>>         *Subject:* RE: New Version Notification for
>>         draft-ietf-mpls-tp-oam-id-mib-07.txt
>>
>>         Hi Joan,
>>
>>         Could you please confirm whether this revision solved your
>>         comments?
>>
>>         To Kenkat and Sam,
>>
>>         For the left comment listed below, what’s your plan about it?
>>
>>         Thanks,
>>
>>         Mach
>>
>>         *From:*Venkatesan Mahalingam 
>> [mailto:[email-masked]]
>>         *Sent:* Tuesday, February 03, 2015 4:21 AM
>>         *To:* Mach Chen; Joan Cucchiara; Joan Cucchiara; Sam Aldrin
>>         *Subject:* Fwd: New Version Notification for
>>         draft-ietf-mpls-tp-oam-id-mib-07.txt
>>
>>         Hi,
>>
>>         We have submitted the new version addressing Joan's comments
>>         except the below comment, will work further on the same.
>>
>>         > > Compliance Statement of the MIB
>>         > > ----------------------------------------------
>>         > > 2) Compliance (mentioned this before)
>>         > >
>>         > > There is no read-only compliance. Has it been made clear 
>> to the WGs
>>         > > (MPLS and
>>         > > PWE3) that SNMP sets  will need to be supported in order 
>> to be
>>         > > compliant with the MIB?
>>
>>         -Venkat.
>>
>>         ---------- Forwarded message ----------
>>         From: <[email-masked] 
>> <mailto:[email-masked]>>
>>         Date: Mon, Feb 2, 2015 at 12:08 PM
>>         Subject: New Version Notification for
>>         draft-ietf-mpls-tp-oam-id-mib-07.txt
>>         To: Venkatesan Mahalingam <[email-masked]
>>         <mailto:[email-masked]>>, Kannan KV Sampath
>>         <[email-masked] <mailto:[email-masked]>>, Sam Aldrin
>>         <[email-masked] <mailto:[email-masked]>>, "Thomas
>>         D. Nadeau" <[email-masked]
>>         <mailto:[email-masked]>>
>>
>>
>>
>>         A new version of I-D, draft-ietf-mpls-tp-oam-id-mib-07.txt
>>         has been successfully submitted by Venkatesan Mahalingam and
>>         posted to the
>>         IETF repository.
>>
>>         Name:           draft-ietf-mpls-tp-oam-id-mib
>>         Revision:       07
>>         Title:          MPLS-TP Operations, Administration, and
>>         Management (OAM) Identifiers Management Information Base (MIB)
>>         Document date:  2015-02-02
>>         Group:          mpls
>>         Pages:          28
>>         URL:
>> http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-oam-id-mib-07.txt
>>         Status:
>> https://datatracker.ietf.org/doc/draft-ietf-mpls-tp-oam-id-mib/
>>         Htmlized:
>> http://tools.ietf.org/html/draft-ietf-mpls-tp-oam-id-mib-07
>>         Diff:
>> http://www.ietf.org/rfcdiff?url2=draft-ietf-mpls-tp-oam-id-mib-07
>>
>>         Abstract:
>>             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 Operations, Administration, and
>>             Management (OAM) identifiers related managed objects for
>>             Multiprotocol Label Switching (MPLS) and MPLS based
>>         Transport Profile
>>             (TP).
>>
>>
>>
>>
>>         Please note that it may take a couple of minutes from the time
>>         of submission
>>         until the htmlized version and diff are available at
>>         tools.ietf.org <http://tools.ietf.org/>.
>>
>>         The IETF Secretariat
>>
>>         No virus found in this message.
>>         Checked by AVG - www.avg.com <http://www.avg.com/>
>>         Version: 2014.0.4800 / Virus Database: 4257/9047 - Release Date:
>>         02/02/15
>>
>> No virus found in this message.
>> Checked by AVG - www.avg.com <http://www.avg.com>
>>
>> Version: 2014.0.4800 / Virus Database: 4257/9180 - Release Date: 
>> 02/25/15
>>
>> No virus found in this message.
>> Checked by AVG - www.avg.com <http://www.avg.com>
>> Version: 2014.0.4800 / Virus Database: 4257/9194 - Release Date: 
>> 02/27/15
>>
>

---

From: Mach Chen <[email-masked]>
Date: Tue, 3 Mar 2015 02:52:36 +0000

Hi Benoit, Loa, Joan,

Thanks for your suggestions, will work with the authors to make sure this will be addressed.

To Loa,

Does it mean we could progress it to AD evaluation stage?

Best regards,
Mach

> -----Original Message-----
> From: Benoit Claise [mailto:[email-masked]]
> Sent: Monday, March 02, 2015 1:04 AM
> To: Loa Andersson; Joan Cucchiara; Mach Chen; 'Venkatesan Mahalingam'
> Cc: 'MIB Doctors (E-mail)'; [email-masked]; 'Sam Aldrin'; 'Joan
> Cucchiara'
> Subject: Re: [MIB-DOCTORS] New Version Notification for
> >> W: f(MPLS-TP-OAM-MIB.my), (883,22) MIN-ACCESS value identical to
> >> access specified for "mplsOamIdMegOperStatus"
> >>
> >> W: f(MPLS-TP-OAM-MIB.my), (888,22) MIN-ACCESS value identical to
> >> access specified for "mplsOamIdMegSubOperStatus"
> >>
> >> *Cc:* Mach Chen; Sam Aldrin; Joan Cucchiara;
> >> [email-masked]; MIB Doctors (E-mail)
> >> If Readonly compliance is all that is remaining, then we will go
> >> ahead and work to get a new rev published.
> >>
> >> As far as Read-write is concerned, we added the text like in TP-TE
> >> MIB (RFC 7453), because it is essential and was implemented as well.
> >>

---

From: Loa Andersson <[email-masked]>
Date: Tue, 03 Mar 2015 12:39:15 +0800

Mach,

> Does it mean we could progress it to AD evaluation stage?

I think we can complete the Shepherds Write-up, ask for author and
chair feedback on the write-up, and send the publication request.
In a separate note to the responsible AD (we'll put it down as Adrian,
but I suspect that it is to late for him to guide this through 
publication) that there are two small warnings that the authors have
agreed to fix along with the rest of the AD comments.

I this case I'd copy the Shepherd Write-up to the MIB-doctors also,

/Loa

-- 

Loa Andersson                        email: [email-masked]
Senior MPLS Expert                          [email-masked]
Huawei Technologies (consultant)     phone: +46 739 81 21 64

---

From: Mach Chen <[email-masked]>
Date: Tue, 3 Mar 2015 05:58:51 +0000

Loa,

I have updated the Shepherds Write-up, the Responsible AD is still Adrian. 

Best regards,
Mach

PS, Shepherds Write-up:
"
As required by RFC 4858, this is the current template for the Document 
Shepherd Write-Up.

Changes are expected over time. This version is dated 24 February 2012.

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)?  Why
is this the proper type of RFC?  Is this type of RFC indicated in the
title page header?

  Proposed Standard.

(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary

  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 Operations, Administration, and
  Management (OAM) identifiers related managed objects for
  Multiprotocol Label Switching (MPLS) and MPLS based Transport Profile
  (TP).

Working Group Summary

  There is good consensus from the WG, and there is no controversy. 

Document Quality

  The draft has been a WG document for over two years. There was active
  discussion in the WG, it passed the MIB Doctor and experts review, many
  valuable comments received and addressed. A number of iterations 
  reflecting that. There are number of vendors that either has or will 
  implement the MIB module.

Personnel

  Document Shepherd: Mach Chen
  Responsible Area Director: Adrian Farrel

(3) Briefly describe the review of this document that was performed by
the Document Shepherd.  If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.

  The Document Shepherd has reviewed the draft and raised some  
  comments that have been solved in the latest version. After the review,
  the Document Shepherd thinks that there is no outstanding issue with the 
  draft and it is ready for publication.

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?  

  No.

(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.

  It has passed the review of MIB Doctor.

(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the
IESG should be aware of? For example, perhaps he or she is uncomfortable
with certain parts of the document, or has concerns whether there really
is a need for it. In any event, if the WG has discussed those issues and
has indicated that it still wishes to advance the document, detail those
concerns here.

  None.

(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why.
  
  Yes.

(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

  None.

(9) How solid is the WG consensus behind this document? Does it 
represent the strong concurrence of a few individuals, with others
being silent, or does the WG as a whole understand and agree with it?   

  There is good consensus from the WG.

(10) Has anyone threatened an appeal or otherwise indicated extreme 
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.) 

  No.

(11) Identify any ID nits the Document Shepherd has found in this
document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.

  None.

(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

  The document passed the review of MIB Doctor.

(13) Have all references within this document been identified as
either normative or informative?

  Yes.

(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?

 No.

(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in 
the Last Call procedure. 

  No.

(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are not
listed in the Abstract and Introduction, explain why, and point to the
part of the document where the relationship of this document to the
other RFCs is discussed. If this information is not in the document,
explain why the WG considers it unnecessary.

  No.

(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly
identified. Confirm that newly created IANA registries include a
detailed specification of the initial contents for the registry, that
allocations procedures for future registrations are defined, and a
reasonable name for the new registry has been suggested (see RFC 5226).
  
  The IANA section is well written, all IANA requests are clearly identified.

(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find
useful in selecting the IANA Experts for these new registries.

  No additional IANA registries are requested.

(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.

  The draft (version 07) passed smilint.

  There (Version 08) are two warnings (as listed below) with SMICNG 
  compiler, the plan is to address them with the AD review comments.

> From: Loa Andersson [mailto:[email-masked]]
> Sent: Tuesday, March 03, 2015 12:39 PM
> To: Mach Chen; Benoit Claise; Joan Cucchiara; 'Venkatesan Mahalingam'
> I think we can complete the Shepherds Write-up, ask for author and chair
> feedback on the write-up, and send the publication request.
> In a separate note to the responsible AD (we'll put it down as Adrian, but I
> suspect that it is to late for him to guide this through
> publication) that there are two small warnings that the authors have agreed to fix
> along with the rest of the AD comments.
> 
> >> Cc: 'MIB Doctors (E-mail)'; [email-masked]; 'Sam Aldrin';
> >> 'Joan Cucchiara'
> >>> thanks - you are right about fixing this later in the process,
> >>> however the publication request is not yet sent, so the next
> >>> substantial step is AD evaluation. I'll ask Mach to make sure this
> >>> is addressed as part of the AD evaluation.
> >>>> New version 08 is available now. let us know if you have any
> >>>> further questions/comments.
> >>>>
> >>>> Not only that, this MIB goes along with the TP-TE MIB, hence
> >>>> retained the write option from day 1.
> >>>>
> >>>> cheers
> >>>>
> >>>> -sam
> >>>>
> >>>>          > > There is no read-only compliance. Has it been made
> >>>> clear to the WGs
> >>>>          > > (MPLS and
> >>>>          > > PWE3) that SNMP sets  will need to be supported in
> >>>> order to be
> >>>>          > > compliant with the MIB?
> >>>>
> >>>>          -Venkat.
> >>>>

---

From: Loa Andersson <[email-masked]>
Date: Tue, 03 Mar 2015 14:17:55 +0800

Mach,

Some small nits, preceded by "Loa:"

I would wait for comments from one of the authors or Joan, before gp
ahead.

When you updated and want to send the publication request please let me
know, since due to a quirk in the data-tracker only chairs can request
publication.

> is this the proper type of RFC?  Is this type of RFC indicated in the

Loa: You should add that the document header says "Standards Track".

>    draft and it is ready for publication.
Loa: If you want you can add that you took over as SHepherd to sort out 
comments raised during wglc.
>    The document passed the review of MIB Doctor.

Loa: Add a pointer to question 19.

/Loa

--

---

From: Sam Aldrin <[email-masked]>
Date: Mon, 2 Mar 2015 23:01:27 -0800

Hi Mach,

Thanks for the writeup. Looks good.

cheers
-sam
> On Mar 2, 2015, at 9:58 PM, Mach Chen <[email-masked]> wrote:
> 
> Loa,
>

---

From: Mach Chen <[email-masked]>
Date: Tue, 3 Mar 2015 07:02:44 +0000

Loa,

Thanks for the review, I will update the Write-up accordingly.

Best regards,
Mach

> Sent: Tuesday, March 03, 2015 2:18 PM
> Cucchiara'; [email-masked]
> I would wait for comments from one of the authors or Joan, before gp ahead.
> 
> When you updated and want to send the publication request please let me know,
> since due to a quirk in the data-tracker only chairs can request publication.
> 
> > Internet Standard, Informational, Experimental, or Historic)?  Why is
> > this the proper type of RFC?  Is this type of RFC indicated in the
> > title page header?
> >
> >    Proposed Standard.
> 
> > (6) Describe any specific concerns or issues that the Document
> > Shepherd has with this document that the Responsible Area Director
> > and/or the IESG should be aware of? For example, perhaps he or she is
> > uncomfortable with certain parts of the document, or has concerns
> > whether there really is a need for it. In any event, if the WG has
> > discussed those issues and has indicated that it still wishes to
> > advance the document, detail those concerns here.
> >
> >    None.
> >
> > disclosures required for full conformance with the provisions of BCP
> > 78 and BCP 79 have already been filed. If not, explain why.
> >
> >    Yes.
> >
> > document. (See http://www.ietf.org/tools/idnits/ and the
> > Internet-Drafts Checklist). Boilerplate checks are not enough; this
> > check needs to be thorough.
> >
> >    None.
> >
> > (14) Are there normative references to documents that are not ready
> > for advancement or are otherwise in an unclear state? If such
> > normative references exist, what is the plan for their completion?
> >
> >   No.
> >
> > in the abstract, and discussed in the introduction? If the RFCs are
> > not listed in the Abstract and Introduction, explain why, and point to
> > the part of the document where the relationship of this document to
> > the other RFCs is discussed. If this information is not in the
> > document, explain why the WG considers it unnecessary.
> >
> >    No.
> >
> > (17) Describe the Document Shepherd's review of the IANA
> > considerations section, especially with regard to its consistency with
> > the body of the document. Confirm that all protocol extensions that
> > the document makes are associated with the appropriate reservations in IANA
> registries.
> > (18) List any new IANA registries that require Expert Review for
> > future allocations. Provide any public guidance that the IESG would
> > find useful in selecting the IANA Experts for these new registries.
> >
> >>> Thanks for your suggestions, will work with the authors to make sure
> >>> this will
> >> be addressed.
> >>>
> >>> To Loa,
> >>>
> >> In a separate note to the responsible AD (we'll put it down as
> >> Adrian, but I suspect that it is to late for him to guide this
> >> through
> >>>> Cc: 'MIB Doctors (E-mail)'; [email-masked]; 'Sam
> >>>> Aldrin'; 'Joan Cucchiara'
> >>>>>> As far as Read-write is concerned, we added the text like in
> >>>>>> TP-TE MIB (RFC 7453), because it is essential and was implemented as
> well.
> >>>>>>
> >>>>>>       MIB’s do take time for the well known reasons. Check the
> >>>>>> ID’s in
> >> the
> >>>>>>       WG history.
> >>>>>>
> >>>>>>       Once we receive review comments, which we are waiting, will
> >>>>>> revise
> >> a
> >>>>>>           *To:* Mach Chen; 'Venkatesan Mahalingam'; 'Joan
> >>>>>> Cucchiara';
> >> 'Sam
> >>>>>>           Aldrin'
> >>>>>>           *To:* Venkatesan Mahalingam; Joan Cucchiara; Joan
> >>>>>> Cucchiara;
> >> Sam
> >>>>>>           Aldrin
> >>>>>>           <[email-masked] <mailto:[email-masked]>>,
> Sam
> >>>> Aldrin
> >>>>>>           has been successfully submitted by Venkatesan
> >>>>>> Mahalingam
> >> and
> >>>>>>           posted to the
> >>>>>>           IETF repository.
> >>>>>>
> >>>>>>           Management (OAM) Identifiers Management Information
> >>>>>> Base
> >>>> (MIB)
> >>>>>>               Management (OAM) identifiers related managed
> >>>>>> objects
> >> for

---

From: "Joan Cucchiara" <[email-masked]>
Date: Tue, 3 Mar 2015 06:35:28 -0500

Please note wrt #19,  that version 08 of the document passed smiLint compiler also.  
There were MIB Module changes between 07 and 08, so better to indicated version 08.

Thanks,
-Joan

> From: Mach Chen [mailto:[email-masked]]
> Sent: Tuesday, March 03, 2015 2:03 AM
> To: Loa Andersson; Benoit Claise; Joan Cucchiara; 'Venkatesan Mahalingam'
> Subject: RE: [MIB-DOCTORS] New Version Notification for draft-ietf-mpls-tp-
> oam-id-mib-07.txt
> 
> Loa,
> 
> > 'Joan Cucchiara'; [email-masked]
> > When you updated and want to send the publication request please let
> > me know, since due to a quirk in the data-tracker only chairs can request
> publication.
> >
> > > As required by RFC 4858, this is the current template for the
> > > Document Shepherd Write-Up.
> > >
> > > is this the proper type of RFC?  Is this type of RFC indicated in
> > > the title page header?
> > >
> > >    Proposed Standard.
> >
> > > Write-Up. Please provide such a Document Announcement Write-Up.
> > > Recent examples can be found in the "Action" announcements for
> > > approved documents. The approval announcement contains the
> following sections:
> > >
> > > Technical Summary
> > >
> > > (3) Briefly describe the review of this document that was performed
> > > by the Document Shepherd.  If this version of the document is not
> > > ready for publication, please explain why the document is being
> > > forwarded to the IESG.
> > >
> > Loa: If you want you can add that you took over as SHepherd to sort
> > out comments raised during wglc.
> > >
> > > (5) Do portions of the document need review from a particular or
> > > from broader perspective, e.g., security, operational complexity,
> > > AAA, DNS, DHCP, XML, or internationalization? If so, describe the
> > > review that took place.
> > >
> > > and/or the IESG should be aware of? For example, perhaps he or she
> > > is uncomfortable with certain parts of the document, or has concerns
> > > discontent? If so, please summarise the areas of conflict in
> > > separate email messages to the Responsible Area Director. (It should
> > > be in a separate email because this questionnaire is publicly
> > > available.)
> > >
> > >    No.
> > >
> > > If so, list these downward references to support the Area Director
> > > in the Last Call procedure.
> > >
> > >    No.
> > >
> > > existing RFCs? Are those RFCs listed on the title page header,
> > > listed in the abstract, and discussed in the introduction? If the
> > > RFCs are not listed in the Abstract and Introduction, explain why,
> > > and point to the part of the document where the relationship of this
> > > document to the other RFCs is discussed. If this information is not
> > > in the document, explain why the WG considers it unnecessary.
> > >
> > >    No.
> > >
> > > considerations section, especially with regard to its consistency
> > > with the body of the document. Confirm that all protocol extensions
> > > that the document makes are associated with the appropriate
> > > reservations in IANA
> > registries.
> > > detailed specification of the initial contents for the registry,
> > > that allocations procedures for future registrations are defined,
> > > and a reasonable name for the new registry has been suggested (see RFC
> 5226).
> > >
> > >>> Thanks for your suggestions, will work with the authors to make
> > >>> sure this will
> > >> be addressed.
> > >>>
> > >>> To Loa,
> > >>>
> > >> publication) that there are two small warnings that the authors
> > >> have agreed to fix along with the rest of the AD comments.
> > >>
> > >>>>> substantial step is AD evaluation. I'll ask Mach to make sure
> > >>>>> this is addressed as part of the AD evaluation.
> > >>>>>> W: f(MPLS-TP-OAM-MIB.my), (883,22) MIN-ACCESS value identical
> > >>>>>> to access specified for "mplsOamIdMegOperStatus"
> > >>>>>>
> > >>>>>> W: f(MPLS-TP-OAM-MIB.my), (888,22) MIN-ACCESS value identical
> > >>>>>> to access specified for "mplsOamIdMegSubOperStatus"
> > >>>>>>
> > >>>>>> *Cc:* Sam Aldrin; Joan Cucchiara; [email-masked];
> > >>>>>> MIB Doctors (E-mail)
> > >>>>>> The version-08 is available, could you please take a look at
> > >>>>>> this version to see whether you are OK with it?
> > >>>>>>
> > >>>>>> Many thanks,
> > >>>>>>
> > >>>>>> Mach
> > >>>>>>
> > >>>>>> <[email-masked]
> <mailto:[email-masked]>>
> > >> wrote:
> > >>>>>>
> > >>>>>> Sam and authors,
> > >>>>>>
> > >>>>>> If Readonly compliance is all that is remaining, then we will
> > >>>>>> go ahead and work to get a new rev published.
> > >>>>>>
> > >>>>>>       OK, I m glad to hear that you are still working on the draft.
> > Both
> > >>>>>>       Joan and I asked your plan three weeks ago, but no
> > >>>>>> response
> > >> received
> > >>>>>>       except the  Read-only  compliance one, almost all
> > >>>>>> comments
> > are
> > >>>>>>       addressed.
> > >>>>>>
> > >>>>>>       Best regards,
> > >>>>>>
> > >>>>>>       Mach
> > >>>>>>
> > >>>>>>       MIB s do take time for the well known reasons. Check the
> > >>>>>> ID s in
> > >> the
> > >>>>>>       WG history.
> > >>>>>>
> > >>>>>>       We have indicated 3 weeks ago that  Read only  compliance, as
> > >>>>>>       Once we receive review comments, which we are waiting,
> > >>>>>> will revise
> > >> a
> > >>>>>>           have interest and energy to keep progressing it
> > >>>>>> further? If
> > so,
> > >>>>>>           Could you let me know your plan also?   I am cc ing the
> > MIB
> > >>>>>>           Dr. s  too.   SNMP sets come up over and over again and
> > >> better
> > >>>>>>           to understand what the authors decide sooner rather
> > >>>>>> than
> > later,
> > >>>>>>           IMHO.
> > >>>>>>
> > >>>>>>           think the addition  of a read-only compliance would
> > >>>>>> be preferable.
> > >>>>>>
> > >>>>>>           Thanks,
> > >>>>>>
> > >>>>>>           -Joan
> > >>>>>>
> > >>>>>>           For the left comment listed below, what s your plan
> > >>>>>> about
> > it?
> > >>>>>>
> > >>>>>>           Thanks,
> > >>>>>>
> > >>>>>>           Mach
> > >>>>>>
> > >>>>>>           > > There is no read-only compliance. Has it been
> > >>>>>> made clear to the WGs
> > >>>>>>           > > (MPLS and
> > >>>>>>           > > PWE3) that SNMP sets  will need to be supported
> > >>>>>> in order to be
> > >>>>>>           > > compliant with the MIB?
> > >>>>>>
> > >>>>>>           -Venkat.
> > >>>>>>
> > >>>>>>           <[email-masked]
> > >>>>>> <mailto:[email-masked]>>,
> > >> "Thomas
> > >>>>>>               In particular, it describes Operations,
> > >>>>>> Administration,
> > and
> > >>>>>>           Please note that it may take a couple of minutes from
> > >>>>>> the
> > time
> > >>>>>>           of submission
> > >>>>>>           Version: 2014.0.4800 / Virus Database: 4257/9047 -
> > >>>>>> Release
> > Date:
> > >>>>>>           02/02/15
> > >>>>>>
> -----
> Checked by AVG - www.avg.com
> Version: 2014.0.4800 / Virus Database: 4257/9215 - Release Date: 03/02/15

---

From: Mach Chen <[email-masked]>
Date: Wed, 4 Mar 2015 03:09:10 +0000

Hi Joan

Indeed, thanks for pointing this out, updated!

Best regards,
Mach

> From: Joan Cucchiara [mailto:[email-masked]]
> Sent: Tuesday, March 03, 2015 7:35 PM
> To: Mach Chen; 'Loa Andersson'; 'Benoit Claise'; 'Venkatesan Mahalingam'
> Subject: RE: [MIB-DOCTORS] New Version Notification for
> > Subject: RE: [MIB-DOCTORS] New Version Notification for
> > draft-ietf-mpls-tp- oam-id-mib-07.txt
> >
> > Loa,
> >
> > > Aldrin'; 'Joan Cucchiara'; [email-masked]
> > > >    discussion in the WG, it passed the MIB Doctor and experts
> > > > review,
> > many
> > > > (3) Briefly describe the review of this document that was
> > > > performed by the Document Shepherd.  If this version of the
> > > > document is not ready for publication, please explain why the
> > > > document is being forwarded to the IESG.
> > > >
> > > >    the Document Shepherd thinks that there is no outstanding issue
> > > > with
> > the
> > > > (4) Does the document Shepherd have any concerns about the depth
> > > > or breadth of the reviews that have been performed?
> > > >
> > > >    No.
> > > >
> > > > is uncomfortable with certain parts of the document, or has
> > > > concerns whether there really is a need for it. In any event, if
> > > > the WG has discussed those issues and has indicated that it still
> > > > wishes to advance the document, detail those concerns here.
> > > >
> > > >    None.
> > > >
> > > > If so, summarize any WG discussion and conclusion regarding the
> > > > IPR disclosures.
> > > >
> > > >    None.
> > > >
> > > > (10) Has anyone threatened an appeal or otherwise indicated
> > > > extreme discontent? If so, please summarise the areas of conflict
> > > > in separate email messages to the Responsible Area Director. (It
> > > > should be in a separate email because this questionnaire is
> > > > publicly
> > > > available.)
> > > >
> > > >    No.
> > > >
> > > > Internet-Drafts Checklist). Boilerplate checks are not enough;
> > > > this check needs to be thorough.
> > > >
> > > >    None.
> > > >
> > > > (14) Are there normative references to documents that are not
> > > > ready for advancement or are otherwise in an unclear state? If
> > > > such normative references exist, what is the plan for their completion?
> > > >
> > > >   No.
> > > >
> > > > and point to the part of the document where the relationship of
> > > > this document to the other RFCs is discussed. If this information
> > > > is not in the document, explain why the WG considers it unnecessary.
> > > >
> > > >    No.
> > > >
> > > > with the body of the document. Confirm that all protocol
> > > > extensions that the document makes are associated with the
> > > > appropriate reservations in IANA
> > > registries.
> > > > future allocations. Provide any public guidance that the IESG
> > > > would find useful in selecting the IANA Experts for these new registries.
> > > >
> > > >> I think we can complete the Shepherds Write-up, ask for author
> > > >> and chair feedback on the write-up, and send the publication request.
> > > >>>>>>       [email-masked] <mailto:[email-masked]>;
> > > >>>>>> Joan
> > > Cucchiara
> > > >>>>>>       MIB s do take time for the well known reasons. Check
> > > >>>>>> the ID s in
> > > >> the
> > > >>>>>>       WG history.
> > > >>>>>>
> > > >>>>>>       Are you asking to publish a new version first and one
> > > >>>>>> more
> > after?
> > > >>>>>>
> > > >>>>>>       -sam
> > > >>>>>>
> > > http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-oam-id-mib-07
> > > .t
> > > xt
> > > >>>>>>           Status:
> > > >>>>>> http://www.ietf.org/rfcdiff?url2=draft-ietf-mpls-tp-oam-id-mi
> > > >>>>>> b-
> > > >>>>>> 07
> > > >>>>>>
> > > >>>>>>           Abstract:
> > > >>>>>>               for use with network management protocols in
> > > >>>>>> the
> > > Internet
> > > >>>>>>           community.
> > > >>>>>>           Please note that it may take a couple of minutes
> > > >>>>>> from the
> > > time
> > > >>>>>>           of submission
> <http://www.avg.com/>