Tunnel Extensible Authentication Protocol (TEAP) Version 1
draft-ietf-emu-eap-tunnel-method-10

[Ballot comment]

Thanks for handling my discuss.

--- didn't check comments against -10

This was discuss point (1), not a comment:

(1) 3.4: when x.500 names or SubjectAltNames are
"exported" is it clear how those are formatted? Maybe a
pointer to where that's defined would be good in case
implementers get it wrong. You might also want to warn
here (or somewhere) about names that contain a null byte
in case that attack is used e.g. with a TLS server cert
subject name like "CN=www.paypal.com\0.badguy.com" Even
though that's really a PKI failure, not detecting it here
would be bad too.

older comments...

- 3.2: You're allowing TLS compression. Is there the
potential for something like a CRIME attack here? I guess
not, given that there's no way to programatically get a
peer or inner method server to send attacker-chosen data.
Is that correct? (Just checking.)

- 3.2.2: Since a PAC-lifetime is a wall-clock time then
it would provide a way to correlate old and new sessions
(i.e. act as a fingerprint) if its ever carried in clear.
Can that happen?

- 3.3.3, 1st para: what does "clear text" mean here? Do
you mean within the TLS tunnel or not? I hope you do mean
within the TLS tunnel, but I think you need to be
clear(er) in any case.

- 3.8: this says mutual auth "results" if the peer trusts
the server cert belongs to the server - that sounds
wrong, isn't it?

- 3.8.1: I think you need an s/MAY/MUST/ here - you say
the request "MAY be issued only ..." but I think you mean
"MUST be issued only..."

- 3.8.2: Just checking, and I may be wrong here. Say if I
establish a TLS server-auth tunnel and then renegotiate
to get TLS client-auth (with id privacy) as well, and
then the Peer wants to get a new cert.  This calls for
the tls-unique for the initial server-auth TLS session to
be used in the pkcs#10.  Am I reading it right? Is that
ok? I think it is, but just want to check since its
pretty confusing;-)

- The secdir review [1] raised a couple of questions that
I think would be good to answer. Did I miss that answer?

  [1] http://www.ietf.org/mail-archive/web/secdir/current/msg04106.html

[Ballot discuss]
update for -09: still discussing

These discuss points are more questions I'd really like
answered than blocking points (depending on the answers I
guess:-) but I expect should be easily resolved.

(1) made this a comment

(2) 5.2, at the end: this adds a dependency on the
TLS-PRF.  I don't suppose TLS1.3 will be a big enough
change for that to be a problem, but what if it was? E.g.
if someone convinced the TLS WG to use IKE instead? Do
you really need the same PRF or could you pick one for
TEAP and remove the dependency? Same question for the MAC
in 5.3.

(3) 7.3: you have a MAY for this separation but also
define what would become a cleartext password set of TLVs
on the link between the two boxes here. Could you not at
least REQUIRE protection (e.g. using radius or diameter
over TLS) of that link if the basic password method will be
used?

[Ballot comment]
This was discuss point (1), not a comment:

(1) 3.4: when x.500 names or SubjectAltNames are
"exported" is it clear how those are formatted? Maybe a
pointer to where that's defined would be good in case
implementers get it wrong. You might also want to warn
here (or somewhere) about names that contain a null byte
in case that attack is used e.g. with a TLS server cert
subject name like "CN=www.paypal.com\0.badguy.com" Even
though that's really a PKI failure, not detecting it here
would be bad too.

older comments...

- 3.2: You're allowing TLS compression. Is there the
potential for something like a CRIME attack here? I guess
not, given that there's no way to programatically get a
peer or inner method server to send attacker-chosen data.
Is that correct? (Just checking.)

- 3.2.2: Since a PAC-lifetime is a wall-clock time then
it would provide a way to correlate old and new sessions
(i.e. act as a fingerprint) if its ever carried in clear.
Can that happen?

- 3.3.3, 1st para: what does "clear text" mean here? Do
you mean within the TLS tunnel or not? I hope you do mean
within the TLS tunnel, but I think you need to be
clear(er) in any case.

- 3.8: this says mutual auth "results" if the peer trusts
the server cert belongs to the server - that sounds
wrong, isn't it?

- 3.8.1: I think you need an s/MAY/MUST/ here - you say
the request "MAY be issued only ..." but I think you mean
"MUST be issued only..."

- 3.8.2: Just checking, and I may be wrong here. Say if I
establish a TLS server-auth tunnel and then renegotiate
to get TLS client-auth (with id privacy) as well, and
then the Peer wants to get a new cert.  This calls for
the tls-unique for the initial server-auth TLS session to
be used in the pkcs#10.  Am I reading it right? Is that
ok? I think it is, but just want to check since its
pretty confusing;-)

- The secdir review [1] raised a couple of questions that
I think would be good to answer. Did I miss that answer?

  [1] http://www.ietf.org/mail-archive/web/secdir/current/msg04106.html

[Ballot comment]
Version -09 makes the negotiation process in Section 3.1 much clearer to me; thanks very much for addressing that.

I note that the shepherd writeup included key information about reviews from outside the working group.  Thanks for that; it's very useful.

[Ballot discuss]
These discuss points are more questions I'd really like
answered than blocking points (depending on the answers I
guess:-) but I expect should be easily resolved.

(1) made this a comment

(2) 5.2, at the end: this adds a dependency on the
TLS-PRF.  I don't suppose TLS1.3 will be a big enough
change for that to be a problem, but what if it was? E.g.
if someone convinced the TLS WG to use IKE instead? Do
you really need the same PRF or could you pick one for
TEAP and remove the dependency? Same question for the MAC
in 5.3.

(3) 7.3: you have a MAY for this separation but also
define what would become a cleartext password set of TLVs
on the link between the two boxes here. Could you not at
least REQUIRE protection (e.g. using radius or diameter
over TLS) of that link if the basic password method will be
used?

[Ballot comment]

This was discuss point (1), not a comment:

(1) 3.4: when x.500 names or SubjectAltNames are
"exported" is it clear how those are formatted? Maybe a
pointer to where that's defined would be good in case
implementers get it wrong. You might also want to warn
here (or somewhere) about names that contain a null byte
in case that attack is used e.g. with a TLS server cert
subject name like "CN=www.paypal.com\0.badguy.com" Even
though that's really a PKI failure, not detecting it here
would be bad too.

older comments...

- 3.2: You're allowing TLS compression. Is there the
potential for something like a CRIME attack here? I guess
not, given that there's no way to programatically get a
peer or inner method server to send attacker-chosen data.
Is that correct? (Just checking.)

- 3.2.2: Since a PAC-lifetime is a wall-clock time then
it would provide a way to correlate old and new sessions
(i.e. act as a fingerprint) if its ever carried in clear.
Can that happen?

- 3.3.3, 1st para: what does "clear text" mean here? Do
you mean within the TLS tunnel or not? I hope you do mean
within the TLS tunnel, but I think you need to be
clear(er) in any case.

- 3.8: this says mutual auth "results" if the peer trusts
the server cert belongs to the server - that sounds
wrong, isn't it?

- 3.8.1: I think you need an s/MAY/MUST/ here - you say
the request "MAY be issued only ..." but I think you mean
"MUST be issued only..."

- 3.8.2: Just checking, and I may be wrong here. Say if I
establish a TLS server-auth tunnel and then renegotiate
to get TLS client-auth (with id privacy) as well, and
then the Peer wants to get a new cert.  This calls for
the tls-unique for the initial server-auth TLS session to
be used in the pkcs#10.  Am I reading it right? Is that
ok? I think it is, but just want to check since its
pretty confusing;-)

- The secdir review [1] raised a couple of questions that
I think would be good to answer. Did I miss that answer?

  [1] http://www.ietf.org/mail-archive/web/secdir/current/msg04106.html

