Subject: Re: Third Last Call: draft-housley-tls-authz-extns

From: <[email-masked]>
Date: Thu, 11 Oct 2007 13:54:40 +0300

> The IESG is considering approving this draft as an experimental
> track RFC with knowledge of the IPR disclosure from Redphone
> Security. The IESG solicits final comments on whether the IETF
> community has consensus to publish draft-housley-tls-authz-extns as
> an experimental standard given the IPR claimed.

<not wearing any hats>

Basically repeating the comments I made earlier:

I think this document is somewhat useful, and whatever you may think
about IPRs, basically nobody has claimed that the technical solution
is flawed (except one minor detail, easily solved by an RFC editor
note -- see below) or undesirable. 

However, since there doesn't seem to be widespread support for this
draft, an Experimental RFC seems like the most appropriate forward
(since Experimental does not need to represent IETF community
consensus or recommendation). 

The minor detail that should be fixed (as was pointed out by
others) is changing the length fields from 16 bits to 24 bits 
(the rest of TLS already uses 24-bit length fields for certificates).

Best regards,
Pasi

_______________________________________________
Ietf mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

---

From: John C Klensin <[email-masked]>
Date: Thu, 11 Oct 2007 09:54:09 -0400

--On Thursday, 11 October, 2007 13:54 +0300
[email-masked] wrote:

>...
> I think this document is somewhat useful, and whatever you may
> think about IPRs, basically nobody has claimed that the
> technical solution is flawed (except one minor detail, easily
> solved by an RFC editor note -- see below) or undesirable. 
> 
> However, since there doesn't seem to be widespread support for
> this draft, an Experimental RFC seems like the most
> appropriate forward (since Experimental does not need to
> represent IETF community consensus or recommendation). 

Assuming that this logic is reasonable (and, personally, I do),
the question remains as to why the document deserves the special
treatment of IESG sponsorship, rather than turning it over to
the tender mercies and independent review of the independent
submission process.  If nothing else, handling it as an
independent submission would remove any suspicion that it was
being given special treatment because one of its authors was
IETF Chair.

I'm not strongly advocating that approach, just asking.

     john

---

From: <[email-masked]>
Date: Thu, 11 Oct 2007 17:05:20 +0300

> I'm not strongly advocating that approach, just asking.

The IANA rules in this case require a document approved by the IESG;
otherwise, independent submission would indeed be preferable.

Best regards,
Pasi

---

From: John C Klensin <[email-masked]>
Date: Thu, 11 Oct 2007 10:48:26 -0400

--On Thursday, 11 October, 2007 17:05 +0300
[email-masked] wrote:

> John C Klensin wrote:
> 
>> Assuming that this logic is reasonable (and, personally, I
>> do), the question remains as to why the document deserves the
>> special treatment of IESG sponsorship, rather than turning it
>> over to the tender mercies and independent review of the
>> independent submission process.  If nothing else, handling it
>> as an independent submission would remove any suspicion that
>> it was being given special treatment because one of its
>> authors was IETF Chair.
>> 
> The IANA rules in this case require a document approved by the
> IESG; otherwise, independent submission would indeed be
> preferable.

Strictly speaking, at least as I understand it, the IANA rules
(actually, the IETF rules imposed on the IANA) require IESG
approval of the registration, not IESG approval/publication of
the document.  If independent submission would be preferable,
nothing would prohibit making that submission.   Then, assuming
that the RFC Editor tentatively agreed to publish, the document
would be submitted for RFC 3932 review and the IESG could sign
off on IANA registration at that point.   

That effectively requires the IESG to make a decision to
register at RFC 3932 review time, since doing otherwise would
presumably block publication of a document that specified such
registration, but it seems to me that is not a big deal,
especially in this case (where the registration has already
occurred as the result of the first IESG decision on the matter).

It may be, in practice, too late to handle this document that
way because of the discussion and IANA registration that have
already occurred, but, in terms of thinking about future cases...

    john

---

From: Sam Hartman <[email-masked]>
Date: Mon, 22 Oct 2007 11:04:23 -0400

>>>>> "John" == John C Klensin <[email-masked]> writes:

    John> --On Thursday, 11 October, 2007 17:05 +0300

    >> IESG; otherwise, independent submission would indeed be

    John> Strictly speaking, at least as I understand it, the IANA
    John> rules (actually, the IETF rules imposed on the IANA) require
    John> IESG approval of the registration, not IESG
    John> approval/publication of the document.  If independent
    John> submission would be preferable, nothing would prohibit
    John> making that submission.  Then, assuming that the RFC Editor
    John> tentatively agreed to publish, the document would be
    John> submitted for RFC 3932 review and the IESG could sign off on
    John> IANA registration at that point.

I do not believe the IESG should approve this IANA registration unless
there is community support to do so.

I think the argument that we should publish this document as-is for
the record makes no sense to me.  If we want to document an approach
so that it can be preserved as an archival record, then remove the
IANA registration, note the document specifies no code point and note
that it is being published to document an approach that did not
achieve consensus.

We should publish this document if we believe that it is reasonable
for people to use this protocol on the Internet and wish to enable
that.

---

From: John C Klensin <[email-masked]>
Date: Mon, 22 Oct 2007 11:15:54 -0400

--On Monday, 22 October, 2007 11:04 -0400 Sam Hartman
<[email-masked]> wrote:

>...
> I do not believe the IESG should approve this IANA
> registration unless there is community support to do so.

> I think the argument that we should publish this document
> as-is for the record makes no sense to me.  If we want to
> document an approach so that it can be preserved as an
> archival record, then remove the IANA registration, note the
> document specifies no code point and note that it is being
> published to document an approach that did not achieve
> consensus.
> 
> We should publish this document if we believe that it is
> reasonable for people to use this protocol on the Internet and
> wish to enable that.

Given that this is a protocol document, and that there appears
to be no substantive experiment to be performed, I believe that
this is an argument for Proposed Standard --possibly with a
comment about the IPR situation in an appendix to the RFC -- or
no publication at all.   Even publication as Informational in
order to inform, and perhaps warn, people about something that
is being used does not meet the test of "believe that it is
reasonable for people to use ... and wish to enable that.

I don't know what position that would lead me to as to whether
or not it should be published, but that simple choice does
appear to me to be the logical conclusion.

      john