Subject: [dns-dir] FW: PRELIMINARY Agenda and Package for July 2, 2009 Telechat

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Fri, 26 Jun 2009 08:05:29 +0200

Please find below the preliminary agenda of the 7/2 IESG telechat.
Please send me all comments, questions and concerns before 7/1 COB. 

Thanks and Regards,

Dan

2.1 WG Submissions
2.1.1 New Item
  o draft-ietf-avt-rtcpssm-18.txt
    RTCP Extensions for Single-Source Multicast Sessions with Unicast
Feedback 
    (Proposed Standard) - 1 of 12 
    Token: Cullen Jennings
  o draft-ietf-tcpm-rfc2581bis-05.txt
    TCP Congestion Control (Draft Standard) - 2 of 12 
    Note: Document Shepherd: Wesley Eddy ([email-masked]).
Interop
 
    Report:
http://www.ietf.org/mail-archive/web/tcpm/current/msg03133.html 
    Token: Lars Eggert
  o draft-ietf-adslmib-vdsl2-07.txt
    Definitions of Managed Objects for Very High Speed Digital
Subscriber
Line 
    2 (VDSL2) (Proposed Standard) - 3 of 12 
    Token: Dan Romascanu
  o draft-ietf-mipshop-mos-dns-discovery-06.txt
    Locating IEEE 802.21 Mobility Servers using DNS (Proposed Standard)
-
4 of 
    12 
    Note: Document shepherd is Vijay Devarapalli
<[email-masked]> 
    Token: Jari Arkko
  o draft-ietf-avt-rtp-mps-02.txt
    RTP Payload Format for Elementary Streams with MPEG Surround multi-
channel 
    audio (Proposed Standard) - 5 of 12 
    Token: Cullen Jennings
  o draft-ietf-dime-qos-attributes-12.txt
    Quality of Service Attributes for Diameter (Proposed Standard) - 6
of
12 
    Token: Dan Romascanu
  o draft-ietf-geopriv-civic-address-recommendations-02.txt
    Considerations for Civic Addresses in PIDF-LO - Guidelines and IANA 
    Registry Definition (BCP) - 7 of 12 
    Token: Cullen Jennings
  o draft-ietf-sip-body-handling-06.txt
    Message Body Handling in the Session Initiation Protocol (SIP)
(Proposed 
    Standard) - 8 of 12 
    Note: Theo Zourzouvillys is the document shepherd 
    Token: Robert Sparks
  o draft-ietf-ospf-dynamic-hostname-04.txt
    Dynamic Hostname Exchange Mechanism for OSPF (Proposed Standard) - 9
of 12 
    Token: Ross Callon
  o draft-ietf-l2tpext-circuit-status-extensions-04.txt
    L2TPv3 Extended Circuit Status Values (Proposed Standard) - 10 of 12

    Note:  Ignacio Goyret <[email-masked]> is the
WG 
    shepherd.  for this document.. 
    Token: Ralph Droms
  o draft-ietf-sipcore-subnot-etags-02.txt
    An Extension to Session Initiation Protocol (SIP) Events for
Conditional 
    Event Notification (Proposed Standard) - 11 of 12 
    Note: Dean Willis ([email-masked]) is document shepherd. 
    Token: Robert Sparks
  o draft-ietf-pwe3-vccv-bfd-05.txt
    Bidirectional Forwarding Detection (BFD) for the Pseudowire Virtual
Circuit 
    Connectivity Verification (VCCV) (Proposed Standard) - 12 of 12 
    Token: Ralph Droms

2.1.2 Returning Item
NONE

2.2 Individual Submissions
2.2.1 New Item
  o draft-dusseault-impl-reports-03.txt
    Guidance on Interoperation and Implementation Reports (BCP) - 1 of 2

    Token: Tim Polk
  o draft-dawkins-nomcom-dont-wait-03.txt
    Nominating Committee Process: Earlier Announcement of Open Positions
and 
    Solicitation of Volunteers (BCP) - 2 of 2 
    Token: Russ Housley

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-geopriv-l7-lcp-ps-09.txt
    GEOPRIV Layer 7 Location Configuration Protocol; Problem Statement
and
 
    Requirements (Informational) - 1 of 9 
    Token: Cullen Jennings
  o draft-ietf-pwe3-ms-pw-arch-06.txt
    An Architecture for Multi-Segment Pseudowire Emulation Edge-to-Edge 
    (Informational) - 2 of 9 
    Note:  David Sinicrope ([email-masked]) is the.
 
    Document Shepherd for this document. 
    Token: Ralph Droms
  o draft-ietf-pce-inter-layer-frwk-10.txt
    Framework for PCE-Based Inter-Layer MPLS and GMPLS Traffic
Engineering
 
    (Informational) - 3 of 9 
    Token: Ross Callon
  o draft-ietf-opsec-blackhole-urpf-04.txt
    Remote Triggered Black Hole filtering with uRPF (Informational) - 4
of
9 
    Token: Ron Bonica
  o draft-ietf-dccp-ccid4-04.txt
    Profile for Datagram Congestion Control Protocol (DCCP) Congestion
ID
4: 
    TCP-Friendly Rate Control for Small Packets (TFRC-SP) (Experimental)
-
5 of 
    9 
    Note: Document Shepherd: Pasi Sarolahti ([email-masked]) [was
Gorry 
    Fairhurst, but he's not a DCCP chair anymore] 
    Token: Lars Eggert
  o draft-ietf-smime-new-asn1-05.txt
    New ASN.1 Modules for CMS and S/MIME (Informational) - 6 of 9 
    Note: Sean Turner ([email-masked]) is the document shepherd. 
    Token: Tim Polk
  o draft-ietf-ancp-security-threats-07.txt
    Security Threats and Security Requirements for the Access Node
Control
 
    Protocol (ANCP) (Informational) - 7 of 9 
    Note: Matthew Bocci ([email-masked]) is the
document
 
    shepherd. 
    Token: Ralph Droms
  o draft-ietf-dccp-quickstart-05.txt
    Quick-Start for Datagram Congestion Control Protocol (DCCP)
(Experimental) 
    - 8 of 9 
    Note: Document shepherd is Pasi Sarolahti
<[email-masked]> 
    Token: Lars Eggert
  o draft-ietf-pkix-tac-04.txt
    Traceable Anonymous Certificate (Experimental) - 9 of 9 
    Token: Tim Polk

3.1.2 Returning Item
NONE

3.2 Individual Submissions Via AD
	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.2.1 New Item
  o draft-livingood-woundy-p4p-experiences-10.txt
    Comcast's ISP Experiences In a P4P Technical Trial (Informational) -
1
of 1 
    Token: Lisa Dusseault

3.2.2 Returning Item
NONE
3.3 Independent Submissions Via RFC Editor
	The IESG will use RFC 3932 responses: 1) The IESG has not
	found any conflict between this document and IETF work; 2) The
	IESG thinks that this work is related to IETF work done in WG
	<X>, but this does not prevent publishing; 3) The IESG thinks
	that publication is harmful to work in WG <X> and recommends
	not publishing at this time; 4) The IESG thinks that this
	document violates the IETF procedures for <X> and should
	therefore not be published without IETF review and IESG
	approval; 5) The IESG thinks that this document extends an
	IETF protocol in a way that requires IETF review and should
	therefore not be published without IETF review and IESG
approval.

	The document shepherd must propose one of these responses in
	the Data Tracker note and supply complete text in the IESG
	Note portion of the write-up. The Area Director ballot positions
	indicate consensus with the response proposed by the
	document shepherd.

	Other matters may be recorded in comments, and the comments will
	be passed on to the RFC Editor as community review of the
document.

3.3.1 New Item
NONE
3.3.2 Returning Item
  o draft-irtf-mobopts-location-privacy-solutions-15.txt
    Mobile IPv6 Location Privacy Solutions (Experimental) - 1 of 1 
    Note: The document shepherd is Basavaraj Patil 
    <[email-masked]> 
    Token: Jari Arkko

4. Working Group Actions
4.1 WG Creation
4.1.1 Proposed for IETF Review
    NONE
4.1.2 Proposed for Approval
  o STORage Maintenance (storm) - 1 of 1
    Token: Lars Eggert
4.2 WG Rechartering
4.2.1 Under evaluation for IETF Review
  o Behavior Engineering for Hindrance Avoidance (behave) - 1 of 3
    Token: Magnus Westerlund
  o IP Flow Information Export (ipfix) - 2 of 3
    Token: Dan Romascanu
  o DNS Extensions (dnsext) - 3 of 3
    Token: Ralph Droms
4.2.2 Proposed for Approval
  o Site Multihoming by IPv6 Intermediation (shim6) - 1 of 3
    Token: Jari Arkko
  o Diameter Maintenance and Extensions (dime) - 2 of 3
    Token: Dan Romascanu
  o Integrated Security Model for SNMP (isms) - 3 of 3
    Token: Pasi Eronen

---

From: Olafur Gudmundsson <[email-masked]>
Date: Fri, 26 Jun 2009 07:49:39 -0400

Early-warning drafts please someone review and post a comment if the drafts
need attention.

tschofenig-geopriv-l7-lcp-ps 03       21
geopriv-l7-lcp-ps 00       21
mipshop-mos-dns-discovery 00       45 01       47 04       51 05       53

         Olafur

At 02:05 26/06/2009, Romascanu, Dan (Dan) wrote:
>_______________________________________________
>dns-dir mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/dns-dir

---

From: Andrew Sullivan <[email-masked]>
Date: Fri, 26 Jun 2009 09:41:13 -0400

> mipshop-mos-dns-discovery 00       45 01       47 04       51 05       53

I will take one of these, and perform the review by Monday noon.
Unless I hear otherwise by the end of today-ish, I'll pick the last
one.  If anyone prefers to read that one, please let me know.

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 29 Jun 2009 11:42:11 -0400

Dear colleagues,

>     Locating IEEE 802.21 Mobility Servers using DNS (Proposed Standard)

I have read this document.  I think it has received some previous DNS
Directorate attention.

I think the reason this document previously received some objections
has to do with certain notions embedded in it.  In particular, this
passage stands out:

   When the MN needs to discover Mobility Services in its home domain,
   the input to the First Well Known Rule MUST be the MN's home domain,
   which is assumed to be pre-configured in the MN.

I imagine the issue has really been this notion of a "home domain",
and how it fits into the DNS (where it's either an entirely alien
notion or one of the suffixes in the search path, depending on how you
feel about these things).  I had a look through the other associated
drafts, and I was not able to find a definition of "home domain" or
"home network" there; neither was it in RFC 5164.  I don't have the
IEEE 802.21 standard, so I don't know whether it is defined there.
Defining this term, however, would go a long way to improving the
document.  All of that said, I was able (I think) to figure out what
is meant by "home domain"; anyway, my _ad hoc_ definition ("the DNS
domain in which the MN thinks its hostname is part of") made the
document make sense to me.  I could live with publication with this
missing definition, but I think it would be a big improvement if it
were added.

The following text in section 2.2 is a little weak:

   Note, that the regexp field in the NAPTR example above is empty.
   This document discourages the use of this field as its usage can be
   complex and error prone; and the discovery of the MIH services do
   not require the flexibility provided by this field over a static
   target present in the TARGET field.

It seems to me that since the regexp field is previously defined to be
empty (in what I assume is the normative text), then a returned NAPTR
record with a populated regexp field is not just discouraged: it's
undefined, and is not an instance of a NAPTR record that conforms with
the specification in this draft.  I do not object to the publication
of the draft with this text still there, but I think it would be a
significant improvement to strengthen this since I think the document
will be easier to understand if this is made plainer.

I believe that Alfred Hoenes has already pointed out that Section 2.3
suggests a possibility of an IP address in TARGET.  That's not right:
the SRV definition in RFC 2782 defines "Target" as "The domain name of
the target host."  There should not be an IP address returned here.  I
think this must be fixed before publication, because the document
seems to be suggesting something is possible that is not.  (Similarly,
an SRV record should always have a port number as far as I can tell --
certainly, RFC 2782 does not make the field optional.  Is the idea
that the port could be "0"?)

The IANA considerations says that the Protocol field of the new
registry contains the name and acronym for the protocol, along with
a reference to a document that describes the transport protocol; but
the initial values defined in the draft don't do that.  They also
don't contain the name, address, email address, and telephone number
of the person registering.  (I actually think this is a very bad idea
-- we already have a broad range of examples of stale information of
this sort in the RFC database itself, and adding more stale examples
to an IANA registry seems to me to be a mistake).  It would be nice to
start IANA off with a clean registry.  

The above said, _apart from fixing the SRV record treatment_ (which I
think is necessary), I have no strong objection to publishing the
document as it stands.

Best regards,

Andrew

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Mon, 29 Jun 2009 17:49:11 +0200

Thanks, Andrew. Unless I hear other objections or comments, I plan to
open a DISCUSS on the SRV record issue, and include the other comments
as non-blocking COMMENTs. 

Dan

> -----Original Message-----
> From: Andrew Sullivan [mailto:[email-masked]] 
> Sent: Monday, June 29, 2009 6:42 PM
> To: Romascanu, Dan (Dan)
> Cc: [email-masked]
> Subject: Re: [dns-dir] FW: PRELIMINARY Agenda and Package for 
> July 2, 2009Telechat
> 
> Dear colleagues,
> 
> I have read this document.  I think it has received some 
> previous DNS Directorate attention.
> 
> I think the reason this document previously received some 
> objections has to do with certain notions embedded in it.  In 
> particular, this passage stands out:
> 
> I imagine the issue has really been this notion of a "home 
> domain", and how it fits into the DNS (where it's either an 
> entirely alien notion or one of the suffixes in the search 
> path, depending on how you feel about these things).  I had a 
> look through the other associated drafts, and I was not able 
> to find a definition of "home domain" or "home network" 
> there; neither was it in RFC 5164.  I don't have the IEEE 
> 802.21 standard, so I don't know whether it is defined there.
> Defining this term, however, would go a long way to improving 
> the document.  All of that said, I was able (I think) to 
> figure out what is meant by "home domain"; anyway, my _ad 
> hoc_ definition ("the DNS domain in which the MN thinks its 
> hostname is part of") made the document make sense to me.  I 
> could live with publication with this missing definition, but 
> I think it would be a big improvement if it were added.
> 
> It seems to me that since the regexp field is previously 
> defined to be empty (in what I assume is the normative text), 
> then a returned NAPTR record with a populated regexp field is 
> not just discouraged: it's undefined, and is not an instance 
> of a NAPTR record that conforms with the specification in 
> this draft.  I do not object to the publication of the draft 
> with this text still there, but I think it would be a 
> significant improvement to strengthen this since I think the 
> document will be easier to understand if this is made plainer.
> 
> I believe that Alfred Hoenes has already pointed out that 
> Section 2.3 suggests a possibility of an IP address in 
> TARGET.  That's not right:
> the SRV definition in RFC 2782 defines "Target" as "The 
> domain name of the target host."  There should not be an IP 
> address returned here.  I think this must be fixed before 
> publication, because the document seems to be suggesting 
> something is possible that is not.  (Similarly, an SRV record 
> should always have a port number as far as I can tell -- 
> certainly, RFC 2782 does not make the field optional.  Is the 
> idea that the port could be "0"?)
> 
> The IANA considerations says that the Protocol field of the 
> new registry contains the name and acronym for the protocol, 
> along with a reference to a document that describes the 
> transport protocol; but the initial values defined in the 
> draft don't do that.  They also don't contain the name, 
> address, email address, and telephone number of the person 
> registering.  (I actually think this is a very bad idea
> -- we already have a broad range of examples of stale 
> information of this sort in the RFC database itself, and 
> adding more stale examples to an IANA registry seems to me to 
> be a mistake).  It would be nice to start IANA off with a 
> clean registry.  
> 
> The above said, _apart from fixing the SRV record treatment_ 
> (which I think is necessary), I have no strong objection to 
> publishing the document as it stands.
> 
> Best regards,
> 
> Andrew
> 
> --
> Andrew Sullivan
> [email-masked]
> Shinkuro, Inc.
> 
> 
> 
>