Peer-to-Peer (P2P) Overlay Diagnostics
draft-ietf-p2psip-diagnostics-22

[Ballot comment]
Thanks for improving the IANA considerations section! However, Section 9.1 still has a bug that IMHO needs to be corrected. The reserved values need to be shifted in value by one, because now you have two with the value 1.

As Alexey said: "The draft has improved, however Section 9.1 still seems incorrect: if the first bit is reserved, then the first allocated value must be 2, so all other allocated values should be shifted by 1 bit."

However, I have cleared so that the shepherding AD and the WG can take care of this. Please make sure you fix this though, as my understanding is that if you didn't make the change, the protocol would not work as you intended it to work.

[Ballot comment]
For Sections 9.1 and 9.2, I wish there had been some working group discussion that resulted in the decision to make the registry policies Standards Action.  It seems that some softer policy, such as "IETF Review" (which might allow for registrations from Experimental documents) or Specification Required (which would allow review by a designated expert of a non-RFC specification) would work OK for this registry, and I would have liked the working group to have actively considered that.  But that ship has sailed for this document and this working group, and it's not likely to box us in for this case, so this is now a non-blocking comment.  Thanks for the discussion we've had on this point.

In addition to what Ben has already said...

One of the things that idnits calls out is this:
  -- The draft header indicates that this document updates RFC6940, but the
    abstract doesn't seem to mention this, which it should.

I believe it's not a problem that the abstract doesn't mention it, but one *reason* the abstract doesn't mention it is that the rest of the document doesn't mention it either.  It's not at all clear WHY this document updates 6940.  Why?  (This is in support of Ben's comment, as well as being a question to the shepherd.)

The idnits tool also mentions the pre-5378 disclaimer, and this has been resolved, so the disclaimer should be removed when the draft is updated.

I strongly agree with Ben's comment about needing explanations for a number of SHOULDs (and SHOULD NOTs) in the document.  RFC 2119 says that for SHOULD, "the full implications must be understood and carefully weighed before choosing a different course."  Without any explanation, there's no way for implementors to understand the implications and to weigh anything, and I tripped over that quite a number of times during my review.

I agree with Spencer's comment that we don't usually strong-arm IANA with 2119 key words.  It's a small point, and I don't think IANA are easily offended [ :-) ], but "IANA is asked to create" is a better approach than "IANA SHALL create", and so on.

[Ballot comment]

- section 3a.: what kind of crypto processing overhead would
make a node unresponsive? Seems a bit odd to me.

- 4.1: the para that starts with "The diagnostic information can
only be provided to authorized nodes." seems pointless to me and
could be deleted.

- 5.3: STATUS_INFO - I don't get the benefit of half-specifying
a thing like this; PROCESS_POWER is also under specified.

- 5.3, SOFTWARE_VERSION etc: providing this information ought not
be on by default - even if the overlay config calls for it to be
available to node X each node can and should decide itself
whether or not to send. While you do say (in 6.3 and 7 and 8)
that nodes need to check that the requestor is authorized to get
this information, I think you ought also say that the default is
to not send. (This is not a discuss because I think you have
enough of those;-)

[Ballot discuss]
Per Alexey's Gen-ART review and my own read, Section 9.1 is inconsistent with Section 5.3. The document says earlier that first and last bits are reserved. This is not shown in the table at all. What's perhaps causing the confusion is that there are special values (all 0s and all 1s) that convey nothing is requested and that everything is requested. This does not appear to be the same as having two reserved bits. You may want one or the other or both, but as it stands 9.1 or 5.3 do not seem to be saying the same thing.

Also, Section 5.3 uses "delimited" when it probably should have said "terminated", unless there's more substructure in the SOFTWARE_VERSION string than is identified by the text.

[Ballot discuss]
I am balloting a DISCUSS because I am concerned that this document doesn't actually do what it set out to achieve.  I would love it if during the discussion I was pointed to the places where RELOAD already solves the issues, but for now I wasn't able to find them.

According to the text, both extensions are intended to collect information "along the path", and the Figures clearly depict what is intended to happen.  However, I don't think that as specified (or at least as explained) the behavior is guaranteed.  Specific points:

1. RFC6940 says (in Section 6.2. (Symmetric Recursive Routing)) that an "overlay MAY be configured to use alternative routing algorithms…[or]…MAY be selected on a per-message basis". How is the symmetry enforced if other routing algorithms are used?  Enforcing that the ping/trace messages use symmetric routing when other algorithms are in use won't necessarily help because the paths may be different.

2. RFC6940 also (in 6.2.2. (Response Origination)) reads: "the response traverses the same peers as the request traversed, except in reverse order (symmetric routing) and possibly with extra nodes (loose routing)." In other words, even if symmetric routing is used, there is no guarantee that the same path will be followed by the response, unless the originator builds the Via List with strict details of all the nodes in the path -- maybe this is what is intended, but no explicit mention occurs in the document.

3. In 4.3, what does "directly or via symmetric routing" mean? Is it directly connected? If so, then (for the text in 4.3) that would mean that C is adjacent to A, and even though it is the next hop after B, the path taken to reach C with the PathTrack request doesn't include B — the result is that the diagnostic information received from C may not be relevant relative to destination D.


Are there implementations available?  What has been the experience? The Shepherd's write-up didn't mention any, and the TBD codes make me think that maybe Experimental might be a better status for this document.

[Ballot comment]
In general, as others have mentioned, I think the text could be a lot clearer and not leave some concepts to interpretation.

1. In 4.2.1, the MessageExtension is defined with a Boolean of "critical", but the text (a paragraph later) says that this "extension is not critical". I may be missing some of the semantics, or there's an error somewhere.

2. In 4.3..the last paragraph reads: if "...succesive calls to PathTrack return different paths, the results should be discarded and the request resent, ensuring that the second request traverses the appropriate path". Path changes are a fact of life — the second request may just be reflecting the new path, so resending it in an attempt to find the "appropriate path" may be futile.

3. What is a "routing mode"?  Section 4.3.1. (New RELOAD Request: PathTrack) talks about it when saying that the "PathTrack request can be routed directly or through the overlay based on the routing mode".  Later Section 6.2. (Message Processing: Intermediate Peers) says that "processing this request according to the overlay specified routing mode from RELOAD protocol" -- I looked in RFC6940 for "routing mode", but didn't find anything.  Note that it also looks to me like there's no place in the DiagnosticsRequest to indicate a mode..

4. Section 5.3. (dMFlags and Diagnostic Kind ID Types) defines an "UNDERLAY_HOP (8 bits): Indicates the IP layer hops from the intermediate peer which receives the diagnostics message to the next hop peer for this message."  How is that information derived?

5. I think that the Reference to RFC5226 should be Normative.


I also agree with others that the title should probably be something around RELOAD Diagnostics, and that this work doesn't really update RFC6940, it extends it in independent ways.

[Ballot comment]
I agree with Ben, Joel & Mehmet (OPS DIR), and Barry.

On top of that,
- This document looks to me as a specific implementation, written in a draft format.
- While reading the document, I was wondering: Is this P2P specific or P2PSIP specific?
Maybe a missed opportunity to have generic OAM principles for P2P, with RELOAD extension.
- Finally, any connection with LIME, at least on the presentation aspects.

[Ballot comment]
I agree with Ben and Barry that the "Updates RFC 6940" is not well-justified.  I also agree with Joel that the readability makes it hard to completely understand what is being proposed.

[Ballot comment]
Mhement Ersue did the opsdir review,

While I would not prevent this document on a technical basis I would hope very strongly that in addressing the discusses that further refinement can improve the proposed standard... where that done I'd be happy to ballot no objection.

-----------

reviewed the document "P2P Overlay Diagnostics" (draft-ietf-p2psip-diagnostics-19.txt) as part of the Operational directorate's ongoing effort to review all IETF documents being processed by the IESG.  These comments were written primarily for the benefit of the operational area directors.  Document editors and WG chairs should treat these comments just like any other last call comments.

Intended status: Standards Track
Updates: 6940 (if approved)
Current IESG state: In Last Call (ends 2015-12-14)
IANA Review State: IANA - Not OK (see for IANA comments at: https://datatracker.ietf.org/doc/draft-ietf-p2psip-diagnostics/history/)

Summary: The document describes mechanisms for P2P overlay diagnostics.  It defines extensions to the RELOAD P2PSIP base protocol to collect diagnostic information, and details the protocol specifications for these extensions. 

Comments:
- The document is not easy to read and the clarity could be improved.
- It is common practice and rule to mention in the document abstract the RFC which is going to be updated.
- There are many occurrences of the word “should”. Are these meant to be normative language and “SHOULD”?

- There are different terms used in the first few sections, which are not introduced properly. One substantial term the reader is surprised with is "diagnostic kind type".
- I believe the basic terms used in the document should be defined in a Terminology section if not defined in RFC 6940. The Terminology section should mention that the terminology from RFC 6940 is used.
- The term "Kind" has been defined in RFC 6940. If the term "kind" is to be used as defined in RFC 6940 it should be used with a capital "K".
- There are different very long sentences and a few 5-to-6-part-substantives which don't contribute to readability (e.g.: “single, general P2PSIP overlay diagnostic framework”).
- Concerning: "The second is a new method and response, PathTrack,"
I would like to suggest to delete "and response" or call it "a new request/response method".

The idnits tool returns one error and numerous warnings which need to be fixed (13 warnings, 2 comment and 1 error).
See http://tools.ietf.org/idnits?url=https://tools.ietf.org/id/draft-ietf-p2psip-diagnostics-19.txt

[Ballot discuss]
For Sections 9.1 and 9.2, I would like to see some evidence of discussion that resulted in the decision to make the registry policies Standards Action.  Did the working group actually discuss this and make a decision that Standards Action is right?  What's the reasoning for not using some softer policy, such as "IETF Review" (which might allow for registrations from Experimental documents) or Specification Required (which would allow review by a designated expert of a non-RFC specification)?  Why is Standards Action the right thing?

Important note on the previous comment: Please don't just change this: talk with me.  I'm actually asking a question, and it might well be that Standards Action is right.  I want to hear the answer and have a discussion about it.

[Ballot comment]
In addition to what Ben has already said...

From the shepherd writeup:

"The normal WG process was followed and the document has been discussed for
several years. The document as it is now, reflects WG consensus, with nothing
special worth noting."

Is it really the case that with *several years* of discussion there's *nothing* worth pointing out as something that generated discussion?  What were those several years spent on?

"A review of Section 9.6 was requested to the APPS area and the authors considered the received feedback."

Similarly: was there nothing about the feedback that was worth mentioning?  I'm glad the authors considered it... it would have been good to say "the feedback was only on minor points," or to say what review brought up.

"The idnits tool returns 5 warnings and 1 comment. They do not seem to be a
problem."

Well, one of the things that idnits calls out is this:
  -- The draft header indicates that this document updates RFC6940, but the
    abstract doesn't seem to mention this, which it should.

I believe it's not a problem that the abstract doesn't mention it, but one *reason* the abstract doesn't mention it is that the rest of the document doesn't mention it either.  It's not at all clear WHY this document updates 6940, and that *is* a problem.  Why?  (This is in support of Ben's comment, as well as being a question to the shepherd.)

The idnits tool also mentions the pre-5378 disclaimer, and the shepherd writeup has no information about why the disclaimer is needed.  What text is in this document that is not subject to the IETF Trust terms from BCP 78, and why is it not?  I think this needs an explanation.

I strongly agree with Ben's comment about needing explanations for a number of SHOULDs (and SHOULD NOTs) in the document.  RFC 2119 says that for SHOULD, "the full implications must be understood and carefully weighed before choosing a different course."  Without any explanation, there's no way for implementors to understand the implications and to weigh anything, and I tripped over that quite a number of times during my review.

I agree with Spencer's comment that we don't usually strong-arm IANA with 2119 key words.  It's a small point, and I don't think IANA are easily offended [ :-) ], but "IANA is asked to create" is a better approach than "IANA SHALL create", and so on.

[Ballot comment]
General comments:

The draft styles itself as P2PSIP diagnostics. But P2PSIP is a usage of RELOAD, and the draft mentions it is generally applicable to RELOAD. This is misleading, and might artificially limit it's applicability.  Perhaps this should be called RELOAD diagnostics? Or if it is really specific to P2PSIP, that should be clarified.

The headers show that this draft updates RFC 6940. As far as I can tell, it extends 6940 along defined extension points. If so, that's not really an update. (Also, the shepherd write up says it does not update anything.)