[Ballot comment]
I can't in good conscience make this a DISCUSS point because really, the best you're going to be able to do is hand-wave or wait on a not-yet-published document. But 4.2.15 (like a bunch of other documents) is really introducing an "...a miracle occurs..." solution. It is presuming that there is a user-input username and password in UTF-8, but no discussion of normalization or mappings. If you are OK with false negatives (i.e., in some circumstances people are going to type things that they are absolutely sure are their usernames and passwords, but they are going to fail, and they will be unable to type their "true" usernames or passwords), then you're probably OK doing nothing. If that would be a really bad outcome, to make it more resilient you could look at:

  http://datatracker.ietf.org/doc/draft-ietf-precis-saslprepbis/

(This document is not just about SASL, the filename notwithstanding.) I'd like to say that the document will be published quickly, and maybe if you all pushed on the PRECIS folks it might, but I can't make any promises. And I wouldn't suggest using RFC 4013, because it's going to be obsoleted by the above (for good reasons).

I'm glad to discuss this with the authors or the WG, but I won't force you to DISCUSS it.

[Ballot discuss]

These discuss points are more questions I'd really like
answered than blocking points (depending on the answers I
guess:-) but I expect should be easily resolved.

(1) 3.4: when x.500 names or SubjectAltNames are
"exported" is it clear how those are formatted? Maybe a
pointer to where that's defined would be good in case
implementers get it wrong. You might also want to warn
here (or somewhere) about names that contain a null byte
in case that attack is used e.g. with a TLS server cert
subject name like "CN=www.paypal.com\0.badguy.com" Even
though that's really a PKI failure, not detecting it here
would be bad too.

(2) 5.2, at the end: this adds a dependency on the
TLS-PRF.  I don't suppose TLS1.3 will be a big enough
change for that to be a problem, but what if it was? E.g.
if someone convinced the TLS WG to use IKE instead? Do
you really need the same PRF or could you pick one for
TEAP and remove the dependency? Same question for the MAC
in 5.3.

(3) 7.3: you have a MAY for this separation but also
define what would become a cleartext password set of TLVs
on the link between the two boxes here. Could you not at
least REQUIRE protection (e.g. using IPsec) of that link
if the basic password method will be used?

[Ballot comment]

- 3.2: You're allowing TLS compression. Is there the
potential for something like a CRIME attack here? I guess
not, given that there's no way to programatically get a
peer or inner method server to send attacker-chosen data.
Is that correct? (Just checking.)

- 3.2.2: Since a PAC-lifetime is a wall-clock time then
it would provide a way to correlate old and new sessions
(i.e. act as a fingerprint) if its ever carried in clear.
Can that happen?

- 3.3.3, 1st para: what does "clear text" mean here? Do
you mean within the TLS tunnel or not? I hope you do mean
within the TLS tunnel, but I think you need to be
clear(er) in any case.

- 3.8: this says mutual auth "results" if the peer trusts
the server cert belongs to the server - that sounds
wrong, isn't it?

- 3.8.1: I think you need an s/MAY/MUST/ here - you say
the request "MAY be issued only ..." but I think you mean
"MUST be issued only..."

- 3.8.2: Just checking, and I may be wrong here. Say if I
establish a TLS server-auth tunnel and then renegotiate
to get TLS client-auth (with id privacy) as well, and
then the Peer wants to get a new cert.  This calls for
the tls-unique for the initial server-auth TLS session to
be used in the pkcs#10.  Am I reading it right? Is that
ok? I think it is, but just want to check since its
pretty confusing;-)

- The secdir review [1] raised a couple of questions that
I think would be good to answer. Did I miss that answer?

  [1] http://www.ietf.org/mail-archive/web/secdir/current/msg04106.html

[Ballot discuss]
I'm going to raise Spencer's comment to a DISCUSS: I find the version negotiation in Section 3.1 to be somewhat confusingly written.  Possibly it will be implemented correctly because people generally know how to code version negotiation -- but I don't think the text here makes it clear.

First, you seem to be using "EAP peer" and "TEAP peer" interchangably.  Please make sure you're consistent in your usage, and if there really is a difference then make that clear and explain it.  You similarly say "EAP server" and "TEAP server" -- again, are they the same, or different enities?

Second, I'm confused by "server" and "peer".  Peers talk with peers; when there's a server, there's a client.  What does it mean to have a server and a peer (in the document in general, and in this negotiation in particular)?

Now, I think you're trying to say this:
1. The server gives the highest version it supports.
2. The client does one of three things:
2a. Sends a response that echos the server's version.
2b. Sends a response that offers a lower version.
2c. Sends a Nak, and we're done here (perhaps we continue with something else).
3. For 2b, the server does one of two things:
3a. Accepts the client's version and continues.
3b. [Does something else; see Spencer's comment.]

Now, I like this approach, in that both the client and server can refuse an earlier version (which perhaps has security flaws), so that's nice.  But I think the wording of the negotiation process ought to be fixed to make it clearer, and that what happens in case 3b, especially, needs to be clearer.

I also think that numbering the list(s) will help, though you don't have to use my numbering (and if you can make it clear without numbers, that's fine).

[Ballot comment]
I note that the shepherd writeup included key information about reviews from outside the working group.  Thanks for that; it's very useful.

In Section 3.3.2, it might be useful to (briefly) note *why* one SHOULD NOT use EAP-FAST-GTC.

[Ballot comment]
I considered balloting Discuss, but I'm assuming that either I'm missing something really obvious, or this will be an easy fix ...

In 3.1.  Version Negotiation

      If the TEAP server does not support the version number proposed by
      the TEAP peer, it MAY terminate the conversation with EAP-Failure
      or negotiate for another EAP type.  Otherwise the TEAP
      conversation continues.

I'm wondering if "MAY terminate the conversation" is what you mean when the TEAP peer doesn't propose a version number that the TEAP server supports.

I'm reading "otherwise the TEAP conversation continues" as saying that the two alternatives given are the only choices when the TEAP server doesn't support a proposed version number. Did I get that right?

If you're expecting the TEAP server to do one of those two things, something like "MUST terminate the conversation unless the TEAP server negotiates for a different version number" might be clearer.

If there are more than two alternatives, it would be helpful to rephrase this text so it's clear that the TEAP server isn't limited to those two alternatives.

