Shepherd writeup
rfc8545-04

>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)?  

Proposed Standard. 

>Why is this the proper type of RFC?  

It asks for the re-assignment of well-known ports for the OWAMP and TWAMP protocols. 

>Is this type of RFC indicated in the
>title page header?

Yes.    

>(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
>
>  Relevant content can frequently be found in the abstract 
>  and/or introduction of the document. If not, this may be 
>  an indication that there are deficiencies in the abstract 
>  or introduction.

It explains the motivation and describes the re-assignment of
well-known ports for the OWAMP and TWAMP protocols for control and
measurement, and clarifies the meaning and composition of these
standards track protocol names for the industry..
  
>Working Group Summary
>
>  Was there anything in WG process that is worth noting? For 
>  example, was there controversy about particular points or 
>  were there decisions where the consensus was particularly 
>  rough?

There was reasonable discussions in the mailing list based on the search of the draft title. 
A couple of people supported the adoption of this document.
There was no objection in the mailing list when the WG chair raised the LC. 

>Document Quality
>
>  Are there existing implementations of the protocol? Have a 
>  significant number of vendors indicated their plan to 
>  implement the specification? Are there any reviewers that 
>  merit special mention as having done a thorough review, 
>  e.g., one that resulted in important changes or a 
>  conclusion that the document had no substantive issues? If 
>  there was a MIB Doctor, Media Type or other expert review, 
>  what was its course (briefly)? In the case of a Media Type 
>  review, on what date was the request posted?

This is a simple idea. I did not see implementation on this. 
  
>Personnel
>
>  Who is the Document Shepherd? 

Tianran Zhou

>
>  Who is the Responsible Area
>  Director?

Mirja K├╝hlewind will normally serve as Responsible AD.

>(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.

I had some commnets on the 01 version and sent to the mailing list. They were kindly solved. 
Based on the 03 version, I think it's 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.

Nothing beyond the normal checks.

>(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.

No.  

>(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?   

Yes. There was reasonable discussions related to this draft. This idea is simple, so easy for people to get consensus. 
The process is smoth.

>(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 https://www.ietf.org/tools/idnits/ and the Internet-Drafts
>Checklist). Boilerplate checks are not enough; this check needs to be
>thorough.

There are some ID nits exist in the 03 version. 
"Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 4 comments (--)."

But some of them are not acurate  by the tool.

  -- The abstract seems to indicate that this document updates RFC5357, but
     the header doesn't have an 'Updates:' line to match this.
 no this problem.

  == Missing Reference: 'RFCXXXX' is mentioned on line 292, but not defined
no this problem.

 -- Duplicate reference: RFC5357, mentioned in 'TimDISCUSS', was also
     mentioned in 'RFC5357'.
These are different references. One is the RFC, the other is the discussion history.

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

N/A.

>(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. All normative references are 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. 

Yes, the normative reference to RFC7594 is a downref due to being informational.

>(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.

It will update RFC4656 and 5357 if approved.

>(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).

IANA request is like this:
   +------------+-------+---------+----------------------+-------------+
   | Service    | Port  | Transp. | Description          | Reference   |
   | Name       | Num.  | Protocol|                      |             |
   |            |       |         |                      |             |
   +------------+-------+---------+----------------------+-------------+
   | owamp-     | 861   | tcp     | OWAMP-Control        | [RFC4656]   |
   | control    |       |         |                      |             |
   | owamp-test | 861   | udp     | OWAMP-Test           | [RFCXXXX]   |
   |            |       |         |                      |             |
   | twamp-     | 862   | tcp     | TWAMP-Control        | [RFC5357]   |
   | control    |       |         |                      |             |
   | twamp-test | 862   | udp     | TWAMP-Test Receiver  | [RFCXXXX]   |
   |            |       |         | Port                 |             |
   +------------+-------+---------+----------------------+-------------+

>(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 new registries.

>(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.

N/A.
Back