Subject: [clue] draft-ietf-clue-protocol-06: stuff found while preparing submission writeup [RESEND]

From: Paul Kyzivat <[email-masked]>
Date: Tue, 9 Feb 2016 11:33:39 -0500

[I first sent this on December 1. I could swear I had a reply from Simon 
promising a new version. But I now cannot find any evidence of such a 
reply. And -06 is still the most recent version of the protocol.]

I did another final review of the protocol draft while doing my shepherd 
writeup. Unfortunately I found a number of things that ought to be 
cleared up before submitting to the iesg. I'm sorry about this - I ought 
to have caught these things sooner.

* Section 4:

Section 4 says sequence numbers are incremented for each message. Does 
something say what number the first message gets? I haven't seen 
anything. Does that mean that the first message can have any number?

I don't think anything says whether version numbers are to be compared 
textually or numerically. In particular, are "1.2", "01.2", "1.02", and 
"01.02" all considered to match?

And then:

    Each CP should manage up to three (independent) streams of sequence
    numbers: ...

Why is "should" used here? It seems to me it is a logical necessity. So 
wouldn't "needs to" be more appropriate?

* Section 4.1:

    ... Only one <version> element MUST
    be provided for each major version supported, containing the maximum
    minor version number of such a version, since all minor versions are
    backward compatible.

I don't know how to parse this. I *think* you mean "*Exactly* one ...".

* Section 4.5:

    The optional boolean <ack> element, set to "true", if present,
    indicates that the CONF message also acknowledges the referred
    advertisement, by applying in that way a piggybacking mechanism for
    simultaneously acknowledging and replying to the ADV message.  In the
    above case, the CONF message MUST carry a 200 (Success) response
    code.  The <ack> element MUST not be present if an ACK message has
    been already sent back to the MP.

The above says that if <ack> is present then 200 response code must also 
be present. But I see no place to put a response code in the CONF message.

I think what is intended is that a CONF with <ack> *implies* a 200 
response code for the ADV.

* Section 4.7:

What code should be used for problems that don't seem to fit any of the 
ones listed? For instance, what if a CONF contains <ack> but the 
advertisement had previously been acknowledged? (Would 301 apply to that?)

In SIP, the n00 codes are catch-alls, while other nXX are more specific. 
Here the n00 values are specific. For the inappropriate <ack> I would 
expect 400 to work, but its definition doesn't work.

Doing that allows the recipient of nXX that it doesn't understand to 
treat it as n00. That isn't really possible now. So ISTM that 300 & 400 
ought to be redefined as "syntax errors or inconsistencies", and 400 as 
"semantic errors". And then new specific error codes assigned for "The 
XML syntax is not correct" and "Version not supported".

* Section 5:

s/both send a receive/both send and receive/

* Section 7:

I don't think it is clear what is to be done when a higher minor version 
is supported by one end than the other. According to paragraph three the 
end at the higher version should be able to sent that unchanged, while 
the other end ignores the parts it doesn't understand. According to 
paragraph 4 it seems that the end with the higher version should censor 
itself down to the lower version. (Which means that it needs to keep 
track of what has to be omitted.)

ISTM the document ought to state the required behavior. My thought is 
that it be REQUIRED to ignore unknown elements and attributes. That 
seems like the easier way to manage the version incompatibility. (Of 
course it would also be ok for the end with the higher version to censor 
itself, but that should be optional.)

It seems that paragraph five was hopeful thinking and hasn't been 
realized. At this point it probably ought to be removed.

* Section 8:

I don't understand how the version element in an option is intended to 
work. If an option is defined for version M.m, does it also apply to 
other versions? I guess it ought to apply to later minor versions of the 
same major version.

If I had an option that will work with more than one major version, how 
would I declare it? I can't list more than one version for it. So I 
guess I have to declare it as more than one option element. Can those be 
identical except for the version? Or do they require different names?

In the OPTIONS RESPONSE, does the version need to be identical to what 
was in the request?

* Section 11.3:

Is see "File extension(s): .clue," declared. To do that, wouldn't we 
need to register the extension somewhere? Do we need this? wouldn't .xml 
be sufficient?

* Section 11.4:

Why are we registering new NAPTR tags? AFAIK we don't need or use them.

* Section 11.5.1:

How should the registry be formatted? Is it one column, or two? And what 
is their significance?

I guess the part in parens is an optional abbreviation. But neither part 
is actually used in the protocol, only in the text of the document. The 
actual names used in the protocol are defined in the schema: "options", 
"optionsResponse", "advertisement", "ack", "configure", "configureResponse".

I guess *those* names would be the ones that ought to be registered, if 
any. But do they need to be registered at all? They are defined in the 
schema. If more are defined, won't they be in another version of the 
*same* schema?

* I previously noted that idnits returns a bunch of errors that need to 
be fixed. All are superficial.

* Typos:

s/seperate/separate/
(I've heard this is the most common spelling error in English.)

	Sorry about this,
	Paul

---

From: Simon Pietro Romano <[email-masked]>
Date: Tue, 9 Feb 2016 18:23:00 +0100

Hi Paul,

> [I first sent this on December 1. I could swear I had a reply from Simon promising a new version. But I now cannot find any evidence of such a reply. And -06 is still the most recent version of the protocol.]

You’re not committing perjury :-). And I actually promised a new version. We have worked on the data model before moving to the protocol, for which we’re currently preparing the -07 version. Sorry for being late on this. We’ll try and give a boost in the next few days.

Cheers,

Simon

> 
> I did another final review of the protocol draft while doing my shepherd writeup. Unfortunately I found a number of things that ought to be cleared up before submitting to the iesg. I'm sorry about this - I ought to have caught these things sooner.
> 
> * Section 4:
> 
> Section 4 says sequence numbers are incremented for each message. Does something say what number the first message gets? I haven't seen anything. Does that mean that the first message can have any number?
> 
> I don't think anything says whether version numbers are to be compared textually or numerically. In particular, are "1.2", "01.2", "1.02", and "01.02" all considered to match?
> 
> And then:
> 
> Why is "should" used here? It seems to me it is a logical necessity. So wouldn't "needs to" be more appropriate?
> 
> * Section 4.1:
> 
> The above says that if <ack> is present then 200 response code must also be present. But I see no place to put a response code in the CONF message.
> 
> I think what is intended is that a CONF with <ack> *implies* a 200 response code for the ADV.
> 
> * Section 4.7:
> 
> What code should be used for problems that don't seem to fit any of the ones listed? For instance, what if a CONF contains <ack> but the advertisement had previously been acknowledged? (Would 301 apply to that?)
> 
> In SIP, the n00 codes are catch-alls, while other nXX are more specific. Here the n00 values are specific. For the inappropriate <ack> I would expect 400 to work, but its definition doesn't work.
> 
> Doing that allows the recipient of nXX that it doesn't understand to treat it as n00. That isn't really possible now. So ISTM that 300 & 400 ought to be redefined as "syntax errors or inconsistencies", and 400 as "semantic errors". And then new specific error codes assigned for "The XML syntax is not correct" and "Version not supported".
> 
> * Section 5:
> 
> I don't think it is clear what is to be done when a higher minor version is supported by one end than the other. According to paragraph three the end at the higher version should be able to sent that unchanged, while the other end ignores the parts it doesn't understand. According to paragraph 4 it seems that the end with the higher version should censor itself down to the lower version. (Which means that it needs to keep track of what has to be omitted.)
> 
> ISTM the document ought to state the required behavior. My thought is that it be REQUIRED to ignore unknown elements and attributes. That seems like the easier way to manage the version incompatibility. (Of course it would also be ok for the end with the higher version to censor itself, but that should be optional.)
> 
> It seems that paragraph five was hopeful thinking and hasn't been realized. At this point it probably ought to be removed.
> 
> * Section 8:
> 
> I don't understand how the version element in an option is intended to work. If an option is defined for version M.m, does it also apply to other versions? I guess it ought to apply to later minor versions of the same major version.
> 
> If I had an option that will work with more than one major version, how would I declare it? I can't list more than one version for it. So I guess I have to declare it as more than one option element. Can those be identical except for the version? Or do they require different names?
> 
> In the OPTIONS RESPONSE, does the version need to be identical to what was in the request?
> 
> * Section 11.3:
> 
> Is see "File extension(s): .clue," declared. To do that, wouldn't we need to register the extension somewhere? Do we need this? wouldn't .xml be sufficient?
> 
> * Section 11.4:
> 
> How should the registry be formatted? Is it one column, or two? And what is their significance?
> 
> I guess the part in parens is an optional abbreviation. But neither part is actually used in the protocol, only in the text of the document. The actual names used in the protocol are defined in the schema: "options", "optionsResponse", "advertisement", "ack", "configure", "configureResponse".
> 
> I guess *those* names would be the ones that ought to be registered, if any. But do they need to be registered at all? They are defined in the schema. If more are defined, won't they be in another version of the *same* schema?
> 
> * I previously noted that idnits returns a bunch of errors that need to be fixed. All are superficial.
> 
> * Typos:
> 
> s/seperate/separate/

                     					       _\\|//_
                           				      ( O-O )
   ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~
                    				Simon Pietro Romano
             				 Universita' di Napoli Federico II
                		     Computer Engineering Department 
	             Phone: +39 081 7683823 -- Fax: +39 081 7683816
                                           e-mail: [email-masked]

		    <<Molti mi dicono che lo scoraggiamento è l'alibi degli 
		    idioti. Ci rifletto un istante; e mi scoraggio>>. Magritte.
               			                     oooO
  ~~~~~~~~~~~~~~~~~~~~~~~(   )~~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~
					                 \ (            (   )
			                                  \_)          ) /
                                                                       (_/

---

From: Paul Kyzivat <[email-masked]>
Date: Sun, 21 Feb 2016 17:26:21 -0500

Ding.

On 2/9/16 12:23 PM, Simon Pietro Romano wrote:
> Hi Paul,
>
>
>> [I first sent this on December 1. I could swear I had a reply from
>> Simon promising a new version. But I now cannot find any evidence of
>> such a reply. And -06 is still the most recent version of the protocol.]
>
> You’re not committing perjury :-). And I actually promised a new
> version. We have worked on the data model before moving to the protocol,
> for which we’re currently preparing the -07 version. Sorry for being
> late on this. We’ll try and give a boost in the next few days.

