Re: I-D Action: draft-joseph-pkix-p6rsshextension-03.txt

- why list-certificates with a  hyphen and listnamespaces without?
  
    Yes we could make that change thought I don't see how it is really
  significant.
  
  <tp>
  the presence and absence of the hyphen will just cause coders, users and
  everyone else to make mistakes, forgetting that it is sometimes there
  and sometimes not.  Technically it makes no difference; in terms of
  producing a robust protocol, it does
  I don't mind making this change as it is minor, however, I doubt it will save an coding errors.

     -" This document defines version 3 of the new protocol.  We are using
       version 3 so that it can be backward compatible with the protocol
       defined by RFC 4819 [1]. "
      Um, seems a bit like namespace squatting which seems improper in an
    Informational RFC
  
  Our document actually defines a totally separate protocol from RFC 4819.
  In section 3 of our document we state that we use a different subsystem
  name:
  
  "[email protected]".    We can start the version number at
  anything.   The benefit of starting with Version 3 is that software
  used to build RFC 4819 implemenations could be extended easily
  to add the functionality we have defined (since that is what we did).
  
  <tp>
  The IETF has produced a Standards Track V2 - I expect the numbers 3, 4,
  5 etc to be implicitly at least reserved for IETF Standard Track use,
  not to be used for a private protocol, even if it does appear in an RFC.
  And since it is 'totally separate', then the use of 3 seems
  inappropriate.  With other, more recent protocols, fields like this have
  a defined range for IETF Standards and a separate one for other
  variants.
  Again we are defining a new protocol one where the subsystem name is private
to us and thus it is easy to start at any number.
Since this is not related directly to any other protocol is it not relevant what version number
we start at.   So in this issue I disagree with the reviewers comment.


    - " Examples of possible "certificate format name" are: "X509",
       "pgp-sign-rsa", and "pgp-sign-dss".  "
    I would expect interoperability to require a defined list, the sort of
    thing that IANA does rather well.
    Also, the names would be more recognisable if there were something
  that
    said certificate, rather than key types, eg cert-pgp-sign-rsa
  A previous reviewer had us add the PGP reference since it comes from RFC
  4253 SSH Transport layer
  protocol (Section 6 Public Key Algorithms).  Frankly I don't see the
  benefit of doing an IANA of certificate types
  for this RFC since there has to be an existing one already for X509 and
  PGP certs.  Seems redundant.
  
  <tp>
  I am surprised by this.  Interoperability, which is a usual requirement
  for an IETF protocol, requires that different implementors come up with
  solutions that can interwork, which means that they know what values of
  what parameters may be encountered, and what they mean.  An undefined
  list of potential certificate types seems not to meet that requirement