Subject: [AAA-DOCTORS] FW: PRELIMINARY Agenda and Package for December 18, 2008 Telechat

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Fri, 12 Dec 2008 09:20:42 +0100

Please find below the preliminary agenda of the 12/18 telechat. Please
review the relevant documents and let me know if there are any concerns
or comments until 12/17 COB the latest. 

Thanks and Regards,

Dan

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
IESG Secretary

2. Protocol Actions
	Reviews should focus on these questions: "Is this document a
	reasonable basis on which to build the salient part of the
Internet
	infrastructure? If not, what changes would make it so?"

2.1 WG Submissions
2.1.1 New Item
  o draft-ietf-tcpm-tcp-uto-10.txt
    TCP User Timeout Option (Proposed Standard) - 1 of 12 
    Token: Magnus Westerlund
  o draft-ietf-forces-protocol-19.txt
    ForCES Protocol Specification (Proposed Standard) - 2 of 12 
    Token: Ross Callon
  o draft-ietf-forces-mib-10.txt
    ForCES MIB (Proposed Standard) - 3 of 12 
    Token: Ross Callon
  o draft-ietf-calsify-rfc2445bis-09.txt
    Internet Calendaring and Scheduling Core Object Specification
(iCalendar) 
    (Proposed Standard) - 4 of 12 
    Token: Lisa Dusseault
  o draft-ietf-mext-nemo-v4traversal-06.txt
    Mobile IPv6 Support for Dual Stack Hosts and Routers (Proposed
Standard) - 
    5 of 12 
    Token: Jari Arkko
  o draft-ietf-nfsv4-rpc-netid-05.txt
    IANA Considerations for RPC Net Identifiers and Universal Address
Formats 
    (Proposed Standard) - 6 of 12 
    Note: Document Shepherd: Spencer Shepler ([email-masked]) 
    Token: Lars Eggert
  o draft-ietf-ospf-lls-05.txt
    OSPF Link-local Signaling (Proposed Standard) - 7 of 12 
    Token: David Ward
  o draft-ietf-smime-3851bis-08.txt
    Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2
Message 
    Specification (Proposed Standard) - 8 of 12 
    Token: Tim Polk
  o draft-ietf-smime-3850bis-08.txt
    Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 
    Certificate Handling (Proposed Standard) - 9 of 12 
    Token: Tim Polk
  o draft-ietf-pkix-ecc-subpubkeyinfo-10.txt
    Elliptic Curve Cryptography Subject Public Key Information (Proposed

    Standard) - 10 of 12 
    Note: Document shepherd is [email-masked] 
    Token: Pasi Eronen
  o draft-freed-sieve-ihave-03.txt
    Sieve Email Filtering: Ihave Extension (Proposed Standard) - 11 of
12

    Token: Lisa Dusseault
  o draft-ietf-mpls-cosfield-def-08.txt
    Multi-Protocol Label Switching (MPLS) label stack entry: "EXP" field

    renamed to "Traffic Class" field (Proposed Standard) - 12 of 12 
    Token: Ross Callon

2.1.2 Returning Item
NONE

2.2 Individual Submissions
2.2.1 New Item
  o draft-kucherawy-sender-auth-header-18.txt
    Message Header Field for Indicating Message Authentication Status
(Proposed 
    Standard) - 1 of 1 
    Token: Lisa Dusseault

2.2.2 Returning Item
NONE

3. Document Actions

3.1 WG Submissions
	Reviews should focus on these questions: "Is this document a
reasonable
	contribution to the area of Internet engineering which it
covers? If
	not, what changes would make it so?"

3.1.1 New Item
  o draft-ietf-mpls-ldp-igp-sync-03.txt
    LDP IGP Synchronization (Informational) - 1 of 3 
    Token: David Ward
  o draft-ietf-l1vpn-ospfv3-auto-discovery-02.txt
    OSPFv3 Based Layer 1 VPN Auto-Discovery (Experimental) - 2 of 3 
    Token: David Ward
  o draft-ietf-roll-urban-routing-reqs-02.txt
    Urban WSNs Routing Requirements in Low Power and Lossy Networks 
    (Informational) - 3 of 3 
    Token: David Ward