How is this coming???

	Thanks,
	Paul

> Cheers,
>
> Simon
>
>>
>> I did another final review of the protocol draft while doing my
>> shepherd writeup. Unfortunately I found a number of things that ought
>> to be cleared up before submitting to the iesg. I'm sorry about this -
>> I ought to have caught these things sooner.
>>
>> * Section 4:
>>
>> textually or numerically. In particular, are "1.2", "01.2", "1.02",
>> and "01.02" all considered to match?
>>
>> And then:
>>
>> Why is "should" used here? It seems to me it is a logical necessity.
>> So wouldn't "needs to" be more appropriate?
>>
>> * Section 4.1:
>>
>> The above says that if <ack> is present then 200 response code must
>> also be present. But I see no place to put a response code in the CONF
>> message.
>>
>> What code should be used for problems that don't seem to fit any of
>> the ones listed? For instance, what if a CONF contains <ack> but the
>> In SIP, the n00 codes are catch-alls, while other nXX are more
>> specific. Here the n00 values are specific. For the inappropriate
>> <ack> I would expect 400 to work, but its definition doesn't work.
>>
>> treat it as n00. That isn't really possible now. So ISTM that 300 &
>> 400 ought to be redefined as "syntax errors or inconsistencies", and
>> 400 as "semantic errors". And then new specific error codes assigned
>> for "The XML syntax is not correct" and "Version not supported".
>>
>> * Section 5:
>>
>> I don't think it is clear what is to be done when a higher minor
>> version is supported by one end than the other. According to paragraph
>> three the end at the higher version should be able to sent that
>> unchanged, while the other end ignores the parts it doesn't
>> understand. According to paragraph 4 it seems that the end with the
>> higher version should censor itself down to the lower version. (Which
>> means that it needs to keep track of what has to be omitted.)
>>
>> course it would also be ok for the end with the higher version to
>> censor itself, but that should be optional.)
>>
>> other versions? I guess it ought to apply to later minor versions of
>> the same major version.
>>
>> If I had an option that will work with more than one major version,
>> how would I declare it? I can't list more than one version for it. So
>> I guess I have to declare it as more than one option element. Can
>> those be identical except for the version? Or do they require
>> different names?
>>
>> need to register the extension somewhere? Do we need this? wouldn't
>> .xml be sufficient?
>>
>> * Section 11.4:
>>
>> I guess the part in parens is an optional abbreviation. But neither
>> part is actually used in the protocol, only in the text of the
>> document. The actual names used in the protocol are defined in the
>> schema: "options", "optionsResponse", "advertisement", "ack",
>> "configure", "configureResponse".
>>
>> I guess *those* names would be the ones that ought to be registered,
>> if any. But do they need to be registered at all? They are defined in
>> the schema. If more are defined, won't they be in another version of
>> the *same* schema?
>>
> <mailto:[email-masked]>
>

---

From: Simon Pietro Romano <[email-masked]>
Date: Mon, 22 Feb 2016 19:02:10 +0100

Hi Paul, 

before finalizing version -07, we would like to discuss the open points on the ML. Please see in-line our answers to the points you raised.

> Section 4 says sequence numbers are incremented for each message. Does something say what number the first message gets? I haven't seen anything. Does that mean that the first message can have any…

This is our thought. The initial sequence number can be chosen randomly by each party. Does this look reasonable?

In order to avoid confusion, we were thinking of defining version numbers in much the same way as HTTP does:

>>  HTTP-version  = HTTP-name "/" DIGIT ".” DIGIT

This means that we’d like to go for a regular expression imposing a sequence of one digit, followed by a dot, followed by another digit. Does this look OK? Comparisons should then work quite straightforwardly.

> Why is "should" used here? It seems to me it is a logical necessity. So wouldn't "needs to" be more appropriate?

Yeah. Shall we make this become a MUST?

> I don't know how to parse this. I *think* you mean "*Exactly* one …".

Exactly. We’ll correct this.

> I think what is intended is that a CONF with <ack> *implies* a 200 response code for the ADV.

You’re right. We have reworded the above text as follows:

*** 
The optional boolean <ack> element, set to "true" when present, indicates that the CONF message also acknowledges with success the referred advertisement (CONF + ACK message),  
hence applying a piggybacking mechanism for simultaneously acknowledging and replying to the ADV message.
***

> Doing that allows the recipient of nXX that it doesn't understand to treat it as n00. That isn't really possible now. So ISTM that 300 & 400 ought to be redefined as "syntax errors or inconsistencies", and 400 as "semantic errors". And then new specific error codes assigned for "The XML syntax is not correct" and "Version not supported”.

This sounds reasonable, indeed.     

> s/both send a receive/both send and receive/

Done.

> ISTM the document ought to state the required behavior. My thought is that it be REQUIRED to ignore unknown elements and attributes. That seems like the easier way to manage the version incompatibi…

The required behavior should be the following. If Clue Participant CP-A is able to speak version 1.5 and CP-B is able to speak version 1.4, version 1.4 is the one to be spoken and has to appear in the "v" attribute of the subsequent CLUE messages. Hence, CP-A MUST use version 1.4 and downgrade to the lower version. 
This said, and coherently with the general IETF "protocol robustness principle" stating that "an implementation must be conservative in its sending behavior, and liberal in its receiving behavior", Clue Participants MUST ignore unknown elements or attributes that are not envisioned in the negotiated protocol version and related options. This allows to cope with "bad downgrade" situations...

What's your feeling about this?

> It seems that paragraph five was hopeful thinking and hasn't been realized. At this point it probably ought to be removed.

Right. Removed...

> I don't understand how the version element in an option is intended to work. If an option is defined for version M.m, does it also apply to other versions? I guess it ought to apply to later minor…

I would not say that if option X is defined for version 1. 4 then it is defined also for version 1.5. Option X for version 1.5 could either not make any sense, or even be defined (with the same name and) in a completely different manner. This means that each option is intrinsically coupled to a well-defined protocol version number (M.m).

> If I had an option that will work with more than one major version, how would I declare it? I can't list more than one version for it. So I guess I have to declare it as more than one option elemen…

If option X is defined/valid for version 1.5 and 1.6, it should appear twice with the different version numbers. The schema allows for the definition of identical <option> elements (except for the version field, of course).

> In the OPTIONS RESPONSE, does the version need to be identical to what was in the request?

Yes, it does.

> Is see "File extension(s): .clue," declared. To do that, wouldn't we need to register the extension somewhere? Do we need this? wouldn't .xml be sufficient?

Actually, .xml will be sufficient. We don't really need a new file extension just for this purpose.

> Why are we registering new NAPTR tags? AFAIK we don't need or use them.

You're right. Tags removed.

> I guess the part in parens is an optional abbreviation. But neither part is actually used in the protocol, only in the text of the document. The actual names used in the protocol are defined in the…

