Subject: [16ng] WGLC : draft-ietf-16ng-ps-goals-00 - REMIND

From: Soohong Daniel Park <[email-masked]>
Date: Wed, 25 Oct 2006 13:21:36 +0900

Remind,

One week remains, but no comments happen on the list. 

Please take a look at the deliverable, then let us know
your good comments and feedbacks on that. 

Thanks in advance.

Daniel (Soohong Daniel Park)
Mobile Convergence Laboratory, SAMSUNG Electronics.

----- Original Message ----- 
From: "Soohong Daniel Park" <[email-masked]>
To: <[email-masked]>
Sent: Tuesday, October 17, 2006 9:19 AM
Subject: [16ng] WGLC : draft-ietf-16ng-ps-goals-00

> Folks,
> 
> This is a two week WGLC on draft-ietf-16ng-ps-goals-00.
> 
> Please review the I-D and submit your comments to the authors or to
> the list directly. The WGLC will exipre on October 31 (Pacific Time).
> 
> o I-D: http://www.ietf.org/internet-drafts/draft-ietf-16ng-ps-goals-00.txt
> 
> o Intended publication: Informational RFC
> 
> 
> -- 
> 
> 
> Daniel (Soohong Daniel Park)
> Mobile Convergence Laboratory, SAMSUNG Electronics.
> _______________________________________________
> 16ng mailing list
> [email-masked]
> http://eeca16.sogang.ac.kr/mailman/listinfo/16ng
> 
>
>From [email-masked] Wed Oct 25 14:55:06 2006
Date: Wed, 25 Oct 2006 12:30:43 +0800
From: wenson <[email-masked]>
Subject: Re: [16ng] WGLC: draft-ietf-16ng-ipv6-link-model-analysis-00
To: "Riegel, Maximilian" <[email-masked]>
cc: Qin Alice <[email-masked]>
cc: [email-masked]

This is a multi-part message in MIME format.

--Boundary_(ID_9Hmwni689YcMg2tSNGF1YA)
Content-type: text/plain; charset=iso-8859-1
Content-transfer-encoding: 7BIT

Hi,Max:
Thanks for your reply. Andyway,I have some questions about your daft, i.e, 
draft-riegel-16ng-ip-over-eth-over-80216-01.txt
In section 3.5, it wrote:
>>Without implementation of the special multicast and broadcast
>>channels in IEEE802.16 all multicast and broadcast packets have to be
>>transferred over unicast connections to each SS causing radio
>>resources redundantly be used for transmission of the same information.  
 So my question is:
Does it mean that upon receiving multicast packet, BS will forward packet over unicast connection?
Is there any approach to implement special multicast and broadcast channels to reduce radio resources overhead until now?

In section 3.4, it wrote:
>>Downlink connections can be shared among multiple SSs, enabling
>>multicast channels with multiple SSs receiving the same information
>>from the BS.  Multicast is not enabled in the uplink but must be
>>realized by an entity on top the IEEE802.16 MAC sending packets
>>received on a unicast uplink downstream on a multicast channel.
why is Multicast not enabled in the uplink but realized by an entity on top the IEEE802.16 MAC?
what is the difference between downlink connection and uplink connection?

In section 4.1.1, it wrote:
>>When performing Standard Learned Bridging, the SS or BS shall learn
>>all source MAC addresses originating from a port up to MAXMSIP
>>individual learned addresses.  The accumulation of all learned MAC to
>>port associations constitutes the Learned Bridge Table.
Since data link connections between each of the SS and the BS are built and identified 
as one 16 bit connection Identifier, why should BS support ARP and use MAC in IPv4 packet processing?
Since introducing ARP mechanism, why not realize native MBS function? what do you think of it? 

Wenson 
  ----- Original Message ----- 
  From: Riegel, Maximilian 
  To: wenson 
  Cc: Qin Alice ; [email-masked] ; Soohong Daniel Park 
  Sent: Tuesday, October 24, 2006 7:15 PM
  Subject: RE: [16ng] WGLC: draft-ietf-16ng-ipv6-link-model-analysis-00

  Wenson,

  You may find answers to your questions in the just released I-D
  draft-riegel-16ng-ip-over-eth-over-80216-01.txt

  The Ethernet link model for IEEE802.16 does not make use of the native MBS function in IEEE802.16 for broadcast and all hosts multicast, as MBS is less efficient than unicast and special processing in the bridge.

  Direkt host-to-host communication is only enabled as a configurable option in VLAN scenario between members of a particular VLAN. Otherwise all communication is passing through the AR to allow for interception and accounting by the AR.

  Broadcast and Multicast is realized in the bridge behind BS over unicast connections to the MSs with special filtering taking place to prevent from wasting transmission and power resources.

  Bye
  Max

------------------------------------------------------------------------------
  From: [email-masked] [mailto:[email-masked]] On Behalf Of wenson
  Sent: Tuesday, October 24, 2006 6:02 AM
  To: Soohong Daniel Park
  Cc: Qin Alice; [email-masked]
  Subject: Re: [16ng] WGLC: draft-ietf-16ng-ipv6-link-model-analysis-00

  Hi Daniel:

  As far as I concern, the link models can be categorized based on three network topology  modes ,i.e., point to point, point to multiple points and multiple points and multipoints. Different topology mode can be deployed in different scenario. 

  >>>In section 3.3.4.2, it said:

  >>>in case of bridging, direct inter-MSs communication may not be not allowed due to restrictions from the service providers.  

  So my questions is

  1.If MSs are served by the same service providers and located below the same BS(i.e., connect to the same BS), Do they communicate with each other?

  2. In Ether like link model, there are several BS attached the same ether Switch device and also there are several MS attached the same BS, how does BS process multicast packet from AR beyond ether Switch and forward the processed packet to each MS who is located below BS?

  ***maybe multicast capability is limited not between MS and AR but between BS and AR, what do you think of it? 

  3. As Above said, how Ether switch or bridge work to support multicast capability?

  ----- Original Message ----- 
  From: "Soohong Daniel Park" <[email-masked]>
  To: <[email-masked]>
  Sent: Thursday, October 12, 2006 5:20 PM
  Subject: [16ng] WGLC: draft-ietf-16ng-ipv6-link-model-analysis-00

  > Folks,
  > 
  > This is a two week WGLC on draft-ietf-16ng-ipv6-link-model-analysis-00.
  > 
  > Please review the I-D and submit your comments to the authors or to
  > the list directly. The WGLC will exipre on October 26 (Pacific Time).
  > 
  > o I-D: http://www.ietf.org/internet-drafts/draft-ietf-16ng-ipv6-link-model-analysis-00.txt
  > 
  > o Intended publication: Informational RFC
  > 
  > -- 
  > 
  > 
  > Daniel (Soohong Daniel Park)
  > Mobile Convergence Laboratory, SAMSUNG Electronics.
  > _______________________________________________
  > 16ng mailing list
  > [email-masked]
  > http://eeca16.sogang.ac.kr/mailman/listinfo/16ng
  > 

