Subject: RE: Comments on draft-ietf-trade-iotp-v1.0-protocol-03.txt, part 1

From: [email-masked]
Date: Tue, 4 May 1999 10:37:32 -0400

Only a few rejoinders.  See @@@...

Donald E. Eastlake, 3rd
17 Skyline Drive, Hawthorne, NY 10532 USA
[email-masked]   tel: 1-914-784-7913, fax: 1-914-784-3833

home: 65 Shindegan Hill Road, RR#1, Carmel, NY 10512 USA
[email-masked]   tel: 1-914-276-2668

David Burdett <[email-masked]> on 04/29/99 07:00:50 PM

To:   Ietf Trade WG <[email-masked]>, Donald Eastlake/Hawthorne/IBM@IBMUS
cc:
Subject:  RE: Comments on draft-ietf-trade-iotp-v1.0-protocol-03.txt, part  1

I have responded to Don's comments with comments marked with ###. I have
also recently sent out separate emails on a number of topics which perhaps
warrant more discussion.

David

> ----------
> From:   [email-masked][SMTP:[email-masked]]
> Sent:   22 April 1999 15:25
> To:     [email-masked]
> Subject:     Comments on draft-ietf-trade-iotp-v1.0-protocol-03.txt, part
> 1
>
> I've done a careful review of the document through section 6 and section
> 13
> and greater and came up with the following somewhat length list of
> suggestions.  I don't think they substantially change the intended meaning
> of the document but those on the list should judge that.
>
>
> IMPORTANT:
>
> "IANA Considerations" needs to be a top level section, perhaps #11.
> Gathering this stuff together into 3.7.3 is good but its still
> unreasonable
> to expect IANA to comb the document to find it.
### Agreed. Move section 3.7.3 to a new section 11 IANA Considerations.###
>      I'm not sure about the criteria for registration.  "IETF Consensus"
> is
> pretty stiff and requires a vote of the IESG.  I should think someone
> could
> register an IOTP Brand or CurrCode by publishing an RFC.  Perhaps that is
> what you mean for ProtocolId but it is not clear.
### Agreed. See separate email.###
>      Toward end so 3.7.3, change "with" to "without".
### Agreed

> MISCELLANEOUS:
>
> I don't understand the difference between "Objectives" and "Purpose".  I
> suggest that 1.4 and 1.5 be merged
###Agreed
> and that the reference to "IOTP Business
> Description" which, as far as I know, is not intended to ever become an
> IETF document, be dropped.
###Agreed

> Section 1.7 still refers to an XML Overview section 11.
###Change to refer to IANA considerations

> Page spanning figures, like Figure 3, are really pretty messy.  It would
> be
> better if the text could be made much more terse and this and similar
> figures started high on a page so they aren't split by a page boundary.
### Not sure. See separate email ###

> Section 2.2: suggest "The Open Trading Protocols identify" be changed to
> "IOTP identifies".
### Agreed. Also suggest changing Open Trading Protocol to Internet Open
Trading Protocol in sections: 1.4,1.6, 8, 12 (heading & DTD)###

> Section 2.2: says "IOTP Transactions are composed of these exchanges" but
> does not list Inquiry or Ping exchange.
###This is deliberate. The Inquiry and Ping exchange are not "trading
exchanges" as they are used primarily to to ensure that messages are
exchanged correctly or to determine the current status of a transaction.###

> Starting in section 2.3 and many other places in the document, words or
> phrases are prefixed and suffixed by an underscore character ("_").  This
> is not any normal IETF style.  I suspect it means that the original text
> is
> italic.  These should be suppressed or if that is impossible, a separate
> pass should be done to delete them.
###These seem to be caused by either a non-breakable dash or "smart quotes"
in MS Word being miss-translated when the document is converted to text.
Will fix in next version.###

> In Figure 9, the things which are supposed to be identical or match aren't
> and don't.  Is that deliberate?
### No. Its a mistake. They should be the same. Will be fixed.###

> I don't think that section 3.6 Brands and Brand Selection fits very well
> where it and suggest it be moved into section 10 which could be renamed
> "Brands".
###Agreed. A good idea.###
>      Continuing on Brands, I looked around a bit in SET literature and
> couldn't find anything about Dual or Promotional brands or anything about
> a
> three component SET Brand.  Two components, "brand" and "product" I see in
> the SET literature, such a "MasterCard" or "Visa:Gold".  But not A:B:C and
> no case where a colon is included if there isn't anything after it.  In
> other words, it's "Visa", not "Visa:", and certainly not "Visa::" as a SET
> brand (re also examples in 6.6.1). Can anyone give me any references to
> shed light on this?
### I think this arose as a result of a japanes requirement. See separate
email###

> Section 3.8.1: I don't understand why sub-pages of an HTML main page
> couldn't have links back to the main page.
### Disagree. See separate email.###

@@@ I'll reply to the separate mail.

> Section 4.1: first section reference says "0"?
###Agreed. Will fix.###

> Figures 10 and 11: These flow diagrams each *almost* fit on a page. If the
> initial "Input IOTP Message" box could be to the side with a horizontal
> arrow and the text were edited down to something a bit more terse, I think
> they would, which would be quite helpful.
### See response to comments about figure 3, and separate email###

> Section 5: Suggest this section be called "Digital Signature" or
> something.
> Usually an IETF Security Considerations section is brief and talks about
> really high level issues.  Material in 5.4 is appropriate for Security
> Considerations.  A separate Security Considerations section would need to
> also say something about deciding when to require signatures, even if it
> is
> just by referring to section 5.1.4, and about depending on payment scheme
> security for the safety of funds, which I didn't see anywhere.
>      Section 5 seems pretty heavy on certificates and public key crypto,
> especially given the originally IOTP v1.0 was going to be secret key only
> and, as I recall, it was with some reluctance that public key hooks were
> added.  The stuff on checking a signature, for example, talks about
> checking the certificate as if there always has to be one.
>      Section 5.1.4: another reason you might not need signatures is the
> that the sender and receiver were on the same machine so it can check
> integrity just by comparing with a saved copy.
### I suggest quite a few changes here specifically:
*    renumber section 5 (and all later sections) as section 6 and rename
as "Digital Signatures and IOTP"
*    insert a new section 5 called "Security Considerations" which is
focussed on the types of IETF security considerations Don describes above.
Specifically including: why you might want (or not want) to use signatures;
use of asymmetric and symmetric cryptography; privacy, and payment protocol
security###

@@@ OK.

> Section 6.4.2: Need to eliminate reference to "Open Trading Protocol
> Consortium" and suggest dropping whole note.
### Agreed ###
> I don't see any difference at all between OkTo/OkFrom and amount.  Both
> could appear in human readable
> form in the Order Description and in machine readable form in their
> element.  Recommending that the UI display the machine readable version is
> reasonable (as in 6.4.1).
### I think the note should remain but include suggestion that the OkFrom
and OkTo dates are displayed to the consumer.###

@@@ Sure.  That would be a good way to handle it.

> ContentSoftwareId: the standard text given for this is quite length and
> repeated dozens of time.  If it could be moved to the glossary or
> something
> and a simple "see glossary" put in, it would save many pages.
### Agreed ###

> As previously discussed, change ISO4217 to ISO4217A or the like.
### Suggest change to ISO4217-A. See other email.###

> Just before section 6.7, it says that examples exist in 6.6 when they are
> in 10.
### Agreed. Will fix ###

> Section 6.17: references to the Richard Brown draft and probably not
> appropriate.  RFCs are not supposed to refer to drafts.  About the future,
> I'm not sure you need to say anything but if you do, I think it should
> just
> say the future versions of IOTP will use industry standard XML signature
> technology if it meets IOTP requirements.
### Agreed will change to refer to IOTP Dsig paper and use of standard XML
signature technology in the future###

>      Shouldn't 6.17.1 refer to the IOTP DSIG document?  It's OK to refer
> to
> that draft because the idea is that it and the main protocol document will
> be issued as RFCs simultaneously.  Maybe the XMLDSIG reference should just
> be changed to refer to the IOTP DSIG document.
### ALL references to XMLDSIG shall be changed to reflect IOTPDSIG
instead.###

>      There is a reference in  6.17.1 to payment scheme specific
> algorithms.
> Wouldn't their use be encapsulated inside the packaged contents and be in
> the payment scheme modules, not an IOTP implementation itself?
### Not necessarily. For example a Mondex purse application on a smart card
can be used to authenticate an individual using cryptography on the smart
card chip. This means that the "Algorithm" used for authenticatiojn purposes
could potentially be: SHA1, a digital signature, or a payment protocol
specific algorithm. Therefore suggest no change.###

@@@ Ahhh, OK.

>      Section 6.18: similarly for certificate reference.  Should point out
> that certs not needed for symmetric keying or for cases where public key
> has been registered at recipient.
### Agreed ###

