Re: [AAA-DOCTORS] [OPS-DIR] FW: PRELIMINARY Agenda and Package forDecember 18, 2008 Telechat

["Hannes Tschofenig" <[e-mail]>]

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: [e-mail]
[mailto:[e-mail]] On Behalf Of Glen Zorn
	Sent: 17 December, 2008 07:00
	To: [e-mail]
	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: [e-mail]
[mailto:[e-mail]] On Behalf Of Tina TSOU
	Sent: Wednesday, December 17, 2008 11:08 AM
	To: IETF DNS Directorate; [e-mail]; MIB Doctors (E-mail);
[e-mail]; 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:

	 

	Is the document readable?
	[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 document class appropriate?
	[Tina: Yes.]

	 

	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.]

	 

	Does the document consider existing solutions?
	[Tina: Yes.]

	 

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

	 

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

	 

	Is the solution sufficiently configurable?
	[Tina: Yes.]

	 

	Can performance be measured?  How?
	[Tina: Yes.]

	 

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

	 

	
	Wish you a joyful greeting season! :D

	 

	B. R.
	Tina

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

		From: Romascanu, Dan (Dan) <mailto:[e-mail]>  

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

		Sent: Friday, December 12, 2008 4:20 PM

		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: [e-mail] [mailto:[e-mail]]
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
([e-mail]) 
		    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 [e-mail] 
		    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
		
		_______________________________________________
		OPS-DIR mailing list
		[e-mail]
		https://www.ietf.org/mailman/listinfo/ops-dir


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