> [By the way, when I find myself in a WG meeting I'm not prepared
> for, I often have my head buried in the drafts being discussed,
> so as to be able to understand the issues. Don't assume that a head
> buried in a laptop is always doing email.]
Has there been an assumption that these "non-participants" sending
email have not read the tls-authz draft?
I'ts impossible to be sure given the lack of technical content in the comments
in question, but given that the call for comments that appeared on the FSF site
basically said "write in and voice your opposition to the publication of
tls-authz" and did not mention actually reviewing the specification, it seems
reasonable to be skeptical.
And even if they have read tls-authz it is hard to take comments containing
oxymorons like "experimental standard" very seriously, since such comments are
a strong indicator of lack of familiarity with our process or 2026 criteria.
Again, I see no difference
between what is happening on this list vs. what would happen in a F2F
meeting, except that I've never witnessed a chair or AD say "Well, it
is obvious you guys are all non-participants and therefore your hums
will be ignored" in a F2F meeting.
OTOH, I've seen plenty of F2F meetings where people were asked if they have
actually read the draft and this information was definitely a factor in how
things preceeded from there.
And I agree with Frank's point about these emails. They have been
unfairly classified as an "attack" or a DoS, perhaps to delegitimize
their content. And this episode doesn't really compare to previous
campaigns.
I, OTOH, have to say that I agree with Scott Bradner's assessment that this is
effectively a call to engage in censorship.
I agree that some of the content of the emails is nonsensical, but
the counter argument to them is that the document should be published
because the IETF process has a slot into which it will fit. Or in
other words, the IETF should publish it because it can. That does
not seem like a good enough reason.
Speaking as someone who previously sent in a message saying I support
publication of tls-authz as experimental, now you're the one being unfair. I
_never_ voice support or opposition for a specification I have not read and
tls-authz is no exception. (And I doubt very much I alone have this policy.) In
fact as it happens I not only reviewed the specification I even managed to make
it to a WG meeting where the document was discussed some time back - unusual
for me given that I don't track TLS work all that closely.
I will add that the criteria I use in evaluting documents vary depending on the
status that is sought. In this specific case I actually think the document is
close to being of sufficient quality and more thatn sufficient utility to be
approved as proposed were it not for the patent issue.
The concerns I would have raised had there been no patent issue and had this
document tried for proposed standard have to do with the use of URLs to access
"large" SAML assertions and X.509 ACs. I'm always leery of protocols that can
cause an agent to silently dereference a URL outside of a user's control. I
think the possibility that such access needs to be controlled in some way might
deserve some mention in the security considerations section. I'm also unsure if
the warning against the possibility of a circular reference (the
x509_attr_cert_url or saml_assertion_url refer to a some URL which requires
tls-authz support in order to dereference) is quite strong enough.
But these concerns didn't seem sufficiently serious to require attention prior
to publication as experimental. I believe the main concerns with experimental
specifications should be (a) Whether or not things are clear enough for
meaningful experimentation to take place and (b) Whether or not the
experimentation has been defined in such a way that it won't interfere with
existing standards-compliant usage or any other experiements. And in my view
this specification easily meets both of these criteria. (I note in passing that
in my view the sender-id and SPF experiments taken together fail to meet the
last of these criteria and IMO should not have been published without first
being modified so there's no chance of them interfering with each other.)
The one thing I wasn't sure of and did check for tls-authz was the size of the
ExtensionType field. Had that field been small I would have been concerned
about this extension wasting a valuable "slot". But since this is a 16 bit
field there's no shortage of values and I cannot get excited about the
possibility of wasting one.
Ned
_______________________________________________
Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf