[Gen-art] Review Assignment: draft-ietf-sipping-transc-conf-03.txt

[Joel M. Halpern]

I am the assigned Gen-ART reviewer for draft-ietf-sipping-transc-conf-03.txt.
For background on Gen-ART, please see the FAQ at
.

Please wait for direction from your AD before posting a new version 
of the draft.



This document is ready for publication as a proposed standard.


nit:
The last paragraph of section 3.2 states that the transcode should 
return an error if it receives a URI List with more than one 
URI.  Earlier sections indicated that such multi-party requests were 
permitted.  Should this paragraph say "If a transcode which supports 
only two party transcoding receives an INVITE request with a URI-list 
with more than one URI, it SHOULD ..."


Section 3.4 begins "Figure 3 shows a similar message flow as the one 
in Figure 3."  I believe that the second "Figure 3" is supposed to be 
"Figure 2".


Yours,
Joel M. Halpern


RAI -- The Session Initiation Protocol (SIP) Conference Bridge Transcoding
 Model
 draft-ietf-sipping-transc-conf-03.txt

AD: Jon Peterson
Reviewer: Joel Halpern


___
Gen-art mailing list
Gen-art@ietf.org
https://www1.ietf.org/mailman/listinfo/gen-art

[Gen-art] Re: review of draft-ietf-l2tpext-pwe3-ethernet-07.txt

[Mark Townsley]

Thanks, Alice. There are additional comments from other IESG members 
that we need to address:


*Brian Carpenter:*
*Discuss:*
*[2006-07-03]* Points from Gen-ART review by Francis Dupont:

>  - 2.2 c): must -> MUST?

...

>  - 3.2: may -> MAY?

...

>  - (technical) 3.3: I am not convinced at all by the very last part
>(fragmentation/reassemble recommendation) because it is a layer 
violation

>and the goal (manage the issue at only one place as explain in
>L2TPFRAG section 5.1) is not explained.


...

>  - 4: For Ethernet VLAN PW, VLAN tag rewrite ...: can't parse this 
statement



[BC] I think I can, but the sentence is very hard to understand. For 
clarity,

shouldn't it be something like

   The VLAN tags of an Ethernet VLAN PW may be rewritten by NSP at
   the egress LCCE, which is outside the scope of this document (see
   Section 3.1).

>  - 4: there is no TOS octet or QoS field in the IP header (look at 
RFC 2474?)



[BC] Indeed, there is no "for example" about it; there only the DSCP.

>  5: should -> SHOULD ??

*Comment:*
*[2006-07-03]* See editorial issues in Gen-ART review:

http://www.alvestrand.no/ietf/gen/reviews/draft-ietf-l2tpext-pwe3-ethernet-07-dupont.txt

*Lars Eggert:*
*Discuss:*
*[2006-06-30]* Section 5., paragraph 3:

>LCCEs SHOULD monitor for congestion (by using explicit congestion
>notification, or by measuring packet loss) in order to ensure that
>the service using the Ethernet or Ethernet VLAN PW may be maintained.
>When severe congestion is detected (for example when enabling
>Sequencing and detecting that the packet loss is higher than a
>threshold) the Ethernet or Ethernet VLAN PW SHOULD be halted by
>tearing down the L2TP session via a CDN message.  The PW may be
>restarted by manual intervention, or by automatic means after an
>appropriate waiting time.  Note that the thresholds and time periods
>for shutdown and possible automatic recovery need to be carefully
>configured. This is necessary to avoid loss of service due to
>temporary congestion, and to prevent oscillation between the
>congested and halted states.

 RFC3985 also says: "Where congestion is avoided by shutting down a PW,
 a suitable mechanism must be provided to prevent it from immediately
 returning to service and causing a series of congestion pulses." I
 don't see such a mechanism in this draft, only the above
 acknowledgment of the issue and the recommendation of careful
 configuration.

 (This is identical to the DISCUSS I have raised
 against draft-ietf-pwe3-atm-encap. As far as I know, PWE3 is working
 on an approach for addressing this. This document, however, belongs to
 a different WG, so I'm not sure if any resolution that PWE3 comes up
 with would apply to this document as well. I'd hope that it would -
 can the authors/ADs confirm?)