--Boundary_(ID_9Hmwni689YcMg2tSNGF1YA)
Content-type: text/html; charset=iso-8859-1
Content-transfer-encoding: 7BIT

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML xmlns:o = "urn:schemas-microsoft-com:office:office" xmlns:st1 = 
"urn:schemas-microsoft-com:office:smarttags"><HEAD>
<META http-equiv=Content-Type content="text/html; charset=iso-8859-1">
<META content="MSHTML 6.00.2900.2963" name=GENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=#ffffff>
<DIV><FONT face=&#23435;&#20307; size=2>Hi,Max:</FONT></DIV>
<DIV><FONT face=&#23435;&#20307; size=2>Thanks for your reply. Andyway,I have some questions 
about your daft, i.e, 
<DIV dir=ltr align=left><SPAN class=720155310-24102006><SPAN lang=NO-BOK 
style="FONT-SIZE: 10pt; FONT-FAMILY: Gulim"><FONT face="Courier New" 
color=#000080>draft-riegel-16ng-ip-over-eth-over-80216-01.txt</FONT></SPAN></SPAN></DIV></FONT></DIV>
<DIV><FONT face=&#23435;&#20307; size=2>In section 3.5, it wrote:</FONT></DIV>
<DIV><FONT face=&#23435;&#20307; size=2>&gt;&gt;Without implementation of the special 
multicast and broadcast<BR>&gt;&gt;channels in IEEE802.16 all multicast and 
broadcast packets have to be<BR>&gt;&gt;transferred over unicast connections to 
each SS causing radio<BR>&gt;&gt;resources redundantly be used for transmission 
of the same information.&nbsp; </FONT></DIV>
<DIV>&nbsp;<FONT face=&#23435;&#20307; size=2>So my question is:</FONT></DIV>
<DIV><FONT face=&#23435;&#20307; size=2>Does it mean that upon receiving multicast packet, BS 
will forward packet over unicast connection?</FONT></DIV>
<DIV><FONT face=&#23435;&#20307; size=2>Is there any approach to implement special multicast 
and broadcast channels to reduce radio resources overhead until 
now?</FONT></DIV>
<DIV><FONT face=&#23435;&#20307; size=2></FONT>&nbsp;</DIV>
<DIV><FONT face=&#23435;&#20307; size=2>In section 3.4, it wrote:</FONT></DIV>
<DIV><FONT face=&#23435;&#20307; size=2>&gt;&gt;Downlink connections can be shared among 
multiple SSs, enabling<BR>&gt;&gt;multicast channels with multiple SSs receiving 
the same information<BR>&gt;&gt;from the BS.&nbsp; Multicast is not enabled in 
the uplink but must be<BR>&gt;&gt;realized by an entity on top the IEEE802.16 
MAC sending packets<BR>&gt;&gt;received on a unicast uplink downstream on a 
multicast channel.</FONT></DIV>
<DIV><FONT face=&#23435;&#20307; size=2>why is Multicast&nbsp;not enabled in the uplink but 
realized by an entity on top the IEEE802.16 MAC?</FONT></DIV>
<DIV><FONT face=&#23435;&#20307; size=2>what is the difference between downlink connection and 
uplink connection?</FONT></DIV>
<DIV><FONT face=&#23435;&#20307; size=2></FONT>&nbsp;</DIV>
<DIV><FONT face=&#23435;&#20307; size=2>In section 4.1.1, it wrote:</FONT></DIV>
<DIV><FONT face=&#23435;&#20307; size=2>&gt;&gt;When performing Standard Learned Bridging, the 
SS or BS shall learn<BR>&gt;&gt;all source MAC addresses originating from a port 
up to MAXMSIP<BR>&gt;&gt;individual learned addresses.&nbsp; The accumulation of 
all learned MAC to<BR>&gt;&gt;port associations constitutes the Learned Bridge 
Table.</FONT></DIV>
<DIV><FONT face=&#23435;&#20307; size=2>Since data link connections between each of the SS and 
the BS&nbsp;are built and identified </FONT></DIV>
<DIV><FONT face=&#23435;&#20307; size=2>as one 16 bit connection Identifier, why 
should&nbsp;BS support ARP and use MAC in IPv4 packet processing?</FONT></DIV>
<DIV><FONT face=&#23435;&#20307; size=2>Since introducing ARP mechanism, why not realize 
native MBS function? what do you think of it?&nbsp;</FONT></DIV>
<DIV><FONT face=&#23435;&#20307; size=2></FONT>&nbsp;</DIV>
<DIV><FONT face=&#23435;&#20307; size=2>Wenson</FONT>&nbsp;</DIV>
<BLOCKQUOTE 
style="PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
  <DIV style="FONT: 9pt &#23435;&#20307;">----- Original Message ----- </DIV>
  <DIV style="BACKGROUND: #e4e4e4; FONT: 9pt &#23435;&#20307;; font-color: black"><B>From:</B> 
  <A title=[email-masked] 
  href="mailto:[email-masked]">Riegel, Maximilian</A> </DIV>
  <DIV style="FONT: 9pt &#23435;&#20307;"><B>To:</B> <A title=[email-masked] 
  href="mailto:[email-masked]">wenson</A> </DIV>
  <DIV style="FONT: 9pt &#23435;&#20307;"><B>Cc:</B> <A title=[email-masked] 
  href="mailto:[email-masked]">Qin Alice</A> ; <A 
  title=[email-masked] 
  href="mailto:[email-masked]">[email-masked]</A> ; <A 
  title=[email-masked] href="mailto:[email-masked]">Soohong Daniel 
  Park</A> </DIV>
  <DIV style="FONT: 9pt &#23435;&#20307;"><B>Sent:</B> Tuesday, October 24, 2006 7:15 PM</DIV>
  <DIV style="FONT: 9pt &#23435;&#20307;"><B>Subject:</B> RE: [16ng] WGLC: 
  draft-ietf-16ng-ipv6-link-model-analysis-00</DIV>
  <DIV><BR></DIV>
  <DIV dir=ltr align=left><SPAN class=720155310-24102006><FONT 
  face="Courier New" color=#000080 size=2>Wenson,</FONT></SPAN></DIV>
  <DIV dir=ltr align=left><SPAN class=720155310-24102006><FONT 
  face="Courier New" color=#000080 size=2></FONT></SPAN>&nbsp;</DIV>
  <DIV dir=ltr align=left><SPAN class=720155310-24102006><FONT 
  face="Courier New" color=#000080 size=2>You may find answers to your questions 
  in the just released I-D</FONT></SPAN></DIV>
  <DIV dir=ltr align=left><SPAN class=720155310-24102006><SPAN lang=NO-BOK 
  style="FONT-SIZE: 10pt; FONT-FAMILY: Gulim"><FONT face="Courier New" 
  color=#000080>draft-riegel-16ng-ip-over-eth-over-80216-01.txt</FONT></SPAN></SPAN></DIV>
  <DIV dir=ltr align=left><SPAN class=720155310-24102006><SPAN lang=NO-BOK 
  style="FONT-SIZE: 10pt; FONT-FAMILY: Gulim"><FONT face="Courier New" 
  color=#000080 size=2></FONT></SPAN></SPAN>&nbsp;</DIV>
  <DIV dir=ltr align=left><SPAN class=720155310-24102006><SPAN lang=NO-BOK 
  style="FONT-SIZE: 10pt; FONT-FAMILY: Gulim"><FONT face="Courier New" 
  color=#000080>The Ethernet link model for IEEE802.16 does not make use of the 
  native MBS function in IEEE802.16 for broadcast and all hosts multicast, as 
  MBS is less efficient than unicast and special processing in the 
  bridge.</FONT></SPAN></SPAN></DIV>
  <DIV dir=ltr align=left><SPAN class=720155310-24102006><SPAN lang=NO-BOK 
  style="FONT-SIZE: 10pt; FONT-FAMILY: Gulim"><FONT face="Courier New" 
  color=#000080></FONT></SPAN></SPAN>&nbsp;</DIV>
  <DIV dir=ltr align=left><SPAN class=720155310-24102006><SPAN lang=NO-BOK 
  style="FONT-SIZE: 10pt; FONT-FAMILY: Gulim"><FONT face="Courier New" 
  color=#000080>Direkt host-to-host communication is only enabled as a 
  configurable&nbsp;option in VLAN scenario&nbsp;between members of a particular 
  VLAN. </FONT></SPAN></SPAN><SPAN class=720155310-24102006><SPAN lang=NO-BOK 
  style="FONT-SIZE: 10pt; FONT-FAMILY: Gulim"><FONT face="Courier New" 
  color=#000080>Otherwise all communication is passing through the AR to allow 
  for interception and accounting&nbsp;by the AR.</FONT></SPAN></SPAN></DIV>
  <DIV dir=ltr align=left><SPAN class=720155310-24102006><SPAN lang=NO-BOK 
  style="FONT-SIZE: 10pt; FONT-FAMILY: Gulim"><FONT face="Courier New" 
  color=#000080></FONT></SPAN></SPAN>&nbsp;</DIV>
  <DIV dir=ltr align=left><SPAN class=720155310-24102006><SPAN lang=NO-BOK 
  style="FONT-SIZE: 10pt; FONT-FAMILY: Gulim"><FONT face="Courier New" 
  color=#000080>Broadcast and Multicast is realized in the bridge behind BS over 
  unicast connections to the MSs with special filtering taking place to prevent 
  from wasting transmission and power resources.</FONT></SPAN></SPAN></DIV>
  <DIV dir=ltr align=left><SPAN class=720155310-24102006><SPAN lang=NO-BOK 
  style="FONT-SIZE: 10pt; FONT-FAMILY: Gulim"></SPAN></SPAN>&nbsp;</DIV>
  <DIV dir=ltr align=left><SPAN class=720155310-24102006><SPAN lang=NO-BOK 
  style="FONT-SIZE: 10pt; FONT-FAMILY: Gulim">Bye</SPAN></SPAN></DIV>
  <DIV dir=ltr align=left><SPAN class=720155310-24102006><SPAN lang=NO-BOK 
  style="FONT-SIZE: 10pt; FONT-FAMILY: Gulim">Max</SPAN></SPAN></DIV>
  <DIV dir=ltr align=left><SPAN class=720155310-24102006><SPAN lang=NO-BOK 
  style="FONT-SIZE: 10pt; FONT-FAMILY: Gulim"></SPAN></SPAN>&nbsp;</DIV><BR>
  <DIV class=OutlookMessageHeader lang=en-us dir=ltr align=left>
  <HR tabIndex=-1>
  <FONT face=Tahoma size=2><B>From:</B> [email-masked] 
  [mailto:[email-masked]] <B>On Behalf Of 
  </B>wenson<BR><B>Sent:</B> Tuesday, October 24, 2006 6:02 AM<BR><B>To:</B> 
  Soohong Daniel Park<BR><B>Cc:</B> Qin Alice; 
  [email-masked]<BR><B>Subject:</B> Re: [16ng] WGLC: 
  draft-ietf-16ng-ipv6-link-model-analysis-00<BR></FONT><BR></DIV>
  <DIV></DIV>
  <DIV>
  <P class=MsoNormal 
  style="MARGIN: 0cm 0cm 0pt; LINE-HEIGHT: normal; TEXT-AUTOSPACE: ideograph-numeric; mso-pagination: widow-orphan; mso-layout-grid-align: auto"><SPAN 
  lang=EN-US 
  style="FONT-SIZE: 12pt; LAYOUT-GRID-MODE: both; FONT-FAMILY: &#23435;&#20307;; mso-bidi-font-family: &#23435;&#20307;"><FONT 
  face="Times New Roman">Hi Daniel:<o:p></o:p></FONT></SPAN></P>
  <P class=MsoNormal 
  style="MARGIN: 0cm 0cm 0pt; LINE-HEIGHT: normal; TEXT-AUTOSPACE: ideograph-numeric; mso-pagination: widow-orphan; mso-layout-grid-align: auto"><SPAN 
  lang=EN-US 
  style="FONT-SIZE: 12pt; LAYOUT-GRID-MODE: both; FONT-FAMILY: &#23435;&#20307;; mso-bidi-font-family: &#23435;&#20307;"><FONT 
  face="Times New Roman">As far as I concern, the link models&nbsp;can be 
  categorized based on three&nbsp;network topology &nbsp;modes ,i.e., point to 
  point, point to multiple points and multiple points and multipoints. Different 
  topology mode can be </FONT></SPAN><SPAN lang=EN-US 
  style="FONT-SIZE: 12pt; LAYOUT-GRID-MODE: both; FONT-FAMILY: &#23435;&#20307;; mso-bidi-font-family: &#23435;&#20307;"><FONT 
  face="Times New Roman">deployed in different scenario. 
  <o:p></o:p></FONT></SPAN></P>
  <P class=MsoNormal 
  style="MARGIN: 0cm 0cm 0pt; LINE-HEIGHT: normal; TEXT-AUTOSPACE: ideograph-numeric; mso-pagination: widow-orphan; mso-layout-grid-align: auto"><SPAN 
  lang=EN-US 
  style="FONT-SIZE: 12pt; LAYOUT-GRID-MODE: both; FONT-FAMILY: &#23435;&#20307;; mso-bidi-font-family: &#23435;&#20307;"><FONT 
  face="Times New Roman">&gt;&gt;&gt;In section <st1:chsdate w:st="on" 
  IsROCDate="False" IsLunarDate="False" Day="30" Month="12" 
  Year="1899">3.3.4</st1:chsdate>.2, it said:<o:p></o:p></FONT></SPAN></P>
  <P class=MsoNormal 
  style="MARGIN: 0cm 0cm 0pt; LINE-HEIGHT: normal; TEXT-AUTOSPACE: ideograph-numeric; mso-pagination: widow-orphan; mso-layout-grid-align: auto"><SPAN 
  lang=EN-US 
  style="FONT-SIZE: 12pt; LAYOUT-GRID-MODE: both; FONT-FAMILY: &#23435;&#20307;; mso-bidi-font-family: &#23435;&#20307;"><FONT 
  face="Times New Roman">&gt;&gt;&gt;in case of bridging, direct inter-MSs 
  communication may not be not allowed due to restrictions from the service 
  providers.&nbsp; <o:p></o:p></FONT></SPAN></P>
  <P class=MsoNormal 
  style="MARGIN: 0cm 0cm 0pt; LINE-HEIGHT: normal; TEXT-AUTOSPACE: ideograph-numeric; mso-pagination: widow-orphan; mso-layout-grid-align: auto"><SPAN 
  lang=EN-US 
  style="FONT-SIZE: 12pt; LAYOUT-GRID-MODE: both; FONT-FAMILY: &#23435;&#20307;; mso-bidi-font-family: &#23435;&#20307;"><FONT 
  face="Times New Roman">So my questions is<o:p></o:p></FONT></SPAN></P>
  <P class=MsoNormal 
  style="MARGIN: 0cm 0cm 0pt; LINE-HEIGHT: normal; TEXT-AUTOSPACE: ideograph-numeric; mso-pagination: widow-orphan; mso-layout-grid-align: auto"><SPAN 
  lang=EN-US 
  style="FONT-SIZE: 12pt; LAYOUT-GRID-MODE: both; FONT-FAMILY: &#23435;&#20307;; mso-bidi-font-family: &#23435;&#20307;"><FONT 
  face="Times New Roman">1.If MSs are served by the same service providers and 
  located below the same BS(i.e., connect to the same BS), Do 
  they&nbsp;communicate with each other?<o:p></o:p></FONT></SPAN></P>
  <P class=MsoNormal 
  style="MARGIN: 0cm 0cm 0pt; LINE-HEIGHT: normal; TEXT-AUTOSPACE: ideograph-numeric; mso-pagination: widow-orphan; mso-layout-grid-align: auto"><SPAN 
  lang=EN-US 
  style="FONT-SIZE: 12pt; LAYOUT-GRID-MODE: both; FONT-FAMILY: &#23435;&#20307;; mso-bidi-font-family: &#23435;&#20307;"><FONT 
  face=&#23435;&#20307; size=2></FONT></SPAN>&nbsp;</P>
  <P class=MsoNormal 
  style="MARGIN: 0cm 0cm 0pt; LINE-HEIGHT: normal; TEXT-AUTOSPACE: ideograph-numeric; mso-pagination: widow-orphan; mso-layout-grid-align: auto"><SPAN 
  lang=EN-US 
  style="FONT-SIZE: 12pt; LAYOUT-GRID-MODE: both; FONT-FAMILY: &#23435;&#20307;; mso-bidi-font-family: &#23435;&#20307;"><FONT 
  face="Times New Roman">2. In Ether like link model, there are several BS 
  attached the same ether Switch device and also there are several MS attached 
  the same BS, how does BS process multicast packet from AR beyond ether Switch 
  and forward the processed packet to each MS who is located below 
  BS?</FONT></SPAN></P>
  <P class=MsoNormal 
  style="MARGIN: 0cm 0cm 0pt; LINE-HEIGHT: normal; TEXT-AUTOSPACE: ideograph-numeric; mso-pagination: widow-orphan; mso-layout-grid-align: auto"><SPAN 
  lang=EN-US 
  style="FONT-SIZE: 12pt; LAYOUT-GRID-MODE: both; FONT-FAMILY: &#23435;&#20307;; mso-bidi-font-family: &#23435;&#20307;"><FONT 
  face=&#23435;&#20307; size=2><FONT face="Times New Roman" size=3>***maybe multicast 
  capability is limited not between MS and AR but between BS and AR, what do 
  you&nbsp;think of it?</FONT>&nbsp;</FONT></SPAN></P>
  <P class=MsoNormal 
  style="MARGIN: 0cm 0cm 0pt; LINE-HEIGHT: normal; TEXT-AUTOSPACE: ideograph-numeric; mso-pagination: widow-orphan; mso-layout-grid-align: auto"><SPAN 
  lang=EN-US 
  style="FONT-SIZE: 12pt; LAYOUT-GRID-MODE: both; FONT-FAMILY: &#23435;&#20307;; mso-bidi-font-family: &#23435;&#20307;"><FONT 
  size=2></FONT></SPAN>&nbsp;</P>
  <P class=MsoNormal 
  style="MARGIN: 0cm 0cm 0pt; LINE-HEIGHT: normal; TEXT-AUTOSPACE: ideograph-numeric; mso-pagination: widow-orphan; mso-layout-grid-align: auto"><SPAN 
  lang=EN-US 
  style="FONT-SIZE: 12pt; LAYOUT-GRID-MODE: both; FONT-FAMILY: &#23435;&#20307;; mso-bidi-font-family: &#23435;&#20307;"><FONT 
  face="Times New Roman">3. As Above said, how Ether switch or bridge work to 
  support multicast capability?<o:p></o:p></FONT></SPAN></P></DIV>
  <DIV><FONT face=&#23435;&#20307; size=2><BR></FONT>&nbsp;</DIV>
  <DIV><FONT face=&#23435;&#20307; size=2>----- Original Message ----- </FONT>
  <DIV><FONT face=&#23435;&#20307; size=2>From: "Soohong Daniel Park" &lt;</FONT><A 
  href="mailto:[email-masked]"><FONT face=&#23435;&#20307; 
  size=2>[email-masked]</FONT></A><FONT face=&#23435;&#20307; size=2>&gt;</FONT></DIV>
  <DIV><FONT face=&#23435;&#20307; size=2>To: &lt;</FONT><A 
  href="mailto:[email-masked]"><FONT face=&#23435;&#20307; 
  size=2>[email-masked]</FONT></A><FONT face=&#23435;&#20307; 
  size=2>&gt;</FONT></DIV>
  <DIV><FONT face=&#23435;&#20307; size=2>Sent: Thursday, October 12, 2006 5:20 