_______________________________________________
AAA-DOCTORS mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/aaa-doctors

---

From: Tina TSOU <[email-masked]>
Date: Tue, 16 Dec 2008 16:24:07 +0800

Hi Dan et al,
Review of draft-ietf-tcpm-tcp-uto-10 is below.

 ---------
Review Questions:

Is the document readable?
[Tina: Yes.]

Does it contain nits?
[Tina: 
1) The connectivity sometimes appears as "connectivity", sometimes appears as "E2E connectivity". Should they be put consistent? Or does it mean intra-net, internet respectively?
2) Should "application-specified user timeout"be "application-specific user timeout"?
3) 
Section 3,
"Performing these steps before an active or passive open causes UTO options to be exchanged in the SYN and SYN-ACK packets and is a reliable way to initially exchange, and potentially adapt to, UTO   values."  
Should "active" be "proactive"?
4) Section 5,
"Several approaches can help mitigate this issue."
Should "mitigate" be "mitigating"?]

Is the document class appropriate?
[Tina: Yes.]

Is the problem well stated?
[Tina: what's the real benefit to the network? In the document, I see that the timeout can be changed bigger or smaller, but it is already in the network by configuration. The only benefit is that this timeout change can be advertised from one end to the other, and then the other end could use it as an input to compute its own timeout. It is not a big benefit, IMHO.]

Is the problem really a problem?
[Tina: concern is as above.]

Does the document consider existing solutions?
[Tina: yes, it does. However, same concern is as above.]

Does the solution break existing technology?
[Tina: No.]

Does the solution preclude future activity?
[Tina: No.]

Is the solution sufficiently configurable?
[Tina: I would like to see clearer procedure in this document. For example,
Should the timeout be configured in the server, and then in the SYS segment, when the client requests, the server returns the time out to client? It is because one server has many unknown clients.]

Can performance be measured?  How?
[Tina: it does not show very well in the document.]

Does the solution scale well?
[Tina: Yes.]
 ----------------

Wish you a joyful greeting season! :D

B. R.
Tina
  ----- Original Message ----- 
  From: Romascanu, Dan (Dan) 
  To: [email-masked] ; MIB Doctors (E-mail) ; [email-masked] ; IETF DNS Directorate 
  Sent: Friday, December 12, 2008 4:20 PM
  Subject: [OPS-DIR] FW: PRELIMINARY Agenda and Package for December 18,2008 Telechat

  Thanks and Regards,

  Dan

  -----Original Message-----

  2. Protocol Actions

  2.1 WG Submissions
  2.1.1 New Item

      Standard) - 10 of 12 

      Token: Lisa Dusseault

  2.1.2 Returning Item
  NONE

  2.2.2 Returning Item
  NONE

  3. Document Actions

  3.1 WG Submissions

  3.1.1 New Item

  _______________________________________________
  OPS-DIR mailing list
  [email-masked]
  https://www.ietf.org/mailman/listinfo/ops-dir
_______________________________________________
AAA-DOCTORS mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/aaa-doctors

---

From: Tina TSOU <[email-masked]>
Date: Wed, 17 Dec 2008 12:07:47 +0800

Hi Dan et al,
  This is a review of Review of draft-ietf-mext-nemo-v4traversal-06 for its
  operational impact.

  Summary: The current Mobile IPv6 and NEMO specifications support IPv6 only.
   This specification extends those standards to allow the registration
   of IPv4 addresses and prefixes, respectively, and the transport of
   both IPv4 and IPv6 packets over the tunnel to the home agent.  This
   specification also allows the Mobile Node to roam over both IPv6 and
   IPv4, including the case where Network Address Translation is present
   on the path between the mobile node and its home agent.

Review summary:
  -----------
  Possible Operational Issues: Below are listed a number of issues that may have significant operational impact. Further explanation or investigations is warranted on each of these.
 ---------
Review Questions:

[Tina: Yes]

Does it contain nits?
[Tina: 
In section 5.1, 5.4.2, 6.2.1, vanilla occurs 6 times and is ambiguous, Should "vanilla UDP encapsulation" be "valid UDP encapsulation"
]

