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

["Glen Zorn" <[e-mail]>]

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 <mailto:[e-mail]>  Doctors
(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