IPv6 Performance and Diagnostic Metrics (PDM) Destination Option
draft-ietf-ippm-6man-pdm-option-13

[Ballot comment]
[ Comments below already already discussed - just keeping them here for history ]
This document defines a new IPv6 Destination Option. Adding this to a packet pushes the L4 information further out, potentially making it unavailable to the forwarding engine / ACLs. This is not just a theoretical issue - see RFC7872 for real world examples. This means that if I connect to a remote machine and enable this, I may lock myself out of the machine (return packets may not make it back to me); this should be noted (perhaps by expanding on section 1.6). In addition, enabling PDM will (almost definitely) add some processing / transmit time, and so will perturb the very thing being measured - I believe that the document should note this. Appendix C mentions overhead from larger packets, but nothing about the additional processing time.

In addition, much of the security advice feels like sops, simply to appease security people. For example, in "PDM as a Covert Channel" we find: "Having said that, an implementation SHOULD stop using PDM if it gets some number of "nonsensical" sequence numbers."  -- seeing as it would be the attacker using PDM as a convert channel, this is like saying attackers must set the evil bit on all attack traffic.

Another example is section 4.4 Timing Attacks:
"Even so, if using PDM, we introduce the concept of user "Consent to be Measured" as a pre-requisite for using PDM.  Consent is common in enterprises and with some subscription services. So, if with PDM, we recommend that the user SHOULD consent to its use." - this has nothing to do with timing attacks. In addition a concept is introduced, but not really explained - it is then claimed that this is common in enterprises (true), and that users SHOULD consent (or should have already consented) to being monitored. This feels like it was sprinkled on like security fairy dust to make security people happy, and (for me) does the opposite.


I don't understand Section 3.6 Dynamic Configuration Options.
"If implemented, each operating system MUST have a default configuration parameter, e.g. diag_header_sys_default_value=yes/no. The operating system MAY also have a dynamic configuration option to change the configuration setting as needed."
I don't understand how an implementing OS could not have a default (unless this were random). If the default were no, presumably it would *have* to have a dynamic option to change the config (or it could never be enabled).
Section 3.5.1 says: "The PDM destination options extension header MUST be explicitly  turned on by each stack on a host node by administrative action. The  default value of PDM is off.", so I'm very confused what 3.6 is trying to say...

[Ballot comment]
Agree with the many comments by the other ADs. Especially, Mirja's and Ben's comments, the document reads like a white paper vs. an IETF specification.

The "Consent to be Measured" by a user (section 4.4) seems contra to the use case described in the document (estimate QoS as experienced by an end user device). It should be the network provider who should be giving "consent to be measured" and the associated risks. Warren also noted these sentences as inappropriate. The document discusses the security aspects relative to the user but is missing discussion with respect to the network provider.

[Ballot comment]
Substantive Comments:

- 1.4, 2nd to last paragraph: Please don't make assumptions about organizational models; different organizations do it differently. Does the motivation still make sense if the organization doesn't follow this model?

- 1.5, first paragraph: "The purpose of the PDM is not to supplant all the variables present
  in all other headers but to provide data which is not available or
  very difficult to get."
How is that different than for any other extension?

3.2.1, PSNTP definition:

What are the consequences if people "spoof and insert such
  packets."?

- 3.2.2: Are there really use cases for attosecond precision?

- 4.1, last paragraph: Can you provide guidance on selecting a reasonable limit? At least a lower bound so that the limit does not negatively impact the PDM function?

-4.2:
Could PDM be used to (help) deduce the nature of the application, or possibly network topology? The last paragraph says it will be unhelpful in deducing content; I suspect otherwise. Section 4.4 talks about how it might help timing attacks against key material.

Does PDM really offer no more information to an observer than they could get by observing packet intervals of otherwise encrypted traffic? For example, it seems like one could not differentiate between wire-time and processing-time from observation alone.

-4.4, 2nd paragraph: Why does the attacker need to induce the host to turn on PDM? What about cases where the host already uses PDM?

-- last paragraph:The text recommends that a user SHOULD consent. I think you mean to say that user consent SHOULD be required. They mean very different things.

But along those lines, do you expect the average user to make informed consent decisions? At what scope should such decisions be made? Some OSs ask a user if they are willing to share diagnostic info at a global level. Does the guidance about using PDM on limited IP addresses or ports suggest consent apply at a smaller granularity?

Editorial Comments:

