Take instruction from your AD. I have cleared… On 05 Mar 2015, at 17:24, Francois Le Faucheur (flefauch) <[email protected]> wrote:
> Hi Jari, > > I have an interim version that addresses part of the IEG review comments (all > the ones for which I have discussed resolution by mail). > Do you prefer that: > * I post that interim version, to allow some folks to clear their > position, OR > * I hold off until I have addressed all/most review comments ? > Whatever is most convenient for you guys. > > Thanks > > 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 >> >
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
