Re: [Gen-art] Gen-ART review of draft-ietf-ipsecme-dh-checks-04

["Romascanu, Dan (Dan)" <[e-mail]>]

Hi Yaron,

Thanks for the quick review. I got the feeling that merkle-ikev2-ke-brainpool got stuck anyway, because they are now in RFC Editor Queue waiting for an IANA action which may be exactly the adding the column in the registry as defined by the IANA considerations in this document. As I said, a clean solution would have been better, but this is not a blocking issue. 

Regards,

Dan
 



> -----Original Message-----
> From: Yaron Sheffer [mailto:[e-mail]]
> Sent: Monday, May 13, 2013 2:12 PM
> To: Romascanu, Dan (Dan)
> Cc: General Area Review Team; draft-ietf-ipsecme-dh-
> [e-mail]
> Subject: Re: Gen-ART review of draft-ietf-ipsecme-dh-checks-04
> 
> Hi Dan,
> 
> Thanks for your review!
> 
> We initially chose a cleaner solution which would have required draft
> merkle-ikev2-ke-brainpool to depend on the current one. The authors of
> that other draft requested this change so that they can move forward to
> publication. I agree it's not ideal, but this band-aid allows them to go
> forward while not creating a downref here. And for the long-term (once
> this is published) we have not created too much of a mess...
> 
> Best,
> 	Yaron
> 
> On 2013-05-13 13:30, Romascanu, Dan (Dan) 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-ipsecme-dh-checks-04
> > Reviewer: Dan Romascanu
> > Review Date: 5/13/13
> > IETF LC End Date: 5/20/13
> > IESG Telechat date:
> >
> > Summary:
> >
> > This document is Ready. It is clearly written and easy to follow, even
> for a non-expert in security. I appreciated the sections that describe
> the transition to implementations that support the update and the ones
> that describe behavior upon test failures - which are of value to
> implementers and operators. One minor issue related to the IANA registry
> may be only an issue of clarification.
> >
> > Major issues:
> >
> > Minor issues:
> >
> > The IANA Considerations Sections mention that Groups 27-30 have been
> recently defined in [I-D.merkle-ikev2-ke-brainpool]. This is an
> Informational Reference which is somehow odd, because without this
> reference the IANA actions could not be completed. On the other hand
> making [I-D.merkle-ikev2-ke-brainpool] Normative Reference would create
> a downref because the later is informational. I believe this is OK,
> because I see the document in RFC Editor Queue waiting for IANA actions,
> which may actually be exactly the ones described in this I-D, but a
> cleaner solution would have been not defining at all Groups 27-30 here.
> >
> > Nits/editorial comments:
> >
> >
> >