*Cullen Jennings:*
*Discuss:*
*[2006-07-05]* I may not understand the congestion control technique but 
it looks like it says,  "in case of congestion, pull the plug". I don't 
believe anyone will implement this congestion control suggestions - and 
if they do, I don't believe the resulting systems will be usable - they 
will be impossible to manage not to mention the incredible DOS 
opportunities. No advice on the threshold is provided. I think this 
needs to be updated to either be clear no congestion control is provided.


The section titled "Applicability Statement" gives me no idea where this 
is applicable and where it is not.


*Dan Romascanu:*
*Discuss:*
*[2006-07-03]* I made the following two comments during the IESG LC. The 
comments were not addressed:


1. The I-D speaks about 'Ethernet' but does not provide any reference.
What version of the Ethernet standard is targeted here? The latest 
approved version of the Ethernet standard is IEEE Std 802.3-2005, but 
the IEEE 802.3 WG also has in works an extension of the frame size as 
IEEE 802.3as. One cannot talk about Ethernet PDU and MTU without a 
proper reference.


2. The I-D speaks about 'Ethernet VLAN'. Strictly speaking there is no 
such thing, Virtual LANs are being defined by IEEE 802.1 and not only 
for Ethernet. However accepting terminology license based on the 
de-facto reality that most if not all VLANs run over Ethernet, there 
still is a need to specify if the document refers to IEEE 802.1Q VLANs 
(one 12-bit tag) or IEEE 802.1ad which accommodate multiple tags and 
introduce the concepts of Customer VLAN and Service VLAN. Maybe the 
VLANs referred in this I-D are transparent to the type of VLANs that are 
being connected, but even so there should be text explaining this.






Maria A. Dos Santos (mariados) wrote:

Mark, Francis,

Please see response inline, I believe I addressed
all issues.  Please check a look at the updated 
version attached.


thanx,
Alice
  


___
Gen-art mailing list
Gen-art@ietf.org
https://www1.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] review of draft-ietf-dnsext-mdns-46.txt

[Francis Dupont]

 In your previous mail you wrote:

   I am the assigned Gen-ART reviewer for draft-ietf-dnsext-mdns-46.txt.
   For background on Gen-ART, please see the FAQ at
   .
   
   Please resolve these comments along with any other
   Last Call comments you may receive.

=> hum, it seems the right boilerplate finishes by:

Please wait for direction from your document shepherd
or AD before posting a new version of the draft.

Regards
   
[EMAIL PROTECTED]

___
Gen-art mailing list
Gen-art@ietf.org
https://www1.ietf.org/mailman/listinfo/gen-art

[Gen-art] GenART review of draft-orly-atommib-rfc3895bis-00.txt

[Black_David]

Orly,

I am the assigned Gen-ART reviewer for draft-orly-atommib-rfc3895bis-00.txt
.

For background on Gen-ART, please see the FAQ at
.

Please resolve these comments along with any other
Last Call comments you may receive.

This draft is basically ready for publication, but has nits
that should be fixed before publication.

Section 3.4 says:

3.4.  DS1 Terminology

   The terminology used in this document to describe error conditions on
   a DS1 interface as monitored by a DS1 device are based on the late
   but not final document of what became the ANSI T1.231 standard
   [ANSI-T1.231].  If the definition in this document does not match the
   definition in the ANSI T1.231 document, the implementer should follow
   the definition described in this document.

The ANSI T1.231 standard has been complete for a while now:

[ANSI-T1.231]
 American National Standard for Telecommunications -- Digital
 Hierarchy -- Layer 1 In-Service Digital Transmission Performace
 Monitoring, T1.231.02, October 2003.

