Certificate Profile and Certificate Management for SEcure Neighbor Discovery (SEND)
draft-ietf-csi-send-cert-10
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2012-08-22
|
10 | (System) | post-migration administrative database adjustment to the No Objection position for Sean Turner |
2012-08-22
|
10 | (System) | post-migration administrative database adjustment to the Yes position for Jari Arkko |
2012-08-22
|
10 | (System) | post-migration administrative database adjustment to the No Objection position for Tim Polk |
2012-08-22
|
10 | (System) | post-migration administrative database adjustment to the No Objection position for David Harrington |
2012-08-22
|
10 | (System) | post-migration administrative database adjustment to the No Objection position for Russ Housley |
2011-01-18
|
10 | Cindy Morgan | State changed to RFC Ed Queue from Approved-announcement sent. |
2011-01-14
|
10 | (System) | IANA Action state changed to No IC from In Progress |
2011-01-14
|
10 | (System) | IANA Action state changed to In Progress |
2011-01-14
|
10 | Cindy Morgan | IESG state changed to Approved-announcement sent |
2011-01-14
|
10 | Cindy Morgan | IESG has approved the document |
2011-01-14
|
10 | Cindy Morgan | Closed "Approve" ballot |
2011-01-14
|
10 | Cindy Morgan | Approval announcement text regenerated |
2011-01-14
|
10 | Cindy Morgan | Ballot writeup text changed |
2010-11-24
|
10 | (System) | New version available: draft-ietf-csi-send-cert-10.txt |
2010-11-24
|
09 | (System) | New version available: draft-ietf-csi-send-cert-09.txt |
2010-11-06
|
10 | Tim Polk | [Ballot Position Update] Position for Tim Polk has been changed to No Objection from Discuss by Tim Polk |
2010-10-07
|
08 | (System) | New version available: draft-ietf-csi-send-cert-08.txt |
2010-09-24
|
07 | (System) | New version available: draft-ietf-csi-send-cert-07.txt |
2010-09-02
|
10 | Russ Housley | [Ballot comment] In Section 7, there are several to-be-assigned values. They have been assigned: id-kp-sendRouter OBJECT IDENTIFIER ::= { id-kp 23 } … [Ballot comment] In Section 7, there are several to-be-assigned values. They have been assigned: id-kp-sendRouter OBJECT IDENTIFIER ::= { id-kp 23 } id-kp-sendProxy OBJECT IDENTIFIER ::= { id-kp 24 } id-kp-sendOwner OBJECT IDENTIFIER ::= { id-kp 25 } |
2010-09-02
|
10 | Russ Housley | [Ballot discuss] The Gen-ART Review by Roni Even on 2-May-2010 raises two concerns about changes from RFC 3971; if these changes are intentional … [Ballot discuss] The Gen-ART Review by Roni Even on 2-May-2010 raises two concerns about changes from RFC 3971; if these changes are intentional it would be very desirable to add a section on changes from RFC 3971. 1. In Section 4, second paragraph, this document says, "SEND certificates MUST include the IP Resources extension for IPv6 Address." And, Section 6.3.1 of RFC 3971 says, "Router Authorization Certificates are X.509v3 certificates, as defined in RFC 3280, and SHOULD contain at least one instance of the X.509 extension for IP addresses, as defined in RFC 3779." Is the transition from "SHOULD" to "MUST" intended? 2. In Section 4, second paragraph, this document says, "Certified IPv6 address space SHOULD be expressed using either addressPrefix or addressesOrRange elements." And, Section 6.3.1 in RFC 3971 says, "The X.509 IP address extension MUST contain at least one addressesOrRanges element" as well as "The X.509 IP address extension MAY contain additional IPv6 subnet prefixes, expressed as either an addressPrefix or an addressRange." I suspect these should be the same. |
2010-09-02
|
10 | Russ Housley | [Ballot Position Update] Position for Russ Housley has been changed to No Objection from Discuss by Russ Housley |
2010-08-29
|
06 | (System) | New version available: draft-ietf-csi-send-cert-06.txt |
2010-06-29
|
05 | (System) | New version available: draft-ietf-csi-send-cert-05.txt |
2010-06-08
|
10 | Alexey Melnikov | [Ballot Position Update] Position for Alexey Melnikov has been changed to No Objection from Discuss by Alexey Melnikov |
2010-06-08
|
10 | Alexey Melnikov | [Ballot comment] It looks like the document needs an Informative reference to RFC 5781 (due to use of rsync URIs in the example). |
2010-06-08
|
10 | Alexey Melnikov | [Ballot discuss] |
2010-06-05
|
10 | Jari Arkko | [Ballot Position Update] Position for Jari Arkko has been changed to Yes from Discuss by Jari Arkko |
2010-06-03
|
10 | Sean Turner | [Ballot comment] I cleared my DISCUSS positions. Because this profile relies on the res-cert profile we should make them address the two additional security considerations. … [Ballot comment] I cleared my DISCUSS positions. Because this profile relies on the res-cert profile we should make them address the two additional security considerations. Also, Suresh has already asked for an OID from PKIX - so I'll trust him to put it in during AUTH48. |
2010-06-03
|
10 | Sean Turner | [Ballot discuss] [Revised - I removed the DISCUSS positions addressed in -04. Added some more information in #2 and #4] #2) You also need to … [Ballot discuss] [Revised - I removed the DISCUSS positions addressed in -04. Added some more information in #2 and #4] #2) You also need to register the OID for the ASN.1 module. I assume you're going to try to get them out of the PKIX arc? Additional Info: If you tell me you'll do this during AUTH48 I'll clear this one too. #4) Two additional security considerations are needed: 1) Why algorithm agility isn't needed 2) Why it's okay to use SHA-1 Additional Info: For this one if you copy the 1st paragraph from the draft-ietf-csi-send-name-type-registry I'd clear this one too. |
2010-06-03
|
10 | Sean Turner | [Ballot Position Update] Position for Sean Turner has been changed to No Objection from Discuss by Sean Turner |
2010-06-03
|
10 | Sean Turner | [Ballot discuss] [Revised - I removed the DISCUSS positions addressed in -04. Added some more information in #2 and #4] #2) You also need to … [Ballot discuss] [Revised - I removed the DISCUSS positions addressed in -04. Added some more information in #2 and #4] #2) You also need to register the OID for the ASN.1 module. I assume you're going to try to get them out of the PKIX arc? Additional Info: If you tell me you'll do this during AUTH48 I'll clear this one too. #4) Two additional security considerations are needed: 1) Why algorithm agility isn't needed 2) Why it's okay to use SHA-1 Additional Info: For this one if you copy the 1st paragraph from the draft-ietf-csi-send-name-type-registry I'd clear this one too. |
2010-06-03
|
10 | Sean Turner | [Ballot discuss] [Revised - I removed the DISCUSS positions addressed in -05. Added some more information in #2 and #4] #2) You also need to … [Ballot discuss] [Revised - I removed the DISCUSS positions addressed in -05. Added some more information in #2 and #4] #2) You also need to register the OID for the ASN.1 module. I assume you're going to try to get them out of the PKIX arc? Additional Info: If you tell me you'll do this during AUTH48 I'll clear this one too. #4) Two additional security considerations are needed: 1) Why algorithm agility isn't needed 2) Why it's okay to use SHA-1 Additional Info: For this one if you copy the 1st paragraph from the draft-ietf-csi-send-name-type-registry I'd clear this one too. |
2010-06-03
|
10 | (System) | Sub state has been changed to AD Follow up from New Id Needed |
2010-06-03
|
04 | (System) | New version available: draft-ietf-csi-send-cert-04.txt |
2010-05-21
|
10 | (System) | Removed from agenda for telechat - 2010-05-20 |
2010-05-20
|
10 | Cindy Morgan | State Changes to IESG Evaluation::Revised ID Needed from IESG Evaluation by Cindy Morgan |
2010-05-20
|
10 | David Harrington | [Ballot Position Update] Position for David Harrington has been changed to No Objection from Discuss by David Harrington |
2010-05-20
|
10 | Jari Arkko | [Ballot discuss] This is an excellent document and I am planning to post a Yes vote on it. However, there was one detail that I … [Ballot discuss] This is an excellent document and I am planning to post a Yes vote on it. However, there was one detail that I wanted to draw your attention to: The inclusion of the owner authorization value indicates that the certificate has been issued for allowing the node to use the address(es) or prefix(es) that are mentioned using the X.509 extensions for IP addresses and AS identifiers [RFC3779] The definition of "owns" is imprecise. What exactly are you allowing nodes to do, if they have this flag on in the certificate? I *think* you mean that a host can assign the address and send/receive traffic on it, and be able to respond to NSes about that address. This is to enable the SEND certificate-based host security. But what would prefix ownership mean, and how would it be different from the router advertisement key usage flag? |
2010-05-20
|
10 | Jari Arkko | [Ballot Position Update] New position, Discuss, has been recorded by Jari Arkko |
2010-05-20
|
10 | Tim Polk | [Ballot comment] (1) Please review the secdir review in its totality. I realize this came in late, but I think there are a number of … [Ballot comment] (1) Please review the secdir review in its totality. I realize this came in late, but I think there are a number of comments that would improve the document. The review is available at: http://www.ietf.org/mail-archive/web/secdir/current/msg01701.html (2) In section 4, last sentence: Certified IPv6 address space SHOULD be expressed using either addressPrefix or addressesOrRange elements. I re-read the syntax in 3779, and I don't quite understand what is intended here. I don't think there is another choice in the end. Is the point that either a prefix or a range is acceptable? (3) Section 4 refers to an earlier version of sidr-res-certs, and the section numbering has changed. Specifically, the sections 3.9.10 and 3.9.11 are now 4.9.10 and 4.9.11. (There may be others.) If you are making other edits, updating the version number and section references might be a good idea. |
2010-05-20
|
10 | Tim Polk | [Ballot discuss] Richard Barnes identified two issues that I consider particularly important, and would like to see addressed before publication. These issues are paraphrased below: … [Ballot discuss] Richard Barnes identified two issues that I consider particularly important, and would like to see addressed before publication. These issues are paraphrased below: Section 5 identifies two deployment models. The text implies (by omission) that deployments must choose between these models. In fact, a hybrid deployment is both possible and likely. In the hybrid deployment model most resources would be certified under the global RPKI, while some (e.g., ULAs) are certified under local TAs. In Section 7, the paragraph beginning "The inclusion of ..." It would be helpful for the document to specify how prefix matching should be done when validating these extensions. Which of the following should the RP use? -- Exact matching, -- Subset matching (RA within cert), or -- The subset/intersection algorithm defined in RFC 3971. What prefix should the RP be matching against from SEND, per EKU? E.g., for id-kp-sendRouter, the RFC 3779 extension in the cert should match against any RAs the router emits. It may be useful to refer to the ROA validation document [draft-ietf-sidr-roa-validation]. |
2010-05-20
|
10 | Tim Polk | [Ballot Position Update] New position, Discuss, has been recorded by Tim Polk |
2010-05-20
|
10 | Tim Polk | [Ballot comment] (1) Please review the secdir review in its totality. I realize this came in late, but I think there are a number of … [Ballot comment] (1) Please review the secdir review in its totality. I realize this came in late, but I think there are a number of comments that would improve the document. The review is available at: http://www.ietf.org/mail-archive/web/secdir/current/msg01701.html (2) In section 4, last sentence: Certified IPv6 address space SHOULD be expressed using either addressPrefix or addressesOrRange elements. I re-read the syntax in 3779, and I don't quite understand what is intended here. I don't think there is another choice in the end. Is the point that either a prefix or a range is acceptable? (3) Section 4 refers to an earlier version of sidr-res-certs, and the section numbering has changed. Specifically, the sections 3.9.10 and 3.9.11 are now 4.9.10 and 4.9.11. (There may be others.) If you are making other edits, updating the version number and section references might be a good idea. |
2010-05-20
|
10 | Adrian Farrel | [Ballot Position Update] New position, No Objection, has been recorded by Adrian Farrel |
2010-05-20
|
10 | Ron Bonica | [Ballot Position Update] New position, No Objection, has been recorded by Ron Bonica |
2010-05-20
|
10 | Dan Romascanu | [Ballot comment] I support the comments about the need to assign the TBS values in the conditions that the document has no IANA actions. |
2010-05-20
|
10 | Dan Romascanu | [Ballot Position Update] New position, No Objection, has been recorded by Dan Romascanu |
2010-05-20
|
10 | Tim Polk | [Ballot comment] Please review the secdir review in its totality. I realize this came in late, but I think there are a number of comments … [Ballot comment] Please review the secdir review in its totality. I realize this came in late, but I think there are a number of comments that would improve the document. The review is available at: http://www.ietf.org/mail-archive/web/secdir/current/msg01701.html |
2010-05-20
|
10 | Gonzalo Camarillo | [Ballot Position Update] New position, No Objection, has been recorded by Gonzalo Camarillo |
2010-05-19
|
10 | Ralph Droms | State Changes to IESG Evaluation from Waiting for AD Go-Ahead by Ralph Droms |
2010-05-19
|
10 | Samuel Weiler | Request for Last Call review by SECDIR Completed. Reviewer: Richard Barnes. |
2010-05-19
|
10 | Stewart Bryant | [Ballot Position Update] New position, No Objection, has been recorded by Stewart Bryant |
2010-05-18
|
10 | David Harrington | [Ballot comment] 1) section 5 is missing a verb, I think - "an end user could local SEND deployment" 2) expand ULA on first use. |
2010-05-18
|
10 | David Harrington | [Ballot discuss] 1) section 7 TBAs raised by others. also the example in A uses TBA. |
2010-05-18
|
10 | David Harrington | [Ballot Position Update] New position, Discuss, has been recorded by David Harrington |
2010-05-18
|
10 | Peter Saint-Andre | [Ballot Position Update] New position, No Objection, has been recorded by Peter Saint-Andre |
2010-05-17
|
10 | Sean Turner | [Ballot discuss] I sent these during IETF LC, and I believe the author is incorporating text to address them. They have been renumbered and I … [Ballot discuss] I sent these during IETF LC, and I believe the author is incorporating text to address them. They have been renumbered and I added a new #4 and #5. I will clear once a new version is posted or an RFC editor is included: #1) I would like to see an ASN.1 module added to the document. That way we can import the EKUs. Here's what I'm looking for (something similar was done in draft-ietf-sip-eku): ----- SENDCertExtns { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) id-mod-send-cert-extns(TBD) } DEFINITIONS IMPLICIT TAGS ::= BEGIN -- OID Arc id-kp OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) 3 } -- Extended Key Usage Values id-kp-sendRouter OBJECT IDENTIFIER ::= { id-kp 23 } id-kp-sendProxy OBJECT IDENTIFIER ::= { id-kp 24 } id-kp-sendOwner OBJECT IDENTIFIER ::= { id-kp 25 } END ----- #2) You also need to register the OID for the ASN.1 module. I assume you're going to try to get them out of the PKIX arc? #3) In the last paragraph of Section 7 you describe what the certificate-using application might require. 3.a) It says that including the EKU extension is a MAY, but the first paragraph says it MUST be present in EE certificates for SEND. Assuming the 1st paragraph is correct the 1st MAY needs to be a MUST in the last paragraph. 3.b) Assuming the 1st paragraph in is correct and EKU MUST be present then shouldn't value also be required? That is, make the second MAY a MUST in the last paragraph. 3.c) Was there discussion about support for the anyExtendedKeyUsage OID from 4.2.1.12 of RFC 5280? 3.d) You should look at draft-ietf-sip-eku for what they say about processing their EKU. Those rules are helpful to implementers. #4) Two additional security considerations are needed: 1) Why algorithm agility isn't needed 2) Why it's okay to use SHA-1 #5) draft-ietf-sidr-arch-09 is a normative reference. It is expired and bound for informational. Assuming draft-ietf-sidr-arch-09 is revised, a new IETF LC is necessary for this DOWNREF. |
2010-05-17
|
10 | Sean Turner | [Ballot discuss] I sent these during IETF LC, and I believe the author is incorporating text to address them. They have been renumbered and I … [Ballot discuss] I sent these during IETF LC, and I believe the author is incorporating text to address them. They have been renumbered and I added a new #4. I will clear once a new version is posted or an RFC editor is included: #1) I would like to see an ASN.1 module added to the document. That way we can import the EKUs. Here's what I'm looking for (something similar was done in draft-ietf-sip-eku): ----- SENDCertExtns { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) id-mod-send-cert-extns(TBD) } DEFINITIONS IMPLICIT TAGS ::= BEGIN -- OID Arc id-kp OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) 3 } -- Extended Key Usage Values id-kp-sendRouter OBJECT IDENTIFIER ::= { id-kp 23 } id-kp-sendProxy OBJECT IDENTIFIER ::= { id-kp 24 } id-kp-sendOwner OBJECT IDENTIFIER ::= { id-kp 25 } END ----- #2) You also need to register the OID for the ASN.1 module. I assume you're going to try to get them out of the PKIX arc? #3) In the last paragraph of Section 7 you describe what the certificate-using application might require. 3.a) It says that including the EKU extension is a MAY, but the first paragraph says it MUST be present in EE certificates for SEND. Assuming the 1st paragraph is correct the 1st MAY needs to be a MUST in the last paragraph. 3.b) Assuming the 1st paragraph in is correct and EKU MUST be present then shouldn't value also be required? That is, make the second MAY a MUST in the last paragraph. 3.c) Was there discussion about support for the anyExtendedKeyUsage OID from 4.2.1.12 of RFC 5280? 3.d) You should look at draft-ietf-sip-eku for what they say about processing their EKU. Those rules are helpful to implementers. 4) draft-ietf-sidr-arch-09 is a normative reference. It is expired and bound for informational. Assuming draft-ietf-sidr-arch-09 is revised, a new IETF LC is necessary for this DOWNREF. |
2010-05-17
|
10 | Sean Turner | [Ballot discuss] I sent these during IETF LC, and I believe the author is incorporating text to address them. They have been renumbered and I … [Ballot discuss] I sent these during IETF LC, and I believe the author is incorporating text to address them. They have been renumbered and I added a new #4. I will clear once a new version is posted or an RFC editor is included: #1) I would like to see an ASN.1 module added to the document. That way we can import the EKUs. Here's what I'm looking for (something similar was done in draft-ietf-sip-eku): ----- SENDCertExtns { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) id-mod-send-cert-extns(TBD) } DEFINITIONS IMPLICIT TAGS ::= BEGIN -- OID Arc id-kp OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) 3 } -- Extended Key Usage Values id-kp-sendRouter OBJECT IDENTIFIER ::= { id-kp 23 } id-kp-sendProxy OBJECT IDENTIFIER ::= { id-kp 24 } id-kp-sendOwner OBJECT IDENTIFIER ::= { id-kp 25 } END ----- #2) You also need to register the OID for the ASN.1 module. I assume you're going to try to get them out of the PKIX arc? #3) In the last paragraph of Section 7 you describe what the certificate-using application might require. 3.a) It says that including the EKU extension is a MAY, but the first paragraph says it MUST be present in EE certificates for SEND. Assuming the 1st paragraph is correct the 1st MAY needs to be a MUST in the last paragraph. 3.b) Assuming the 1st paragraph in is correct and EKU MUST be present then shouldn't value also be required? That is, make the second MAY a MUST in the last paragraph. 3.c) Was there discussion about support for the anyExtendedKeyUsage OID from 4.2.1.12 of RFC 5280? 3.d) You should look at draft-ietf-sip-eku for what they say about processing their EKU. Those rules are helpful to implementers. 4) draft-ietf-sidr-arch-09 is expired and informational. Assuming draft-ietf-sidr-arch-09 is revised, a new IETF LC is necessary for this DOWNREF. |
2010-05-17
|
10 | Sean Turner | [Ballot Position Update] New position, Discuss, has been recorded by Sean Turner |
2010-05-16
|
10 | Russ Housley | [Ballot comment] In Section 7, there are several to-be-assigned values. They have been assigned: id-kp-sendRouter OBJECT IDENTIFIER ::= { id-kp 23 } … [Ballot comment] In Section 7, there are several to-be-assigned values. They have been assigned: id-kp-sendRouter OBJECT IDENTIFIER ::= { id-kp 23 } id-kp-sendProxy OBJECT IDENTIFIER ::= { id-kp 24 } id-kp-sendOwner OBJECT IDENTIFIER ::= { id-kp 25 } |
2010-05-16
|
10 | Russ Housley | [Ballot discuss] The Gen-ART Review by Roni Even on 2-May-2010 raises two concerns about changes from RFC 3971; if these changes are intentional … [Ballot discuss] The Gen-ART Review by Roni Even on 2-May-2010 raises two concerns about changes from RFC 3971; if these changes are intentional it would be very desirable to add a section on changes from RFC 3971. 1. In Section 4, second paragraph, this document says, "SEND certificates MUST include the IP Resources extension for IPv6 Address." And, Section 6.3.1 of RFC 3971 says, "Router Authorization Certificates are X.509v3 certificates, as defined in RFC 3280, and SHOULD contain at least one instance of the X.509 extension for IP addresses, as defined in RFC 3779." Is the transition from "SHOULD" to "MUST" intended? 2. In Section 4, second paragraph, this document says, "Certified IPv6 address space SHOULD be expressed using either addressPrefix or addressesOrRange elements." And, Section 6.3.1 in RFC 3971 says, "The X.509 IP address extension MUST contain at least one addressesOrRanges element" as well as "The X.509 IP address extension MAY contain additional IPv6 subnet prefixes, expressed as either an addressPrefix or an addressRange." I suspect these should be the same. |
2010-05-16
|
10 | Russ Housley | [Ballot Position Update] New position, Discuss, has been recorded by Russ Housley |
2010-05-14
|
10 | (System) | State has been changed to Waiting for AD Go-Ahead from In Last Call by system |
2010-05-13
|
10 | Amanda Baber | IANA comments: We understand this document to have NO IANA Actions. |
2010-05-09
|
10 | Alexey Melnikov | [Ballot comment] 5. Deployment Models In this scenario, the deployment of SEND MAY be done independently of the existence of deployment in … [Ballot comment] 5. Deployment Models In this scenario, the deployment of SEND MAY be done independently of the existence of deployment in the upper RPKI hierarchy (i.e. an end user could local SEND deployment without the need of RPKI deployment in Missing verb after "could". its ISP). This model MAY include ULA addresses. Please expand the ULA acronym on first use. It looks like the document needs an Informative reference to RFC 5781 (due to use of rsync URIs in the example). |
2010-05-09
|
10 | Alexey Melnikov | [Ballot discuss] 7. Extended Key Usage Values id-kp OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) dod(6) internet(1) … [Ballot discuss] 7. Extended Key Usage Values id-kp OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) kp(3) } Who owns this OID arc and who is going to assign the three values below: id-kp-sendRouter OBJECT IDENTIFIER ::= { id-kp TBA1 } id-kp-sendProxy OBJECT IDENTIFIER ::= { id-kp TBA2 } id-kp-sendOwner OBJECT IDENTIFIER ::= { id-kp TBA3 } ? |
2010-05-09
|
10 | Alexey Melnikov | [Ballot Position Update] New position, Discuss, has been recorded by Alexey Melnikov |
2010-05-03
|
10 | Samuel Weiler | Request for Last Call review by SECDIR is assigned to Richard Barnes |
2010-05-03
|
10 | Samuel Weiler | Request for Last Call review by SECDIR is assigned to Richard Barnes |
2010-04-30
|
10 | Amy Vezza | Last call sent |
2010-04-30
|
10 | Amy Vezza | State Changes to In Last Call from Last Call Requested by Amy Vezza |
2010-04-30
|
10 | Ralph Droms | Placed on agenda for telechat - 2010-05-20 by Ralph Droms |
2010-04-30
|
10 | Ralph Droms | [Note]: 'Marcelo Bagnulo (marcelo@it.uc3m.es) is the document shepherd.' added by Ralph Droms |
2010-04-29
|
10 | Ralph Droms | Last Call was requested by Ralph Droms |
2010-04-29
|
10 | Ralph Droms | State Changes to Last Call Requested from AD Evaluation by Ralph Droms |
2010-04-29
|
10 | Ralph Droms | [Ballot Position Update] New position, Yes, has been recorded for Ralph Droms |
2010-04-29
|
10 | Ralph Droms | Ballot has been issued by Ralph Droms |
2010-04-29
|
10 | Ralph Droms | Created "Approve" ballot |
2010-04-29
|
10 | (System) | Ballot writeup text was added |
2010-04-29
|
10 | (System) | Last call text was added |
2010-04-29
|
10 | (System) | Ballot approval text was added |
2010-04-29
|
10 | Ralph Droms | State Changes to AD Evaluation from Publication Requested by Ralph Droms |
2010-04-05
|
10 | Cindy Morgan | Document Shepherd Write-up for draft-ietf-csi-send-cert-03 (1.a) Who is the Document Shepherd for this document? Has the Document Shepherd personally … Document Shepherd Write-up for draft-ietf-csi-send-cert-03 (1.a) Who is the Document Shepherd for this document? Has the Document Shepherd personally reviewed this version of the document and, in particular, does he or she believe this version is ready for forwarding to the IESG for publication? The document shepherd is Marcelo Bagnulo who has reviewed this version of the document and believes that us ready for forwarding to the IESG for publication. (1.b) Has the document had adequate review both from key WG members and from key non-WG members? Does the Document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? The document was reviewed by both WG members and non-WG members. Notably, the document has been reviewed by SIDR WG members and it was produced in close collaboration with them. Other relevant WGs have been consulted during WGLC. (1.c) Does the Document Shepherd have concerns that the document needs more review from a particular or broader perspective, e.g., security, operational complexity, someone familiar with AAA, internationalization, or XML? No. (1.d) Does the Document Shepherd have any specific concerns or issues 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. Has an IPR disclosure related to this document been filed? If so, please include a reference to the disclosure and summarize the WG discussion and conclusion on this issue. No special concerns or issues. (1.e) 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 consensus behind the document is solid. the document adopts the RPKI defined in the SIDR WG, so it goes along the general consensus in the IETF. (1.f) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarize the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is entered into the ID Tracker.) No conflicts. (1.g) Has the Document Shepherd personally verified that the document satisfies all ID nits? (See http://www.ietf.org/ID-Checklist.html and http://tools.ietf.org/tools/idnits/.) Boilerplate checks are not enough; this check needs to be thorough. Has the document met all formal review criteria it needs to, such as the MIB Doctor, media type, and URI type reviews? If the document does not already indicate its intended status at the top of the first page, please indicate the intended status here. I have verified the ID nits. No MIB Doctor, media type nor UR type reviews are needed for this document. The document intended status is STD. It is intended to update RFC3971 if approved. (1.h) Has the document split its references into normative and informative? 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 strategy for their completion? Are there normative references that are downward references, as described in [RFC3967]? If so, list these downward references to support the Area Director in the Last Call procedure for them [RFC3967]. The references are split into normative and informative. There are five normative references that are in draft status. draft-ietf-csi-proxy-send will be submitted to the IESG briefly. The other 4 drafts are being done by the sidr WG, which we hope will be submitted to the IESG at some point in time. This dependence is due tot he fact that we have adopted the SIDR architecture in this draft. (1.i) Has the Document Shepherd verified that the document's IANA Considerations section exists and is consistent with the body of the document? If the document specifies protocol extensions, are reservations requested in appropriate IANA registries? Are the IANA registries clearly identified? If the document creates a new registry, does it define the proposed initial contents of the registry and an allocation procedure for future registrations? Does it suggest a reasonable name for the new registry? See [RFC2434]. If the document describes an Expert Review process, has the Document Shepherd conferred with the Responsible Area Director so that the IESG can appoint the needed Expert during IESG Evaluation? There are no IANA actions in this draft. There is however the need to assign 3 values of extended key purpose identifiers. We have requested the values to the PKIX WG and cc the AD. We would need to obtain the allocation in order for this draft to proceed. (1.j) Has the Document Shepherd verified that sections of the document that are written in a formal language, such as XML code, BNF rules, MIB definitions, etc., validate correctly in an automated checker? The document does no contain any section written in a formal language. (1.k) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary Relevant content can frequently be found in the abstract and/or introduction of the document. If not, this may be an indication that there are deficiencies in the abstract or introduction. SEcure Neighbor Discovery (SEND) Utilizes X.509v3 certificates for performing router authorization. This document specifies a certificate profile for SEND based on Resource Certificates along with extended key usage values required for SEND. Working Group Summary Was there anything in the WG process that is worth noting? For example, was there controversy about particular points or were there decisions where the consensus was particularly rough? Nothing special that worth noting. Not a controversial document. Document Quality Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to implement the specification? Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, Media Type, or other Expert Review, what was its course (briefly)? In the case of a Media Type Review, on what date was the request posted? The document defines the cert profile for SEND certs. The work has benefited from the involvement of members of the SIDR WG, notably Stephen Kent as well as the SIDR WG chairs at the time the work was done, Geoff Huston and Sandy Murphy. Personnel Who is the Document Shepherd for this document? Who is the Responsible Area Director? If the document requires IANA experts(s), insert 'The IANA Expert(s) for the registries in this document are .' Document shepherd: Marcelo Bagnulo Area Director: Ralf Droms |
2010-04-05
|
10 | Cindy Morgan | Draft Added by Cindy Morgan in state Publication Requested |
2010-04-05
|
10 | Cindy Morgan | [Note]: 'Marcelo Bagnulo (marcelo@it.uc3m.es) is the document shepherd.' added by Cindy Morgan |
2010-03-07
|
03 | (System) | New version available: draft-ietf-csi-send-cert-03.txt |
2010-02-16
|
02 | (System) | New version available: draft-ietf-csi-send-cert-02.txt |
2009-10-26
|
01 | (System) | New version available: draft-ietf-csi-send-cert-01.txt |
2009-07-03
|
00 | (System) | New version available: draft-ietf-csi-send-cert-00.txt |