From: Kurt Zeilenga <Kurt.Zeilenga@Isode.com>
In-Reply-To: <4D2C0BC2.7050002@ericsson.com>
Date: Thu, 13 Jan 2011 06:56:16 -0800
Message-Id: <627F499B-09E6-4896-A45F-6E29C1C611BC@Isode.com>
References: <4BF3DB9C-02D5-4778-9D30-694F8DB74A8D@estacado.net>
 <1B9BC3F1-3FA4-4FAF-BD32-2FE8417840FD@estacado.net>
 <4D2C0BC2.7050002@ericsson.com>
To: Gonzalo Camarillo <Gonzalo.Camarillo@ericsson.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Cc: Adam Roach <adam@nostrum.com>, draft-ietf-sipcore-sec-flows@tools.ietf.org,
 apps-discuss@ietf.org, Brian Hibbard <brian@estacado.net>
Subject: Re: [apps-discuss] Apps-team review: draft-ietf-sipcore-sec-flows
Precedence: list

On Jan 10, 2011, at 11:50 PM, Gonzalo Camarillo wrote:

> Hi Kurt,
>=20
> could you please have a look at Brian's explanation below and let us
> know whether or not you are happy with it?

My general view is that our examples and discussions should well use =
established syntaxes.  Inconsistent use of syntaxes not only reduces =
readability of individual documents containing such inconsistencies, but =
tends to cause confusion in the whole series of documents.   With DNs, =
we see significant confusion over whether the RDNs are to be written =
least-to-most specific or most-to-least specific.   This document adds =
to that confusion.

As far as the desire to use actual output of a tool a developer might =
use, I note that I would hope that bugs in such tools, such as those in =
its use of formal syntaxes, would be corrected over time.

So, I would suggestion that, either one don't use the exact output of =
the tools and noting this in the I-D OR using the exact output in the =
tools and noting both that flaws in that output and the fact that =
different versions of these tools might produce different output.

-- Kurt

>=20
> Thanks,
>=20
> Gonzalo
>=20
>>> *From: *Brian Hibbard <brian@estacado.net =
<mailto:brian@estacado.net>>
>>> *Date: *January 6, 2011 10:35:07 AM CST
>>> *To: *Kurt Zeilenga <Kurt.Zeilenga@Isode.com
>>> <mailto:Kurt.Zeilenga@Isode.com>>
>>> *Cc: *Alexey Melnikov <alexey.melnikov@Isode.com
>>> <mailto:alexey.melnikov@Isode.com>>,
>>> draft-ietf-sipcore-sec-flows@tools.ietf.org
>>> <mailto:draft-ietf-sipcore-sec-flows@tools.ietf.org>,
>>> apps-discuss@ietf.org <mailto:apps-discuss@ietf.org>
>>> *Subject: **Re: Apps-team review: draft-ietf-sipcore-sec-flows *
>>>=20
>>> Hello Kurt,
>>>=20
>>> Thank you for your input.   The inconsistencies in presentation of =
DN
>>> that you're talking about are the actual results of the dumps of the
>>> OpenSSL "x509" certificate tool.  The use of the tool in this =
context
>>> is only to examine the content of the certificates for learning and
>>> testing purposes, and in the draft, to show what  designers and
>>> testers would see in their environments.   It is only because those
>>> are the actual results from the tool most likely to be used by =
readers
>>> of this document, that we are partial to leaving the dumps as they =
are. =20
>>>=20
>>> With that said, if you remain convinced that consistency  of
>>> presentation is the more important factor here, I will go and make
>>> changes to the x509 dumps.
>>>=20
>>> Regards,
>>> Brian
>>>=20
>>> On Dec 15, 2010, at 9:21 AM, Kurt Zeilenga wrote:
>>>=20
>>>> I have been selected as the Applications Area Review Team reviewer
>>>> for this draft (for background on apps-review, please
>>>> seehttp://www.apps.ietf.org/content/applications-area-review-team).
>>>>=20
>>>> Please resolve these comments along with any other Last Call =
comments
>>>> you may receive. Please wait for direction from your document
>>>> shepherd or AD before posting a new version of the draft.
>>>>=20
>>>> Document: draft-ietf-sipcore-sec-flows (rev-07 reviewed)
>>>> Title: Example call flows using Session Initiation Protocol (SIP)
>>>> security mechanisms
>>>> Reviewer: Kurt Zeilenga
>>>> Review Date: 12/15/2010
>>>> IETF Last Call Date: [include if known]
>>>> IESG Telechat Date: 2011-01-20
>>>> Summary: This draft is basically ready for publication as an
>>>> Informational RFC but has a few issues that should be fixed before
>>>> publication.
>>>> Major Issues: None.
>>>> Minor Issues:
>>>>=20
>>>> I see some inconsistencies in how Distinguished Names (DNs) are
>>>> presented in the RFC.
>>>>=20
>>>> For instance (from 2.1):
>>>> Issuer: C=3DUS, ST=3DCalifornia, L=3DSan Jose, O=3Dsipit,
>>>>         OU=3DSipit Test Certificate Authority
>>>>=20
>>>> vs. (also from 2.1)
>>>> DirName:/C=3DUS/ST=3DCalifornia/L=3DSan Jose/O=3Dsipit/
>>>>         OU=3DSipit Test Certificate Authority
>>>>=20
>>>> The former kind of looks like the LDAP DN format but, if that's =
what
>>>> was intended, the RDNs appear in the incorrect order.  Note that in
>>>> the LDAP DN format, the most specific element appears first (the
>>>> reverse of how they appear in the BER/DER encoding of a DN).  Also,
>>>> there should be no spaces after the RDN separators (the commas).
>>>>=20
>>>> The latter appears to be DCE format.
>>>>=20
>>>> I would think it appropriate to use a single format for all DNs =
and,
>>>> if one chooses to use the LDAP DN format, that values ought to be
>>>> constructed per RFC 4514.  I note that Appendix A of RFC 4514
>>>> discusses presentation issues of Distinguished Names.
>>>>=20
>>>> Nits: The usual (many acronyms are not spelled out on first use, =
etc.)
>>>=20
>>=20
>=20
> _______________________________________________
> apps-discuss mailing list
> apps-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss