Subject: Re: [Emu] Barry Leiba's No Objection on draft-ietf-emu-eaptlscert-06: (with COMMENT)

From: Roman Danyliw <[email-masked]>
Date: Thu, 5 Nov 2020 14:18:47 +0000

Hi Barry!

> -----Original Message-----
> From: iesg <[email-masked]> On Behalf Of Barry Leiba
> Sent: Friday, October 30, 2020 10:17 AM
> To: Mohit Sethi M <[email-masked]>
> Cc: [email-masked]; [email-masked]; The IESG
> <[email-masked]>; [email-masked]
> Subject: Re: [Emu] Barry Leiba's No Objection on draft-ietf-emu-eaptlscert-06:
> (with COMMENT)

[snip]
 
> On the document status issue, I'd like to hear what other working group
> participants think, and also what Roman's thoughts are.

Based on field experience, this document is proposing numerous ways to address parts of the problem spanning operational configuration, recommended implementation behavior and future protocol work.  As the guidance does not provide unambiguous, universal guidance, I believe it does fit more appropriately in the Informational status. 

Roman

> Barry
> 
> On Fri, Oct 30, 2020 at 4:12 AM Mohit Sethi M <[email-masked]>
> wrote:
> >
> > Hi Barry,
> >
> > Thank you for the careful review. I have updated the draft in github
> > (https://github.com/emu-wg/eaptls-longcert). Here is the diff for your
> > convenience:
> > https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-emu-
> eaptlscert.txt&url2=https://emu-wg.github.io/eaptls-longcert/draft-ietf-emu-
> eaptlscert.txt.
> > I will wait for all the comments to come in before submitting a new version.
> >
> > Regarding your comment of informational vs. applicability statement: I
> > am not opposed to the idea. I am happy to follow whatever the IESG
> > recommends.
> >
> > --Mohit
> >
> > On 10/28/20 9:21 PM, Barry Leiba via Datatracker wrote:
> > > Barry Leiba has entered the following ballot position for
> > > draft-ietf-emu-eaptlscert-06: No Objection
> > >
> > > When responding, please keep the subject line intact and reply to
> > > all email addresses included in the To and CC lines. (Feel free to
> > > cut this introductory paragraph, however.)
> > >
> > >
> > > Please refer to
> > > https://www.ietf.org/iesg/statement/discuss-criteria.html
> > > for more information about IESG DISCUSS and COMMENT positions.
> > >
> > >
> > > The document, along with other ballot positions, can be found here:
> > > https://datatracker.ietf.org/doc/draft-ietf-emu-eaptlscert/
> > >
> > >
> > >
> > > --------------------------------------------------------------------
> > > --
> > > COMMENT:
> > > --------------------------------------------------------------------
> > > --
> > >
> > > Thanks for this; it will be useful to have this issue fixed.
> > >
> > > There’s something I’d like to discuss, but without making it a blocking
> DISCUSS:
> > > While I understand the reason for putting this forward as
> > > Informational, it does strike me more as a Standards Track
> > > Applicability Statement.  BCP 9 says (in RFC 2026 Section 3.2):
> > >
> > >     An Applicability Statement specifies how, and under what
> > >     circumstances, one or more TSs may be applied to support a particular
> > >     Internet capability.
> > >
> > > Reading the rest of Section 3.2 as well, I think that it fits
> > > exactly what you’re doing with this document: the document is saying
> > > that there’s an interoperability problem with large certs and long
> > > chains, and here are things to do in order to make that work.  Let’s
> > > please have a brief discussion about whether this should instead be
> published at Proposed Standard as an AS.
> > >
> > > —————
> > >
> > > Below are some nits that I hope you’ll consider, but there’s no need
> > > to respond in detail here; please do as you think best.
> > >
> > > — Section 1 —
> > >
> > >     vendor specific EAP methods.
> > >
> > > Need a hyphen in “vendor-specific”.
> > >
> > >     EAP-TLS
> > >     deployments typically authenticates both the EAP peer and the
> > > EAP
> > >
> > > Make it “authenticate”.
> > >
> > >     Section 3.1 of [RFC3748] states that EAP implementations can assume a
> > >     MTU of at least 1020 octets from lower layers.
> > >
> > > Unless you have a way of pronouncing “MTU” that I don’t, make it “an
> MTU”.
> > >
> > >     Such fragmentation can not only negatively
> > >     affect the latency, but also results in other challenges.
> > >
> > > The “can” is misplaced; make it “not only can affect”.
> > >
> > > — Section 2 —
> > >
> > >     The document additionally uses the terms trust anchor and
> > >     certification path defined in [RFC5280].
> > >
> > > I would put “trust anchor” and “certification path” in quotes here.
> > >
> > > — Section 3 —
> > >
> > >     Certificate sizes can however be large
> > >
> > > Commas are needed both before and after “however”.  Also, the list
> > > talks about a singular “certificate”, so the lead-in should match
> > > that (and you don’t need to say that a *size* can be large): “A
> > > certificate can, however, be large for a number of reasons:”
> > >
> > > The list is also not parallel (the third item, in particular, is not
> > > like the others).  I would make the whole list be complete
> > > sentences, like this, referring to “a certificate” in the lead-in:
> > >
> > > NEW
> > >     o  It can have a long Subject Alternative Name field.
> > >
> > >     o  It can have long Public Key and Signature fields.
> > >
> > >     o  It can contain multiple object identifiers (OID) that indicate the
> > >        permitted uses of the certificate as noted in Section 5.3 of
> > >        [RFC5216].  Most implementations verify the presence of these OIDs
> > >        for successful authentication.
> > >
> > >     o  It can contain multiple user groups.
> > > END
> > >
> > > — Section 4.1 —
> > >
> > > Throughout this paragraph you refer to “size of public keys” and
> > > “size of digital signatures”.  It’s a really nitty nit, but I would
> > > make these all singular, because we’re really talking about the size
> > > of an individual public key or digital signature, not the size of a collection of
> them.
> > >
> > >     authentication which can alleviate the problem of authenticators
> > >
> > > There needs to be a comma before “which”.
> > >
> > >     ECC based cipher suites with existing code can significantly
> > >
> > > Hyphenate “ECC-based”.
> > >
> > > — Section 4.1.1 —
> > >
> > >     OIDs are used lavishly in X.509 certificates
> > >
> > > I like it: “lavishly” is not a word we often see in RFCs.  :-)
> > >
> > >        DNs
> > >        used in the issuer and subject fields as well as numerous
> > >        extensions.
> > >
> > > This is not a complete sentence; please fix that (I think you’re
> > > just missing “are” after “DNs”).
> > >
> > >     CN=Coolest IoT Gadget Ever
> > >
> > > Oh!  I want that!
> > >
> > >
> > >
> > > _______________________________________________
> > > Emu mailing list
> > > [email-masked]
> > > https://www.ietf.org/mailman/listinfo/emu