Nit: "Performace" is missing an "n" in that reference.

If the terminology cannot be aligned (and I would not change terms
in the actual MIB definition solely for alignment), specific differences
from T1.231 terminology should be explained in subsections of Section
3.4, and the warning about differences from T1.231 either removed
or revised to say that any significant differences are explained in
the definitions that follow.

I see that a MIB Doctor review has been performed on this MIB and
hence have not reviewed the actual MIB definitions.

Thanks,
--David

David L. Black, Senior Technologist
EMC Corporation, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953 FAX: +1 (508) 293-7786
[EMAIL PROTECTED]Mobile: +1 (978) 394-7754


___
Gen-art mailing list
Gen-art@ietf.org
https://www1.ietf.org/mailman/listinfo/gen-art

[Gen-art] RE: Review assignments for 06 July 2006

[Mary Barnes]

I've uploaded the reviews received to date and updated the spreadsheets.


Let me know if you see any errors or omissions.

Mary.


-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 
Sent: Thursday, June 29, 2006 10:24 PM
To: gen-art@ietf.org
Cc: Barnes, Mary [RICH2:B601:EXCH]
Subject: Review assignments for 06 July 2006


Hi all,

I'm posting from my private email account as my Outlook server was just
taken down for maintenance for 2 hours. 

Here's the assignments for the July 6th, 2006 telechat:
http://www.alvestrand.no/ietf/gen/art/reviewers-060706.html

With the updated spreadsheets:
http://www.alvestrand.no/ietf/gen/art/gen-art.html
http://www.alvestrand.no/ietf/gen/art/gen-art-by-reviewer.html

I've also uploaded all the reviews received this week, so let me know if
I've missed something.

Mary. 

___
Gen-art mailing list
Gen-art@ietf.org
https://www1.ietf.org/mailman/listinfo/gen-art

[Gen-art] Re: Gen-ART Review of draft-nystrom-ct-kip-01.txt

[Magnus Nyström]

Eric,

Thanks very much for your review. Just a couple of quick comments:


In section 3.7.1 - you say:

"The XML format for CT-KIP messages have been designed to be
extensible.  However, it is possible that the use of extensions will
harm interoperability and therefore any use of extensions should be
carefully considered."

Can we say anything about what "harm interoperability" or "carefully
considered" means?  What are the risks?  How can they be avoided?
Is there a reference you can point to that talks about the issues?


I can add an explanation and example (of course, it means the document 
won't be a true republication anymore, but this can be clarified in the 
abstract).