PM</FONT></DIV>
  <DIV><FONT face=&#23435;&#20307; size=2>Subject: [16ng] WGLC: 
  draft-ietf-16ng-ipv6-link-model-analysis-00</FONT></DIV></DIV>
  <DIV><FONT face=&#23435;&#20307;><BR><FONT size=2></FONT></FONT></DIV><FONT face=&#23435;&#20307; 
  size=2>&gt; Folks,<BR>&gt; <BR>&gt; This is a two week WGLC on 
  draft-ietf-16ng-ipv6-link-model-analysis-00.<BR>&gt; <BR>&gt; Please review 
  the I-D and submit your comments to the authors or to<BR>&gt; the list 
  directly. The WGLC will exipre on October 26 (Pacific Time).<BR>&gt; <BR>&gt; 
  o I-D: </FONT><A 
  href="http://www.ietf.org/internet-drafts/draft-ietf-16ng-ipv6-link-model-analysis-00.txt"><FONT 
  face=&#23435;&#20307; 
  size=2>http://www.ietf.org/internet-drafts/draft-ietf-16ng-ipv6-link-model-analysis-00.txt</FONT></A><BR><FONT 
  face=&#23435;&#20307; size=2>&gt; <BR>&gt; o Intended publication: Informational RFC<BR>&gt; 
  <BR>&gt; -- <BR>&gt; <BR>&gt; <BR>&gt; Daniel (Soohong Daniel Park)<BR>&gt; 
  Mobile Convergence Laboratory, SAMSUNG Electronics.<BR>&gt; 
  _______________________________________________<BR>&gt; 16ng mailing 
  list<BR>&gt; </FONT><A href="mailto:[email-masked]"><FONT face=&#23435;&#20307; 
  size=2>[email-masked]</FONT></A><BR><FONT face=&#23435;&#20307; size=2>&gt; 
  </FONT><A href="http://eeca16.sogang.ac.kr/mailman/listinfo/16ng"><FONT 
  face=&#23435;&#20307; 
  size=2>http://eeca16.sogang.ac.kr/mailman/listinfo/16ng</FONT></A><BR><FONT 
  face=&#23435;&#20307; size=2>&gt;</FONT> </BLOCKQUOTE></BODY></HTML>