(I should have mentioned that I agree with Martin's Discuss, but one Discuss on those topics is enough)

[Ballot comment]
I considered balloting Discuss, but I'm assuming that either I'm missing something really obvious, or this will be an easy fix ...

In 3.1.  Version Negotiation

      If the TEAP server does not support the version number proposed by
      the TEAP peer, it MAY terminate the conversation with EAP-Failure
      or negotiate for another EAP type.  Otherwise the TEAP
      conversation continues.

I'm wondering if "MAY terminate the conversation" is what you mean when the TEAP peer doesn't propose a version number that the TEAP server supports.

I'm reading "otherwise the TEAP conversation continues" as saying that the two alternatives given are the only choices when the TEAP server doesn't support a proposed version number. Did I get that right?

If you're expecting the TEAP server to do one of those two things, something like "MUST terminate the conversation unless the TEAP server negotiates for a different version number" might be clearer.

If there are more than two alternatives, it would be helpful to rephrase this text so it's clear that theTEAP server isn't limited to those two alternatives.

[Ballot discuss]
Two points about Section 3.7. "Fragmentation"
- Both ends have to wait for either each fragment or fragment ack to arrive. However, the timers on how to long to wait before giving up waiting for fragments or acks are missing.

- how does the sending TEAP entity determine what the maximum transmission unit (MTU) of the path is?

IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-emu-eap-tunnel-method-07.  Authors should review the comments and/or questions below.  Please report any inaccuracies and respond to any questions as soon as possible.

IANA's reviewer has the following comments/questions:

IANA has questions about some of the actions requested to be completed by IANA in this document.

IANA understands that, upon approval of this document, there are eleven actions that are required to be completed by IANA.

First, in the Method Types registry of the Extensible Authentication Protocol (EAP) Registry located at:

http://www.iana.org/assignments/eap-numbers/eap-numbers.xhtml

a new method type will be assigned for TEAP.

IANA Question -> What range of the Method Types registry is the TEAP Method Type to be allocated from?

Second, a new registry will be created called "TEAP TLV Types"

IANA Question -> Should all the new TEAP subregistries be grouped together in a common TEAP master registry?

Maintenance of this new registry will be done via Specification Required as defined in RFC 5226.

IANA Question -> for the TEAP TLV Types registry are the registry entries supposed to contain only the information listed in Section 6 of the current document, or is the full set of information in Section 4.2 to be used. What fields should appear in the registry?

Third, a new registry is to be created called the "TEAP Identity-Type Registry" and to be located according to the response of the authors to questions in task two above. The new registry will be maintained through Specification Required as defined in RFC 5226. There are initial registrations in the new registry as follows:

Identity-Type Meaning Reference
------------- -------------------- -----------------
1 User [ RFC-to-be ]
2 Machine [ RFC-to-be ]

Fourth, a new registry is to be created called the "TEAP Status Code Registry" and to be located according to the response of the authors to questions in task two above. The new registry will be maintained through Specification Required as defined in RFC 5226. There are initial registrations in the new registry as follows:

Status Code Meaning Reference
-------------- -------------------- ---------------
1 Success [ RFC-to-be ]
2 Failure [ RFC-to-be ]

Fifth, a new registry is to be created called the "TEAP Error-code Registry" and to be located according to the response of the authors to questions in task two above. The new registry will be maintained through Specification Required as defined in RFC 5226. There are initial registrations in the new registry as follows:

Error-code Meaning Reference
---------- --------------------------------------------------- --------------
1001 Inner_Method_Error [ RFC-to-be ]
2001 Tunnel_Compromise_Error [ RFC-to-be ]
2002 Unexpected_TLVs_Exchanged [ RFC-to-be ]
2003 Unsupported_Algorithm_In_CertificateSigning_Request [ RFC-to-be ]
2004 Unsupported_Extension_In_CertificateSigning_Request [ RFC-to-be ]
2005 Bad_Identity_In_CertificateSigning_Request [ RFC-to-be ]
2006 Bad_CertificateSigning_Request [ RFC-to-be ]
2007 Internal_CA_Error [ RFC-to-be ]
2008 General_PKI_Error [ RFC-to-be ]

Sixth, a new registry is to be created called the "TEAP Request-Action TLV Registry" and to be located according to the response of the authors to questions in task two above. The new registry will be maintained through Specification Required as defined in RFC 5226. There are initial registrations in the new registry as follows:

Request-Action Meaning Reference
--------------------- --------------------- ---------------
1 Process-TLV [ RFC-to-be ]
2 Negotiate-EAP [ RFC-to-be ]

Seventh, a new registry is to be created called the "TEAP PAC Attribute Type Code Registry" and to be located according to the response of the authors to questions in task two above. The new registry will be maintained through Specification Required as defined in RFC 5226. There are initial registrations in the new registry as follows:

Type Code Meaning Reference
---------- ------------------ --------------
1 PAC-key [ RFC-to-be ]
2 PAC-Opaque [ RFC-to-be ]
3 PAC-Lifetime [ RFC-to-be ]
4 A-ID [ RFC-to-be ]
5 I-ID [ RFC-to-be ]
6 Reserved [ RFC-to-be ]
7 A-ID-Info [ RFC-to-be ]
8 PAC-Acknowledgement [ RFC-to-be ]
9 PAC-Info [ RFC-to-be ]
10 PAC-Type [ RFC-to-be ]

Eighth, a new registry is to be created called the "TEAP PAC-type Type Code Registry" and to be located according to the response of the authors to questions in task two above. The new registry will be maintained through Specification Required as defined in RFC 5226. There are initial registrations in the new registry as follows:

Type Code Meaning Reference
----------- ------------------- ---------------
1 Tunnel PAC [ RFC-to-be ]

Ninth, a new registry is to be created called the "TEAP Trusted-Server-Root TLV Credential-Format Code Registry" and to be located according to the response of the authors to questions in task two above. The new registry will be maintained through Specification Required as defined in RFC 5226. There are initial registrations in the new registry as follows:

Credential
Format Code Meaning Reference
------------- ------------------------------ -------------------
1 PKCS#7-Server-Certificate-Root [ RFC-to-be ]

IANA Question -> The authors request that "The various values under Vendor-Specific TLV are assigned by Private Use and do not need to be assigned by IANA." What values are these and in what TEAP subregistries are there Vendor-Specific TLVs?

Tenth, in the TLS Exporter Label Registry in the Transport Layer Security (TLS) Parameters located at:

http://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#exporter-labels

a new exporter labels is to be added to the registry.

IANA understands the value to be "EXPORTER: teap session key seed" and the reference to be set to [ RFC-to-be ].

IANA Question -> What should the entry be for the DTLS-OK field for this new exporter label?

Eleventh, the in the User Specific Root Keys (USRK) Key Labels subregistry of the Extended Master Session Key (EMSK) Parameters registry located at:

http://www.iana.org/assignments/emsk-parameters/emsk-parameters.xhtml#emsk-parameters-1

a new key label is to be registered as follows:

Label: "TEAPbindkey@ietf.org"
Description: "USRK Key Labels"
Reference: [ RFC-to-be ]

IANA understands that these eleven actions are the only ones 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.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Tunnel EAP Method (TEAP) Version 1) to Proposed Standard