Is the problem well stated?
[Tina:
In section 5.3, it mentioned that if the mobile node is not active, it will send binding update to the home agent, I'm wondering what home agent operates upon receiving the binding update message? Also if the mobile node is not active, does it mean the mobile node is not reachable?
And in section 5.3, it mentions that the mobile node maintains NAT binding, if the mobile node is not reachable, then it need not to refresh the NAT binding? What I confuse here is that
NAT device also maintains NAT binding associated with the mobile node, so if the mobile node is not reachable, whether the mobile node refreshes the NAT binding in itself or in NAT on the path between the mobile node and the home agent?
Moreover if the mobile node is not reachable, does it mean the mobile node change the port or private address?

What's the difference for NAT keep alive between the mobile node behind NAT and the home agent behind NAT?]

Is the problem really a problem?
[Tina: See comment above.]

B. R.
Tina
  ----- Original Message ----- 
  From: Romascanu, Dan (Dan) 
  To: [email-masked] ; MIB Doctors (E-mail) ; [email-masked] ; IETF DNS Directorate 
  Sent: Friday, December 12, 2008 4:20 PM
  Subject: [OPS-DIR] FW: PRELIMINARY Agenda and Package for December 18,2008 Telechat

  Thanks and Regards,

  Dan

  -----Original Message-----

  2. Protocol Actions

  2.1 WG Submissions
  2.1.1 New Item

      Standard) - 10 of 12 

      Token: Lisa Dusseault

  2.1.2 Returning Item
  NONE

  2.2.2 Returning Item
  NONE

  3. Document Actions

  3.1 WG Submissions

  3.1.1 New Item

---

From: "Glen Zorn" <[email-masked]>
Date: Wed, 17 Dec 2008 12:00:13 +0700

I've seen several of this kind of message recently & (not that I don't
really appreciate increasing the volume of email that I receive ;-), I'm
having trouble understanding what they have to do w/AAA in general or
specifically AAA Doctors.  Perhaps I'm just ignorant of the relevance but if
not could we be a bit more selective in the CC:s?

From: [email-masked] [mailto:[email-masked]] On
Behalf Of Tina TSOU
Sent: Wednesday, December 17, 2008 11:08 AM
To: IETF DNS Directorate; [email-masked]; MIB Doctors (E-mail);
[email-masked]; Romascanu, Dan (Dan)
Subject: Re: [AAA-DOCTORS] [OPS-DIR] FW: PRELIMINARY Agenda and Package for
December 18, 2008 Telechat

Hi Dan et al,

  Summary: The current Mobile IPv6 and NEMO specifications support IPv6
only.

Review summary:
  -----------
  Possible Operational Issues: Below are listed a number of issues that may
have significant operational impact. Further explanation or investigations
is warranted on each of these.
 ---------
Review Questions:

Does it contain nits?
[Tina: 
In section 5.1, 5.4.2, 6.2.1, vanilla occurs 6 times and is ambiguous,
Should "vanilla UDP encapsulation" be "valid UDP encapsulation"
]

Is the problem well stated?
[Tina:
In section 5.3, it mentioned that if the mobile node is not active, it will
send binding update to the home agent, I'm wondering what home agent
operates upon receiving the binding update message? Also if the mobile node
is not active, does it mean the mobile node is not reachable?
And in section 5.3, it mentions that the mobile node maintains NAT binding,
if the mobile node is not reachable, then it need not to refresh the NAT
binding? What I confuse here is that
NAT device also maintains NAT binding associated with the mobile node, so if
the mobile node is not reachable, whether the mobile node refreshes the NAT
binding in itself or in NAT on the path between the mobile node and the home
agent?
Moreover if the mobile node is not reachable, does it mean the mobile node
change the port or private address?

What's the difference for NAT keep alive between the mobile node behind NAT
and the home agent behind NAT?]

B. R.
Tina

----- Original Message ----- 

From: Romascanu, Dan (Dan) <mailto:[email-masked]>  

To: [email-masked] ; MIB <mailto:[email-masked]>  Doctors
(E-mail) ; [email-masked] ; IETF DNS Directorate <mailto:[email-masked]>

Subject: [OPS-DIR] FW: PRELIMINARY Agenda and Package for December 18,2008
Telechat

