Re: some thoughts on IPv6-over-IPv6CS (was: [16NG] Re: review of the new revision (ipv6 over ipcs))

[Alexandru Petrescu <[e-mail]>]

Basavaraj Patil wrote:
> Alex,
> 
> Why don't you try and implement the I-D first? All I see from you is 
> non-constructive comments. I think the chairs, ADs and the IESG will 
> form their own opinion about the track for this I-D. And since when 
> is it required that a standards track RFC MUST specify "n" number of 
> MUSTS and SHOULDS and MAYS.

Raj, I gave one opinion and I respect opinion of WG members and decision
by WG Chairs and AD.

About non-constructive comments: I gave several constructive comments
several times (entry procedure enhanced, RA bit, etc), including my
support to advance this document to delivery to IESG.  What you seem to
react to is its status (your remark on n MUSTs).  If you wish we can
discuss its status.

> Other comments inline:
> 
> On 1/24/07 12:49 PM, "ext Alexandru Petrescu" 
> <[e-mail]> wrote:
> 
>> Raj, Jari, thanks for having this exchange public on the mailing 
>> list.
>> 
>> I will precede this mail with a high-level unease I have about 
>> advancement of this draft towards a Standards Track RFC.  This can 
>> be solved by several ways, eg change its name into 'Goals for ...' 
>> or maybe change status, or other way one may think of.  The draft 
>> is definitely well written, complete in its own and self-contained,
>>  a piece of text worth the effort to submit to IESG.
>> 
>> Usually a a Standards Track RFC gives clear directions about what 
>> should be implemented.  This document doesn't: there's no new 
>> message format, no new message exchange, no new issues with other 
>> implementation, 'MUST' occurs only two times and it's for lifetimes
>>  in RA - no new lifetime in RA suggested, 'SHOULD' appears once to 
>> say MTU should be what 2460 recommends (which is good), 'MAY' never
>>  appears.  It doesn't offer a implementer anything special that 
>> should be done about running an existing IPv6 stack over a new kind
>>  of link (802.16 IPv6CS in this case, allow me the term IPv6CS).
> 
> There is nothing special needed for an implementer other than what is
>  stated in the I-D.
> 
>> Section 2 Introduction describes what the IEEE standard describes. 
>> It also describes what WiMax thinks the architecture should be.
>> 
>> Section 3 Terminology describes a new term 'ASN' which is a WiMax 
>> term.
>> 
>> Sections 4 and 5 are architectural descriptions, from IEEE 
>> documents.
> 
> So whats your point above other than the fact that you have read the 
> document and noted the section numbers and their content?

YEs, one point is to show I've read it.  Often I'm asked to read, so
I've tried to avoid this recommendation.

The second point is that there's nothing to be implemented in these
sections.

>> One very important part in Section 4, giving indication to which 
>> specific part to use when putting IPv6 packets on 802.16 MAC (ETHCS
>>  or IPv6CS?) is left implementation-dependent (who implements that?
>>  how?) - is there an RA-overIPv6CS enhancement that says use ETHCS 
>> vs use IPv6CS.
> 
> As I said IPv6 can be run over 802.3 (which runs on the EthCS) or 
> directly over the IPv6 CS. The choice depends on the host. The 
> clarification that has been put in is the fact that the network will 
> need to support both. And that is sufficient.

How does the network 'support' both?  How does the network switch
between the two modes?  That is left implementation-dependent.  Or this
implementation should follow this spec.

Constructive comment: the spec could specify a means in an ICMPv6
message enhancement to change between the modes.  I suggest one bit only.

>> Section 6 'IPv6 link' makes recommendation about how to configure 
>> things, but nothing to implement.
>> 
>> Section 6.2 'IPv6 link establishment' which is the 802.16 
>> network-entry procedure.  What should the IPv6 stack implementer 
>> write?
> 
> Nothing.

Ok, so nothing to write about the network entry procedure.  Maybe
something to configure then.

Constructive comment: I suggest IPv6CS to offer configuration parameters
to the IPv6 stack, such that the IPv6 stack can enable/disable the use
of some features.  For example, PANA does auth at IP level, so the IP
stack could request disabling of the PKM MAC-layer auth features and
message exchanges.

This can happen as an extension to the BSD Socket interface.

>> Section 6.3 'MTU' says MTU should be what it should be.  This is a 
>> good goal, but what to implementer means?
> 
> I do not see anything in this section that would not be 
> understandable by an IPv6 implementer.

YEs, it is, understandable, complete description, agreed in the WG.  The
comment is that an IPv6 stack implementer doesn't have to do anything
special about MTU to run on IPv6CS.  This is good - less work.

>> Section 7 "IPv6 Prefix Assignment" recommends each mobile to be on 
>> a different prefix.  This is (1) different than any other 
>> IPv6-over-foo documents (and there are other point-to-point links 
>> out there not recommending this) and (2) a configuration management
>>  issue, nothing to be implemented.
>> 
>> Section 8 "Router Discovery" is standard behaviour nothing new, 
>> nothing to implement.
>> 
>> Section 9 "IPv6 addressing for hosts" - nothing new.  I could think
>>  of SeND issues with the MS having the same link-local address on 
>> all its 802.16 connections (subnets) but that's all.
>> 
>> These are the reasons I have that uneases.  That said, let me 
>> address the point where I was cited, see below.
> 
> Point about your uneasiness noted. Can we move on?

YEs, thanks about noting my point.  Let's move on.

Alex

_______________________________________________
16NG mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/16ng