Hi Ekr, See below
> On 13. Mar 2019, at 16:50, Eric Rescorla <[email protected]> wrote: > > Thanks for pointing that out. I had forgotten. This in fact seems to support > use of Obsoletes here. > > -Ekr > > > On Wed, Mar 13, 2019 at 7:53 AM Alissa Cooper <[email protected]> wrote: > Hi Mirja, > > > On Mar 13, 2019, at 10:19 AM, Mirja Kuehlewind <[email protected]> wrote: > > > > HI Ekr, > > > > I actually have a related question. As this document is rather specifying a > > new version than “just” correcting an existing spec, it’s not really clear > > to me if the obsolete tag is the right choice here. I know some other > > protocols do this in a similar fashion, but I would rather recommend to > > only update the previous version RFC (in order to create a link to this new > > spec) or declare it historic if usage is not recommended anymore. I think > > that's also something we should discuss on the IESG. > > We have a statement that explains our current position: > https://www.ietf.org/blog/iesg-statement-designating-rfcs-historic/ Based on the statement you made in the other mail: "this is a new version of this protocol and you should stop using the old and and start using this one” And what’s written in this statement: " • A document is labelled Historic when what it describes is no longer considered current: no longer recommended for use. “ I would think historic should be used. Mirja > > Alissa > > > > > Coming back to your original question about how much should be changed in a > > bis document. I think this is a valid question for bis doc that correct > > known errors. However, in case of this document that specifies a new > > version, I think it is the right thing to do to also align such a new > > version with the guidelines we follow at the time of publication. > > > > Mirja > > > > > >> On 13. Mar 2019, at 14:28, Eric Rescorla <[email protected]> wrote: > >> > >> > >> > >> On Tue, Mar 12, 2019 at 11:36 PM Adam Roach via Datatracker > >> <[email protected]> wrote: > >> Adam Roach has entered the following ballot position for > >> draft-ietf-trans-rfc6962-bis-31: Discuss > >> > >> When responding, please keep the subject line intact and reply to all > >> email addresses included in the To and CC lines. (Feel free to cut this > >> introductory paragraph, however.) > >> > >> > >> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > >> for more information about IESG DISCUSS and COMMENT positions. > >> > >> > >> The document, along with other ballot positions, can be found here: > >> https://datatracker.ietf.org/doc/draft-ietf-trans-rfc6962-bis/ > >> > >> > >> > >> ---------------------------------------------------------------------- > >> DISCUSS: > >> ---------------------------------------------------------------------- > >> > >> Thanks to everyone who worked on updating this protocol to reflect > >> experience > >> gathered from the initial CT protocol. I have one blocking comment, and a > >> small > >> number of editorial suggestions. > >> > >> --------------------------------------------------------------------------- > >> > >> §5: > >> > >>> Clients are configured with a base URL for a log and construct URLs > >>> for requests by appending suffixes to this base URL. This structure > >>> places some degree of restriction on how log operators can deploy > >>> these services, as noted in [RFC7320]. However, operational > >>> experience with version 1 of this protocol has not indicated that > >>> these restrictions are a problem in practice. > >> > >> The synthesis of URLs by a protocol in this fashion is prohibited by BCP > >> 190: > >> > >> Scheme definitions define the presence, format, and semantics of a > >> path component in URIs; all other specifications MUST NOT constrain, > >> or define the structure or the semantics for any path component. > >> > >> Unless the intention of this document is to update BCP 190 to change this > >> normative requirement, we can't publish it in its current form. Note that > >> doing > >> so would require a change of venue, as updates to BCP 190 would not be > >> covered > >> by the current TRANS charter. > >> > >> Please see BCP 190 section 3 for alternate approaches. All three approaches > >> could be made to work for CT, and I would be happy to explain how to do so > >> if > >> clarification is desired. > >> > >> While I agree that this is forbidden by BCP 190, this structure is > >> inherited from > >> RFC 6962, which predated 7320, so making that change seems like it's going > >> to be fairly disruptive. This seems like it is falling into our discussion > >> the other > >> day about what must be changed in -bis documents. > >> > >> -Ekr > >> > >> > >> > >> ---------------------------------------------------------------------- > >> COMMENT: > >> ---------------------------------------------------------------------- > >> > >> §1.1: > >> > >>> The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", > >>> "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this > >>> document are to be interpreted as described in [RFC2119]. > >> > >> Consider using the boilerplate from RFC 8174. > >> > >> --------------------------------------------------------------------------- > >> > >> §1.3: > >> > >>> This document revises and obsoletes the experimental CT 1.0 [RFC6962] > >>> protocol, drawing on insights gained from CT 1.0 deployments and on > >>> feedback from the community. > >> > >> Given that *this* document is also experimental, it seems a bit odd to > >> call out > >> RFC 6962 as experimental. > >> > >> --------------------------------------------------------------------------- > >> > >> §2.1.1: > >> > >>> We have established a registry of acceptable hash algorithms (see > >> > >> The use of first person here is awkward. Consider: "This document > >> establishes..." > >> > >> --------------------------------------------------------------------------- > >> > >> §10.2: > >> > >>> | 0x01 - | Unassigned | | Specification | > >>> | 0xDF | | | Required and | > >>> | | | | Expert Review | > >> > >> The policy being cited here is confusing. It is unclear whether the > >> intention is > >> that values can be registered under both §4.5 and §4.6 of RFC 8126. I > >> suspect > >> the intention here is the policy specified in RFC 8126 §4.6 only, without > >> reference to the policy in §4.5. If so, please use the formal name > >> "Specification Required." > >> > >> --------------------------------------------------------------------------- > >> > >> §10.4: > >> > >>> | 0x0008 - | Unassigned | Specification Required and | > >>> | 0xDFFF | | Expert Review | > >> > >> Same comment as above. > >> > >> --------------------------------------------------------------------------- > >> > >> §10.5: > >> > >>> | 0x0000 - | Unassigned | n/a | Specification Required and | > >>> | 0xDFFF | | | Expert Review | > >> > >> Same comment as above. > >> > >> > > > _______________________________________________ Trans mailing list [email protected] https://www.ietf.org/mailman/listinfo/trans