Thanks and Regards,

Dan

-----Original Message-----

2. Protocol Actions

2.1 WG Submissions
2.1.1 New Item

    Standard) - 10 of 12 

    Token: Lisa Dusseault

2.1.2 Returning Item
NONE

2.2.2 Returning Item
NONE

3. Document Actions

3.1 WG Submissions

3.1.1 New Item

---

From: Tina TSOU <[email-masked]>
Date: Wed, 17 Dec 2008 14:20:24 +0800

Hi Glen,
I just replied to all in the cc list of Dan sent.
Should I just reply to Dan himself?

B. R.
Tina
  ----- Original Message ----- 
  From: Glen Zorn 
  To: [email-masked] 
  Cc: 'Romascanu, Dan (Dan)' ; 'Tina TSOU' 
  Sent: Wednesday, December 17, 2008 1:00 PM
  Subject: RE: [AAA-DOCTORS] [OPS-DIR] FW: PRELIMINARY Agenda and Package for December 18, 2008 Telechat

  I've seen several of this kind of message recently & (not that I don't really appreciate increasing the volume of email that I receive ;-), I'm having trouble understanding what they have to do w/AAA in general or specifically AAA Doctors.  Perhaps I'm just ignorant of the relevance but if not could we be a bit more selective in the CC:s?

  From: [email-masked] [mailto:[email-masked]] On Behalf Of Tina TSOU
  Sent: Wednesday, December 17, 2008 11:08 AM
  To: IETF DNS Directorate; [email-masked]; MIB Doctors (E-mail); [email-masked]; Romascanu, Dan (Dan)
  Subject: Re: [AAA-DOCTORS] [OPS-DIR] FW: PRELIMINARY Agenda and Package for December 18, 2008 Telechat

  Hi Dan et al,

  Review summary:
    -----------

  Does it contain nits?
  [Tina: 

  B. R.
  Tina

    ----- Original Message ----- 

    Thanks and Regards,

    Dan

    -----Original Message-----

    2. Protocol Actions

    2.1 WG Submissions
    2.1.1 New Item

        Standard) - 10 of 12 

        Token: Lisa Dusseault

    2.1.2 Returning Item
    NONE

    2.2.2 Returning Item
    NONE

    3. Document Actions

    3.1 WG Submissions

    3.1.1 New Item

---

From: "Hannes Tschofenig" <[email-masked]>
Date: Wed, 17 Dec 2008 10:09:46 +0200

Hi Glen, 
 
Dan provides us with these document announcements as we should try to catch
AAA related aspects in documents about to get published. 
 
Ciao
Hannes

________________________________

	From: [email-masked]
[mailto:[email-masked]] On Behalf Of Glen Zorn
	Sent: 17 December, 2008 07:00
	To: [email-masked]
	Subject: Re: [AAA-DOCTORS] [OPS-DIR] FW: PRELIMINARY Agenda and
Package forDecember 18, 2008 Telechat

	I've seen several of this kind of message recently & (not that I
don't really appreciate increasing the volume of email that I receive ;-),
I'm having trouble understanding what they have to do w/AAA in general or
specifically AAA Doctors.  Perhaps I'm just ignorant of the relevance but if
not could we be a bit more selective in the CC:s?

	From: [email-masked]
[mailto:[email-masked]] On Behalf Of Tina TSOU
	Sent: Wednesday, December 17, 2008 11:08 AM
	To: IETF DNS Directorate; [email-masked]; MIB Doctors (E-mail);
[email-masked]; Romascanu, Dan (Dan)
	Subject: Re: [AAA-DOCTORS] [OPS-DIR] FW: PRELIMINARY Agenda and
Package for December 18, 2008 Telechat

	Hi Dan et al,

	  This is a review of Review of draft-ietf-mext-nemo-v4traversal-06
for its
	  operational impact.

	  Summary: The current Mobile IPv6 and NEMO specifications support
IPv6 only.
	   This specification extends those standards to allow the
registration
	   of IPv4 addresses and prefixes, respectively, and the transport
of
	   both IPv4 and IPv6 packets over the tunnel to the home agent.
This
	   specification also allows the Mobile Node to roam over both IPv6