Specific comments:

- 4.1, 2nd to last paragraph: "The default policy or access rule for a type of diagnostic information is "permit" unless specified in the diagnostics extension document."

Can you elaborate on this? I assume "diagnostic extension document" refers to a spec that registers something in one of the new registries defined herein?  How does a policy of "permit" interact with the authorization requirements and security considerations elsewhere in the draft?

-6.2:
The section has lots of SHOULDs, where the reasons they are not MUSTs are not obvious. Please offer reasons why an implementation might choose not to follow the SHOULD.

- 6.4, first and last paragraphs:
The MAYs seems like a statements of fact rather than normative requirements.

-6.4, 2nd paragraph:
Does this document have requirements for clock resolution or skew? (It seems odd to mention the NTP capabilities unless they matter.)

9.1 (and others in the IANA section)

Where should these new registries be created? (I imagine IANA can figure it out, but it's best to be explicit.)

Editorial:

- 4.1, 2nd paragraph:
OLD:
Essentially, this document reuses RELOAD [RFC6940] specification and extends them to introduce the new diagnostics methods.
NEW:
Essentially, this document reuses the RELOAD [RFC6940] specification and extends it to introduce the new diagnostics methods.
END.

[Ballot comment]
In Section 5.3, the authors are working on text to clarify the formulas for EWMA_BYTES_SENT and EWMA_BYTES_RCVD to distinguish what is being calculated for this time period versus what was calculated for the previous one, and to explain how the value is calculated the first time.

(Via drafts-lastcall-comment@iana.org): IESG/Authors/WG Chairs:

IANA has completed its review of draft-ietf-p2psip-diagnostics-19.txt. If any part of this review is inaccurate, please let us know.

IANA has a question about one of the actions requested in the IANA Considerations section of this document.

IANA understands that, upon approval of this document, there are six actions which it must complete.

First, IANA is to create a new registry called the RELOAD Diagnostics Flag registry.

IANA QUESTION -> Where should this new registry be located? Is it a néw registry on the IANA Matrix or is it a subregistry of an existing registry? If it is a subregistry of an existing registry, in which registry will it be contained? Should it be grouped with the other RELOAD subregistires?

The new registry is to be maintained via Standards Action as defined in RFC 5226.

There are initial registrations in the new registry as follows:

+-------------------------+------------------------------+-------------+
| diagnostic information |diagnostic flag in dMFlags | Reference |
|-------------------------+------------------------------+-------------|
|Reserved | 0x 0000 0000 0000 0000 |[ RFC-to-be ]|
|STATUS_INFO | 0x 0000 0000 0000 0001 |[ RFC-to-be ]|
|ROUTING_TABLE_SIZE | 0x 0000 0000 0000 0002 |[ RFC-to-be ]|
|PROCESS_POWER | 0x 0000 0000 0000 0004 |[ RFC-to-be ]|
|UPSTREAM_BANDWIDTH | 0x 0000 0000 0000 0008 |[ RFC-to-be ]|
|DOWNSTREAM_ BANDWIDTH | 0x 0000 0000 0000 0010 |[ RFC-to-be ]|
|SOFTWARE_VERSION | 0x 0000 0000 0000 0020 |[ RFC-to-be ]|
|MACHINE_UPTIME | 0x 0000 0000 0000 0040 |[ RFC-to-be ]|
|APP_UPTIME | 0x 0000 0000 0000 0080 |[ RFC-to-be ]|
|MEMORY_FOOTPRINT | 0x 0000 0000 0000 0100 |[ RFC-to-be ]|
|DATASIZE_STORED | 0x 0000 0000 0000 0200 |[ RFC-to-be ]|
|INSTANCES_STORED | 0x 0000 0000 0000 0400 |[ RFC-to-be ]|
|MESSAGES_SENT_RCVD | 0x 0000 0000 0000 0800 |[ RFC-to-be ]|
|EWMA_BYTES_SENT | 0x 0000 0000 0000 1000 |[ RFC-to-be ]|
|EWMA_BYTES_RCVD | 0x 0000 0000 0000 2000 |[ RFC-to-be ]|
|UNDERLAY_HOP | 0x 0000 0000 0000 4000 |[ RFC-to-be ]|
|BATTERY_STATUS | 0x 0000 0000 0000 8000 |[ RFC-to-be ]|
|Reserved | 0x FFFF FFFF FFFF FFFF |[ RFC-to-be ]|
+-------------------------+------------------------------+-------------+

Second, IANA is to create a new registry called the RELOAD Diagnostic Kind ID Types registry.

IANA QUESTION -> As before, where should this new registry be located? Is it a néw registry on the IANA Matrix or is it a subregistry of an existing registry? If it is a subregistry of an existing registry, in which registry will it be contained? Should it be grouped with the other RELOAD subregistires?

IANA understands that the ID types from 0x0000 to 0x003F SHALL be assigned together with flags within "RELOAD Diagnostics Flag" registry defined above. As with the Diagnostic Flags, these ID Types would require Standards Action as defined in RFC 52267. The remaining ID Types in the range 0x0040 to 0xEFFF require Standards Action as defined in RFC 5226.

There are initial registrations in the new registry as follows:

+---------------------------+---------------+------------------+
| Diagnostic Kind Type | Code | Reference |
+---------------------------+---------------+------------------+
| reserved | 0x0000 | [ RFC-to-be ] |
| STATUS_INFO | 0x0001 | [ RFC-to-be ] |
| ROUTING_TABLE_SIZE | 0x0002 | [ RFC-to-be ] |
| PROCESS_POWER | 0x0003 | [ RFC-to-be ] |
| UPSTREAM_BANDWIDTH | 0x0004 | [ RFC-to-be ] |
| DOWNSTREAM_BANDWIDTH | 0x0005 | [ RFC-to-be ] |
| SOFTWARE_VERSION | 0x0006 | [ RFC-to-be ] |
| MACHINE_UPTIME | 0x0007 | [ RFC-to-be ] |
| APP_UPTIME | 0x0008 | [ RFC-to-be ] |
| MEMORY_FOOTPRINT | 0x0009 | [ RFC-to-be ] |
| DATASIZE_STORED | 0x000A | [ RFC-to-be ] |
| INSTANCES_STORED | 0x000B | [ RFC-to-be ] |
| MESSAGES_SENT_RCVD | 0x000C | [ RFC-to-be ] |
| EWMA_BYTES_SENT | 0x000D | [ RFC-to-be ] |
| EWMA_BYTES_RCVD | 0x000E | [ RFC-to-be ] |
| UNDERLAY_HOP | 0x000F | [ RFC-to-be ] |
| BATTERY_STATUS | 0x0010 | [ RFC-to-be ] |
| reserved for future flags | 0x0011-40 | [ RFC-to-be ] |
| local use (reserved) | 0xF000-0xFFFE | [ RFC-to-be ] |
| reserved | 0xFFFF | [ RFC-to-be ] |
+---------------------------+---------------+------------------+

Third, in the RELOAD Message Code subregistry of the REsource LOcation And Discovery (RELOAD) registry located at:

http://www.iana.org/assignments/reload/

three new message codes are to be registered as follows:

Code Value: [ TBD-at-registration ]
Message Code Name: path_track_req
Reference: [ RFC-to-be ]

Code Value: [ TBD-at-registration ]
Message Code Name: path_track_ans
Reference: [ RFC-to-be ]

Fourth, the authors request five additional items in the Message Code subregistry. It appears that the authors may have intended the new values in RELOAD Error Code subregistry, located at:

http://www.iana.org/assignments/reload/

IANA Question --> are the five, new values indicated in section 9.4 of the current draft intended to be added to the Message Code subregistry or the Error Code subregistry?

Fifth, in the RELOAD Extension Code subregistry of the REsource LOcation And Discovery (RELOAD) registry located at:

http://www.iana.org/assignments/reload/

a single new extension code is to be registered as follows:

Code Value: [ TBD-at-Registration ]
Code Name: Diagnostic_Ping
Reference: [ RFC-to-be ]

Sixth, in the name space registry of the IETF XML Registry located at:

http://www.iana.org/assignments/xml-registry/

a new namespace is to be registered as follows:

ID: p2p:config-diagnostics
URI: urn:ietf:params:xml:ns:p2p:config-diagnostics
Filename: [ TBD-at-registration ]
Reference: [ RFC-to-be ]

IANA NOTE --> As this document requests registrations in an Expert Review or Specification Required (see RFC 5226) registry, we will initiate the required Expert Review via a separate request. Expert review will need to be completed before your document can be approved for publication as an RFC.

IANA Question --> In section 9.6 the authors state that:

"And the overlay configuration file MUST contain the following xml language declaring P2PSIP diagnostics as a mandatory extension to RELOAD.

urn:ietf:params:xml:ns:p2p:config-diagnostics
"

IANA understands that this clause holds no request for IANA action and is simply guidance to future implementers.

IANA also understands that these six actions are the only ones required to be completed upon approval of this document.

IANA will not be able to complete the registry actions for this document until these issues have been resolved.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is only to confirm what actions will be performed. 

Thank you,

Sabrina Tanamal
IANA Specialist
ICANN

The following Last Call announcement was sent out:

From: The IESG
To: "IETF-Announce"
CC: draft-ietf-p2psip-diagnostics@ietf.org, alcoop@cisco.com, p2psip@ietf.org, cjbc@it.uc3m.es, p2psip-chairs@ietf.org
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (P2P Overlay Diagnostics) to Proposed Standard


The IESG has received a request from the Peer-to-Peer Session Initiation
Protocol WG (p2psip) to consider the following document:
- 'P2P Overlay Diagnostics'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2015-12-14. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  This document describes mechanisms for P2P overlay diagnostics.  It
  defines extensions to the RELOAD P2PSIP base protocol to collect
  diagnostic information, and details the protocol specifications for
  these extensions.  Useful diagnostic information for connection and
  node status monitoring is also defined.  The document also describes
  the usage scenarios and provides examples of how these methods are
  used to perform diagnostics in P2PSIP overlay networks.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-p2psip-diagnostics/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-p2psip-diagnostics/ballot/


The following IPR Declarations may be related to this I-D:

  https://datatracker.ietf.org/ipr/1427/
  https://datatracker.ietf.org/ipr/1190/

P2P Overlay Diagnostics (draft-ietf-p2psip-diagnostics-16)

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

The document has received significant community review, and appears to enjoy
enough community interest to be considered valuable. It defines extensions to
RFC6940, which also has the status of Proposed Standard.

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:

The document defines extensions to the RELOAD P2PSIP base protocol to collect
diagnostic information for connection and node status monitoring. The document
also describes the usage scenarios and provides examples of how these methods
are used to perform diagnostics in P2PSIP overlay networks.

Working Group Summary:

The normal WG process was followed and the document has been discussed for
several years. The document as it is now, reflects WG consensus, with nothing
special worth noting.

Document Quality:

The document was thoroughly reviewed by Marc Petit-Huguenin and Carlos J.
Bernardos.

Personnel:

Who is the Document Shepherd?

Carlos J. Bernardos

Who is the Responsible Area Director?

Alissa Cooper

(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 personally done a thorough review of the document.
Some changes were requested to the authors and included in the last revision of
the draft. The Document Shepherd believes the document is ready for forwarding
to IESG for publication.

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

The Document Shepherd has no concerns about the depth or breadth of these
reviews.

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

A review of Section 9.6 was requested to the APPS area and the authors considered the received feedback.

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

The Document Shepherd has no such concerns.

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

Yes. There are two. ID # 1190 and ID # 1427, both from Huawei. The IPR
disclosures took place before the WGLC was issued. No concerns during WGLC were
raised by any WG member.

(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 WG consensus behind this document.

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

The idnits tool returns 5 warnings and 1 comment. They do not seem to be a
problem.

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

The document meets the review criteria.

(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 document introduces two new types of messages (and their responses) to the
"RELOAD Message Code" Registry defined in [RFC6940]. The document
also introduces new error codes to the "RELOAD Message Code" registry defined
in [RFC6940]. The document also introduces a new RELOAD extension.

The document requests the IANA to create a "RELOAD Diagnostic Kind ID Types"
Registry and a "RELOAD Diagnostics Flag" Registry. Detailed specification of
the initial contents for these registries is provided.

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

None.

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

No formal language segments exist.

P2P Overlay Diagnostics (draft-ietf-p2psip-diagnostics-16)

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

The document has received significant community review, and appears to enjoy
enough community interest to be considered valuable. It defines extensions to
RFC6940, which also has the status of Proposed Standard.

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:

The document defines extensions to the RELOAD P2PSIP base protocol to collect
diagnostic information for connection and node status monitoring. The document
also describes the usage scenarios and provides examples of how these methods
are used to perform diagnostics in P2PSIP overlay networks.

Working Group Summary:

The normal WG process was followed and the document has been discussed for
several years. The document as it is now, reflects WG consensus, with nothing
special worth noting.

Document Quality:

The document was thoroughly reviewed by Marc Petit-Huguenin and Carlos J.
Bernardos.

Personnel:

Who is the Document Shepherd?

Carlos J. Bernardos

Who is the Responsible Area Director?

Alissa Cooper

(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 personally done a thorough review of the document.
Some changes were requested to the authors and included in the last revision of
the draft. The Document Shepherd believes the document is ready for forwarding
to IESG for publication.

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

The Document Shepherd has no concerns about the depth or breadth of these
reviews.

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

A review of Section 9.6 was requested to the APPS area.

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

The Document Shepherd has no such concerns.

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

Yes. There are two. ID # 1190 and ID # 1427, both from Huawei. The IPR
disclosures took place before the WGLC was issued. No concerns during WGLC were
raised by any WG member.

(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 WG consensus behind this document.

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

The idnits tool returns 5 warnings and 1 comment. They do not seem to be a
problem.

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

The document meets the review criteria.

(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 document introduces two new types of messages (and their responses) to the
"RELOAD Message Code" Registry defined in [RFC6940]. The document
also introduces new error codes to the "RELOAD Message Code" registry defined
in [RFC6940]. The document also introduces a new RELOAD extension.

The document requests the IANA to create a "RELOAD Diagnostic Kind ID Types"
Registry and a "RELOAD Diagnostics Flag" Registry. Detailed specification of
the initial contents for these registries is provided.

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

None.

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

No formal language segments exist.

P2P Overlay Diagnostics (draft-ietf-p2psip-diagnostics-16)

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

The document has received significant community review, and appears to enjoy
enough community interest to be considered valuable. It defines extensions to
RFC6940, which also has the status of Proposed Standard.

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:

The document defines extensions to the RELOAD P2PSIP base protocol to collect
diagnostic information for connection and node status monitoring. The document
also describes the usage scenarios and provides examples of how these methods
are used to perform diagnostics in P2PSIP overlay networks.

Working Group Summary:

The normal WG process was followed and the document has been discussed for
several years. The document as it is now, reflects WG consensus, with nothing
special worth noting.

Document Quality:

The document was thoroughly reviewed by Marc Petit-Huguenin and Carlos J.
Bernardos.

Personnel:

Who is the Document Shepherd?

Carlos J. Bernardos

Who is the Responsible Area Director?

Alissa Cooper

(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 personally done a thorough review of the document.
Some changes were requested to the authors and included in the last revision of
the draft. The Document Shepherd believes the document is ready for forwarding
to IESG for publication.

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

The Document Shepherd has no concerns about the depth or breadth of these
reviews.

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

A review of Section 8.6 has been requested to the APPS area.

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

The Document Shepherd has no such concerns.

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

Yes. There are two. ID # 1190 and ID # 1427, both from Huawei. The IPR
disclosures took place before the WGLC was issued. No concerns during WGLC were
raised by any WG member.

(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 WG consensus behind this document.

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

The idnits tool returns 11 warnings and 1 comment. Most of them seem not to be a
problem, but there are 3 items listed on the references section that are not
referenced in the document. And there are 2 outdated references.

The document seems to contain a disclaimer for pre-RFC5378 work.

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

The document meets the review criteria.

(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 document introduces two new types of messages (and their responses) to the
"RELOAD Message Code" Registry defined in [RFC6940]. The document
also introduces new error codes to the "RELOAD Message Code" registry defined
in [RFC6940]. The document also introduces a new RELOAD extension.

The document requests the IANA to create a "RELOAD Diagnostic Kind ID Types"
Registry and a "RELOAD Diagnostics Flag" Registry. Detailed specification of
the initial contents for these registries is provided.

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

None.

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

No formal language segments exist.