On Sat, Jun 27, 2020 at 12:35:35PM -0400, Stephen Kent wrote:
> Toerless,
> > Dear Stephen,
> >
> > Thank you very much for your thoughts, but i do not think we can move
> > the discussion ahead when it stops with non-technical opinion dropping
> > statements like "lets not play games" (you) or "i do not think this
> > is the right thing to do" (Ben/Russ).
> >
> > Could you please explain your assertion with technical arguments ?
>
> The ID goes to great lengths to justify the use of the rfc822Name field for
> this context, rather than defining a new data type. If this was the obvious
> "right" thing to do, there would not need to be so much text justifying the
> choice ("The lady doth protest too much, methinks").
Seriously ? Because some people people do not like it and the text
goes to great length to technically explain the choices, your
conclusion is that it must be wrong ? Do you call that a technical argument ?
> I am not an AD; I don't have a vote on this.
The IETF does not vote. We supposedly have rough consensus. I thought
that means that it needs to have a sufficient community to be interested
work (we hae that, ANIMA WG), and it needs to pass technical challenges.
It should IMHO NOT mean that people who do not have a technical arrgument
should be able to just succeed by creating a flash mob rejecting the
choice and arguing "The lady doth protest too much".
Aka: Yes, you did miss the timeline (just about 5 years ongoing) to
argue your preference how to encode in the WG before last call. You
and everybody ense in this discussion should IMHO stick to providing
technical challenges why the ANIMA WG choice can technically not appropriate
or suggest better technical choices. But such proposed better technical
choices can not simply ignore the requirements described by the
solution, and those include the long list that you like to refer to
in the negative without (i think) even having read them.
(section 6.1.2 numbered lists).
> If PKIX were still an active
> WG, and if someone came to me and asked about the choice of identifier in
> the ACP context, I would say that it was a questionable choice, given 25+
> years of experience with PKI standards and technologies.
How about ANY technical argument. If you hae experience, you would
be able to make a technical argument.
> As I noted in a prior message, when Netscape elected to shove a DNS name
> into the common name field, it was a questionable choice, and we have had to
> live with the result for 20+ years.
If your example was actually applicable to this case, you wuld be
able to describe the problem without that example. I replied to
your prior email stating that i think that eample is non-applicable
to this case.
> Elliot Lear's messages suggest that this choice was motivated,
> at least in part, by expediency, but he believes
> that sometimes expediency is an OK justification in these matters.
> Personally, I don't, but, ...
What experience do you have with backbone/WAN router/switches and NOC
software ecosystems ? If you had any idea how fragmented/duplicated/
and ossified the target deployment environment is, you too would look
for appropriate solutions that avoid unnecessary forklift
upgrade requirements. Thats exactly what new attribute types introduce
to achieve the same degree of ecosystem support as using existing
cert attributes.
Of course, this means that the solution to use an existing attribute
must accordingly match the requirements for such use. So now this
document has a long list of explanations why this is the case, and
the only rejections we are getting are opinions, but no technical
arguments.
> Steve
>
--
---
[email protected]
_______________________________________________
Anima mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/anima
