Re: Last Call: draft-iesg-sponsoring-guidelines (Guidance on Area Director Sponsoring of Documents) to Informational RFC
Frank, Don't they also set the pubreq bit in the I-D tracker ? Very possibly, but that is just a progress tracking issue. I agree we need a progress tracking mechanism, but that isn't the underlying point here, which IMHO is to get the author in discussion with the appropriate AD. Brian ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-ietf-smime-cms-mult-sign (CryptographicMessageSyntax(CMS) MultipleSignerClarification) to Proposed Standard
Denis: The only person who has really engaged the conversation during the last call period was the draft editor, i.e. Russ Housley (who also happens to be a Security Area Director, but in this case he cannot play this role). So it is one against one and Sam is now the single Security Area Director allowed to make a decision. In general the activity on this mailing list is rather low. Silence on the mailing list is rather difficult to interpret. I do not agree with the interpretation Blake made of this silence: it like making the dead peole talk. I cannot understand why Russ is not wishing to try to find a compromise. In the current situation, I believe it t would be fair to have a straw poll on the mailing list and raise the two topics separately. I do not expect many responses. If you agree, I can draft the text of the two questions and propose it to you (i.e. Sam and the co-chairs). I am dumbfounded by this characterization of the dialogue. First, we had an extend exchange during WG Last Call, and you were unable to communicate any problem that justified further changes. As Blake has already said, some of your comments were accepted. Second, this topic was discussed at the San Diego meeting. Sadly, I do not see anything in the minutes, by I recall it being discussed as a dependency for the document that Jim and Sean are writing to deal with multiple signatures on S/MIME messages. I recall this portion of the document being discussed: | signerInfos is a collection of per-signer information. There MAY | be any number of elements in the collection, including zero. When | the collection represents more than one signature, the successful | validation of one of signature from each signer ought to be | treated as a successful validation of the signed-data content | type. However, there are some application environments where | other rules are needed. ... It was discussed because the document that Jim and Sean are writing will provide the application-specific rules for S/MIME. At the San Diego meeting I recall asking if anyone supported your position but was staying silent because they thought that you were doing a good job as champion for that position. No one spoke up. So, it is not one against one. I know that the WG Chairs have consulted several people before declaring that the WG had reached rough consensus. And, the write-up that the WG chairs sent to Sam (in his role as Security AD that is shepherding this document) clearly indicated that you did not agree, but that you have failed to gain any support for your position. The only form of compromise that you appear to find acceptable is the adoption of your words. I think that the long thread on the S/MIME WG mail list shows that I took the time to try to understand your position (again, some of your comments were accepted). You were not able to gain support for your position. I do not think it is appropriate to rehash the same discussion in the IETF mail list that has already taken place on the S/MIME WG mail list. Russ ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-heard-rfc4181-update (RFC 4181 Update to Recognize the IETF Trust) to BCP [WAS: Gen-art review of draft-heard-rfc4181-update-00.txt]
On Tue, 23 Jan 2007, Gonzalo Camarillo wrote: I have been selected as the General Area Review Team (Gen-ART) reviewer for this draft (for background on Gen-ART, please see http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html). Please resolve these comments along with any other Last Call comments you may receive. I will do so, and in that spirit I'm posting my response to the IETF list with the subject line changed. My apologies for the delay in replying. Draft: draft-heard-rfc4181-update-00.txt Reviewer: Gonzalo Camarillo [EMAIL PROTECTED] Review Date: 23 January 2006 IETF LC Date: 16 January 2006 Summary: This draft is basically ready for publication, but has nits that should be fixed before publication. Comments: The title of the draft could be more explicit. Now it mentions RFC 4181. It could also indicate that it is an update to the Guidelines for Authors and Reviewers of MIB Documents. I disagree with this comment -- I believe that doing as it suggests would make the title unnecessarily long. Note that the Abstract already spells out the full title of RFC 4181. Acronyms (e.g., MIB) should be expanded on their first use. The only places where the acronym MIB is used are in the Abstract and the References, where the title of RFC 4181 is quoted. The acronym is not expanded in that title, and it would be inappropriate to do so in a citation, which is supposed to quote the exact title of the document being cited. Also, I believe that MIB qualifies as an appreviation that is so firmly extablished in IETF usage that its use is very unlikely to cause uncertainty or ambiguity and so is exempt from the usual acronym expansion requirement. Granted that it is not explicitly mentioned in http://www.rfc-editor.org/policy.html#policy.abbrevs, but several recent RFCs using the acronym MIB have appeared without it being expanded anywhere. RFC 4181 and RFC 4663 are examples. The only other acronym I see is IETF, and that one is explicitly mentioned in http://www.rfc-editor.org/policy.html#policy.abbrevs. The draft should be divided into pages, none of which should exceed 58 lines. Unless I'm required to make another revision for other reasons, I'd like to let the RFC Editor take care of that (which they will do anyway) ... my apologies if the lack of pagination has caused any readability problems. Mike ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Document Action: 'Suite B Cryptographic Suites for IPsec' to Informational RFC
The IESG has approved the following document: - 'Suite B Cryptographic Suites for IPsec ' draft-solinas-ui-suites-01.txt as an Informational RFC This document has been reviewed in the IETF but is not the product of an IETF Working Group. The IESG contact person is Russ Housley. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-solinas-ui-suites-01.txt Technical Summary This document proposes four optional cryptographic user interface suites (UI suites) for IPsec similar to the two suites specified in RFC 4308. The four new suites provide compatibility with the United States National Security Agency's Suite B specifications. Working Group Summary This is not part of any Working Group, but the document was announced on the IPsec mail list. Protocol Quality This document was reviewed by Russ Housley for the IESG. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
