Subject: Re: [Ietf-krb-wg] Comments on Adopting draft-hudson-krbwg-camellia-cts-02 as a work item

From: Greg Hudson <[email-masked]>
Date: Wed, 06 Jul 2011 11:58:19 -0400

On Wed, 2011-06-29 at 10:14 -0400, Sam Hartman wrote:
> The chairs would like to solicit comments on whether to adopt Greg's
> Camellia CTS draft as a working group item.  It's my understanding that
> we have a consensus to specify some Camellia enctype.  I'd like to
> confirm that we're happy with the move from counter modes back to CTS.

I'll review the reasoning here:

* CCM and GCM require us to fit a nonce and block counter, plus some
cipher mode overhead, into a 128-bit block.  This turns out to be a
tight fit for an RFC3961 enctype.

* CBC with padding might be seen as undesirable as an SSPI enctype
because of apps which provide 8-byte padding buffers.

* That leaves CTS.

More here about the nonce/block counter:
https://lists.anl.gov/pipermail/ietf-krb-wg/2011-June/009298.html

And more here about padding:
https://lists.anl.gov/pipermail/ietf-krb-wg/2011-June/009273.html

_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Nico Williams <[email-masked]>
Date: Wed, 6 Jul 2011 11:10:28 -0500

> tight fit for an RFC3961 enctype.

Right, thank you Greg, that is a very succint way to put it.

I have no opinion as to Camellia, but I agree that since we cannot use
a counter mode, and because of the SSPI limitation, we have no choice
but to use CTS.  That makes the question of consensus regarding CTS
moot -- unless there's some other cipher mode which has similar
properties to CTS that I don't know about.

The only other question of consensus, ISTM, would be whether to
abandon Camellia due to CTS being unacceptable to the WG.  But since
we already use CTS happily enough, I don't think there's any serious
question of abandoning Camellia over CTS.

Nico
--

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 08 Jul 2011 00:00:33 +0100

Hi Sam,

On 29/06/11 15:14, Sam Hartman wrote:
> It's my understanding that
> we have a consensus to specify some Camellia enctype. 
...
> Please send comments by July 10.

Could I add a request to yours?

We see a fairly constant stream of "new cipher for foo"
requests and, as ADs, Sean and I generally ask "which
WG wants/needs this?" and push back if the answer is
none. The basis for asking being that we don't think
that having seven different ciphers for foo is
generally helpful unless there's a reason.

So, I'd be quite interested in knowing who actually
(currently) wants Camellia for kerberos as part of
this exercise. Actually, if/when this I-D comes up
for an AD review then that'll be my first question.

I'm not sure if that was something that happened
already in the WG or not, if so, then a pointer to
the archive would be appreciated, but I'd still be
interested in current opinions.

Thanks,
Stephen.

---

From: Thomas Hardjono <[email-masked]>
Date: Thu, 7 Jul 2011 20:02:24 -0400

Hi Stephen,

>> this exercise. 

This work (Camellia support in Kerberos) originated from
joint work between the MIT-KC and NTT.
The first draft was submitted by NTT in March 2010, but
after several revisions we finally settled for the CTS-based
solution (which is the current draft under consideration).

In terms of user community, NTT and several other companies
in Japan want to use Kerberos with a cipher
other than AES. Since the Camellia cipher itself is already an 
ISO standard (ISO/IEC 18033-3), we thought it a reasonable
to support Camellia in Kerberos.

ps.  There is already RFC4132 covering Camellia in TLS.
And I believe there are other Camellia-related drafts in other WGs.

Hope this helps.

cheers,

/thomas/

________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Stephen Farrell [[email-masked]]
Sent: Thursday, July 07, 2011 7:00 PM
To: Sam Hartman
Cc: [email-masked]
Subject: Re: [Ietf-krb-wg] Comments on Adopting draft-hudson-krbwg-camellia-cts-02 as a work item

Hi Sam,

...

Thanks,
Stephen.

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 08 Jul 2011 09:21:02 +0100

Hi Thomas,

On 08/07/11 01:02, Thomas Hardjono wrote:
> ISO standard (ISO/IEC 18033-3), 

Seems like that's true for almost all algorithms that show
up. I'm not clear what the requirements are there.

> we thought it a reasonable

