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

From: Paul Kyzivat <[email-masked]>
Date: Tue, 1 Dec 2015 14:43:58 -0500

I did another final review of the protool 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: "Duckworth, Mark" <[email-masked]>
Date: Tue, 1 Dec 2015 14:49:21 -0800

Hi Paul,

My previous comments also mentioned similar things about sequence numbers and <ack>.  Simon responded in email on Oct 19<https://mailarchive.ietf.org/arch/msg/clue/31ZvMbjtwwFJ6vMlbb1x-eCiIrY>.

I agree about section 4.5, the <ack> in this case should imply 200 success.

About comparing version numbers, the text says both major and minor version numbers are unsigned integers. My interpretation is these are compared numerically, so yes all your examples below match. Probably the document should be more clear about this. And also "1.2" is not the same as "1.20".

Mark

> -----Original Message-----

> From: clue [mailto:[email-masked]] On Behalf Of Paul Kyzivat

> Sent: Tuesday, December 01, 2015 2:44 PM

> To: Simon Pietro Romano; Roberta Presta

> Cc: CLUE

> Subject: [clue] draft-ietf-clue-protocol-06: stuff found while preparing

> submission writeup

> advertisement had previously been acknowledged? (Would 301 apply to

> that?)

> "optionsResponse", "advertisement", "ack", "configure",

> "configureResponse".

> _______________________________________________

> clue mailing list

> [email-masked]<mailto:[email-masked]>

> https://www.ietf.org/mailman/listinfo/clue

---

From: Christian Groves <[email-masked]>
Date: Wed, 2 Dec 2015 12:55:15 +1100

Hello Paul, all,

I agree with many of the comments. A couple of responses:

..snip..
>
>
> * 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.)
>
> course it would also be ok for the end with the higher version to 
> censor itself, but that should be optional.)
[CNG] I pretty sure the intention is that by using the OPTIONs the 
endpoints agree on a single version. Cl.3 in the overview indicates that 
the participants agree on a protocol version. To me that implies both 
endpoints use that version.

> realized. At this point it probably ought to be removed.
[CNG] I agree.
> other versions? I guess it ought to apply to later minor versions of 
> the same major version.
[CNG] Good questions. I assume that for major version changes which 
could be non-backward compatible that it can't be assumed that the 
extension will also work for the major version change. I agree on the 
minor versions.
>
> 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?
>

Regards, Christian