and
	   IPv4, including the case where Network Address Translation is
present
	   on the path between the mobile node and its home agent.

	Review summary:
	  -----------
	  Possible Operational Issues: Below are listed a number of issues
that may have significant operational impact. Further explanation or
investigations is warranted on each of these.
	 ---------
	Review Questions:

	Does it contain nits?
	[Tina: 
	In section 5.1, 5.4.2, 6.2.1, vanilla occurs 6 times and is
ambiguous, Should "vanilla UDP encapsulation" be "valid UDP encapsulation"
	]

	Is the problem well stated?
	[Tina:
	In section 5.3, it mentioned that if the mobile node is not active,
it will send binding update to the home agent, I'm wondering what home agent
operates upon receiving the binding update message? Also if the mobile node
is not active, does it mean the mobile node is not reachable?
	And in section 5.3, it mentions that the mobile node maintains NAT
binding, if the mobile node is not reachable, then it need not to refresh
the NAT binding? What I confuse here is that
	NAT device also maintains NAT binding associated with the mobile
node, so if the mobile node is not reachable, whether the mobile node
refreshes the NAT binding in itself or in NAT on the path between the mobile
node and the home agent?
	Moreover if the mobile node is not reachable, does it mean the
mobile node change the port or private address?

	What's the difference for NAT keep alive between the mobile node
behind NAT and the home agent behind NAT?]

	

	B. R.
	Tina

		----- Original Message ----- 

		To: [email-masked] ; MIB Doctors (E-mail)
<mailto:[email-masked]>  ; [email-masked] ; IETF DNS Directorate
<mailto:[email-masked]>  

		Subject: [OPS-DIR] FW: PRELIMINARY Agenda and Package for
December 18,2008 Telechat

		Please find below the preliminary agenda of the 12/18
telechat. Please
		review the relevant documents and let me know if there are
any concerns
		or comments until 12/17 COB the latest. 
		
		Thanks and Regards,
		
		Dan

		-----Original Message-----
		From: [email-masked] [mailto:[email-masked]]
On Behalf Of
		IESG Secretary

		2. Protocol Actions

		2.1 WG Submissions
		2.1.1 New Item
		  o draft-ietf-tcpm-tcp-uto-10.txt
		    TCP User Timeout Option (Proposed Standard) - 1 of 12 
		    Token: Magnus Westerlund
		  o draft-ietf-forces-protocol-19.txt
		    ForCES Protocol Specification (Proposed Standard) - 2 of
12 
		    Token: Ross Callon
		  o draft-ietf-forces-mib-10.txt
		    ForCES MIB (Proposed Standard) - 3 of 12 
		    Token: Ross Callon
		  o draft-ietf-calsify-rfc2445bis-09.txt
		    Internet Calendaring and Scheduling Core Object
Specification
		(iCalendar) 
		    (Proposed Standard) - 4 of 12 
		    Token: Lisa Dusseault
		  o draft-ietf-mext-nemo-v4traversal-06.txt
		    Mobile IPv6 Support for Dual Stack Hosts and Routers
(Proposed
		Standard) - 
		    5 of 12 
		    Token: Jari Arkko
		  o draft-ietf-nfsv4-rpc-netid-05.txt
		    IANA Considerations for RPC Net Identifiers and
Universal Address
		Formats 
		    (Proposed Standard) - 6 of 12 
		    Note: Document Shepherd: Spencer Shepler
([email-masked]) 
		    Token: Lars Eggert
		  o draft-ietf-ospf-lls-05.txt
		    OSPF Link-local Signaling (Proposed Standard) - 7 of 12 
		    Token: David Ward
		  o draft-ietf-smime-3851bis-08.txt
		    Secure/Multipurpose Internet Mail Extensions (S/MIME)
Version 3.2
		Message 
		    Specification (Proposed Standard) - 8 of 12 
		    Token: Tim Polk
		  o draft-ietf-smime-3850bis-08.txt
		    Secure/Multipurpose Internet Mail Extensions (S/MIME)
Version 3.2 
		    Certificate Handling (Proposed Standard) - 9 of 12 
		    Token: Tim Polk
		  o draft-ietf-pkix-ecc-subpubkeyinfo-10.txt
		    Elliptic Curve Cryptography Subject Public Key
Information (Proposed
		
		    Standard) - 10 of 12 
		    Note: Document shepherd is [email-masked] 
		    Token: Pasi Eronen
		  o draft-freed-sieve-ihave-03.txt
		    Sieve Email Filtering: Ihave Extension (Proposed
Standard) - 11 of
		12
		
		    Token: Lisa Dusseault
		  o draft-ietf-mpls-cosfield-def-08.txt
		    Multi-Protocol Label Switching (MPLS) label stack entry:
"EXP" field
		
		    renamed to "Traffic Class" field (Proposed Standard) -
12 of 12 
		    Token: Ross Callon
		
		2.1.2 Returning Item
		NONE
		
		2.2 Individual Submissions
		2.2.1 New Item
		  o draft-kucherawy-sender-auth-header-18.txt
		    Message Header Field for Indicating Message
Authentication Status
		(Proposed 
		    Standard) - 1 of 1 
		    Token: Lisa Dusseault
		
		2.2.2 Returning Item
		NONE
		
		3. Document Actions
		
		3.1 WG Submissions
		
		3.1.1 New Item
		  o draft-ietf-mpls-ldp-igp-sync-03.txt
		    LDP IGP Synchronization (Informational) - 1 of 3 
		    Token: David Ward
		  o draft-ietf-l1vpn-ospfv3-auto-discovery-02.txt
		    OSPFv3 Based Layer 1 VPN Auto-Discovery (Experimental) -
2 of 3 
		    Token: David Ward
		  o draft-ietf-roll-urban-routing-reqs-02.txt
		    Urban WSNs Routing Requirements in Low Power and Lossy
Networks 
		    (Informational) - 3 of 3 
		    Token: David Ward

---

From: "Glen Zorn" <[email-masked]>
Date: Wed, 17 Dec 2008 15:55:49 +0700

> AAA related aspects in documents about to get published.

Thanks, Hannes, but I wasn't talking about the announcements, I was talking
about the replies: in particular, those about documents that have no
apparent AAA-related aspects.  It's not a big deal, I just don't really need
even more irrelevant email (if I feel a deep need for that I can always
re-subscribe to the IETF list ;-).  Unfortunately, my attempt to decrease
the size of my Inbox has (perhaps predictably) increased it, so never mind.

...

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Wed, 17 Dec 2008 15:16:37 +0100

Glen,
 
These messages are soliciting reviews and input from the AAA-Doctors
(and other review teams and directorate in the OPS Area) that would help
the Area Directors in the IESG reviews and discussions. Specifically
Hannes the AAA secretary is filtering and assigning the reviews of the
more important documents for the members of the lists. However, you are
welcome to review and comment on other documents as well. Also, reviews
are posted to the AAA-Doctors list so that they can be seen and
evaluated by the other team members. 
 
I hope that this clarifies. 
 
Dan

	From: Glen Zorn [mailto:[email-masked]] 
	Sent: Wednesday, December 17, 2008 7:00 AM
	To: [email-masked]
	Cc: Romascanu, Dan (Dan); 'Tina TSOU'
	Subject: RE: [AAA-DOCTORS] [OPS-DIR] FW: PRELIMINARY Agenda and
Package for December 18, 2008 Telechat

	I've seen several of this kind of message recently & (not that I
don't really appreciate increasing the volume of email that I receive
;-), I'm having trouble understanding what they have to do w/AAA in
general or specifically AAA Doctors.  Perhaps I'm just ignorant of the
relevance but if not could we be a bit more selective in the CC:s?

	From: [email-masked]
[mailto:[email-masked]] On Behalf Of Tina TSOU
	Sent: Wednesday, December 17, 2008 11:08 AM
	To: IETF DNS Directorate; [email-masked]; MIB Doctors
(E-mail); [email-masked]; Romascanu, Dan (Dan)
	Subject: Re: [AAA-DOCTORS] [OPS-DIR] FW: PRELIMINARY Agenda and
Package for December 18, 2008 Telechat

	Hi Dan et al,

	  This is a review of Review of
