Subject: [Gen-art] Gen-ART LC review of draft-ietf-tls-srp-14.txt

From: Brian E Carpenter <[email-masked]>
Date: Mon, 09 Jul 2007 17:23:39 +0200

(I don't believe the small issue I mention in this review really needs
to be copied to the IETF list.)

_______________________________________________
Gen-art mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/gen-art

---

From: Trevor Perrin <[email-masked]>
Date: Mon, 09 Jul 2007 09:45:29 -0700

Brian E Carpenter wrote:

> I note that intended status is Informational but there is a list of Normative
> references. That's OK, but note that the key reference [SRP-6] is in fact 
> Informative and is not even directly available at the given URL. I'm
> not sure this is OK for independent implementors (and it would clearly
> not be OK as Proposed Standard).

Hi Brian, all,

All the details from the SRP-6 paper needed to implement this draft are included in the draft.  That's why we decided that making the reference informational was OK.

Since the SRP-6 paper was not published elsewhere, the P1363.2 submission was the most stable way to reference it.  Thus we followed the example of RFC 3447, reference 5, for referring to a P1363 submission, and giving the URL of P1363.

Eventually, IEEE P1363.2 should issue as an IEEE standard that includes SRP-6.  If the TLS/SRP document is revisited later (perhaps for a move from informational -> standards track), we could change the reference to IEEE Std P1363.2 for SRP-6.  

But for now, I think this is the best we can do.

Trevor

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 10 Jul 2007 14:00:20 +0200

On 2007-07-09 18:45, Trevor Perrin wrote:
>> references. That's OK, but note that the key reference [SRP-6] is in 
>> fact Informative and is not even directly available at the given URL. I'm
> All the details from the SRP-6 paper needed to implement this draft are 
> included in the draft.  That's why we decided that making the reference 
> informational was OK.

OK, that wasn't clear to someone without access to [SRP-6] so if
you revise the draft for any reason, I suggest stating that clearly
the first place you refer to [SRP-6].

Thanks

    Brian
> 
> Since the SRP-6 paper was not published elsewhere, the P1363.2 
> submission was the most stable way to reference it.  Thus we followed 
> the example of RFC 3447, reference 5, for referring to a P1363 
> submission, and giving the URL of P1363.
> 
> Eventually, IEEE P1363.2 should issue as an IEEE standard that includes 
> SRP-6.  If the TLS/SRP document is revisited later (perhaps for a move 
> from informational -> standards track), we could change the reference to 
> IEEE Std P1363.2 for SRP-6.