Subject: Re: [secdir] Review of draft-ietf-forces-protocol-16 (now -18)

From: "Uri Blumenthal" <[email-masked]>
Date: Sat, 1 Nov 2008 20:21:18 -0400

1. Apologies for dealying the response - but reply to my comments missed my
"sweet spot" in the schedule and thus had to wait till my next window opens.

2. In general, Security Considerations section of the Architecture document
(RFC 3746) adequately deals with the issue. However RFC3746 is an
INFORMATIONAL document, while this draft seems to claim the STANDARD track.
I think that Standards-track document cannot refer to Informational. If I'm
wrong (and you can) - just rename the existing (unmodified) "Security
Consideration" section to "Security Mechanisms" or such, and add a
one-statement "Security Consideration" that refers the reader to RFC 3746.
If I'm right (that you can refer to Informational), then instead of the text
you're proposing you'd have to copy the entire section from RFC 3746.

-----Original Message-----
From: Avri Doria [mailto:[email-masked]] 
Sent: Thursday, October 30, 2008 11:05
To: Jamal Hadi Salim; Ross Callon
Cc: [email-masked]; Khosravi, Hormuzd M; Robert Haas; Weiming Wang; Patrick
Droz
Subject: Re: Review of draft-ietf-forces-protocol-16 (now -18)

Hi,

Thanks for making my excuses.

Fortunately with your help I was able to get it submitted.
And now off to the airport for a full week of 'fun' with ICANN in Cairo.

a.

On 30 Oct 2008, at 09:48, Jamal Hadi Salim wrote:

> Ross,
>
> We are going to make a very small change and submit. Avri is going to 
> be travelling today and will be overloaded in the next week.
> She may get to it and submit the new version today. Your call on 
> whether you want it in this upcoming call or next if we dont make it 
> in.
>
> The change we are making (which seems sufficient to address Uri's
> concern) is:
>
> ------------------ Protocol draft section 9 -------
>
> 9.  Security Considerations
>
>   ForCES architecture identifies several levels of security in
>   [RFC3746].  ForCES PL uses security services provided by the ForCES
>   TML.  The TML provides security services such as endpoint
>   authentication service, message authentication service and
>   confidentiality service.  Endpoint authentication service is invoked
>   at the time of the pre-association connection establishment phase 
> and
>   message authentication is performed whenever the FE or CE receives a
>   packet from its peer.
> ----------------------------------------------------------------------
> -
>
> suggestion changes to:
>
> -----------
> 9.  Security Considerations
>
>   The ForCES Framework document[RFC3746], section 8, goes into a
>   lot of details and identifies several levels of security
>   challenges. This document does not repeat that discussion, the
>   reader is referred to the  ForCES Framework document[RFC3746]
>   for those details and how ForCES architecture addresses them.
>
>   ForCES PL uses security services provided by the ForCES
>   TML.  The TML provides security services such as endpoint
>   authentication service, message authentication service and
>   confidentiality service.  Endpoint authentication service is invoked
>   at the time of the pre-association connection establishment phase 
> and
>   message authentication is performed whenever the FE or CE receives a
>   packet from its peer.
> ---------------
>
> cheers,
> jamal
>
> On Wed, 2008-29-10 at 11:00 -0400, Ross Callon wrote:
>> Jamal;
>>
>> I think that if you don't hear back by sometime tomorrow, you should 
>> go ahead and post the updated draft and I will put it (and its MIB) 
>> onto the IESG agenda for next week.
>>
>> Thanks, Ross
>
>

_______________________________________________
secdir mailing list
[email-masked]
https://mailman.mit.edu/mailman/listinfo/secdir
_______________________________________________
secdir mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/secdir

---

From: "Ross Callon" <[email-masked]>
Date: Sun, 2 Nov 2008 21:42:15 -0500

Standards track documents can have normative references to informational
documents. However, this needs to be explicitly called out in the IETF
last call. Thus to do this would requiring repeating the last call (it
also requires listing the downref in a registry, but I can take care of
that when putting the document onto an IESG agenda). 

