Re: Extra comments - I-D ACTION:draft-clausen-ipdvb-enc-00.txt

[Dr G Fairhurst <gorry@erg.abdn.ac.uk>]

Haitham Cruickshank wrote:
> 
> Hi Everybody,
> 
<<snip>>
> 
> Back to the draft, I think the new draft looks good and I had been
> following the recent discussions.  I have few extra comments and I hope
> it will improve the final version:
> 
> * A table of content is missing in the beginning.

OK - we can fix that, I'll add it to the list.

> * A Security Considerations section is missing.  I would like to
> contribute to this section, but I am not sure about the issues.  Has
> anybody thought about any security problems, then I could make some
> comments.

Actually, it is there - section 8, but doesn't suggest any issues.
Are there issues we should talk about?

> * I think it will be beneficial to add a small section about the main
> problems with current MPE (such as large overheads and complex options,
> implementation compatibility, etc ..) and provide a brief comparison
> with the new leaner encapsulation.  This will help a lot the people who
> are not familiar with MPE.

I disagree - in that this is a protocol spec, however we wondered
whether to update the requirements ID:

or should we create a new ID with this infromation?

> * Finally I have two a basic comment:
> 1. The size of "type" field in the SNDU encapsulation format (figure
> 1).  Why do we have to stick with two bytes size (16 bits) where the
> types are only 4 types only (ipv4, ipv6, mpls and Br. Ethernet)

But, it's not clear to me, there may be some more...

e.g. there are two different MAC bridge encapsulations in use elsewhere
in the internet and, we *DO* plan to support ROHC.

> 2. Is there really a need for CRC ?

A dificult one. It would seem that bit errors should be rare, due to the
under-lying coding in most cases. But the IETF has previously suggested 
we should be certain there are no undetected bit errors to the same
level of certaintity as a 32-bit CRC would give.  So, my main worry
is reassembly bugs and hardware-related transfer problems, rather than
the physical channel. Recent experience shows we should NOT ignore such
things, they happen often in IP Routers, so why not here? I personnaly
would advocate at least a CRC-16.

> 
> Regards
> Haitham
> --
> Dr. Haitham S. Cruickshank
> 
> Senior Research Fellow in Communications
> Centre for Communication Systems Research (CCSR)
> School of Electronics, Computing and Mathematics
> University of Surrey
> Guildford, Surrey GU2 7XH, UK
> 
> Tel: +44 1483 686007 (indirect 689844)
> Fax: +44 1483 686011
> e-mail: H.Cruickshank@surrey.ac.uk
> http://www.ee.surrey.ac.uk/Personal/H.Cruickshank/