My additions to Jouni's review since I am also assigned INT directorate reviewer for draft-ietf-hip-rfc6253-bis-05: The document reads well, appreciate that. Generic problem: I see how the requester and the registrar can cancel registrations, but is unclear how a registrar can withdraw a service. I think this should be clarified before publication, with possibly a validation from the WG. More detailed stuff: 3. HIP Registration Extension Overview This document does not specify the means by which a requester discovers the availability of a service, or how a requester locates a registrar. >> The fact that the lookup is not included in the method means potentially an additional round trip than if R1 could be send to some anycast address (like DHAAD is in MIPv6). 3.1. Registrar Announcing Its Ability A requester 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. Also, the R1 could contain a certificate and a some signed stuff that includes I1 to prove it is whom the requester thinks. >> Why is this a SHOULD? I expected a MUST otherwise nothing happens, right? >> I mean, the potential not to do it is contained in the words capable and willing. If services can be provided later, it SHOULD send UPDATE packets indicating the current set of services available in a new REG_INFO parameter to all hosts it is associated with. >> And if the registrar is no more capable (maybe temporarily) SHOULD it also UPDATE with a REG_INFO? If the requester does not have any suitable certificates, it SHOULD send the registration request without the CERT parameter to test whether the registrar accepts the request based on the host's identity. >> The Registrar could have hinted the required Authentication method in R1, per service type if needed. >> This is wasting a round trip if the host does not have a certificate and has to try multiple registrars in a row. the registrar MUST proceed with the registration. >> MUST looks strong language now; e.g. what of the registrar can no more for whatever reason? >> I'd not have expected lowercase "may". Failure Type 0 >> Not that I mind so much but sometime it is good to avoid the value '0'. >> This makes software easier to test (did my code write the damn field ?) etc... If the registrar requires further authorization and the requester has additional credentials available, the requester SHOULD try to register again with the service after the HIP association has been established. >> again the uppercase is not necessarily warranted. A lowercase "may" would do. >> It may have other options like going somewhere else. The requester MUST NOT include more than one REG_REQUEST parameter in its I2 or UPDATE packets, while the registrar MUST be able to process one or more REG_REQUEST parameters in received I2 or UPDATE packets. >> Is this me or is the 'or more' is pointless? >> the registrar receiving more than one REG_REQUEST is a protocol error and the traditional way is to drop the packet. The minimum lifetime both registrars and requesters MUST support is 10 seconds, while they SHOULD support a maximum lifetime of 120 seconds, at least. >> I agree that there needs to be boundaries. But this text looks inconsistent with: The requester MUST be prepared to receive any registration lifetime, including ones beyond the minimum and maximum lifetime indicated in the REG_INFO parameter. A zero lifetime is reserved for canceling purposes. >> This text should be in section 4.1 I hope this helps, Pascal > -----Original Message----- > From: Int-dir [ mailto:int-dir-bounces at ietf.org] On Behalf Of Jouni Korhonen > Sent: mardi 24 novembre 2015 18:29 > To: ; draft-ietf-hip-rfc6253- > bis at tools.ietf.org; Bernie Volz (volz) > Subject: [Int-dir] Int-Dir review of draft-ietf-hip-rfc6253-bis-05 > > I reviewed this document as part of the Int-Dir reviews activity. You should treat > the comments as any IETF LC comments. > > The document is ready for piblication with minor nits. My comments follow the > line numbering as seen in IDnits. > > Editorial Comments: > > * Line 28: s/extends/updates > * Line 72: s/extends/updates > * Line 269: replaces or obsoletes.. typically when following the > cover page terminology I would prefer "obsoletes" here as well. > * Line 287: a verb is missing? e.g. "..are discussed.." etc > * Lines 264-265: I cannot parse this sentence. "in order" meanning > the 2 octets contain first Cert Group and followed by Cert ID? > Please clarify. > * Figure line 136: although text is clear about the padding > behavior the figure makes one think there is always 2 octets > of padding.. suggest coming up with slightly different ascii > art here. > > Other (substantial) comments: > > * Lines 95-98: I find the recommendation of not including the CERT > in the I1 packet odd. Actually, allowing it in I1 is a bit odd in > general. A well behaving initiator would not do that unless it has > a very good reason to do so but a hostile initiator would most > certainly do that just to cause more processing at the responder. > Why the CERT has to be possible in I1 if it is not recommended to > be added in the first place? > * Lines 103-14: The "MUST be set" text is a bit strange. Why not > stating the same for Cert ID and type as well? Actually as these > fields are in fixed positions and cannot be "optionally" left out. > I suggest doing some rewording here. > * Section 7 security considerations does not discuss the possible > hostile use of CERT payload in I1 packet.. this is already hinted > in Section 2. > > - Jouni > > _______________________________________________ > Int-dir mailing list > Int-dir at ietf.org > https://www.ietf.org/mailman/listinfo/int-dir