Subject: [dns-dir] 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

_______________________________________________
dns-dir mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dns-dir

---

From: Peter Koch <[email-masked]>
Date: Wed, 17 Dec 2008 18:45:12 +0100

> or comments until 12/17 COB the latest. 

the only draft that dealt with DNS was

>     Message Header Field for Indicating Message Authentication Status

The draft has issues with terminology, when it again uses 'domain' as a synonym
for an organization - even though it goes the laudable approach of re-introducing
the term ADMD (which reminds me of X.400, again).

More to the protocol level,  the references to DNS error conditions in sections
2.4.3 and 2.4.4 as well as 3 need a bit more thought; I'll add details tomorrow
but would appreciate if another Dir member could have a look into this before.

Regards,
  Peter

---

From: Peter Koch <[email-masked]>
Date: Thu, 18 Dec 2008 13:56:03 +0100

> the term ADMD (which reminds me of X.400, again).

1.2 says:

   This document makes several references to the "trust boundary" of an
   administrative mail domain (ADMD).  Given the diversity among
   existing mail environments, a precise definition of this term isn't
   possible.

Fine, although the relation to X.400 ADMDs might be worth noting to appreciate
the historical parallels.  The problem I see is that later in the document the
term isn't used consistently, but instead "domain" again appears as an acting entity,
as in [2.4.3] "none:  No policy records were published by the sender's domain".
There is a fundamental and reoccuring disagreement about the nature of "a domain"
between the DNS and the Mail community, which is fine as long as each group
is having internal conversation.  At the overlap areas we have this issue over
and over again and I'd really appreciate if that issue would be wider acknowledged
and addressed. This isn't only about wording, but also about implications of
hierarchy, administrative boundaries, setting "domain wide" defaults and so on.
cf. the DKIM debates and others.  That said, introducing "ADMD" seems to be a good
way forward, if it's used consistentnly and if the distinctions between an ADMD
and a (DNS) domain are dealt with properly.

Nit: 1.6 has a conflicting expansion of ADMD (s/Mail/Management/).

> but would appreciate if another Dir member could have a look into this before.

2.4.4 defines the "iprev" method of "authentication" (which reminds me of our,
dnsop's, reverse mapping draft under consideration). I can't tell the difference
between

   softfail:  The reverse DNS evaluation failed.  In particular, one or
      both of the "reverse" and forward lookups returned no data (i.e. a
      DNS reply code of NODATA).

and

   permerror:  The reverse DNS evaluation could not be completed due to
      some error which is unrecoverable (e.g. a DNS reply code of NODATA
      or NXDOMAIN).  A later attempt is unlikely to produce a final
      result.

First, there is no real reply code of NODATA (the description is usually
NOERROR/NODATA, meaning NOERROR and empty answer section), but it's unclear to me
what the author really want's to achieve here.

The description of the "iprev" method in section 3 defers details to RFC 4408,
which is an experimental RFC, while the draft under consideration aims at proposed.
Also, there's the conceptuyal/terminology issue again:

   A successful test using this algorithm constitutes a result of "pass"
   since the domain in which the client's PTR claims it belongs has
   confirmed that claim.  A failure to match constitutes a "hardfail".

It isn't that the match acknowledges the membership in some kind of administrative
boundary; it's just a consistency check of some limited value.  The whole discussion
should take into account the long debate that has taken place in DNSOP regarding the
draft-ietf-dnsop-reverse-mapping-considerations draft.  This is currently expired,
but will be revived and WGLCed "soon".

-Peter

---

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
_______________________________________________
dns-dir mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dns-dir

---

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