The IESG has received a request from the EAP Method Update WG (emu) to
consider the following document:
- 'Tunnel EAP Method (TEAP) Version 1'
  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 2013-07-30. 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 defines the Tunnel Extensible Authentication Protocol
  (TEAP) version 1.  TEAP is a tunnel based EAP method that enables
  secure communication between a peer and a server by using the
  Transport Layer Security (TLS) protocol to establish a mutually
  authenticated tunnel.  Within the tunnel, Type-Length-Value (TLV)
  objects are used to convey authentication related data between the
  EAP peer and the EAP server.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-emu-eap-tunnel-method/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-emu-eap-tunnel-method/ballot/


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

  http://datatracker.ietf.org/ipr/1902/

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

A standards track RFC is being requested. This is a standard
tunnel-based EAP method method. This is indicated in the header.


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

Technical Summary:

This document defines the Tunnel Extensible Authentication Protocol
(TEAP) version 1. TEAP is a tunnel based EAP method that enables
secure communication between a peer and a server by using the
Transport Layer Security (TLS) to establish a mutually authenticated
tunnel. Within the tunnel, Type-Length-Value (TLV) objects are used
to convey authentication related data between the EAP peer and the
EAP server.

Working Group Summary:

At the start of this work there were different proposals. Through a
long process the working group settled on the current approach and
document. There is good consensus from the working group on this document.

Document Quality:

This document has had review from different groups including EMU, ABFAB,
NEA and RADEXT.

Personnel:

THe Responsible area director is Sean Turner. The Document Shepherd is
Alan DeKok

(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 checked it against
ID-nits and believes its 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.

The document has had security and AAA review.

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

No Specific 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, The working group had discussion early when deciding on approach.
The consensus was to move forward with this approach since license terms
were agreeable.

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

The working group as a whole agrees with it.


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

It is compliant with the Internet drafts checklist. There are a few
references that need to be updated.

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

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

Not applicable

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


New registries are clearly identified along with their contents.


(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 registries require expert review

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