-General: Much of the text reads more like a white paper than an IETF standards-track RFC. This makes some sections seem like advertisements. The heavy use of "we" calls into question whether it documents the opinions of the WG, or the opinions of the authors. It also makes some sections longer than they need to be (e.g. the discussions related to time scaling factors read more like a classroom lecture than a specification.) I recognize that fixing this would require a re-write. I will leave it to the authors, chairs, and AD to decide if that is worthwhile this late in the process.

- Abstract: Last sentence is long and convoluted. Please consider breaking it up.

- 1.4, list of advantages: How is 5 different than 2?
-- 2nd paragraph after end of list: s/"to do"/"to"

- 3.2, 2nd paragraph: Please expand DTN

- 3.2, last paragraph:
The reference to Appendix A is worded in a way that suggests you have to read that section to understand how to implement time scaling factors. That led me to wonder why the appendix was not part of the body. But when I read the appendix, I realized that it really was additional explanation, and not a normative part of the process. Please consider something like the following:

OLD:
For a full description of this process...
NEW:
For additional discussion about this process...

- 3.4.1, first paragraph: The MAY seems like a statement of fact, not a normative requirement. (Same for 3.4.2)

[Ballot comment]
No objection to the publication of this document, but it's important to get Warren's COMMENT addressed:
This document defines a new IPv6 Destination Option. Adding this to a packet pushes the L4 information further out, potentially making it unavailable to the forwarding engine / ACLs. This is not just a theoretical issue - see RFC7872 for real world examples. This means that if I connect to a remote machine and enable this, I may lock myself out of the machine (return packets may not make it back to me); this should be noted (perhaps by expanding on section 1.6).

[Ballot comment]
My main concern is that part of this document read like an advertisement (e.g. "In our experience, valuable time is often lost.." whose experience? The IETF? This is an IETF RFC!). I think most of this text is not needed to understand the option and therefore should simply be removed. More concretely, I propose to remove sections 1.2, 1.3., and 1.5 as well as paragraphs 4-8 of section 1.4 (starting with "In our experience, valuable time is often lost..." to the end).

I would also recommend these two changes to shorten the RFC:
- section 3.2.3. could just be moved into the appendix.
- the diagrams from RFC4303 in sections 3.4.1. and 3.4.2 are not needed
In general I think another editing pass could help to bring the document more to the point in a couple of cases. But that's not really an issue.

Further comments:
1) This text in 3.4.2 is a bit confusing:
"As a completely new IP packet will be made, it means that PDM
  information for that packet does not contain any information from the
  inner packet, i.e. the PDM information will NOT be based on the
  transport layer (TCP, UDP, etc) ports etc in the inner header, but
  will be specific to the ESP flow.

  If PDM information for the inner packet is desired, the original host
  sending the inner packet needs to put PDM header in the tunneled
  packet, and then the PDM information will be specific for that
  stream."
I think what you want to say is something like
"A tunnel endpoint that creates a new packet may decide to use PDM independent of the use of PDM of the original packet to enable delay measurements between the two tunnel endpoints."
Correct?

2) I'm not sure this is really useful to specify normatively in an RFC as this is really implementation specific:
"The PDM destination options extension header MUST be explicitly
  turned on by each stack on a host node by administrative action. The
  default value of PDM is off."
I would recommend the following text instead (without normative language):
"An implementation should provide an interface to enable or disable the use of PDM.
This specification recommends to turn PDM off by default."

3) I don't understand section 3.6. Isn't that redundant with 3.5.1? Or what's meant by 'dynamic configuration option'? In any case, I don't think the use of normative language is appropriate here.

4) I would also like to propose new text on 3.6 5-tuple Aging (btw. 3.6. exists twice)
OLD
"3.6 5-tuple Aging

  Within the operating system, metrics must be kept on a 5-tuple basis.

  The question comes of when to stop keeping data or restarting the
  numbering for a 5-tuple.  For example, in the case of TCP, at some
  point, the connection will terminate.  Keeping data in control blocks
  forever, will have unfortunate consequences for the operating system.

  So, the recommendation is to use a known aging parameter such as Max
  Segment Lifetime (MSL) as defined in Transmission Control Protocol
  [RFC0793] to reuse or drop the control block.  The choice of aging
  parameter is left up to the implementation."
NEW
"3.6 Information Access and Storage

  Measurement information provided by PDM must be made accessible
  for higher layers or the user itself. Similar as activating the use of PDM,
