warning

i'm waiting

[Filename: note.scr, Content-Type: application/octet-stream]
The attachment file in the message has been removed by eManager.

CTP and CARD Drafts

I spoke with Allison and Thomas Narten this week about the Seamoby drafts.
The CTP draft is currently undergoing review by the ROHC WG. The CARD draft
has undergone IESG review. The following list contains the issues and a
suggested resolution.

1) (This issue applies to CTP too) CARD requests allocation of a number of
ICMP type codes. These type codes are limited to 255 total. Since CARD is
experimental, it is possible that it will never be deployed and the type
codes will therefore become unavailable for other protocols that might be
deployed.

Suggested solution: Seamoby will ask IANA for a single type code per IP
version, one for IPv4 and one for IPv6, that is used for all Seamoby ICMP
based protocols. The subtype code will indicate the actual message type.
Seamoby will generate a third draft with IANA instructions (which I
volunteer to author) that the two protocol drafts will refer to.

2) Ted Hardie expressed an objection to the use of multicast. The objection
was that the amount of data that would have to be multicast would be
expected to be large. Also, as is the case with the ICMP types, multicast
would consume an IPv4 multicast address for an experimental protocol that
would probably never be deployed.

Suggested solution: remove multicast from the protocol for initial
publication.

3) Russ Housley gave the following editorial comments:

 Expand 'AP' and 'PCF' the first time they are used.

RE: CTP and CARD Drafts

James,

> I spoke with Allison and Thomas Narten this week about the Seamoby drafts.
> The CTP draft is currently undergoing review by the ROHC WG. 

Just out of curiosity, what is the ROHC WG reviewing CTP for?  

> The CARD draft has undergone IESG review. The following list contains the 
> issues and a suggested resolution.

Was the list just for CARD?

John

Re: CTP and CARD Drafts

> > I spoke with Allison and Thomas Narten this week about the Seamoby
drafts.
> > The CTP draft is currently undergoing review by the ROHC WG.
>
> Just out of curiosity, what is the ROHC WG reviewing CTP for?
>

I believe the intent is to get input from a potential customer of CTP, and
header compression context has always been a top potential customer.

> > The CARD draft has undergone IESG review. The following list contains
the
> > issues and a suggested resolution.
>
> Was the list just for CARD?
>

The only point that specifically applied to CTP as well was the ICMP type
code point. The solution I worked out with Thomas and Allison was one type
code for both protocols, and a separate draft requesting IANA allocation.

I suspect we might see similar comments from the Security ADs about CTP,
since the level of detail in the security design for CTP is approximately
the same as for CARD. I suggest we wait until they've had a chance to review
it first, however, unless I my dialog with them about CARD suggests that
they would be happy with a similar solution.

            jak

RE: CTP and CARD Drafts

Hi James,

> I believe the intent is to get input from a potential customer of CTP, and
> header compression context has always been a top potential customer.

That is what I thought, but I just wanted to make sure.

> > > The CARD draft has undergone IESG review. The following 
> list contains
> the
> > > issues and a suggested resolution.
> >
> > Was the list just for CARD?
> >
> 
> The only point that specifically applied to CTP as well was the ICMP type
> code point. The solution I worked out with Thomas and Allison was one type
> code for both protocols, and a separate draft requesting IANA allocation.

OK.

> I suspect we might see similar comments from the Security ADs about CTP,
> since the level of detail in the security design for CTP is approximately
> the same as for CARD. I suggest we wait until they've had a chance to review
> it first, however, unless I my dialog with them about CARD suggests that
> they would be happy with a similar solution.

Sounds good.  Thanks for the details.

John

RE: CTP and CARD Drafts

Is it customary that a draft is reviewed by another WG before going to IESG?
Would the CTP draft go to IESG after ROHC review?
What if it is not customized enough for Rohc application?

Madjid

-----Original Message-----
From: seamoby-admin <at> ietf.org [mailto:seamoby-admin <at> ietf.org]On Behalf Of
James Kempf
Sent: Thursday, March 04, 2004 2:08 AM
To: seamoby <at> ietf.org
Cc: mankin <at> psg.com
Subject: [Seamoby] CTP and CARD Drafts

I spoke with Allison and Thomas Narten this week about the Seamoby drafts.
The CTP draft is currently undergoing review by the ROHC WG. The CARD draft
has undergone IESG review. The following list contains the issues and a
suggested resolution.

1) (This issue applies to CTP too) CARD requests allocation of a number of
ICMP type codes. These type codes are limited to 255 total. Since CARD is
experimental, it is possible that it will never be deployed and the type
codes will therefore become unavailable for other protocols that might be
deployed.

Suggested solution: Seamoby will ask IANA for a single type code per IP
version, one for IPv4 and one for IPv6, that is used for all Seamoby ICMP
based protocols. The subtype code will indicate the actual message type.
Seamoby will generate a third draft with IANA instructions (which I
volunteer to author) that the two protocol drafts will refer to.

Re: CTP and CARD Drafts

