Re: [16NG] IESG Comments on draft-ietf-16ng-ip-over-ethernet-over-802-dot-16

[Hongseok Jeon <[e-mail]>]

Dear Jari,
I have submitted the draft.
Please find it at the following URL.

http://www.ietf.org/internet-drafts/draft-ietf-16ng-ip-over-ethernet-over-802-dot-16-12.txt

Best Regards,
Hongseok Jeon

On Fri, Sep 18, 2009 at 2:25 AM, Jari Arkko <[e-mail]> wrote:

> Please submit the draft and I'll check if there's anything that remains.
> But this sounds good in general.
>
> Jari
>
>
> Riegel, Maximilian (NSN - DE/Munich) wrote:
>
>> When checking the datatracker
>> https://datatracker.ietf.org/idtracker/draft-ietf-16ng-ip-over-ethernet-
>> over-802-dot-16/ I found the following open comments from last weeks
>> IESG discussions.
>>
>> Meanwhile we have prepared a new revision of the I-D addressing the
>> issues. We are ready to submit the revised I-D and would like to clarify
>> that we really solved the issues.
>>
>> Bye
>> Max
>> pls see inline
>>
>>
>>
>>> Date: 2009-09-10, 04:24:05 Document:
>>> draft-ietf-16ng-ip-over-ethernet-over-802-dot-16 Version: 11 Commented by:
>>> Jari Arkko Comment: [IESG Evaluation DISCUSS] The document is now in quite
>>> good shape -- there's been progress
>>> since the previous versions! I did have a few issues, though:
>>>
>>> Here the conclusion is right but the rationale needs a bit work:
>>>
>>>
>>>
>>>> According to [RFC4861], a link is defined as a communication
>>>>
>>>>
>>> facility
>>
>>
>>> or medium over which IP devices can communicate at the link layer,
>>>> i.e. the layer immediately below IP.  Ethernet fully satisfies the
>>>> definition of the link.  IEEE 802.16, however, has limitations on
>>>>
>>>>
>>> its
>>
>>
>>> transitive connectivity, i.e.  IEEE 802.16 provides point-to-point
>>>> connections between SSs and the BS but does not enable any direct SS
>>>> to SS connectivity.  Hence, it is required to bridge each of the
>>>> point-to-point connections between SSs and the BS so that Ethernet
>>>>
>>>>
>>> is
>>
>>
>>> realized over IEEE 802.16 access network.
>>>>
>>>>
>>> Here's a piece of Ethernet technology that has the same limitations as
>>> 802.16:
>>>
>>> - it is point to point
>>> - it doesn't do multicast
>>> - it has limitations with regards to host - host connectivity
>>>  unless your nic supports either straight and twisted cables
>>>
>>> http://www.ccrane.com/images/medium/cat-5e-ethernet-cable.jpg
>>>
>>>
>>
>> Great! And congratulation. This is the best explanation of the IEEE
>> 802.16 link model which I have ever seen.
>>
>>
>>
>>> But I do agree, of course, that bridging is required. I would suggest
>>> however that the paragraph be reworded to:
>>>
>>>   Like in today's wired Ethernet networks, bridging is required to
>>>   implement connectivity between more than two devices. In 802.16,
>>>
>>>
>> the
>>
>>
>>>   point-to-point connections between SSs and the BS can be bridged
>>>   so that Ethernet is realized over IEEE 802.16 access network.
>>>
>>>
>>
>> Your proposal is much shorter and hits the point. We included the
>> proposed text
>> instead of the previous wording.
>>
>>
>>
>>> The network-side bridging function SHOULD create a new radio side
>>>> port whenever a new SS attaches to any of the BSs of the network or
>>>> SHOULD remove a radio side port when an associated SS detaches from
>>>> the BSs.
>>>>
>>>>
>>> Wouldn't this be more of a case for a MUST than a SHOULD? This is
>>>
>>>
>> basic
>>
>>
>>> functionality for 802.16 Ethernet.
>>>
>>>
>>
>> Agreed. It is the essential behavior of the bridge. MUST is more
>> appropriate.
>> We changed SHOULD to MUST in the new revision of the I-D.
>>
>>
>>
>>> The generic IP over Ethernet network scenario assumes that all hosts
>>>> are residing on the same link with trust relationship between all of
>>>> them.
>>>>
>>>>
>>> I'm not sure why we need to assume a trust relationship here. I would
>>> suggest deleting everything from word "link" onwards.
>>>
>>>
>>
>> We are mentioning here trust relationship, because it is the main
>> difference to the public access case, where direct communication on the
>> link layer is prevented to protect other hosts on the same link from
>> malicious attacks. For the plain Ethernet functionality, trust
>> relationship is not required. We deleted as you proposed.
>>
>>
>>
>>> All multicast and multicast control messages SHOULD be processed in
>>>> the network-side bridging function according to [RFC4541].
>>>>
>>>>
>>> This is a fine requirement, except for 4541 being an informational
>>> document and this spec being proposed standard. I would like to change
>>> this and similar recommendations in Section 7 to a different wording.
>>> Say, "can" instead of "SHOULD". Alternatively, we could call out this
>>> downref in a Last Call, but AFAICT this was not done in the last call
>>> we just had.
>>>
>>> Same for RFC 4562 references.
>>>
>>>
>>
>> We changed "SHOULD" to "can". We know about the difficulty to make
>> normative references to informative specifications. If "can" allows us
>> to point to the Informational RFCs, we are fine.
>>
>>
>>
>>> --------------------------
>>> Date: 2009-09-08, 07:18:44 Document:
>>> draft-ietf-16ng-ip-over-ethernet-over-802-dot-16 Version: 10 Commented by:
>>> Magnus Westerlund Comment: [IESG Evaluation COMMENT] Section 5.2, 7.1:
>>>
>>> I wonder why these section puts the requirement level on SHOULD and
>>>
>>>
>> not a MUST?
>>
>>
>>> And what are the reasons/motivation for when it is allowable to not do
>>>
>>>
>> the
>>
>>
>>> action?
>>>
>>>
>>
>> For Section 5.2 (replicating broadcast messages and sending them unicast
>> to all hosts) we used 'SHOULD', because later in the document we
>> describe, when this rule should not be followed.
>>
>> In section 7.1 hints are given to conserve radio resources by
>> selectively processing multicast and broadcast messages. The system
>> still works even when not all of the hints are adopted. Furthermore some
>> of the hints are from Informational RFCs, which makes it difficult to
>> use 'MUST' (see Jari's comment above).
>>
>> I hope we were able to sufficiently address all the remaining issues of
>> the document. If yes, we will submit the revised I-D to the IETF.
>>
>> Bye
>> Max
>>
>>
>>
>
>