Hi Tom, Thank you for the WGLC review. Please see inline the proposed resolution of your WGLC comments.
--julien On Tue, Jun 2, 2015 at 12:45 PM, Tom Henderson <[email protected]> wrote: > I discovered recently that my email this year to the HIPSEC list has not been > making it to the list, and I haven't been able to resolve the issue, so I > will start to send from a different address. > > Below, please find some comments on the RFC5203-bis draft that I sent on May > 11. > > - Tom > > On 04/24/2015 03:09 AM, Gonzalo Camarillo wrote: >> Hi, >> >> I would like to start a WGLC on the following draft. This WGLC will end >> on May 11th: >> >> https://datatracker.ietf.org/doc/draft-ietf-hip-rfc5203-bis/ >> >> Please, send your comments to this list. > > Gonzalo and Julien, I had a fresh read of this document and it looks > ready, aside from the following small comments. > > - Tom > > p.3 s/registration type implicated/registration type requested/ done. > p.4 "A host that is capable and willing to act as a registrar SHOULD > include a REG_INFO parameter in the R1 packets it sends during all > base exchanges." Shouldn't this be constrained to include REG_INFO > only to those hosts to which it wants to offer services (i.e. it may not > offer such services to all peers that it talks to)? Makes sense. I have adjusted the text to read: A host that is capable and willing to act as a registrar vis-a-vis a specific requester SHOULD include a REG_INFO parameter in the R1 packets it sends during all base exchanges with that requester. > p.4 s/unfeasible/infeasible done. > p.9 what is the purpose of including minimum and maximum lifetime in > the REG_INFO, when it can be seemingly disregarded by the registrar? > > The requester MUST be prepared to receive any registration lifetime, > including ones beyond the minimum and maximum lifetime indicated in > the REG_INFO parameter. It MUST NOT expect that the returned > lifetime will be the requested one, even when the requested lifetime > falls within the announced minimum and maximum. > > wouldn't it be easier to just have the requester just submit its > request, and accept whatever the registrar gives it (which it has to do > anyway)? Else, please clarify what a requester should do with the > min/max provided by the REG_INFO. The min/max lifetime in the the REG_INFO are offered by the registrar to the requester as guidance w.r.t. to the interval of lifetimes that are currently acceptable to the registrar. The provision that the requester be prepared to deal with a registration lifetime that is not within the previously advertized interval makes the protocol robust against a change of the acceptable interval between its advertisement in REG_INFO and the registration being requested and granted in REG_REQ/RESP exchange. I've added to the REG_INFO parameter description the following paragraph to clarify what the requester should do with these values. The registrar indicates the minimum and maximum registration lifetime that it is willing to offer to a requester. A requester SHOULD NOT request registration with lifetime greater than the maximum registration lifetime or smaller than the minimum registration lifetime. > p.11 In the IANA section, I think that you want to instead request that > IANA replace references to RFC 5203 to with references to this document, > and to allocate two new Registration Failure Type codes for these new ones: > > [TBD-IANA] Insufficient resources > [TBD-IANA] Invalid certificate done: This document updates the IANA Registry for HIP Parameters Types by replacing references to [RFC5203] by references to this document. This document also updates the registry for registration failure types by making the following failure type definitions and reservations: Failure Type Reason ------------ -------------------------------------------- [TBD-IANA] Insufficient resources [TBD-IANA] Invalid certificate _______________________________________________ Hipsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/hipsec
