Re: [secdir] SECDIR review of draft-shin-augmented-pake-10

["SeongHan Shin" <[e-mail]>]

Dear Tina and Tero,

Thank you very much for your comments!
The following changes are reflected to a next version of our I-D.


> I found some editorial glitches and the use of "temporal" when "temporary"
> was intended, but someone else can catch those.
Corrected to "temporary"


> Reference K11 is now RFC 6467. That means the Notify message type and the
> GSPM payload type have now been assigned (16424 and 49 respectively) and
> can be inserted into the document where it currently says "TBD".
I updated reference K11 to RFC6467 and inserted the assigned values into the
document.


> The request to IANA names the wrong registry. The correct name is "IKEv2
> Secure Password Methods" registry, established by RFC 6467.
Corrected.


> > The relationship between this document and RFC 6467 is odd. In the
> > ordinary course of events this document would have a normative
> > dependency on RFC 6467.
> 
> Not exactly. The original intention is that all documents using numbers
> defined in my draft (now RFC6467) would be self-containing, and there
might
> not even be need for publishing my draft as RFC, it was originally just
> written as tool so that all secure password method drafts could coordinate
> their numbers. As it is now published as RFC, I think it is ok to make
either
> normative or non-normative reference to it, depending whether the document
> itself is self-containing or not.
> 
> Currently I think all the secure password method documents are
> self-containing, thus non-normative reference is needed, the implementor
> who is implementing the secure password method in question, does not NEED
> to read RFC6467 to be able to implement for example
> draft-shin-augmented-pake as that draft already contains all information
> needed.
> 
> > It is obvious that the latter was written after the present document,
> > and avoidance of the dependency was deliberate on both sides. Still,
> > the authors of this document might reconsider, even though RFC 6467
> > would be a down-reference since it is Informational.
> 
> The intended status of draft-shin-augmented-pake is listed as
experimental,
> so there really a down-reference problem there?
> 
> Anyways as draft-shin-augmented-pake self-contained, the reference can be
> non-normative.
Thanks, Tero!
I just keep reference RFC6467 in non-normative.


Best regards,
Shin


------------------------------------------------------------------
SeongHan Shin
Research Center for Information Security (RCIS),
National Institute of Advanced Industrial Science and Technology (AIST),
Central 2, 1-1-1, Umezono, Tsukuba City, Ibaraki 305-8568 Japan
Tel : [phone]
Fax : [phone]
E-mail : [e-mail]
------------------------------------------------------------------


> -----Original Message-----
> From: Tero Kivinen [mailto:[e-mail]]
> Sent: Friday, January 27, 2012 10:51 PM
> To: Tina TSOU
> Cc: [e-mail]; [e-mail]
> Subject: [secdir] SECDIR review of draft-shin-augmented-pake-10
> 
> Tina TSOU writes:
> > The relationship between this document and RFC 6467 is odd. In the
> > ordinary course of events this document would have a normative
> > dependency on RFC 6467.
> 
> Not exactly. The original intention is that all documents using numbers
> defined in my draft (now RFC6467) would be self-containing, and there
might
> not even be need for publishing my draft as RFC, it was originally just
> written as tool so that all secure password method drafts could coordinate
> their numbers. As it is now published as RFC, I think it is ok to make
either
> normative or non-normative reference to it, depending whether the document
> itself is self-containing or not.
> 
> Currently I think all the secure password method documents are
> self-containing, thus non-normative reference is needed, the implementor
> who is implementing the secure password method in question, does not NEED
> to read RFC6467 to be able to implement for example
> draft-shin-augmented-pake as that draft already contains all information
> needed.
> 
> > It is obvious that the latter was written after the present document,
> > and avoidance of the dependency was deliberate on both sides. Still,
> > the authors of this document might reconsider, even though RFC 6467
> > would be a down-reference since it is Informational.
> 
> The intended status of draft-shin-augmented-pake is listed as
experimental,
> so there really a down-reference problem there?
> 
> Anyways as draft-shin-augmented-pake self-contained, the reference can be
> non-normative.
> --
> [e-mail]