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/ 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
