[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [TLS] WGLC for draft-ietf-tls-des-idea-01
I don't have a problem with MUSTs and SHOULDs in the security
considerations. The introduction and abstract are clear in stating that
the cipher suites are no longer recommended.
I'm OK with this resolution of the last call comments.
Joe
> -----Original Message-----
> From: tls-bounces@xxxxxxxx [mailto:tls-bounces@xxxxxxxx] On
> Behalf Of Pasi.Eronen@xxxxxxxxx
> Sent: Thursday, June 19, 2008 2:09 AM
> To: tls@xxxxxxxx
> Subject: Re: [TLS] WGLC for draft-ietf-tls-des-idea-01
>
> Joe and Eric: I'm waiting for your reply about this.
>
> Best regards,
> Pasi
>
> > -----Original Message-----
> > From: tls-bounces@xxxxxxxx [mailto:tls-bounces@xxxxxxxx] On
> Behalf Of
> > ext Pasi.Eronen@xxxxxxxxx
> > Sent: 01 June, 2008 21:37
> > To: tls@xxxxxxxx
> > Subject: Re: [TLS] WGLC for draft-ietf-tls-des-idea-01
> >
> > Here's my proposal for addressing the WGLC comments for
> > draft-ietf-tls-des-idea-01:
> >
> > Paul Hoffman wrote on 2008-05-16:
> > > - If it is meant to be an Informational RFC, it should not have
> > > SHOULD and MUST requirements
> >
> > Russ already replied to this one; we're using MUST/SHOULD
> requirements
> > in other Informational documents as well (e.g. RFC 4492),
> so I suggest
> > we keep them as is.
> >
> > > - Even if were meant for BCP or standards track, it is
> better to put
> > > SHOULD and MUST requirements in the main body of the document
> > > instead of in the Security Considerations section because
> they are
> > > requirements, not considerations.
> >
> > We don't have any MUST requirements, and the SHOULD requirements in
> > the Security Considerations section IMHO need the surrounding text
> > (<10 lines) to be understandable.
> >
> > We could move all the text to Sections 2 and 3, and just have a
> > Security Considerations text saying "The security
> considerations are
> > described in Sections 2 and 3", but I'm not sure if this
> would really
> > improve the readability. (The document is extremely short anyway).
> >
> > So, I suggest we keep them in Section 4 (but if someone
> comes up with
> > more readable text, I'm open to including it).
> >
> >
> > Tom Petch wrote on 2008-05-21:
> > > 1) In the abstract, RFC NNNN refers to the new TLS1.2
> RFC; in s.5,
> > > RFCnnnn refers to the I-D itself. I suggest adding notes
> to the RFC
> > > Editor spelling out which is which.
> >
> > TLS 1.2 will be RFC 5246, so I'll change NNNN to 5246.
> >
> > > 2) s.3, s4.2
> > > 'IDEA Cipher Suites' but there is only one; make it singular?
> >
> > Ok, will fix.
> >
> > > 3) s.3
> > > s/IDEA (International Data Encryption Algorithm) is block
> > cipher/IDEA
> > > (International Data Encryption Algorithm) is a block cipher/
> >
> > Ok, will fix.
> >
> > > 4) 3.4.1
> > > s/Given these/Given this/
> >
> > Ok, will fix.
> >
> > Chairs: I'm ready to submit an updated draft with these
> changes once I
> > get a go-ahead from you.
> >
> > Best regards,
> > Pasi
> _______________________________________________
> TLS mailing list
> TLS@xxxxxxxx
> https://www.ietf.org/mailman/listinfo/tls
>
_______________________________________________
TLS mailing list
TLS@xxxxxxxx
https://www.ietf.org/mailman/listinfo/tls