> Section 6.19.2: For ElContIllegal, ValueTooSmall, and ValueTooLarge, I
> believe it should say "content" rather than "PackagedContent".
### Agreed ###

> TRIVIAL NITS:
>
> In the Abstract and section 1, Delivery Handler is capitalized but payment
> handler isn't.
### Agreed ###

> It is not usual to have a section like 1.7, History, in an IETF document.
> If the evolution of a protocol sheds light on its technical content,
> that's
> one thing.  But it is not usual to have what is mostly a list of editing
> versions.  Suggest it be dropped to shorten the document.
### Agreed ###

> I'm not sure why there is a skip to new page before section 3.1 or 3.1.2.
> Suggest dropping these to make the document more compact.  RFC style is to
> have no skips to the start of a new page anywhere in the body text.
### This was caused by keeping figure 6 together with the immediately
preceeding lines. ###

> Section 3.8 example packaged content:  I don't like the "Name"s FirstMsg
> and SecondMsg.  Using Msg => Message seems confusing.  Suggest FirstPiece
> and SecondPiece.
### Changed ###

> Section 3.10 says "Where both types of net location are present, the
> following rules apply:" and then gives three rules only the third of which
> applies in the described circumstances.  Suggest moving the first two up
> and combining the quoted phrase with the third.
### Agreed ###

> Section 3.11.1 "treated by the recipient is an error": is -> as
### Fixed ###

> Section 4: "There are a several ..." delete "a"
### Fixed ###

> Section 4.4.1.2: in first sentence has -> have.
### Agreed ###

> Section 4.4.2.9: in first sentence, insert "server" between "the" and
> "unless".
> ### Agreed ###
>
> Not sure why skip to new page before section 5.3.1 shortly before Figure
> 14
> which overflows onto next page by just one line...
### Fixed ###

> Section 5.3.1.1: numbered subsections, lettered subsubsections:  The text
> at the ends of these 12 subsubsections is substantially the same.
> Starting
> with 3)b) sometimes the final period is omitted.  Suggest moving this text
> up to the numbered section level or to before the whole two level list.
### Tidied up ###

> Section 5.3.1.2: ditto 5.3.1.1 except list is one level.
### Ditto ###

> Section 6.1: towards the end, delete "the" from "that the should".
### Fixed ###

> Section 6.2: Insert "may be" after "there" in "there only one".
### Fixed ###

> Section 6.5.5: PostalCode missing from detailed attributes list.
### Fixed ###

> Just before 6.6.3 and 6.7.1: "in10" -> "in section 10".
### Fixed ###

> Suggest replacing occurrences of "SSL" with "SSL/TLS" and adding the TLS
> RFC to the References.
### Agreed ###

> Section 6.11:  has "Plain/Text" where other similar sentences use "Plain
> Text" which is probably better.  The "/" makes it look like a MIME type
> and
> the MIME type is actually text/plain.  But I would suggest not using the
> MIME type as there isn't a unique one for HTML.
### Agreed ###

> Section 6.12.1: DelivReqNetLocn & SecDelivReqNotLocn: "Mechanism must" ->
> "Mechanism and must".
### Agreed ###

> Section 6.13: Content, should be "PackagedContent" not "Delivery Note".
### Agreed ###

> REFERENCES (section 14)
>
> For DOM-HASH, can't refer to any Internet-Drafts by URL or filename.  For
> HMAC, suggest refereing to RFC 2104 HMAC: Keyed-Hashing for Message
> Authentication. H. Krawczyk, M. Bellare, R. Canetti. February 1997.
>
> It looks pretty odd to the IETF spelled out in the RFC references.  I've
> never seen that in an IETF document references section.
>
> For SET, suggest referencing the SETco.org site, not Mastercard.  Can't
> reference the Brown XMLDSIG draft in an RFC (although you can talk about
> it
> without a URL or file name reference if necessary).
>
>
> Donald E. Eastlake, 3rd
> 17 Skyline Drive, Hawthorne, NY 10532 USA
> [email-masked]   tel: 1-914-784-7913, fax: 1-914-784-3833
>
> home: 65 Shindegan Hill Road, RR#1, Carmel, NY 10512 USA
> [email-masked]   tel: 1-914-276-2668

-----------------------------------------------------------------------
Message addressed to: [email-masked]
Archive available at: http://www.elistx.com/archives/ietf-trade/
To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
body to: [email-masked]