Here we actually took inspiration from our previous work in RFC6503 (https://tools.ietf.org/html/rfc6503). Message types are in three-column style (Message | Description | RFC Reference); response codes are in four-column style (Number | Default response String | Description | Reference). This is the format in which we are putting such information in version -07 of the draft. 
Does this look OK, or do you think we'll have to go for a different (and perhaps clearer) representation?

> I guess *those* names would be the ones that ought to be registered, if any. But do they need to be registered at all? They are defined in the schema. If more are defined, won't they be in another…

If the schema changes and new messages are introduced, we believe the RFC changes accordingly. The same holds true for the registry, which needs to be updated. Agreed?

> * I previously noted that idnits returns a bunch of errors that need to be fixed. All are superficial.

Sure. We're fixing them.

> (I've heard this is the most common spelling error in English.)

I wish this were the only common spelling error we make. English spelling and pronunciation are a scary world for us poor people! 
After listening to this (http://www.thepoke.co.uk/2016/02/17/english-pronunciation-poem/) we're indeed very close to throwing in the towel!
Jokes apart, if we arrive at an agreed-upon version of the draft, we'll ask Dan (who kindly volunteered) to double-check the document for English correctness.

> 	Sorry about this,

Thank you for your precious feedback. let's keep it going...

Simon

                     					       _\\|//_
                           				      ( O-O )

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 25 Feb 2016 18:37:04 -0500

Hi Simon,

> This is our thought. The initial sequence number can be chosen randomly by each party. Does this look reasonable?

Yes, that is fine. (Since the protocol is over a reliable transport 
there isn't any chance that the first message will be lost, so we can be 
confident that the two ends will agree on what the sequence of numbers 
should be.)

>>>   HTTP-version  = HTTP-name "/" DIGIT ".” DIGIT

OK, I can live with that. It means there can never be more than 9 major 
versions or 10 minor versions of a major version. In theory that could 
be a problem, but in practice I don't think we need to worry. (We don't 
seem at any risk of running out of single digit sip versions!)

> This means that we’d like to go for a regular expression imposing a sequence of one digit, followed by a dot, followed by another digit. Does this look OK? Comparisons should then work quite straig…

Yes, that should work.

> hence applying a piggybacking mechanism for simultaneously acknowledging and replying to the ADV message.

WFM

> This sounds reasonable, indeed.

So can I assume you will make the changes for this?

> What's your feeling about this?

That will *work*. I am concerned that it will put a significant burden 
on the implementor. It will be necessary to remember the details of all 
the prior minor versions, and then to build messages accordingly. That 
seems like a lot of work.

OTOH, if the burden is on the receiver to ignore what isn't understood, 
then that is a one-time cost, and one that ought to be done anyway.

> I would not say that if option X is defined for version 1. 4 then it is defined also for version 1.5. Option X for version 1.5 could either not make any sense, or even be defined (with the same nam…

I guess this is *possible*. But I would expect it to be more common that 
an option defined for version 1.4 will also be applicable to versions 
1.5 and beyond.

But, regardless of this, I don't really see any way to optimize for the 
option being supported in the subsequent versions, other than by 
requiring it to be. And that may be too far to go.

> If option X is defined/valid for version 1.5 and 1.6, it should appear twice with the different version numbers. The schema allows for the definition of identical <option> elements (except for the…

Again, that would work, but seems cumbersome. Why not simply allow the 
<version> element to be repeated?

>> In the OPTIONS RESPONSE, does the version need to be identical to what was in the request?

Will you update the text to make that clear?

> Actually, .xml will be sufficient. We don't really need a new file extension just for this purpose.

So you will change this?

> Does this look OK, or do you think we'll have to go for a different (and perhaps clearer) representation?

The most important part is to be very clear for IANA about how the table 
is formatted. And then about the template for populating the table, so 
that they know what to put in each field. Right now that isn't clear.

> If the schema changes and new messages are introduced, we believe the RFC changes accordingly. The same holds true for the registry, which needs to be updated. Agreed?

You seem to be asking IANA to put "OPTIONS", "OPTIONS RESPONSE", ... 
into the registry. If so, then those key to section heading lines in the 
draft, rather than to protocol elements. I guess that is ok, as long as 
it is made clear.

> Jokes apart, if we arrive at an agreed-upon version of the draft, we'll ask Dan (who kindly volunteered) to double-check the document for English correctness.

I greatly appreciate those of you who are multi-lingual. (In spite of 
having tried in high school and college I was unsuccessful in acquiring 
even a menu-reading competence in another language.)

Also, I expect that a major advantage I have over you is that I have an 
English spell checker. :-)

In any case, the editor will catch the stuff we don't.

Thanks for all of your hard work on this!!! We are almost at the finish 
line!

	Paul