the implementation may also provide an interface to indicate if received
PDM information should be stored or not. If a packet with PDM information
is received and the information should be stored, the upper layers may be
notified. Further it is recommend to define a configurable
maximum lifetime after which the information can be removed as well as a
configurable maximum amount of memory that should be allocated for PDM
information."
This text also addresses some of the "SYN flood attack" concerns as described in the
security considerations section. I would recommend to rewrite this section as
well and I would also recommend to not use the term SYN flood as that is clearly
associated with TCP only.

5) Also section 4.1 (security consideration): I don't think this sentence is true:
" For PDM, the amount of data to be kept is quite small. That is, the
  control block is quite lightweight."
Because you eventually have to hold this data per packet, so it can grow quickly.
However, this is also really an implementation question only. You could also just
store the delay calculation and not the whole control block, or even an moving
average of the delay which only needs a fixed amount of memory for a few values.
I really depends what your use case is for the information provided by PDM.

[Ballot comment]
The analysis in Sec 4.2 seems to be missing some considerations. In cases where the packet payload is encrypted and the attacker does not have access to the keys, the attacker does not in fact have access to the entire packet, in which case PDM provides more information than a packet without PDM. Also in those cases, it seems like including PDM information would generally make a packet stream more susceptible to traffic analysis insofar as the timing and sequence information may provide additional indicators about the type of application in use, not just the speed of the end host.

[Ballot comment]
I think the description of timing attacks could use a bit more work.
Specifically:

- I am assuming that you should discard rather than using as timestamp
  sources packets which fail ESP. This shouldn't be an issue for
  transport mode because you process ESP first, but in tunnel mode
  you allow either order, so it's a potential issue.

- It seems like you could use this technique for fine-grained
  timing of the cryptographic operations traffic keys as well (cf. Lucky 13),
  not just long-term keys as you say in S 4.4.

Note that both of these attacks are not ameliorated by restricting
to host and ports because one assumes that the attacker controls
the network per 3552.

[Ballot discuss]
* Section 3.2.1.
  The option length seems to be wrong here. This will make the parser parse incorrectly onto a following option or worse. I think this MUST be set to 10 instead of 16 (Or some field is missing from the description of the option)

  8-bit unsigned integer. Length of the option, in octets, excluding
  the Option Type and Option Length fields. This field MUST be set to
  16.

* Section 3.2.1.
  The option does not seem to state an alignment requirement, but I think one is required to properly align the multi-byte PSN and Delta fields. Can you please specify one.

* Section 5

The IANA considerations section needs to be more specific as you are requesting a specific type of option.

e.g. This draft requests an Destination Option Type assignment with
  the act bits set to 00 and the chg bit set to 0 from the ...

[Ballot comment]
* Section 1.6

I am not sure where this inference comes from. Can you please clarify?

It is likely that an IPv6 packet containing PDM will be dropped if using IPv6 transition technologies.

* Section 3.1

This text is not correct as the PDM option is not an implementation of the Destination options *header*.

The IPv6 Performance and Diagnostic Metrics Destination Option (PDM) is an implementation of the Destination Options Header.

Suggest rewording to

The IPv6 Performance and Diagnostic Metrics Destination Option (PDM) is implemented as an IPv6 Option carried in the Destination Options Header.

[Ballot comment]
I support Warren's discuss and comments and have a few additional comments to add.

Kind of related to Warren's discuss, I kept looking for a limitation to the scope for this work in the draft and didn't get to one until the end of the security considerations section.  The text there wasn't quite clear enough for me.  It seems that this might only be used for small periods of time while troubleshooting, is that correct?  It also seems like this has to be end-to-end, is that right?  And if it does need to be end-to-end, is the user aware of this troubleshooting so that they are not sending traffic that contains sensitive data that should remain confidential (security or privacy implications may also exist if this is not the case).

If the scope were limited, I would not have as many security concerns.  Network reconnaissance may or may not be an issue.  I don't think it is, but I need to better understand the scope of use for this option.

nit:
s/IPSec/IPsec/g

Thanks for adding in Tero's suggested text from his SecDir review, his point is important to include.  Please make sure this gets into the approved version.
https://mailarchive.ietf.org/arch/msg/secdir/BAIkONwtaQvH2toiTY76Ic1cakA

[Ballot comment]
I support Warren's discuss and comments and have a few additional comments to add.

Kind of related to Warren's discuss, I kept looking for a limitation to the scope for this work in the draft and didn't get to one until the end of the security considerations section.  The text there wasn't quite clear enough for me.  It seems that this might only be used for small periods of time while troubleshooting, is that correct?  It also seems like this has to be end-to-end, is that right?  And if it does need to be end-to-end, is the user aware of this troubleshooting so that they are not sending traffic that contains sensitive data that should remain confidential (security or privacy implications may also exist if this is not the case).