--Boundary_(ID_9Hmwni689YcMg2tSNGF1YA)--
>From [email-masked] Wed Oct 25 17:17:11 2006
Date: Wed, 25 Oct 2006 14:48:57 +0800
From: wenson <[email-masked]>
Subject: Re: [16ng] WGLC : draft-ietf-16ng-ps-goals-00
To: Soohong Daniel Park <[email-masked]>, [email-masked]

Hi,Daniel:
Since there are two cases to be considered, i.e.,IP over 802.16 with IP CS and IP over 802.16 with Ethernet CS, the question is:
what is the essential difference between these two cases?
It seems not clear in demonstrating approach to implement these two cases in different scenarios. 
----- Original Message ----- 
From: "Soohong Daniel Park" <[email-masked]>
To: <[email-masked]>
Sent: Tuesday, October 17, 2006 8:19 AM
Subject: [16ng] WGLC : draft-ietf-16ng-ps-goals-00

> Folks,
> 
> This is a two week WGLC on draft-ietf-16ng-ps-goals-00.
> 
> Please review the I-D and submit your comments to the authors or to
> the list directly. The WGLC will exipre on October 31 (Pacific Time).
> 
> o I-D: http://www.ietf.org/internet-drafts/draft-ietf-16ng-ps-goals-00.txt
> 
> o Intended publication: Informational RFC
> 
> 
> -- 
> 
> 
> Daniel (Soohong Daniel Park)
> Mobile Convergence Laboratory, SAMSUNG Electronics.
> _______________________________________________
> 16ng mailing list
> [email-masked]
> http://eeca16.sogang.ac.kr/mailman/listinfo/16ng
>
>From [email-masked] Wed Oct 25 18:02:11 2006
Date: Wed, 25 Oct 2006 16:37:48 +0900
From: "Soohong Daniel Park" <[email-masked]>
To: wenson <[email-masked]>
Subject: Re: [16ng] WGLC : draft-ietf-16ng-ps-goals-00
cc: [email-masked]

Wenson,

> Since there are two cases to be considered, i.e.,IP over 802.16 with IP CS and IP over 802.16 with Ethernet CS, the question is:
> what is the essential difference between these two cases?
> It seems not clear in demonstrating approach to implement these two cases in different scenarios.

Could you please elaborate on the question more ? The most difference
between them is whether it has a Ethernet functionality or not. When
implementing IPCS, you don't need any Ethernet funtionalities on the
stack. Is that your concern ?

-- 

Daniel (Soohong Daniel Park)
Mobile Convergence Laboratory, SAMSUNG Electronics.
>From [email-masked] Wed Oct 25 19:05:12 2006
Date: Wed, 25 Oct 2006 08:40:52 +0000
From: "Syam Madanapalli" <[email-masked]>
To: "Alexandru Petrescu" <[email-masked]>
Subject: Re: [16ng] Re: I-D ACTION:draft-ietf-16ng-ipv6-over-ipv6cs-00.txt
cc: "Soininen Jonne \(Nokia-NET/Espoo\)" <[email-masked]>
cc: [email-masked]

Hi Alex,

On 10/21/06, Alexandru Petrescu <[email-masked]> wrote:
> Syam Madanapalli wrote:
> > Hi,
> >
> > Quick reply on CID.
> >
> > CID (Connection Identifier) is assigned dynamically by the ASN GW in
> > WiMAX  networks when connection is being set up. There can be
> > multiple connections exists between MS and AR (ASN GW) at any given
> > time to satisfy different QoS requirements.
>
> I believe each such connection would imply a different IP address, no?

May or many not be. Different connections are used for different QoS
requirements. There can be multiple IP addresses associated with a
single connection.

>
> > So I am not sure if we can use the CID in ND messages for any real
> > use.
>
> Indeed, if there is no IP address per connection (but a unique IP
> address for all connections) then maybe not necessary to encode CID in ND.

As I mentioned above, there may not be a unique IP address per connection.

>
> Unless, maybe, if there is a maximum number of such connections (maybe
> max 4) they could be _all_ encoded in a 64bit IID.  Just a possibility.

No such restrictions either for now.

>
> The reason to encode CID into IID is probably to make it look like IPv6
> LCP PPP, where there is some ID given by the PPP server to the client,
> which encodes it into IID.
>
> > Also it is better if we generate the IID from the MAC address which
> > is globally unique compared to 16 bit CID which is not globally
> > unique.
>
> Yes, I agree.
>
> >> So you mean that even with the IPv6 CS there is no intermediary
> >> 802.3 Ethernet MAC header between the IPv6 header and the 802.16e
> >> MAC header?
> >
> > If Ethernet CS is being used then there will be Ethernet MAC header
> > between IP header and 802.16 MAC frame.
>
> Ok, this is very different than other IPv6 over point-to-point links I
> believe.  In a sense, the IPv6 stack will not be aware at all about the
> existence of CS, or of the fact there's point-to-point behind it.
>
> In that case, I think it is very illustrative to picture a IEEE 802.16e
> MAC header, followed by the Ethernet MAC header and followed by the IPv6
> header.
>
> In that case too, I think it should be useful to know (for implementer)
> how the MAC addresses and type (of the intermediary Ether MAC header)
> should contain.  And these addresses will be encoded - normally - in ND
> messages.

I hope these appears in IP over Ethernet CS draft. I think the draft
has been published from Max, I also need to look into this.

>
> >> I realize the 2-byte CID replaces what I commonly thought is a
> >> 6-byte IEEE MAC address.  If so, and only if no intermediary 802.3
> >> MAC header, then I think we should have a method to translate a
> >> 2-byte CID into an IID, and build an fe80 address out of that CID,
> >> no?
> >
> > Actually, according to 802.16 spec, IP addresses is needed to
> > establish a connection and hence CID; to get the IP address the host
> > needs a connection, it's like deadlock.
>
> Sounds so to me too.  It's good to point out in the draft that
> 802.16(e?) requires the host to have an IP address before establishing a
> connection, which in turn will give it an address - and that't a
> deadlock.  Maybe someone could provide the necessary solution to that
> deadlock.

But int the current PS draft, this is not a problem. May be because as
I mentioned
WIMAX NWG solved this by defining a initial service flow which will be
established as soon as the MS attaches to the network. This connection
does nto require an IP address.

>
> > In WiMAX, NWG defined Initial Service Flow to overcome this, which is
> >  an initial CID established as soon as MS completes the network entry
> >  and authorization.
>
> I see.  I think I can not comment on this, because I'm interested first
> in IPv6 over 802.16e, then WiMax.

Currently most of the work is targeted at WiMAX Forum as there are no other
users atleast for now.

>
> >> If there are multicast CIDs then we should map the IPv6 mc
> >> addresses into them too, no?
> >
> > May be, but that use has not yet been defined.
>
> Ok, if there are no multicast CIDs then it's probably useless to convert
> Ethernet mc addresses (33:...) into them.

Yes. But 802.16 supports downlink multicast, that is not used.

>
> >>>> Section 8.1 "Router Solicitation"  What is the src address of
> >>>> that RS?
> >>>
> >>> Unspecified address if the host has not  configured the link
> >>> local address yet. This behavior should be same as RFC2461bis.
> >>
> >> Ok.  Should the link-local address be auto-computed (such as cat
> >> IID to fe80)?  If so does the IID come from the BS?
> >
> > IID can be derived from the MAC address or any other method. And Link
> >  Local address configuration is same as that of Ethernet interface
> > type. One of the goals for the solution is to impose no changes to
> > the normal IPv6 host implementations, so it should work as defined in
> >  RFC 2461/2462.
>
> Which solution?  The CS design?  I think that should be done outside of
> here, no?

I was talking about IPv6 over XX CS drafts in 16ng. All of these solutions
should not be requiring any changes to the host side IP stack implementations.

>
> Do we know what does look the MAC header offered by CS?

The 802.16 MAC header does not differ by CS types. CS just
defines classification i.e. mapping higher layer PDUs to a particular CID.
If it is IP CS, it looks at IP and transport layers for mapping, if it
is Ethernet
CS it looks into Ethernet frame header in addition to IP and transport layer
headers.

Thanks,
Syam

>
> Alex
>
>From [email-masked] Wed Oct 25 19:17:54 2006
Date: Wed, 25 Oct 2006 17:53:27 +0900
From: Soohong Daniel Park <[email-masked]>
To: [email-masked]
Subject: [16ng] 67-IETG agenda

This is a multi-part message in MIME format.

--Boundary_(ID_0b/eh5eEVMpslKO9+m92Ww)
Content-type: text/plain; charset=ks_c_5601-1987
Content-transfer-encoding: 7BIT

IP over IEEE 802.16 Networks Working Group (16ng)

o 67th IETF - San Diego, US
o 0900 - 1130 Morning Session II, Tuesday, November 7, 2006
o Room: Grande Ballroom C

========================================

AGENDA

o Update: 2006-10-25

o Timeslot 2.5 hours

15    Administrative                        Chairs
 - Blue sheets
 - Minutes and Jabber scribe
 - Agenda bashing
 - Interim report 
 - WG report (updated milestone, etc)
 
10    Liaison report
 - IEEE 802.16 WG                        DJ Johoston
 - WiMAX Forum NWG   TBD
 - Etc.
 
10    16ng problem statement        Junghoon Jee & Daniel Park
 - Initial WG ID
   [draft-ietf-16ng-ps-goals-00]
 - WGLC issues 
 - GOAL: Ready for the IESG
 
30    IPv6 link model analysis        Syam Madanapalli
 - Design team report
 - Initial WG ID
   [draft-ietf-16ng-ipv6-link-model-analysis-00]
 - WGLC issues
 - GOAL: Ready for the IESG
 
30    IPv6 over IPv6CS                    Basavaraj Patil
 - Initial WG ID
   [draft-ietf-16ng-ipv6-over-ipv6cs-01]
 - WGLC issues
 - GOAL: Ready for the IESG
 
30    IP over EthernetCS                Maximilian Riegel
 - Initial individual ID
   [draft-riegel-16ng-ip-over-eth-over-80216-01]
 - Relevant activities
 - GOAL: WG Adoption
 
10    IPv4 over IPv4CS                    Daniel Park
 - Introduction to this work
 - None I-D 

05    Closing                                 Chairs

=====
140 mins

Daniel (Soohong Daniel Park)
Mobile Convergence Laboratory, SAMSUNG Electronics.

--Boundary_(ID_0b/eh5eEVMpslKO9+m92Ww)
Content-type: text/html; charset=ks_c_5601-1987
Content-transfer-encoding: 7BIT

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=Content-Type content="text/html; charset=ks_c_5601-1987">
<META content="MSHTML 6.00.2900.2912" name=GENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY>
<DIV><FONT size=2><STRONG>IP over IEEE 802.16 Networks Working Group 
(16ng)</STRONG></FONT></DIV>
<DIV><FONT size=2></FONT>&nbsp;</DIV><FONT size=2></FONT>
<DIV><BR><FONT size=2>o 67th IETF - San Diego, US<BR>o 0900 - 1130 Morning 
Session II,&nbsp;Tuesday, November 7, 2006</FONT></DIV>
<DIV><FONT size=2>o Room: Grande Ballroom C</FONT></DIV>
<DIV><FONT size=2></FONT>&nbsp;</DIV>
<DIV><FONT size=2>========================================</FONT></DIV>
<DIV><FONT size=2></FONT>&nbsp;</DIV>
<DIV><FONT size=2>AGENDA</FONT></DIV>
<DIV><FONT size=2></FONT>&nbsp;</DIV>
<DIV><FONT size=2>o Update: 2006-10-25</FONT></DIV>
<DIV><FONT size=2></FONT>&nbsp;</DIV>
<DIV><FONT size=2>o Timeslot&nbsp;2.5 hours</FONT></DIV>
<DIV><FONT size=2></FONT>&nbsp;</DIV>
<DIV><BR><FONT size=2>15&nbsp;&nbsp;&nbsp; Administrative&nbsp;&nbsp;&nbsp; 
&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; 
&nbsp;&nbsp;&nbsp; Chairs<BR>&nbsp;- Blue sheets<BR>&nbsp;- Minutes and Jabber 
scribe<BR>&nbsp;- Agenda bashing<BR>&nbsp;- Interim report&nbsp;<BR>&nbsp;- WG 
report (updated milestone, etc)<BR>&nbsp;<BR>10&nbsp;&nbsp;&nbsp; Liaison 
report<BR>&nbsp;- IEEE 802.16 WG&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; 
&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; DJ 
Johoston<BR>&nbsp;- WiMAX Forum NWG&nbsp;&nbsp;&nbsp;TBD<BR>&nbsp;- 
Etc.<BR>&nbsp;<BR>10&nbsp;&nbsp;&nbsp; 16ng problem statement&nbsp;&nbsp;&nbsp; 
&nbsp;&nbsp;&nbsp; Junghoon Jee &amp; Daniel Park<BR>&nbsp;- Initial WG 
ID<BR>&nbsp;&nbsp; [draft-ietf-16ng-ps-goals-00]<BR>&nbsp;- WGLC 
issues&nbsp;<BR>&nbsp;- GOAL: Ready for the 
IESG<BR>&nbsp;<BR>30&nbsp;&nbsp;&nbsp; IPv6 link model 
analysis&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; Syam Madanapalli<BR>&nbsp;- Design 
team report<BR>&nbsp;- Initial WG ID<BR>&nbsp;&nbsp; 
[draft-ietf-16ng-ipv6-link-model-analysis-00]<BR>&nbsp;- WGLC issues<BR>&nbsp;- 
GOAL: Ready for the IESG<BR>&nbsp;<BR>30&nbsp;&nbsp;&nbsp; IPv6 over 
IPv6CS&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; 
&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; Basavaraj Patil<BR>&nbsp;- Initial WG 
ID<BR>&nbsp;&nbsp; [draft-ietf-16ng-ipv6-over-ipv6cs-01]<BR>&nbsp;- WGLC 
issues<BR>&nbsp;- GOAL: Ready for the IESG<BR>&nbsp;<BR>30&nbsp;&nbsp;&nbsp; IP 
over EthernetCS&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; 
&nbsp;&nbsp;&nbsp; Maximilian Riegel<BR>&nbsp;- Initial individual 
ID</FONT></DIV>
<DIV><FONT 
size=2>&nbsp;&nbsp;&nbsp;[draft-riegel-16ng-ip-over-eth-over-80216-01]<BR>&nbsp;- 
Relevant activities<BR>&nbsp;- GOAL: WG 
Adoption<BR>&nbsp;<BR>10&nbsp;&nbsp;&nbsp; IPv4 over IPv4CS&nbsp;&nbsp;&nbsp; 
&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; 
Daniel Park<BR>&nbsp;- Introduction to this work<BR>&nbsp;- None 
I-D&nbsp;</FONT></DIV>
<DIV><FONT size=2></FONT>&nbsp;</DIV>
<DIV><FONT size=2>05&nbsp;&nbsp;&nbsp; 
Closing&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Chairs</FONT></DIV>
<DIV><FONT size=2></FONT>&nbsp;</DIV>
<DIV><FONT size=2>=====<BR>140 mins</FONT></DIV>
<DIV><FONT size=2></FONT>&nbsp;</DIV>
<DIV><FONT size=2></FONT>&nbsp;</DIV>
<DIV><BR><FONT size=2>Daniel (Soohong Daniel Park)<BR>Mobile Convergence 
Laboratory, SAMSUNG Electronics.<BR></FONT></DIV></BODY></HTML>

--Boundary_(ID_0b/eh5eEVMpslKO9+m92Ww)--
>From [email-masked] Wed Oct 25 19:34:42 2006
Date: Wed, 25 Oct 2006 17:05:06 +0800
From: wenson <[email-masked]>
Subject: Re: [16ng] WGLC : draft-ietf-16ng-ps-goals-00
To: Soohong Daniel Park <[email-masked]>
cc: [email-masked]