In section 3.8.6 (CT-KIP server's second PDU), on pages 27 and 28,
I am having trouble matching message fields (shown on page 27) with
descriptions (given on pages 27 and 28).


The initial fields in the description are attributes inherited from the 
abstract type (c.f. 3.8.5 that makes it explicit that the Version 
attribute is inherited from the abstract type). I can clarify this.


I agree with your suggestions for the nits, but will, as you propose, hold 
back on making any changes until all comments have been received and Russ 
has had a chance to discuss them with me.


-- Magnus

On Wed, 5 Jul 2006, Gray, Eric wrote:


Magnus,

I am the assigned Gen-ART reviewer for:

draft-nystrom-ct-kip-01.txt

For background on Gen-ART, please see the FAQ at
.


Please wait for instructions from Russ Housley before
taking any action on these comments.

This document is nearly ready for publication as an
Informational RFC.

I have some questions/comments and a few very minor
NITs.

Comments:


General Comment:
---

The abstract claims this is almost entirely a literal
republication of a document produced by the OTPS service
of RSA Laboratories - who intends to retain change control.
The abstract specifically excludes the Intellectual Propety,
and IANA, Considerations sections.

I'm not sure what that means with respect to handling of
comments relative to the "republished" material.

Also, it's a minor point but, unless the previous document
was also an RFC (I saw no indication that this was true),
there are quite a few other portions of the current draft
that probably did not exist in the original document (RFC
boiler-plate, reference sections and author information,
for example).

Perhaps this is implied by the phrase "body of this ..."

I read through the document.  It appears to be well thought
out and written, and I did not see anything that is ambiguous
or obviously unclear - although (not being an expert in this
area) some sections just eluded comprehension for me.

Specific Comments/Questions:
---

In section 3.7.1 - you say:

"The XML format for CT-KIP messages have been designed to be
extensible.  However, it is possible that the use of extensions will
harm interoperability and therefore any use of extensions should be
carefully considered."

Can we say anything about what "harm interoperability" or "carefully
considered" means?  What are the risks?  How can they be avoided?
Is there a reference you can point to that talks about the issues?

-

In section 3.8.6 (CT-KIP server's second PDU), on pages 27 and 28,
I am having trouble matching message fields (shown on page 27) with
descriptions (given on pages 27 and 28).

-

NITs:


In section 5.2.1, the last sentence would be better worded as:

"Sections 5.2.2 through 5.2.7 analyze these attack scenarios."

-

In section 6 (IANA Considerations), you say:

"None at this point; the MIME type is already registered."

The document mentions several MIME types.  I assume you meant:
"application/vnd.otps.ct-kip+xml" in this case (as opposed to
- for instance - "image/jpeg" or "image/gif").

I would change the section to read either -

"None at this point; the MIME type (section 4.2.2) is already
registered."

OR

"IANA has no action with respect to this document."





___
Gen-art mailing list
Gen-art@ietf.org
https://www1.ietf.org/mailman/listinfo/gen-art

[Gen-art] review of draft-ietf-dnsext-mdns-46.txt

[Francis Dupont]

I am the assigned Gen-ART reviewer for draft-ietf-dnsext-mdns-46.txt.
For background on Gen-ART, please see the FAQ at
.

Please resolve these comments along with any other
Last Call comments you may receive.

Summary: Ready with nits

Some comments/suggestions (including a required fix for 5.3 [b]):
 - 2.1 page 5: the 512 octets default maximum seems a bit too conservative?
 - 2.1.1 C page 6: request -> query (IMHO the document should use only
  the pair of terms query/response)
 - 2.9 page 14: check if SIG(0) is not now RSIG(0) (PS: as far as I know
  the RFC 2931 was not updated so it is still SIG(0))
 - 3.1 pages 17 and 18: linklocal -> link-local (twice)
 - 4.1 page 19: I am not happy with "interpreted as an unsigned integer"
  as this involves an ambiguous byte order (I assume it is big endian
  but it is not specified). I strongly prefer the lexicographical order.
 - 4.2 page 20: same than the previous point.
 - 4.2 page 21: requests -> queries, and replies -> responses
 - 5 page 22: 802.11 -> IEEE 802.11
 - 5.1 page 23: silently discarding them as rapidly as possible ->
  silently discarding them (I don't know a way to slowly discard them :-)
 - 5.2 page 23: link layer security -> link-layer security (the link-xxx
  style seems fine)
 - 5.2 page 23: local-link -> local link
 - 5.3 [a] page 24: same than 2.9
 - 5.3 [b] page 24: IPsec ESP has two NULL algorithms, NULL encryption
  and NULL integrity/authentication (cf RFC 4305, the term transform comes
  from RFC 4306 but "algorithm" is better). I strongly suggest:
  null-transform -> NULL encryption algorithm.
 - 6 page 25: my dictionary has no "coincident", in particular in this
  position... (i.e., there is a possible wording/language problem)
 - 8.2 pages 26/27: many informative references are for 2002 I-Ds,
  perhaps this can become a problem?
 - Acks page 28: Van-Valkenburg -> van Valkenburg? (please check with him)
 - Open Issues page 30: should be marked as to be removed by the RFC editor. 

Regards

[EMAIL PROTECTED]

___
Gen-art mailing list
Gen-art@ietf.org
https://www1.ietf.org/mailman/listinfo/gen-art