I didn't get this onto the agenda for this week's telechat (My
apologies, I didn't get to it until Friday night, which is too late).
Thus it will need to go onto a telechat very soon after the Minneapolis
IETF. Thus repeating the IETF last call won't slow it down by much. 

Thanks, Ross

-----Original Message-----
From: Jamal Hadi Salim [mailto:[email-masked]] 
Sent: 02 November 2008 20:57
To: [email-masked]
Cc: 'Avri Doria'; Ross Callon; 'Khosravi, Hormuzd M'; 'Robert Haas';
'Weiming Wang'; 'Patrick Droz'; [email-masked]; [email-masked]
Subject: RE: Review of draft-ietf-forces-protocol-16 (now -18)

Hi Uri,

> "sweet spot" in the schedule and thus had to wait till my next window
opens.

Understandable; we all get busy - Thanks for taking the effort to
respond. 

> you're proposing you'd have to copy the entire section from RFC 3746.

I will have to review the rules to be sure. Is rule this documented
somewhere?
Ross, to reiterate/sumarize what Uri is saying above:
The document(RFC 3746) we reference in the security section is
informational. Given the protocol is shooting for standard track it 
cant reference that doc as authoritative and we would have to cutnpaste
the statements made in RFC 3746 into the security section of the
protocol.

I dont think this is a show-stopper for the telechat inclusion; however,
if indeed the above is needed we will make a new release probably after
your telechat which doesnt change really the semantics of the doc
(rather just adds content which was previously being referenced).

cheers,
jamal

---

From: Jamal Hadi Salim <[email-masked]>
Date: Sun, 02 Nov 2008 20:57:00 -0500

Hi Uri,

cheers,
jamal

---

From: Jamal Hadi Salim <[email-masked]>
Date: Mon, 03 Nov 2008 09:51:19 -0500

Ross,

So the choice is either repeating the last call or copying the content?
Since we missed the IESG agenda and we have at least 2 weeks, I dont
mind just adding cutnpasting that content (then we can avoid the downref
altogether).
Thoughts?

cheers,
jamal

---

From: "Ross Callon" <[email-masked]>
Date: Mon, 3 Nov 2008 15:05:16 -0500

In general the problem with copying text is that if you want to update
the text, then you need to update both documents (and you need to be
careful to keep them aligned).

In this particular case, it seems to me that the two documents are very
closely linked, so that it would be necessary to keep them aligned in
any case. 

Ross

-----Original Message-----
From: Jamal Hadi Salim [mailto:[email-masked]] 
Sent: 03 November 2008 09:51
To: Ross Callon
Cc: [email-masked]; Avri Doria; Khosravi, Hormuzd M; Robert Haas; Weiming
Wang; Patrick Droz; [email-masked]; [email-masked]
Subject: RE: Review of draft-ietf-forces-protocol-16 (now -18)

Ross,

cheers,
jamal

---

From: "Ross Callon" <[email-masked]>
Date: Tue, 4 Nov 2008 14:50:20 -0500

A down-ref requires an IETF last call, which I need to request. 

To me it looks like the current draft
(draft-ietf-forces-protocol-18.txt) is not the right one to last call.
Specifically, draft-ietf-forces-protocol-18.txt only has three normative
references, one to the model (which is PS), and two to existing RFCs
that are BCPs. It's reference to the Forces Framework (RFC3746) is
informational. 

Does this mean that you will quickly do an update to the protocol that
moves the reference to RFC3746 to be normative, and then I will repeat
the last call? 

Thanks, Ross

-----Original Message-----
From: Jamal Hadi Salim [mailto:[email-masked]] 
Sent: 04 November 2008 14:34
To: Ross Callon
Cc: [email-masked]; Avri Doria; Khosravi, Hormuzd M; Robert Haas; Weiming

Ok, Ross I suppose a re-issue of the last call may be in order then.
Shall the chair post the LC to the ForCES list only or is 
this something the IESG does at this stage?

cheers,
jamal

---

From: Jamal Hadi Salim <[email-masked]>
Date: Tue, 04 Nov 2008 14:33:47 -0500

cheers,
jamal

---

From: Jamal Hadi Salim <[email-masked]>
Date: Tue, 04 Nov 2008 20:17:04 -0500

> moves the reference to RFC3746 to be normative, and then I will repeat

Sounds reasonable.

I am gonna punt to Avri.
Avri?

cheers,
jamal