ietf
[Top] [All Lists]

Re: Comments on draft-eastlake-additional-xmlsec-uris-07.txt

2013-02-07 09:38:21
Hi,

Thanks for your comments.

See below.

On Thu, Feb 7, 2013 at 2:25 AM, SM <sm(_at_)resistor(_dot_)net> wrote:
Hi Donald,

At 18:48 06-02-2013, Donald Eastlake wrote:

I'm not sure exactly what you mean here. The errata does appear in the
references  as

   [Errata191] - RFC Errata, Errata ID 191, RFC 4051, http://www.rfc-
         editor.org

I have been told by an Area Director that this it the format that the
RFC Editor likes. You can certainly find the Errata starting with that
link and by just linking to the main ref-editor.org web page, it does
not constrain the other structure of that web site.

[Errata191] was a normative reference.  Referencing errata in an intended
Proposed Standard might be a trivial matter.  There are side effects to
that.  That may only be apparent in the long term.  I hope that the RFC
Editor does not plan to turn Standard Track RFCs into "living" standards.

OK. I will move the Errata to the Informational references.

See above.

I disagree. I believe acknowledgments are very important and should be
at the front. I commonly (but not always) put them there in my drafts.
I am also not aware of any IETF rule prescribing where
Acknowledgements go in Internet Drafts. It is true that the RFC Editor
always move them to the end, but that's the way it goes.

I noticed that you are one of the rare authors who has the Acknowledgements
at the beginning of their document.  It was a practice followed in some of
the three-digit RFCs.  There isn't any requirement in the RFC Style Guide
which prohibits the Acknowledgements from being at the front of the
document.

As I say, although I frequently put them near the front of my Internet
Drafts, the RFC Editor always moves them to the end.

I don't know whether it is relevant but John Klensin mentioned this a few
days ago:

  "One might even suggest that one of the reasons early
   ARPANET/ Internet developments worked better than the IETF
   process of today is that there was wide recognition that it was
   necessarily a collaborative effort with many people contributing
   ideas and no one wanting to seize credit."

I believe there may be some legal requirement to acknowledge those
whose contributions have resulted in change in the document, unless
they ask not to be listed. Anyway, my practice is not because anyone
has asked to be listed nearer the beginning of the document but
because I think they deserve to be so listed.

Section 5 mentions that "This document requires no IANA actions".  However,
there is another paragraph in the IANA Considerations section which is not
even actionable by IANA folks.  I am not sure whether the text should go
into that section.

Well, I could rename Section 5 to be "Allocation Considerations" and
provide two subsection, one "5.1 IANA Considerations" and one "5.2 W3C
Allocation Considerations" or the like and perhaps also move some of
the material at the beginning of Section 2 down to 5.2.

In Section 1:

  "Note that raising XML Digital Signature to Draft Standard [RFC3275]
   in the IETF required removal of any algorithms for which there was
   not demonstrated interoperability from the Proposed Standard
   document.  This required removal of the Minimal Canonicalization
   algorithm, in which there appears to be continued interest. The URI
   for Minimal Canonicalization was included in [RFC4051] and is
   included here."

That was the historic rationale for the different levels in the Standards
Track.  Rumor has it that although the rationale was forgotten, whether
intentionally or not, the "MUST" wars continued.  Dave Crocker once raised
the question of complexity of a specification.  Advancement along the
Standards could have been used to make a specification less complex by
trimming stuff which has not been implemented (see quoted text above).

In Section 2.1.1:

  "The content of the DigestValue element shall be the base64 [RFC2045]
   encoding of this bit string viewed as a 16-octet octet stream."

RFC 4648 could be reference instead of RFC 2045.

RFC4648 is Informational, so that would cause yet another downref. RFC
2045 has not bee obsoleted and seems fine to me for this purpose.

Thanks,
Donald
=============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 155 Beaver Street, Milford, MA 01757 USA
 d3e3e3(_at_)gmail(_dot_)com

Regards,
-sm