Subject: [OPSAWG] Fwd: [Int-area] Please review my Internet Draft

From: Mykyta Yevstifeyev <[email-masked]>
Date: Sat, 6 Nov 2010 10:46:15 +0200

Hello all,

I have recently writtent to INTAREA Working Group
for reviewing my Internet-Draft. However I was advised to write
to OPS area WG. You will gind the link to the I-D below
in the 'history' of messaging among the INTAREA WG.
At the moment I am planning to make a new version
of the I-D - so when I will submit it - I'l tell you.

While answering, please send copy to
Ronald Bonica <[email-masked]>
Joe Touch <[email-masked]>,
Stephane Bortzmeyer <[email-masked]>,
"[email-masked]" <[email-masked]>,
   and
Henk Uijterwaal <[email-masked]>

Thn ank you in advance. Waiting for an answer, MYKYTA
YVSTIFEYEV

---------- Forwarded message ----------
From: Mykyta Yevstifeyev <[email-masked]>
Date: Sat, 6 Nov 2010 09:23:36 +0200
Subject: Re: [Int-area] Please review my Internet Draft
To: Ronald Bonica <[email-masked]>
Cc: Joe Touch <[email-masked]>, Stephane Bortzmeyer
<[email-masked]>, "[email-masked]" <[email-masked]>, Henk
Uijterwaal <[email-masked]>

Hi all.

I have recently received the message of Ronald.
The motivation he supposed, IMO, can be acceptable for
my project. The HCITP may be useful for controlling large networks.
But I consider resource conservation to be the main aim of the]
project. At the moment there are no critical necessity for it, but in future,
I think, it would be rather needed.

Some notes about secure issues.
The system admin. can make ACL (find some notes
below) to forbid transferring the corresponding information.
So IMO it is not a great problem.

Finally, I don't want to make it a 'Standards Track'
specification - I thinf it should be just 'Experimental'.
And in future it may become the 'Standards Track' IMO.

As soon as I will publish the newer version of I-D I'll tell
you.

All the best,
Mykyta Yevstifeyev.

