ICANN ICANN Email List Archives

[gnso-reg-sgc]


<<< Chronological Index >>>    <<< Thread Index >>>

RE: [gnso-reg-sgc] Draft Final Report of Sub Group C

  • To: "Goodendorf, Lynn \(IHG\)" <Lynn.Goodendorf@xxxxxxx>, "Chris Gibson" <cgibson@xxxxxxxxxxx>, "Maria Farrell" <maria.farrell@xxxxxxxxx>, <gnso-reg-sgc@xxxxxxxxx>
  • Subject: RE: [gnso-reg-sgc] Draft Final Report of Sub Group C
  • From: "Rosette, Kristina" <krosette@xxxxxxx>
  • Date: Wed, 30 May 2007 10:52:53 -0400

I agree with the proposed changes submitted by Chris and Lynn.  
 
I would prefer that we take Lynn's suggestion a step further.  More
specifically, I believe it's appropriate that the report use the
MUST-SHOULD-MAY conventions from RFC 2119 that have been used in other
WGs AND the the Agreement-Support-Alternative View conventions that
other WGs (IDN and Protecting the Rights of Others) are using.  A
summary table at the beginning of the report that sets forth the
recommendations with levels of support would be very helpful, and would
presumably make integration and cross-referencing of this subgroup's
work with the other groups' work easier.
 
While I am not usually one to simply suggest a change (as opposed to
suggesting and circulating a revision), I must do so here as I've just
finished working on the PRO WG and don't have any time to spare in light
of the deadlines for both this work and the PRO WG final report. 
 
Here's a link to RFC 2119 http://www.ietf.org/rfc/rfc2119.txt
<http://www.ietf.org/rfc/rfc2119.txt>  , but I copy below the relevant
text. 

-*- 

In many standards track documents several words are used to signify the
requirements in the specification. These words are often capitalized.
This document defines these words as they should be interpreted in IETF
documents. Authors who follow these guidelines should incorporate this
phrase near the beginning of their document: The key words "MUST", "MUST
NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT",
"RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be
interpreted as described in RFC 2119.

Note that the force of these words is modified by the requirement level
of the document in which they are used. 
1. MUST This word, or the terms "REQUIRED" or "SHALL", mean that the
definition is an absolute requirement of the specification.

 2. MUST NOT This phrase, or the phrase "SHALL NOT", mean that the
definition is an absolute prohibition of the specification. 

3. SHOULD This word, or the adjective "RECOMMENDED", mean that there may
exist valid reasons in particular circumstances to ignore a particular
item, but the full implications must be understood and carefully weighed
before choosing a different course.

 4. SHOULD NOT This phrase, or the phrase "NOT RECOMMENDED" mean that
there may exist valid reasons in particular circumstances when the
particular behavior is acceptable or even useful, but the full
implications should be understood and the case carefully weighed before
implementing any behavior described with this label. 

5. MAY This word, or the adjective "OPTIONAL", mean that an item is
truly optional. One vendor may choose to include the item because a
particular marketplace requires it or because the vendor feels that it
enhances the product while another vendor may omit the same item. An
implementation which does not include a particular option MUST be
prepared to interoperate with another implementation which does include
the option, though perhaps with reduced functionality. In the same vein
an implementation which does include a particular option MUST be
prepared to interoperate with another implementation which does not
include the option (except, of course, for the feature the option
provides.)

 6. Guidance in the use of these Imperatives Imperatives of the type
defined in this memo must be used with care and sparingly. In
particular, they MUST only be used where it is actually required for
interoperation or to limit behavior which has potential for causing harm
(e.g., limiting retransmisssions) For example, they must not be used to
try to impose a particular method on implementors where the method is
not required for interoperability. 

-*-

Here's explanatory text for the A-S-Av convention:

 
-Agreement -  there is broad agreement within the Working Group (largely
equivalent to "rough consensus" as used in the IETF);

 

-Support -  there is some gathering of positive opinion, but competing
positions may exist and broad agreement has not been reached; 

 

-Alternative view - a differing opinion that has been expressed, without
garnering enough following within the WG to merit the notion of either
Support or Agreement.

 

-*-

 

Kristina 

 


________________________________

        From: owner-gnso-reg-sgc@xxxxxxxxx
[mailto:owner-gnso-reg-sgc@xxxxxxxxx] On Behalf Of Goodendorf, Lynn
(IHG)
        Sent: Wednesday, May 30, 2007 10:31 AM
        To: Chris Gibson; Maria Farrell; gnso-reg-sgc@xxxxxxxxx
        Subject: RE: [gnso-reg-sgc] Draft Final Report of Sub Group C
        
        
        I would just like to add a comment that I feel these revisions
help achieve the balance needed to win a broad consensus of support.
         
        Some members have not been as vocal in our discussions and I do
not have a sense of whether the majority of the group is in agreement.
        Since we did not have a teleconference today, is it possible to
have some kind of quick informal poll?
         
        Regards,
        -Lynn Goodendorf

________________________________

        From: Chris Gibson [mailto:cgibson@xxxxxxxxxxx] 
        Sent: Wednesday, May 30, 2007 10:12 AM
        To: 'Chris Gibson'; 'Maria Farrell'; gnso-reg-sgc@xxxxxxxxx
        Cc: Goodendorf, Lynn (IHG)
        Subject: RE: [gnso-reg-sgc] Draft Final Report of Sub Group C
        
        

        Sorry for the duplication - this message has the document
attached.

         

        Chris

         

        
________________________________


        From: owner-gnso-reg-sgc@xxxxxxxxx
[mailto:owner-gnso-reg-sgc@xxxxxxxxx] On Behalf Of Chris Gibson
        Sent: Wednesday, May 30, 2007 10:04 AM
        To: 'Maria Farrell'; gnso-reg-sgc@xxxxxxxxx
        Cc: 'Goodendorf, Lynn (IHG)'
        Subject: RE: [gnso-reg-sgc] Draft Final Report of Sub Group C

         

        Dear All,

         

        I have attached the draft final report for sub-group C with some
revisions marked in red-line, which Lynn Goodendorf and I propose.  We
believe these suggested changes are helpful to improve some of the
writing, accuracy and balance of the report.

         

        Thanks,

         

        Chris Gibson

         

          

        
________________________________


        From: owner-gnso-reg-sgc@xxxxxxxxx
[mailto:owner-gnso-reg-sgc@xxxxxxxxx] On Behalf Of Maria Farrell
        Sent: Friday, May 25, 2007 2:12 PM
        To: gnso-reg-sgc@xxxxxxxxx
        Subject: [gnso-reg-sgc] Draft Final Report of Sub Group C

         

        Dear all,

         

        Attached is the Final Report of Sub Group C, prepared by its
chair, Jon Bing. 

         

        We agreed on this week's call to discuss any further - hopefully
minor - changes to the report using this mailing list rather than on a
conference call. 

         

        So please review this draft and circulate any comments on it to
this list. Please do use 'track changes' mode if you suggest changes to
the document. 

         

        We should expect to finalise this report next week and submit it
to the Working Group. I will also be adding some basic information to it
about membership of the group and attendance.  

         

        All the best, Maria



<<< Chronological Index >>>    <<< Thread Index >>>

Privacy Policy | Terms of Service | Cookies Policy