Hello Jari, I have responded to Klaas, Adrian and Richard’s comments.
I have not yet worked on the gen-art comments but will get onto those next. Thanks everyone for working on our document. Francois > On 5 Mar 2015, at 12:14, Jari Arkko <[email protected]> wrote: > > Thanks for your detailed review, Martin, and for your work on this important > document, Francois. Where are we with the updates? I chose to hold a Discuss > on the IESG telechat to ensure that a couple of things are resolved. But if > you already have changed text, I could clear. > > Jari > > On 16 Feb 2015, at 17:16, Francois Le Faucheur (flefauch) > <[email protected]> wrote: > >> Hi, >> >> Thank you Martin. >> We are working on this. >> >> Francois >> >>> On 12 Feb 2015, at 02:24, Martin Thomson <[email protected]> wrote: >>> >>> And because I hit send too soon, here's more... >>> >>> I think that this is ready. I have a couple of major concerns: >>> >>> Major General 1. >>> >>> However, I would like to see more consideration given to forward >>> compatibility. There are a lot of normative statements regarding what >>> MUST be included in the file, but no actions described for a receiver. >>> That means that it is hard to establish expectations regarding file >>> format evolution. If the file is rejected when the version isn't >>> "CDNI/1.0", then that makes changes to that field impossible (and the >>> specification of ABNF for it somewhat pointless). >>> >>> Major Specific 2. >>> >>> An implementation of the CDNI Logging interface MUST support the >>> TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 cipher suite ( [RFC5288]). >>> >>> Please don't do that. There are mandatory to implement cipher suites >>> in all the specs you cite and you don't need anything special here. I >>> have no problem with recommending PFS suites, but you might be better >>> served there by citing the uta TLS usage draft: >>> https://tools.ietf.org/html/draft-ietf-uta-tls-bcp >>> >>> S 3.4.1 >>> o cs(<HTTP-header-name>): >>> HTTP header fields, esp. in HTTP/2 can contain HTAB, even if that >>> isn't permitted by the grammar. You probably want to describe how >>> that is handled. >>> >>> Bottom of P33 (won't adding the established-origin directive >>> invalidate the MD5? What do you expect to happen there? (I see two >>> choices, it would help if you could even *hint* at what you would >>> prefer implementations to do). >>> >>> Nit: HTTP/2 not HTTP/2.0 >>> >>> Question: There is no mention made of range requests, for which this >>> might be well suited, particularly if files get large. >>> >>> I note the privacy considerations are pretty reasonable. I'd be much >>> happier if IP anonymization were not optional though. >>> >>> >>> >>> On 12 February 2015 at 12:02, Martin Thomson <[email protected]> >>> wrote: >>>> I am the assigned Gen-ART reviewer for this draft. For background on >>>> Gen-ART, please see the FAQ at >>>> >>>> <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>. >>>> >>>> Please resolve these comments along with any other Last Call comments >>>> you may receive. >>>> >>>> Document: draft-ietf-cdni-logging-15 >>>> Reviewer: Martin Thomson >>>> Review Date: 2015-02-12 >>>> IETF LC End Date: 2015-02-18 >>>> IESG Telechat date: (if known) >>>> >>>> Summary: >>>> >>>> Major issues: >>>> >>>> Minor issues: >>>> >>>> S3.1 needs to define the basic atom that is used for the logging file. >>>> It appears as though the atom is an octet. >>>> >>>> S3.2 uses the wildcard ABNF rule (i.e., <text....>) too aggressively. >>>> RECLINE (a potentially confusing name) could be more strictly defined. >>>> >>>> <CDNI Logging File> = 1*<DIRGROUP RECGROUP> >>>> >>>> ... is not valid and could be: >>>> >>>> CDNI-LOG-FILE = 1*(DIRGROUP / RECGROUP) >>>> >>>> That implies that an empty file is not valid. I'd have thought that * >>>> rather than 1* would be better. >>>> >>>> S3.3 again uses wildcard rules too aggressively. DIRNAME (not the >>>> unix command) should be defined more explicitly, even if it is just to >>>> specify what characters are allowed. Use text to further constrain >>>> it. As it stands, a generic processor cannot know that the name >>>> doesn't permit the inclusion of (for instance) ":" or CRLF. A common >>>> method is to define something like this as: >>>> >>>> DIRNAME = Version-directive / UUID-directive / ... / extension-directive >>>> >>>> More commonly, go up a level and define directive using the choice. >>>> That way, each directive can define a name and value together using >>>> ABNF. e.g. >>>> >>>> Version-directive = "Version" ":" HTAB "CDNI" "/" 1*DIGIT "." 1*DIGIT >>>> >>>> I wouldn't be so prescriptive about the version format. Unless there >>>> are specific semantics you want to extract from each digit. >>>> >>>> What is a receiver expected to do if the version *isn't* CDNI/1.0 ? >>>> Discard the entire file? That doesn't seem like a good way to ensure >>>> forward compatibility. >>>> >>>> UUID: this a Universally Unique IDentifier (UUID) >>>> from the UUID Uniform Resource Name (URN) namespace specified >>>> in [RFC4122]) for the CDNI Logging File. >>>> >>>> I don't know how to apply this. Is it the UUID portion of the URN or a >>>> URN? >>>> >>>> Please don't use MUST here: If the >>>> two values are equal, then the received CDNI Logging File MUST >>>> be considered non-corrupted. >>>> >>>> MD5 collisions are easy to manufacture. I'd also drop the MUST from >>>> the following sentence. >>>> >>>> S3.4: more wildcards >>>> >>>> S3.4.1: I wouldn't worry about HTTP/2 being special here. All that >>>> speculation is painful, especially since HTTP/2 will likely be >>>> published before this document. Better to just cite it and avoid >>>> getting caught up in the details. >>>> >>>> >>>> >>>> >>>> Nits/editorial comments: >>>> >>>> There are lots of uses of lowercase "may". >>>> >>>> Page 6 has a few instances of missing hyphens in dCDN3/dCDN2 etc... >>>> S6.2.1: chunck >>>> >>>> S3.1 the DATE/TIME rules can/should reference RFC 3339 >>>> >>>> S3.3 using ":" HTAB as a separator makes it hard to construct these >>>> files manually. >>>> >>>> S3.4 use of "c:" in combination with the unordered list is confusing >>>> when the prefix is actually "c-". Maybe use the string "c-" quotes >>>> and all to denote the prefix. >>>> >>>> S3.4.1 citing RFC 7230 is sufficient for HTTP/1.1; and probably for >>>> HTTP in general at this moment. >> >> _______________________________________________ >> Gen-art mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/gen-art > _______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
