Subject: Re: ID Tracker State Update Notice: draft-ietf-opes-ocp-core

From: Alex Rousskov <[email-masked]>
Date: Thu, 2 Sep 2004 09:46:53 -0600 (MDT)

FYI: It looks like we need to wait another IESG telechat cycle since 
Steve Bellovin excersized a "Defer" option to review the latest draft 
changes (published in May). Steve's DISCUSS is the last DISCUSS we 
need to clear.

FWIW, ID Tracker description of "Defer" says that it can only be 
invoked the first time the document comes up for discussion during a 
telechat. Since this is the second telechat for OCP Core, I am 
guessing that the rule applies to each revision of the document.
https://datatracker.ietf.org/public/pidtracker.cgi?command=view_state_desc&id=21

There is also a new problem recorded by Bill Fenner (without the 
corresponding DISCUSS): OCP Core syntax cannot be fully expressed 
using ABNF. ABNF cannot express an "n octets" rule where "n" is 
determined dynamically.

Since it is not a DISCUSS, I would leave the BNF "as is" because the 
offending rule is essentially a free-flow comment (from ABNF point of 
view), and we have no better way of expressing this, short of 
extending ABNF.

Alex.

On Thu, 2 Sep 2004, The IESG wrote:

> 'State Changes to IESG Evaluation - Defer from IESG Evaluation::AD Followup by Steve Bellovin'
> ID Tracker URL: https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=10380&rfc_flag=0
>
>

---

From: Ted Hardie <[email-masked]>
Date: Thu, 2 Sep 2004 12:33:00 -0700

Actually, Steve simply wanted to hold the document open for
discussion, since there were some things he wanted to dig
through further; the IESG doesn't use DEFER for that (it just continues
the discussion), but it was very, very early in the morning in
Australia when he pushed the button and he forgot.  He and
I hope to circle up on it next week.

We did have a short discussion of the registry requirements, though,
and it would help IANA if we mocked up what an entry in the
registry would look like, so they can prepare the registry when it
goes to them.  Also, is there an available validator for
PETDM, or is this something the expert will validate?

On the ABNF issue, if there is a different flavor of BNF which can
express the "n octets" rule, we can switch the reference; the
IESG doesn't mind folks using different flavors of notation, it
just needs the citations to match.  If there is no flavor of
BNF that matches, we can say "expressed in ABNF, except for
the "n octets rule"", which is a kludge, but will probably work.
		regards,
			Ted Hardie

At 9:46 AM -0600 9/2/04, Alex Rousskov wrote:
>Steve Bellovin excersized a "Defer" option to review the latest 
>draft changes (published in May). Steve's DISCUSS is the last 
>DISCUSS we need to clear.
>
>offending rule is essentially a free-flow comment (from ABNF point 
>of view), and we have no better way of expressing this, short of 
>extending ABNF.
>
>Alex.
>
>>ID Tracker URL: 
>>https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=10380&rfc_flag=0

---

From: Alex Rousskov <[email-masked]>
Date: Thu, 2 Sep 2004 14:05:49 -0600 (MDT)

On Thu, 2 Sep 2004, Ted Hardie wrote:

> discussion, since there were some things he wanted to dig through 
> further; the IESG doesn't use DEFER for that (it just continues the 
> discussion), but it was very, very early in the morning in Australia 
> when he pushed the button and he forgot.  He and I hope to circle up 
> on it next week.

That explains, and thank you for watching over the discussion.

> and it would help IANA if we mocked up what an entry in the registry 
> would look like, so they can prepare the registry when it goes to 
> them.

I would be happy to create an example, probably using a real entry 
from OCP/HTTP profile. Where should I send it once it is discussed by 
the WG?

> Also, is there an available validator for PETDM, or is this 
> something the expert will validate?

I doubt PETDM is formal[ized] enough to automate validation. If PETDM 
happens to be useful, we probably would be able to judge whether 
further fomalization makes sense. For now, it is just a semi-formal 
mnemonic requiring human interpretation. Expert validation would be 
required.

> express the "n octets" rule, we can switch the reference; the IESG 
> doesn't mind folks using different flavors of notation, it just 
> needs the citations to match.  If there is no flavor of BNF that 
> matches, we can say "expressed in ABNF, except for the "n octets 
> rule"", which is a kludge, but will probably work.

I do not know of any *BNF that allows dynamic rules (other than via 
comments). Moreover, since *BNF notations vary, simply switching 
references will most likely not be possible. How about replacing the 
offending

 	data = size ":" <n>OCTET                 ; n == size

rule with ABNF compliant

 	data = size ":" *OCTET         ; exactly size octets

rule. This change can be done via Editor Note, I think. Would that 
work?

Thank you,

Alex.

