From nobody Tue Feb 9 08:33:45 2016 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C13DA1ACC7F for ; Tue, 9 Feb 2016 08:33:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.165 X-Spam-Level: X-Spam-Status: No, score=0.165 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rk-O4GtKwYUT for ; Tue, 9 Feb 2016 08:33:42 -0800 (PST) Received: from resqmta-po-02v.sys.comcast.net (resqmta-po-02v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:161]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 497591AC3BC for ; Tue, 9 Feb 2016 08:33:42 -0800 (PST) Received: from resomta-po-15v.sys.comcast.net ([96.114.154.239]) by resqmta-po-02v.sys.comcast.net with comcast id GGZg1s0025AAYLo01GZhwS; Tue, 09 Feb 2016 16:33:41 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([73.218.51.154]) by resomta-po-15v.sys.comcast.net with comcast id GGZg1s00E3KdFy101GZgVJ; Tue, 09 Feb 2016 16:33:41 +0000 From: Paul Kyzivat To: Simon Pietro Romano , Roberta Presta Message-ID: <56BA14E3.9080806@alum.mit.edu> Date: Tue, 9 Feb 2016 11:33:39 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1455035621; bh=v30LyEmX0ILxsU4PyVEk++tkDoH6dB8L8BCLKeqxitU=; h=Received:Received:From:Subject:To:Message-ID:Date:MIME-Version: Content-Type; b=LwQNmvOtJtoeSX1+PrTcw7c0RSowZO90tdX93tFRyKC5OI+haj3iTpMDyoTXUgvEw jf1akqpc1sFGxg7cNPm44lHGnSiCk7+/PmkjN8aLR0J9Br7ngM0JKRAxGZ/81ge+XL ug0IwoYXLce0w1E49fCNq8y0651/CQk0tw+Jqb+pdf729qXBr8j4uVRvL5xcxaJaxB u1dfK3gtyOh4LNjZMR3MTXJZOhRDg/XrzON9/TM+l3Noir7IhmRMbtIGGqduu5ya+S VXIc3GlFESfQCA3RXxEu3R4uYe+9PBaSudTxWYDDOKecF5BOeTQBBBB+ar3bVRjGON XaQJyQVjgnHDA== Archived-At: Cc: CLUE Subject: [clue] draft-ietf-clue-protocol-06: stuff found while preparing submission writeup [RESEND] X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Feb 2016 16:33:43 -0000 [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 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 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 element MUST not be present if an ACK message has been already sent back to the MP. The above says that if 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 *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 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 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 nobody Tue Feb 9 09:23:06 2016 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 349BE1ACD7B for ; Tue, 9 Feb 2016 09:23:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.021 X-Spam-Level: X-Spam-Status: No, score=-0.021 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pL2FRixZC5Zy for ; Tue, 9 Feb 2016 09:23:00 -0800 (PST) Received: from brc2.unina.it (brc2.unina.it [192.132.34.42]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 65E391ACD74 for ; Tue, 9 Feb 2016 09:23:00 -0800 (PST) X-ASG-Debug-ID: 1455038577-05f27525956994e0001-dOUo1C Received: from smtp2.unina.it (smtp2.unina.it [192.132.34.62]) by brc2.unina.it with ESMTP id cLx2GpCD2VG68isN (version=TLSv1 cipher=AES256-SHA bits=256 verify=NO); Tue, 09 Feb 2016 18:22:57 +0100 (CET) X-Barracuda-Envelope-From: spromano@unina.it X-Barracuda-Apparent-Source-IP: 192.132.34.62 Received: from [143.225.28.169] ([143.225.28.169]) (authenticated bits=0) by smtp2.unina.it (8.14.4/8.14.4) with ESMTP id u19HMuP4014447 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 9 Feb 2016 18:22:56 +0100 Content-Type: multipart/alternative; boundary="Apple-Mail=_5DFF2EB9-4A3A-4D0B-BE8B-62AFC381C1EE" Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Simon Pietro Romano X-ASG-Orig-Subj: Re: [clue] draft-ietf-clue-protocol-06: stuff found while preparing submission writeup [RESEND] In-Reply-To: <56BA14E3.9080806@alum.mit.edu> Date: Tue, 9 Feb 2016 18:23:00 +0100 Message-Id: <3F74EA9C-D751-4CAE-A71B-4C6C05660B79@unina.it> References: <56BA14E3.9080806@alum.mit.edu> To: Paul Kyzivat X-Mailer: Apple Mail (2.1993) X-Barracuda-Connect: smtp2.unina.it[192.132.34.62] X-Barracuda-Start-Time: 1455038577 X-Barracuda-Encrypted: AES256-SHA X-Barracuda-URL: http://192.132.34.42:8000/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at unina.it X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=6.0 tests=BSF_SC0_MISMATCH_TO, HTML_MESSAGE X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.26891 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 BSF_SC0_MISMATCH_TO Envelope rcpt doesn't match header 0.00 HTML_MESSAGE BODY: HTML included in message Archived-At: Cc: CLUE Subject: Re: [clue] draft-ietf-clue-protocol-06: stuff found while preparing submission writeup [RESEND] X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Feb 2016 17:23:05 -0000 --Apple-Mail=_5DFF2EB9-4A3A-4D0B-BE8B-62AFC381C1EE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 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=92re 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=92re currently preparing the -07 version. Sorry for being = late on this. We=92ll try and give a boost in the next few days. Cheers, Simon >=20 > 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. >=20 > * Section 4: >=20 > 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? >=20 > 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? >=20 > And then: >=20 > Each CP should manage up to three (independent) streams of sequence > numbers: ... >=20 > Why is "should" used here? It seems to me it is a logical necessity. = So wouldn't "needs to" be more appropriate? >=20 > * Section 4.1: >=20 > ... Only one 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. >=20 > I don't know how to parse this. I *think* you mean "*Exactly* one = ...". >=20 > * Section 4.5: >=20 > The optional boolean 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 element MUST not be present if an ACK message has > been already sent back to the MP. >=20 > The above says that if is present then 200 response code must = also be present. But I see no place to put a response code in the CONF = message. >=20 > I think what is intended is that a CONF with *implies* a 200 = response code for the ADV. >=20 > * Section 4.7: >=20 > 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 but the = advertisement had previously been acknowledged? (Would 301 apply to = that?) >=20 > In SIP, the n00 codes are catch-alls, while other nXX are more = specific. Here the n00 values are specific. For the inappropriate = I would expect 400 to work, but its definition doesn't work. >=20 > 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". >=20 > * Section 5: >=20 > s/both send a receive/both send and receive/ >=20 > * Section 7: >=20 > 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.) >=20 > 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.) >=20 > It seems that paragraph five was hopeful thinking and hasn't been = realized. At this point it probably ought to be removed. >=20 > * Section 8: >=20 > 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. >=20 > 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? >=20 > In the OPTIONS RESPONSE, does the version need to be identical to what = was in the request? >=20 > * Section 11.3: >=20 > 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? >=20 > * Section 11.4: >=20 > Why are we registering new NAPTR tags? AFAIK we don't need or use = them. >=20 > * Section 11.5.1: >=20 > How should the registry be formatted? Is it one column, or two? And = what is their significance? >=20 > 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". >=20 > 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? >=20 > * I previously noted that idnits returns a bunch of errors that need = to be fixed. All are superficial. >=20 > * Typos: >=20 > s/seperate/separate/ > (I've heard this is the most common spelling error in English.) >=20 > Sorry about this, > Paul >=20 _\\|//_ ( O-O ) ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~ Simon Pietro Romano Universita' di Napoli Federico = II Computer Engineering Department=20 Phone: +39 081 7683823 -- Fax: +39 081 7683816 e-mail: spromano@unina.it <>. = Magritte. oooO ~~~~~~~~~~~~~~~~~~~~~~~( )~~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~ \ ( = ( ) \_) ) = / = (_/ --Apple-Mail=_5DFF2EB9-4A3A-4D0B-BE8B-62AFC381C1EE Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 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=92re 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=92re = currently preparing the -07 version. Sorry for being late on this. We=92ll= 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:

  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


  =                   =   =        = _\\|//_
            =                 =       ( 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: spromano@unina.it

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






= --Apple-Mail=_5DFF2EB9-4A3A-4D0B-BE8B-62AFC381C1EE-- From nobody Sun Feb 21 14:26:28 2016 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 346281A1B9C for ; Sun, 21 Feb 2016 14:26:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.465 X-Spam-Level: * X-Spam-Status: No, score=1.465 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vy1KEksGj_Ad for ; Sun, 21 Feb 2016 14:26:24 -0800 (PST) Received: from resqmta-ch2-11v.sys.comcast.net (resqmta-ch2-11v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:43]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1FAC01A1A92 for ; Sun, 21 Feb 2016 14:26:23 -0800 (PST) Received: from resomta-ch2-06v.sys.comcast.net ([69.252.207.102]) by resqmta-ch2-11v.sys.comcast.net with comcast id MASJ1s0052D5gil01ASPVj; Sun, 21 Feb 2016 22:26:23 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([73.218.51.154]) by resomta-ch2-06v.sys.comcast.net with comcast id MASN1s00B3KdFy101ASN0f; Sun, 21 Feb 2016 22:26:23 +0000 To: Simon Pietro Romano References: <56BA14E3.9080806@alum.mit.edu> <3F74EA9C-D751-4CAE-A71B-4C6C05660B79@unina.it> From: Paul Kyzivat Message-ID: <56CA398D.3020601@alum.mit.edu> Date: Sun, 21 Feb 2016 17:26:21 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <3F74EA9C-D751-4CAE-A71B-4C6C05660B79@unina.it> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1456093583; bh=tQGH58ZsI6wKUeFpn1HFmb7Z+iQDHSrDNrSjj9KNLPE=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=AfnraTl0ShAWB8JE0BycxXBDmsC+yW32RPLV/fwqhzohj3VQ0hxHbuTympkFC2lDa wqOz+u/U3xh6JfiZYhUpDe/Kf4xjErRRDgbkoHr+zpzkpA2cCdFMyDZ3DubsuZ16QT AiSMsuC0d6VRMNE1oygGRLYKN8mDoyW5lDKxTv2uTlPVSkTcyh1KukrjypYR9Eg8oY jyIMsYImXaKphUfvl564o3aNhYDFAHlatBTCRMejNCPNwYkELm/PwQZc8Ppqv4vLog UZSW/OWQ/34bXf7ku5xwTM/IpeiDlAr5sJdjhJiB4rJJ4ojTJhqTACwcdD5c+vPu5+ sAgJoG8jj+52w== Archived-At: Cc: CLUE Subject: Re: [clue] draft-ietf-clue-protocol-06: stuff found while preparing submission writeup [RESEND] X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Feb 2016 22:26:26 -0000 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: >> >> 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 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 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 element MUST not be present if an ACK message has >> been already sent back to the MP. >> >> The above says that if 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 *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 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 >> 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 >> > > _\\|//_ > ( 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: spromano@unina.it > > > < idioti. Ci rifletto un istante; e mi scoraggio>>. Magritte. > oooO > ~~~~~~~~~~~~~~~~~~~~~~~( )~~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~ > \ ( ( ) > \_) ) / > (_/ > > > > > > From nobody Mon Feb 22 10:02:13 2016 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E4221B2BD1 for ; Mon, 22 Feb 2016 10:02:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.673 X-Spam-Level: ** X-Spam-Status: No, score=2.673 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id foUNW728xy10 for ; Mon, 22 Feb 2016 10:02:08 -0800 (PST) Received: from brc2.unina.it (brc2.unina.it [192.132.34.42]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8BBF71B2BE0 for ; Mon, 22 Feb 2016 10:02:07 -0800 (PST) X-ASG-Debug-ID: 1456164124-05f27504cd50bdfd0001-dOUo1C Received: from smtp2.unina.it (smtp2.unina.it [192.132.34.62]) by brc2.unina.it with ESMTP id Gi4WgJVM9K6FAfKB (version=TLSv1 cipher=AES256-SHA bits=256 verify=NO); Mon, 22 Feb 2016 19:02:04 +0100 (CET) X-Barracuda-Envelope-From: spromano@unina.it X-Barracuda-Apparent-Source-IP: 192.132.34.62 Received: from [143.225.28.169] ([143.225.28.169]) (authenticated bits=0) by smtp2.unina.it (8.14.4/8.14.4) with ESMTP id u1MI236c028884 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 22 Feb 2016 19:02:04 +0100 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Simon Pietro Romano X-ASG-Orig-Subj: Re: [clue] draft-ietf-clue-protocol-06: stuff found while preparing submission writeup [RESEND] In-Reply-To: <56BA14E3.9080806@alum.mit.edu> Date: Mon, 22 Feb 2016 19:02:10 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <543BDCB4-6EDD-43D9-BDDD-0DA9FB6FA784@unina.it> References: <56BA14E3.9080806@alum.mit.edu> To: Paul Kyzivat X-Mailer: Apple Mail (2.1993) X-Barracuda-Connect: smtp2.unina.it[192.132.34.62] X-Barracuda-Start-Time: 1456164124 X-Barracuda-Encrypted: AES256-SHA X-Barracuda-URL: http://192.132.34.42:8000/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at unina.it X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=6.0 tests=BSF_SC0_MISMATCH_TO X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.27242 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 BSF_SC0_MISMATCH_TO Envelope rcpt doesn't match header Archived-At: Cc: CLUE Subject: Re: [clue] draft-ietf-clue-protocol-06: stuff found while preparing submission writeup [RESEND] X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Feb 2016 18:02:11 -0000 Hi Paul,=20 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: >=20 > 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? This is our thought. The initial sequence number can be chosen randomly = by each party. Does this look reasonable? > 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? In order to avoid confusion, we were thinking of defining version = numbers in much the same way as HTTP does: >> HTTP-version =3D HTTP-name "/" DIGIT ".=94 DIGIT This means that we=92d 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. > And then: >=20 > Each CP should manage up to three (independent) streams of sequence > numbers: ... >=20 > 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? > * Section 4.1: >=20 > ... Only one 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. >=20 > I don't know how to parse this. I *think* you mean "*Exactly* one =85". Exactly. We=92ll correct this. > * Section 4.5: >=20 > The optional boolean 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 element MUST not be present if an ACK message has > been already sent back to the MP. >=20 > The above says that if is present then 200 response code must = also be present. But I see no place to put a response code in the CONF = message. >=20 > I think what is intended is that a CONF with *implies* a 200 = response code for the ADV. You=92re right. We have reworded the above text as follows: ***=20 The optional boolean element, set to "true" when present, = indicates that the CONF message also acknowledges with success the = referred advertisement (CONF + ACK message), =20 hence applying a piggybacking mechanism for simultaneously acknowledging = and replying to the ADV message. *** > * Section 4.7: >=20 > 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 but the = advertisement had previously been acknowledged? (Would 301 apply to = that?) >=20 > In SIP, the n00 codes are catch-alls, while other nXX are more = specific. Here the n00 values are specific. For the inappropriate = I would expect 400 to work, but its definition doesn't work. >=20 > 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=94. This sounds reasonable, indeed. =20 > * Section 5: >=20 > s/both send a receive/both send and receive/ Done. > * Section 7: >=20 > 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.) >=20 > 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.) 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.=20 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... > * Section 8: >=20 > 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. 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 element. Can those be = identical except for the version? Or do they require different names? 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