Re: [mpls] Shepherd Writeup update for draft-ietf-mpls-tp-temporal-hitless-psm-12

[Loa Andersson <[e-mail]>]

David,

I'm mostly a OK with this update to the Shwphwrérs Write-Up. A few very
small nits inline.

On 2017-03-01 04:15, David Sinicrope wrote:
> The last Shepherd writeup of this draft was from Dec 2015 (v8 and v9 of
> the document).
>
> The text below is intended to update that writeup based on v12 of the
> document.
>
>
>
> Let me know if you have any questions.
>
> Thanks,
>
> Dave
>
>
>
> (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?
>
>
>
>   Informational. This is indicated on the title page header, and is
>
>    appropriate since this document specifies requirements for future work.
>
>
>
> (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
>
>
>
>    The MPLS transport profile (MPLS-TP) includes OAM functions which enable
>
>    maintenance tools that may be used by network operators and service
> providers
>
>    for fault location, survivability, performance monitoring, in-service
> and out-
>
>    of-service measurements.  Based on identified problems, this document
> provides
>
>    considerations for the specification of new requirements to consider
> a new
>
>    improved mechanism for hitless transport path segment monitoring to
> be named
>
>    Enhanced Path Segment Monitoring (EPSM).
>
>
>
> Working Group Summary
>
>
>
>    WG progress was relatively smooth with no controversy.
>
>
>
> Document Quality
>
>
>
>    The document has been well reviewed by the WG and also as mentioned
> below,
>
>    and updated accordingly.

This sentence does not read well. Did you intend to mention that it has
been reviewed by SG15?

As a requirements document it does not
> specify any
>
>    protocol to be implemented, but rather specifies requirements which
> will be used
>
>    to guide future work.
>
>
>
> Personnel
>
>
>
> David Sinicrope is the current Document Shepherd, taking over from Ross
> Callon. Deborah Brungard is the Responsible Area
>
>    Director.
>
>
I think there is a script extending Shepherd and AD (but I might be
wrong), but I use the format:

    David Sinicrope is the current Document Shepherd.
    Deborah Brungard is the Responsible Area Director.

You might add an extra sentence mentioning that you taken over from
Ross.

>
> (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 document, and the document
>
>    has been updated in response to his comments.  At WG chair request Huub

hmmm - sent the request to Huub, but I think I did it as a co-author.
>
>    van Helvoort has also done a grammatical review of the document. In
> addition Rtg Dir Review was performed and liaisons to ITU-T SG15
> generated to inform them of the draft and its intent to describe
> different MPLS-TP OAM requirements those communicated from ITU-T previously.
>
>
>
> (4) Does the document Shepherd have any concerns about the depth or
>
> breadth of the reviews that have been performed?
>
>
>
>    no concerns.
>
>
>
> (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.
>
>
>
>    no additional review needed.
>
>
>
> (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.
>
>
>
>    While no explicit concerns, it should be noted that the document
> entertains “analysis of existing MPLS-TP OAM mechanisms” and “provides
> requirements to guide development of new OAM tools” on a topic where
> requirements were established, led and communicated from ITU-T SG15.
>   There has been liaison activity related to this topic and I-D dating
> back to 2010 with https://datatracker.ietf.org/liaison/917/.   Continued
> open communication with ITU-T SG15 should be maintained to ensure
> continuity and migration from existing requirements and solutions.
>
>
>
> (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. (this is being reconfirmed for the latest revision)
>
>
>
> (8) Has an IPR disclosure been filed that references this document?
>
> If so, summarize any WG discussion and conclusion regarding the IPR
>
> disclosures.
>
>
>
>    No IPR disclosures have been filed that reference this document.
>
>
>
> (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?
>
>
>
> Rough consensus. The document has been progressing slowly for quite a
> while and there was positive response to the WGLC with no objections
> albeit from a small handful of people, mostly from the author’s
> affiliations.
>
>
>
> (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 discontent or objection, just caution as noted by the comments
> regarding ITU-T above.
>
>
>
> (11) Identify any ID nits the Document Shepherd has found in this
>
> document. (See https://www.ietf.org/tools/idnits/ and the Internet-Drafts
>
> Checklist). Boilerplate checks are not enough; this check needs to be
>
> thorough.
>
>
>
>    IDnits pointed to a few minor issues which should be corrected in v12.

There is actually one error in version -12, there is a reference in the
abstract, [6371] should be removed, so that we mention RFC 6371 only. I
think it would be possible to do this at the next round of feedback.
>
>
>
> (12) Describe how the document meets any required formal review
>
> criteria, such as the MIB Doctor, media type, and URI type reviews.
>
>
>
>    Not applicable.
>
>
>
> (13) Have all references within this document been identified as
>
> either normative or informative?
>
>
>
>    Yes. It should be noted that there are M#/Mandatory requirements made
> to informative references.

I don't quite get this, did you intend to say that references to 
Informational RFCs in earlier versions has no been moved ti Informative?

/Loa
>
>
>
> (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?
>
>
>
>    All references are to published RFCs.
>
>
>
> (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 downrefs. Earlier versions of the document did have downrefs but
> it was
>
>    clear that these should have been informative references, and the
> document
>
>    was updated accordingly.
>
>
>
> (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.
>
>
>
>    not applicable.
>
>
>
> (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).
>
>
>
>    There are no requests for IANA actions in this document. This is
> appropriate.
>
>
>
> (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.
>
>
>
>    There are no requests for IANA actions in this document.
>
>
>
> (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.
>
>
>
>    not applicable.
>
>
>
>
>
> _______________________________________________
> mpls mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mpls
>

-- 


Loa Andersson                        email: [e-mail]
Senior MPLS Expert                          [e-mail]
Huawei Technologies (consultant)     phone: [phone]