What i concern is whether point to point  link model (details in draft-ietf-16ng-ipv6-link-model-analysis-00)can be implemented based on IP over 802.16 with IP CS, while Ether like link model 
is implement mostly based on IP over 802.16 with Ethernet CS?
Another point is 
Ethernet CS can be introduced to support multcast and broadcast capability, but what the real purpose of introducing Ethernet layer is? I want to know the motivation to introduce Ethernet CS?
 
may i ask you to confirm this?
3x!
----- Original Message ----- 
From: "Soohong Daniel Park" <[email-masked]>
To: "wenson" <[email-masked]>
Cc: <[email-masked]>
Sent: Wednesday, October 25, 2006 3:37 PM
Subject: Re: [16ng] WGLC : draft-ietf-16ng-ps-goals-00

> Wenson,
> 
>> Since there are two cases to be considered, i.e.,IP over 802.16 with IP CS and IP over 802.16 with Ethernet CS, the question is:
>> what is the essential difference between these two cases?
>> It seems not clear in demonstrating approach to implement these two cases in different scenarios.
> 
> Could you please elaborate on the question more ? The most difference
> between them is whether it has a Ethernet functionality or not. When
> implementing IPCS, you don't need any Ethernet funtionalities on the
> stack. Is that your concern ?
> 
> -- 
> 
> 
> Daniel (Soohong Daniel Park)
> Mobile Convergence Laboratory, SAMSUNG Electronics.
>
>From [email-masked] Fri Oct 27 11:16:51 2006
Date: Fri, 27 Oct 2006 09:52:12 +0900
From: "Soohong Daniel Park" <[email-masked]>
To: [email-masked]
Subject: [16ng] WGLC : draft-ietf-16ng-ipv6-over-ipv6cs-01

Folks,

This is a two week WGLC on draft-ietf-16ng-ipv6-over-ipv6cs-01.

Please review the I-D and submit your comments to the authors or to
the list directly. The WGLC will exipre on November 10 (Pacific Time).

o I-D: http://www.ietf.org/internet-drafts/draft-ietf-16ng-ipv6-over-ipv6cs-01.txt

o Intended publication: Proposed Standard RFC

-- 

Daniel (Soohong Daniel Park)
Mobile Convergence Laboratory, SAMSUNG Electronics.
>From [email-masked] Fri Oct 27 12:03:19 2006
Content-return: prohibited
Date: Fri, 27 Oct 2006 01:37:31 +0000 (GMT)
From: Daniel Park <[email-masked]>
To: [email-masked]
Msgkey: [email-masked]
Subject: [16ng] Fwd: Update to Internet-Draft and RFC Boilerplate
Reply-To: [email-masked]

FYI, 

Keeping the right form is a good activity in the Standard.

Daniel (Soohong Daniel Park)
Mobile Convergence Laboratory. SAMSUNG Electronics
 
 ------- Original Message -------
Sender : IETF Chair<[email-masked]>
Date   : 2006-10-27 10:19
Title  : Update to Internet-Draft and RFC Boilerplate

A small update to BCP 78 was recently approved by the IESG as
RFC 4748, to update the boilerplate (i.e., standard legal text) in 
RFCs and Internet-Drafts to recognize the IETF Trust as a rights 
holder, instead of ISOC.

The actual boilerplate changes are given below this message.

Starting as soon as reasonably possible, all authors of Internet-Drafts 
are requested to use the new boilerplate. The RFC Editor will in any case
be inserting it in all RFCs issued from 2006-11-01. (The rights held by 
ISOC in older RFCs will be administratively transferred to the IETF
Trust.)

The public ID Nits checker already accepts I-Ds with old or new
boilerplate.
The Secretariat has started accepting I-Ds with old or new boilerplate

XML2RFC version 1.32 will generate the new boilerplate.
Users of I-D templates are requested to update them appropriately.

http://www.ietf.org/ID-Checklist.html and
http://www.ietf.org/ietf/1id-guidelines.html are being updated.

Starting December, the public ID Nits checker will issue warnings for 
old boilerplate.

Starting February 2007, the Secretariat will refuse 
the old boilerplate in Internet-Drafts.

We are sorry for the inconvenience, but this change cannot
be avoided.

    IETF Chair
    IETF Secretariat
    TOOLS Team

--------

Copyright Notice (required for all IETF Documents)

   (Normally placed at the end of the IETF Document.)

NOTE: by convention, the first line of the copyright statement
is usually placed near the beginning of each document. This must
also be updated.

OLD
      "Copyright (C) The Internet Society (year).

      This document is subject to the rights, licenses and restrictions
      contained in BCP 78, and except as set forth therein, the authors
      retain all their rights.

NEW
      "Copyright (C) The IETF Trust (year).

      This document is subject to the rights, licenses and restrictions
      contained in BCP 78, and except as set forth therein, the authors
      retain all their rights.

Disclaimer (required in all IETF Documents)

   (Normally placed at the end of the IETF Document after the copyright
   notice.)

OLD
      "This document and the information contained herein are provided
      on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
      REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND
      THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES,
      EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT
      THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR
      ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A
      PARTICULAR PURPOSE."

NEW
      "This document and the information contained herein are provided
      on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
      REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE 
      IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL
      WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY
      WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE
      ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS
      FOR A PARTICULAR PURPOSE."

Exceptions

      In MIB modules, PIB modules and similar material commonly
      extracted from IETF Documents, except for material that is being
      placed under IANA maintenance, the following abbreviated notice
      shall be included in the body of the material that will be
      extracted in lieu of the notices otherwise required by Section 5:

OLD
         "Copyright (C) The Internet Society <year>.  This version of
         this MIB module is part of RFC XXXX; see the RFC itself for
         full legal notices."

NEW
         "Copyright (C) The IETF Trust <year>.  This version of
         this MIB module is part of RFC XXXX; see the RFC itself for
         full legal notices."

      When the MIB or PIB module is the initial version of a module that
      is to be maintained by the IANA, the following abbreviated notice
      shall be included:

OLD
         "Copyright (C) The Internet Society <year>.  The initial
         version of this MIB module was published in RFC XXXX; for full
         legal notices see the RFC itself.  Supplementary information
         may be available at:
         http://www.ietf.org/copyrights/ianamib.html."

NEW
         "Copyright (C) The IETF Trust <year>.  The initial
         version of this MIB module was published in RFC XXXX; for full
         legal notices see the RFC itself.  Supplementary information
         may be available at:
         http://www.ietf.org/copyrights/ianamib.html."

_______________________________________________
IETF-Announce mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf-announce