ROHC is considered to be a potential "customer" of CTP, and therefore a
review by ROHC should determine if it would meet their needs. In general,
ADs have an obligation to ensure that a document receives sufficient review
prior to submitting it to the IESG. The ROHC group won't be looking for
specific features to support the ROHC application, but whether they can
build their header compression context transfer on top of CTP.

        jak

----- Original Message ----- 
From: "Nakhjiri Madjid-MNAKHJI1" <Madjid.Nakhjiri <at> motorola.com>
To: "'James Kempf'" <kempf <at> docomolabs-usa.com>; <seamoby <at> ietf.org>
Cc: <mankin <at> psg.com>
Sent: Tuesday, March 09, 2004 2:47 PM
Subject: RE: [Seamoby] CTP and CARD Drafts

> Is it customary that a draft is reviewed by another WG before going to
IESG?
> Would the CTP draft go to IESG after ROHC review?
> What if it is not customized enough for Rohc application?
>
> Madjid
>
> -----Original Message-----
> From: seamoby-admin <at> ietf.org [mailto:seamoby-admin <at> ietf.org]On Behalf Of
> James Kempf
> Sent: Thursday, March 04, 2004 2:08 AM
> To: seamoby <at> ietf.org
> Cc: mankin <at> psg.com
> Subject: [Seamoby] CTP and CARD Drafts

RE: CTP and CARD Drafts

Ok, All makes sense. I am just wondering what the course of action would be
if CTP does not meet Rohc needs?

Madjid

-----Original Message-----
From: James Kempf [mailto:kempf <at> docomolabs-usa.com]
Sent: Tuesday, March 09, 2004 4:56 PM
To: Nakhjiri Madjid-MNAKHJI1; seamoby <at> ietf.org
Cc: mankin <at> psg.com
Subject: Re: [Seamoby] CTP and CARD Drafts

ROHC is considered to be a potential "customer" of CTP, and therefore a
review by ROHC should determine if it would meet their needs. In general,
ADs have an obligation to ensure that a document receives sufficient review
prior to submitting it to the IESG. The ROHC group won't be looking for
specific features to support the ROHC application, but whether they can
build their header compression context transfer on top of CTP.

        jak

----- Original Message ----- 
From: "Nakhjiri Madjid-MNAKHJI1" <Madjid.Nakhjiri <at> motorola.com>
To: "'James Kempf'" <kempf <at> docomolabs-usa.com>; <seamoby <at> ietf.org>
Cc: <mankin <at> psg.com>
Sent: Tuesday, March 09, 2004 2:47 PM
Subject: RE: [Seamoby] CTP and CARD Drafts

> Is it customary that a draft is reviewed by another WG before going to
IESG?

Re: CTP and CARD Drafts

I assume Allison would at that point return the draft to us with their
comments and require us to fix it before sending it to the IESG. She might
edit the comments based on her technical assessment if there were some that
she thought were not appropriate.

            jak

----- Original Message ----- 
From: "Nakhjiri Madjid-MNAKHJI1" <Madjid.Nakhjiri <at> motorola.com>
To: "'James Kempf'" <kempf <at> docomolabs-usa.com>; <seamoby <at> ietf.org>
Cc: <mankin <at> psg.com>
Sent: Tuesday, March 09, 2004 3:21 PM
Subject: RE: [Seamoby] CTP and CARD Drafts

> Ok, All makes sense. I am just wondering what the course of action would
be
> if CTP does not meet Rohc needs?
>
> Madjid
>
> -----Original Message-----
> From: James Kempf [mailto:kempf <at> docomolabs-usa.com]
> Sent: Tuesday, March 09, 2004 4:56 PM
> To: Nakhjiri Madjid-MNAKHJI1; seamoby <at> ietf.org
> Cc: mankin <at> psg.com
> Subject: Re: [Seamoby] CTP and CARD Drafts
>
>
> ROHC is considered to be a potential "customer" of CTP, and therefore a
> review by ROHC should determine if it would meet their needs. In general,

Re: CTP and CARD Drafts

All,

Actually, there's been a little bit of misunderstanding of my message about the
CTP draft, which is easy to have happen, because we were all very busy during
the IETF week.  What I meant was that I had to talk with some ROHC people about CTP,
not that ROHC _WG_ review of the document would be required.  

Why is this?  It's due to some commitment that was made in the Vienna Seamoby 
meeting to deliver Seamoby with a use case, which I understood would probably be
header compression context.  The minutes show an action item to work with Carsten
Bormann to make this concrete.  We discussed the need for the use case that
would describe a context very well defined in IETF, with ROHC header compression
meeting that criterion.  If contexts for context transfer are just open-ended,
and there isn't an clear use case, it's hard to build support for this
protocol in the broader IETF (not only the IESG - we had a lot* of questions
about this charter item when the WG was formed).  

So, I've done a little talking and looking at the document.  The example of a
service that was supposed to be covered in Appendix C is missing.  There is no 
companion document describing a use case.  What's up?

Allison

http://www.ietf.org/proceedings/03jul/index.html