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

[Tina TSOU <[e-mail]>]

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) 
  To: [e-mail] ; MIB Doctors (E-mail) ; [e-mail] ; IETF DNS Directorate 
  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