Hi Ari, Thanks for pointing out the typo! I have just submitted the draft.
Best, --julien On Mon, Feb 24, 2014 at 10:03 AM, Ari Keranen <[email protected]> wrote: > Hi Julien, > > Looks good, thanks. One small typo in section 6: "potetially unknown hosts". > > > Cheers, > Ari > > > On 21/02/14 07:04, Julien Laganier wrote: >> >> Hi Ari, >> >> Thanks for reviewing the draft and suggesting improvements. I have >> incorporated them all in the version-to-be -05, unfortunately the >> deadline has passed so I am attaching it below for your (and the rest >> of the WG) review in case you spot some errors before submission >> reopens. >> >> Cheers, >> >> --julien >> >> >> >> On Fri, Jan 17, 2014 at 6:42 AM, Ari Keranen <[email protected]> >> wrote: >>> >>> Hi Julien, >>> >>> >>> On 1/17/14 5:50 AM, Julien Laganier wrote: >>>> >>>> >>>> Hi Ari, >>>> >>>> On Thu, Jan 16, 2014 at 8:20 AM, Ari Keranen >>>> <[email protected]> >>>> wrote: >>>>> >>>>> >>>>> Hi Julien, >>>>> >>>>> Thanks, that looks good to me. Although reading the draft again, I was >>>>> wondering is it missing some text regarding the "Insufficient >>>>> resources" >>>>> error? >>>> >>>> >>>> >>>> Hmm... a registration failing because of "insufficient resources" is >>>> quite explicit; it conveys enough information for a requester to know >>>> that there are no resources to create a registration at a given >>>> registrar. Presumably a requester would try to register at a different >>>> registrar if it knows one... >>>> >>>> What else would the requester need to know? >>> >>> >>> >>> I mean that it looks a bit strange that there's only an error code >>> defined >>> but no text at all when to use it (even if the name of the code kinda >>> gives >>> it away). I would recommend to add a sentence or two about when/how to >>> use >>> it. >>> >>> I spotted one (copy-paste) error in the draft, section 3.3: >>> >>> If the registrar knows the Host Identities (HIs) of all the hosts >>> that are allowed to use the relaying service, it SHOULD reject >>> registrations from unknown hosts. However, since it may be >>> unfeasible to pre-configure the relay with all the HIs, the relay >>> SHOULD also support HIP certificates [I-D.ietf-hip-rfc6253-bis] to >>> allow for certificate based authentication. >>> >>> This should no longer be "relaying service" and "relay" (2 instances >>> here) >>> but in general the service for which one is registering for. >>> >>> In the figures, at the end of the section, I was wondering why S3 is not >>> announced by the registrar? Also the text is a bit unclear; almost as if >>> RQ >>> would try to register for S1 and S2 even if the figure shows only S1. >>> >>> In section "4.5. REG_FAILED", it says "Failure types other than zero (0) >>> and >>> one (1) have not been defined." This is obviously not true anymore. >>> Perhaps >>> here would be a good place for some text on the insufficient resources >>> error >>> code. >>> >>> And by the way, I guess you can have more than one REG_FAILEDs if there >>> was >>> more than one failure type? The text seems to now imply only single >>> REG_FAILED. >>> >>> Section 6 says: >>> >>> Registrars act on a voluntary basis and are willing to accept being a >>> responder and then to create HIP associations with a number of >>> previously unknown hosts. >>> >>> Now with the HI/cert authentication this has actually improved (you only >>> potentially do things with previously unknown hosts). >>> >>> Otherwise I think the draft is in good shape and could move forward. >>> >>> >>> Cheers, >>> Ari >>> >>> _______________________________________________ >>> Hipsec mailing list >>> [email protected] >>> https://www.ietf.org/mailman/listinfo/hipsec > > > _______________________________________________ > Hipsec mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/hipsec _______________________________________________ Hipsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/hipsec