>> FYI: It looks like we need to wait another IESG telechat cycle since Steve 
>> Bellovin excersized a "Defer" option to review the latest draft changes 
>> (published in May). Steve's DISCUSS is the last DISCUSS we need to clear.
>> 
>> FWIW, ID Tracker description of "Defer" says that it can only be invoked 
>> the first time the document comes up for discussion during a telechat. 
>> Since this is the second telechat for OCP Core, I am guessing that the rule 
>> applies to each revision of the document.
>> corresponding DISCUSS): OCP Core syntax cannot be fully expressed using 
>> ABNF. ABNF cannot express an "n octets" rule where "n" is determined 
>> dynamically.
>> 
>> view), and we have no better way of expressing this, short of extending 
>> ABNF.
>> 
>> Alex.
>>

---

From: Ted Hardie <[email-masked]>
Date: Thu, 2 Sep 2004 13:14:32 -0700

At 2:05 PM -0600 9/2/04, Alex Rousskov wrote:
>from OCP/HTTP profile. Where should I send it once it is discussed 
>by the WG?

[email-masked], cc'ing me would be great; thanks.

>I doubt PETDM is formal[ized] enough to automate validation. If 
>PETDM happens to be useful, we probably would be able to judge 
>whether further fomalization makes sense. For now, it is just a 
>semi-formal mnemonic requiring human interpretation. Expert 
>validation would be required.

Okay.

>rule. This change can be done via Editor Note, I think. Would that work?
>
>Thank you,
>
>Alex.

I think it could be done via an editor note, if the wg is okay with the change.
			regards,
				Ted Hardie

>>>FYI: It looks like we need to wait another IESG telechat cycle 
>>>since Steve Bellovin excersized a "Defer" option to review the 
>>>latest draft changes (published in May). Steve's DISCUSS is the 
>>>last DISCUSS we need to clear.
>>>
>>>invoked the first time the document comes up for discussion during 
>>>a telechat. Since this is the second telechat for OCP Core, I am 
>>>Since it is not a DISCUSS, I would leave the BNF "as is" because 
>>>the offending rule is essentially a free-flow comment (from ABNF 
>>>point of view), and we have no better way of expressing this, 
>>>short of extending ABNF.
>>>
>>>Alex.
>>>
>>>>'State Changes to IESG Evaluation - Defer from IESG 
>>>>Evaluation::AD Followup by Steve Bellovin'
>>>>ID Tracker URL:

---

From: Tony Hansen <[email-masked]>
Date: Thu, 02 Sep 2004 16:29:58 -0400

looks good to me

	Tony Hansen

---

From: Alex Rousskov <[email-masked]>
Date: Tue, 7 Sep 2004 16:22:12 -0600 (MDT)

On Thu, 2 Sep 2004, Alex Rousskov wrote:

>> We did have a short discussion of the registry requirements, 
>> though, and it would help IANA if we mocked up what an entry in the 
>> goes to them.
> from OCP/HTTP profile.

To refresh your memory, OCP Core, the IANA Considerations section, 
says

     The IANA maintains a list of OCP features, including
     application profiles (Section 10.11). For each feature, its
     "uri" parameter value is registered along with the extension
     parameters (if any). Registered feature syntax and semantics
     are documented using PETDM notation.

     Standards-track OCP Core extensions SHOULD use
     "http://iana.org/assignments/opes/ocp/" prefix for feature
     "uri" parameters.  It is suggested that the IANA populates
     resources identified by such "uri" parameters with
     corresponding feature registrations.  It is also suggested
     that the IANA maintains an index of all registered OCP
     features at http://iana.org/assignments/opes/ocp/ URL or on a
     page linked from that URL.

Here is an example of how IANA could register a "request profile" 
feature described in draft-ietf-opes-http-02.txt (the unincorporated 
IANA Section of that draft requests such a registration).

First, IANA may put the following text and links to
http://iana.org/assignments/opes/ocp

     This is the master index of the IANA-registered features for
     OPES Callout Protocol Core standard
     [http://www.ietf.org/rfc/rfcOcpCore.txt]

     * HTTP adaptation with OPES features
       [http://iana.org/assignments/opes/ocp/http]

Second, IANA may add the following text and links to
http://iana.org/assignments/opes/ocp/http

     HTTP adaptation with OPES features standard
     [http://www.ietf.org/rfc/rfcOcpHttp.txt] defines the following
     features:

     * "request profile"
       [http://iana.org/assignments/opes/ocp/http/request]

     * "response profile"
       [http://iana.org/assignments/opes/ocp/http/response]

Finally, IANA may add the following text to 
http://iana.org/assignments/opes/ocp/http/request

     This is a registration page for an OPES Callout Protocol feature
     described below.

     URI:        http://iana.org/assignments/opes/ocp/http/request
     Name:       request profile
     Definition: see Section 3.2 of rfcOcpHttp

The above does not include "up" links and other non-essential 
information that IANA may want to add to these pages.

Any improvement suggestions or objections?

Thanks,

Alex.