2010/11/5, Ronald Bonica <[email-masked]>:
> Mykyta,
>
> I have a few questions regarding this draft:
>
> - What is the motivation for the draft? In the draft, you talk about
> conserving resources that would otherwise be consumed by transferring files
> that the recipient doesn't have the hardware capability to consume. Is this
> a real operational issue? Are any operators complaining about it?
>
> While I don't think that conserving resources is a valid motivation, I can
> see other motivations for this draft. For example, my employer issues a
> laptop computer to all employees. Our IT department might want to probe it
> every now and the to make sure that I haven't swapped out the disk drive for
> a cheaper model.
>
> However, if it were to be used that way, the application should be
> accessible my employer's IT department only.
>
> - If used as you suggest, would this protocol make the Internet more
> brittle? For example, assume that in my house, I have one computer that has
> a large disk drive and but an ancient video card and another computer that
> has a tiny disk drive and a fancy video card. I want to download a movie,
> but the content provider won't let me download because the requesting device
> doesn't have the required video card.
>
> - If used as you suggest, would this make the Internet less secure? For
> example, let's assume that somebody has found a vulnerability manufacturer
> XYZ's XYZ operating system. Would this protocol make it easier for
> miscreants to find XYZ gear?
>
> Responding to Joe's comment, OPS is the correct area for this work in one
> respect and is not the correct area in another. We should probably work out
> the motivation and uses for this protocol in OPS. However, OPS does not
> create protocols. That part would have be done in APP or INT.
>
>                                                  Ron
>
>
>
>> -----Original Message-----
>> From: Mykyta Yevstifeyev [mailto:[email-masked]]
>> Sent: Friday, November 05, 2010 3:40 AM
>> To: Joe Touch
>> Cc: Stephane Bortzmeyer; [email-masked]; Ronald Bonica
>> Subject: Re: [Int-area] Please review my Internet Draft
>>
>> Hi all,
>>
>> I have revised all the messages I have received .
>> Thank everybody for discussion. I think all
>> the suggestions will be taken into consideration.
>> I'll make the HCTP TCP-based, add the support
>> of IPv6. At the moment IANA is ready to assign
>> a port for the service - so I'll add the corresponding
>> IANA Considerations section. As soon as newer version
>> will be available - I'll tell you.
>>
>> However I'm still ready for discussion and suggestions.
>>
>> Mykyta Yevtifeyev
>>
>> 2010/11/5, Joe Touch <[email-masked]>:
>> > Hi, all,
>> >
>> > On 11/4/2010 2:26 AM, Mykyta Yevstifeyev wrote:
>> >> Hi all.
>> >> --------------------------------------
>> >> [TO RONALD BONICA - Dear Ronald. Joe Touch
>> >> has advised me to ask you for review of my I-D.
>> >
>> > Actually, I had only indicated that OPS would be the relevant area
>> for
>> > this work.
>> >
>> > My current view is that a revision would be useful (esp. as you
>> suggest
>> > below) before further feedback is solicited. FWIW. Also, as per
>> below,
>> > TCP will provide reliability, but not security.
>> >
>> > Joe
>> >
>> >> You can find the link for it in the 'history'
>> >> I have put below. You can find another
>> >> messages there, too. Thank you in advance.]
>> >> --------------------------------------
>> >> I have read all the notes.
>> >>
>> >> Thank everybody for useful advices.
>> >>
>> >> While developing the next version of the I-D,
>> >> I'll make some changes to it as you have advised.
>> >> I'll make it TCP-based - so it'll obtain have some
>> >> realibility and security. I should explain that
>> >> my priority is low 'cost' of processing for
>> >> computers using HCTP - as Joe Touch has mentioned.
>> >>
>> >> Mykyta Yevstifeyev
>> >> 2010/11/3, Joe Touch<[email-masked]>:
>> >>> Hi, Mykyta,
>> >>>
>> >>> Some additional info below:
>> >>>
>> >>> On 11/3/2010 3:08 AM, Mykyta Yevstifeyev wrote:
>> >>>> I have read your message. Thank you very much for your review.
>> >>>>
>> >>>> Now I will explain some issues you have written about in you
>> letter.
>> >>>>
>> >>>> Before I have submitted the I-D to IETF, I had an idea to transfer
>> the
>> >>>> information
>> >>>> using XML, however I tried to make the protocol easier and that is
>> why
>> >>>> I have to use defined format.
>> >>>
>> >>> It's not clear what you're optimizing for. The document should
>> clearly
>> >>> explain your priorities (space, processing cost, etc.), and
>> indicate
>> >>> alternatives not chosen and why.
>> >>>
>> >>>> I tried to make the messages of HCTP as short as possible - that
>> is wy
>> >>>> I 'compressed' the field in bits.
>> >>>
>> >>> It's not clear why 'short' is a useful optimization, as others have
>> >>> noted, except for highly-constrained (sensornet) environments. This
>> >>> would be useful to explain.
>> >>>
>> >>>> There would not be a lot of messages in transaction - why should
>> the
>> >>>> be transferred using TCP? This way uses more resources than UDP-
>> based
>> >>>> one.
>> >>>
>> >>> This is, FWIW, a mistake made by Tim Berners-Lee when designing
>> HTTP
>> >>> instead of just using FTP. He thought that most interactions would
>> only
>> >>> get one file, so why open two connections?
>> >>>
>> >>> In this case, there are other things your protocol doesn't address
>> >>> (reordering, reliability) that you get for free with TCP.
>> >>>
>> >>> Finally, what resources is TCP using? TCP runs on nearly
>> everything, and
>> >>> certainly anything that has most of the devices you've listed.
>> I.e.,
>> >>> from a CPU, memory, transaction speed, and bandwidth cost, using
>> XML
>> >>> over HTTP over TCP is sufficient for even for things like sensor
>> motes.
>> >>> What kind of device are you considering that would think that TCP
>> was
>> >>> high overhead vs UDP?
>> >>>
>> >>>> To the question to usefullness - the administrator of computer can
>> >>>> make a list of acceptable 'requesters' of hardware information -
>> e. g.
>> >>>> some trusted Internet sites which really need an information about
>> >>>> hardware.
>> >>>
>> >>> That's called an "access control list" (ACL), and doesn't account
>> for IP
>> >>> spoofing attacks. It's a very old model of security, and isn't
>> generally
>> >>> considered sufficient even on LANs these days (esp. given many LANs
>> are
>> >>> wireless and open).
>> >>>
>> >>>   >  Moreover, information about some devices can be restricted
>> >>>> to be transferred.
>> >>>
>> >>> Also part of ACLs...
>> >>>
>> >>>> I think at the moment the implementation of HCTP is quite
>> troubleful -
>> >>>> I am going to make it command-based, like FTP e. g..
>> >>>
>> >>> XML can support that sort of command/response model very easily,
>> FWIW.
>> >>>
>> >>>> Finally, it seems that there is no OPS WG, I just ca't found it on
>> the
>> >>>> IETF site.
>> >>>
>> >>> OPS is an area; you might contact the ADs there to see what advice
>> they
>> >>> might have. Overall, however, there appear to be many other options
>> that
>> >>> should be considered (MIBs, XML over TCP, etc.) before this
>> protocol is
>> >>> ready for broader IETF review, IMO.
>> >>>
>> >>> Joe
>> >>>
>> >>>>
>> >>>> Waiting for an answer,
>> >>>> Mykyta Yevstifeyev
>> >>>> 2010/11/2, Joe Touch<[email-masked]>:
>> >>>>> Hi, Mykyta,
>> >>>>>
>> >>>>> This document doesn't appear to be in-scope for INT area. It
>> looks like
>> >>>>> an application protocol running over UDP. At best, it would be
>> more
>> >>>>> relevant to the OPS WG.
>> >>>>>
>> >>>>> There are a bunch of questions that are fairly obvious, though:
>> >>>>>
>> >>>>> - why not use any of existing protocols to obtain this info?
>> >>>>> The easiest and most obvious would be to describe the info as an
>> XML
>> >>>>> profile, and use HTTP to retrieve it. Note that this doesn't mean
>> you
>> >>>>> need to run it over port 80, though; there are many custom
>> protocols
>> >>>>> that exchange information like this over other assigned ports
>> using
>> >>>>> HTTP
>> >>>>> and XML.
>> >>>>>
>> >>>>> - why do this over UDP?
>> >>>>> The messages are limited in size, can be fragmented, lost, etc.
>> If you
>> >>>>> use TCP you avoid those issues, and don't need to 'compress' the
>> format
>> >>>>> by using bitfields (and thus can consider more than 32 kinds of
>> device
>> >>>>> components)
>> >>>>>
>> >>>>> - why would anyone allow this service?
>> >>>>> Exposing this information seems to give exactly the detail needed
>> to
>> >>>>> attack a machine. Also, there is no security in your protocol -
>> no
>> >>>>> signatures, no hashes, etc. This seems like a security nightmare.
>> >>>>>
>> >>>>> - why is this even useful?
>> >>>>> My machine can support dozens of video resolutions; what do I
>> respond?
>> >>>>> I
>> >>>>> have a variable clockrate CPU, and often run OS's in virtual
>> partitions
>> >>>>> (with variable amounts of other resources) - what does that mean
>> to
>> >>>>> you?
>> >>>>> Why do you even care?
>> >>>>>
>> >>>>> Joe
>> >>>>>
>> >>>>> On 11/2/2010 8:11 AM, Mykyta Yevstifeyev wrote:
>> >>>>>> Hello!
>> >>>>>>
>> >>>>>> I have recently made an Internet-Draft 'draft-yevstifeyev-hctp'
>> >>>>>> defining Hardware Configuration transfer Protocol. I think
>> >>>>>> the Internet area WG is the best place to discuss it. So
>> >>>>>> please review the I-D (find it here, please
>> >>>>>>
>> >>>>>> https://datatracker.ietf.org/doc/draft-yevstifeyev-hctp/
>> >>>>>>
>> >>>>>> )
>> >>>>>>
>> >>>>>> Thank you very much for your time.
>> >>>>>>
>> >>>>>> Mykyta Yevstifeyev
>> >>>>>> _______________________________________________
>> >>>>>> Int-area mailing list
>> >>>>>> [email-masked]
>> >>>>>> https://www.ietf.org/mailman/listinfo/int-area
>> >>>>>
>> >>>
>> >>> Hi, all, some other notes...
>> >>>
>> >>> On 11/3/2010 8:41 AM, Mykyta Yevstifeyev wrote:
>> >>>> I have read this notices. Thank you for them. Let me explain
>> >>>> some mentioned issues.
>> >>>>
>> >>>> The current version of HCTP is very difficult to imply.
>> >>>> I think it would be a better idea to make it command-based
>> >>>> (like FTP) and using TCP. However I intend to make
>> >>>> curent version 'alternative' and another one - main.
>> >>>>
>> >>>> I tried to make a protocol really diffferent from SNMP.
>> >>>> That is an answer to one of your notices.
>> >>>
>> >>> What we need to understand (not necessarily on this list, but in a
>> >>> revision to your doc) is how is your protocol different from SNMP
>> (other
>> >>> than line encoding, which is more compact but also more limiting)?
>> >>>
>> >>> Also, even if it is different, why? what's the benefit of being
>> >>> different, and is it worth the cost.
>> >>>
>> >>> Joe
>> >>>
>> >
>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Sat, 6 Nov 2010 09:53:42 +0100

> of the I-D - so when I will submit it - I'l tell you.

I think SNMP and the HOST-RESOURCES-MIB and the ENTITY-MIB have solved
this problem already.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: Mykyta Yevstifeyev <[email-masked]>
Date: Sat, 6 Nov 2010 19:09:28 +0200

Hello,

To my mind SNMP is not very easy in the plan of implementation -
so I proposed the simplier protocol with a 'narrower' possibilities.

Mykyta Yevstifeyev

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Sun, 7 Nov 2010 04:45:06 +0100

Hi Mykyta,

Can you explain what you mean by 'not very easy in the plan of implementation' means, and why a new protocol would be easier compared to a protocol which has 20 years of implementation experience on all kinds of targets and environments, and tools to write, test, and debug? 

Thanks and Regards,

Dan

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Mykyta Yevstifeyev
> Sent: Saturday, November 06, 2010 7:09 PM
> To: Juergen Schoenwaelder; Mykyta Yevstifeyev; 
> [email-masked]; Ronald Bonica; Joe Touch; Stephane 
> Bortzmeyer; [email-masked]; Henk Uijterwaal
> Subject: Re: [Int-area] [OPSAWG] Fwd: Please review my Internet Draft
> 
> Hello,
> 
> To my mind SNMP is not very easy in the plan of 
> implementation - so I proposed the simplier protocol with a 
> 'narrower' possibilities.
> 
> Mykyta Yevstifeyev
> 
> >> I have recently writtent to INTAREA Working Group for reviewing my 
> >> Internet-Draft. However I was advised to write to OPS area WG. You 
> >> will gind the link to the I-D below in the 'history' of messaging 
> >> among the INTAREA WG.
> >> At the moment I am planning to make a new version of the I-D - so 
> >> when I will submit it - I'l tell you.
> >