draft-ietf-mext-nemo-v4traversal-06 for its
	  operational impact.

	  Summary: The current Mobile IPv6 and NEMO specifications
support IPv6 only.
	   This specification extends those standards to allow the
registration
	   of IPv4 addresses and prefixes, respectively, and the
transport of
	   both IPv4 and IPv6 packets over the tunnel to the home agent.
This
	   specification also allows the Mobile Node to roam over both
IPv6 and
	   IPv4, including the case where Network Address Translation is
present
	   on the path between the mobile node and its home agent.

	Review summary:
	  -----------
	  Possible Operational Issues: Below are listed a number of
issues that may have significant operational impact. Further explanation
or investigations is warranted on each of these.
	 ---------
	Review Questions:

	Does it contain nits?
	[Tina: 
	In section 5.1, 5.4.2, 6.2.1, vanilla occurs 6 times and is
ambiguous, Should "vanilla UDP encapsulation" be "valid UDP
encapsulation"
	]

	Is the problem well stated?
	[Tina:
	In section 5.3, it mentioned that if the mobile node is not
active, it will send binding update to the home agent, I'm wondering
what home agent operates upon receiving the binding update message? Also
if the mobile node is not active, does it mean the mobile node is not
reachable?
	And in section 5.3, it mentions that the mobile node maintains
NAT binding, if the mobile node is not reachable, then it need not to
refresh the NAT binding? What I confuse here is that
	NAT device also maintains NAT binding associated with the mobile
node, so if the mobile node is not reachable, whether the mobile node
refreshes the NAT binding in itself or in NAT on the path between the
mobile node and the home agent?
	Moreover if the mobile node is not reachable, does it mean the
mobile node change the port or private address?

	

	B. R.
	Tina

		----- Original Message ----- 

		Subject: [OPS-DIR] FW: PRELIMINARY Agenda and Package
for December 18,2008 Telechat

		Please find below the preliminary agenda of the 12/18
telechat. Please
		review the relevant documents and let me know if there
are any concerns
		or comments until 12/17 COB the latest. 
		
		Thanks and Regards,
		
		Dan

		-----Original Message-----
		From: [email-masked]
[mailto:[email-masked]] On Behalf Of
		IESG Secretary

		2. Protocol Actions
		Reviews should focus on these questions: "Is this
document a
		reasonable basis on which to build the salient part of
the
		Internet
		infrastructure? If not, what changes would make it so?"

		2.1 WG Submissions
		2.1.1 New Item
		    TCP User Timeout Option (Proposed Standard) - 1 of
		    ForCES Protocol Specification (Proposed Standard) -
2 of 12 
		    OSPF Link-local Signaling (Proposed Standard) - 7 of
		    Secure/Multipurpose Internet Mail Extensions
(S/MIME) Version 3.2
		    Secure/Multipurpose Internet Mail Extensions
(S/MIME) Version 3.2 
		
		    Standard) - 10 of 12 
		
		    Token: Lisa Dusseault
		  o draft-ietf-mpls-cosfield-def-08.txt
		    Multi-Protocol Label Switching (MPLS) label stack
entry: "EXP" field
		
		    renamed to "Traffic Class" field (Proposed Standard)
- 12 of 12 
		    Token: Ross Callon
		
		2.1.2 Returning Item
		NONE

		2.2.2 Returning Item
		NONE
		
		3. Document Actions
		
		3.1 WG Submissions
		Reviews should focus on these questions: "Is this
document a
		reasonable
		contribution to the area of Internet engineering which
it
		covers? If
		not, what changes would make it so?"
		
		3.1.1 New Item
		  o draft-ietf-mpls-ldp-igp-sync-03.txt
		    LDP IGP Synchronization (Informational) - 1 of 3 
		    Token: David Ward
		  o draft-ietf-l1vpn-ospfv3-auto-discovery-02.txt
		    OSPFv3 Based Layer 1 VPN Auto-Discovery
(Experimental) - 2 of 3 
		    Token: David Ward
		  o draft-ietf-roll-urban-routing-reqs-02.txt
		    Urban WSNs Routing Requirements in Low Power and
Lossy Networks 
		    (Informational) - 3 of 3 
		    Token: David Ward