If the scope were limited, I would not have as many security concerns.  Network reconnaissance may or may not be an issue.  I don't think it is, but I need to better understand the scope of use for this option.

nit:
s/IPSec/IPsec/g

[Ballot comment]
I support Warren's discuss and comments and have a few additional ones to add.

Kind of related to Warren's discuss, I kept looking for a limitation to the scope for this work in the draft and didn't get to one until the end of the security considerations section.  The text there wasn't quite clear enough for me.  It seems that this might only be used for small periods of time while troubleshooting, is that correct?  It also seems like this has to be end-to-end, is that right?  And if it does need to be end-to-end, is the user aware of this troubleshooting so that they are not sending traffic that contains sensitive data that should remain confidential (security or privacy implications may also exist if this is not the case).

If the scope were limited, I would not have as many security concerns.  Network reconnaissance may or may not be an issue.  I don't think it is, but I need to better understand the scope of use for this option.

nit:
s/IPSec/IPsec/g

[Ballot discuss]
The document says that packet sequence number are optional ("measurements based on optional sequence numbers and timing may be embedded in each packet"), but doesn't say what should be put in the PSNTP field if I'm not using them. It also doesn't say what I should put in the PSNLR field if I haven't received any PDM packets (the exmaple just has a dash). This means that I cannot create an interoperable implementation from this document alone.

[Ballot comment]
This document defines a new IPv6 Destination Option. Adding this to a packet pushes the L4 information further out, potentially making it unavailable to the forwarding engine / ACLs. This is not just a theoretical issue - see RFC7872 for real world examples. This means that if I connect to a remote machine and enable this, I may lock myself out of the machine (return packets may not make it back to me); this should be noted (perhaps by expanding on section 1.6). In addition, enabling PDM will (almost definitely) add some processing / transmit time, and so will perturb the very thing being measured - I believe that the document should note this. Appendix C mentions overhead from larger packets, but nothing about the additional processing time.

In addition, much of the security advice feels like sops, simply to appease security people. For example, in "PDM as a Covert Channel" we find: "Having said that, an implementation SHOULD stop using PDM if it gets some number of "nonsensical" sequence numbers."  -- seeing as it would be the attacker using PDM as a convert channel, this is like saying attackers must set the evil bit on all attack traffic.

Another example is section 4.4 Timing Attacks:
"Even so, if using PDM, we introduce the concept of user "Consent to be Measured" as a pre-requisite for using PDM.  Consent is common in enterprises and with some subscription services. So, if with PDM, we recommend that the user SHOULD consent to its use." - this has nothing to do with timing attacks. In addition a concept is introduced, but not really explained - it is then claimed that this is common in enterprises (true), and that users SHOULD consent (or should have already consented) to being monitored. This feels like it was sprinkled on like security fairy dust to make security people happy, and (for me) does the opposite.


I don't understand Section 3.6 Dynamic Configuration Options.
"If implemented, each operating system MUST have a default configuration parameter, e.g. diag_header_sys_default_value=yes/no. The operating system MAY also have a dynamic configuration option to change the configuration setting as needed."
I don't understand how an implementing OS could not have a default (unless this were random). If the default were no, presumably it would *have* to have a dynamic option to change the config (or it could never be enabled).
Section 3.5.1 says: "The PDM destination options extension header MUST be explicitly  turned on by each stack on a host node by administrative action. The  default value of PDM is off.", so I'm very confused what 3.6 is trying to say...

[Ballot comment]
In Sec 3.2.1, it specifies "Delta Time Last Received = (Send time packet 2 - Receive time packet 1)"
&  "Delta Time Last Sent = (Receive time packet 2 - Send time packet 1)".  I think this would be clearer
and not subject to misinterpretation if it were "n" and "n-1" - with words indicating wrapping cases.

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

IANA has completed its review of draft-ietf-ippm-6man-pdm-option-05.txt. If any part of this review is inaccurate, please let us know.

IANA understands that, upon approval of this document, there is a single action which IANA must complete.

In the Destination Options and Hop-by-Hop Options subregistry of the Internet Protocol Version 6 (IPv6) Parameters registry located at:

http://www.iana.org/assignments/ipv6-parameters/

a new option is to be registered as follows:

Hex Value: [ TBD-at-registration ]
Binary value act: [ TBD-at-registration ]
Binary value chg: [ TBD-at-registration ]
Binary value rest: [ TBD-at-registration ]
Description: Performance and Diagnostic Metrics (PDM)
Reference: [ RFC-to-be ]

IANA understands that this is the only action required to be completed upon approval of this document.

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: ippm-chairs@ietf.org, acmorton@att.com, ippm@ietf.org, draft-ietf-ippm-6man-pdm-option@ietf.org, "Al Morton" , spencerdawkins.ietf@gmail.com, "Bill Cerveny"
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (IPv6 Performance and Diagnostic Metrics (PDM) Destination Option) to Proposed Standard


The IESG has received a request from the IP Performance Metrics WG (ippm)
to consider the following document:
- 'IPv6 Performance and Diagnostic Metrics (PDM) Destination Option'
  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 2016-09-28. 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


  To assess performance problems,  measurements based on optional
  sequence numbers and timing may be embedded in each packet.  Such
  measurements may be interpreted in real-time or after the fact. An
  implementation of the existing IPv6 Destination Options extension
  header, the Performance and Diagnostic Metrics (PDM) Destination
  Options extension header as well as the field limits, calculations,
  and usage of the PDM in measurement are included in this document.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-ippm-6man-pdm-option/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-ippm-6man-pdm-option/ballot/

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

  https://datatracker.ietf.org/ipr/2815/

As required by RFC 4858, this is the Document Shepherd Write-Up
for: IPv6 Performance and Diagnostic Metrics (PDM) Destination Option
draft-ietf-ippm-6man-pdm-option-03

The version of this template 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:

To assess performance problems,  measurements based on optional
sequence numbers and timing may be enabled in packets of a
particular flow using a new Destination Options Header.  Such
measurements may be interpreted in real-time or after-the-fact.
This document gives a specification of the existing IPv6
Destination Option extension header,
called the Performance and Diagnostic Metrics (PDM) Destination
Option. The document also provides the field limits, calculations,
and usage of the PDM in measurement.

Working Group Summary:

After years of discussion, consideration, and revision, the working
group adopted the draft and then moved smoothly to consensus in
another year, aided by the implementation of the option in Free BSD.

Document Quality:

This document was reviewed at many occasions by the measurement and
IPv6 communities.

Personnel:
Who is the Document Shepherd? Who is the Responsible Area Director?

The document shepherd is Al Morton (was formerly Bill Cerveny).
Spencer Dawkins is the responsible area director.

(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.
Bill Cerveny provided an editorial review, and his comments were
addressed in version 03. Al Morton reviewed the document many times
in WG review and Last Call, and his comments have been shared with
the authors.

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

No.  There have been reviews by experts in v6ops, 6man and IPPM.

(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

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

IPR was disclosed in the form of an early filing on
draft-elkins-ippm-6man-pdm-option
https://datatracker.ietf.org/ipr/2257/
Since the provisional filing (2013) was not followed-up, the time limit has
expired and the provisional filing is no longer valid. See:
http://www.uspto.gov/patents-getting-started/patent-basics/types-patent-applications/provisional-application-patent

The current filing 
https://datatracker.ietf.org/ipr/2815/
reflects this status accurately.

There is no evidence of IPPM WG discussion of IPR revealed in list
search, and only one message on v6ops:
https://mailarchive.ietf.org/arch/msg/v6ops/x6wwSViK6Wl32-yru0csA1_2Bb8
(which indicates an issue with the licensing terms of another
draft, not PDM.)

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

Among the individuals who have reviewed and provided comments,
there now appears to be agreement with the content and concurrence
that the draft is ready.

(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 Abstract appears after the ToC, which is an odd order of front-matter.

(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

(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 was revised as a result of review with the
Document Shepherds(both past and present), and now meets these
requirements.

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

Not applicable


Shepherd's (editorial) comments (Al, on version 03)

112 ... An
113   implementation of the existing IPv6 Destination Options extension
114   header, the Performance and Diagnostic Metrics (PDM) Destination
115   Options extension header has been proposed in a companion document.
acm: It would be good to provide a reference to the
companion document here, if possible.

Also, "proposed" appears 5 times in the text,
it's more accurate to say "defined" now that this
doc has reached WG consensus (at least) and will soon
be an RFC.


1129 8 Security Considerations

1131   The PDM MUST NOT be changed dynamically via packet flow as this
1132   creates a possibility for potential security violations or DoS
1133   attacks by numerous packets turning the header on and off.
acm: does this mean
The *presence or omission of*
PDM MUST NOT be changed dynamically via packet flow as...