So I'd be interested if several other folks also said
they wanted this. (I'm not insisting, but I am asking.)

> And I believe there are other Camellia-related drafts in other WGs.

Maybe we need to think about this - there's a constant
stream of new-cipher-with-TLS drafts, just because one
of those got through doesn't mean that we should follow
suit in other WGs without being happy with the algorithm,
its IPR environment, performance etc.

I guess that's one cfrg/saag really - what's the preferred
thing to have in most places as an alternative to AES?

S.

---

From: Sam Hartman <[email-masked]>
Date: Fri, 08 Jul 2011 17:20:55 -0400

Thomas, WG.

Since Stephen has raised the question, I'd like to explicitly ask for WG
participants who support advancing a WG document on Camellia as a
Kerberos cipher to explicitly speak up.  We've heard from Thomas and
Greg already.
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Thomas Hardjono <[email-masked]>
Date: Mon, 11 Jul 2011 11:02:11 -0400

Sam,

There might be some delay in emails from folks in Japan, as many of the companies there are on periodic power blackouts (ie. mail servers periodically down).

/thomas/

__________________________________________

> -----Original Message-----
> From: Sam Hartman [mailto:[email-masked]]
> Sent: Friday, July 08, 2011 5:21 PM
> To: Thomas Hardjono
> Cc: Stephen Farrell; Sam Hartman; [email-masked]; ietf-krb-
> [email-masked]
> Since Stephen has raised the question, I'd like to explicitly ask for
> WG participants who support advancing a WG document on Camellia as a

---

From: Nico Williams <[email-masked]>
Date: Mon, 11 Jul 2011 12:33:13 -0500

I agree with not adding new required-to-implement ciphers haphazardly.
 We must have at least one strong required to implement cipher suite
for every protocol, and we should stick to the roughly same algorithms
in all those cases (i.e., AES-128, SHA-256, HMAC, GCM, ...).

This should not preclude the addition of non-required-to-implement
cipher suites though, right?

Is the proposed Camellia enctype intended to be required-to-implement
for Kerberos?

Nico

---

From: Nico Williams <[email-masked]>
Date: Mon, 11 Jul 2011 12:34:05 -0500

> in all those cases (i.e., AES-128, SHA-256, HMAC, GCM, ...).

I meant to add that we should also not have N > 2 such cipher suites.

Nico

---

From: Greg Hudson <[email-masked]>
Date: Mon, 11 Jul 2011 13:40:42 -0400

> Is the proposed Camellia enctype intended to be required-to-implement

Certainly not.  This is "if you have a business need to use Camellia in
Kerberos, this is how you should do it."

---

From: Nico Williams <[email-masked]>
Date: Mon, 11 Jul 2011 12:48:51 -0500

> Kerberos, this is how you should do it."

Then I am firmly in support of it.  I would object to having a
required-to-implement cipher suite for every national security agency,
or even a small subset of them all.
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Simon Josefsson <[email-masked]>
Date: Mon, 11 Jul 2011 20:06:49 +0200

> Kerberos, this is how you should do it."

My preference then is that it would be a good fit for Informational
category, but not for Standards Track.  We already have a good cipher
for Kerberos in AES.  If AES is publicly broken, we need to perform
standards actions anyway, and then we move Camellia to standards track
if there is (however unlikely) consensus to use Camellia as the
mandatory-to-implement cipher at that point.

/Simon

---

From: Sam Hartman <[email-masked]>
Date: Mon, 11 Jul 2011 14:10:01 -0400

>>>>> "Nico" == Nico Williams <[email-masked]> writes:

    Nico> I agree with not adding new required-to-implement ciphers haphazardly.
    Nico>  We must have at least one strong required to implement cipher suite
    Nico> for every protocol, and we should stick to the roughly same algorithms
    Nico> in all those cases (i.e., AES-128, SHA-256, HMAC, GCM, ...).

    Nico> This should not preclude the addition of non-required-to-implement
    Nico> cipher suites though, right?

    Nico> Is the proposed Camellia enctype intended to be required-to-implement
    Nico> for Kerberos?

It is not.
It's not even clear it's standards track.

    Nico> Nico
    Nico> --

---

From: Nico Williams <[email-masked]>
Date: Mon, 11 Jul 2011 14:00:25 -0500

> mandatory-to-implement cipher at that point.

!required-to-implement !-> !Standards-Track.

Standards-Track !-> required-to-implement.

I think cipher suites must be specified in Standards-Track RFCs
wherever there is sufficient interest.

Nico

---

From: Martin Rex <[email-masked]>
Date: Mon, 11 Jul 2011 21:40:11 +0200 (MEST)

Nico Williams wrote:
> > category, but not for Standards Track. Â We already have a good cipher
> > for Kerberos in AES. Â If AES is publicly broken, we need to perform

I believe this characterization is neither correct nor useful.

Standards Track (=Proposed) should be reserved for
cipher suite (TLS) or enctype (Kerberos) with "broad" support
from the working group and/or IETF, the notion that it is considered
generally useful, and the ambition that it may become a recommended
or even mandated cipher suite in the underlying spec.

A protocol extension at level "proposed" regularly creates some
level of expectation to consumers of a technology, even if there
is no spec around that declares it as mandatory (or even recommended).

E.g. the TLS extension "server name indication" is purely optional,
but there appears to be a certain level of expectation that newer
clients would support it (or that servers would support it).

Or the RSA PKCS#v2.x RSA-PSS (probabilistic signature scheme) is
something where a lot of consumers seem to silently assume it would
be available everywhere, which seems to be a flawed assumption.

Everything else (and in particular IP-encumbered algorithms)
should go informational with an "indeterminte" status about their future
(i.e. if you want to use that as well, that's how you should do it,
 otherwise, don't bother).

When looking at TLS cipher suites, I'm confused about the PS/Info motivations:

6209  Informational   Aria TLS cipher suites
5932  Proposed        Camellia TLS cipher suites
5489  Informational   ECDHE_PSK TLS cipher suites
5487  Proposed        PSK cipher suites for TLS with SHA256/384 and AES
5469  Informational   DES and IDEA TLS cipher suites NOT RECOMMENDED
5289  Informational   TLS EC cipher suites with SHA-256/384 and AES-GCM
5288  Proposed        TLS cipher suites with AES-GCM
4785  Proposed        PSK cipher suites with Null Encryption
4492  Informational   ECC cipher suites for TLS
4279  Proposed        PSK cipher suites for TLS
4162  Proposed        SEED cipher suites for TLS
4132  Proposed,obsoleted by 5932  Camellia TLS cipher suites
3268  Proposed        AES cipher suites for TLS
2712  Proposed        Kerberos cipher suites for TLS

More precisely, I'm confused by the stati of
the documents 2712,4162,4492,4785,5288

Having Camellia (4132/5932) as an alternative symmetric cipher at
Proposed is OK in case the community believes that this would be
an appropriate alternative to AES.  But IMHO the IETF should be
careful about picking stuff that goes to Proposed.

-Martin

---

From: Nico Williams <[email-masked]>
Date: Mon, 11 Jul 2011 14:56:42 -0500

> or even mandated cipher suite in the underlying spec.

IMO "standard" != "must implement", and "informational" is too weak in
many cases (for example, process-wise, publication as Informational
may elicit less review, both in quantity and quality.

To me the correct rationale for selecting Informational is that too
few people care to provide the level of review required for a
Standards-Track RFC.  Thus Informational might still be appropriate,
but it is not correct to say that just because we don't want this as a
required-to-implement enctype we can't have it be Standards-Track.

> is no spec around that declares it as mandatory (or even recommended).

This is true, but this is a problem for the implementor, not a problem
for the IETF (except in so far as the IETF could do a better job of
documenting that a Standards-Track RFC is not actually a
required-to-implement part of a larger standard).

> clients would support it (or that servers would support it).

Irrelevant.  The fact that a feature is published as Informational
does not preclude it from becoming so popular that moving it to the
Standards-Track may become the only reasonable thing to do (short of
replacing the feature with some other, better alternative, but that
may not be realistic).  The reverse is also true: that putting
something on the Standards-Track does not mean that anyone will bother
implementing it.

>  otherwise, don't bother).

I also don't agree that IPR encumbrance should preclude publication on
the Standards-Track.  It *can*, but it doesn't have to.

BTW, we really need to put criteria for track selection into an RFC
and then make sure that participants know what that RFC is (I suspect
it exists, so please feel free to clue me in as to what it is).  I
don't want to have this debate too frequently and outside the context
of documenting such criteria or making changes to that documentation.
This is not a debate we ought to have in this WG either, so I'll shut
up on this matter going forward and limit my opinions to the proposed
status for Camellia.

> careful about picking stuff that goes to Proposed.

Of course we should be careful about this.  I'm not asserting that
Camellia must be on the Standards-Track.  I'm asserting that lack of
interest in making Camellia required-to-implement does not preclude
publication on the Standards-Track.

I might still support publication as Informational, or even not have
an opinion on that matter.  What I am saying with certitude is that I
oppose making Camellia a required-to-implement enctype.

Nico

---

From: Martin Rex <[email-masked]>
Date: Tue, 12 Jul 2011 00:12:21 +0200 (MEST)

> required-to-implement enctype we can't have it be Standards-Track.

Standards Track should be reserved for stuff that we really intend
to go _on_ Standards Track and continue -> DS -> Full Standard
in short time.

It would look pretty strange to have a document with Camellia
--and not being required or even recommended anywhere-- progess
through -> DS -> Full Standard while a similar document with AES
is required and still at Proposed.

I firmly believe that for any document where there is _no_ intention
to work on advancing it along -> DS -> Full _within_ the next 24 months,
it should be Informational *ONLY*.

The reasons why there are too many documents sitting there at PS
and doing nothing is probably that a lot of them should not be
on the Standards Track in the first place.

-Martin

---

From: Satoru Kanno <[email-masked]>
Date: Tue, 12 Jul 2011 22:08:27 +0900

Hi Sam,

I'm sorry for the delayed response.

I support for the Camellia draft as a WG document.

Because NTT and several other companies in Japan think of using Kerberos 
with Camellia.  And, Camellia cipher has been internationally 
recognized, for example the NESSIE project [1] evaluated Camellia to 
have "many similarities to the AES, so much of the analysis for the AES 
is also applicable to Camellia."
Of course, Camellia cipher is already an ISO standard (ISO/IEC 18033-3).

We thought it a reasonable to support Camellia in Kerberos.

[1] Section 2.2 of Portfolio of recommended cryptographic primitives
https://www.cosic.esat.kuleuven.be/nessie/deliverables/decision-final.pdf

Regards,
-- 
Satoru Kanno

Security Business Unit
Mobile and Security Solution Business Group
NTT Software Corporation

e-mail: [email-masked]

---

From: "Thomas Hardjono" <[email-masked]>
Date: Tue, 12 Jul 2011 10:17:52 -0400

> From: [email-masked] [mailto:ietf-krb-wg-
> [email-masked]] On Behalf Of Martin Rex
> Sent: Monday, July 11, 2011 6:12 PM
> To: Nico Williams
> Cc: [email-masked]; [email-masked]
> Subject: Re: [Ietf-krb-wg] Comments on Adopting
> 
> Nico Williams wrote:
> >
> > > Standards Track (=Proposed) should be reserved for cipher suite
> > > (TLS) or enctype (Kerberos) with "broad" support from the
working
> > > group and/or IETF, the notion that it is considered generally
> > > useful, and the ambition that it may become a recommended or
even
> > > mandated cipher suite in the underlying spec.
> >
> > IMO "standard" != "must implement", and "informational" is too
weak
> in
> > but it is not correct to say that just because we don't want this
as
> a
to
> go _on_ Standards Track and continue -> DS -> Full Standard in short
> time.
> 
> 
> -Martin

Hi Martin, Nico,

The desire is to have Camellia go forward to Standards Track (eg.
along same track as RFC3962).

FYI. Many vendors are anticipating that the Japanese government will
soon require Camellia to be present (but not necessarily enabled) in
all vendor-products sold into the government sector in Japan. This
would allow them to quickly switch to Camellia (from AES) should the
need arises. So I think having Kerberos-Camellia as Standards Track is
important for US vendors.  Release 1.9 of MIT Kerberos already
implements Camellia-CTS (Greg's draft).

Now I do understand that there are lots ciphers being put forward in
the IETF (in one WG or another).  This is why I suggested that a good
criteria for selecting ciphers for this WG (and the whole of IETF)
would be the cipher passing the ISO standardization process.

/thomas/

---

From: Nico Williams <[email-masked]>
Date: Tue, 12 Jul 2011 09:51:28 -0500

> Hi Martin, Nico,

To be extra clear: I'm not opposed to this being on the
Standards-Track (Martin is), or at least I wasn't yesterday.  I'm
opposed to this being a required to implement cipher.

I understand that every country with a cipher of its own and enough
economic power will be pushing this approach.  Who cares if a cipher
suite is required to implement, or even standardized, if the country
has enough economic pull to force implementors to implement it
anyways?

There's an obvious argument for resisting this approach: it leads to a
huge burden on implementors.  The counter-arguments are a bit weaker,
I think: if these cipher suites get standardized outside the IETF
they'll get less review -- but then, if this results in some national
security agency getting egg on its face, does the IETF care?  Probably
not.

Perhaps I should rethink my position.  However, first I'd like to hear
more from the ADs as to the IESG's position on this.

Nico

---

From: Martin Rex <[email-masked]>
Date: Tue, 12 Jul 2011 17:18:33 +0200 (MEST)

Nico Williams wrote:
> Standards-Track (Martin is),

No, I'm not.  Never said that.  I just pointed out that both the WG
and the IETF should be extra careful about putting proposals on the
Standards Track, and rather go for Informational if they are not
really serious about usefulness _and_ broad acceptance.

That means that the cipher should be found generally acceptable
by all folks that are potentially affected: IPsec, CMS, TLS, Kerberos

There have been made arguments for having Camellia TLS cipher suites
on the standards track, so I did _not_ list the respective rfcs
as ones where I find the status confusing.

>
>                        or at least I wasn't yesterday.  I'm

The idea of having an alternative symmetric cipher on the Standards Track
is to make it RECOMMENDED, so that it really becomes an alternative
to the consumers.

Having more than one algorithm required to implement is advisable only
during a transition from a previously mandatory cipher to a new mandatory
cipher.

> has enough economic pull to force implementors to implement it

I agree with Nico.  With that reasoning, we will quickly have to
adopt ciphers from China, Russia and India as well.

So I find the argument that Japan is embracing Camellia not acceptable.
Camellia being an ISO-Standard is a more acceptable rationale.

-Martin

---

From: Nico Williams <[email-masked]>
Date: Tue, 12 Jul 2011 10:32:11 -0500

> really serious about usefulness _and_ broad acceptance.

My apology for the misunderstanding.

> by all folks that are potentially affected: IPsec, CMS, TLS, Kerberos

Reaching that kind of consensus will be difficult.

> is to make it RECOMMENDED, so that it really becomes an alternative

To me Standards-Track does not imply even RECOMMENDED status.

But we agree, I think, that status is practically irrelevant.  If the
government of large country X wants to force implementors who want
their implementations used in X to implement... well, who cares about
standardization status?

> during a transition from a previously mandatory cipher to a new mandatory

Having two widely deployed cipher suites has proved to be useful in
some cases (SSHv2 comes to mind).

But having N>2 required-to-implement cipher suites is asking a lot of
implementors, and will confuse users.

> adopt ciphers from China, Russia and India as well.

Add Brazil to the list.  Also the EU.  And any future blocks that form
to get enough combined economic power to force the matter.  We're
talking well over six cipher suites, all effectively required to
implement.

OTOH, if this is inevitable, why fight it?  Convince me either way.

Nico

---

From: Martin Rex <[email-masked]>
Date: Tue, 12 Jul 2011 18:17:17 +0200 (MEST)

> Reaching that kind of consensus will be difficult.

Why? I don't remember it being difficult for AES.

> To me Standards-Track does not imply even RECOMMENDED status.

As previously discussed, standards track (PS) was supposed to be only
an interim step to DS and Full Standard.  Having something that is
not supposed to be recommended a Full Standard seems just wrong.
But if there is no motivation to make something progress beyond PS,
then it should not be on IETF standards track at all -> Informational.

> their implementations used in X to implement... well, who cares about

Agreed.  Having an informational document publish at some point
"if you want to do this variant of a protocol and become interoperable
 with what others before you did, this is how to do it".

> 
> > I agree with Nico. Â With that reasoning, we will quickly have to

I was just randomly guessing a few country names with high population.
I don't know about Brazil.  It seems that EU is mostly comfortable with
the openness and outcome of the NIST selection process.  Are you aware
of a more open and widely participated selection process with less bias
than the competitions run by NIST, please speak up.

> OTOH, if this is inevitable, why fight it?  Convince me either way.

Having to fulfil certain market requirements will be inevitable for
many software vendors.

IMHO the IETF should be careful in selecting what it puts on
the standards track.

Perfection in design in achieved not when there is nothing left to add,
but rather when there is nothing more to take away. (Antoine de Saint-Exupery)

-Martin

---

From: Nico Williams <[email-masked]>
Date: Tue, 12 Jul 2011 11:41:51 -0500

> Why? I don't remember it being difficult for AES.

Because then we badly needed to move on from DES (and 3DES).  Now..
what's the reason to do anything other than AES?  (Ease of
high-performance side-channel-free implementation in software would be
a very good reason, actually.)

> an interim step to DS and Full Standard.  Having something that is

There's a defined time to go from DS to S.  There's no defined
timeline for PS->DS.  The RFC database is littered with important PS
RFCs that are not likely to progress anytime soon.  So what?

> not supposed to be recommended a Full Standard seems just wrong.

I'm not opposed to Camellia becoming a Standard.  And again, to me
Standard says nothing about whether the thing is required to implement
in any other context.  If RFC4120 were a Standard, would anyone be
required to implement it?  No.

> then it should not be on IETF standards track at all -> Informational.

I disagree.  PS is Proposed Standard.  A lot of time is allowed to
pass between placing an RFC on the Standards-Track and either
progressing it or moving it to HISTORIC.  The choice of track should
be made in part based on willingness of the community to review -- if
unwilling, then publish as Informational or Experimental, or even not
at all as an RFC.

> Having to fulfil certain market requirements will be inevitable for

If it's inevitable then I have nothing against publication of a
Camellia enctype as a Proposed Standard.  If this is evitable (why
isn't that a word? :) then I might not acquiesce.

Nico

---

From: Martin Rex <[email-masked]>
Date: Tue, 12 Jul 2011 20:52:46 +0200 (MEST)

> unwilling, then publish as Informational or Experimental, or even not

What is so difficult to understand about rfc2026?

http://tools.ietf.org/html/rfc2026#section-4

   4.  THE INTERNET STANDARDS TRACK

*  Specifications that are intended to become Internet Standards evolve
*  through a set of maturity levels known as the "standards track".
   These maturity levels -- "Proposed Standard", "Draft Standard", and
   "Standard" -- are defined and discussed in section 4.1.  The way in
   which specifications move along the standards track is described in
   section 6.

http://tools.ietf.org/html/rfc2026#section-4

   4.2.2  Informational

   An "Informational" specification is published for the general
   information of the Internet community, and does not represent an
*  Internet community consensus or recommendation.

http://tools.ietf.org/html/rfc2026#section-6.2

   6.2  Advancing in the Standards Track

   The procedure described in section 6.1 is followed for each action
   that attends the advancement of a specification along the standards
   track.

   A specification shall remain at the Proposed Standard level for at
   least six (6) months.

   A specification shall remain at the Draft Standard level for at least
   four (4) months, or until at least one IETF meeting has occurred,
   whichever comes later.

   [...]

   When a standards-track specification has not reached the Internet
   Standard level but has remained at the same maturity level for
   twenty-four (24) months, and every twelve (12) months thereafter
   until the status is changed, the IESG shall review the viability of
   the standardization effort responsible for that specification and the
   usefulness of the technology. Following each such review, the IESG
   shall approve termination or continuation of the development effort,
   at the same time the IESG shall decide to maintain the specification
   at the same maturity level or to move it to Historic status.

What is missing there are IESG actions to move documents from
a standards level to Experimental or to Informational as an
alternative to Historic -- in case that the Standardization Effort
is terminated but the criteria for Historic is not met.  But it
should be possible for the IESG to close this gap with pragmatism.

> 
> >> OTOH, if this is inevitable, why fight it? Â Convince me either way.
> >

The fact that having to implement something being inevitable for
some software vendors would be an extremely poor rationale for
making a document IETF standards track.  Personally, I think that
it would be a strong indicator for Informational if that is
the only motivator.

-Martin

---

From: Sam Hartman <[email-masked]>
Date: Wed, 13 Jul 2011 09:40:24 -0400

I had initially requested that comments on whether to adopt the Camellia
CTS draft be received by July 10.  I think the discussion is still
ongoing, so I want to explicitly encourage people to continue the
discussions.

In terms of timing, I'm going to need to coordinate with the other
chairs to make a consensus call here; I hope we're in a position to make
a decision by IETF.
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg