[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Pls review documents on IESG Agenda for December 1, 2005
On Thu, 24 Nov 2005, Wijnen, Bert (Bert) wrote:
> as always, pls review from MIB, SNMP or in general NM point of view.
> comments (if any, a "I think doc x is OK or great" area also welcome)
> to me before the end-of-day Wednesday Nov 30th pls.
>
> You can see, it is an agenda that has LOTS of documents on it.
> So help will be extra appreciated this time!
Since I had time to do so (for a change), I made a superficial sweep
of some of the docs. Comments inline.
> 2.1 WG Submissions
> 2.1.1 New Item
> o draft-ietf-mpls-lsp-ping-10.txt
> Detecting MPLS Data Plane Failures (Proposed Standard) - 1 of 22
> Note: ITU requires an RFC number by December 12th.
> Token: Alex Zinin
No comments on this one, since a ballot position was already recorded.
> o Four-document ballot: - 2 of 22
> - draft-ietf-dnsext-dhcid-rr-10.txt
> A DNS RR for Encoding DHCP Information (DHCID RR) (Proposed Standard)
> - draft-ietf-dhc-fqdn-option-11.txt
> The DHCP Client FQDN Option (Proposed Standard)
> Note: Note: 3 related DDNS documents need to be reconciled. See email
> to dhcwg list on 2003-06-05.
> - draft-ietf-dhc-ddns-resolution-10.txt
> Resolution of FQDN Conflicts among DHCP Clients (Proposed Standard)
> Note: 11/21/05: Check for last minute IETF LC comments before
> telechat.
Looked reasonable on a _very_ superficial scan. Did not check rest of ballot.
> - draft-ietf-dhc-dhcpv6-fqdn-03.txt
> The DHCPv6 Client FQDN Option (Proposed Standard)
> Token: Margaret Wasserman
> o draft-ietf-ips-fcip-mib-09.txt
> Definitions of Managed Objects for FCIP (Proposed Standard) - 3 of 22
> Note: PROTO shepherd black_david@emc.com
> Token: Allison Mankin
Got this from smilint:
mailbody:177: [5] {identifier-case-match} warning: identifier `fcipEntityId'
differs from `FcipEntityId' only in case
mailbody:79: [6] {previous-definition} info: previous definition of
`FcipEntityId'
Probably not worth making an issue of it at this point, but I probably would
have asked for fcipEntityId to be renamed had I done the review.
> o draft-ietf-idr-rfc2858bis-07.txt
> Multiprotocol Extensions for BGP-4 (Draft Standard) - 4 of 22
> Token: Bill Fenner
The doc has exactly the same abstract as 2858, except for the last sentence of
the latter. Seems to me that the abstract needs to be updated, since the spec
has been around a while and routers do now support this stuff (as evidenced by
sufficient implementations to go to Draft). Also the abstract does not say it
obsoletes RFC 2858, which it should do.
Note that the current BGP-4 MIB (draft-ietf-idr-bgp4-mib-15.txt, now in
RFC Ed queue to replace RFCs 1269 and 1657) does not support this extension,
but the new version (draft-ietf-idr-bgp4-mibv2-05.txt, still under
construction) will.
> o draft-ietf-rmonmib-rmon2-v2-05.txt
> Remote Network Monitoring Management Information Base Version 2 (Draft
> Standard) - 5 of 22
> Token: Bert Wijnen
No need to comment on this one, I think :-)
> o draft-ietf-mip4-dynamic-assignment-06.txt
> Mobile IPv4 Dynamic Home Agent Assignment (Proposed Standard) - 6 of 22
> Token: Margaret Wasserman
No real competence to comment on technical content. As far as I can tell, the
existing MIB modules (RFC 2002) provides no support for this extension (or the
related ones in RFC 2794) but can still be used -- there is just no visibilty
into the workings of dynamic home agent assignment.
> o draft-ietf-sigtran-rfc3332bis-05.txt
> Signaling System 7 (SS7) Message Transfer Part 3 (MTP3) - User Adaptation
> Layer (M3UA) (Proposed Standard) - 7 of 22
> Token: Jon Peterson
Abstract and front page need to say that it obsoletes RFC 3332.
> o draft-ietf-mip4-rfc3012bis-04.txt
> Mobile IPv4 Challenge/Response Extensions (revised) (Proposed Standard) -
> 8 of 22
> Note: 11/22/05:A' Waiting for version -05 to address final issues.
> Token: Margaret Wasserman
I wonder why this is here if -05 is still forthcoming.
> o draft-ietf-mpls-ecmp-bcp-02.txt
> Avoiding Equal Cost Multipath Treatment in MPLS Networks (BCP) - 9 of 22
> Token: Alex Zinin
Have read the doc and think it looks reasonable.
> o draft-ietf-mip4-faerr-02.txt
> Foreign Agent Error Extension for Mobile IPv4 (Proposed Standard) - 10 of
> 22
> Token: Margaret Wasserman
No real competence to comment on technical content. As far as I can tell, the
objects in the existing MIB module (RFC 2002) do actually provide support for
this extension (mnRepliesDroppedInvalidExtension or mnRegRequestsDeniedByFA,
depending on whether the mobile node supports the extension).
> o draft-ietf-simple-cipid-06.txt
> CIPID: Contact Information in Presence Information Data Format (Proposed
> Standard) - 11 of 22
> Token: Ted Hardie
> o draft-ietf-simple-rpid-09.txt
> RPID: Rich Presence Extensions to the Presence Information Data Format
> (PIDF) (Proposed Standard) - 12 of 22
> Note: The proto write-up (available in tracker comment log) discusses why
> this document was not combined with cipid and future, despite them being
> interconnected. Rough consensus for this approach does. seem evident.
> Token: Ted Hardie
> o draft-ietf-simple-future-04.txt
> Timed Presence Extensions to the Presence Information Data Format (PIDF)
> to Indicate Status Information for Past and Future Time Intervals
> (Proposed Standard) - 13 of 22
> Token: Ted Hardie
> o draft-ietf-radext-digest-auth-06.txt
> RADIUS Extension for Digest Authentication (Proposed Standard) - 14 of 22
> Note: Note: Bernard Aboba is the proto shepherd
> Token: David Kessens
> o draft-ietf-imss-ip-over-fibre-channel-03.txt
> Transmission of IPv6, IPv4 and ARP Packets over Fibre Channel (Proposed
> Standard) - 15 of 22
> Token: Bert Wijnen
> o draft-ietf-dhc-dhcpv6-remoteid-00.txt
> DHCPv6 Relay Agent Remote ID Option (Proposed Standard) - 16 of 22
> Token: Margaret Wasserman
> o draft-ietf-dhc-dhcpv6-subid-00.txt
> DHCPv6 Relay Agent Subscriber-ID Option (Proposed Standard) - 17 of 22
> Token: Margaret Wasserman
> o draft-ietf-enum-iris-ereg-02.txt
> An ENUM Registry Type for the Internet Registry Information Service
> (Proposed Standard) - 18 of 22
> Note: Finishes Last Call on October 27. On IESG agenda, however LC
> comments urged and will be heeded.
> Token: Allison Mankin
> o draft-ietf-enum-voice-01.txt
> IANA Registration for Enumservice Voice (Proposed Standard) - 19 of 22
> Token: Allison Mankin
> o draft-ietf-isis-wg-mib-24.txt
> Management Information Base for IS-IS (Proposed Standard) - 20 of 22
> Token: Alex Zinin
I did the MIB Doctor review for this doc and I am satisfied with it. I see
come comments from a GenArt in the tracker. I agree with those on Section 2
and disagree with those on Section 7. The reason I disagree is that complying
with the comment would require listing all writeable objects in the MIB
module, and it should be sufficient to say "all writeable attributes have the
potential to disrupt network operations if improperly modified" as the doc
now does.
> o draft-ietf-simple-presence-data-model-06.txt
> A Data Model for Presence (Proposed Standard) - 21 of 22
> Note: Much of the language here reflects long discussion and
> compromise. Please recognize that when suggesting wordsmithing
> changes.
> Token: Ted Hardie
> o Two-document ballot: - 22 of 22
> - draft-ietf-kitten-gssapi-prf-07.txt
> A PRF API extension for the GSS-API (Proposed Standard)
> Note: proto shepherd: jaltman@columbia.edu
> - draft-ietf-kitten-krb5-gssapi-prf-04.txt
> A PRF for the Kerberos V GSS-API Mechanism (Proposed Standard)
> Token: Sam Hartman
>
> 2.1.2 Returning Item
> o draft-ietf-mmusic-sdp-new-25.txt
> SDP: Session Description Protocol (Proposed Standard) - 1 of 3
> Note: Ancient returning item: no longer has enough ballot positions to
> advance. Mercy for these poor souls, new reviewers!
> Token: Jon Peterson
> o draft-ietf-lemonade-mms-mapping-06.txt
> Mapping Between the Multimedia Messaging Service (MMS) and Internet Mail
> (Proposed Standard) - 2 of 3
> Note: This is returning post-appeal processing by the WG and post
> replacement IETF Last Call. If we can complete this on 12/1, it will
> likely be referenced by OMA (currently the text is copied)
> Token: Ted Hardie
> o draft-ietf-dhc-dna-ipv4-17.txt
> Detecting Network Attachment in IPv4 (DNAv4) (Proposed Standard) - 3 of 3
> Note: This document has changed substantially since the IESG reviewed
> version -12 based on post-LC comments. Back for a re-review before
> sending to the RFC Editor.
> Token: Margaret Wasserman
>
>
> 2.2 Individual Submissions
> 2.2.1 New Item
> o draft-rja-ripv2-auth-03.txt
> RIPv2 Cryptographic Authentication (Proposed Standard) - 1 of 1
> Token: Russ Housley
>
> 2.2.2 Returning Item
> o draft-eastlake-ip-mime-09.txt
> IP over MIME (Proposed Standard) - 1 of 1
> Note: Back on agenda to ask people to restate discusses in terms of
> discuss. criteria document and to see if any discusses have been
> addressed.. Note that I have not decided to vote yes; if people want me
> to pull. the document until I do so, let me know..
> Token: Sam Hartman
>
>
> 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-ieprep-domain-frame-05.txt
> A Framework for Supporting Emergency Telecommunications Services (ETS)
> Within a Single Administrative Domain (Informational) - 1 of 4
> Token: Jon Peterson
> o draft-ietf-grow-bgp-med-considerations-04.txt
> BGP MED Considerations (Informational) - 2 of 4
> Note: Note: Dave Meyer is the protoshepherd
> Token: David Kessens
> o Two-document ballot: - 3 of 4
> - draft-ietf-mpls-oam-requirements-06.txt
> OAM Requirements for MPLS Networks (Informational)
> Note: ITU requires an RFC number by December 12th.
> - draft-ietf-mpls-oam-frmwk-03.txt
> A Framework for MPLS Operations and Management (OAM) (Informational)
> Token: Alex Zinin
Not my favorite authors, but since we were specifically requested to look at
these ...
NITs in draft-ietf-mpls-oam-requirements-06.txt: abstract uses the imperative
"MAY" in a context where the ordinary verb "may" is required (the same error
occurs at other places in the document; I don't think imperatives belong
here at all). Some acronyms in the abstract also may need to be expanded
there (judgment call). Also replace "this draft" by "this document". In
Section 2 please exand "LSP" and "TE" and all other acronyms on or prior to
first use (reverse order of subsections if necessary). Eliminate one of the
duplicate definitions of "Head-end Label Switch Router". More substantive:
it is news to me that ICMP is part of the MPLS control plane (sec. 4.1) ...
I thought it was part of the data plane, as far as MPLS was concerned. I
stop here on minor things that should have been corrected before the doc
went to the IESG (grumble). Having said all that, I would be OK to have it
published once it got cleaned up (assuming that the responsible AD can vouch
that the MPLS network operator community is happy with its content.
Regarding draft-ietf-mpls-oam-frmwk-03.txt -- the title led me to expect some
real content regarding how OAM would be carried out on MPLS networks. I didn't
see any. I am not sure what purpose this document serves. I do not understand
why it needs to be published.
> o draft-ietf-mpls-p2mp-sig-requirement-03.txt
> Signaling Requirements for Point to Multipoint Traffic Engineered MPLS
> LSPs (Informational) - 4 of 4
> Token: Alex Zinin
>
> 3.1.2 Returning Item
> o draft-ietf-dnsop-ipv6-dns-issues-12.txt
> Operational Considerations and Issues with IPv6 DNS (Informational) - 1
> of 1
> Note: To check (for the second time) on the status of the resolution of
> Thomas Narten/Margaret Wasserman's DISCUSS..
> Token: David Kessens
>
>
> 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
> NONE
> 3.2.2 Returning Item
> o draft-krovetz-umac-07.txt
> UMAC: Message Authentication Code using Universal Hashing (Informational) -
> 1 of 1
> Token: Russ Housley
>
> 3.3 Individual 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
> , but this does not prevent publishing; 3) The IESG thinks
> that publication is harmful to work in WG and recommends
> not publishing at this time; 4) The IESG thinks that this
> document violates the IETF procedures for 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.
> Other matters may be recorded in comments to be passed on
> to the RFC Editor as community review of the document.
>
>
> 3.3.1 New Item
> o draft-glenn-mo-aggr-mib-07.txt
> The Managed Object Aggregation MIB (Informational) - 1 of 1
> Token: Bert Wijnen
Already commented that I think Experimental would be more appropriate than
Informational. Otherwise no objection.
> 3.3.2 Returning Item
> NONE
> 3.3.3 For Action
> o draft-manning-opcode-discover-02.txt
> DISCOVER: Supporting Multicast DNS Queries (Experimental) - 1 of 1
> Note: Note: Submitted to RFC Editor, being treated as an ISR.
> Token: Brian Carpenter
That's all I had time for.
Mike